コードジンのヘッダーが入ります
去る2008年8月に出荷された最新バージョン「SQL Server 2008」で、従来の特徴であった管理性の良さに加え、多様な側面での機能強化が図られ、大きな進歩を遂げている「SQL Server」。「しかし、元来がPC向けのデータベースであったという出自に起因してか、その機能や内部動作をめぐって、いまだ誤解されている部分があるというのも事実。特にOracle Databaseとの設計思想、アーキテクチャの違いが、そうした誤解につながっていることも多いと考えます」とマイクロソフトの北川剛氏は切り出す。
まず設計思想に関しての相違については、2つのポイントがあげられる。1つは、チューニングについての考え方。SQL Serverでは、そもそもチューニングを行わなくても妥当な速度で稼働し続けるべきであるという考え方に立って設計されている。具体的には、インストールした段階で相応の性能を達成できるように考慮されているわけだ。またSQL Serverでは、自動チューニング機能を先進的に搭載してきているが、それもこのあたりに起因している。「この点については、システムの性能というものがデータベース管理者のスキルに依存すべきではないという考えに基づくものです」と北川氏は強調する。
そしてもう1つがトランザクションにいての思想。SQL Serverでは、データベースのCPU処理時間の大部分を占める参照処理を可能な限り高速に行うということが念頭に置かれている。この2つ目のポイントは、Oracle Databaseなど他のデータベースの間とのアーキテクチャの違いにも現れており、デフォルトでは1つのSQL文が1トランザクションに相当するショートトランザクションの考え方がとられている。つまり、処理開始からコミットに至るまでをトランザクションと捉えるのではなく、基本的にSQL Serverでは、例えばUPDATE命令が実行されるたびにコミットが行われることになる。
その後、北川氏は、以上のような設計思想、アーキテクチャの相違を踏まえ、SQL Serverをめぐっていまだ根強く残る誤解に解説を加えた。
中でも典型的なのが「SQL Serverの行ロックは不完全なのか」という問題。これに関して、実際にはSQL Serverでは行ロックが最小のロック単位であり、特定の条件に合致しない限り、この最小ロック単位が適用される。そして、単一のSQLステートメントにおいて、テーブルもしくはインデックスに対して5000個以上のロックを獲得した、あるいはデータベースインスタンスにおけるロックの総数がメモリもしくは構成のしきい値を超えたといった条件によって、行以上のレベルでのロック、すなわちロックエスカレーションが行われる。
「問題なのは、このロックエスカレーションがどちらかというと悪いイメージで捉えられていること。あくまでもそれは、メモリ使用を効率化するための処理なのです」と北川氏は強調する。しかも、このロックエスカレーションについては、サーバーの搭載するメモリ容量が限られていた過去のシステムでは頻繁に実行されることもあったが、現在の潤沢なメモリ環境で実行されることはレアケースだという。また、必要がなければ、パラメタの変更によりロックエスカレーションを無効化することも可能である。
「すでにSQL Serverは、国内の銀行でも採用されており、その基幹業務を支えているという事例もあります」と北川氏。SQL Serverが可用性や性能の点でも安心して利用できるデータベース製品であることをあらためて強調した。