oracle database 10gを使用したデータベース・パ...

Oracle Database 10gを使用したデータベース・パフォーマンス

オラクル・ホワイト・ペーパー 2003年 7月


概要 ...................................................................................................................... 3 多数の同時ユーザーの管理............................................................................... 3 共有リソースに対する内部競合の解消 ..................................................... 3 マルチバージョン読込み一貫性 ........................................................... 4 段階的に拡大しない行レベル・ロック ............................................... 5 アプリケーション・パッケージに対するロックの影響.................... 5

リソース使用率の最適化 ............................................................................. 5 Oracle Database 10g - グリッド・コンピューティング用のデータベース ........................................................................................... 5 Resource Manager ..................................................................................... 6 セルフチューニング・メモリー ........................................................... 7 セルフチューニング・チェックポイント ........................................... 8 最適化された PL/SQL............................................................................. 9

複雑なトランザクションのサポート............................................................. 10 豊富な問合せ処理テクニック ................................................................... 10 索引 ......................................................................................................... 10 索引構成表 ............................................................................................. 12 コストベースの問合せ最適化 ............................................................. 12 サマリー管理の強化 ............................................................................. 14

新しいスキーマ・オブジェクト: ソート済ハッシュ・クラスタ ........ 16 大量のデータの管理 ........................................................................................ 17 パラレル実行のサポート ........................................................................... 17 データの分割（パーティション化） ....................................................... 18 ローリング・ウィンドウ処理 ............................................................. 19 パーティション・プルーニング ......................................................... 19 パーティション・ワイズ結合 ............................................................. 20 グローバル索引 ..................................................................................... 21

高速データ移動........................................................................................... 22 プラットフォーム固有の改善......................................................................... 23

Microsoft Windowsベースのシステム ...................................................... 23 高速 Infinibandネットワークのサポート ................................................ 24

Oracle Database 10gのパフォーマンス新機能のサマリー........................... 24 結論 .................................................................................................................... 25

Oracle Database 10g を使用したデータベース・パフォーマンス

2

Oracle Corporation 発行「Database Performance with Oracle Database 10g」の翻訳版です。


概要

Oracle Databaseは、イギリス内国歳入庁（Inland Revenue）の国税管理システム、

フランス・テレコムの 10 TBデータ・ウェアハウス、重電エンジニアリング企業

ABBの大規模 SAP R/3システムなど、世界中で多数の大規模情報システムをサ

ポートしています。Oracle6におけるマルチバージョン読込み一貫性に始まり、

Oracle Databaseでは、各リリースでデータベースのパフォーマンスとスケーラビ

リティを改善するために設計された革新的な機能を発表してきました。そして、

その時点で使用可能なすべての主要プラットフォームにおける各リリースは、基

本的な変更をせずに実行できました。

Oracle Database 10gでは、Windowsおよび Linuxの 64ビット・バージョンを含む

Oracle Databaseの対応プラットフォームを拡大する一方、新しいパフォーマンス

機能とデータベース最適化により、これからもデータベース・パフォーマンスの

リーダーシップを担い続けます。このホワイト・ペーパーでは、パフォーマンス

とスケーラビリティに直接関連する Oracle Databaseの特長について、Oracle

Database 10gの新機能を中心に説明します。

データベースのパフォーマンスに関する課題は 3つのカテゴリ、すなわち、多数

の同時ユーザーの管理、複雑になるトランザクションの処理、および巨大データ

ベースのサポートに分類されます。次の項に、これらの課題について Oracle

Databaseの対応を説明します。

多数の同時ユーザーの管理

データベース・サーバーは、予測不可能な数（非常に多い場合もある）のユーザー

にサービスを提供すると同時に、あらゆる種類の問合せと更新にバッチ処理とリ

アルタイム処理の両方でユーザーが満足するパフォーマンスを提供するという課

題に直面しています。Oracle Database 10gの機能によりこれらの要件を満たし、優

れたスケーラビリティと最適なリソース使用率を常に保証します。

共有リソースに対する内部競合の解消

Oracle Databaseの基本アーキテクチャでは、多数の同時トランザクションを非常

に効率よく管理します。これを可能にするテクノロジ（マルチバージョン読込み

一貫性、および特許取得済の段階的に拡大しない行レベル・ロック）により、Oracle

Databaseは、アプリケーションに接続するユーザー数およびトランザクション量

が増加しても、一貫したパフォーマンスを提供できます。


3


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

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

装によって異なります。

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

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

生します。

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

の再読込みを行ない、他のコミット済トランザクションがそのデータを変

更または削除したことを検出する場合に発生します。

• 仮読込みは、検索条件を満たす行セットを返す問合せをトランザクション

が 2回実行し、第 1の問合せが返さなかった行を第 2の問合せが取得でき

る（条件を満たす行を他のアプリケーションが挿入できたため）ことを検

出する場合に発生します。

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

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

の値がデータベースの UNDOレコードに記録されます。Oracle Databaseはこの値

を使用して表のデータの読込み一貫性ビューを構築し、あるバージョンの情報（非

コミット・トランザクションの開始時に一貫している）を常に任意のユーザーに

返すことができます。

図 1: トランザクションおよびマルチバージョン読込み一貫性（赤い線はトランザクション 10023に示されるデータ値を表す）

このため Oracle Databaseは、同時問合せおよび更新処理が行われる複合ワーク

ロード環境を完全にサポートします。Oracle Databaseでは、書込み機能が読込み

機能をブロックすることなく、また読込み機能が書込み機能をブロックすること

もありません。非ブロック式のマルチバージョン読込み一貫性により、ユーザー


4


への一貫した問合せ結果の提供と、同時更新処理中のパフォーマンスの維持が同

時に実現します。

段階的に拡大しない行レベル・ロック

行レベル・ロックでは、詳細なロック管理に最高レベルのデータ並行性が実現し

ます。また、表内の行を更新するユーザーまたは処理はその行のみをロックする

ので、その他すべての行は同時処理で使用可能な状態で残されます。

Oracle Databaseは、行レベル・ロックをデフォルトの並行性モデルとして使用し

ます。Oracle Databaseは、ロック情報を行データとともに格納するため、データ

ベース内の行または索引エントリと同数の行レベル・ロックを持ち、データ並行

性が制限されません。このため、Oracle Databaseはロックを段階的に拡大する必

要がなく、Oracleユーザーはロックの段階的拡大によるデッドロック状況に陥る

ことがありません。

アプリケーション・パッケージに対するロックの影響

データベース内のロック構造は、そのデータベースを使用するすべてのアプリ

ケーションに透過的に適用されます。このようなロック構造における弱点の対処

には、アプリケーション・コードの追加が必要です。この問題は、強力なマルチ

