Oracle DatabaseとIBM DB2 UDBの技術的比較: パフォーマンスを重視

(1)

Oracle Database と IBM DB2 UDB の

技術的比較: パフォーマンスの観点

オラクル・ホワイト・ペーパー

(2)

Oracle Database と IBM DB2 UDB の技術的比較:

パフォーマンスの観点

概要 ... 3

主なパフォーマンスの特徴的機能 ... 4

Oracle Database は Oracle Database。IBM DB2 とは ... 4

トランザクション処理 ... 5

並行性モデル... 5

マルチバージョン読込み一貫性 ... 6

ロック・エスカレーションしない行レベル・ロック... 7

索引付け機能... 9

索引構成表... 10

クラスタ化システム... 10

Oracle Database 10g Oracle Real Application Clusters ... 10

DB2 のシェアード・ナッシング・アーキテクチャ ... 11

アプリケーションの互換性 ... 11

OLTP アプリケーション用パフォーマンス... 12

パッケージ・アプリケーション用パフォーマンス... 14

データ・ウェアハウスおよび意思決定支援... 16

ビットマップ・インデックスおよびビットマップ・ジョイン・インデッ

クス... 16

パーティション化... 17

Oracle のパーティション化オプション... 17

DB2 のパーティション化オプション... 18

追加のデータ・ウェアハウス機能: マルチテーブル・インサート .... 19

パフォーマンスの管理性 ... 19

自動ワークロード・リポジトリ（AWR） ... 20

自動パフォーマンス診断（ADDM） ... 20

自動 SQL チューニング... 21

結論 ... 21

(3)

Oracle Database と IBM DB2 UDB の技術的比較:

パフォーマンスを重視

概要

このホワイト・ペーパーでは、市場をリードするデータベース管理システムの Oracle Database および競合製品の IBM DB2 UDB のパフォーマンスと拡張性の最も重要な相違点を考えます。

Oracle Database は、各種の業界標準および ISV 固有のベンチマークで常に競合会社を凌ぐ結果をだし、データベースの拡張性で業界をリードしています。このドキュメントでは、両製品の技術的相違点について、ベンチマークおよび実際の顧客環境における Oracle の卓越したパフォーマンスを中心に説明します。プラットフォームの可用性の違いを簡単に説明し、現代の企業クラスのリレーショナル・データベース・システムで最適なパフォーマンスと拡張性（並行性モデル、索引付け、パーティション化、パラレル実行およびクラスタ化）の確保に使用される一般的な方法に重点を置いて説明していきます。最後に、両製品のパフォーマンスの管理性を簡単に比較します。

(4)

主なパフォーマンスの特徴的機能

次の表と項に Oracle Database と DB2 の主な特徴的機能を示します。それ以降に機能を詳しく説明します。

機能 Oracle Database DB2 UDB

並行性モデルマルチバージョン読込み一貫性ロック・エスカレーションしない行レベル・ロックなしロック・エスカレーション

クラスタ化構成 Real Application Clusters による透過的なスケーラビリティ DB2ESE に必要な柔軟性の低いデータのパーティション化索引付け機能多様な索引付けスキーム B ツリーおよび動的ビットマップ・インデックスのみパーティション化オプションレンジ、ハッシュ、リストおよびコンボジットのパーティション化ローカルおよびグローバル索引ハッシュ･パーティション索引のみローカル索引のみ追加データ・ウェアハウス機能複数表の挿入サポートしません高度なアドバイザリアクセス、SQL チューニング、インデックス、サマリー、メモリー、MTTR 索引アドバイザリのみセルフチューニング機能自動パフォーマンス診断自動 SQL チューニングセルフチューニング・メモリー、空き領域および I/O 管理同等の機能がないか、制限ある機能表 1: 主な特徴的機能

Oracle Database は Oracle Database。IBM DB2 とは

製品の可用性が直接パフォーマンスに結びつかない場合でも、多種多様なハードウェアとオペレーティング・システム全体に真の移植性があれば、ユーザーはアプリケーションの変更、再設計または再構築をせずシームレスにハードウェア・システムをアップグレードまたは変更できます。つまり、移植性があればアプリケーション・ソフトウェアへの初期投資を保護し、複数のプラットフォームにわたってパフォーマンスの一貫性を持たせることができます。 Oracle Database は単一製品で、多数のハードウェアとオペレーティング・システムにシングル・コード・ベースから移植されています。このデータベースは、すべてのプラットフォームで、パフォーマンス機能とツールを同様にサポートします。IBM は DB2 を 1 つの製品として販売していますが、実際には違うコード・ベースを持つ製品のファミリーで、各製品の機能とツールは大きく異なります。

(5)

話を明確および簡単にするため、このホワイト・ペーパーでは DB2 UDB Enterprise Server Edition (ESE) Version 8.2 についてのみ検討します。ドキュメント全体での用語として、DB2 および DB2 UDB は、製品 DB2 UDB ESE Version 8.2 を指し、Oracle、 Oracle Database および Oracle Database 10g はすべて最新バージョンの Oracle Database である Oracle Database 10g Enterprise Edition リリース 2 を指します。

トランザクション処理

オンライン・トランザクション処理（OLTP）アプリケーションには、非常に多くのユーザーが多量のデータに同時にアクセスして、短時間の挿入または更新トランザクションが頻繁にあるという特徴があります。このような環境には、高スループット、いくつかの索引付けポリシーの選択、卓越したデータの並行性に対するサポートが必要となります。Oracle Database は、これらの要求に応えるためのプラットフォーム選択の決め手となる、他にはない機能を提供します。

並行性モデル

