web-dev-qa-db-fra.com

Quelle technique PowerShell dois-je utiliser pour parler à SQL Server?

J'aimerais finalement utiliser PowerShell pour remplacer les anciens scripts KornShell que nous utilisons pour les moniteurs d'instance SQL. J'ai du mal, cependant, à me familiariser avec toutes les différentes façons dont PowerShell peut réellement parler au serveur SQL. Je ne sais pas si c'est tous, mais voici 5 façons entièrement différentes de interroger la version d'un serveur SQL:

1. Classe .NET SQLConnection

$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. Fournisseur WMI

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

. 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"

Comment dois-je procéder pour décider laquelle de ces techniques utiliser pour différents scénarios? Y a-t-il des avantages/inconvénients pour chacun? Certaines de ces techniques PowerShell 1.0 ont-elles été dépassées en 2.0? Certains d'entre eux ne fonctionneront-ils pas pour communiquer avec les serveurs SQL 2000 ou 2005?

À un certain niveau, je suis sûr que la réponse est "utilisez ce qui fonctionne", mais pour quelqu'un de nouveau à Powershell, il est très déroutant de voir autant d'exemples écrits comme # 1 ci-dessus, quand c'est le plus long et (dans mon esprit) le moins exemple "de type coquille".

Un peu plus d'informations au cas où cela serait pertinent: le serveur SQL qui exécutera réellement les scripts de contrôle est SQL 2005, mais il est utilisé pour se connecter à plusieurs instances de SQL 2000 à 2008R2.

sql-servermonitoringpowershell
29
BradC

De toute évidence, cela dépend en grande partie d'un simple choix personnel. Voici mes propres rationalisations personnelles.

J'utilise Powershell avec SQL SQL depuis PSH v 1.0 et avant que SQL Server ne commence officiellement à l'intégrer. (Quand j'ai commencé avec PSH, j'administrais des serveurs SQL Server 2000 et 2005.) Donc, j'ai appris avec SMO (ou c'est une incarnation légèrement plus ancienne, dont le nom m'échappe pour le moment) et .Net et je suis habitué à leur. Je pencherais généralement pour SMO, car cela rend certaines choses beaucoup plus faciles, comme l'écriture de scripts sur des objets. Mon propre code utilise SMO parfois et .Net parfois. Je pense qu'il est plus pratique d'utiliser .Net pour obtenir des jeux de résultats simples, par exemple.

Je pense que Invoke-SQLCMD a plus de sens si vous avez beaucoup de scripts TSQL existants. Si vous créez des chaînes et les exécutez via -Query, cela va être compliqué. Si vous avez une bonne compréhension du fonctionnement de Powershell avec .Net et SMO, utiliser Invoke-SQLCMD à l'occasion, lorsque vous avez un fichier de script à exécuter, est facile.

J'ai toujours trouvé la chose PSDrive maladroite et j'ai senti qu'ils l'avaient implémentée parce qu'ils étaient pris dans l'idée "tout peut ressembler à un système de fichiers". Je sais que les gars de * nix adorent\proc et autres, mais je pense que cette implémentation semble en quelque sorte forcée. Je pense que PSDrive est OK, peut-être même bon si vous détestez l'interface utilisateur, pour explorer les choses, mais je n'ai jamais écrit de script qui l'utilise.

Je n'ai jamais vu personne utiliser le fournisseur WMI. Ce serait donc mon dernier choix.

Donc, je dirigerais avec SMO et retomberais sur .Net quand ce serait plus pratique.

7
darin strait

4 pour les nouveaux travaux, 5 pour la réutilisation de scripts ou de lieux existants T-SQL est plus logique que le code de style objet/chic. Je préfère ceux qui sont clairs et simples.

3
onupdatecascade

J'ai tendance à privilégier l'utilisation de SQLPS si je le peux. C'est plus simple et si je l'utilise dans des scripts, c'est beaucoup plus facile à lire et à taper moins que d'essayer d'utiliser SMO. SMO a sa place en ce qu'il a un bon peu de puissance, mais peut parfois être déroutant à utiliser si vous ne le connaissez pas.

Je pense que lorsque les versions de SQL Server seront publiées, SQLPS sera amélioré. D'autant plus qu'avec SQL Server 2012, SQLPS n'est pas modulaire au lieu d'être un composant logiciel enfichable. Cela va permettre à Microsoft de proposer des correctifs ou des améliorations avec SQLPS via des service packs ou des correctifs, peut-être même des CU.

Ensuite, il y a aussi les offres de la communauté comme SQLPSX , qui a beaucoup de ce code SMO déjà préparé pour vous en tant qu'applets de commande et fonctions. Ce que je suis tout au sujet de ne pas réinventer la roue :)

2
user507