Quale tecnica di PowerShell dovrei usare per parlare con SQL Server?

In definitiva, vorrei utilizzare PowerShell per sostituire i vecchi script di KornShell che utilizziamo per i monitor delle istanze SQL. Sto facendo fatica, però, a farmi un'idea dei diversi modi in cui PowerShell può effettivamente parlare con SQL Server. Non sono sicuro se questo è tutto, ma qui ci sono 5 modi completamente diversi in cui posso interrogare la versione di un server SQL:

1. Classe 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. Fornitore 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"

Come devo fare per decidere quale di queste tecniche utilizzare per diversi scenari? Ci sono pro / contro di ciascuno? Alcune di queste tecniche PowerShell 1.0 sono state superate nella versione 2.0? Alcuni di loro non funzioneranno per comunicare con i server SQL 2000 o 2005?

Ad un certo livello, sono sicuro che la risposta è "usa qualunque cosa funzioni", ma per qualcuno che non conosce Powershell, è molto confuso vedere così tanti esempi scritti come il numero 1 sopra, quando quello è il più lungo e (nella mia mente) meno esempio "PowerShell-like".

Un po 'più di informazioni nel caso sia rilevante: il server SQL che eseguirà effettivamente gli script di monitoraggio è SQL 2005, ma viene utilizzato per connettersi a più istanze da SQL 2000 a 2008R2.

Ovviamente, molto di questo si trasforma in una semplice scelta personale. Ecco le mie razionalizzazioni personali.

Uso Powershell con SQL SQL da PSH v 1.0 e prima che SQL Server iniziasse a integrarlo ufficialmente. (Quando ho iniziato con PSH, gestivo i server SQL Server 2000 e 2005.) Così, ho imparato con SMO (o è un'incarnazione leggermente più vecchia, il cui nome mi sfugge al momento) e .Net e sono abituato a loro. In genere mi rivolgo a SMO, poiché rende alcune cose molto più facili, come scrivere oggetti. Il mio codice usa SMO alcune volte e .Net alcune volte. Penso che sia più comodo usare .Net per ottenere semplici set di risultati, per esempio.

Penso che Invoke-SQLCMD abbia più senso se hai molti script TSQL esistenti. Se stai creando stringhe ed eseguendole tramite -Query, sarà un casino. Se hai una buona conoscenza di come Powershell funziona con .Net e SMO, usare Invoke-SQLCMD di tanto in tanto, quando hai un file di script da eseguire, è facile.

Ho sempre trovato la cosa di PSDrive goffa e ho sentito che l'hanno implementata perché sono rimasti intrappolati nell'idea "tutto può sembrare un file system". So che i ragazzi * nix adorano \ proc e simili, ma sento che questa implementazione sembra un po 'forzata. Penso che PSDrive sia OK, forse anche buono se odi l'interfaccia utente, per esplorare le cose, ma non ho mai scritto uno script che lo utilizza.

Non ho mai visto nessuno usare il provider WMI. Quindi, questa sarebbe la mia ultima scelta.

Quindi, guiderei con SMO e tornerei a .Net quando è più pratico.

4 per nuovi lavori, 5 per il riutilizzo di script o posizioni esistenti T-SQL ha più senso del codice di stile / posh basato sugli oggetti. Mi piacciono quelli migliori perché sono chiari e semplici.

Se posso, tendo ad usare SQLPS. È più semplice e se lo uso negli script è molto più facile da leggere e meno digitato rispetto al tentativo di utilizzare SMO. SMO ha il suo posto in quanto ha un buon potere, ma a volte può essere confuso da usare se non si ha familiarità con esso.

Penso che man mano che verranno rilasciate le versioni di SQL Server, SQLPS verrà migliorato. Soprattutto perché con SQL Server 2012 SQLPS non è modulare invece di essere uno snapin. Ciò consentirà a Microsoft di inviare correzioni o miglioramenti con SQLPS tramite service pack o hotfix, forse anche CU.

Poi ci sono anche le offerte della community come SQLPSX , che ha già un sacco di quel codice SMO già preparato per te come cmdlet e funzioni. Di cui sto parlando di non reinventare la ruota :)