Oracle Database 10g Release 2を使用したデータ...

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

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


概要 ...................................................................................................................... 3 パフォーマンスの管理性 .................................................................................. 3 セルフチューニング・データベース ......................................................... 3

Automatic Workload Repository（AWR） .............................................. 3 Automatic Database Diagnostic Monitor（ADDM） .............................. 4 Automatic SQL Tuning（自動SQLチューニング） .............................. 4 SQL Access Advisor .................................................................................. 5 セルフチューニングSGA ....................................................................... 5 セルフチューニング・チェックポイント ........................................... 5

セルフチューニング・マルチブロック読込みカウント ......................... 6 多数の同時ユーザーの管理............................................................................... 7 共有リソースに対する内部競合の解消 ..................................................... 7 マルチバージョン読込み一貫性 ........................................................... 7 段階的に拡大しない行レベル・ロック ............................................... 8 パッケージ・アプリケーションに対するロックの影響.................... 9

非同期コミット............................................................................................. 9 複雑なトランザクションのサポート............................................................... 9 豊富な問合せ処理テクニック ..................................................................... 9 索引 ........................................................................................................... 9 索引構成表 ............................................................................................. 11 コストベースの問合せ最適化 ............................................................. 11

ソート済ハッシュ・クラスタ ................................................................... 14 サマリー管理の強化 ............................................................................. 15

最適化されたPL/SQL ................................................................................. 17 大量のデータの管理 ........................................................................................ 18 パラレル実行のサポート ........................................................................... 18 パラレル単一カーソル ......................................................................... 19

データの分割（パーティション化） ....................................................... 19 ローリング・ウィンドウ処理 ............................................................. 20 パーティション・プルーニング ......................................................... 20 パーティション・ワイズ結合 ............................................................. 21 グローバル索引 ..................................................................................... 22 多数のパーティション ......................................................................... 23

全表スキャン............................................................................................... 24 メモリー内ソート....................................................................................... 24 ハッシュ・ベースの集計 ........................................................................... 24 高速データ移動........................................................................................... 24

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


2

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


概要

Oracle Databaseは、世界中で多数の大規模情報システムをサポートしています。

約 30年にわたって、Oracle Databaseはパフォーマンスとスケーラビリティに関す

る業界標準を設定してきました。Oracle6におけるマルチバージョン読込み一貫性

に始まり、各リリースでデータベースのパフォーマンスとスケーラビリティを改

善するために設計された革新的な機能を導入してきました。また、各リリースは、

その時点で使用可能なすべての主要プラットフォームで基本的な変更を必要とせ

ずに実行できました。このホワイト・ペーパーでは、パフォーマンスとスケーラ

ビリティに直接関係する Oracle Databaseの特長について、最新リリースである

Oracle Database 10g Release 2の新機能とパフォーマンス改善点を中心に説明しま

す。

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

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

ベースのサポートに分類されます。これらの課題にはすべて、パフォーマンス診

断とデータベース・チューニングに多くの時間と労力を使わずに対応することが

必要です。優れたパフォーマンスであれば、可能な最低コストでの配布とメンテ

ナンスも容易です。

このホワイト・ペーパーでは、これらの課題に関し Oracle Databaseの対応を説明

します。

パフォーマンスの管理性

セルフチューニング・データベース

Oracle Database 10gには、パフォーマンス監視を簡略化し、パフォーマンス問題の

検出と解決を自動化する機能が用意されています。これらの機能により、Oracle

Databaseは初のセルフチューニング・データベースとなります1。

Automatic Workload Repository（AWR）

Automatic Workload Repository（AWR）は、Oracle Database内の永続リポジトリで

あり、データベースの処理に関するパフォーマンス・データと統計を保管します。

Oracle Databaseは、重要な統計およびワークロード情報のスナップショットを定期

1 Oracle Database 10gの自己管理性機能の詳細は、オラクル・ホワイト・ペーパー『Oracle Database 10g: 自己管理型データベース』参照。


3


的に取得し、それをAWRに格納します。これらの統計によりOracle Database 10g

の診断機能用のデータが提供され、事前監視と事後監視がサポートされます2。

Automatic Database Diagnostic Monitor（ADDM）

ADDMは、データベースにある自己診断エンジンであり、AWRで取得したデー

タを事前に分析してシステムの状態を把握します。ADDMの目標は、システムで

DB時間を最も多く消費している部分を発見したうえで、推奨ソリューション、ま