バージョン読込み一貫性モデルにより全アプリケーションにスケーラビリティ上

のメリットを提供する Oracle Databaseでは発生しません。SAPでは対照的に、使

用可能なロック数に対する制限や、DB2で発生の可能性があるデッドロックに対

処するため、アプリケーション中間層に専用の機能を実装する必要があります。

SAP R/3、PeopleSoftおよび Siebelなどのほとんどの基幹業務アプリケーション・

パッケージがそのベースの大部分を Oracle Database上に配置している主な理由は、

Oracle Databaseの並行性制御アーキテクチャにあります。

リソース使用率の最適化

Oracle Database 10g - グリッド・コンピューティング用のデータベース

グリッド・コンピューティングは、コンピューティングの経済性に画期的な変革

をもたらします。最高レベルとして、グリッド・コンピューティングの基本的概

念は、データの場所、リクエストを処理するコンピュータかの選択をユーザーが

考える必要がないことです。コンピューティングは、電力グリッド（送電網）や

電話網に似た生活必需品と考えるべきです。すなわち、グリッド・コンピューティ

ングでは、ハードウェアとソフトウェア・リソースの供給が一元化されます。厳

密な技術的観点からこの供給は、パフォーマンスが向上しないかも知れません。

しかし、ビジネス観点からは、ユーザーによりよいパフォーマンスを提供します。

同じリソースを使用する状況では、業務の優先度やニーズに基づいた適切なアプ

リケーションにリソースが供給されることで、ユーザーのパフォーマンスは向上

します。


5


グリッド・コンピューティングの概念は、オラクル社が長年にわたって開発して

きた機能やテクノロジと同一線上にあり1、Oracle Database 10gは、今後のグリッ

ド・コンピューティング・テクノロジの実現に向けた最適なアーキテクチャを備

えています。

最適なリソース使用率をさらに保証するため、Oracle Database 10gには、ほとんど

の構成を自動的かつ動的に管理し、使用可能なリソースをチューニングする強力

な組込みツールとセルフ管理機能があります。

Resource Manager

パフォーマンスは、全データベースの要件ですが、その要件は、データベースに

アクセスするアプリケーションの種類によって大きく異なります。

たとえば、ビジネス・アプリケーション・パッケージ（ERP）をサポートするデー

タベースの要件は、銀行業務アプリケーションの要件とはまったく異なります。

トランザクションが短く予測可能という本質的傾向がある銀行業務アプリケー

ションをサポートするデータベースとは異なり、ERPデータベースの場合は、短

いトランザクションと実行時間の長いバッチ・ジョブの両方が含まれるため、ワー

クロードの変動が激しくなります。このようなシステムでは、バッチ・ジョブで

使用されるリソースを制限してオンライン・ユーザーへの応答時間の短縮が目標

となります。これは、データ・ウェアハウス・アプリケーションの要件とも大き

く異なり、データ・ウェアハウス・アプリケーションでは、データベースが大量

のデータを定期的にロードすることを目的に設計されており、実行時間の長い非

定型問合せ向けに最適化されています。

Resource Managerは、データベース管理者が指定したリソース・プランに基づい

てユーザー間またはアプリケーション間でリソースを割り当てます。リソース・

プランは、様々なアクティブ・ユーザーまたはアプリケーション間でのリソース

の配布方法を定める指示で構成されます。ユーザーまたはアプリケーションは、

それぞれのリソース要件と業務の優先度に基づいて異なるリソース・コンシュー

マ・グループに分類されます。

データベース・リソース・マネージャを使用すると、管理者は次の制御が可能に

なります。

• 各ユーザー・グループに割り当てられる処理能力の割合

• 各ユーザー・グループに許可される同時アクティブ処理の最大数

• 必要に応じて問合せの優先順位を変更するポリシー

• 各グループが行う処理に許可される最大予測実行時間

• 各ユーザー・グループが並列性を使用できる範囲

1 オラクル社とグリッド・コンピューティングの詳細は、2002年 11月のオラクル・ホワイト・ペーパー

『Oracle and the Grid』を参照


6


リソース・プランの例を図 2に示します。このプランでは、データ・ウェアハウ

ス環境で見られるような 3つのリソース・コンシューマ・グループを定義してい

ます。

リソース・コンシュー

マ・グループ

処理能力の割合（%）

同時アクティ

ブ処理の最大数

リソース・コ

ンシューマ・

グループの切替え

最大予測実行時間

最大並列度

高優先度 60

中優先度 30 15 低優先度への

切替え時間 = 1時間

0

低優先度 10 5 10時間

図 2: リソース・プランの例

重要と考えられる処理は、高優先度リソース・コンシューマ・グループ内で実行

されます。このグループは CPUリソースの 60%を受け取り、このグループが行う

全処理は並列に実行できます。

その他の処理は、すべて中優先度グループ内で開始されます。このグループは処

理能力の 30%を受け取り、同時に可能な問合せは 15に制限されています。この制

限に達すると、受け取られた問合せはキューに入れられます。処理の並列実行は

不可能です。処理が 1時間以内に完了しない場合、または実行時間が 1時間を超

えると予測される場合、その処理は低優先度グループに自動的に切り替えられま

す。

低優先度グループは処理能力の残り 10%を受け取り、同時に可能な処理は 5つま

でに制限されます。そして、実行時間が 10時間を超えると予測される重要でない

処理は、開始を許可されません。

データベース・リソース・マネージャの主な利点は次の 2つです。

• ハードウェア・リソースの最適な使用を保証すると同時に、システムが過

剰使用されないようワークロードを管理します。

• ハードウェア・リソースを各ユーザー・グループに適切に割り当てます。

セルフチューニング・メモリー

システム・リソースの消費の変動を活用するため Oracle Databaseには、データベー

ス・パラメータを動的に調整する多数のセルフチューニング機能があります。

セルフチューニング SGA

システム・グローバル領域（SGA）は、すべてのユーザーに共有されるメモリー

領域で、特定の Oracleデータベース・インスタンスのためのデータと制御情報を

含みます。SGAは、メモリー・コンポーネントで内部的に分割されています。そ

れぞれのコンポーネントは、最後に使用されたデータのブロックを格納するリク

エストや、データベースの変更を記録するリクエストなど、メモリー割当てリク

エストの各カテゴリを満たすためのメモリーのプールを表します。


7


最適なパフォーマンスのために、これらのキャッシュのサイズをチューニングす

ることは、アドバイス・メカニズムがあっても簡単ではありません。コンポーネ

ントのサイズが小さいため、メモリー割当てが失敗する、サイズが大きいために、

使用できたメモリーを他のキャッシュが無駄にするなどのリスクが常に存在しま

