Посилання на контекст SQL Agent

На моїй новій роботі у нас є кілька названих екземплярів на кожному сервері. напр

• Server1 \ Dev
• Server1 \ DevIintegrated
• Server1 \ QA

У мене є сценарій SQL PowerShell в роботах, який викликає ОС, викликає, Foo.exeале потрібно передавати параметр командного рядка (рядок з'єднання). Завдання агента SQL буде існувати в кожному екземплярі з кроком типу PowerShell, який повинен знати, що таке поточний контекст. тобто це виконання розпочалося на DevIntegrated.

У мене немає бажання починати кожен сценарій з ...

$thisInstance = "Dev"

... тим більше, що мені доведеться це редагувати, коли ми переходимо до середовищ (нових серверів та названих примірників) у наступні місяці.

Якщо я запускаю SQLPS, я можу визначити свій екземпляр, нарізавши та підкресливши результати Get-Location або запустивши

(Invoke-Sqlcmd -Query "SELECT @@servername AS ServerName" -SuppressProviderContextWarning).ServerName

Коли агент SQL запускає завдання типу PowerShell, він запускається в C: \ windows \ system32 і Get-Locationмаршрут не працює, оскільки він не знаходиться в контексті SQLSERVER. Я можу перейти до цього контексту, але я буду в "корені" SQL Server і не знаю, в якому екземплярі я повинен бути. Використання Invoke-Sqlcmdмаршруту не працюватиме ні з тієї ж причини (технічно це виходить, як там не є примірником за замовчуванням)

Наскільки мені відомо, я перерахував усі основні "речі", які я можу потрапити в журнал роботи, але нічого, схоже, не показує SQLSERVER:\SQL\Server1\DevIntegrated

• Get-ChildItem
• Get-Host
• Get-Location
• Get-Process
• Get-PSDrive
• Get-PSProvider
• Get-Service
• Get-TraceSource
• Get-Variable

Get-ProcessЗдається, я міг би скористатися цим і деяким вуду, намагаючись обмотати речі, вдаряючи про екземпляри та узгоджуючи павуків, але це просто звучить як кривавий злом з пекла. Повинно бути щось основне, чого я не вистачає, може хтось пролити світло?

Досліджені альтернативи PowerShell

Я досліджував, використовуючи інші види роботи, і не отримав задовільного рішення. Дослідження показали, що PowerShell, зазначений у SQL Agent, був SQLPS, і запустити його екземпляр, натиснувши правою кнопкою миші на Агент, автоматично перекинув мене в потрібне місце. Лише коли я вставив свій інтерактивний код у крок завдання, я дізнався про різницю, про яку говорилося раніше.

Тип роботи ОС поставив мене в ідентичний стан тим, що я не міг знайти спосіб визначити, який екземпляр потрапив у командну оболонку. Звичайно, я міг sqlcmd і отримати значення, @@servernameале якби я знав, з якого з'єднання запустити sqlcmd, мені не потрібно було б запитувати базу даних;)

TSQL, ймовірно, може працювати, якщо ми включимо, xp_cmdshellале я не впевнений, чи він увімкнено --- урядовий об'єкт, і вони можуть бути відповідальними за налаштування, що не використовуються за замовчуванням. Вже тоді я застряг у фьюзингу з динамічним SQL і втратив багато виразності та потужності, яку надає PowerShell.

Хоча трохи непогано, я думав визначити змінну на першому кроці та передати її наступним крокам, але дослідження показало цю статтю Поводження з декількома кроками роботи (BOL)

Крок роботи повинен бути самостійним. Тобто завдання не може передавати булеві значення, дані чи числові значення між етапами завдання. Однак ви можете передавати значення з одного кроку завдання Transact-SQL в інший, використовуючи постійні таблиці або глобальні тимчасові таблиці. За допомогою файлів ви можете передавати значення з кроків завдання, які запускають виконувані програми з одного кроку завдання на інший.

Я не можу використовувати поширені хитрощі, як добре відомі файлові / середовищні змінні / налаштування реєстру, які Foo.exeшукають, оскільки це запобіжить одночасному виконанню через екземпляри.

TL; DR:

На кроці роботи SQL Agent Job типу PowerShell, як можна визначити екземпляр SQL Server, який запустив процес?

Якщо ви подивитеся на BOL для SQL Server, агент SQL Server надає набір "жетонів", які він замінить як текст командного кроку завдання, так і вихідний файл (пізніше це не дозволить працювати кнопці "перегляду" графічного інтерфейсу). Ці маркери, здається, працюють для будь-якого типу кроку, крім T-SQL.

https://docs.microsoft.com/en-us/sql/ssms/agent/use-tokens-in-job-steps#sql-server-agent-tokens

Отже, якщо у вас є крок SQL 2008 PowerShell, ви можете почати його з:

$sqlInstance = "$(ESCAPE_DQUOTE(SRVR))"

Можливо, вам потрібно буде використовувати MACH(ім’я машини) та INST(просто ім'я екземпляра) замість цього, тому що з екземпляром за замовчуванням SRVR == MACH, але з названими екземплярами SRVR == MACH\INST.

Сумно сказати, що я багато не робив із тим, що сценарії PowerShell викликали всередині SQL Server. Також я не за комп’ютером, що можу зараз із ним пограти.

Я вважаю, що замість того, щоб використовувати крок типу PowerShell, що якщо ви використовували CmdExec і просто зателефонували своєму скрипту так, як це було б з командного рядка "powershell 'MyScript.ps1" ", ви могли б потім передати параметр, який має екземпляр, з якого ви працюєте. Як і "Powershell" MyScript.ps1 "MyInstanceName".

Отже, на початку вашого сценарію у вас є параметр (), щоб прийняти це значення MyInstanceName:

param(
   [Parameter(Position=0,Mandatory=$True)]
   [string]$InstanceName
)
#so if I wanted to use sqlcmd
sqlcmd -S $InstanceName -Q "SELECT @@VERSION"

Коли ви почали заявляти один крок, необхідний, щоб знати, на якому екземплярі він був, щоб сценарій PowerShell міг правильно викликати Foo.exe. Однак згодом ви згадаєте про можливість передавати значення іншим крокам. Якщо це правда, ви можете поглянути на створення невеликого пакета SSIS, який викликає ваш сценарій PowerShell і робить все, що вам потрібно. За допомогою SSIS ви зможете встановити глобальну змінну, якою міг би користуватися весь пакет.