OracleとDB2、ロッキング・メカニズムはこれだけ違う：RDBMSアーキテクチャの深層（4）（1/2 ページ）

はじめに

　本連載の第2回「OracleとDB2、アーキテクチャはこれだけ違う」において、OracleとDB2のアーキテクチャの違いについて解説しました。同じRDBMSでも、アーキテクチャは随分と異なることが理解できたと思います。当然ながら、アーキテクチャが異なれば、RDBMSを利用するアプリケーションの振る舞いも異なります。今回は、その中でも、Oracle経験者がDB2を扱った場合に、最も戸惑うと思われる「分離レベルとロッキング・メカニズム」を取り上げます。

　なお、以降の説明では、特に断りのない限り、「Oracle」はOracle9i Enterprise Edition、および「DB2」はDB2 Universal Database V8.1 Enterprise Server Editionの各製品に関する説明とします。

今回扱うRDBMSとその対象内容

　今回は、すでにOracleでのアプリケーション開発経験があり、今後、DB2の導入を検討しているアプリケーション開発者向けに、「分離レベルとロッキング・メカニズム」の観点から、アプリケーション並行性の改善に役立つ内容を解説します（図1）。

図1　今回扱うRDBMSとその対象内容

分離レベル

　DB2は、ANSI/ISO標準のトランザクション分離レベルをすべてサポートしています。それに対し、Oracleは、Read Committed、Serializableの2つをサポートしています（表1）。OracleもDB2もデフォルトのトランザクション分離レベルはRead Committedです。Read Committedとは、コミットされたデータのみ参照が許されることでデータの一貫性を保証するものです。まず、OracleとDB2のデフォルト分離レベルであるRead Committedについて、両者の振る舞いの違いを見ていきます。

　OracleとDB2では、このトランザクション制御の実装の仕方が異なるため、同じRead Committedであっても、トランザクションの振る舞いが異なります。

　最も大きな違いは、更新中のデータに対して検索を行った場合です。DB2では、検索時に共有ロックをかけます。しかし、読み取るデータが更新中の場合は、すでにそのデータに排他ロックがかかっているため、共有ロックをかけることができません。つまり、DB2では更新中のデータに読み手はアクセスできず、検索処理が待たされます。一方、Oracleでは、マルチ・バージョン一貫性制御により、UNDO表領域に保持された更新前の情報を読み込むため、読み取るデータが更新中であっても検索処理が待たされることはありません。この両者の癖を理解していないと、アプリケーション開発者は、パフォーマンス劣化やデッド・ロックなどのトラブルに見舞われることになります（図2）。

図2　更新中のデータに対して検索を行った場合のOracleとDB2の比較

　DB2において、更新中のデータが確定されるまで検索処理が待たされる振る舞いは、複数アプリケーション間の同時実行性を損ないます。これに対しては、「未コミット読み取り」という、ダーティー・リードを許す方法がありますが、実用的なアプリケーションで適用できるケースはごくまれであるため、ここでは取り上げません。

　ここでは、いかにしてダーティー・リードを使わずにDB2で優れた同時実行性を実現すればよいかを考えます。ポイントはロック取得時間（ほかのトランザクションからの更新を許さない時間）を短くするような排他制御のアプリケーション設計を行うことです。ロック取得時間が短ければ、検索処理と重複する機会を減らすことができます。これには、オプティミスティック・ロック（楽観的ロック）と呼ばれる実装方法をよく用います。オプティミスティック・ロックのフローは以下のようになります。

クライアントサーバシステムのプログラミング例

　ただし、オプティミスティック・ロックは、頻繁に複数ユーザーが同時に同一データを変更するようなシステムだと、更新に失敗し、ユーザーに再入力を促す確率が高くなるため、利便性が低くなる場合があります。そういった場合においては、1回目の読み込み時（上記（1）のタイミング）でロックをかける設計も検討するべきでしょう。また加えて、データにロックをかけて画面表示するような場合は、画面を表示したまま放置することがないよう、一定時間内に画面上から入力がなければ、取り込んだデータを自動的に破棄するようなアプリケーションの設計にする必要があります。

　つまり、DB2の場合、オプティミスティック・ロックによる実装が並行性の改善には有効ですが、オプティミスティック・ロックによる画一的な設計でよいというわけではありません。アプリケーションの要件、ユーザーの利便性を満たす排他制御方法を選択する必要があります。（次ページに続く）