たは新しい SQL Access Advisorなど他のアドバイザリ・コンポーネントの参照に

より、この時間をできる限り短縮することです。ADDMは、単に症状に着目する

だけではなく、問題の根本的原因を識別する詳しい分析を行い、問題の全般的影

響をレポートします。また、ADDMは、推奨事項により期待される利点を数値化

し、パフォーマンスを低下させることがなく、チューニングの必要がないシステ

ム領域についても文書化します。

Automatic SQL Tuning（自動 SQLチューニング）

Oracle Database 10gでのSQL文のチューニングは、完全に自動化されています3。

Automatic SQL TuningはAutomatic Tuning Optimizerに基づいています。自動チュー

ニング・モードでの問合せオプティマイザは、チューニング・プロセスに必要な

検査および確認作業に多くの時間が与えられます。この十分な時間により、オプ

ティマイザは、通常の処理モードの制限時間のもとでは使用できなかった動的サ

ンプリングやパーシャル実行などのテクニックが使用できます。これらのテク

ニックにより、オプティマイザはコスト、選択性およびカーディナリティに関す

る独自の予測を検証できます。その結果、自動チューニング・モードの使用によ

り、SQL文の適切にチューニングされた計画を生成できます。

Automatic Tuning Optimizerの機能は、新しいSQL Tuning Advisorを介して公開され

ます。Automatic Tuning Optimizerは、統計分析、SQLプロファイリング、アクセス・

パス分析およびSQL構造分析など、複数の分析を実行します4。

Automatic Tuning Optimizerにより生成された結論は、SQL Tuning Advisorから

チューニング・アドバイスの形式でユーザーに渡されます。アドバイスは、1つ

以上の推奨事項で構成されます。各推奨事項には論理的根拠と実装時に得られる

利点が含まれます。アドバイスには、新規索引の追加、SQL文のリライト、SQL

プロファイルの実装などに関する推奨事項も含むことができます。ユーザーには

アドバイスを受け入れるオプションが与えられ、対応する SQL文のチューニング

が完了します。

2 AWRおよびADDMの詳細は、オラクル・ホワイト・ペーパー『自動管理型データベース：自動パフォーマンス診断』参照。

3 Automatic SQL Tuningの詳細は、オラクル・ホワイト・ペーパー『自動管理型データベース：アプリケーションおよびSQLチューニング･ガイド』参照。

4 これらの分析および結果の詳細は、オラクル・ホワイト・ペーパー『自動管理型データベース：アプリケーションおよびSQLチューニング･ガイド』参照。


4


SQL Access Advisor

SQL Access Advisorは、与えられたワークロードに対してワークロードのスキーマ

設計を自動分析し、そのワークロードに対応して、索引およびマテリアライズド・

ビューの作成、保持または削除に関し推奨事項を提供します。推奨事項を生成す

る場合、SQL Access Advisorは、新しい索引およびマテリアライズド・ビューの追

加が挿入、更新、削除などのデータ操作に与える影響と、それによって改善され

る問合せのパフォーマンスを考慮します。

セルフチューニング SGA

システム・グローバル領域（SGA: System Global Area）は、すべてのユーザーが共

有するメモリー領域で、特定の Oracle Databaseインスタンスに関するデータと制

御情報が入っています。SGAは、内部でメモリー・コンポーネントに分割されて

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

クエストや、データベースに対して行われた変更を記録するリクエストなど、メ

モリー割当てリクエストの各カテゴリを満たすために使用されるメモリーのプー

ルを表します。

これらのキャッシュ・サイズをチューニングして最適なパフォーマンスを得るこ

とは、アドバイザリ・メカニズムを使用しても容易ではありません。コンポーネ

ントが小さすぎてメモリー割当てが失敗する、またはサイズが大きすぎて他の

キャッシュが使用できるはずのメモリーを無駄にしている、などのリスクが常に

あります。

Oracle Database 10gの最初のリリースで、セルフチューニング SGA機能が導入さ

れ、管理者は、SGAの合計サイズ（SGA_TARGET）のみを指定することにより、

各種SGAプール間の最適なメモリー配分をOracle Databaseに内部的に決定させる

ことができるようになりました。この新機能により、各種 SGAキャッシュに対す

るメモリー配分は、ワークロードの変化に応じて時間とともに動的に変化します。

Oracle Database 10g Release 2では、新しい SGA Size Advisorの提供により、管理者

は、SGA_TARGETパラメータの最適な設定に関しアドバイスを受けることができ、

