Oracle Database とIBM DB2 UDB の技術的比較 ...otndnld.oracle.co.jp/products/database/oracle10g/...Oracle Corporation 発行「Technical Comparison of Oracle Database vs. IBM

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

オラクル・ホワイト・ペーパー 2005年 9月


概要 ...................................................................................................................... 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


2

Oracle Corporation発行「Technical Comparison of Oracle Database vs. IBM DB2 UDB: Focus on Performance」の翻訳版です。

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

概要

このホワイト・ペーパーでは、市場をリードするデータベース管理システムの

Oracle Databaseおよび競合製品の IBM DB2 UDBのパフォーマンスと拡張性の最

も重要な相違点を考えます。

Oracle Databaseは、各種の業界標準および ISV固有のベンチマークで常に競合会

社を凌ぐ結果をだし、データベースの拡張性で業界をリードしています。

このドキュメントでは、両製品の技術的相違点について、ベンチマークおよび実

際の顧客環境における Oracleの卓越したパフォーマンスを中心に説明します。プ

ラットフォームの可用性の違いを簡単に説明し、現代の企業クラスのリレーショ

ナル・データベース・システムで最適なパフォーマンスと拡張性（並行性モデル、

索引付け、パーティション化、パラレル実行およびクラスタ化）の確保に使用さ

れる一般的な方法に重点を置いて説明していきます。最後に、両製品のパフォー

マンスの管理性を簡単に比較します。


3


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

次の表と項に 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つの製品として販売していますが、実際には違うコード・ベー

スを持つ製品のファミリーで、各製品の機能とツールは大きく異なります。


4


話を明確および簡単にするため、このホワイト・ペーパーでは 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


5


次の表に主な違いをまとめます。詳細は次項で説明します。

Oracle Database 10g DB2

マルチバージョン読込み一貫性使用できません。

読込みロックは必要ありません。内容を保証しない読込みを回避する読込み

ロックが必要です。

内容を保証しない読込みはありません。読込みロックを使用しないと、内容を保証

しない読込みが行われます。

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

ル・ロック。ロック・エスカレーションします。

読取りは、書込みをブロックしません。読取りは書込みをブロックします。

書込みは、読取りをブロックしません。書込みは読取りをブロックします。

負荷状態で、デッドロックは発生しませ

ん。負荷状態でデッドロックが発生し、深刻な

問題となる可能性があります。

表 2: 並行性モデル

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

マルチユーザー環境で発生する既知の現象を防止する能力は、データベースの実

装によって異なります。

• 内容を保証しない読込み、すなわち非コミット読込みは、コミットされ

ていないデータベースへの変更をトランザクションが読み込める場合に

発生します。

• 非リピータブル・リードは、トランザクションが以前に読み込んだデー

タを再び読み込んで、そのデータを他のコミット済トランザクションが

変更または削除した検出に発生します。

• ファントム・リードは、検索条件を満たす行セットを返す問合せをトラ

ンザクションが 2回実行し、第 1の問合せが返さなかった行を第 2の問

合せが取得できる（条件を満たす行を他のアプリケーションが挿入でき

たため）ことの検出に発生します。

Oracleのマルチバージョン読込み一貫性の実装は、常に一貫性がある正確な結果

を提供します。トランザクションがデータを更新すると、元のデータ値がデータ

ベースの UNDOレコードに記録されます。Oracleでは、読込み中の情報の変更を

防止するため、または変更されているがコミットされていない情報の問合せによ

る読込みを防止するための情報のロックではなく、UNDOレコードの現在の情報

を使用した表のデータの読込み一貫性ビューを構築し、一貫したバージョンの情

報を常に任意のユーザーに返すことができます。

DB2では、マルチバージョン読込み一貫性は提供されません。DB2の場合、アプ

リケーションに様々な分離レベルの読込みロックを使用するか、内容を保証しな