す。

Oracle Database 10gではセルフチューニング SGAが導入され、管理者は SGAの合

計サイズのみの指定で、SGAプール間の最適なメモリー配分を Oracle Databaseへ

内部的に決定できます。この新機能は、各種 SGAキャッシュに対するメモリー配

分は、ワークロードの変化に合せて時間とともに動的に変化します。

SQL 実行メモリーの自動管理

Oracle Databaseには、各問合せに対してランタイム・メモリーを動的に割り当て

る自動メカニズムもあります2 。ランタイム・メモリーとは、問合せ実行中にソー

トやハッシングなどの目的で割り当てられるメモリー領域のことです。多くの

データ・ウェアハウス環境では、データ・ウェアハウス・サーバーの 70%以上の

物理メモリーがランタイム・メモリーに割り当てられる場合があります。

この機能により、データベース管理者は作業領域のサイズ変更に関するポリシー

を指定できます。自動モードでは、メモリー集中型処理に使用する作業領域を、

メモリー使用量の大小に応じて自動的かつ動的に調整できます。

SQL実行メモリーの自動管理には、意思決定支援ワークロードまたは複雑な問合

せの複合ワークロードに対してパフォーマンスおよびスケーラビリティ上の利点

がいくつかあります。複雑な問合せとは、ランタイム領域の大部分がソートやハッ

シュ結合などのメモリー集中型処理に使用される作業領域専用となることです。

自動管理により、全体的なシステム・パフォーマンスが最大化され、使用可能な

メモリーが問合せ間でさらに効率よく割り当てられるため、スループットと応答

時間の両方が最適化します。特に、メモリー使用率の改善は、高負荷時のスルー

プットの向上につながります。

セルフチューニング・チェックポイント

チェックポイントは、メモリーで変更されたデータをデータベースのデータ・ファ

イルと同期化する手段です。Oracle Databaseでは、チェックポイント間で変更さ

れたデータをデータ・ファイルに定期的に書き込むことにより、十分な量のメモ

リーが使用できることを保証し、受信操作にフリーなメモリーを探すパフォーマ

ンスを改善します。

Oracle Database 10g以前、管理者はチェックポイント関係の初期化パラメータ

（FAST_START_MTTR_TARGET）の値を設定することで、推定クラッシュ・リカ

バリ時間（MTTR）を指定しました。管理者は、MTTRアドバイス機能を使用し

て、様々なMTTR目標値で実際に増加する書込み数の予測ができます。Oracle

Database 10g以降は、データベースのチェックポイントをセルフチューニングし、

通常のスループットにあまり影響を与えず良好なリカバリ時間を達成できます。

自動チェックポイント・チューニングで、Oracle Databaseは I/O使用率の低い時間

を活用したメモリーで変更されたデータをデータ・ファイルに書き出すので、ス

2 Oracle9i以降


8


ループットに悪影響を与えません。したがって、管理者がチェックポイントに関

するパラメータを設定していない場合や、このパラメータが非常に大きな値に設

定されている場合でも、リーズナブルなクラッシュ・リカバリ時間を達成できま

す。

最適化された PL/SQL

PL/SQLは、SQLを拡張したオラクル社の手続き型プログラミング言語です。SQL

の簡便性と柔軟性を、構造化プログラミング言語の手続き型の機能性と組み合せ

ます。PL/SQLコードは、データベースに一元的に格納できます。

PL/SQLストアド・プロシージャを使用することにより、パフォーマンスが向上し、

メモリー使用率が最適化されます。その理由として、次の点があげられます。

• アプリケーションとデータベース間のネットワーク・トラフィックが減少

します。

• データベースでは、プロシージャのコンパイル済の形式を容易に利用でき

るため、実行時のコンパイルが必要ありません。

• プロシージャの 1つのコピーを、複数のユーザーがメモリー内で共有でき

ます。

Oracle Database 10gは、PL/SQLで大幅なパフォーマンス改善を達成しています。

PL/SQLコンパイラは書き換えられて計算集中型の PL/SQLプログラムの効率を高

め、最適化を促進するフレームワークを提供しています。新しいコンパイラには、

多くのプログラムのパフォーマンスを実質的に改善する、より洗練されたコー

ド・ジェネレータとグローバル・コード・オプティマイザがあります。その結果、

特に計算集中型の PL/SQLプログラムのパフォーマンスが向上し、純粋な PL/SQL

プログラムでは、Oracle9i Databaseリリース 2と比較して約 2倍のパフォーマンス

の向上を実現しました。また、PL/SQL実行可能コードのサイズは最大 30%減少し、

動的スタック・サイズは 2分の 1に縮小しました。これらのサイズ減少により、

PL/SQLプログラムのメモリーに対する圧力が低下したため、全体的パフォーマン

ス、スケーラビリティ、信頼性が向上し、その結果 Oracleシステム全体のパフォー

マンスが向上します。

パフォーマンスの管理に役立つ Oracle Database 10gの新機能には、PL/SQLコンパ

イル時警告もあります。この機能は、構文は正しいが、実行時低いパフォーマン

スの可能性がある PL/SQL構文のクラスを自動的に指摘します。

Oracle Database 10gでは、Oracle9i Databaseに存在していた PL/SQLのネイティブ

実行に対するいくつかの制限もなくなっています。PL/SQLプログラムのネイティ

ブ実行により、PL/SQLモジュールをネイティブ・コードにコンパイルでき、これ

にはいくつかのパフォーマンス上のメリットがあります。第 1に、バイト・コー

ドの解釈に付随するオーバーヘッドがなくなります。第 2に、制御フローと例外

処理は解釈されたコードよりネイティブ・コードがはるかに高速です。結果、

PL/SQLプログラムの実行速度が大幅に向上します。


9


複雑なトランザクションのサポート

豊富な問合せ処理テクニック

Oracle Databaseには、非常に複雑な環境の要件に対処する多様な問合せ処理テク

ニックが用意されています。次のような洗練されたテクニックがあります。

• あらゆる種類のアプリケーション向けに調整された索引付けテクニック

とスキーマ・オブジェクト

• 効率的なデータ・アクセスのためのコストベースの問合せ最適化

• サマリー管理機能

索引

索引は、データへのより高速なパスを提供するために作成されるデータベース構

造です。索引を使用するとディスク I/O処理が大幅に削減されるので、データ取

得のパフォーマンスが向上します。Oracle Databaseは、業界最多の索引付け方式

をサポートします。

• Bツリー索引

• Bツリー・クラスタ索引

• ハッシュ・クラスタ索引

• 逆キー索引

• ビットマップ索引

• ビットマップ結合索引

• ファンクション・ベース索引