その作業をさらに容易にします。

Oracle9i Databaseで導入されたPGA_AGGREGATE_TARGETパラメータを併用す

ることにより、セルフチューニングSGAは、Oracle Databaseがワークロード分布の

変化に合せてメモリー消費量を自動的かつ動的に調整できるようにし、最適なメ

モリー使用率を保証します5。

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

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

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

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

リーの使用を保証し、新しく到着する処理に空メモリーを探すパフォーマンスを

改善します。

5 オラクル社とグリッド・コンピューティングの詳細は、オラクル・ホワイト・ペーパー『Oracle and Grid』参照。


5


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

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

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

して、様々なMTTR目標値で発生する物理的書込み数を予測できました。Oracle

Database 10gでは、データベースはチェックポイント・アクティビティをセルフ

チューニングして、通常のスループットにほとんど影響を与えずに良好なリカバ

リ時間を達成できます。Oracle Databaseは、自動チェックポイント・チューニン

グにより、I/O使用率の低い時間帯を活用してメモリーで変更されたデータをデー

タ・ファイルに書き出すので、スループットに悪影響を与えません。したがって、

管理者がチェックポイント関係のパラメータを設定していない場合や、このパラ

メータが非常に大きな値に設定されている場合でも、妥当なクラッシュ・リカバ

リ時間を達成できます。

Oracle Database 10gの 2番目のリリースで行われたもう 1つの強化は、直接パス読

込み（パラレル問合せで発生する状況）によりアクセスされるオブジェクトに発

行されるオブジェクト・チェックポイント・リクエストのパフォーマンス6の大幅

な向上です。直接パス読込みによりオブジェクトにアクセスするためには、その

前にオブジェクトの使用済バッファをオブジェクト・チェックポイント・リクエ

ストによりディスク上のデータ・ファイルに書き出すことが必要です。Oracle

Database 10g Release 2以前では、チェックポイント・リクエストは、オブジェク

トが属する表領域に対するチェックポイントを発行し表領域全体の使用済バッ

ファすべてを書き出すことにより処理されていました。同じ表領域に多数のオブ

ジェクトが存在する場合があるため、この方法は不必要なディスク書込みを多数

発生することがあります。新しいリリースでは、ターゲット・オブジェクトの

チェックポイント・リクエストは、そのオブジェクトの使用済バッファを書き出

すだけで、他のオブジェクトの使用済みバッファに関わる余分な書込みは発生し

ません。

図 1: オブジェクト・チェックポイント

セルフチューニング・マルチブロック読込みカウント

全表スキャンや索引高速完全スキャンのようなスキャン操作では、オブジェクト

のすべてのブロックが読み込まれます。ディスクからバッファ・キャッシュにブ

ロックを読み込むコストは、大きな I/O操作でブロックを読み込むことにより取

り戻せます。DB_FILE_MULTIBLOCK_READ_COUNTパラメータは、キャッ

シュ・ミスが特定のブロックで発生した場合に、バッファ・キャッシュにプリ

フェッチされるブロック数を制御します。このパラメータの値は、データベース

の全体的パフォーマンスに重要な影響を与える場合があるため、最適な値を決定

することは管理者にとって簡単ではありません。

Oracle Database 10g Release 2は、オペレーティング・システムの最適 I/Oサイズと

バッファ・キャッシュのサイズに応じて、このパラメータに適した値を自動的に

選択します。

6 Oracle Database 10g Release 2のテスト結果の詳細は、オラクル・ホワイト・ペーパー『Oracle Database

10g Release 2におけるDSSパフォーマンス』参照。


6


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

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

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

処理でもリアルタイム処理でもユーザーが満足するパフォーマンスを提供すると

いう課題に直面しています。Oracle Database 10gの内蔵機能によりこれらの要件を

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

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

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

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

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

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

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

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

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

装によって異なります。

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

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

発生します。

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

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

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

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

ンが 2回実行し、1回目の問合せが返さなかった行を 2回目の問合せが取

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

ことを検出する場合に発生します。

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

正確な結果を提供します。トランザクションがデータを更新すると、オリジナル・

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

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

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

ザーに返すことができます。


7


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

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

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

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

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

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

時に実現します。

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

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

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

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

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

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

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

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

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

陥ることがありません。


8


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

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

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

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

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

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

可能なロック数に対する制限や、デッドロック発生の可能性に対処するため、SAP