い読込みを受け入れるか、どちらか 1つの選択が必要です。読込みロックは、同

時トランザクションによる読込みデータの変更を防止します。こうした実装の場

合、読込みと書込みが混在する環境で同時要求を適切に処理するシステムの能力

が制限されることは明らかです。ユーザーは、別のワークロード環境を構築する


6


ほかありません。結果として、受入れ可能なデータの並行性および精度を得るた

めに、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.pdf3 IBM DB2 Universal Databaseの『Administration Guide: Performance, Version 8』p. 49参照。


7


つまり、同時にデータにアクセスできるユーザー数は少なく、ユーザーには待機

時間が発生することを次に示します。「行から表へのロック・エスカレーション

が発生すると、ロック・エスカレーションの処理自体にはそれほど時間がかかり

ませんが、表全体のロックにより並行性が低下します。ロック処理された表への

その後のアクセスによって、データベースの全体的パフォーマンスが低下する可

能性があります。」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.pdf5 『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.pdf6 DB2 Magazine http://www.db2mag.com/db_area/archives/1999/q2/99sp_yevich.shtml7 IBM Redbooks『DB2 UDB/WebSphere Performance Tuning Guide』p. 116参照。http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246417.pdf8 IBM DB2 Universal Database『Administration Guide: Performance, Version 8』p. 51参照


8


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.pdf10 Bloor Research 2001、Database Report p.84「DB2は従来の索引付けはBツリーに制限されます。」


9


みをサポートします。索引付けスキームの詳細は、「データ・ウェアハウス」お

よび「意思決定支援」の項に説明します。

索引構成表

索引構成表では、表の行はプライマリ・キー索引に格納されているので、プライ

マリ・キーでの完全一致検索や範囲検索を含む問合せの場合、表データに高速に

アクセスできます。索引構成表では表とプライマリ・キー索引の両方でのキー列

の重複がないため、ストレージ要件が減少します。索引値と行データのリンクに

は、行のアドレスを通常の表に格納し通常の索引で使用される 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™

は、ノード間同期のクリティカル・パスから低速のディスク処理を削除します。

時間のかかるディスク・アクセスは、必要なデータがどのキャッシュにもない場


10


合、および更新トランザクションがコミットされディスク書き込み保証を必要と

する場合にのみ行われます。この実装は、データベース・キャッシュの作業セッ

トを効果的に拡張しディスク I/O処理を減らすことで、データベース処理をスピー

ドアップします。

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

DB2はシェアード・ナッシングのアプローチを採用しています。純粋なシェアー

ド・ナッシング・アーキテクチャでのデータベース・ファイルは、マルチコンピュー

タ・システムのノードで稼働するインスタンス間でパーティション化されます。

各インスタンスまたはノードには、区分されたデータ・サブセットのアフィニティ

があります。このデータへのアクセスはすべてこの所有インスタンスによって排

他的に行われます。つまり、純粋なシェアード・ナッシング・システムは、複数

のノードにわたって処理を分配するために、パーティション化されたアクセス・

スキームまたは制限付アクセス・スキームを使用します。これは、ノードのデー

タ所有権の変更が比較的まれな環境でのみ順調に動作します。所有権が変更され

る一般的理由は、データベース再編成またはノード障害です。

シェアード・ナッシング・システムにおけるパラレル実行は、データ・パーティ

ション化スキームにそのまま基づいています。データが正確にパーティション化

されると、システムはほぼ直線的に拡張されます。

表層的には、純粋なシェアード・ナッシング・システムは分散データベースと同

じです。任意のノードで実行されるトランザクションは、アクセス対象のデータ

を所有する他のノードにメッセージを送る必要があります。また、必要な読み込

みおよび書き込み処理を行うために、他のノードで行われた処理を連携させる必

要もあります。このようなメッセージングを一般にファンクション・シッピング

と呼びます。ただし、シェアード・ナッシング・データベースは分散データベー