• ドメイン索引

索引の有無は、アプリケーションに対して完全に透過的です。

Oracle Databaseは静的なビットマップ索引3 およびビットマップ結合索引4 をサ

ポートします。これらの索引を使用すると、データ・ウェアハウス環境で一般的

なロードおよび問合せ処理でパフォーマンスが大幅に向上します。このような索

引付け方式により、Oracle Databaseは IBM DB2やMicrosoft SQL Serverよりもは

るかに優れたデータベースとなっています。この方式については、次の項で詳し

く説明します。

ビットマップ索引およびビットマップ結合索引

ビットマップ索引は、各キー値に対して、表の行の格納場所のリストではなくビッ

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

が表中の行に対応し、表の行にキー値が含まれる場合にビットが設定されます。

3 Oracle7.3以降 4 Oracle9i以降


10


行の格納場所のリストを使用する場合と比べて、ビットマップ表現を使用すると、

カーディナリティが低いデータの場合は特に多くの領域を節約できます。図 3の

表では、索引のカーディナリティが変化する場合のビットマップ索引と従来の B

ツリー索引の各サイズを比較しています。

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

マップを結合します。ビットマップ索引は、WHERE句内の複数の条件に対応する索引を効率よくマージします。すべての条件ではなく一部を満たす行には、表自

体のアクセス前に、フィルタが適用されます。この結果、応答時間が短縮され、

場合によっては大幅な短縮が可能です5 。

ビットマップ結合索引は、2つ以上の表の結合に関するビットマップ索引です。

ビットマップ結合索引を使用すると、表の実際の結合を回避できます。または、

制限を事前に実行することにより、結合の必要なデータ量を大幅に削減できます。

問合せでビットマップ結合索引を使用すると、ビット単位処理を通じた問合せ時

間が短縮できます。

ビットマップ結合索引には、複数のディメンション表が含まれており、単一表に

対するビットマップ索引を使用するスター型変換で必要となるビット単位処理が

不要になります。各種のスター型問合せに対するパフォーマンス測定では、ビッ

トマップ結合索引を問合せで使用すると応答時間が大幅に短縮されることが示さ

れています。

カーディナリティ Bツリー 6 ビットマップ 2 比率

1000000 14.33 23.9 0.60

500000 15.29 12.35 1.24

250000 15.27 8.46 1.80

100000 15.21 5.25 2.90

40000 15.06 3.76 4.01

10000 14.34 2.99 4.08

1000 14.26 2.25 6.34

100 13.40 1.38 9.71

25 13.40 1.31 10.23

10 13.40 1.11 12.07

5 13.40 0.78 17.18

4 13.40 0.67 20.00

2 13.40 0.37 36.22

図 3: 索引サイズの比較: ビットマップ対 Bツリー

5 2001年 9月のオラクル・ホワイト・ペーパー『Key Data Warehousing Features in Oracle9i: A Comparative

Performance Analysis』を参照。 http://otn.oracle.com/deploy/performance/content.html

6 単位はMB


11


索引構成表

索引構成表7 では、索引付け情報とデータが一緒に格納されているので、プライ

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

アクセスできます。索引構成表を使用すると、表とプライマリ・キー索引の両方

でのキー列の重複がないので、ストレージ要件が減少します。通常の索引では、

索引値と行データをリンクするため、行のストレージ位置での追加ストレージが

必要ですが、索引構成表では、これが不要になります。したがって、データを取

り出すために必要なアクセス時間が減少するため、パフォーマンスが向上します。

索引構成表は、パーティション化やパラレル問合せをはじめとするすべての表機

能がサポートします。Oracle Database 10gでは、索引構成表に使用可能なパーティ

ション化オプションの選択肢としてリスト・パーティション化を含むように拡張

されました。

コストベースの問合せ最適化

問合せ（クエリー）の最適化は、リレーショナル・データベース、特に複雑な SQL

文の実行パフォーマンスにとって非常に重要です。Oracle Databaseでは、コスト

ベースの最適化戦略8 が使用されます。コストベースの最適化では、1つの問合せ

に複数の実行計画が生成され、各計画について予想コストが計算されます。そし

て、問合せオプティマイザにより、最良の計画すなわち予想コストが最も低い計

画で選択されます。この問合せ最適化プロセスは、アプリケーションとエンドユー

ザーに対して完全に透過的です。

アプリケーションは非常に複雑な SQLコードを生成するので、良好なパフォーマ

ンスの保証に、問合せオプティマイザは、高度に洗練された堅牢なことが必要で

す。Oracle Databaseのコストベースのオプティマイザは、そのコスト・モデルの

正確性と完全性、および特定の問合せに指定されたデータに最も効率的にアクセ

スするテクニックとメソッドの結果として、優れた実行計画を生成します9 。

SQL 変換

オプティマイザは、オリジナル SQL文を同じ結果で返しますが、もっと効率的に

処理できる SQL文に変換できます。ビューのマージや条件プッシュのような経験

則による問合せ変換は、可能なかぎり適用されます。これらは、スキャン、結合、

集計するデータ量を大幅に減らすことにより、常に問合せのパフォーマンスを改

善するからです。Oracle Databaseでは、コストベースの問合せ変換も適用されま

す。この場合、マテリアライズド・ビュー・リライトやスター型変換のような各

種テクニックによる問合せの変換には、オプティマイザのコスト予測に基づいて

行われます。

7 Oracle9i Database以降で使用可能 8 ルールベースのオプティマイザに対するサポートは Oracle Database 10gで廃止 9 Oracle Databaseにおける問合せ最適化の詳細は、2002年 2月のホワイト・ペーパー

『Query Optimization in Oracle9i』を参照。


12


実行計画の選択

実行計画は、SQL文処理の実行手順をすべて記述したものです。たとえば、どの

ような順序で表にアクセスするか、どのように表を結合するか、索引を介して表

にアクセスするかなどです。

Oracle Databaseには、データベース構造、パーティション化と索引付けのテクニッ

ク、結合方法について、非常に豊富な選択肢が用意されています。パラレル実行

アーキテクチャでは、実際、どのような SQL文も任意のパラレル度で実行できま

す。また、コストベースのオプティマイザは、ユーザーにより提供され、SQL文

に注釈として置かれている最適な示唆のヒントを考慮します。

結果として、1つの SQL文についてオプティマイザにより多数の異なる計画が生

成されることがあります。同じ結果を生成しながら、データへのアクセスや処理

に使用できるアクセス・パス、結合方法、結合順序の組合せに様々なバラエティ

があるからです。

コスト予測

実行計画のコストを予測し、最低コストの計画を選択するため、オプティマイザ

では、SQL文の実行を構成する個々の操作のコスト予測が使用されます。この予

