web-dev-qa-db-ja.com

SQL Serverと通信するには、どのPowerShellテクニックを使用すればよいですか？

最終的には、PowerShellを使用して、SQLインスタンスモニターに使用している古いKornShellスクリプトを置き換えたいと思います。しかし、PowerShellが実際にSQLサーバーと通信するさまざまな方法について頭を悩ませています。これがすべてかどうかはわかりませんが、SQLサーバーのバージョンを照会できる5つのまったく異なる方法を次に示します。

1。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。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"

さまざまなシナリオで使用するこれらの手法を決定するにはどうすればよいですか？それぞれの長所/短所はありますか？ 2.0で置き換えられたこれらのPowerShell 1.0テクニックの一部はありますか？それらのいくつかは、SQL 2000または2005サーバーとの通信に機能しませんか？

あるレベルでは、答えは「機能するものをすべて使用する」だと確信していますが、Powershellの初心者にとって、上記の＃1のように書かれた非常に多くの例を見るのは非常に混乱します。 "powershell-like"の例。

関連する場合は少し詳細：実際に監視スクリプトを実行するSQLサーバーはSQL 2005ですが、SQL 2000から2008R2までの複数のインスタンスへの接続に使用されます。

sql-servermonitoringpowershell
29
BradC

明らかに、これの多くは単純な個人的な選択に委ねられています。ここに私自身の個人的な合理化があります。

PSH v 1.0以降、SQL Serverが正式に統合する前に、SQL SQLでPowershellを使用しています。 （PSHで始めたとき、私はSQL Server 2000および2005サーバーを管理していました。）したがって、私はSMO（またはそれが少し古い化身であり、その名前が現時点で私をエスケープしている）と.Netで習得しました。それら。オブジェクトをスクリプト化するなど、いくつかの点ではるかに簡単になるため、私は一般的にSMOに傾いています。私のコードでは、SMOを使用したり、.Netを使用したりすることがあります。たとえば、.Netを使用して単純な結果セットを取得する方が便利だと思います。

Invoke-SQLCMDは、既存のTSQLスクリプトがたくさんある場合に、より意味があると思います。文字列を作成し、それを-Queryを介して実行していると、面倒になります。 Powershellが.NetおよびSMOでどのように機能するかを十分に理解している場合は、スクリプトファイルを実行するときに、Invoke-SQLCMDを使用するのは簡単です。

私はいつもPSDriveの物事を不格好に見つけ、「すべてがファイルシステムのように見える可能性がある」という考えに追いついたので、PSDriveが実装されていると感じていました。 * nixの人たちは\ procなどを愛していることは知っていますが、この実装は一種の強制されていると感じています。 PSDriveは大丈夫だと思います。UIが嫌いな場合でも、物事を探るのには良いかもしれませんが、それを使用するスクリプトを記述したことはありません。

WMIプロバイダーを使用している人を見たことがありません。それで、それが私の最後の選択です。

したがって、私はSMOでリードし、必要に応じて.Netにフォールバックします。

7
darin strait

4は新しい作業、5は既存のスクリプトまたは場所を再利用するためのもので、T-SQLはオブジェクトベース/ poshスタイルのコードよりも理にかなっています。それらは明確でシンプルなので、私はそれらが一番​​好きです。

3
onupdatecascade

できればSQLPSを使用する傾向があります。それは単純で、スクリプトで使用すると、SMOを使用するよりも読みやすく、タイピングが少なくなります。 SMOは、十分なパワーを備えているという点でその役割を果たしますが、慣れていないと、使用するのが難しい場合があります。

SQL Serverのバージョンがリリースされると、SQLPSが改善されると思います。特にSQL Server 2012では、SQLPSはスナップインではなくモジュール化されていません。これにより、Microsoftは、サービスパックまたはホットフィックス、さらにはCUを通じて、SQLPSの修正または改善をプッシュできるようになります。

次に、 [〜＃〜] sqlpsx [〜＃〜] のようなコミュニティ製品もあり、コマンドレットと関数としてすでに準備されているSMOコードがたくさんあります。それは私が車輪を再発明しないことについてすべてです:)

2
user507