ではアプリケーション中間層に専用の機能を実装する必要があります。SAP R/3、

PeopleSoftおよび Siebelなどのほとんどの基幹業務アプリケーション・パッケージ

がそのインストール・ベースの大部分を Oracle Database上に配置している主な理

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

非同期コミット

Oracle Databaseは、トランザクションのコミット時に、コミットが永続的である

ことを保証します。すなわち、コールがクライアントに返される前に、コミット

情報はオンライン REDOログ・ファイルのあるディスクにフラッシュされ、デー

タベース・クラッシュが発生してもトランザクションが維持されるようにします。

これにより、コミット操作で多少の遅延が発生します。コールはコミットがディ

スクで永続化されないと返さないからです。

非同期コミットにより、アプリケーション開発者はトランザクション・コミット

の動作をより綿密に制御できます。すなわち、REDOログ I/Oを強制する/しない

や、コミットがディスクで永続化するのを待つか待たないかを選択できるオプ

ションが与えられます。これにより、当面コミットが永続的でなくてもよいアプ

リケーションでは、コミット遅延が減少し、トランザクション・スループットが

向上します。

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

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

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

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

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

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

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

• サマリー管理機能

索引

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

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

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

トします。


9


• Bツリー索引

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

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

• 逆キー索引

• ビットマップ索引

• ビットマップ結合索引

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

• ドメイン索引

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

Oracle Databaseは、静的ビットマップ索引7およびビットマップ結合索引8をサポー

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

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

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

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

説明します。

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

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

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

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

れます。

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

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

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

マップを結合し、高速化を図ります。ビットマップ索引は、WHERE句内の複数の

条件に対応する索引を効率よくマージします。すべての条件ではなく、一部を満

たす行には、表自体のアクセス前にフィルタが適用されます。この結果、応答時

間が短縮され、場合によっては大幅な短縮が可能です9。

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

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

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

合せにビットマップ結合索引を使用すると、ビット単位処理を通じて時間を短縮

できます。

7 Oracle7.3以降 8 Oracle9i以降 9 オラクル・ホワイト・ペーパー『Key Data Warehousing Features in Oracle9i: A Comparative Performance

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


10


OracleJapan

図3の表が見つかりません。

http://otn.oracle.com/deploy/performance/content.html

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

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

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

プ結合索引を使用するとレスポンス時間の大幅な短縮が示されます。

索引構成表

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

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

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

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

値と行データのリンクに行のストレージで追加ストレージが必要ですが、索引構

成表では、これが必要ありません。したがって、データの取出しに必要なアクセ

ス時間が減少するため、パフォーマンスが向上します。

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

能をサポートします。

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

問合せ（クエリー）の最適化は、リレーショナル・データベースのパフォーマン

ス、特に複雑なSQL文の実行にとって非常に重要です。Oracle Databaseでは、コス

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

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

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

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

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

アプリケーションは非常に複雑なSQLコードを生成するので問合せオプティマイ

ザは、良好なパフォーマンスを保証するために高度に洗練され堅牢である必要が

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

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

アクセス方法を決定するテクニックとメソッドの活用により、優れた実行計画を

生成します12。

SQL変換

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

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

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

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

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

す。この場合、問合せ変換の決定は、マテリアライズド・ビュー・リライトやス

ター型変換のような各種テクニックが使用され、オプティマイザのコスト予測に

基づいて行われます。

10 Oracle9i Database以降で使用可能 11 Oracle Database 10g以降、ルールベースのオプティマイザに対するサポートは廃止 12 Oracle Databaseにおける問合せ最適化の詳細は、オラクル・ホワイト・ペーパー『Oracle9iでの問合せ最適化』参照。


11


実行計画の選択

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

アクセスする順序、表結合の仕方、表へのアクセスに索引を使用するかなどの手

順です。

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

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

アーキテクチャでは、実際、どのような SQL文も任意の並列度で実行できます。

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

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

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

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

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

があるためです。

コスト予測

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

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

測はできるかぎり正確であることが必要なため、Oracle Databaseは、そのデータ

構造とアクセス方式に関する深い知識を含む非常に高度なコスト・モデルを、オ

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

す。

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

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

引およびマテリアライズド・ビュー）に関する情報が収集されます。列データの

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

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

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

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

Oracle Database10gでは、デフォルト・コスト・モデルは CPU+IOです。ある問合

せの実行時間を予測するために、問合せオプティマイザは、その問合せの実行中