測はできるかぎり正確である必要性から、Oracle Databaseのデータ構造とアクセ

ス方式についての深い知識を取り込んだ非常に高度なコスト・モデルを、オブジェ

クト・レベルの統計やシステム統計およびパフォーマンス情報と統合します。

オブジェクト・レベルの統計では、Bツリー索引のレベル数や、表における列

の個別値の数（カーディナリティ）など、データベース内のオブジェクト

（表、索引、マテリアライズド・ビュー）に関する情報が収集されます。

列データの分布の正確な予測を得るために、データ値ヒストグラムも使用

できます。

システム統計は、標準的なワークロードのアクティビティ中に収集されたハー

ドウェア・コンポーネント（プロセッサ、メモリー、ストレージ、ネット

ワーク）のパフォーマンス特性を示します。

統計とパフォーマンス情報を収集するプロセスは、高い効率と高度な自動化の両

方を必要とするので、このプロセスを自動化し、高速化する機能が多数使用され

ています。

Oracle Database 10gでは、自動統計収集が導入されています。古い統計しかないオ

ブジェクトや統計のないオブジェクトが自動的に分析されるので、管理者は、分

析する必要性の有無を判断する作業から解放され、必要に応じた分析ができます。

統計収集の完全自動化により、SQL実行パフォーマンスが大きく改善されます。

Oracle Databaseは、サンプリングで関連するデータのサンプルを調べることによ

り、統計を収集します。サンプリングは問合せと同じトランザクションで発生す

る静的とすること、あるいは動的とすることもできます。また、パラレル化と組

み合せた使用ができます。Oracle Databaseの統計収集ルーチンは、対象となる表

のデータ特性に基づいて、適切なサンプリング割合とパラレル度を自動的に決定

します。また、Oracle Databaseは、ヒストグラムを必要とする列、分布の正確な

予測に使用される列データを絶対的に決定します。


13


ユーザーは、オプティマイザのアプローチと目標を設定することにより、オプティ

マイザの選択に関与できます。Oracle Databaseには、2つのオプティマイザ・モー

ドがあります。第 1のモードは、問合せの最初の n行を返す時間を最小にします。

このモードは、最初の行を返すレスポンス時間を最良にするために運用システム

のようなアプリケーションに対応しています。第 2のモードは、問合せからすべ

ての行を返す時間を最小にし、最良のスループットを目標とする場合に使用され

ます。

ランタイム動的最適化

SQL実行をすべて事前に最適な計画はできないので、Oracle Databaseは、事業の

優先度と現在のデータベース・ワークロードおよびハードウェア能力に基づくラ

ンタイム動的調整を、問合せ処理戦略に取り入れています。このような動的最適

化の目標は、それぞれの問合せが理想的な量の CPUまたはメモリー・リソースを

獲得できない場合でも最適なパフォーマンスを達成することにあります。

Oracle Databaseは、問合せのパラレル度を自動的に調整し、個々の問合せに対し

て適切な量のメモリーを動的に割り当てます。また、Resource Managerを使用し、

リソース・プランによる指示に基づき、各問合せにリソースを割り当てます。

その結果、問合せオプティマイザにより使用されるコストとサイズ・モデルの正

確性が向上します。これは、オプティマイザがより効果的な実行計画を生成し、

問合せパフォーマンスの改善に役立ちます。

サマリー管理の強化

マテリアライズド・ビュー

マテリアライズド・ビューは、データの要約、事前計算、複製、配布に使用でき

るスキーマ・オブジェクトです。マテリアライズド・ビューは、データ・ウェア

ハウス、意思決定支援、分散コンピューティング、モバイル・コンピューティン

グなど、様々なコンピューティング環境に適しています。たとえば、データ・ウェ

アハウス・アプリケーションでは、月、製品、地域のような一般的ディメンショ

ンで詳細データを要約する問合せの発行がよくあります。マテリアライズド・

ビューは、そのような複数のディメンションと要約計算を格納するメカニズムを

提供します。コストベースのオプティマイザでマテリアライズド・ビューを使用

することにより、問合せパフォーマンスが劇的に向上します（クエリー・リライ

トに関する次の項参照）。

マスター表のデータが変更されたときマテリアライズド・ビューは、リフレッシュ

の必要があります。完全リフレッシュでは、マテリアライズド・ビュー問合せを

再実行して、マスター表からマテリアライズド・ビューの内容を完全に再計算し

ます。完全リフレッシュは非常に時間がかかるので、多くのデータ・ウェアハウ

ス環境では、運用目標に合せる高速な増分リフレッシュが必要です。

高速リフレッシュでは、マスター表にある新規データや更新データを考慮し、様々

な増分アルゴリズムを使用し、マテリアライズド・ビューを更新します。Oracle

Databaseは、UPDATE（すなわちマスター表に対して直接実行されるロード操作）

のような従来の DML操作時に使用される従来の高速リフレッシュ・メカニズム、

およびベース表のパーティションでのメンテナンス操作または DML変更後の


14


パーティション認識高速リフレッシュ・メカニズムを提供しています。たとえば、

ベース表のパーティションで切捨てまたは削除が発生した場合、マテリアライズ

ド・ビューで影響を受ける行が識別され、削除されます。

Oracle Database 10gでは、高速リフレッシュ・メカニズムに対するサポートをさら

に広範囲のマテリアライズド・ビューに拡張しています。このリリースでは、パー

ティション認識高速リフレッシュは、ベース表がリスト・パーティション化され

ているマテリアライズド・ビュー、またはパーティション・マーカーとして ROWID

を使用するマテリアライズド・ビューに拡張されました。

Oracle Database 10gでは、機能依存性およびクエリー・リライトを使用しても高速

リフレッシュを拡張します。ユーザーがディメンションの階層に沿ってマテリア

ライズド・ビューを定義している場合、Oracle Databaseは、ベース表で影響を受

けるパーティションに対応する、マテリアライズド・ビューで影響を受けるパー

ティションを検出し、他のマテリアライズド・ビューまたはベース表に対する効

率的なリフレッシュ式を生成します。

クエリー・リライト

クエリー・リライトは、マテリアライズド・ビューからデータをフェッチするこ

とにより、さらに高速で実行するため表とビューに関連したユーザー問合せを変

換する問合せ最適化技法です。

詳細レコードのサマリーを要求する問合せの場合、問合せオプティマイザは、そ

の要求を満足するために既存のマテリアライズド・ビューを使用できるか、そし

て使用すべきかを自動的に判断します。オプティマイザは、基礎になる表ではな

くマテリアライズド・ビューを使用するように、問合せを透過的にリライトしま