スとは根本的に異なり、これらは 1つのデータ・ディクショナリを使用した 1つ

の物理データベースの処理です。

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

クラスタ化構成のサポートでは、選択するアーキテクチャによってアプリケー

ションの互換性に大きな差が生じます。

Oracle Database 10g Oracle Real Application Clustersは、アプリケーションの完全互

換性を可能にする設計となっています。カスタム OLTP、DSS、または Oracle

E-Business Suiteなどのパッケージ・アプリケーションなど、すべての種類のアプ

リケーションは、単一システムからクラスタ化構成までの幅広い配置に対し、何

の変更もなく稼働できます。再設計、コードの変更、明示的なアプリケーション・

セグメント化またはデータ・パーティション化などが一切必要ありません。

これに対して、単一システムで稼働する既存の DB2データベースを、DB2 UDB

ESEのクラスタ化構成で使用するためには移行が必要です。この移行には硬直し

たデータ・パーティション化と、費用のかかる複雑な追加の開発が必要にもなり

ます。


11


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システムでは、最後にアクセスしてから一度もデータを変更していな

い場合でも、そのデータへ別のパーティションからアクセスするにはプロセス間

通信が必要となります。


12


パーティション・プローブ

DB2は、索引および表の同一レベル・パーティション化を行います。このため、

問合せの複数パーティション・プローブが行われてパーティション・プルーニン

グは生じません。たとえば、従業員表が従業員数でパーティション化されており

従業員名の索引がある場合、DB2では、従業員の検索にすべてのパーティション

の中にあるその従業員名をプローブします。名前による従業員の検索で実行され

る総処理量は、パーティションの数とともに増加します。

一方、Real Application Clustersでは、同じ問合せは単一の Bツリー従業員名索引

にある関連索引ページのみにアクセスすれば実行できます。

ロードの偏り

DB2システムでは、次の 2つの理由でロードが偏る可能性があります。第 1に、

基礎となるデータは、すべてのパーティションに均一に分散されない可能性があ

ります。特にカーディナリティの低いデータの場合に発生しやくなります。第 2

に、データ・アクセスは、基礎となるデータが均一に分散されていた場合でも、

季節的傾向または毎日の傾向によって小さな列値セットに偏る可能性があります。

Real Application Clustersにはデータを排他的に所有するノードがなく、すべての

ノードがすべてのデータにアクセスできるため、ロードの偏りは発生しません。

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

Real Application Clustersのパフォーマンスは、トランザクションをクラスタのノー

ドのサブセットにルーティングすることでさらに改善できる場合があります。こ

の場合ではデータ・アフィニティが向上し、ノード間通信が減少します。ルーティ

ングは、Oracle Net構成のサービス名を使用して簡単に実行できます。

DB2では、ルーティング・トランザクションは関数で実行されるため、トランザ

クションによってアクセスされるデータ位置の知識が必要で非常に煩雑です。ま

た、データを再分散せずにより多くの（またはより少ない）数の論理ノードでト

ランザクションを実行するため、最適なパフォーマンスが得られず、負荷の変動

に対する柔軟性も不足しています。

状況によっては、Real Application Clustersシステムを適切なミドルウェアとともに

構成して、アプリケーションのバインド値に基づく要求もルーティングできます。

たとえば、メール・サーバーはユーザーのログインに基づいた電子メール接続の

ルーティングができます。基礎となるデータもレンジまたはリスト・パーティショ

ン化によるバインド値に基づいてパーティション化すれば、最も効果的なルー

ティングが可能となります。DB2では、データの配置をユーザーが制御できない

ため、このようなことは実行できません（DB2は、ハッシュ・パーティション化

のみをサポートし、レンジおよびリスト・パーティション化はサポートしません）。


13


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

ポピュラーな 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


14


図 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ノード構成より低下する」と述べています。


15


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

データ・ウェアハウスは、問合せおよびデータ分析専用に設計された大規模デー

