Powershellを使用した保守計画
現在、約125の実稼働インスタンスがあり、それぞれにスクリプトベースのメンテナンスプランがエージェントジョブとして実行されています。
実行されるタスクは、Index Reorg/Rebuild、Statsの更新、およびCheckdbです。バックアップはNetbackupによって管理されるため、計画の一部にはなりませんが、いくつかの例外があります。
昨年、すべてのインスタンスをSSMSウィザードで作成したプランからスクリプトベースのメンテナンスプランに移動しました（それらは嫌いです）。それらは効率的で効果的であるため、全体的に満足しています。
もう少し先に進むことが可能かどうか疑問に思っています。私は最近、インスタンスを指すと、そのインスタンスのデータベースを反復処理し、オンデマンドでこれら3つのタスクを実行するPowerShellスクリプトに取り組んでいます。
私の質問は、すべてのインスタンスに対してこれを行うことによって、誰かが何らかの欠点を見ることができるかどうかです。 Windowsスケジュールのインスタンスのリストを繰り返し処理し、メンテナンスタスクを実行する単一のPowerShellスクリプトをDBAサーバーに配置します。エラーはすべて処理され、ログなどに書き出されます。
これの主な利点は、mpジョブを新しいインスタンスにデプロイしたり、スケジュールを構成したりしないことです。スクリプトが繰り返す必要のあるインスタンスに新しいインスタンスの名前を追加するだけです。
あなたの考えを歓迎します。
私は最近、インスタンスを指すと、そのインスタンスのデータベースを反復処理し、オンデマンドでこれら3つのタスクを実行するPowerShellスクリプトに取り組んでいます。
私の質問は、すべてのインスタンスに対してこれを行うことによって、誰かが何らかの欠点を見ることができるかどうかです。 Windowsスケジュールのインスタンスのリストを繰り返し処理し、メンテナンスタスクを実行する単一のPowerShellスクリプトをDBAサーバーに配置します。エラーはすべて処理され、ログなどに書き出されます。
問題は、プロセスの記述方法に基づいています。ですから、考えてみればすぐに検討できることがいくつかあります。どんな答えでも作者の意見に行くのですが。
- 並列処理または順次処理を行いますか？
順次処理を使用している場合、特定の1つのサーバーがインデックスのメンテナンスまたは統計のメンテナンスによる負荷をいつ受けるかはわかりません。また、特定のインスタンスで実行されている他のプロセスに基づいて、実行されるたびに変化する可能性もあります。考慮すべきことは、メンテナンスウィンドウがその変動を処理するのに十分な大きさであるかどうかです。
- 1つのサーバーから実行する場合、
Invoke-Sqlcmdを使用して実行するか、Invoke-Command（PowerShellリモート）を使用します。
これは、PowerShellでコマンドを実行するときに、PowerShellで任意の量のデータを処理するか、SQL Serverですべて処理するかを考慮しています。データを使用して何らかの配管を行う場合は、データの処理方法を検討してください。特定の事柄（実行可能ファイルへのパイプ）では、パイプを下って次のコマンドに移動する前に、すべてのデータをメモリにキャッシュする必要があります。