す。マテリアライズド・ビューは、実行前にデータベース上に結合と集計操作を

事前計算し、その結果をデータベースに格納しているため、問合せパフォーマン

スが劇的に向上します。マテリアライズド・ビューを使用するように問合せをリ

ライトして、問合せの発行ごとに詳細レコードを合計する作業がなくなります。

できるかぎり広範な問合せのセットに対してマテリアライズド・ビューを使用す

るために、Oracle Databaseにはマテリアライズド・ビューをリライトする非常に

強力なテクニックのセットが用意されています。

Oracle Database 10gでは、クエリー・リライトに複数のマテリアライズド・ビュー

を使用できます。したがって、より多くの問合せをクエリー・リライトに使用で

きるため、問合せのレスポンス時間の向上が見込まれます。

サマリー・アドバイザ

Oracle Databaseのサマリー・アドバイザを使用すると、管理者は時間のかかる

チューニングおよび診断作業から解放され、様々な仮定シナリオのシミュレー

ションができます。

サマリー・アドバイザは、スキーマ特性と過去のワークロード履歴に基づいてマ

テリアライズド・ビューに分析およびアドバイザ機能を提供するファンクション

とプロシージャを集めたものです。これらのファンクションとプロシージャは、

ユーザーが自分のスキーマで使用できる多数のマテリアライズド・ビューから選

択する際に役立ちます。


15


サマリー・アドバイザは特に、マテリアライズド・ビューのサイズの予測、収集

または推定されたワークロード情報に基づくマテリアライズド・ビューの推奨、

および収集されたワークロードに基づくマテリアライズド・ビューの実際の使用

率の報告に使用できます。

新しいスキーマ・オブジェクト: ソート済ハッシュ・クラスタ

Oracle Databaseには、表データの格納方法として、クラスタやハッシュ・クラス

タなどのオプションの方法がいくつかあります。Oracle Database 10gでは、ソート

済ハッシュ・クラスタと呼ばれる新しいオプションが追加されました。このオプ

ションは、非常に高いデータ挿入率および取得率を必要とするシステムに特に適

しています。

この表構造は、データを挿入順に処理する First-in First-out（FIFO）タイプのデー

タ処理アプリケーションを効率よくサポートします。このようなアプリケーショ

ンは通常、通信環境や製造環境で使用されます。この良い例が、通信スイッチ用

の呼詳細記録（CDR）と呼ばれるデータ構造です。発呼用の電話番号は固定され

ていますが、各電話番号からスイッチを通じることができる呼の数は無制限です。

請求および監査に、それぞれの呼を記録し、その発呼元と関連付ける必要があり

ます。呼は、スイッチの通過に格納後、顧客への請求が行われるときに FIFO順で

取得されます。

これを次の図に示します。

図 4: 呼詳細記録のデータ構造

このデータを 2つの標準表で取得することも可能ですが、ソート済ハッシュ・ク

ラスタの方が優れたソリューションとなります。任意の加入者に対して呼記録の

ソート済リストへの安価なアクセスを提供でき、請求アプリケーションがソート

済リストを参照しながら FIFO方式で呼記録を読み込むためです。


16


データが常に挿入順で使用されるすべてのアプリケーションは、この新しいタイ

プの最適化された表構造を使用することにより、パフォーマンスを大幅に改善で

きます。

大量のデータの管理

大量のデータを管理するデータベース・システムは、Oracleの顧客に多数見られ

ます。データベース・サイズは、Oracle Databaseにとって問題ではありません。

Oracle Database 10gは、最大 8エクサバイト（800万テラバイト）のデータを持つ

極めて大きなデータベースをサポートできます。

Oracle Databaseは、このような大量のデータの作成、配置、管理、使用を支援す

る強力なメカニズムを備えているだけでなく、すべてのタイプでデータベース操

作のパフォーマンスを大幅に向上させています。

パラレル実行のサポート

パラレル処理では、1つ以上のタスクの実行に必要な処理を、同時に実行中の複

数のプロセッサおよび I/Oリソース間で分散するため、追加のハードウェア・リ

ソースを最適に使用でき、システムのスケーラビリティが確保されます。

Oracle Databaseが複数の SQL文をパラレルに実行すると、複数のプロセスが同時

に協調動作して単一の SQL文を実行します。Oracle Databaseでは、1つの文の実

行に必要な処理を複数のプロセス間で分割することで、単一のプロセスでの場合

よりも時間を短縮できます。

Oracle Databaseは、単一システムの複数プロセッサ間、および Real Application

Clustersを使用した単一クラスタの複数ノード間のパラレル処理をサポートしま

す。

Oracle Databaseは、次を含む、あらゆるタイプの処理に対してパラレル実行をサ

ポートします。

• 管理処理: データのロード、表および索引の作成、一時表の作成、パーティ

ションのメンテナンス、バックアップおよびリカバリ、複製

• エンドユーザー処理: 問合せ、SELECT文の副問合せ、挿入、更新、削除、

OLAP分析

最適なスループットとシステム使用率を常時保証するため、Oracle Databaseでは、

業界をリードするパフォーマンスの提供だけでなく、独自の適応力および動的特

性も備えたパラレル実行アーキテクチャを提供します。

Oracle Databaseの各インスタンスでは、パラレル実行サーバーのプールを提供し

ます。使用可能なパラレル実行サーバーの合計数は、データベース・システムに

より動的かつ自動的に調整されます。インスタンスが同時に実行するパラレル処

理の数が大きく変化する場合、Oracle Databaseはプール内のパラレル実行サーバー

の数を自動的に変更します。

処理に使用されるパラレル実行サーバーの数が、並列度（DOP）になります。DOP

は、使用可能なハードウェア・リソース（システムに過負荷をかけないため）、

システムの実際のワークロード、対象オブジェクトのパラレル特性、および要求


17


に対する業務の優先度に基づいて問合せ実行時に決定されます。各処理に対して、

Oracle Databaseはこれらの要素に基づいて並列度を自動的かつ動的に調整し、シ

ステムのリソースを最適に使用します。

データの分割（パーティション化）

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

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

なるアプリケーション・シナリオに対応する表パーティション化方法を複数用意

しています10 。

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

パーティションにマッピングします。レンジ別のパーティション化は、特

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

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

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

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

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

• リスト・パーティション化は、パーティションに行をマッピングする方法

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

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

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

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

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

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

法を使用してパーティション化されるパーティション表に対する索引で

す。ローカル索引の各パーティションが、基礎になる表の 1つのパーティ

ションのみと 1対 1で対応します。

• パーティション化されたグローバル索引は、表とは異なるパーティション

化キーを使用してパーティション化されるパーティション表または非

パーティション表に対する索引です。