タベースです。これらのデータ・ウェアハウスは、長時間実行される多様な一時

問合せ用とした稼働には最適化が必要です。

こうした環境には、クエリー・リライト機能、効率的な索引付け機能、パーティ

ション化ポリシーの多様な選択肢を適切にサポートし、パラレル実行についても

様々なサポートが必要となります。繰り返しますが、Oracle Database 10gでは、他

にはない機能でこれらの要件に完全に対応できます。

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

クス

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

インデックスをサポートします。

ビットマップ・インデックスは、各キー値に対する ROWIDリストではなくビッ

トマップ（またはビット・ベクトル）を使用します。ビットマップの各ビットは、

表の 1つの行に対応します。

ROWIDのリストの場合と比べてビットマップ表現では、特にカーディナリティが

低いデータの場合、多くの領域を節約できます。ビットマップ・インデックスで

は、ブール演算子を使用して異なる索引エントリのビットマップを結合します。

ビットマップ・インデックスは、WHERE句内の複数の条件に対応する索引を効率

よくマージします。すべての条件ではなく一部を満たす行には、表自体のアクセ

ス前にフィルタが適用されます。この結果、しばしば大幅に、応答時間が短縮さ

れます。

ビットマップ・ジョイン・インデックスは、2つ以上の表の結合に関するビット

マップ・インデックスです。ビットマップ・ジョイン・インデックスを使用する

と、表の実際の結合が回避できます。または、事前に制限することにより、結合

の必要なデータ量を大幅に削減できます。問合せにビットマップ・ジョイン・イ

ンデックスを使用すると、ビット単位処理によって時間を短縮できます。

ビットマップ・ジョイン・インデックスには複数のディメンション表が含まれて

おり、単一表にビットマップ・インデックスを使用するスター型変換で必要なビッ

ト単位処理が必要ありません。各種のスター型問合せに対するパフォーマンス測

定では、ビットマップ・ジョイン・インデックスの使用による応答時間の大幅な

短縮が示されています。

DB2は動的ビットマップ・インデックスのみをサポートします。動的ビットマッ

プ・インデックスは、実行時に RIDを既存の通常の索引から取り出し、ハッシン

グまたはソートですべての RIDからビットマップを作成することにより作成され

ます。このため、動的ビットマップ・インデックスでは、Oracleの実際のビット

マップ・インデックスと同じクエリー・パフォーマンスは提供されません。動的

ビットマップ・インデックスはスター型変換ポリシーでスター型問合せを実行で

きますが、これらの索引は依然としてBツリー索引ベースなため、さらに大型のB

ツリー索引にアクセスするI/Oコストがかなり高くなります。13

13オラクル・ホワイト・ペーパー『Oracle10gの主要なデータ・ウェアハウス機能: 比較パフォーマンス分析』参照。


16


さらに、動的ビットマップ・インデックスを持つデータベースでは、Oracleの真

のビットマップ・インデックスでは可能な、領域の削減または索引作成時間の削

減ができません。

パーティション化

パーティション化により大規模なデータベース構造（表や索引など）を、さらに

小さく管理の容易なパーティションに分割できます。パーティション化は、パー

ティション・プルーニングと呼ばれる方法でパフォーマンスを向上させます。パー

ティション・プルーニングでは、必要なデータを含むパーティションのみを処理

できます。処理に必要ではないデータを含むパーティションは検索対象から排除

されます。この方法では、ディスクから取得されるデータ量を大幅に削減するこ

とで処理時間が短縮されるため、問合せのパフォーマンスとリソースの使用率が

向上します。

パーティション化を通じて複数表結合のパフォーマンスも向上します。これは

パーティション・ワイズ・ジョインという方法です。パーティション・ワイズ・

ジョインは、2つの表が結合され、その両方が結合キーに基づいてパーティショ

ン化されている場合に適用できます。パーティション・ワイズ・ジョインは、各

