1 月に開催された Get The Fact セミナーで optimize for ad hoc workloads オプション についてのお話があったようですので今回はこの内容についてまとめてみたいと思います。
Archive for the ‘Get The Fact’ tag
第 1 回 Get The Fact セミナーの振り返り その 7
今回は [データベースの整合性確認の負荷] について振り返っていきたいと思います。
前回の振り返りでまとめていたデータベースの整合性確認 (DBCC CHECKDB) ですが、データベースの状態を確認するためには大事になる処理ですが、整合性を確認するためには負荷がかかります。
第 1 回 Get The Fact セミナーの振り返り その 6
今回は [データベースの整合性確認] について振り返っていきたいと思います。
[メンテナンス プラン ウィザード] では、 [データベースの整合性確認] のメンテナンス タスクを作成することが可能です。
このタスクを実行するとデータベースの整合性をチェックすることができます。
セミナーの中では、バックアップの取得前等に実行をすることでデータベースに問題が無いかを確認しバックアップを取得することが可能というようなお話がありました。
今回は、この整合性確認についてまとめていきたいと思います。
■データベースの整合性確認で実行される内容
まずはデータベースの整合性確認のタスクで実行される内容について確認していきたいと思います。
作成したデータベースの整合性確認のタスクで実行される T-SQL を確認してみます。
データベースの整合性確認のタスクでは、実行対象として指定したデータベースに対して [DBCC CHECKDB] が実行されます。
# [インデックスを含める] を外すと [NOINDEX] オプションを指定して実行されます。
以下は、BOL の DBCC CHECKDB の記載内容の引用になります。
次の操作を実行し、指定したデータベース内のすべてのオブジェクトの論理的および物理的な整合性をチェックします。
- データベースに対して DBCC CHECKALLOC を実行。
- データベース内にあるすべてのテーブルとビューに対して DBCC CHECKTABLE を実行。
- データベースに対して DBCC CHECKCATALOG を実行。
- データベース内にあるすべてのインデックス付きビューの内容を検証。
- FILESTREAM を使用して varbinary(max) データをファイル システムに格納する場合のテーブルのメタデータとファイル システムのディレクトリおよびファイルの間のリンクレベルの一貫性を検証。
- データベースの Service Broker データを検証。
DBCC CHECKDB では、上記の処理を実行してデータベースの整合性が取れているかを確認する処理になります。
■整合性確認を実施しないとどうなるか
データベースの整合性確認を行う事でどのようなことが分かるか、簡単に試してみたいと思います。
今回は、バイナリエディタでデータファイル (mdf) を開き、一部のデータを書き換え、データの内容とページのチェックサムが一致しないようにしてみました。
データを書き換える前のテーブルの全件を取得した情報がこちらになります。
SQL Server 2008 以降であれば、データがどのページに格納されているかは [sys.fn_PhysLocFormatter(%%physloc%%)] を使用することで確認することができます。
# この関数は、Undocument の関数です。
上のデータは、以下のクエリを実行して取得しています。
SELECT |
SQL Server のページにはチェックサムがあり、データの内容を元に計算したチェックサムとデータの内容が一致しているかを確認することで、ページが破損しているかを検出する機能がありますのでページに一貫性が無いとエラーとして検出することができます。
# データベースオプションで [CHECKSUM] / [TORN_PAGE_DETECTION] / [NONE] のいずれかを設定することが可能です。([TORN_PAGE_DETECTION] は下位互換となっていますが。)
今回はバイナリエディタでデータベースのファイルを開いて、 (1:114:0) のページを壊してみました。
ページを壊した後に、データを全件取得すると以下のデータまでは取得できるのですが、 (1:114:0) のデータを読み込もうとした際にエラーが発生します。
メッセージ 824、レベル 24、状態 2、行 1 |
(1:114) という情報が表示されていますので、ファイル ID 1 (mdf ファイル) の 114 ページに一貫性のエラー (チェックサムとデータが不整合) が発生していることが確認できます。
今回、私が壊したページ番号と一致しますね。
破損ページの操作をした場合、イベント ビューアーのアプリケーションにも同様の情報が出力されますので、監視ソフト等でログ監視をしているのであれば、エラーを検知することもできます。
今回はデータを全件読み込みしたので破損ページも読み込まれエラーが発生しましたが、破損したページにアクセスをしなければ正常にデータを読み込むことができます。
# Col = 4 のデータを読もうとするとエラーになってしまうので飛ばしています。(先行読み込みの可能性が)
破損したページを操作しないとエラーにはなりませんので、データベースに異常があるかは分かりません。
DBCC CHECKDB を定期的に実行することで障害により発生した潜在的に潜んでいるデータベースの異常をチェックすることが可能です。
[DBCC CHECKDB(N’TEST’)] を実行して、今回整合性のエラーが発生している [TEST] データベースでデータベースのチェックをしてみます。
‘TEST’ の DBCC 結果。 |
DBCC CHECKDB を実行することで、データベースの状態をチェックしてくれますので、破損している領域を操作しなくても異常があるかどうかの確認をしてくれます。
イベントビューアーと SQL Server のログにも結果の概要が出力されますので、後で結果を再確認することも可能です。
SQL Server のダンプのテキストも出力されています。
[msdb..suspect_pages] を SELECT することで直近の情報を取得することもできます。
DBCC CHECKDB をバックアップ実行前に実施する理由ですが、[障害が発生しているデータベースのバックアップは障害が発生した状態] となるからです。
障害が発生していない状態のデータベースのバックアップがないと破損している領域を修復することができません。
# SQL Server 2008 以降のデータベースミラーリングであれば、破損ページを読み込んだ際にミラー側から修復することも可能ですが。
そのため、バックアップを取得する前にデータベース自体に異常が無いかを確認して、その後にバックアップを取ることが推奨されます。
セミナーの中で質問 / 回答があったのですが、DBCC CHECKDB によるデータベースの整合性確認はデータベースのサイズが大きいとかなり負荷がかかります。
そのため、バックアップのたびに毎回実行するのが難しいかもしれませんね。
次の投稿では [データベースの整合性確認の負荷] についてまとめてみたいと思います。
第 1 回 Get The Fact セミナーの振り返り その 5
今回は [バックアップポリシー] について振り返っていきたいと思います。
# 参加から 2 週間経過したのでテンポよくまとめていかないとだいぶ記憶が薄れてきました…。
セミナーでは以下のような図を元にバックアップポリシーについてのお話しがありました。
■バックアップの基本的な設定
上の図は復旧モデルを [完全] または [一括ログ] にした場合のバックアップの基本的な設定になります。
# [単純] 復旧モデルの場合は、ログのバックアップが取れませんので、データベースのバックアップのみになります。
セミナーでは日に一度のデータベースバックアップと、一時間おきのログのバックアップで設定というような例でお話をされていたと思います。
SQL Server のバックアップは大きく分けて 3 種類あります。
# ファイル / ファイルグループでのバックアップも取得ができるのですが、今回は割愛しておきます。
- 完全
- 差分
- トランザクションログ
完全 / トランザクションログは上の図で [データベース] [ログ] と書かれているバックアップになります。
[完全バックアップ] は、その時点 (バックアップを実行したタイミング) でのデータまで復元することが可能なバックアップとなります。
完全バックアップはそのバックアップ単体で戻すことが可能ですのでバックアップにはログも含まれています。
[差分バックアップ] は、前回の完全バックアップからの差分データのみを含んだバックアップになります。
完全バックアップを元にした差分になりますので、単体で戻すことはできず必ず前回の完全バックアップが必要となります。
また、差分バックアップは前回の完全バックアップからの差分データですので、完全バックアップを取得してからの期間が長くなり、全データが更新された状態になってしまうと、完全バックアップ相当のバックアップファイルのサイズとなります。
[トランザクションログバックアップ] は、ログレコードのバックアップになります。
復旧モデルのときにもお話しがあったのですが、復旧モデルを [完全] [一括ログ] にしている場合は必須になるバックアップとなります。
これらの復旧モデルに関しては、ログレコードは自動的に切り捨てはされず、バックアップを取得したタイミングで切り捨てが行われ、切り捨てられた個所が再利用可能となります。
そのため、ログのバックアップを取得しないとログがずっと蓄積された状態となり、ログ領域のディスクが枯渇することになります。
ログのバックアップは障害発生時に重要となるバックアップのため、できるだけ短い間隔で取得することが重要であるとセミナーではお話がありました。
# 1 時間おきのログのバックアップというお話はこのタイミングであった気がします。
データベースの完全バックアップを取得していない状態ではログバックアップは取得することはできません。
バックアップについてですが、以下の資料がわかりやすいと思います。
SQL Server 2000 の資料ですが、それ以降のバージョンでも考え方は同じですので。
第 4 章 バックアップと復元
■定期的なバックアップの設定
定期的なバックアップの設定方法として、[メンテナンスプランウィザード] によるバックアップの設定が紹介されていました。
ワンタイムのバックアップであれば、データベースを右クリックして、[タスク] → [バックアップ] からバックアップを取得することが可能です。
このバックアップに関しては、ワンタイムになりますので定期的なバックアップの取得の設定はできません。
定期的なバックアップをウィザード形式で設定する場合は、セミナーで紹介のあった [メンテナンスプランウィザード] を使用する事で設定ができます。
メンテナンスプランウィザードは [管理] → [メンテナンス プラン] → [メンテナンス プラン ウィザード] から起動することができます。
メンテナンス プラン ウィザードを使用することで、データベースのメンテナンスをする仕組みを数ステップで設定が可能となります。
今回のセミナーでお話しのあったメンテナンスプランに似たものを実際に作ってみたいと思います。
- [次へ] をクリックします。
- [タスクごとに個別のスケジュールを使用する] を選択して、[次へ] をクリックします。
- [データべすのバックアップ (完全)] [データベースのバックアップ (トランザクション ログ)] を選択して、[次へ] をクリックします。
- [次へ] をクリックします。
- [完全] バックアップの取得対象とバックアップのスケジュールを設定し、[次へ] をクリックします。
今回は [すべてのデータベース] を毎日 [22:00] に取得するように設定をしています。
- トランザクションログのバックアップを取得するデータベースとスケジュールを選択し、[次へ] をクリックします。
今回は、[すべてのユーザー データベース] を [毎日1 時間置き] にバックアップを取得するように設定しています。
すべてのユーザー データベースですが復旧モデルが単純以外のデータベースが対象となります。 - ログの出力場所を設定し、[次へ ]をクリックします。
- [完了] をクリックします。
- [閉じる] をクリックします。
以上でメンテナンスプランの作成は完了です。
今回は、[完全 バックアップ] の取得と、[トランザクションログ] のバックアップの取得を設定していますので二つのジョブが SQL Server エージェントに作成されています。
作成した 2 つのジョブを手動で実行して、バックアップの取得状況を確認してみたいと思います。
ジョブを手動実行する場合は、対象のジョブを右クリックして、[ステップでジョブを開始] をクリックします。
今回は、H ドライブにアックアップを取得しているのですが、データベースのバックアップ (.bak) とトランザクションログのバックアップ (.trn) が取得されていることが確認できます。
今回のメンテナンスプランですが、バックアップを取得するたびにタイムスタンプが設定されたバックアップファイルが蓄積されていきます。
また、ログに関してもバックアップを実行するたびに蓄積されていきます。
このバックアップとログの履歴 (世代) 管理ですが、[メンテナンス クリーンアップ タスク] を使用することで管理することができます。
先ほど作成したメンテナンスプランにこの履歴クリーンアップタスクを組み込んでみたいと思います。
作成したメンテナンスプランは、[管理] → [メンテナンス プラン] の下に作成がされますので、作成したプランをダブルクリックします。
そうするとメンテナンスプランのデザインウィンドウが開きます。
先ほど作成したプランが、[Subplan_1] [Subplan_2] として設定されています。
今回は [サブプランの追加] をクリックして、[Subplan_3] として[メンテナンス クリーンアップ タスク] を設定します。
タスクをダブルクリックすると設定画面になります。
このタスクを使用することで、バックアップファイルとメンテナンスプランのレポートを削除することが可能です。
拡張子単位で指定はできるのですが、ワイルドカードは使えないので、[bak] [tran] 用のバックアップファイル削除タスクを用意します。
テキストレポートのクリーンアップタスクとしては以下の内容を設定しました。
今回はスケジュールも設定し、このような形でサブプランを設定してみました。
今回は 4 週経過したファイルが対象になっていますので、以下の PowerShell を実行して、ファイルの更新日付を変更してみました。
# クリーンアップタスクでファイル操作をする際の日付はファイルの更新日付が検索対象となります。
Get-Item "C:Program FilesMicrosoft SQL ServerMSSQL10_50.SQL2008R2MSSQLLogMaintenancePlan_Subplan_1_20101220221815.txt" | Set-ItemProperty -name LastWriteTime -Value (Get-Date).AddDays(-28) |
これで、メンテナンスレポートの日付が 28 日前 (4 週間前) になりました。
それでは、作成したクリーンアップタスクんのジョブを実行してみます。
ジョブを実行したことで、先ほどファイルの更新日付を変更したメンテナンスレポートが削除されていることが確認できます。
バックアップ ファイルに関しても更新日付が条件に一致するのであれば削除されます。
メンテナンス プラン ウィザードを使用することでバックアップのメンテナンスプランを GUI のウィザードベースで柔軟に設定することが可能となります。
今回の投稿では設定をしなかったのですが、メンテナンスプランには [データベースの整合性確認] というメンテナンス タスクがあります。
セミナーの中ではこのタスクについてもお話がありました。
次の投稿では、データベースの整合性確認についてまとめてみたいと思います。
第 1 回 Get The Fact セミナーの振り返り その 4
今回は [パフォーマンス条件警告] について振り返ってみたいと思います。
セミナーの中で SQL Server のパフォーマンス条件警告をしようして、ログの使用状況が一定の閾地に達した場合にログのバックアップを取得して、ログを切り捨てるという方法が紹介されました。
それでは、パフォーマンス条件警告についてまとめていきたいと思います。
■パフォーマンス条件警告設定の流れ
パフォーマンス条件警告ですが、[SQL Server Agent] を使用して動作します。
設定は
- 警告の条件を設定
- 警告が発生した際に実行する SQL Server Agent のジョブを設定
- 警告が発生したことの通知方法を設定
という流れになります。
# 実際の設定は順不同でジョブと通知方法は必須ではないですが。
■パフォーマンス条件警告を設定
それでは、実際にパフォーマンス条件警告を設定していきたいと思います。
今回はセミナーでお話しのあったものと同じ設定を行っていきます。
- [警告] を右クリックして、[新しい警告] をクリックします。
- 警告の条件を設定します。
今回は以下の内容で設定を行っています。
TEST データベースのログが 200,000KB 使用された場合に警告を発生するように設定しています。 - [応答] の [ジョブの実行] を有効にして、[新しいジョブ] をクリックします。
今回は警告を作成する作業の流れで、新しいジョブを作成していますが、事前に作成したジョブを使う事も可能です。 - ジョブの [名前] を入力します。
- [ステップ] の [新規作成] をクリックします。
- ログのバックアップを取得するためのステップを作成し、[OK] をクリックします。
# 今回のパフォーマンス条件警告は後でスクリプト化したものを記載しますのでコマンドの内容はここでは割愛します。
- [OK] をクリックします。
- [OK] をクリックします。
今回は通知設定はしていませんが、通知は以下の方法で行う事ができます。
それでは実際にデータを追加して挙動がどのように変わるかを試してみたいと思います。
今回も自動チェックポイントは無効にしています。
パフォーマンス条件警告を無効にしている場合の状態はこのようになります。
# 作成した警告は、個別に無効化することができます。
ログの書き込み待ちとバックアップ処理時間は 2 軸にしていますが、これらは発生していないことが確認できます。
それでは、パフォーマンス条件警告を有効にして同じ処理を実行してみます。
こちらも、バックアップ処理時間は 2 軸に表示しています。
ログの書き込み待ちに関しては、カウンタがあがっていることを示すために、元の値に 10,000 をかけています。
パフォーマンス条件警告の設定内容が有効になっていますので、ログファイルの使用状況が一定に達したタイミングで自動的にログのバックアップが行われています。(バックアップ処理時間はデータ/ログのバックアップを取得すると発生します。)
今回作成したパフォーマンス条件警告のサンプルスクリプトがこちらになります。
USE [msdb] /****** Object: Job [TEST Database Log Backup] Script Date: 12/16/2010 21:09:09 ******/ END DECLARE @jobId BINARY(16) GO
EXEC msdb.dbo.sp_add_alert @name=N’TEST Database Log Auto Backup’, |
このスクリプトですが、[INIT] を指定してログのバックアップを取得しています。
本来の運用では、この指定は NG です。
# テスト用でログのバックアップを蓄積したくなかったので INIT でバックアップを上書きしています。
ログのバックアップはログチェーンという考えがあり、連続したログのバックアップが担保されている必要があります。
ログチェーンが途切れてしまうとログを使用したリストアができませんので、本番運用で使う場合は [NOINIT] かログファイルの名称を動的に生成するようにしてログを上書きしないようにする必要があります。
■Twitter での質問について
セミナー中に Twitter で以下のような質問がありました。
「オンライン中のトランザクションログバックアップのパフォーマンス劣化はどれくらいなのでしょうか?」
ログのバックアップをするとログの書き込み待ちが発生しているのが上のグラフで確認することができます。
# 今回の環境では 200 MB 程度のログのバックアップを書き込む際には、書き込み待ちは最大で 7ms 程度になっていました。
グラフではなくWRITELOG の待ち事象でも比較をし手みたいと思います。
パフォーマンス条件警告を設定していない場合はこのような待ち事象になります。
waiting_tasks_count = 619,844 ? 519,766 = 100,078
wait_time_ms = 459,265 ? 396,561 = 62,704
パフォーマンス条件警告を設定した場合はこのようになります。
waiting_tasks_count = 720,408 ? 619,881 = 100,527
wait_time_ms = 532,001 ? 459,405 = 72,596
ログのバックアップをしている最中はログの使用状況がなだらかになりますのでログの書き込みにも多少の影響が発生します。
また、BOL に以下のように書かれているようにバックアップの実行を行うと CHECKPOINT が発生します。
チェックポイントは次の状況で作成されます。
- CHECKPOINT ステートメントが明示的に実行された場合。接続を確立するために、現在のデータベースでチェックポイントが作成されます。
- データベースで最小ログ記録操作が実行された場合。たとえば、一括ログ復旧モデルを使用しているデータベースで一括コピー操作が実行された場合です。
- ALTER DATABASE を使用して、データベース ファイルが追加または削除された場合。
- SHUTDOWN ステートメント、または SQL Server (MSSQLSERVER) サービスを停止することによって、SQL Server のインスタンスが停止された場合。どちらの場合でも、SQL Server のインスタンスの各データベースでチェックポイントが作成されます。
- データベースの復旧にかかる時間を短縮するために、SQL Server のインスタンスにより、各データベースで定期的に自動チェックポイントが作成されている場合。
- データベースのバックアップが作成された場合。
- データベースのシャットダウンが必要な動作が実行された場合。たとえば、AUTO_CLOSE が ON に設定されていて、データベースへの最後のユーザー接続が終了した場合、またはデータベースの再起動が必要なデータベース オプションが変更された場合です。
データベースのバックアップにはログのバックアップも含まれています。
先ほどのグラフにチェックポイントの発生状況も追加してみます。
バックアップのタイミングに合わせてチェックポイントが発生していることが確認できます。
チェックポイントが発生するとメモリ上のダーティーページをデータファイルに書きだしますので、データファイルに対しても負荷がかかることになります。
この辺はディスクの性能にも依存するのでどれくらいというのは難しいところなのですが、ログの書き込み待ち + チェックポイントによるデータファイルへの書き出しを劣化分として見込んでおく必要があると思います。
# この辺はディスク性能とドライブ構成に依存するところがあるのですよね…。
■WMI イベント警告
これは警告のちょっとした応用なのですが、パフォーマンス条件警告ではなく、[WMI イベント警告] を使用することでイベントを受信してジョブを実行することが可能となります。
例えば、ロックエスカレーションが発生した場合にそのイベントを受信してテーブルにロックエスカレーションが発生した時に実行されたクエリを保存してくれるような警告が作れると運用で便利そうですよね。
WMI イベント警告を使用すると、イベントを受信して特定のジョブを実行するということができるようになります。
# イベントを取得してログに出すだけであれば SQL トレースでもできるのですけどね。
BOL には [サンプル : WMI Provider for Server Events の使用による SQL Server エージェント警告の作成] という形でデッドロックをトラップしてテーブルにデータを書きだすサンプルが紹介されています。
# サンプル : WMI Provider for Server Events の使用による SQL Server エージェント警告の作成
ただし、内容に一か所誤りがあり、
@command= N’INSERT INTO DeadlockEvents (AlertTime, DeadlockGraph) VALUES (getdate(), N”$(ESCAPE_SQUOTE(WMI(TextData))))’ |
を
@command= N’INSERT INTO DeadlockEvents (AlertTime, DeadlockGraph) VALUES (getdate(), N”$(ESCAPE_SQUOTE(WMI(TextData)))”)’ |
にしないと動かなかったはずですが。
# シングルクォート × 2 が足りていないのですよね…。
WMI イベント警告を使用するための事前準備として 2 つの作業があります。
- 対象のデータベースで [Service Broker] を有効にする。
WMI イベントを受信するために対象のデータベースで [Service Broker] を有効にします。
BOL に以下のように記載されています。
SQL Server エージェントが WMI イベントを受信するには、msdb および AdventureWorks2008R2 で Service Broker が有効化されている必要があります。 msdb に関してはデフォルトで Service Broker が有効になっているはずなのですが、ユーザーデータベースではデフォルトでは無効になっています。
Service Broker を有効にするためにはデータベースのプロパティを開いて、[Broker が有効] を [True] にする必要があります。
ただし、この変更をする際にはデータベースに対して [LCK_M_X] (排他ロック) を取得しにいきますので、対象のデータベースに接続中のユーザーがいると変更できません。
今回は、SQL Server のサービスを再起動して、サクッと全ロックを外してから実行してしまいました。
クエリで設定を変更する場合は以下のクエリを実行します。
# DB 名は適宜変更する必要があります。USE [master]
GO
ALTER DATABASE [TEST] SET ENABLE_BROKER WITH NO_WAIT
GO - SQL Server エージェントで [トークンの置き換え] を有効化
WMI イベント警告を使用した場合、SQL Server のジョブステップの中で WMI のイベントのプロパティを使用することが可能です。
WMI のプロパティを使用する場合は、SQL Server エージェントで [トークンの置き換え] を有効にする必要があります。
たとえば、ロックエスカレーションが発生した際クエリ (SQL) を取得する場合には、WMI(TextData) というように記述をするのですが、[トークンの置き換え] が有効になっていないとこの設定がそのまま文字データ (WMI(TextData) という単純な文字列) として認識されてしまいます。
WMI(TextData) → 実行されていたクエリ に変換するためには、トークンの置き換えを有効にする必要があります。
# ジョブ ステップでのトークンの使用ロックエスカレーション時のクエリは SQL Server 2008 からでないと取得できなかった気もします…。
トークンの置き換えはSQL Server エージェントのプロパティから [警告システム] を選択して、[警告に応答するすべてのジョブのトークンを置き換える] を有効にします。
クエリで有効にする場合は、以下のような内容になります。USE [msdb]
GO
EXEC msdb.dbo.sp_set_sqlagent_properties @email_save_in_sent_folder=1,
@alert_replace_runtime_tokens=1
以上で、事前準備は完了です。
基本的な流れはパフォーマンス条件警告と変わりません。
WMI イベント警告特有な内容としては、WMI の名前空間を指定するのとクエリを WQL ステートメントで記載する箇所になります。
名前空間に関しては通常の WMI の名前空間を指定すれば問題ありません。
SQL Server のサーバーイベントに関しては以下の指定をします。
\.rootMicrosoftSqlServerServerEvents<インスタンス名> |
私の環境ではこのような指定ですね。
[\.rootMicrosoftSqlServerServerEventsSQL2008R2]
WQL ステートメントを記載するためには、イベント名を記載しなくてはいけないのですが、イベント名は [wbemtest.exe] (Windows Management Instrumentation テスト) を使用すると簡単に確認することができます。
# Windows Server 2008 R2 だと標準で入っています。
[接続] をクリックして、SQL Server の名前空間に接続をします。
名前空間に接続をしたら、[クラスの列挙] をクリックします。
[再帰] 選択して [OK] をクリックするとクラスの一覧が取得できます。
クラスとして表示されたものが WMI イベント警告で受信できるイベントになります。
今回はロックエスカレーションを受信したいので、[LOCK_ESCALATION] というイベントを受信することになります。
LOCK_ESCALATION をダブルクリックするとプロパティを取得することができます。
このプロパティ名がトークンの置き換えで使用できる WMI のプロパティ名になります。
続いて応答で使用するジョブを作成します。
今回は発生時刻 / データベース名 / 実行していたクエリの情報をテーブルに格納したいと思います。
そのため、以下のテーブルを事前に作成しておきます。
# 今回は [TEST] というデータベース上に作成しています。
CREATE TABLE dbo.LockEscalationEvent |
コマンドにはトークンの置き換えを使用して、WMI のプロパティを ESCAPE_SQUOTE を使って、プロパティ内にシングルクォートが存在している場合は修飾するように指定をしたクエリを設定しています。
以上で、WMI イベント警告の設定は完了です。
それでは実際にロックエスカレーションを発生させて正常に動作するかを見ていきたいと思います。
UPDLOCK を設定して、トランザクション内で大量のデータを SELECT したためロックエスカレーションが発生しています。
そのあとに、JobStep が実行されていますね。
# JobStep は SQL Server Agent サービスの起動アカウントで SQL Server に接続して実行されています。
今回は LocalSystem アカウントで実行しています。
最後の JobStep を確認すると、INSERT 文が実行されていることが確認できます。
INSERT 文ですが、トークンの置き換えにより WMI のプロパティが文字列に置き換えられて実行されているのが確認できますね。
作成したテーブルを確認してみます。
イベントが発生した日と対象のデータベース、クエリがテーブルに格納されています。
WMI イベント警告を使用することで特定のイベント受信時にジョブを動かくすことができますのでうまく使うと運用が楽になるかもしれないですね。
今回作成した警告とジョブのサンプルスクリプトは以下になります。
USE [msdb] /****** Object: Job [JOB LockEscalation] Script Date: 12/16/2010 23:10:33 ******/ END DECLARE @jobId BINARY(16) GO
USE [msdb] /****** Object: Alert [WMI Lock Escalation] Script Date: 12/16/2010 23:10:16 ******/ |
パフォーマンス条件警告と WMI イベント警告を使用することでデータベースの特定の状態を受信してジョブを実行することが可能になります。
# WMI イベント警告は良い機会だったのでついでにまとめたものですが。
パフォーマンス条件警告でログのバックアップを取るのは今まで考えていなかったので、なるほどと思いました。
この後には [バックアップポリシーの検討] ということで、バックアップタクトの一例や障害発生時の復元の概要についてのお話がありました。
次の投稿では、バックアップポリシーについてまとめてみたいと思います。