Dans mon nouveau travail, nous avons plusieurs instances nommées sur chaque serveur. par exemple
- Server1 \ Dev
- Server1 \ DevIntegrated
- Server1 \ QA
J'ai un script SQL PowerShell en cours qui appelle le système d'exploitation, appelle Foo.exe
mais doit passer un paramètre de ligne de commande (la chaîne de connexion). Un travail SQL Agent existera sur chaque instance, avec une étape de type PowerShell, qui doit connaître le contexte actuel. ie Cette exécution a commencé sur DevIntegrated.
Je ne souhaite pas que chaque script commence par ...
$thisInstance = "Dev"
... d'autant plus que je devrais le modifier lorsque nous migrerons vers des environnements (nouveaux serveurs et instances nommées) dans les mois à venir.
Si je démarre SQLPS, je peux déterminer mon instance en découpant et en découpant les résultats de Get-Location ou en exécutant
(Invoke-Sqlcmd -Query "SELECT @@servername AS ServerName" -SuppressProviderContextWarning).ServerName
Lorsque l'Agent SQL démarre un travail de type PowerShell, il démarre dans C: \ windows \ system32 et l' Get-Location
itinéraire ne fonctionne pas car il ne se trouve pas dans le contexte SQLSERVER. Je peux changer dans ce contexte mais je serai à la "racine" de SQL Server et je ne saurai pas dans quelle instance je devrais être. L'utilisation de la Invoke-Sqlcmd
route ne fonctionnera pas non plus pour la même raison (techniquement, elle expire comme n'est pas une instance par défaut)
À ma connaissance, j'ai énuméré toutes les «choses» de base que je peux entrer dans le journal des tâches, mais rien ne semble montrer SQLSERVER:\SQL\Server1\DevIntegrated
Get-ChildItem
Get-Host
Get-Location
Get-Process
Get-PSDrive
Get-PSProvider
Get-Service
Get-TraceSource
Get-Variable
Get-Process
semble que je pourrais utiliser cela et un vaudou d'essayer de bricoler les choses ensemble en frappant les instances et en faisant correspondre les spids, mais cela ressemble juste à un hack sanglant de l'enfer. Il doit y avoir quelque chose de basique qui me manque, quelqu'un peut-il faire la lumière?
Recherche d'alternatives à PowerShell
J'avais étudié l'utilisation d'autres types d'emploi et je n'ai pas obtenu de résolution satisfaisante. La recherche a indiqué que PowerShell répertorié sous SQL Agent était SQLPS et que le démarrage d'une instance de celui-ci en cliquant avec le bouton droit sur l'agent m'a automatiquement déposé au bon endroit. Ce n'est que lorsque j'ai collé mon code interactif dans l'étape de travail que j'ai appris la différence comme mentionné précédemment.
Le type de travail du système d'exploitation m'a mis dans un état identique en ce sens que je ne pouvais pas trouver un moyen de déterminer quelle instance m'avait déposé dans le shell de commande. Bien sûr, je pourrais sqlcmd et obtenir la valeur de @@servername
mais si je savais quelle connexion pour démarrer sqlcmd, je n'aurais pas besoin d'interroger la base de données;)
TSQL pourrait probablement fonctionner si nous l'activions xp_cmdshell
mais je ne sais pas s'ils l'ont activé --- installation gouvernementale et ils peuvent être persnickety sur des paramètres non par défaut. Même alors, je suis coincé avec le SQL dynamique et je perds beaucoup de l'expressivité et de la puissance que PowerShell prête.
Bien qu'un peu disgracieux, je pensais définir une variable à la première étape et la transmettre aux étapes successives, mais la recherche a révélé cet article Gestion des étapes de travail multiples (BOL)
Les étapes du travail doivent être autonomes. En d'autres termes, un travail ne peut pas transmettre de valeurs booléennes, de données ou de valeurs numériques entre les étapes du travail. Vous pouvez toutefois transmettre des valeurs d'une étape de travail Transact-SQL à une autre en utilisant des tables permanentes ou des tables temporaires globales. Vous pouvez transmettre des valeurs d'étapes de travail qui exécutent des programmes exécutables d'une étape de travail à une autre étape de travail à l'aide de fichiers.
Je ne peux pas utiliser des astuces courantes comme un fichier / des variables d'environnement / un paramètre de registre bien connus qui Foo.exe
recherchent car cela empêcherait l'exécution simultanée entre les instances.
TL; DR:
Dans une étape de travail de l'Agent SQL de type PowerShell, comment pouvez-vous déterminer l'instance de SQL Server qui a lancé le processus?