PowerShell 7+ a SQL Server

PowerShell 7+ współpracuje z modułem SqlServer, choć część starszych funkcji wymaga jeszcze Windows PowerShell 5.1.

PowerShell 7+ i moduł SqlServer

PowerShell 7+ jest rozwijany jako wieloplatformowa powłoka i środowisko automatyzacji oparte na nowszym środowisku .NET. Do pracy z Microsoft SQL Server używa się przede wszystkim modułu SqlServer, który zawiera polecenia do wykonywania zapytań, uruchamiania skryptów oraz obsługi wybranych obiektów serwera. Moduł instaluje się z galerii PowerShell poleceniem Install-Module -Name SqlServer, a dostępne polecenia można sprawdzić przez Get-Command -Module SqlServer.

PowerShell 7+ i Windows PowerShell 5.1 są odrębnymi środowiskami. W systemie Windows mogą być zainstalowane równocześnie, ale korzystają z różnych procesów i mogą ładować moduły w odmienny sposób. Dlatego przed uruchomieniem skryptu należy sprawdzić wersję poleceniem $PSVersionTable.PSVersion, ścieżkę modułu za pomocą Get-Module SqlServer -ListAvailable oraz faktycznie załadowaną wersję przez Get-Module SqlServer.

Wykonywanie zapytań przez Invoke-Sqlcmd

Najczęściej używanym poleceniem modułu SqlServer jest Invoke-Sqlcmd. Pozwala ono przekazać zapytanie w parametrze -Query albo wskazać plik skryptu przez -InputFile. Nazwę instancji SQL Server podaje się w parametrze -ServerInstance, a nazwę bazy danych w -Database. Przykładowe polecenie ma postać Invoke-Sqlcmd -ServerInstance "localhost" -Database "TestDb" -Query "SELECT name FROM sys.databases". Wynik jest zwracany do potoku PowerShell, więc może zostać zapisany do pliku, przekształcony lub przekazany innemu poleceniu.

Przy połączeniu z użyciem uwierzytelniania SQL Server można użyć obiektu PSCredential i parametru -Credential. Hasła nie powinny być wpisywane bezpośrednio w treści skryptu ani przekazywane jako zwykły tekst w wierszu poleceń. W przypadku uwierzytelniania systemowego sposób działania zależy od środowiska, konta uruchamiającego PowerShell oraz konfiguracji serwera SQL Server. Samo uruchomienie powłoki jako administrator systemu Windows nie nadaje automatycznie uprawnień w bazie danych, ponieważ uprawnienia SQL Server są kontrolowane oddzielnie.

Różnice zgodności między PowerShell 7+ i 5.1

Nie każda funkcja związana z SQL Server zachowuje się identycznie w PowerShell 7+ i Windows PowerShell 5.1. Moduł SqlServer współpracuje z PowerShell 7+, lecz starsze elementy ekosystemu SQL Server mogą wymagać Windows PowerShell 5.1. Dotyczy to zwłaszcza poleceń lub dodatków zależnych od starszych bibliotek .NET, komponentów Windows albo mechanizmów dostępnych wyłącznie w klasycznym środowisku Windows PowerShell.

Przed migracją skryptu należy zweryfikować używane polecenia, wersję modułu oraz sposób uwierzytelniania. Pomocne są polecenia Get-Help Invoke-Sqlcmd -Full, Get-Module SqlServer -ListAvailable i test prostego zapytania w docelowym środowisku. Jeżeli skrypt korzysta z poleceń innych niż Invoke-Sqlcmd, trzeba sprawdzić ich dostępność poleceniem Get-Command, ponieważ obecność modułu nie oznacza, że wszystkie historyczne komponenty SQL Server będą obsługiwane przez każdą wersję PowerShell.

Diagnostyka połączenia i błędów skryptu

Błąd podczas wykonywania polecenia PowerShell nie musi oznaczać błędu samego zapytania SQL. Przyczyną może być brak modułu, niepoprawna nazwa instancji, niedostępny port, odmowa uwierzytelnienia, brak uprawnień do wskazanej bazy albo niezgodność używanego polecenia z PowerShell 7+. Diagnostykę warto prowadzić etapami: najpierw sprawdzić wersję powłoki i modułu, następnie wykonać proste zapytanie, a dopiero później uruchamiać złożony skrypt.

W praktyce serwisowej analizuje się zarówno komunikat PowerShell, jak i szczegóły wyjątku zwrócone przez dostawcę połączenia z SQL Server. Znaczenie ma także kontekst uruchomienia: skrypt uruchomiony ręcznie przez użytkownika może korzystać z innych poświadczeń niż zadanie uruchamiane przez usługę lub harmonogram. W przypadku komputera z systemem Windows można również porównać działanie tego samego skryptu w PowerShell 7+ i Windows PowerShell 5.1, aby ustalić, czy problem wynika z wersji środowiska, modułu SqlServer czy konfiguracji SQL Server.