排他制御メカニズムから“待ち”原因を究明する：Dr. K's SQL Serverチューニング研修（4）（1/3 ページ）

» 2006年05月30日 00時00分公開

[熊澤幸生, 工藤淳（インタビュアー），CSK Winテクノロジ/オフィスローグ]

SQL Serverは一般的にチューニング不要のデータベースと認識されている。しかし基幹系業務システムへの導入が進むにつれて、パフォーマンス・チューニングのニーズは急速に高まってきた。そこで本記事では、日本におけるSQL Serverコンサルタントの第一人者、熊澤幸生氏にSQL Serverチューニングのノウハウを語っていただくことにした。インタビュアーはSQL Serverへの造詣が深いITジャーナリスト、工藤淳氏が担当する。（編集部）

　「何か動き方がヘンだな」「妙に遅くなったな」と思っても、すぐにパフォーマンス・チューニングに取りかかれる人は多くありません。私のようにパフォーマンス・チューニングを専門にしているエンジニアでさえ、毎日新しい疑問との追いかけっこですから、一般のデータベース管理者は「どこから手を付けていいやら分からない」とお手上げになることが少なくないでしょう。しかし、ツボを押さえて探っていけば、必ず原因は発見され、対策は可能になります。

　第2～3回では主にメモリに関するチューニングのポイントを解説してきました。今回と次回では、チューニングのツボの中でも代表的なポイントの1つ、「wait事象」を取り上げていきましょう。

wait事象とは、何らかの処理に伴う待ち時間の総称

QL ServerとWindows Serverの間で発生するリソース競合

　wait事象とは読んで字のごとし、「待ちが発生する状態」です。ひとことで「待ち」といっても原因はさまざまです。データ書き込み／読み出しの待ちや、処理が重複した場合の待ちといった、正常なタスクに伴うものから、データベース・システムの設計が悪くて処理時間がやたらかかるといった欠陥に起因するものまであります。

　エンドユーザーにとっては「待ち」ではなく「遅い！」「使えない！」といった情緒的な評価として感じられることの方が多いでしょう。しかしエンジニアにとっては、それでは済まされません。遅さの背後にある「待ち」の事象を掘り下げて、システムのパフォーマンスを低下させている真の原因を探り当てなくてはならないのです。

　SQL Serverで見られるwait事象には、大きく分けて2つあります。1つは「SQL ServerとWindows Serverの間で発生する待ち」です。第1回「SQL Serverというブラックボックスを開いてみる」でお話ししたように、SQL Serverは内部にUMS（User Mode Scheduler）と呼ばれるスケジューラを持っており、OSと同様にマルチスレッドのコンテクストの割り当てを行っています。

　一般にOSレベルでのマルチスレッドのコンテクスト切り替えはプリエンプティブ、つまり自分よりも優先順位の高いスレッドがあると、優先順位の低いユーザーはスレッドの実行権を取り上げられてしまいます。ところがSQL Serverでは、スレッドが自ら実行権の放棄をしない限り使えるのです（OSから見てノンプリエンプティブ）。スレッド管理をSQL Server自身で行うことで自動チューニングが可能になる一方、コンテクストが切り替わらないことでCPUの利用権をめぐる「待ち」が生じることもあります。この話は別の機会に掘り下げることにしましょう。

マルチユーザーの排他制御に伴う“待ち”

　今回のテーマは、もう1つのwait事象、つまり「マルチユーザーの排他制御に伴う待ち」です。排他制御とは、ユーザーAがトランザクション処理でデータを更新中に、ほかのユーザーがそのデータを参照できないようロックすることを指します。当然、ほかのユーザーはユーザーAのトランザクションが終了するまで「待ち」状態となります。通常はSQL Serverのロックマネージャによって、適切なロックの種類や粒度の制御が行われます。

　ところがアプリケーションの設計に問題があり、排他制御によるロックが頻発するとパフォーマンスは大幅に低下することになります。これはデータベース側のチューニングでは直しきれない範囲ですので、ある意味致命的なのですが、パフォーマンス低下の原因を調べていき、最終的にアプリケーション側の排他制御の設計に問題があることを究明できなければ、問題解決にはつながりません。そこで今回は、SQL Serverのロック・アーキテクチャを解説していきます。