パーティション間での大きな結合を小さい結合として分割するため、結合全体の

終了までの時間を短縮します。これは、シリアル実行とパラレル実行の両方のパ

フォーマンスを大幅に向上します。

最後に、DML文のパラレル実行を可能にすることで、意思決定支援システムおよ

びデータ・ウェアハウスのような大規模データベースにおけるデータ処理集中型

処理の応答時間を短縮します。

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

Oracle Database 10gでは、様々な特別な状況に応じて適切に設計されたパーティ

ション化の方法をいくつか提供しています14。

• レンジ・パーティション化は、あるレンジ（範囲）の列値で行をパーティ

ションにマッピングします。範囲によるパーティション化は、特に履歴

データベースで適しています。また、データ・ウェアハウスのローリン

グ・ウィンドウ操作のサポートにも最適なパーティション化方法です。

• ハッシュ・パーティション化は、パーティション列にハッシュ関数を使

用してデータをパーティションにストライプ化します。これは、データ

の均等分散に有効な方法です。

• リスト・パーティション化は、行のパーティションへのマッピング方法

を明示的に制御できます。このためには、各パーティションの説明とし

て、パーティション列に対する離散値のリストを指定します。

• さらに、Oracleではレンジ-ハッシュとレンジ-リスト・コンポジット・パー

ティション化もサポートしています。

Oracleでは、次の 3種類のパーティション索引も使用できます。

14 Oracle Databaseのパーティション化オプションの詳細は、オラクル・ホワイト・ペーパー『Partitioning in Oracle Database 10g』参照。


17


• ローカル索引は、基礎となるパーティション表と同様のパーティション

方法でパーティション化されるパーティション表に対する索引です。

ローカル索引の各パーティションが、基礎となる表の 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


18


データの可用性も低減します。

最終的に、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


19


ケータかは正確に示されません。システムが遅いという曖昧な問題に直面すると、

DB2の管理者は、原因を調べる場所の追求が必要となります。

一方 Oracleでは、問題の原因を分析する処理を通してアドバイス、ヘルプ、ドリ

ルダウンが提供されるため管理者は自動的に操作を進められます。

次の表に、Oracleが提供する、データベースのチューニングに使用できる情報の

拡張およびチューニング処理の自動化に有用な一意の機能を示します。DB2には

このような機能がないため、管理者は経験に基づくアプローチを手動で行いデー

タベースでのパフォーマンスのチューニングが必要となります。

Oracle Database 10g DB2

パフォーマンスの管理性自動ワークロード・リポジトリ

自動パフォーマンス診断


同等の機能がないか、制

限ある機能

表 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ホワイト・ペーパー『自己管理型データベース：自動パフォーマンス診断』参照。


20



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チューニング』参照。


21


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. 無断転載を禁ずこの文書はあくまで参考資料であり、掲載されている情報は予告なしに変更されることがあります。オラクル社は、本ドキュメントの無謬性を保証しません。また、本ドキュメントは、法律で明示的または暗黙的に記載されているかどうかに関係なく、商

品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証または条件に制約されません。オラクル社は、本書の内容に関していか

なる保証もいたしません。また、本書により、契約上の直接的および間接的義務も発生しません。本書は、事前の書面による許可を得ることなく、電子的

または機械的に、いかなる形態または手段によっても複製または伝送することはできません。 Oracleは米国 Oracle Corporationおよび関連会社の登録商標です。他の製品名は、それぞれの所有者の商標です。

Documents

Oracle Database とIBM DB2 UDB の 技術的比較 ...otndnld.oracle.co.jp/products/database/oracle10g/...Oracle Corporation 発行「Technical Comparison of Oracle Database vs. IBM

Oracle Database とIBM DB2 UDB の技術的比較 ...otndnld.oracle.co.jp/products/database/oracle10g/...Oracle Corporation 発行「Technical Comparison of Oracle Database vs. IBM