にデータベースが実行する IO操作の数とタイプおよび CPUサイクル数を予測し

ます。次に、システム統計を使用して、この CPUサイクル数と IO操作数を実行

時間に変換します。この改善されたコスト・モデルにより、より優れた実行計画

が作成されるので、問合せのタイプによってはパフォーマンスが改善されます。

すなわち、IOモデルと比較した改善係数は最大 77%（経過時間）になります。

図 3: CPU + IOコスト・モデルによるパフォーマンス改善の例図 3に示す最初の例では、結合問合せが Oracle Sampleスキーマの Sales表と

Products表で行われています。問合せは、Sales表と Products表間に参照整合性制

約があることをチェックします。IOコスト・モデルでは、問合せオプティマイザ

は、Sales表をスキャンするコストのみを考慮し、実行計画にネステッド・ループ

を選択します。CPU+IOコスト・モデルでは、メモリーで実行される操作のコス

トが考慮されるので、オプティマイザはハッシュ結合を選択します。結果的に、

はるかに優れた実行計画であり、高いパフォーマンスを示します。


12


さらにCPU+IOコスト・モデルの潜在的メリットは、問合せで条件の順序を変更で

きる点です。条件の順序変更は、各条件のコストを評価できる場合にかぎり可能

です。これはCPU+IOコスト・モデルでのみ可能です。なぜなら、ほとんどの場合、

条件のコストに含まれるのはCPUサイクルのみだからです。第 2の例で使用され

た問合せには、2つの条件があり、第 1の条件のほうが高い実行コストを持って

います。IOコスト・モデルでは、条件はオリジナルの問合せ順序で実行されます。

CPU+IOコスト・モデルでは、コストの低いほうの条件を先に実行するように、条

件の順序が変更されます。この順序変更により、第 2の条件の実行は、第 1の条

件を満たさない行についてはスキップするため、パフォーマンスが向上します13。

統計とパフォーマンス情報を収集するプロセスは、高度に効率化、自動化が必要

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

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

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

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

す。

Oracle Databaseは、サンプリングを使用して関連するデータのサンプルを調べる

ことにより、統計を収集します。サンプリングは、静的に、あるいは問合せと同

じトランザクションで発生する問い合わせとして動的に行えます。また、パラレ

ル化と組み合せて使用できます。Oracle Databaseの統計収集ルーチンは、対象と

なる表のデータ特性に基づいて、適切なサンプリング割合と適切な並列度を自動

的に決定します。また、Oracle Databaseは、ヒストグラムを必要とする列を絶対

的に決定し、それを列データ分布の正確な予測に使用します。

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

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

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

このモードは、最初の行を返すレスポンス時間の最良化を目標としたアプリケー

ション、たとえば運用システムに適しています。第 2のモードは、問合せからす

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

れます。

ランタイム動的最適化

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

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

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

の目標は、各問合せが理想的な量の CPUまたはメモリー・リソースを獲得できな

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

Oracle Databaseは、問合せの並列度を自動的に調整し、個々の問合せに対して適

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

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

13 これらの例の詳しい説明は、オラクル・ホワイト・ペーパー『Oracle Database 10g におけるDSSパフォーマンス』参照。 http://otndnld.oracle.co.jp/products/database/oracle10g/pdf/twp_dss_performance_10gr1_0903.pdf


13


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

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

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

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

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

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

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

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

適しています。

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

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

ンは、通常、通信環境や製造環境で見られます。この良い例が、電話交換の通話

明細（CDR: call detail record）のデータ構造です。発呼用の電話番号の数は固定で

すが、各電話番号から交換機を通って出る通話の数は無制限です。請求および監

査に、各通話を記録し、その発呼元との関連付けが必要です。通話は、交換機を

通るときに格納され、顧客への請求書が生成されるときに FIFO順で取得されます。

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

図 4: 通話明細データ構造

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

ラスタの方が優れたソリューションです。なぜなら、任意の加入者に対して通話

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

ソート済リストから FIFO方式で順に通話記録を読み込むためです。

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

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


14


サマリー管理の強化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

高速リフレッシュでは、様々な増分アルゴリズムを使用し、マスター表の新規デー

タや更新データを考慮しながらマテリアライズド・ビューを更新します。Oracle

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

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

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

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

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

アライズド・ビューの中の影響を受ける行が識別され、削除されます。

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

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

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

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

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

Oracle Database 10gでは、機能依存性およびクエリー・リライトの使用によっても

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

