ところが、最近の商用RDBMS選定の現場においては、このような状況に変化が起きていることはご承知かと思います。Oracle以外のRDBMSも多く選定されるようになってきている背景には、以下のような理由があると考えられます。
上記のような理由から、いままでOracleを主体にしてきた技術者でも、これからはOracle以外のRDBMSを、管理者もしくは開発者として担当する局面が増えてくることが考えられます。
このような商用RDBMS選定の基準の変化から、今後、エンタープライズ環境で選定される可能性の高い商用RDBMSとして、本連載では、以下の3つのRDBMS製品を取り上げます。
これらの製品は、アーキテクチャ、チューニングパラメータ、エラーメッセージ、およびサポートする構造化照会言語(SQL)が大きく異なります。各RDBMSとも、マニュアルに記載されている仕様上は同じ機能を持っていたとしても、その実現方法はそれぞれ独自の方式を採用しています。
一例を挙げると、データの一貫性を確保する機能として、ANSI/ISO SQL規格の分離レベルというものがあります。Oracleの分離レベルは、読み込み一貫性によって実現され、読み込み専用のトランザクションに対してロックを獲得しません。一方、SQLServerとDB2では、基本的な実装は異なりますが、ともにロック制御によって実現されており、読み込み専用のトランザクションに対してもロックを獲得します。
この実装の違いを把握しないまま、Oracleと同じ感覚でアプリケーションを開発すると、SQL ServerとDB2では意図しないロック待ちが発生することになり、思わぬパフォーマンスの劣化問題に悩まされることになります。
第2回以降で、これら具体的な違いについても記していきますが、この連載は、どの製品がより優れているかの比較を論じるものではありません。RDBMSというミドルウェアでは、製品の違いにかかわらず、さまざまな業務システムで使用するデータ(情報)を集中的に蓄積・管理するとともに、複数の利用者による同時アクセスを確保することが求められています。データベース技術者には、それぞれの製品の特徴や機能特性、付属する管理ツールなどの“癖”をつかんで不要なトラブルを防止することが求められます。
今回は、3つの商用RDBMS製品の機能的な比較を始める前に、これまでエンタープライズ環境でOracleが多く選定されてきた理由と、今後、技術者はOracle以外のRDBMSを扱う必要に迫られることになるという背景について整理してみました。
次回からは、OracleとOracle以外のRDBMS(OracleとSQL ServerもしくはOracleとDB2)の比較を、具体的な機能例などを挙げて解説していきます。(次回へ続く)
アクセンチュアから生まれた、企業改革のためのシステム開発を手掛けるエンジニア集団。安間裕が代表取締役社長を務める。鵜原和広はデータベース技術に精通したシニア・システム・アナリスト。
Copyright © ITmedia, Inc. All Rights Reserved.