Oracle Database と DB2 では、並行性制御の実装に大きな違いがあります。 Oracle は、同時問合せおよび更新処理する複合ワークロード環境を完全にサポートします。Oracle Database では、書込み機能が読取り機能をブロックすることなく、また読取り機能が書込み機能のブロックもしません。ノンブロッキングのマルチバージョン読込み一貫性により、ユーザーへの一貫した問合せ結果の提供と、同時更新処理中のパフォーマンスの維持が同時に実現します。 DB2 には Oracle が持つ強力なマルチバージョン読込み一貫性はなく、ユーザーは精度と並行性どちらかの選択が必要です。つまり、DB2 ユーザーは、書込みをブロックして読込み一貫性を確保するか、不正確な結果すなわち内容を保証しない読込みを受け入れるか、どちらか 1 つの選択が必要となります。 Oracle の基本アーキテクチャでは、多数のトランザクションを非常に効率よく管理します。これを可能にするテクノロジが Oracle の特許取得済のロック・エスカレーションしない行レベル・ロックです。すべてのトランザクション処理のアプリケーションで、Oracle テクノロジの効果を実感できます。アプリケーションに接続するユーザー数の増加に伴いトランザクション量が増大しても、Oracle Database は一貫したパフォーマンスを提供し続けることができます。データベース拡張性を専門とする会社のWinter Corporationによると、サイズが 1 ∼10 位までのUnixのOLTPデータベース1_{すべてがOracleで稼働されている理由の} 1 つは、この効率的な並行性モデルにあります。他のデータベースでは、それに近づくことすら困難です。 DB2 はロック情報を追跡できるメモリー構造に制限があるため、アクティビティが増加するとリソース使用量を最小化するために、行ロックを表ロックに拡大する必要があります。このため、不必要な競合が発生しスループットは低減します。 1_{http://www.wintercorp.com/vldb/2003_TopTen_Survey/TopTenWinners.asp}

(6)

次の表に主な違いをまとめます。詳細は次項で説明します。 Oracle Database 10g DB2 マルチバージョン読込み一貫性使用できません。読込みロックは必要ありません。内容を保証しない読込みを回避する読込みロックが必要です。内容を保証しない読込みはありません。読込みロックを使用しないと、内容を保証しない読込みが行われます。ロック・エスカレーションしない行レベル・ロック。ロック・エスカレーションします。読取りは、書込みをブロックしません。読取りは書込みをブロックします。書込みは、読取りをブロックしません。書込みは読取りをブロックします。負荷状態で、デッドロックは発生しません。負荷状態でデッドロックが発生し、深刻な問題となる可能性があります。表 2: 並行性モデル

マルチバージョン読込み一貫性

マルチユーザー環境で発生する既知の現象を防止する能力は、データベースの実装によって異なります。 • 内容を保証しない読込み、すなわち非コミット読込みは、コミットされていないデータベースへの変更をトランザクションが読み込める場合に発生します。 • 非リピータブル・リードは、トランザクションが以前に読み込んだデータを再び読み込んで、そのデータを他のコミット済トランザクションが変更または削除した検出に発生します。 • ファントム・リードは、検索条件を満たす行セットを返す問合せをトランザクションが 2 回実行し、第 1 の問合せが返さなかった行を第 2 の問合せが取得できる（条件を満たす行を他のアプリケーションが挿入できたため）ことの検出に発生します。 Oracle のマルチバージョン読込み一貫性の実装は、常に一貫性がある正確な結果を提供します。トランザクションがデータを更新すると、元のデータ値がデータベースの UNDO レコードに記録されます。Oracle では、読込み中の情報の変更を防止するため、または変更されているがコミットされていない情報の問合せによる読込みを防止するための情報のロックではなく、UNDO レコードの現在の情報を使用した表のデータの読込み一貫性ビューを構築し、一貫したバージョンの情報を常に任意のユーザーに返すことができます。 DB2 では、マルチバージョン読込み一貫性は提供されません。DB2 の場合、アプリケーションに様々な分離レベルの読込みロックを使用するか、内容を保証しない読込みを受け入れるか、どちらか 1 つの選択が必要です。読込みロックは、同時トランザクションによる読込みデータの変更を防止します。こうした実装の場合、読込みと書込みが混在する環境で同時要求を適切に処理するシステムの能力が制限されることは明らかです。ユーザーは、別のワークロード環境を構築する

(7)

ほかありません。結果として、受入れ可能なデータの並行性および精度を得るために、DB2 ユーザーはアプリケーション設計を多少犠牲にすることは避けられません。IBMは、自社のドキュメントでこの事実を認めています。「DB2 UDBは、更新中はアプリケーションに排他ロックが要求されるため、その他のアプリケーションは行の読込みができません（ただし、UR（非コミット読込み、内容を保証しない読込みを意味します）。分離レベルを使用する場合は読込みが可能です）。このため、多数のアプリケーションが同時に同じデータにアクセスすると、システムの並行性が下がる可能性があります。システムの並行性を高めるには、読取り専用トランザクションなどのトランザクションを頻繁にコミットしてください。できれば、同じ表へのアクセスが競合するアプリケーションをリスケジュールしてください。また、読込み一貫性が問題とならない非コミット読込み（内容を保証しない読込み）トランザクションを使用してください。」2 Oracle では、書込みと読取りが互いにブロックしあうことは決してありません。 Oracle の強力なマルチバージョン読込み一貫性によって、パフォーマンスを維持した状態で適切な機能を発揮する複合ワークロード環境が実現します。この機能がアプリケーション開発にどのように影響するか、SAP を例に説明します。予想される並行性に読込みロックの重大な影響を回避するため、DB2 の内容を保証しない読込みを SAP で補正する必要があります。これは、SAP インタフェースのデータベース依存レイヤーに実装されている追加コードを介して行われます。SAP 用の Oracle インタフェースでは読込み一貫性の確保はデータベース・サーバーが担当するため、機能の追加が必要ありません。

ロック・エスカレーションしない行レベル・ロック

行レベル・ロックが提供する非常にきめ細やかなロック管理により、最高レベルのデータ並行性が実現します。また、表内の行を更新するユーザーまたは処理がその行のみをロックするので、その他すべての行は同時処理で使用可能な状態です。 Oracle では、行レベル・ロックをデフォルトの並行性モデルとして使用し、ロック情報を実際の行に格納します。このことで、Oracle はデータベース内の行または索引エントリと同数の行レベル・ロックを持つことができ、データ並行性は制限されません。DB2 も、行レベル・ロックをデフォルトの並行性モデルとしてサポートします。しかし、過去のバージョンでのデータベースでは、そのロック粒度はデフォルト・レベルで提供されなかったため、後に行レベル・ロックを追加して対応していました。ただし、これにはロック・リストという別のメモリー構造の追加が必要でした。どのようなメモリー構造でもロック・リストにはサイズの制限があるため、データベースでサポートできる最大ロック数も制限されます。アプリケーションにアクセスするユーザー数の増加に伴いトランザクションの量が増大すると、DB2 はメモリーを節約するために、行レベル・ロックから表ロックに拡大します。「…行レベル・ロックの最大同時ユーザー数は、表レベル・ロックより多くなります。しかし、ロックには記憶域と処理時間が必要なため、単一の表ロックによってロック・オーバーヘッドを最小化します。」3

2_{『IBM DB2 Universal Database Poring Guide, Oracle to DB2 UDB for Windows, OS/2 and Unix, Version7.2』} p. 51 参照。http://www-106.ibm.com/developerworks/db2/library/techarticle/0205wilkins/0205wilkins.pdf 3_{IBM DB2 Universal Databaseの『Administration Guide: Performance, Version 8』p. 49 参照。}

(8)

つまり、同時にデータにアクセスできるユーザー数は少なく、ユーザーには待機時間が発生することを次に示します。「行から表へのロック・エスカレーションが発生すると、ロック・エスカレーションの処理自体にはそれほど時間がかかりませんが、表全体のロックにより並行性が低下します。ロック処理された表へのその後のアクセスによって、データベースの全体的パフォーマンスが低下する可能性があります。」4 DB2 では「ロック・エスカレーションには他のアプリケーションの同時実行性への影響という重大な副作用があります。たとえば、ロック・エスカレーションにより（または他の理由により）あるアプリケーションが表T1に対して共有表ロックを保持すると、他のアプリケーションはT1の行の更新ができません（しかしT1 の行の読込みはできます）。同様に、アプリケーションが排他的な表ロックを保持すると、他のアプリケーションは表の行の読込みまたは更新ができません。」5 DB2 Magazineのある記事に、「… ERP、ロック・エスカレーションはパフォーマンスを低下させる最大要因の1つです。」6という記述があります。この記事では、ロック・エスカレーションをオフにするアドバイスをしています。ただし、これはOS/390 でDB2 を使用する際のオプションであって、UnixおよびWindowsでDB2 を使用する際はロック・エスカレーションをオフにできません。「ロック・エスカレーションは内部メカニズムで、保持されているロック数を減らすためにDB2ロック・マネージャで呼び出されます。ロック・エスカレーションは、保持されているロック数がデータベース構成パラメータのLOCKLISTによって定義されたしきい値を超えると、行ロックから表ロックまでロック範囲が拡大します。ロック・エスカレーションは、並行性に非常に大きく影響し、並行稼動しているアプリケーションの応答時間を低下させる可能性があります。」7 このロック・エスカレーションの結果、保持されている総ロック数が減少し、2 人以上のユーザーが互いにロックされたデータを待つ可能性は大きく増加します。「ロック・エスカレーションは、デッドロックを引き起こすこともあります。」8 このような好ましくないデッドロック状況は、通常、同時ユーザーの 1 つ以上のトランザクションを強制終了して解決します。

「OracleおよびDB2 UDBで異なる並行性制御の結果、OracleからDB2 UDBに直接移

植されたアプリケーションは、以前は発生しなかったデッドロックを経験することがあります。DB2 UDBは読取りに共有ロックを取得するため、更新がブロックされることがあります。デッドロックは、トランザクションが他の何らかのトランザクションがロックした排他的なリソースに依存し、次に後者のトランザクションが前者のトランザクションが使用する排他的なリソースに依存したため、トランザクションが進行処理不可能となったときに発生します。デッドロックを解決する唯一の方法は、アプリケーションの1つをロールバックすることです。」「Oracle から DB2 UDB に直接移植されたアプリケーションは、以前に経験しなかったデッドロックを発生することがあ ります。」 ホワイト・ペーパー『Oracle to DB2 Migration Comparison』p.58参照。

4_{IBM Redbooks 『DB2 UDB/WebSphere Performance Tuning Guide』p. 128 参照。} http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246417.pdf

5_{『IBM DB2 Universal Database Poring Guide, Oracle to DB2 UDB for Windows, OS/2 and Unix, Version7.2』} p. 52 参照。http://www-106.ibm.com/developerworks/db2/library/techarticle/0205wilkins/0205wilkins.pdf 6_{DB2 Magazine}_{http://www.db2mag.com/db_area/archives/1999/q2/99sp_yevich.shtml}

7_{IBM Redbooks『DB2 UDB/WebSphere Performance Tuning Guide』p. 116 参照。} http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246417.pdf

(9)

9 Oracle では、ロック・エスカレーションが発生しないため、Oracle ユーザーはロック・エスカレーションによるデッドロック状況に陥ることがありません。

索引付け機能

索引は、データによる高速なパスの提供に作成されるデータベース構造です。索引を使用するとディスク I/O 処理が大幅に削減されるため、データ取得のパフォーマンスが向上します。 Oracle および DB2 はともに従来の B ツリー索引付けスキームをサポートしますが、 Oracle は多様なアプリケーション・シナリオに適した索引付け機能を数多く追加、提供します。特に、Oracle は静的ビットマップ・インデックスおよびビットマップ・ジョイン・インデックスをサポートします。これらのインデックスは、他の索引付け方法と比べて応答時間を大幅に改善し領域使用率を大幅に削減するため、データ・ウェアハウス・アプリケーションが活用できます。さらに、Oracle は OLTP 環境でパーティション化された表の使用に不可欠なパーティション全体のグローバル索引をサポートします。 DB2 は、Bツリー索引10および動的ビットマップ・インデックスのみをサポートします。DB2 は索引および表を同一レベルでパーティション化し、パーティション全体のグローバル索引はサポートしません。次の表に相違点を示します。機能 Oracle DB2 ストアド圧縮ビットマップ・インデックスあり - ビットマップ・ジョイン・インデックスあり - 動的ビットマップ・インデックスありあり索引構成表あり - 逆キー索引あり - ファンクション・ベース索引あり一部表 3: 索引付け機能 Oracle では、索引付けされている表の 1 つまたは 2 つ以上の列のファンクションに索引を作成することもできます。ファンクション・ベース索引は、ファンクションまたは式の値を事前に計算して索引に格納します。ファンクション・ベース索引は、B ツリーまたはビットマップ・インデックスのどちらかとして作成できます。 DB2 の生成列の機能で、索引は生成列の値の導出に使用する式に基づいて作成できます。しかし、DB2 では導出された値が表に格納されるため、このような実装は Oracle のファンクション・ベース索引より効率が劣ります。最後に、Oracle は静的ビットマップ・インデックスおよびビットマップ・ジョイン・インデックスをサポートします。DB2 は動的ビットマップ・インデックスの

9_{『IBM DB2 Universal Database Poring Guide, Oracle to DB2 UDB for Windows, OS/2 and Unix, Version7.2』} p. 52 参照。http://www-106.ibm.com/developerworks/db2/library/techarticle/0205wilkins/0205wilkins.pdf 10_{Bloor Research 2001、Database Report p.84「DB2 は従来の索引付けはBツリーに制限されます。}_」

(10)

みをサポートします。索引付けスキームの詳細は、「データ・ウェアハウス」および「意思決定支援」の項に説明します。

索引構成表

索引構成表では、表の行はプライマリ・キー索引に格納されているので、プライマリ・キーでの完全一致検索や範囲検索を含む問合せの場合、表データに高速にアクセスできます。索引構成表では表とプライマリ・キー索引の両方でのキー列の重複がないため、ストレージ要件が減少します。索引値と行データのリンクには、行のアドレスを通常の表に格納し通常の索引で使用される ROWID が必要ですが、索引構成表ではこれを必要としません。索引構成表は、ROWID 疑似列、 LOB、セカンダリ索引、レンジおよびハッシュ・パーティション化、オブジェクト・サポートおよびパラレル問合せをはじめとするすべての表機能をサポートします。また、索引構成表にビットマップ・インデックスを作成できるため、データ・ウェアハウス環境において索引構成表をファクト表として使用できます。 DB2 は、索引構成表をサポートしません。DB2 では、索引のキー列セットに追加する列を指定できます。この機能は索引のみのアクセスを介した問合せのパフォーマンスを高めますが、列は表と索引の両方に複製されるため、索引構成表のストレージ効率は上がりません。

クラスタ化システム

クラスタは、プライベート・ネットワークで接続された独立したサーバーまたはノードの集まりです（クラスタ・インターコネクトと呼ばれます）。ノードは、単一のシステムとして協調動作します。クラスタは、アプリケーションをシングル・ノード・システムの制限を超えて拡張します。Oracle および DB2 はともにクラスタ化構成をサポートしますが、アーキテクチャには大きな違いがあります。

Oracle Database 10g Oracle Real Application Clusters

Real Application Clusters（RAC）は、Oracle Database のオプションでハードウェア・クラスタをサポートします。Oracle Database 10g Oracle Real Application Clusters は共有ディスク・アプローチを採用します。純粋な共有ディスク・データベース・アーキテクチャでは、データベース・ファイルは論理的にすべてのデータにアクセスする各インスタンスにより疎結合されたシステムのノード間で共有されます。

Oracle Database 10g Real Application Clusters は、特許取得済の Cache Fusion™アー キテクチャを使用します。このテクノロジは、クラスタ内でのすべてのノードが相互接続されたキャッシュで、どのような種類のアプリケーション（OLTP、DSS、パッケージ・アプリケーション）にもデータベース要求を満たします。これで、ローカル・キャッシュでも他のキャッシュでも問合せ要求を満たすことができます。ローカル・ノードは必要なブロックを他のクラスタ・ノードのデータベース・キャッシュから直接取得できるため、更新処理でのディスク書込み処理と読込み処理の同期が必要ありません。Oracle の Cache Fusion™は、必要なデータ・ブロックをリモート・ノード・キャッシュからローカル・キャッシュへ直接送る待機時間の少ないクラスタ・インターコネクト・プロトコルを展開します。Cache Fusion™ は、ノード間同期のクリティカル・パスから低速のディスク処理を削除します。時間のかかるディスク・アクセスは、必要なデータがどのキャッシュにもない場

(11)

合、および更新トランザクションがコミットされディスク書き込み保証を必要とする場合にのみ行われます。この実装は、データベース・キャッシュの作業セットを効果的に拡張しディスク I/O 処理を減らすことで、データベース処理をスピードアップします。

DB2 のシェアード・ナッシング・アーキテクチャ

DB2 はシェアード・ナッシングのアプローチを採用しています。純粋なシェアード・ナッシング・アーキテクチャでのデータベース・ファイルは、マルチコンピュータ・システムのノードで稼働するインスタンス間でパーティション化されます。各インスタンスまたはノードには、区分されたデータ・サブセットのアフィニティがあります。このデータへのアクセスはすべてこの所有インスタンスによって排他的に行われます。つまり、純粋なシェアード・ナッシング・システムは、複数のノードにわたって処理を分配するために、パーティション化されたアクセス・スキームまたは制限付アクセス・スキームを使用します。これは、ノードのデータ所有権の変更が比較的まれな環境でのみ順調に動作します。所有権が変更される一般的理由は、データベース再編成またはノード障害です。シェアード・ナッシング・システムにおけるパラレル実行は、データ・パーティション化スキームにそのまま基づいています。データが正確にパーティション化されると、システムはほぼ直線的に拡張されます。表層的には、純粋なシェアード・ナッシング・システムは分散データベースと同じです。任意のノードで実行されるトランザクションは、アクセス対象のデータを所有する他のノードにメッセージを送る必要があります。また、必要な読み込みおよび書き込み処理を行うために、他のノードで行われた処理を連携させる必要もあります。このようなメッセージングを一般にファンクション・シッピングと呼びます。ただし、シェアード・ナッシング・データベースは分散データベースとは根本的に異なり、これらは 1 つのデータ・ディクショナリを使用した 1 つの物理データベースの処理です。

アプリケーションの互換性

クラスタ化構成のサポートでは、選択するアーキテクチャによってアプリケーションの互換性に大きな差が生じます。

Oracle Database 10g Oracle Real Application Clusters は、アプリケーションの完全互換性を可能にする設計となっています。カスタム OLTP、DSS、または Oracle E-Business Suite などのパッケージ・アプリケーションなど、すべての種類のアプリケーションは、単一システムからクラスタ化構成までの幅広い配置に対し、何の変更もなく稼働できます。再設計、コードの変更、明示的なアプリケーション・セグメント化またはデータ・パーティション化などが一切必要ありません。これに対して、単一システムで稼働する既存の DB2 データベースを、DB2 UDB ESE のクラスタ化構成で使用するためには移行が必要です。この移行には硬直したデータ・パーティション化と、費用のかかる複雑な追加の開発が必要にもなります。

(12)

OLTP アプリケーション用パフォーマンス

2 つの製品で採用されるアーキテクチャの違いによって、パフォーマンスと拡張性に多数の違いがあります。次の表にそれを示します。

Oracle Database 10g Oracle Real Application Clusters DB2 EEE 2 フェーズ・コミットは不要 2 フェーズ・コミットは必要データを複数ノードでキャッシュ各クロスパーティション・アクセス用 IPC データ用単一プローブマルチ・パーティション・プローブ均一な負荷の分散ロードの偏りの可能性表 4: クラスタリング 2 フェーズ・コミット DB2 システム上の複数のパーティションのデータを変更するトランザクションでは、2 フェーズ・コミット・プロトコルを使用して、複数のマシンでトランザクションの一貫性を保証することが必要です。DB2 のトランザクションは、2 フェーズ・コミットの第 1 フェーズでコミット時に準備レコードを書き込む必要があります。トランザクションは第 1 フェーズが完了すると第 2 フェーズに進むことができます。そのために、OLTP アプリケーションの応答時間も増えていました。

Oracle Database 10g Real Application Clusters では、コミットの場合にはトランザク ションを実行しているノードでのログの強制実行を待つだけです。そのトランザクションがクラスタの他のノードで変更されたデータにアクセスすると、これらのブロックはディスク I/O 処理を行うことなく高速相互接続で送信されます。Real Application Clusters では、送信前にそのブロックに存在する変更の強制的なログが必要です。しかし、SAP Sales および分散ベンチマークなどの挿入集約型ベンチマークでも、これらの送信がログの強制実行でブロックされる可能性は非常にわずかです（5%未満）。その理由は、ブロックに対する変更のログが別のノードで必要となる前に、ログ・ライターによりバックグラウンドで連続して強制的にディスクに記録されるためです。データ・キャッシュ

Real Application Clusters では、グローバル・キャッシュ・サービス（GCS）によりキャッシュの一貫性を確保します。グローバル・キャッシュ・サービスでは、Real Application Clusters で、データを必要としキャッシュに領域を持つノードと同数の頻繁に変更されないデータをキャッシュできます。それ以降のこのデータへのアクセスは、メインメモリーへのスピードで行われます。一方、DB2 システムでは、最後にアクセスしてから一度もデータを変更していない場合でも、そのデータへ別のパーティションからアクセスするにはプロセス間通信が必要となります。

(13)

パーティション・プローブ DB2 は、索引および表の同一レベル・パーティション化を行います。このため、問合せの複数パーティション・プローブが行われてパーティション・プルーニングは生じません。たとえば、従業員表が従業員数でパーティション化されており従業員名の索引がある場合、DB2 では、従業員の検索にすべてのパーティションの中にあるその従業員名をプローブします。名前による従業員の検索で実行される総処理量は、パーティションの数とともに増加します。

一方、Real Application Clusters では、同じ問合せは単一の B ツリー従業員名索引にある関連索引ページのみにアクセスすれば実行できます。ロードの偏り DB2 システムでは、次の 2 つの理由でロードが偏る可能性があります。第 1 に、基礎となるデータは、すべてのパーティションに均一に分散されない可能性があります。特にカーディナリティの低いデータの場合に発生しやくなります。第 2 に、データ・アクセスは、基礎となるデータが均一に分散されていた場合でも、季節的傾向または毎日の傾向によって小さな列値セットに偏る可能性があります。

Real Application Clusters にはデータを排他的に所有するノードがなく、すべてのノードがすべてのデータにアクセスできるため、ロードの偏りは発生しません。

トランザクション・ルーティング

Real Application Clusters のパフォーマンスは、トランザクションをクラスタのノードのサブセットにルーティングすることでさらに改善できる場合があります。この場合ではデータ・アフィニティが向上し、ノード間通信が減少します。ルーティングは、Oracle Net 構成のサービス名を使用して簡単に実行できます。 DB2 では、ルーティング・トランザクションは関数で実行されるため、トランザクションによってアクセスされるデータ位置の知識が必要で非常に煩雑です。また、データを再分散せずにより多くの（またはより少ない）数の論理ノードでトランザクションを実行するため、最適なパフォーマンスが得られず、負荷の変動に対する柔軟性も不足しています。

状況によっては、Real Application Clusters システムを適切なミドルウェアとともに構成して、アプリケーションのバインド値に基づく要求もルーティングできます。たとえば、メール・サーバーはユーザーのログインに基づいた電子メール接続のルーティングができます。基礎となるデータもレンジまたはリスト・パーティション化によるバインド値に基づいてパーティション化すれば、最も効果的なルーティングが可能となります。DB2 では、データの配置をユーザーが制御できないため、このようなことは実行できません（DB2 は、ハッシュ・パーティション化のみをサポートし、レンジおよびリスト・パーティション化はサポートしません）。

(14)

パッケージ・アプリケーション用パフォーマンス

ポピュラーな OLTP アプリケーション（Oracle、SAP、PeopleSoft または Siebel のアプリケーション）には、非常に多くの表および一意のグローバル索引があります。これらのアプリケーションでは、スピーディなデータ・アクセスとデータ整合性を確保するため、非プライマリ・キー列に一意のグローバル索引が必要です。この索引がないと、重要な役割を担うアプリケーション・データに破損、複製または紛失が生じる可能性があります。アプリケーションでもデータ・アクセスの完全なパーティション化は行われません。問合せ要件がデータの単一パーティションの内容ごとに排他的に満たすことができ、かつ高い比率でローカル・データ・アクセスを行うアプリケーション表のパーティション化キーを見つけることは不可能です。非ローカル・データ・アクセスは、頻繁に起こる分散トランザクションで許容できないパフォーマンス・オーバーヘッドをもたらします。共通の場所以外に置かれているデータへのアクセスでは「トランザクションで使用されるデータには、パーティション間でのデータの移動にパーティション間通信が必要です。2つ以上のパーティションが関連する更新トランザクションの場合は、2フェーズ・コミット処理のオーバーヘッドが追加されるため、状態はさらに悪化します。」11

SAP、PeopleSoft または Oracle E-Business Suite では、非常に重要な問合せは複数の表を結合し、それ以外の問合せは結合の述語に別の非プライマリ・キーを使用します。PeopleSoft または SAP アプリケーションを DB2 などのシェアード・ナッシング・データベースに配置することは極めて困難です。

それに対して、パッケージ・アプリケーションでは、Oracle Database 10g Real Application Clustersアーキテクチャの稼働や拡張に書き換えを必要としません。 Oracle用に開発されたその他のアプリケーションの場合、次に示すとおりReal Application Clustersでの稼働に移植または特別なチューニングは必要ありません。「RACは、[…]実質的に無制限の拡張性を提供し、[…]顧客のアプリケーションはすべて、変更せずにサポートできます。RAC専用以外のアプリケーションでも、 Oracle9i RACの可用性および拡張性機能の利点を活用できます。」12

11_{『DB2 UDB EEE as an OLTP Database』}_{、Gene Kligerman、DB2 and Business Intelligence Technical Conference、} Las Vegas、Nevada、2000 年 10 月 16-20 日

12_{IBM Redpaper『Implementing Oracle9i RAC with Linux on IBM @server xSeries servers』P.3 参照。} http://publib-b.boulder.ibm.com/cgi-bin/searchsite.cgi?query=linux+AND+Oracle

(15)

図 1: Oracle Database Real Application Clusters における Oracle E-Business Suite の拡張性これは、Oracle Applications の標準ベンチマークで明確に実証されました。2 つのベンチマークが、同じベース・システムを使用してそれぞれ 2 ノード・クラスタ構成と 4 ノード・クラスタ構成で実行されました。報告結果によると、サポートされるユーザー数は、2 ノード構成では 2296 から増加、4 ノード構成で 4368 から増加しスケーラビリティは 1.9 です。

図 2: Oracle Database Real Application Clusters における SAP の拡張性

同様に、SAP R/3 販売および分散（SD）アプリケーションの初期パフォーマンス・テストでは、1 ノードから 2 ノードに、2 ノードから 4 ノードに構成を拡張するとパフォーマンスは 1.8 倍増加する結果となりました。

いずれの場合も、アプリケーションまたはデータベースの特別な再設計は必要ありません。

発表によれば、2001 年 5 月に Orlando で開催された International DB2 User's Group Conference で配布された IBM 社の Gene Kligerman 著『DB2 EEE as an OLTP

Database』では、OLTP 環境でノードを追加すると実際に DB2 のパフォーマンス

は低下するとしています。Kligerman は、「すべてのトランザクションが均一に分散される環境をシミュレートしてみると、2ノード構成および4ノード構成の場合、パフォーマンスは1ノード構成より低下する」と述べています。

(16)

データ・ウェアハウスおよび意思決定支援

データ・ウェアハウスは、問合せおよびデータ分析専用に設計された大規模データベースです。これらのデータ・ウェアハウスは、長時間実行される多様な一時問合せ用とした稼働には最適化が必要です。こうした環境には、クエリー・リライト機能、効率的な索引付け機能、パーティション化ポリシーの多様な選択肢を適切にサポートし、パラレル実行についても様々なサポートが必要となります。繰り返しますが、Oracle Database 10g では、他にはない機能でこれらの要件に完全に対応できます。

ビットマップ・インデックスおよびビットマップ・ジョイン・インデッ

クス

Oracle は静的ビットマップ・インデックスおよび静的ビットマップ・ジョイン・インデックスをサポートします。ビットマップ・インデックスは、各キー値に対する ROWID リストではなくビットマップ（またはビット・ベクトル）を使用します。ビットマップの各ビットは、表の 1 つの行に対応します。 ROWID のリストの場合と比べてビットマップ表現では、特にカーディナリティが低いデータの場合、多くの領域を節約できます。ビットマップ・インデックスでは、ブール演算子を使用して異なる索引エントリのビットマップを結合します。ビットマップ・インデックスは、WHERE 句内の複数の条件に対応する索引を効率よくマージします。すべての条件ではなく一部を満たす行には、表自体のアクセス前にフィルタが適用されます。この結果、しばしば大幅に、応答時間が短縮されます。ビットマップ・ジョイン・インデックスは、2 つ以上の表の結合に関するビットマップ・インデックスです。ビットマップ・ジョイン・インデックスを使用すると、表の実際の結合が回避できます。または、事前に制限することにより、結合の必要なデータ量を大幅に削減できます。問合せにビットマップ・ジョイン・インデックスを使用すると、ビット単位処理によって時間を短縮できます。ビットマップ・ジョイン・インデックスには複数のディメンション表が含まれており、単一表にビットマップ・インデックスを使用するスター型変換で必要なビット単位処理が必要ありません。各種のスター型問合せに対するパフォーマンス測定では、ビットマップ・ジョイン・インデックスの使用による応答時間の大幅な短縮が示されています。 DB2 は動的ビットマップ・インデックスのみをサポートします。動的ビットマップ・インデックスは、実行時に RID を既存の通常の索引から取り出し、ハッシングまたはソートですべての RID からビットマップを作成することにより作成されます。このため、動的ビットマップ・インデックスでは、Oracle の実際のビットマップ・インデックスと同じクエリー・パフォーマンスは提供されません。動的ビットマップ・インデックスはスター型変換ポリシーでスター型問合せを実行できますが、これらの索引は依然としてBツリー索引ベースなため、さらに大型のB ツリー索引にアクセスするI/Oコストがかなり高くなります。13 13_{オラクル・ホワイト・ペーパー『Oracle10gの主要なデータ・ウェアハウス機能: 比較パフォーマンス分} 析』参照。

(17)

さらに、動的ビットマップ・インデックスを持つデータベースでは、Oracle の真のビットマップ・インデックスでは可能な、領域の削減または索引作成時間の削減ができません。

パーティション化

パーティション化により大規模なデータベース構造（表や索引など）を、さらに小さく管理の容易なパーティションに分割できます。パーティション化は、パーティション・プルーニングと呼ばれる方法でパフォーマンスを向上させます。パーティション・プルーニングでは、必要なデータを含むパーティションのみを処理できます。処理に必要ではないデータを含むパーティションは検索対象から排除されます。この方法では、ディスクから取得されるデータ量を大幅に削減することで処理時間が短縮されるため、問合せのパフォーマンスとリソースの使用率が向上します。パーティション化を通じて複数表結合のパフォーマンスも向上します。これはパーティション・ワイズ・ジョインという方法です。パーティション・ワイズ・ジョインは、2 つの表が結合され、その両方が結合キーに基づいてパーティション化されている場合に適用できます。パーティション・ワイズ・ジョインは、各パーティション間での大きな結合を小さい結合として分割するため、結合全体の終了までの時間を短縮します。これは、シリアル実行とパラレル実行の両方のパフォーマンスを大幅に向上します。最後に、DML 文のパラレル実行を可能にすることで、意思決定支援システムおよびデータ・ウェアハウスのような大規模データベースにおけるデータ処理集中型処理の応答時間を短縮します。

Oracle のパーティション化オプション

Oracle Database 10gでは、様々な特別な状況に応じて適切に設計されたパーティ ション化の方法をいくつか提供しています14_。 • レンジ・パーティション化は、あるレンジ（範囲）の列値で行をパーティションにマッピングします。範囲によるパーティション化は、特に履歴データベースで適しています。また、データ・ウェアハウスのローリング・ウィンドウ操作のサポートにも最適なパーティション化方法です。 • ハッシュ・パーティション化は、パーティション列にハッシュ関数を使用してデータをパーティションにストライプ化します。これは、データの均等分散に有効な方法です。 • リスト・パーティション化は、行のパーティションへのマッピング方法を明示的に制御できます。このためには、各パーティションの説明として、パーティション列に対する離散値のリストを指定します。 • さらに、Oracle ではレンジ-ハッシュとレンジ-リスト・コンポジット・パーティション化もサポートしています。 Oracle では、次の 3 種類のパーティション索引も使用できます。 14_{Oracle Databaseのパーティション化オプションの詳細は、オラクル・ホワイト・ペーパー『Partitioning in} Oracle Database 10g』参照。

(18)

• ローカル索引は、基礎となるパーティション表と同様のパーティション方法でパーティション化されるパーティション表に対する索引です。ローカル索引の各パーティションが、基礎となる表の 1 つのパーティションのみと 1 対 1 で対応します。 • パーティション化されたグローバル索引は、表とは異なるパーティション化キーでパーティション化されるパーティション表または非パーティション表に対する索引です。 • パーティション化されていないグローバル索引は、非パーティション表に対する索引と本質的には同じであり、索引構造がパーティション化されません。 Oracle では、パーティション/非パーティション索引および表の任意な組合せができ、パーティション表でパーティション索引と非パーティション索引の使用や、非パーティション表でパーティション索引と非パーティション索引の使用が可能です。

DB2 のパーティション化オプション

次の表に、Oracle と DB2 がサポートするパーティション化オプションの相違点を示します。機能 Oracle DB2 レンジ・パーティション化あり − リスト・パーティション化あり − ハッシュ・パーティション化ありありコンポジット・パーティション化あり − ローカル索引ありありパーティション化されたグローバル索引あり − パーティション化されていないグローバル索引あり − 表 5: パーティション化オプション DB2 がサポートするのは、ハッシュ・パーティション化15だけで、Oracleのパーティション化機能と比較すると多くの制限があり弱い点となります。ハッシュ・パーティション化は、レンジ・パーティション化やリスト・パーティション化と異なり、一般的な問合せでパーティション・プルーニングを活用できません。Oracle では、表および索引の多数のパーティション化オプションをサポートしているため、多くの問合せでパーティションをプルーニングできます。 DB2 はハッシュ・パーティション化のみをサポートし、ローリング・ウィンドウのサポートはできません。この処理では、新しいデータのロードと古いデータのパージを定期的に行うことで、データ・ウェアハウスを最新の状態に保持し最新のデータは常にオンライン状態にします。DB2 のハッシュ・パーティション化スキームでは再分散されるデータがすべてのパーティションに必要なため、新しいデータのロード時間が増すだけでなく、データ再分散処理中に表がロックされ

15_{IBM DB2 Universal Database, SQL Reference, Volume 2, Version 8 のp.373 参照。} http://ftp.software.ibm.com/ps/products/db2/info/vr8/pdf/letter/db2s2e80.pdf

(19)

データの可用性も低減します。最終的に、DB2 では表と索引の間に同一レベル・パーティション化が必要です。グローバル索引はパーティションまたは非パーティションでも作成されません。これは、グローバル索引で個々のレコードに効率よくアクセスするOLTP環境では大きな問題です。DB2 でのアプリケーション・デザイナには、パーティション化構成に索引付け方針を定義する際の柔軟性はありません16_。

追加のデータ・ウェアハウス機能: マルチテーブル・インサート

Oracle では、データ・ウェアハウス環境、特に抽出、変換およびロード（ETL）処理に役立つ 1 つの追加機能を提供します。複数表では単一の SQL 文を使用してデータを複数の表に挿入できます。これは、各表に別々な複数の SQL 文を使用するより効率的です。この機能は、データが 1 つ以上の業務系データ・ソースからターゲット表セットに送信されるデータ・ウェアハウス・システムに非常に有効です。複数表を挿入すると、行を単一 DML 文の一部として複数表に挿入する INSERT...SELECT 文の有効範囲が拡大されます。この新機能によって、実行が最適化されソース・データのスキャン処理が減少するため、パフォーマンスの著しい改善17_{がもたらされます。一時表での実体化は必} 要なく、複数文による各ターゲット表のスキャンの変わりに、処理全体で 1 回のソース・データのスキャンが行われます。マルチテーブル・インサートによって、SQL はデータ変換および条件付き処理でさらに実用性を増し、多量データの高速なロードと変換を実現します。 DB2 はマルチテーブル・インサートをサポートしません。これは、同様の処理は一連の INSERT 文としてのみ表現可能で、ソース・データ上で多数のスキャン操作を必要とするということを意味します。

パフォーマンスの管理性

Oracle と DB2 では、診断機能とセルフチューニング機能に大きな違いがあります。 Oracle Database 10g では、ユーザーは多数の内部ツールと機能でパフォーマンス監 視を簡略化し、パフォーマンス問題の検出および解決を自動化します。システム・リソースの消費の変動を活用するため、Oracle にはデータベース・パラメータを動的に調整する多数のセルフチューニング機能があります。最終的に、Oracle Database は、パフォーマンス・チューニングを目的としたインテリジェント・アドバイザリを多数提供します。このため、管理者は様々な what-if シナリオ（索引アドバイザリ、サマリー・アドバイザリ、メモリー・アドバイザリ、MTTR アドバイザリ、表/索引使用アドバイザリ）をシミュレートできます。 DB2 でもいくつかのセルフチューニング機能およびアドバイザリを提供しますが、管理者にはデータベースに関する多くの知識が求められます。たとえば、リアルタイム監視の場合、DB2 のコントロール・センターは管理者に大量の基準を提供しますが、どれが全体的パフォーマンスまたはシステム健全性の重要なインジ 16_{DB2 のパーティション化の制限については、} http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0405wilkins/index.htmlを参照。 17_{Oracleテクニカル・ホワイト・ペーパー『DSS環境におけるOracle9iのパフォーマンスと拡張性』参照。} http://otndnld.oracle.co.jp/products/iserver/oracle9i/pdf/dss_enviroment_9i.pdf

(20)

ケータかは正確に示されません。システムが遅いという曖昧な問題に直面すると、 DB2 の管理者は、原因を調べる場所の追求が必要となります。一方 Oracle では、問題の原因を分析する処理を通してアドバイス、ヘルプ、ドリルダウンが提供されるため管理者は自動的に操作を進められます。次の表に、Oracle が提供する、データベースのチューニングに使用できる情報の拡張およびチューニング処理の自動化に有用な一意の機能を示します。DB2 にはこのような機能がないため、管理者は経験に基づくアプローチを手動で行いデータベースでのパフォーマンスのチューニングが必要となります。 Oracle Database 10g DB2 パフォーマンスの管理性自動ワークロード・リポジトリ自動パフォーマンス診断自動 SQL チューニング同等の機能がないか、制限ある機能表 6: パフォーマンスおよびセルフチューニングの管理性

自動ワークロード・リポジトリ（AWR）

Oracle Databaseの自動ワークロード・リポジトリ（AWR）は永続リポジトリで、データベース処理のパフォーマンス・データおよび統計を保管します。Oracle Databaseは重要な統計およびワークロード情報のスナップショットを定期的に収集してAWRに格納します。収集および処理された統計からOracle Database 10gの診断機能のデータが提供され、事前および事後監視をサポートします18_。 DB2 は、同等のインフラストラクチャを提供していません。

自動パフォーマンス診断（ADDM）

ADDM はデータベース内にある自己診断エンジンです。このエンジンで、AWR 内の取得データを事後分析してシステムの状態を把握します。ADDM の目標は、 DB 時間を最も多く消費するシステム領域を見つけること、およびソリューションを推奨するか新規 SQL アクセス・アドバイザなど 10g アドバイザリ・コンポーネントを参照してこの時間を最小限に短縮することです。ADDM では、分析により問題の症状だけでなく根本的な原因を見つけ、システム全体に与える影響をレポートします。 ADDM は、その推奨事項およびパフォーマンスの低下やチューニングする必要がないことを示すドキュメント領域から期待される利点も数値化できます。 ADDM を使用した DB 時間の短縮により、データベース・サーバーは同じリソースでより多くのユーザーからのリクエストをサポートできるため、全体的なアプリケーションのスループットが増加します。 DB2 では、問題症状の調査、原因の特定および解決策の推奨を行う同様の機能が提供されません。 18_{AWRおよびADDMの詳細は、Oracleホワイト・ペーパー『自己管理型データベース：自動パフォーマン} ス診断』参照。

(21)

自動 SQL チューニング

Oracle Database 10gでは、SQL文のチューニングはすべて自動化されています19。自動 SQL チューニングは Automatic Tuning Optimizer に基づいています。自動チューニング・モードでの Oracle Query Optimizer は、チューニング・プロセスに必要な検査および確認作業のため、より多くの時間が費やされます。この追加時間のため、オプティマイザは時間制限に通常の処理モードでは使用できない動的サンプリングまたはパーシャル実行などの方法が使用できます。これらの方法によって、オプティマイザはコスト、選択性およびカーディナリティの独自の予測を検証します。これは、自動チューニング・モードを使用すると、SQL 文の適切なチューニング計画を生成する可能性を高めることになります。

Automatic Tuning Optimizerの機能は、新しいSQLチューニング・アドバイザを介して公開されます。Automatic Tuning Optimizerは、統計分析、SQLプロファイリング、アクセス・パス分析およびSQL構造分析などの多くの分析を行います20_。

Automatic Tuning Optimizer によって生成された推定は、SQL チューニング・アドバイザを介したチューニング・アドバイスとしてユーザーに伝達されます。アドバイスには、1 つ以上の推奨事項を含み、各提案には理由および実行時での利点が含まれます。アドバイスには、新規索引の追加、SQL 文の再書込みまたは SQL プロファイルの実行の推奨事項を含むことができます。ユーザーには、アドバイスを受け入れるオプションが与えられ、該当する SQL 文のチューニングが完了します。 DB2 には、SQL に関連する問題の簡単な判断方法はなく（使用できる方法はトレースのみ）、SQL を書き換えることのできるチューニング・ツールは提供されません。

結論

オラクル社には、最高のパフォーマンスと卓越した拡張性を備えたデータベース製品の販売に長い歴史があります。

最新リリースの Oracle Database 10g も例外ではありません。Oracle Database 10g は長年にわたる技術革新を基に構築されています。Oracle の先進性は、あらゆる種類のアプリケーションの実行および並はずれた標準への拡張を実現する新機能の導入と改善を重ね大きく前進いたします。 19_{自動SQLチューニングの詳細は、Oracleホワイト・ペーパー『自己管理型データベース：アプリケーショ} ンおよびSQLチューニング』参照。 20_{これらの分析および結果の詳細は、Oracleホワイト・ペーパー『自己管理型データベース：アプリケー} ションおよびSQLチューニング』参照。

(22)

Oracle Database と IBM DB2 UDB の技術的比較: パフォーマンスの観点 2005 年 9 月

著者: Hervé Lejeune

寄稿者: Jenny Tsai、Valerie Kane、Vineet Buch、Bill Kehoe、Sashikanth Chandrasekaran、Ray Glasstone Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口: 電話: +1.650.506.7000 ファックス: +1.650.506.7200 www.oracle.com オラクル社は、インターネット上での活動を強化するソフトウェアを提供します。 Oracle はオラクル社の登録商標です。このガイドで使用されているさまざまな製品名およびサービス名には、オラクル社の商標が含まれています。その他のすべての製品名およびサービス名は、各社の商標です。

Copyright © 2005 Oracle Corporation All rights reserved. 無断転載を禁ずこの文書はあくまで参考資料であり、掲載されている情報は予告なしに変更されることがあります。オラクル社は、本ドキュメントの無謬性を保証しません。また、本ドキュメントは、法律で明示的または暗黙的に記載されているかどうかに関係なく、商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証または条件に制約されません。オラクル社は、本書の内容に関していかなる保証もいたしません。また、本書により、契約上の直接的および間接的義務も発生しません。本書は、事前の書面による許可を得ることなく、電子的または機械的に、いかなる形態または手段によっても複製または伝送することはできません。