• パーティション化されていないグローバル索引は、非パーティション表に

対する索引と本質的には同じであり、索引構造がパーティション化されま

せん。

Oracle Databaseでは、パーティション/非パーティション索引および表を任意に組

み合せることができ、パーティション表でパーティション索引と非パーティショ

ン索引の使用や、非パーティション表でパーティション索引と非パーティション

索引の使用が可能です。

パーティション化は主に管理の容易さと可用性を考慮した機能ですが、パフォー

マンス面のメリットも多数あります。

10 Oracle Databaseのパーティション化オプションの詳細は、2001年 5月のオラクル・ホワイト・ペー

パー『Oracle9i partitioning』を参照。 http://otn.oracle.com/products/oracle9i/pdf/o9i_partitioning.pdf


18


ローリング・ウィンドウ処理

ローリング・ウィンドウ処理は、データ・ウェアハウス環境で非常によく行われ

ています。この処理では、新しいデータのロードと古いデータのパージを定期的

に行うことで、データ・ウェアハウスを最新の状態に保持し、常に最新のデータ

をオンライン状態に保持します。レンジ・パーティション化とローカル索引によ

り、ローリング・ウィンドウ処理の効率が非常に高まります。

次に示す例では、データ・ウェアハウスに 1年分のデータを保持して、レンジが

月別にパーティション化されています。新しい月のデータをロードして一番古い

月のデータを削除しても、残りのパーティションは影響を受けません。処理全体

の完了までにかかる時間は新しいデータの量に正比例し、データ・ウェアハウス

のサイズとは関係ありません。

図 5: ローリング・ウィンドウ処理

パーティション・プルーニング

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

処理できます。問合せオプティマイザは SQL文の FROM句とWHERE句を解析

し、不要なパーティション、すなわち処理で必要なデータを含まないパーティショ

ンを検索から排除します。この方法では、ディスクから取得されるデータ量が大

幅に削減し、処理時間が短縮されるため、問合せのパフォーマンスとリソースの

使用率が向上します。図 6に示す例では、2002年の Sales表が月別にパーティショ

ン化されています。オプティマイザは、問合せのWHERE句の解析後、問合せ実

行中にアクセスの必要があるのは 2月と 3月に対応する 2つのパーティションの

みであると判断します。このパーティション・プルーニングのみで、問合せの実

行速度が 6倍になることがあります。

Oracle Databaseはパーティション・プルーニングを完全にサポートして、対象に

はコンポジット・パーティション化されたオブジェクトも含まれています。パー

ティション・プルーニングはさらに、索引アクセス（グローバルまたはローカル）

とも結合できます。索引と表が別の列に基づいてパーティション化された場合、

基礎になる表のパーティションを排除できなくても、Oracle Databaseは不要な索

引パーティションを排除します。


19


図 6: パーティション・プルーニングの例

Oracle Databaseは多様なパーティション化オプション、および表や索引の組合せ

をサポートしているため、アプリケーションではさらに幅広いビジネス環境で

パーティション・プルーニングを活用できます。

パーティション・ワイズ結合

Oracle Databaseでは、パーティション化を通じて複数表結合のパフォーマンスも

向上できます。この際、パーティション・ワイズ結合という方法を使用します。

これには、フル・パーティション・ワイズ結合とパラレル・パーティション・ワ

イズ結合の 2種類があります。フル・パーティション・ワイズ結合は、2つの表

が結合され、その両方が結合キーに基づいてパーティション化される場合に適用

できます。パーシャル・パーティション・ワイズ結合は、一方の表のみが結合キー

に基づいてパーティション化される場合に適用できます。この場合、Oracle

Databaseは、一般に小さい方の非パーティション表を、大きい方のパーティショ

ン参照表のパーティション化キーに基づいて動的に最分散します。もう一方の表

が動的に再パーティション化された後は、フル・パーティション・ワイズ結合と

同様の処理が行われます。

パーティション・ワイズ結合は、各パーティション間での大きめの結合をそれよ

り小さい結合に分割するため、結合全体の終了までの時間が短くなります。これ

は、シリアル実行とパラレル実行の両方のパフォーマンスを大幅に向上します。


20


図 7: フル・パーティション・ワイズ結合

パーティション・ワイズ結合は、結合のパラレル実行時にパラレル実行サーバー

間で交換されるデータ量を最小化することで、問合せ応答時間も短縮します。こ

の結果、応答時間が大幅に短縮され、CPUとメモリーの両方のリソースの使用効

率が高まります。

グローバル索引

グローバル索引は、一般にオンライン・トランザクション処理（OLTP）環境で使

用されます。異なる基準を使用して個々のレコードに効率的にアクセスする能力

は、OLTP環境では基礎的要件の 1つです。この理由から、多くの OLTPシステ

ムは、大きな表で多数の索引を持ちます。オラクル社が社内で使用しているアプ

リケーションの E-Business Suiteは、その大きな表のほとんどに 1ダース以上の索

引を持ちます。パーティション化されたグローバル索引は、パーティション化の

程度とパーティション化キーが表のパーティション化方法とは独立している点で、

より高い柔軟性があります。これを次の図に示します。この図では、Customers表

は Customer_IDキーでパーティション化されています。Customer_Nameキーでグ

ローバル索引を作成し、パーティション化できます。


21


図 8: パーティション化されたグローバル索引の例

Oracle Database 10gでは、表のハッシュ・パーティション索引、パーティション化

された表および索引構成表の利用ができます。これは、多数の同時挿入を行うア

プリケーションでのスループットを向上させます。

高速データ移動

Oracle Database 10gには、大規模なデータ・ウェアハウスや複数のデータ・マート

の効率的な構築とリフレッシュを容易にするデータの抽出、ロード、変換（ELT）

を行う新機能が用意されています。

データの大量移動のために、Oracle Database 10gは、移植可能な表についてプラッ

トフォームをまたぐサポートを提供しています。このサポートにより、あるプラッ

トフォーム上のデータベースから大量のデータを非常に迅速に切り離して、別の

プラットフォーム上のデータベースに再接続できます。

Oracle Database 10gは、新しいData Pumpユーティリティも導入します。Oracle Data

Pumpは、あるデータベースから別のデータベースへのデータとメタデータの迅速

な移動を可能にする、高速なパラレル・インフラストラクチャです。このテクノ

ロジは、Oracleの新しいデータ移動ユーティリティであるData Pump ExportとData

Pump Importの基礎となっています。

Data Pump Exportおよび Importの設計は、オリジナルの Exportと Importより大幅

に強化されたパフォーマンスを実現します。次の表に、単一ストリーム・データ

移動について、オリジナルの Exportおよび Importユーティリティと新しい Data

