OracleとDB2、アーキテクチャはこれだけ違う：RDBMSアーキテクチャの深層（2）（2/2 ページ）

トランザクションとデータの一貫性

　トランザクションとは、1つ以上のSQL文を含む作業単位です。また、その実行結果について成功／失敗のどちらかしかない（アトミック）という基本的な考え方を持っており、これは2つのRDBMSで同じです。ただし、データの一貫性を保証するための仕組みには大きな相違があります。

　データの一貫性を保証するための仕組みとして、Oracleでは、ロールバック・セグメントによるマルチバージョン制御を使用し、それに対してDB2ではロッキング・メカニズムを使用しています（図3）。

図3　トランザクションとデータの一貫性の仕組み

　Oracleの場合、あるアプリケーションが更新トランザクションを開始すると、データの旧バージョンはロールバック・セグメントに保持されます。ほかのアプリケーションがそのデータに対する読み取り要求をすると、ロールバック・セグメントに保持された旧バージョンのデータを取り出します。更新トランザクションがコミットされると、ロールバック・セグメントのバージョンは消去され、ほかのすべてのアプリケーションはテーブル上の新バージョンのデータを見ることになります。

　一方、DB2にはロールバック・セグメントに当たるものはなく、データの読み取り一貫性の保証にはロッキング・メカニズムを使用しています。あるアプリケーションが更新トランザクションを開始すると、テーブル内の該当するデータには非共有モードのロックが保持されます。ほかのアプリケーションがそのデータに対する読み取り要求をすると、未コミット読み取り分離レベル（俗にいうダーティーリードを許可するレベル）以外の読み取りトランザクションでは、データを取り出すことは許可されず待たされることになります。更新トランザクションがコミットされると、非共有モードのロックが解除され、ほかのすべてのアプリケーションはテーブル上の新バージョンのデータを見ることになります。

　これらの実装方法の相違により、同一の表に同時にアクセスするトランザクションを持つDB2アプリケーションの場合、ロック待機待ち時間が長くなることでパフォーマンスが低下することが考えられます。DB2でアプリケーションを開発する時には、ロック待機待ちを減らすために、読み取りトランザクションを定期的にコミットする、オプティミスティック・ロック方式を使用する、などのアプリケーション並行性の改善を考慮する必要があります。

　並行性を改善するためのアプリケーション開発テクニックについては、第4回「分離レベルとロッキング・メカニズム」にて詳しく紹介します。

オプティマイザ

　Oracleのオプティマイザは当初はルール・ベースのみしかありませんでした。現在はコスト・ベースとルール・ベースの2種類が提供されています。DB2のオプティマイザでは、常にコスト・ベースでアクセス・プランが選択されます（図4）。コスト・ベース・オプティマイザは、SQL文がアクセスするデータベース・オブジェクト（表または索引）について、使用可能なアクセス・パスを検討し、統計に基づいた情報要素を考慮することによって最も効率のよい（速い）実行計画を判断します。

図4　オプティマイザのモード

1. 統計情報の更新

　オプティマイザが最も効率のよい実行計画を判断するために必要なデータベース・オブジェクトの情報が統計情報です。統計情報はシステム管理情報として、Oracleではシステム表領域、DB2ではカタログ表スペース内に情報として保持されています。統計情報は、そのままでは自動的に更新されないため、ユーザーが専用のユーティリティ・コマンドで最新の情報に更新してやる必要があります。Oracleで統計情報を更新するには、ANALYZEコマンドを使用します。DB2では、これに相当する機能として、RUNSTATSコマンドを使用します。

　2つのRDBMSともに、コスト・ベースのオプティマイザでは、詳細な統計情報に基づいて最良のアクセス・プランを決定するため、ANALYZE／RUNSTATSコマンドを頻繁に実行して、常に統計情報を最新に保つことが不可欠です。

2. ヒント

　Oracleではヒントを利用して、オプティマイザにユーザーが指定したい特定のアクセス・プランを選択させることができます。DB2では、最初からコスト・ベースによる最適化処理のアプローチが取られてきたため、ヒントのサポートはありません。

　両RDBMSともに、基本的にはオプティマイザによる最適化に任せて十分にパフォーマンスが得られるケースがほとんどです。しかし、DB2でもユーザーがアクセス・パスを制御したい場合がないわけではありません。例えば、以下のような状況があります。

• 表のサイズがあまりにも頻繁に増減するため、現行のサイズを継続的に反映するために統計情報を更新してもあまり意味がない場合
• 表のサイズが小さく、かつ複数のアプリケーションから参照・更新が発生する場合

　このような状況の場合、オプティマイザは最も効率のよい実行計画として、行を検索する際に表走査を実施する可能性が高くなります。前に述べたとおり、DB2ではデータの一貫性を保証する仕組みとして、ロッキング・メカニズムを使用しているため、アプリケーションの並列性に深刻な影響を与えることが考えられます。

　DB2では、Oracleのヒントのように、ユーザーが使用したい索引を指定するようなことはできませんが、実は、以下のような2通りの方法によって間接的にオプティマイザの動作を制御することができます。

• 「ALTER TABLE VOLATILE」を実行する。volatile（揮発性）表に対して照会が発行されると、オプティマイザは強制的に索引走査を使用する実行計画を作成する
• SYSSTATスキーマ内で、表の統計情報が格納されている列値を、ユーザーが直接UPDATE文を実行して変更する。この値を想定される最大の表サイズに変更することにより、オプティマイザの最適化選択ロジックに間接的に影響を与えて、ユーザーが必要な実行計画を作成させるように調整する

今回のまとめ

　OracleとDB2のアーキテクチャの相違は、今回トピックとして取り上げた項目のほかにも数多くありますが、今回は、2つのRDBMSで特に根本的な違いがある機能について取り上げました。

　次回は、Oracle とSQL Serverのアーキテクチャの比較について同様に解説します。（次回に続く）