マテリアライズド・ビューを定義している場合、Oracle Databaseは、ベース表で

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

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

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

図 5: パーティション対応マテリアライズド・ビュー高速リフレッシュ

図 5は、ベース表のパーティションを変更後、マテリアライズド・ビューをリフ

レッシュする増分リフレッシュおよびクエリー・リライト・メカニズムを使用す

ることにより達成されるパフォーマンス改善を示しています14。

14 これらの例の詳しい説明は、オラクル・ホワイト・ペーパー『Oracle Database 10g におけるDSSパフォーマンス』参照。 http://otndnld.oracle.co.jp/products/database/oracle10g/pdf/twp_dss_performance_10gr1_0903.pdf


15


クエリー・リライト

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

とにより、表とビューに関して書かれたユーザー問合せをさらに高速実行するた

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

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

の要求を満たすために既存のマテリアライズド・ビューが使用可能か、そして使

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

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

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

算し、その結果をデータベースに格納するため、問合せパフォーマンスが劇的に

向上します。マテリアライズド・ビューを使用するよう問合せをリライトして、

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

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

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

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

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

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

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

サマリー・アドバイザ

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

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

ションできます。

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

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

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

ジャは、ユーザーが自分のスキーマで使用できる多数のマテリアライズド・ビュー

から選択する際に役立ちます。

たとえば、マテリアライズド・ビューのサイズの予測、収集された情報または仮

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

クロードに基づくマテリアライズド・ビューの実際の使用率の報告などに、サマ

リー・アドバイザが使用できます。


16


最適化された 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倍のパフォー

マンス向上を実現しました15。

また、PL/SQL実行可能コードや動的スタック・サイズも大幅に減少しました。こ

れらのサイズ減少により、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プログラムの実行速度が大幅に向上します。

15 詳細はhttp://otn.oracle.com/tech/pl_sql/htdocs/new_in_10gr1.htm参照。


17


大量のデータの管理

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

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

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

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

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

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

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

パラレル実行のサポート

パラレル処理では、1つ以上のタスクに必要な処理を同時実行する複数のプロセッ

サと I/Oリソース間で分散するため、追加のハードウェア・リソースを最適に使

用でき、システムのスケーラビリティが確保されます。

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

調動作して単一の SQL文を実行します。1つの文の実行に必要な処理を複数のプ

ロセス間で分割することで、単一のプロセスでの実行よりも時間が短縮できます。

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

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

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

行をサポートします。

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

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

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

OLAP分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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


18


パラレル単一カーソル

Oracle Database 10gでは、問合せのパラレル実行モデルは、スレーブ SQLモデル

からパラレル単一カーソル・モデルに移行しました。単一カーソルには、パラレ

ル実行に必要なすべての情報が入っており、それがパラレル実行プロセス全体で

使用されます。

パラレル単一カーソル・アーキテクチャから、シリアルな実行に使用される処理

をパラレルに実行することによるパフォーマンス向上と、共有メモリー消費量の

削減というメリットをただちに獲得できます。

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

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

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

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

ています16。

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

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

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

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

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

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

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

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

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

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

• さらに、Oracle Databaseでは、レンジ-ハッシュおよびレンジ-リストのコ

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

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

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

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

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

のみと 1対 1で対応します。

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

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

ション表に対する索引です。

• グローバル非パーティション索引は、非パーティション表に対する索引

と本質的に同じです。索引構造はパーティション化されません。

16 Oracle Databaseのパーティション化オプションの詳細は、オラクル・ホワイト・ペーパー『Oracle9i

partitioning』参照。 http://otn.oracle.com/products/oracle9i/pdf/o9i_partitioning.pdf


19


http://otn.oracle.com/products/oracle9i/pdf/o9i_partitioning.pdf

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

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

ション索引の使用および非パーティション表でパーティション索引と非パーティ

ション索引の使用ができます。

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

ローリング・ウィンドウ処理は、データ・ウェアハウス環境で頻繁に行われます。

この処理では、新しいデータのロードと古いデータのパージによりデータ・ウェ

アハウスを定期的に更新し、常に最新のデータをオンラインで保持します。レン

ジ・パーティション化とローカル索引により、ローリング・ウィンドウ処理の効

率が非常に高まります。

次の例では、データ・ウェアハウスは、月別にパーティション化されたレンジの、

1年分のデータを保持しています。新しい月のデータをロードして一番古い月の

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

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

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

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

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