Pumpユーティリティとの経過時間の比較を示します。


22


エクスポート

（単一ストリーム）インポート（単一ストリーム）

オリジナル・ユーティリティ 2' 23" 25' 55"

Data Pumpユーティリティ 1' 32" 1' 41"

パフォーマンス向上率 35% 93.5% （速度にすると 15倍以上）

1.0 GBのデータ（930万行）ハードウェア: 1 GBメモリー、2ディスク・ドライブを装備した 1-CPU Ultra 60

さらに、PARALLELパラメータを使用して、Importジョブまたは Exportジョブに

稼働するアクティブな実行サーバーのスレッドの最大数を指定でき、データのア

ンロードとロードのパフォーマンスがさらに向上します。

新しい Data Pump Exportおよび Importユーティリティは、オブジェクト選択でも

さらに高い柔軟性を提供します。すなわち、オブジェクトとオブジェクトのタイ

プに基づいたファイングレインなオブジェクト選択をサポートします。この新し

いユーティリティは、ソース・データベースとターゲット・データベース間で発

生する Export/Import操作のファイルレスなオーバーラッピングを実現するネット

ワーク・モードもサポートします。PL/SQLパッケージにより、ユーザーは仕様公

開されたインタフェースで独自のデータ移動ユーティリティを作成できます。

Export/Import環境の管理も、このリリースで改善されました。Data Pump操作は、

ジョブがユーザーの意思で停止されたか、不測による終了にも関係なく、完全に

再開可能です。ユーザーは、ジョブによるディスク領域の消費量を調べ、そのジョ

ブの完了までの時間を予測できます。管理者は、長時間実行ジョブの切断と再接

続により、複数の場所からジョブを監視できます。また、パラレル度やダンプファ

イル可用性など、そのジョブの特定の属性を変更できます。

プラットフォーム固有の改善

Microsoft Windows ベースのシステム

Windowsの 64ビット・バージョンの登場により、ファイル・サイズやメモリー・

アドレッシングに課せられた制限など、32ビット・プラットフォームに存在して

いた制限がなくなりました。Oracle Database 10gは、ネイティブ 64ビット・アプ

リケーションとして 64ビットWindowsで使用でき、Intel Itanium 2プロセッサに

基づくハードウェア・アーキテクチャの高パフォーマンスを最大限活用します。

Microsoft Windowsプラットフォームにおけるトランザクション処理アプリケー

ションのパフォーマンスとスケーラビリティも、Oracle Database 10gにファイバを

使用することで改善されています。ファイバ（ユーザー・スレッドとも呼ばれる）

は、オペレーティング・システム・レベルのスケジューラに関係するスケジュー

リングとコンテキスト・スイッチングのオーバーヘッドを大幅に削減またはゼロ

にする超軽量プロセスです。ファイバの使用により、Oracle Databaseは、独自の

インテリジェントな Oracle対応スケジューリング・モデルを活用できます。ファ

イバに対するサポートは、既存のアプリケーションに対して完全に透過的です。

この新しい環境での実行にアプリケーション・コードを変更は必要ありません。


23


高速 Infiniband ネットワークのサポート

Oracle Net高速相互接続サポートは、InfiniBandアーキテクチャや将来の他の高速

ネットワークをサポートするために設計されたOracle Database 10gの新機能です。

今日の主流である LANとインターネットのプロトコル（TCP/IP）は、大容量イン

ターネット・アプリケーションが必要とするパフォーマンスを提供しません。そ

のようなアプリケーションは、操作の同期やデータの共有に、ノード間で高速な

信頼性の高い情報交換が必要です。高速、高密度、シリアル相互接続の InfiniBand

は、このような制限に対処し、データ・センターの増大する要求を満たすために

特に設計されたものです。この機能は、中間コピーをなくすこと、およびメッセー

ジング作業の大部分を CPUからネットワーク・ハードウェアに移転することによ

り、ネットワーク通信のスループットを高め、CPU使用率を削減します。InfiniBand

を使用することにより、アプリケーションはメッセージング作業の大部分を高速

ネットワーク・ハードウェアに置き、他のタスクのために CPUを解放します。

Oracle Net高速相互接続サポートにより提供される新機能は、SDP（Sockets Direct

Protocol）と非同期 I/Oの 2つのカテゴリに分けることができます。SDPプロトコ

ルは、クライアント/サーバー接続およびサーバー/サーバー接続のパフォーマンス

を高速化する高速通信プロトコルです。非同期 I/Oサポートにより送信バッファ

および受信バッファをオペレーティング・システム・カーネルに渡せるため、CPU

を大量消費するコピー操作は必要ありません。このサポートは、アプリケーショ

ンのパフォーマンス、特に大量のネットワーク・トラフィックを持つアプリケー

ションのパフォーマンスの改善に役立ちます。

Oracle Database 10g のパフォーマンス新機能のサマリー

次の表に、Oracle Database 10gで導入された主要なパフォーマンス機能のサマリーを示します。

領域機能

表構造ソート済ハッシュ・クラスタ

パーティション化グローバル・ハッシュ索引

索引構成表に対するリスト・パーティション化

サポート

Windowsベースのシステム 64ビットWindowsのサポート

Windowsファイバのサポート

ネットワーキング高速 Infinibandネットワークのサポート

マテリアライズド・ビューパーティション対応リフレッシュの改善

複数のマテリアライズド・ビューを使用できる

クエリー・リライト

OLAP パラレル SQL Import

パラレル AGGREGATE

コストベースのオプティマイザ自動統計収集

PL/SQL 新しいコード・ジェネレータおよびグローバ

ル・オプティマイザ


24


セルフチューニング・メモリーセルフチューニング SGA

チェックポイントのセルフチューニング

ETL Data Pump Exportおよび Importユーティリティ

プラットフォーム間で移植可能な表領域

結論

Oracle Database 10gは、エンタープライズ・アプリケーションを構築して実行する

ベースとなる、スケーラビリティ、信頼性および可用性に最も優れたデータベー

ス・プラットフォームです。Oracle Database 10gは、非常に要件の厳しい環境にお

けるスケーラビリティ要件を満たすだけでなく、その要件をも越えます。

Oracle Database 10gを使用すると、企業や組織は時間が経過してもスケーラビリ

ティ要件を簡単に満たすことができ、複雑な環境のニーズに応じて即時に変更で

きる柔軟性も手に入れることができます。


25


Oracle Database 10g を使用したデータベース・パフォーマンス 2003 年 7 月著書: Hervé Lejeune 寄稿者: Vineet Buch, Carol Palmer 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 © 2003 Oracle Corporation All rights reserved.

oracle database 10gを使用したデータベース・パ...

Documents