¿Qué técnica de PowerShell debo usar para hablar con SQL Server?

En última instancia, me gustaría usar PowerShell para reemplazar los viejos scripts de KornShell que usamos para los monitores de instancias SQL. Sin embargo, me está costando mucho pensar en las diferentes formas en que PowerShell realmente puede hablar con el servidor SQL. No estoy seguro de si se trata de todos ellos, pero aquí hay 5 formas completamente diferentes de consultar la versión de un servidor SQL:

1. SQLConnection .NET Class

$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. Proveedor de 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"

¿Cómo debo decidir cuál de estas técnicas usar para diferentes escenarios? ¿Hay pros / contras de cada uno? ¿Algunas de estas técnicas de powershell 1.0 fueron superadas en 2.0? ¿Algunos de ellos no funcionarán para comunicarse con los servidores SQL 2000 o 2005?

En un nivel, estoy seguro de que la respuesta es "usar lo que funcione", pero para alguien nuevo en Powershell, es muy confuso ver tantos ejemplos escritos como # 1 arriba, cuando eso es más largo y (en mi opinión) menos ejemplo de "power-like".

Un poco más de información en caso de que sea relevante: el servidor SQL que realmente ejecutará los scripts del monitor es SQL 2005, pero se usa para conectarse a múltiples instancias desde SQL 2000 hasta 2008R2.

Obviamente, mucho de esto depende de una simple elección personal. Aquí están mis propias racionalizaciones personales.

He estado usando Powershell con SQL SQL desde PSH v 1.0, y antes de que SQL Server comenzara a integrarlo oficialmente. (Cuando comencé con PSH, administraba servidores SQL Server 2000 y 2005). Entonces, aprendí con SMO (o es una encarnación un poco más antigua, cuyo nombre se me escapa en este momento) y .Net y estoy acostumbrado a ellos. En general, me inclino por SMO, ya que hace que algunas cosas sean mucho más fáciles, como crear scripts de objetos. Mi propio código usa SMO algunas veces y .Net algunas veces. Creo que es más útil usar .Net para obtener conjuntos de resultados simples, por ejemplo.

Creo que Invoke-SQLCMD tiene más sentido si tiene muchos scripts TSQL existentes. Si está creando cadenas y ejecutándolas a través de -Query, eso será complicado. Si tiene una buena idea de cómo funciona Powershell con .Net y SMO, usar Invoke-SQLCMD ocasionalmente, cuando tiene que ejecutar un archivo de script, es fácil.

Siempre he encontrado que la cosa de PSDrive es torpe y sentí que la implementaron porque quedaron atrapados en la idea de "todo puede parecer un sistema de archivos". Sé que los chicos * nix aman \ proc y tal, pero siento que esta implicación se siente forzada. Creo que PSDrive está bien, tal vez incluso bueno si odias la interfaz de usuario, por explorar cosas, pero nunca he escrito un script que lo use.

Nunca he visto a nadie usar el proveedor de WMI. Entonces, esa sería mi última opción.

Entonces, lideraría con SMO y volvería a .Net cuando sea más útil.

4 para trabajos nuevos, 5 para reutilizar scripts o lugares existentes T-SQL tiene más sentido que el código de estilo basado en objetos / elegante. Me gustan más porque son claros y simples.

Tiendo a inclinarme hacia el uso de SQLPS si puedo. Es más simple y si lo uso en scripts es mucho más fácil de leer y escribir menos que tratar de usar SMO. SMO tiene su lugar en que tiene un poco de poder, pero a veces puede ser confuso de usar si no está familiarizado con él.

Creo que a medida que se lancen las versiones de SQL Server, SQLPS mejorará. Sobre todo porque con SQL Server 2012 SQLPS no es modular en lugar de ser un complemento. Esto le permitirá a Microsoft sacar soluciones o mejoras con SQLPS a través de paquetes de servicio o revisiones, tal vez incluso CU.

Luego, también están las ofertas de la comunidad como SQLPSX , que tiene mucho de ese código SMO ya preparado para ti como cmdlets y funciones. De lo que estoy totalmente dispuesto a no reinventar la rueda :)