パーティション・プルーニングにより、必要なデータを含むパーティションに対

してのみ操作を実行できます。問合せオプティマイザは、SQL文の FROM句と

WHERE句を解析し、不要なパーティション、すなわち処理で必要なデータを含

まないパーティションを検索から除外します。この方法では、ディスクから取得

されるデータ量が大幅に減少し処理時間が短縮されるため、問合せのパフォーマ

ンスとリソースの使用率が向上します。図 6の例では、2002年の Sales表が月別

にパーティション化されています。オプティマイザは、問合せのWHERE句を解

析後、問合せ実行中にアクセスが必要なのは 2月と 3月に対応する 2つのパーティ

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

合せの実行速度は 6倍速くなる可能性があります。


20


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

その対象には、コンポジット・パーティション化されたオブジェクトも含まれて

います。また、パーティション・プルーニングは、索引アクセス（グローバルま

たはローカル）と結合できます。索引と表が別の列に基づいてパーティション化

された場合、Oracle Databaseは、基礎になる表のパーティションが除外できない

場合でも、必要のない索引パーティションを除外します。

図 8: パーティション・プルーニングによるパフォーマンス向上

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

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

をサポートしているため、アプリケーションでは様々なビジネス環境でパーティ

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

パーティション・プルーニング・テクニックは、Oracle Database 10g Release 2でさ

らに改善されています。プルーニングのさらなる最適化と、実際のI/Oリクエスト

数の削減により、図 8と 9に示すように、問合せによってはパフォーマンスを大

幅に向上できます17。

図 9: パーティション・プルーニングによる I/O数削減

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

Oracle Databaseでは、パーティション・ワイズ結合というテクニックの使用によ

り、パーティション化を通じて複数表結合のパフォーマンスも向上できます。

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

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

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

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

17 Oracle Database 10g Release 2のテスト結果の詳細は、オラクル・ホワイト・ペーパー『Oracle Database

10g Release 2におけるDSSパフォーマンス』参照。


21


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

Databaseは、一般に大きい方のパーティション参照表のパーティション化キーに

基づいて、小さい方の非パーティション表を動的に再分散します。一方の表が動

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

の処理が行われます。

パーティション・ワイズ結合は、各パーティション間で大きい結合をより小さな

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

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

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

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

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

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

が高まります。

グローバル索引

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

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

は、OLTP環境では基礎的要件の 1つです。このため、多くの OLTPシステムは、

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

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

ります。グローバルなパーティション索引は、パーティション化の程度とパーティ

ション化キーが表のパーティション化方法とは独立しているので、より柔軟性で

す。これを次の図に示します。この図での Customers表は Customer_IDキーでパー

ティション化されています。Customer_Nameキーでグローバル索引を作成し、パー

ティション化できます。


22


図 11:グローバルなパーティション索引の例

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

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

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

time_idのレンジ・パーティション（72パーティション）と prod_idのハッシ・パーティション（1パーティションにつき 256サブパーティション）→72 × 256 = 18,432パーティションを持つ Oracle Sampleスキーマのセールス表図 12: 多数のパーティションでの

DROP TABLE

多数のパーティション

パーティション化の使用がますます一般的になるとともに、データ・ウェアハウ

スのサイズも成長を続け、数万のパーティションを持つデータベース構造の作成

も可能になっています。Oracle Dabatase 10g Release 2では、表あたりの最大パー

ティション数は、64,000個から 1,024,000個に増え、非常に大きな表があるデータ

ベースに一層の柔軟性とスケーラビリティを提供します。

Oracle Database 10gでは、また、パーティション化されたオブジェクトのスケーラ

ビリティとメモリー使用率が大幅に改善され、確実に、そのようなオブジェクト

に対して行われる操作にパフォーマンス上の影響がほとんど出ないようにしてい

ます。

たとえば、18,432個のパーティションを持つ表で、DROP TABLE処理のパフォー

マンス改善をOracle9i DatabaseとOracle Database 10gで比較すると、経過時間を約

56%削減できました18。

18 オラクル・ホワイト・ペーパー『Oracle Database 10gにおけるDSSパフォーマンス』参照。


23


全表スキャン

図 13: 全表スキャン

全表スキャンのパフォーマンスは、Oracle Database10gで大幅に向上しています。

経過時間と CPU使用率の改善係数は、単純な条件または条件なしの単一表スキャ

ンの場合で 40%～60%です。

左の図は、圧縮表の全表スキャンで測定されたパフォーマンス向上を示していま

