Jakiej techniki PowerShell powinienem użyć, aby rozmawiać z SQL Server?

Ostatecznie chciałbym użyć programu PowerShell do zastąpienia starych skryptów KornShell, których używamy do monitorów instancji SQL. Trudno mi się jednak zająć mózgiem na różne sposoby, w jaki PowerShell może rozmawiać z serwerem SQL. Nie jestem pewien, czy to wszystko, ale oto 5 zupełnie innych sposobów, w jakie mogę zapytać o wersję serwera SQL:

1. Klasa SQLConnection .NET

$SqlConnection = New-Object System.Data.SqlClient.SqlConnection
$SqlConnection.ConnectionString = "Server=MyServer;Database=Master;Integrated Security=True"
$SqlCmd = New-Object System.Data.SqlClient.SqlCommand
$SqlCmd.CommandText = "Select @@version as SQLServerVersion"
$SqlCmd.Connection = $SqlConnection
$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter
$SqlAdapter.SelectCommand = $SqlCmd
$DataSet = New-Object System.Data.DataSet
$SqlAdapter.Fill($DataSet)
$SqlConnection.Close()
$DataSet.Tables[0]

2. Dostawca WMI

$sqlProperties = Get-WmiObject 
    -computerName "MyServer"
    -namespace root\Microsoft\SqlServer\ComputerManagement10
    -class SqlServiceAdvancedProperty
    -filter "ServiceName = 'MSSQLSERVER'"
$sqlProperties.VERSION

3. SMO

[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SqlServer.SMO') | Out-Null
$smo-var = New-Object ('Microsoft.SqlServer.Management.Smo.Server') 'MyServer\instancename'
$smo-var.VersionString

4. PSDrive

Set-Location SQLSERVER:\SQL\MyServerName\
$server = Get-Item Default
$server.get_VersionString()

5. Invoke-SQLCMD

Invoke-Sqlcmd -Query "SELECT @@version" -ServerInstance "MyServer"

Jak powinienem zdecydować, które z tych technik zastosować w różnych scenariuszach? Czy są zalety / wady każdego z nich? Czy niektóre z tych technik PowerShell 1.0 zostały zastąpione w wersji 2.0? Czy niektóre z nich nie będą działać w celu komunikacji z serwerami SQL 2000 lub 2005?

Na jednym poziomie jestem pewien, że odpowiedź brzmi „użyj tego, co działa”, ale dla kogoś nowego w programie PowerShell bardzo mylące jest zobaczenie tak wielu przykładów napisanych jak powyżej, gdy jest to najdłuższa i (moim zdaniem) najmniej przykład „przypominający PowerShell”.

Nieco więcej informacji, jeśli jest to istotne: SQL Server, który będzie faktycznie uruchamiał skrypty monitorowania, to SQL 2005, ale służy on do łączenia się z wieloma instancjami od SQL 2000 do 2008R2.

Oczywiście wiele z nich przechodzi na prosty osobisty wybór. Oto moje osobiste racjonalizacje.

Korzystam z Powershell z SQL SQL od PSH 1.0, a zanim SQL Server zaczął oficjalnie go integrować. (Kiedy zaczynałem od PSH, administrowałem serwerami SQL Server 2000 i 2005.) Więc nauczyłem się z SMO (lub jego nieco starszym wcieleniem, którego nazwa w tej chwili mi ucieka) oraz .Net i jestem przyzwyczajony do im. Generalnie skłaniam się ku SMO, ponieważ ułatwia to niektóre rzeczy, takie jak pisanie skryptów na obiektach. Mój własny kod czasami używa SMO, a czasem .Net. Myślę, że wygodniej jest na przykład używać .Net, aby uzyskać proste zestawy wyników.

Myślę, że Invoke-SQLCMD ma większy sens, jeśli masz wiele istniejących skryptów TSQL. Jeśli tworzysz ciągi znaków i wykonujesz je przez -Query, będzie to bałagan. Jeśli dobrze rozumiesz, jak Powershell współpracuje z .Net i SMO, od czasu do czasu korzystanie z Invoke-SQLCMD, gdy masz plik skryptowy do uruchomienia, jest łatwe.

Zawsze uważałem PSDrive za niezręczną i czułem, że ją wdrożyli, ponieważ wpadli w pomysł, że „wszystko może wyglądać jak system plików”. Wiem, że * nix faceci uwielbiają \ proc i tak dalej, ale czuję, że ta implikacja jest jakby wymuszona. Myślę, że PSDrive jest OK, może nawet dobry, jeśli nienawidzisz interfejsu użytkownika, do eksploracji rzeczy, ale nigdy nie napisałem skryptu, który go używa.

Nigdy nie widziałem, aby ktokolwiek korzystał z dostawcy WMI. To byłby mój ostatni wybór.

Więc prowadziłbym z SMO i wracałem do .Net, kiedy jest to wygodniejsze.

4 dla nowej pracy, 5 dla ponownego wykorzystania istniejących skryptów lub miejsc T-SQL ma większy sens niż kod obiektowy / szykowny styl. Najbardziej lubię te, ponieważ są jasne i proste.

Skłaniam się ku korzystaniu z SQLPS, jeśli mogę. Jest to prostsze i jeśli używam go w skryptach, jest o wiele łatwiejszy do odczytania i mniej pisania niż próba użycia SMO. SMO ma swoje miejsce w tym, że ma sporą moc, ale może być mylące w użyciu, jeśli nie jesteś z nim zaznajomiony.

Myślę, że wraz z wydaniem wersji SQL Server poprawi się SQLPS. Zwłaszcza, że ​​w SQL Server 2012 SQLPS nie jest modułowy zamiast być przystawką. Umożliwi to firmie Microsoft wypychanie poprawek lub ulepszeń za pomocą SQLPS za pośrednictwem dodatków Service Pack lub poprawek, a nawet CU.

Są też oferty społecznościowe, takie jak SQLPSX , który zawiera już wiele kodu SMO przygotowanego dla ciebie jako polecenia cmdlet i funkcje. O co mi chodzi tylko o to, żeby nie wymyślać od nowa koła :)