す19。

メモリー内ソート

Oracle Database 10g Release 2では、新しいメモリー内ソート・アルゴリズムを導入

しています。これは、Oracle Database 10g Release 1の既存のソート・アルゴリズム

より高速で、メモリー・システム局所性も向上しています。新しいメモリー内ソー

ト・アルゴリズムは、ORDER BY句を含む問合せ（図 14参照）、ソート・マージ

結合を使用する問合せ、パーティション外部結合を使用する問合せ、索引作成を

はじめ様々な問合せや操作のパフォーマンス20を向上させます。

図 14: メモリー内ソート

この新しいアルゴリズムでは、経過時間について問合せパフォーマンスが大幅に

向上しているだけでなく、CPU消費量の減少により、より多くの問合せを同時処

理できます。新しいメモリー内ソート・アルゴリズムによりメモリー・システム

局所性が向上しているため、このアルゴリズムを使用する問合せのパフォーマン

スは、使用可能なメモリーが増加すると向上します（図 15の異なる sort_area_sizes

値を持つ CREATE INDEXの場合を参照）。

ハッシュ・ベースの集計

図 15: メモリー内ソート

データ集計は、データ・ウェアハウス環境やOLAP環境では頻繁に見られる処理で

す。データは、その場で集計されることも、事前に計算され、マテリアライズド・

ビューとして格納される場合もあります。いずれの場合も、集計に必要な時間と

リソースは最小限である必要があります。Oracle Database 10g Release 2では、以前

のリリースで使用されていたソート・ベースのアプローチの代わりに、ハッシュ・

ベースの方法で集計することにより、集計のパフォーマンスを向上させています。

ハッシュ・ベース・スキームは、データ集計のパフォーマンス（図 16参照）を大

幅に向上させます21。

図 16: ハッシュ・ベースの集計

高速データ移動

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

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

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

データの大量移動のために、Oracle Database 10gは、トランスポータブル表につい

てクロス・プラットフォームのサポートを提供しています。このサポートにより、

あるプラットフォーム上のデータベースから大量のデータを非常に迅速に切り離

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

19 オラクル・ホワイト・ペーパー『Oracle Database 10gにおけるDSSパフォーマンス』参照。 20 Oracle Database 10g Release 2のテスト結果の詳細については、オラクル・ホワイト・ペーパー『Oracle

Database 10g Release 2におけるDSSパフォーマンス』参照。 21 脚注 19参照


24


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

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

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

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

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

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

に強化されたパフォーマンスを実現します。図 17のグラフに、単一ストリーム・

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

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

大規模企業ポータルの 1.0GBデータベース（9,300,000行）、単一ストリームハードウェア: 1-CPU Ultra 60、1GBメモリー、2ディスク・ドライブ図 17: Data Pump Import/Exportユーティ

リティ

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

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

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

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

さらに高い柔軟性を提供し、オブジェクトとオブジェクト・タイプに基づいたファ

イングレインなオブジェクト選択をサポートします。この新しいユーティリティ

は、ソース・データベースとターゲット・データベース間で発生する Export/Import

操作をファイルレスで行うネットワーク・モードもサポートします。PL/SQLパッ

ケージにより、ユーザーは仕様公開されたインタフェースで独自のデータ移動

ユーティリティを作成できます。

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

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

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

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

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

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


25


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

（ボールド体は Release 2の機能）

領域機能

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

全表スキャン

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

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

多数のパーティションでの操作のパフォーマンス改善

表あたり 100万パーティションのサポート

パーティション・プルーニング・テクニックの改善

Windowsベースのシステム

64ビットWindowsのサポート

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

マテリアライズド・

ビューパーティション対応リフレッシュの改善

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

ト

コストベース・オプ

ティマイザ自動統計収集

CPU+IOコスト・モデル

Automatic Tuning Optimizer

トランザクション非同期コミット

複合問合せメモリー内ソート

ハッシュ・ベースの集計

PL/SQL 新しいコード・ジェネレータおよびグローバル・オプティマイザ

セルフチューニン

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

SGAサイズ・アドバイザ

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

オブジェクト・チェックポイント

セルフチューニング・マルチブロック読込みカウント

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

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


26


Oracle Database 10g Release 2を使用したデータベース・パフォーマンス 2005年 9月著書: 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 © 2005 Oracle Corporation All rights reserved.

Date post:	21-May-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Oracle Database 10g Release 2を使用したデータ...

Documents