Oracle Database 11g パフォーマンスとスケーラビリティ

Transcription

1 Oracle Database 11g パフォーマンスとスケーラビリティ Oracle ホワイト ペーパー 2007 年 6 月

2 ご注意 本書は Oracle の一般的な製品の方向性を示すことが目的です また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 下記の事項は マテリアルやコード 機能の提供を確約するものではなく また 購買を決定する際の判断材料とはなりえません Oracle の製品に関して記載されている機能の開発 リリース および時期については 弊社の裁量により決定いたします Oracle Database 11g パフォーマンスとスケーラビリティ 2

3 Oracle Database 11g パフォーマンスとスケーラビリティ ご注意... 2 はじめに... 4 スケーラビリティの課題... 5 スケーラビリティの要素... 5 スケーラブルな実行... 6 Server Result Cache... 6 Oracle Call Interface (OCI) Consistent Client Cache... 8 Database Resident Connection Pool... 8 Cache Fusion プロトコル... 9 高可用性 Reader Farms... 9 オプティマイザ統計 Real Native PL/SQL と Java コンパイル スケーラブルなストレージ OLTP 表の圧縮 SecureFiles パーティション化の拡張機能 スケーラブルな可用性 バックアップとリカバリ Oracle Data Guard スケーラブルな管理 自己管理の強化 Database Replay SQL プラン管理 結論 Oracle Database 11g パフォーマンスとスケーラビリティ 3

4 Oracle Database 11g パフォーマンスとスケーラビリティ はじめに 企業は ビジネスを改善し拡大するために情報テクノロジ (IT) への投資を活用し続けています IT は 企業と顧客との相互の交流を可能にし 企業が顧客をより理解するための手助けになります さらに技術の革新と次世代の製品やサービスの開発に有用です 企業における IT の重要性は アプリケーションの増加や テクノロジ インフラストラクチャの処理能力の向上をもたらすアプリケーションの要求によって証明されています データ保存の規制 豊富なマルチメディア コンテンツのオンライン配布 Web 2.0( コンテンツがエンド ユーザーのコラボレーションから派生する Web サービス ) の登場により テクノロジによる処理能力の要求は今後も急激に増大していきます 増大する要求と IT の重要性はデータ量の増加と相まって 企業の IT 組織に前例のない課題を掲げます テクノロジ インフラストラクチャは 現行のパフォーマンス要件を満たすだけではなく ビジネス需要の増大に伴い シームレスに拡大を続ける必要があります 30 年以上にわたり Oracle Database は パフォーマンスとスケーラビリティを先導してきました Oracle Database は 世界で最も厳しい環境の大半を支えつつ 業界のさまざまなベンチマークで多方面にわたってトップの座を維持しています 現在 Oracle は TPC SAP および他のベンチマークの世界記録のほとんどを所有しています また Winter Top Ten program( 英語 ) による世界で最も大規模なデータベースの調査では Oracle が世界の真のリーダーであることが証明されています Oracle Database 11g は 以前のリリースで証明された基盤を継続的に拡大することで 顧客に次世代のパフォーマンスとスケーラビリティを提供し IT インフラストラクチャに課された大きな要求に対して顧客が対応できるようにします このホワイト ペーパーでは ビジネスの需要に応じて機能し拡大する IT インフラストラクチャを確立する際に 現代の企業が直面する課題について説明します 次に Oracle Database 11g で提供される新機能を中心に Oracle データベース内で使用できるテクノロジを検証します これらの機能により IT インフラストラクチャが抱える課題に対応できます Oracle Database 11g パフォーマンスとスケーラビリティ 4

5 スケーラビリティの課題 今日の企業は ますます複雑になりながら成長を続ける IT 環境で 拡大および機能する Oracle データベースに依存しています 前述したように Oracle Database は 最高のパフォーマンスとスケーラビリティを求める顧客にふさわしい製品です 一方 より大きなコンピューティング能力とスピードの必要性は さまざまな要因により 急激な増大を続けています 企業は日々多くのアプリケーションを導入し これらのアプリケーションは社内外を問わず多くのユーザーの要求を満たしますが その結果として 莫大な処理能力が要求されるようになります 同時に 長期的なデータ保存の規制 企業の合併および買収 非構造化データ ( ドキュメント 画像 マルチメディア XML) の増加といった新情勢が データベース サイズの想像がつかないほどに成長し続けています 企業がビジネス環境をより良く理解するために 顧客に関するデータをできる限り多く取得し 長い間保存しようとするので 数年前では珍しかった 1TB のデータベースが 現在では標準的な存在になっています 同様に 科学研究および医療部門で生成されるデータ量は文字どおり爆発的に増加し 一部の組織では 毎年 1PB(1000TB) 以上のデータの生成が予想されています ハードウェア ベンダーは 膨大な演算能力を手ごろな価格で提供することにより このような課題に対処してきました マルチコア プロセッサ テクノロジの画期的な発展により 一部の企業アプリケーションは 今後 3~5 年以内に 1000 のプロセッサ システムで稼動する可能性があります また ストレージとメモリーの価格が急落しているため 顧客がマルチテラバイトのデータベースをマルチテラバイトのメモリーを持つマシンで実行することが一般的になります Oracle Database 11g は 特にこのようなコンピューティング能力を活用して 顧客に次世代のパフォーマンスとスケーラビリティを提供するように設計されています データベース エンジンの多数の革新的な強化機能と新機能により Oracle Database 11g は数千のプロセッサに規模を拡大し 膨大な量のリレーショナル ( 構造化 ) データおよびファイル ( 非構造化 ) データを処理する体制を整えています さらに Oracle Database 11g には 企業がサービス品質を落とさず IT 予算を増大させずに 大規模なデータベースを管理できるテクノロジが組み込まれています スケーラビリティの要素 スケーラビリティの要素 スケーラブルな実行 スケーラブルなストレージ スケーラブルな可用性 スケーラブルな管理 IT 組織は インフラストラクチャの設計時に パフォーマンスとスケーラビリティの要求を満たすための 3 つの主要な要素に注目する必要があります 第一に アプリケーションの実行が パフォーマンス期待値およびエンド ユーザーとの品質保証契約を満たす必要があります Oracle Database 11g は 次のスケーラブルな実行およびスケーラブルなストレージの項で説明する 2 つの主要な点を通じて これらを可能にします 第二に データ量が増大するにつれ 高可用性アーキテクチャの維持が困難になります Oracle のこのリリースと バックアップとリカバリ フェイルオーバー (Data Guard) およびクラスタ化テクノロジの進歩により 企業はスケーラブルな可用性を実現できます 最後に アプリケーションおよびハードウェア リソースの数が増えているので インフラストラクチャを管理する効率的で費用効率の高い方法が必要です Oracle Database 11g パフォーマンスとスケーラビリティ 5

6 Oracle Database 11g のスケーラブルな管理では 多くの管理アクティビティを自動化し シンプルな環境と複雑な環境の管理のために Oracle Enterprise Manager Grid Control を使用した 使いやすい堅牢なツールセットを提供します スケーラブルな実行 前述したように Oracle Database 11g では 莫大なハードウェア能力をフルに活用して アプリケーションのパフォーマンスとスケーラビリティを向上します メガバイト当たりのメモリーの費用が下降しているので 多くの顧客は ストレージのボトルネックに対処し アプリケーションのパフォーマンスを改善するために 大容量のメモリーを使用することを検討しています Oracle Database 11g では 新しいキャッシング機能を導入して拡張されたメモリー量をより利用することで 問合せ処理を高速化します Sever Result Cache は SGA の新しいコンポーネントで 問合せの ' 結果 ' と問合せの断片をキャッシュします Server Result Cache によって 読取り集中型ワークロードのパフォーマンスは 2 倍になります Server Result Cache Oracle Database 11g の新機能である Server Result Cache により 問合せの結果をメモリーにキャッシュできます キャッシュされた結果は その後 類似した問合せまたは問合せ断片の実行時に 通常の問合せ処理を回避して 結果をより速く返すために使用されます Server Result Cache を有効にすると 結果がメモリーから直接取得されるので 物理および論理 IO に対する待機時間が減少し SQL の実行が最適化されます キャッシュされた結果は セッションおよび SQL 文の間で完全に共有され ( それらが共通の実行計画を共有する限り ) 開始カーソルの存続期間を超えて永続します Oracle Database 11g は 基盤となるデータが変更されるたびに Server Result Cache のエントリを消去することで キャッシュの整合性を管理します 内部のテストでは Server Result Cache を使用すると 読取り集中型ワークロードのパフォーマンスが 200% も向上することが証明されています 結果のキャッシュ専用メモリーは システム グローバル領域にあり 自動共有メモリー管理インフラストラクチャによって自動的に管理されます Server Result Cache は 新しい初期化パラメータ RESULT_CACHE_MAX_SIZE を使用して キャッシュの最大サイズを設定することにより使用可能になります グローバルできめ細かな制御を使用して 結果キャッシュをアーキテクチャに統合するための複数のオプションを選択できます 管理者は システム セッション 表 および文のレベルで使用法を定義できます 管理者は 新しい PL/SQL インタフェースを介して Server Result Cache のコンテンツを監視および管理できます このインタフェースを使用して 管理者はキャッシュ全体または個々のキャッシュされた結果セットを消去できます 管理者は このインタフェースを介して Server Result Cache メモリーの使用状況レポートを生成し Server Result Cache の有効性をさらに分析するためにデータ ディクショナリ ビューを使用できます 新しいオプティマイザ ヒントにより ユーザーは問合せレベルで Server Result Cache の使用を指定できます Oracle Database 11g パフォーマンスとスケーラビリティ 6

7 例 1-a では result_cache ヒントを使用しない 問合せ実行を示します 例 1-b では result_cache ヒントを使用した 同じ SQL 文の実行を示します 新しい演算子 'RESULT CACHE' に注意してください このヒントを発行すると 演算子は この実行計画に対する結果がすでにキャッシュに存在するかどうかを判定するために 結果キャッシュを調べます Oracle Database 11g パフォーマンスとスケーラビリティ 7

8 結果がキャッシュで見つかると 演算子は内在する実行計画の実行を回避して 直接結果キャッシュから行を戻します 結果がキャッシュに存在しない場合 内在する実行計画から行が取得され 結果キャッシュに保存されます Client Cache テクノロジにより クライアントとデータベース サーバー間のラウンドトリップが減少し サーバー CPU 使用率が下がります Oracle Call Interface (OCI) Consistent Client Cache OCI Consistent Client Cache(Client Cache) は 前項で説明した Server Result Cache に対する補足的なキャッシュ機能です この機能により クライアント マシンで問合せ結果をキャッシュできます Client Cache は 通常アプリケーション サーバー上で OCI クライアントのプロセスごとのメモリーを使用して 問合せ結果セット ( 表またはすべての結果セット ) に影響を与えるデータを保存します Client Cache は OCI クライアント プロセスのメモリーに常駐するので コンテンツは 複数のセッションおよびスレッドにわたって共有できます Client Cache が配置されていると クライアントは繰り返しサーバーに問合せを実行させるのではなく 結果セットをキャッシュから直接取得します Client Cache を使用する場合 必要とするクライアントとデータベース サーバー間のラウンドトリップが減少するので パフォーマンスが大幅に向上し 実行する SQL コールが減少する結果として サーバー上の CPU 使用率が下がります Client Cache は 一般的に読取り専用または read-mostly の小さいルックアップ表の問合せに最適です Client Cache を使用するシンプルな問合せでは 経過時間を 80% CPU 時間を 50% 減少できることがベンチマークで証明されています Client Cache を使用するシンプルな問合せでは 経過時間を 80% CPU 時間を 50% 減少できます Client Cache テクノロジには データベース サーバーとキャッシュ間の整合性を管理する固有のメカニズムが組み込まれています そのテクノロジが OCI 層の内部に常駐する場合 この機能は JDBC-OCI(Thick)Driver ODBC ODB.NET PHP およびプリコンパイラを含むすべての Oracle Database 11g OCI クライアントで使用可能です したがって Oracle Database 11g OCI ベースのクライアントを使用するすべてのアプリケーションで Client Cache 機能を透過的に使用できます アプリケーション コードを変更する必要はありません クライアント キャッシュ機能を有効にするには データベース初期化パラメータ CLIENT_RESULT_CACHE_SIZE をゼロ以上の値に設定する必要があります このパラメータにより クライアントのプロセス当たりの結果セットのキャッシュの最大サイズが決定されます また 前項で説明した表のプロパティ オプティマイザ ヒント およびシステム / セッション パラメータが Client Cache に適用されます サーバー パラメータを使用すると 一元化された方法で多数のクライアントのキャッシング動作を管理できるようになるため Client Cache の管理が簡単になります オプションとして クライアント構成ファイルを維持できます これにより データベース サーバー上で Client Cache の設定をオーバーライドできます クライアント側で使用できるオプションの設定には プロセス当たりの最大キャッシュ サイズ キャッシュごとの行の最大数 バイト数と行数で表した結果セットの最大サイズが含まれます Database Resident Connection Pool 企業アプリケーションでは 長い間アプリケーション サーバー レベルでデータベース接続プーリングを使用してきました 接続プーリングにより アプリケーションはより少数のデータベース セッションの使用で 多数のアプリケーションのエンド ユーザーにサービスを提供できます 接続プーリングの最終的な目的は データベース セッション作成のオーバーヘッドを制限し データベース セッションのメモリー使用を削減することで アプリケーションのパフォーマンスとスケーラビリティを向上することです PHP など一部のテクノロジは Web サーバーごとに少なくとも 1 つのデータベース接続を使用する必要があるので アプリケーション サーバーをベースとする接続プーリングの対象にはなりません さらに すでにアプリケーション サーバー レベルの接続プーリングを使用している大企業は 数百または数千のアプリケーション サーバーを使用する場合 Oracle Database 11g パフォーマンスとスケーラビリティ 8

9 には 依然として多数のデータベース セッションを使用する場合があります PHP アプリケーションおよびアプリケーション サーバー ファームは スケーラビリティを大幅に増進するために Database Resident Connection Pool を利用します Database Resident Connection Pool は Oracle データベースが管理するセッション接続プーリングを提供するスケーラビリティに優れたソリューションです Database Resident Connection Pool を有効にすると クライアントは専用のサーバー プロセスではなく 新しいバックグラウンド プロセスの接続モニター (CMON) に接続します CMON はサーバー側の接続プール機能を管理します 共通のユーザー名を使用してデータベースにアクセスするクライアントは 以前に割り当てられたセッションを利用します クライアントは CMON への永続的接続を透過的にキャッシュし アプリケーションがデータベース接続を要求したときにそれらを使用します アプリケーションがデータベース接続を終了すると 専用のサーバー プロセスは CMON に戻され 次のクライアントの要求に対して準備ができたプールに配置されます Database Resident Connection Pool は アプリケーション サーバー接続プーリングを実装できないアプリケーションと大規模なアプリケーション サーバー ファーム上でホストされるアプリケーションの両方に 多大なスケーラビリティを提供します Cache Fusion プロトコル Oracle は クラスタ内のノードが高速インターコネクトを使用して互いのメモリーと通信できるようにする Cache Fusion プロトコルを導入することで クラスタ化テクノロジを激変させました Cache Fusion は Oracle Real Application Clusters (RAC) のテクノロジの主要な要素の 1 つです Oracle Database 11g では次世代の Cache Fusion プロトコルを導入します ワークロードを認識する新しいプロトコルにより パフォーマンスを最大にするために処理されるワークロードの種類に応じて ノード間のメッセージ動作が動的に変更されます たとえば 新たに導入された読込みのために最適化されたプロトコルにより 読込み操作のためのノード間のメッセージ数が大幅に減少します 同様に 他の新しいプロトコルにより 更新や表スキャンの操作時のメッセージ動作が最適化されます Oracle Database 11g は ワークロード プロファイルに基づいて 最適なプロトコルを自動的に選択して使用します このように Cache Fusion プロトコルを最適化すると ノード間のメッセージが大きく減少し Oracle RAC のスケーラビリティが向上します 高可用性 Reader Farms Oracle Data Guard は Oracle の主要な障害時リカバリ テクノロジです このテクノロジを使用すれば 顧客はスタンバイ データベースと呼ばれる同期化されたデータベースのコピーをリモートで維持することにより データベースをサイト障害から保護できます スタンバイ データベースは 障害または計画的なメンテナンス処理の場合に ビジネスを確実に継続するためにアクティブ化できます 顧客は 2 種類のスタンバイ データベースを作成できます Oracle Data Guard Redo Apply を使用して 顧客はプライマリ データベースをデータベース ブロック レベルでミラー化するフィジカル スタンバイを作成できます 別の方法では Oracle Data Guard SQL Apply テクノロジを使用して ロジカル スタンバイを作成できます このテクノロジではプライマリ データベースからの変更情報は まず SQL に変換され 次にスタンバイ データベースに適用されます フィジカル スタンバイとは異なり ロジカル スタンバイでは ユーザーはスタンバイ データベースで書込み操作を実行できます これにより 追加の索引またはマテリアライズド ビューを作成し レポート作成アクティビティを最適化できます ただし フィジカル スタンバイのほうがシンプルで変更をより速く適用できるので パフォーマンスにおいてはロジカル スタンバイよりも優れています スタンバイ データベースは 効果的な障害防止を提供するだけではなく 多数の日常業務にも使用できます たとえば スタンバイ データベースは プライマリ データベースのレポートまたはバックアップのワークロードの負荷を軽減 Oracle Database 11g パフォーマンスとスケーラビリティ 9

10 するために使用でき テストのためにも使用できます Oracle Database 11g 以前 フィジカル スタンバイ データベースは 問合せが実行される間 プライマリ データベースから受信した変更を適用できませんでした Oracle Database 11g では その制限から開放され フィジカル スタンバイをリアルタイムの問合せに使用できます この注目すべき進歩により Reader Farm Database などの 新しい機能を得ることができます 非常に多くのユーザーをサポートする多数の Web アプリケーションでは 並列ワークロードをサポートし アプリケーションの可用性を高めるために主要なデータベースの複数の読取り専用レプリカを使用するアーキテクチャが使用されます リアルタイム問合せ機能を持つフィジカル スタンバイにより Oracle Database 11g は Reader Farm データベース アーキテクチャの理想的な基盤になります すべての更新はプライマリ データベースに対してのみ行われ スタンバイ データベースは読取り専用ワークロードに対応します さらに 指定されたファスト スタート フェイルオーバー スタンバイとしてスタンバイ データベースの 1 つを使用すると 障害に対するプライマリ データベースの保護が推進され その結果可用性が向上します 図 1 に代表的な高可用性 Reader Farm トポロジを示します 図 1 - 高可用性 Reader Farm トポロジ Oracle Database 11g パフォーマンスとスケーラビリティ 10

11 オプティマイザ統計 Oracle のコストベース オプティマイザ (CBO) は オブジェクト統計を使用して SQL 文の最適な実行計画を確定します Oracle Database 11g の強化機能により オプティマイザ統計は改善され より高速でより安全になります まず Oracle Database 11g のパフォーマンス強化により オプティマイザ統計の収集がより速くなり オプティマイザ統計の収集と計算に必要な合計時間が短縮されます 次に 計算されたオプティマイザ統計は より詳細で 固有の値の数 (NDV) やヒストグラムなどの統計を複数の列で相互に関連付けることにより より良い情報を CBO に提供します 最後に Oracle Database 11g は統計の収集をより安全にします 新たに生成された統計は 広く使用するために検証され公開されるまで プライベートな ' 統計ワークスペース ' に残すことができます Real Native PL/SQL と Java コンパイル Oracle Database 11g は PL/SQL に対して Real Native Compilation(RNCOMP) を Oracle データベースに保存されている Java プログラムに対して Just In Time(JIT) コンパイルを実装することにより PL/SQL と Java のパフォーマンスとスケーラビリティを改善します RNCOMP では Oracle の以前のバージョンの Native Compilation (NCOMP) が改善され 顧客は C コンパイラを取得してインストールし ライセンスを購入する必要がなくなりました RNCOMP と JIT の両方が ソース コードとマシンのネイティブの命令セットにコンパイルすることにより パフォーマンスが改善されます パフォーマンスの向上は アプリケーションがどれほど計算集中型であるかによって 30% から 100% までの幅があります スケーラブルなストレージ 企業は 構造化リレーショナル データと非構造化データ ( ドキュメント スプレッドシートなど ) のために より大きいストレージを継続して要求しています ハードウェア ベンダーは これらの要求に対処するために ディスクの容量を継続的に拡大していますが ディスクのパフォーマンスは それと同じペースで改善されてはいません マルチテラバイトのデータベースが一般的になっている中で Oracle Database 11g は豊富な強化機能を提供し IT 組織はパフォーマンス要件を満たしながら ストレージ インフラストラクチャをコスト効率の優れた方法で拡大できます OLTP 表の圧縮 Oracle は Data Warehouse とともに使用する目的で Oracle9i Database でデータ圧縮を導入しました 圧縮された表でデータを操作する方法が制限されていたので これは OLTP ワークロードには適していませんでした Oracle Database 11g ではこれらの制限が取り除かれ 従来の DML 文 (INSERT UPDATE DELETE) を圧縮された表で使用できます これらの圧縮の追加機能により 表の圧縮は DBA が OLTP データベースを管理するための独自のツールになります 表を圧縮すると 記憶容量に対する需要が減少し アプリケーションのパフォーマンスは向上します Oracle の表圧縮は強化され 圧縮を行うすべての DML 操作を OLTP アプリケーションで使用できるようになりました 表の圧縮は 記憶容量に対して増大する需要を IT 組織が管理するために利用できる戦略的な手段です 通常 圧縮された表のディスク容量の使用は 同じ表で圧縮されていない場合の 1/3 から 1/2 となります Oracle Database 11g は 圧縮されたデータを直接操作し データの復元に関連するアプリケーションのオーバーヘッドを排除します 圧縮された表を使用する場合 主に物理 IO の量が減少し キャッシュの効率が向上するため パフォーマンスが向上します Oracle Database 11g パフォーマンスとスケーラビリティ 11

12 ディスク外の表のスキャンは 圧縮された表の最大 2 倍の速度で実行されます SecureFiles 非構造化データ ( ドキュメント スプレッドシート 画像 マルチメディアなど ) は 企業に広く普及しています これは 主にネットワークの帯域幅が向上して 豊富な非構造化コンテンツの共有が可能になり SOX 法や HIPPA などの規制要件が変化したためです ファイル システムがシンプルであり パフォーマンスに利点があることを認識しているので 通常 IT 組織はデータベースではなく ファイル システムに非構造化コンテンツを保存します アプリケーションは Oracle データベースを使用して 非構造化データを記述するメタデータなど 構造化データを保存 編成 管理します ただし 2 つの独立したデータ ストアを持つというこのパラダイムにより IT インフラストラクチャの管理 保護 拡大は より複雑になります 具体的には このモデルで以下が導入されます 分離されたセキュリティおよび監査モデル 断片化されたバックアップとリカバリ 非原子的なデータ変更 ( メタデータを更新せずにファイルを削除 ) さまざまな情報ストアに及ぶ複雑な検索 異機種領域管理戦略 Oracle Database 11g に導入された機能である SecureFiles は 企業が Oracle データベースに非構造化データを保存できないようにしていたパフォーマンスの壁を打ち破るために設計されました LOB と同様に SecureFiles は データベースに大型のオブジェクトを格納するために構築されるデータ構造です ただし LOB またはファイル システムと比較すると SecureFiles は より豊かな機能セットを備え パフォーマンスは大幅に改善されています SecureFiles の機能セットは 透過的な非重複 圧縮 暗号化など最新のファイル システム機能を備え さらにファイル システムをはるかに超えた高度なデータベース機能を提供します SecureFiles は Oracle Database 11g のトランザクションおよび読取り一貫性モデル内で管理され Oracle RAC Readable Standby Oracle Data Guard 一貫性バックアップ ポイント イン タイム リカバリ フラッシュバックなど 高可用性機能によってサポートされます 非構造化データを SecureFiles として保存する企業は データ セキュリティ バックアップとリカバリ および領域管理に統一されたアプローチによって利益を得ます Oracle 内部のテストでは 読取りと書込みの両方の操作で SecureFiles のパフォーマンス パリティが示されました Oracle データベースの利点とパフォーマンスの促進により SecureFiles は IT 組織に非構造化データの保存と管理における戦略的な利点を提供します パーティション化の拡張機能 Oracle Database 11g に導入された複数の新しいパーティション化機能は 拡大と実行の能力を増大する一方で IT 組織でのパーティション化したオブジェクトの管理をシンプルにします レンジ パーティションの拡張機能であるインターバル パーティションは パーティション化された表の管理を簡単にするために開発された機能です Oracle Database 11g 以前 IT 組織は パーティション化スキームに応じて DDL 文を使用してレンジ パーティションを作成しました インターバル パーティションを使用すると DBA は インターバル要件を満たす最初の行が表に挿入されたときに Oracle Database 11g が自動的にパーティションを作成する間隔を指定するだけになります Oracle Database 11g パフォーマンスとスケーラビリティ 12

13 Oracle の以前のバージョンでは コンポジット パーティション化あるいはサブパーティションの使用が許可されていましたが パーティション / サブパーティションの組合せは制限されていました Oracle Database 11g では これらの制限が排除され 新しい時間隔パーティションを含む すべてのコンポジット パーティションを使用できます 表 1 にコンポジット パーティション化マトリックスを示します 表 1: コンポジット パーティション化マトリックス レンジ リスト ハッシュ レンジ はい はい はい リスト はい はい はい 時間隔 はい はい はい データの正規化を設計に組み込むデータ モデルにより リレーショナル モデルを利用して データの重複が低減されます Oracle Database 11g では 参照整合性制約 すなわち外部キーを使用するデータ モデルが オプションとして ' 親 ' 表のパーティション化スキームに基づいて ' 子 ' 表でパーティションを構築できます 参照によるパーティションは 指定された参照制約に基づいて ' 子 ' 表でパーティションを作成します ' 子 ' 表には ' 親 ' 表がパーティション キーとして使用する列を含める必要はありません 子パーティションは 親パーティションと同じ相対的なパーティションに保存されます このため 極度に効率的なパーティション ワイズ結合が可能になります Oracle Database 11g に導入される仮想列は 式を使用して定義されますが SQL では従来の列として表示されます 仮想列はパーティション キーとしてサポートされ 索引を付けることが可能で オプティマイザ統計とヒストグラムを含むことができます たとえば 仮想列は表の定義で次のように定義できます CREATE TABLE t1 ( c1 NUMBER, c2 NUMBER, vc AS (c1 + c2) VIRTUAL) スケーラブルな可用性 アプリケーションと企業情報の可用性は 企業の成功に不可欠です IT の重要性が大きくなるに従い テクノロジ インフラストラクチャも大きくなります このため IT 組織は インフラストラクチャを稼動させるテクノロジが スケーラブルな高可用性 (HA) 機能とツールで構築されていることを確認する必要があります Oracle は 組込みの HA 機能を持った世界に通用する製品を提供します Oracle RAC Oracle Data Guard Oracle Recovery Manager(RMAN) フラッシュバックは Oracle が提供する HA 機能の例です Oracle Database 11g では 画期的な新しい HA 機能が導入され 多数の既存の機能のスケーラビリティとパフォーマンスが改善されています Oracle Secure Backup は 一元化されたテープ バックアップ管理システムで 主要な競合他社の製品よりも最大で 25% 高速になります バックアップとリカバリ Oracle Secure Backup は データベースおよびファイル システムの両方に一元化したテープ バックアップ管理を提供する Oracle の新製品です Oracle Secure Backup は RMAN とのシームレスな統合により 主要な競合他社の製品より最大で 25% 高速のデータベース バックアップを提供します Oracle Database 11g パフォーマンスとスケーラビリティ 13

14 これは データベース エンジンへの直接コールを利用し 使用されないデータ ブロックをスキップする効率的なアルゴリズムにより実現します 今度リリースされる Oracle Secure Backup は 不必要な UNDO 表領域データのバックアップを回避するといったインテリジェント機能を使用して パフォーマンスの優位性を高めます Oracle Database 10g では 増分の RMAN バックアップのパフォーマンスを促進するブロック トラッキング機能が導入されました この機能は Oracle Data Guard フィジカル スタンバイで使用可能でしたが 管理リカバリの間は積極的にブロック トラッキング ファイルを更新していませんでした Oracle Database 11g は 管理リカバリ中にフィジカル スタンバイでブロック トラッキングを使用でき DBA は バックアップ処理のアクティビティをスタンバイ サーバーにオフロードしながら 増分バックアップの強化された能力を利用できます 企業データベースのサイズは成長し続けており Bigfile Tablespace の使用がより有用になります Oracle のもう 1 つの革新技術である Bigfile Tablespace は 多数の小さいファイルではなく 1 つの大きなファイルにより構成され Oracle データベースを 8EB(exabytes) まで拡張できます Oracle Database 11g の中心となるのは 拡張された RMAN ツールです このツールは Bigfile Tablespace のためにファイル内のパラレル バックアップおよびリカバリ操作を実行でき その結果 バックアップおよびリストア操作を大幅に速めることができます Oracle Data Guard 前述したように Oracle Data Guard は Oracle の高可用性ソリューションに欠くことのできないコンポーネントであり 最大可用性アーキテクチャ (MAA) の主要なコンポーネントです Oracle Data Guard は スタンバイ データベースを維持するプロセスを自動化します スタンバイ データベースは 本番の計画停止および計画外停止の間に起動されます Oracle Database 11g では REDO 転送を改善することにより Data Guard 機能を強化しています 非同期 (ASYNCH)REDO 転送は スタンバイ データベースと本番データベース間のネットワーク メッセージを REDO データの送信から分離することにより 中断することなく REDO データを流すように改善されています ネットワーク メッセージと REDO 転送を非同期化することで より大きなネットワーク スループットを提供し その結果 より低コストでデータ保護を提供します その他のネットワーク スループットの向上として 本番データベースとスタンバイ データベースの間で転送されている REDO データを圧縮する新機能が含まれています これは ネットワーク停止やスタンバイ サーバー障害が原因で スタンバイ サーバーと本番サーバーが通信できない場合に特に有用です スタンバイ データベースは 自動的に REDO ログ ギャップ ソリューションを実行します このソリューションは ログ転送の速度を上げる圧縮機能を使用できます スケーラブルな管理 現在 IT 管理者が直面している最大の課題の 1 つは IT インフラストラクチャとそれに依存するアプリケーションのパフォーマンスとスケーラビリティの管理です 管理者は 事前対応および事後対応の両方の観点からパフォーマンスを管理します 事前対応の管理には 使用率とデータ量の測定された増加に対するインフラストラクチャの拡大が含まれます また 管理者がアプリケーションとインフラストラクチャをテストし それらの変更 たとえば Oracle ソフトウェアの更新の準備をすることが必要です 事後対応の管理には 予想外のワークロード プロファイルの変更によるアプリケーションまたはデータベースのチューニングなど 日常的な管理者の職務が含まれます Oracle Database 11g パフォーマンスとスケーラビリティ 14

15 自己管理の強化 Oracle Database 10g は データベースを自己管理型にするための大きな一歩を踏み出しました Oracle Automatic Workload Repository(AWR) Oracle Automatic Database Diagnostic Monitor(ADDM) および SQL Tuning Advisor など 高く評価された革新的な機能により Oracle Database 10g は パフォーマンスのボトルネックをすばやく簡単に識別して修正する貴重なツールのセットを管理者に提供します Oracle Database 11g は データベースの自己管理を次のレベルに引き上げることにより この推進力を基に拡大を続けます ADDM の強化により Oracle RAC パフォーマンスをより綿密に分析できるようになりました Oracle Database 11g の SQL Tuning Advisor は 完全に自動化できるようになりました SQL チューニング推奨事項を自動的に実装するので 管理者は手動のタスクから解放されます SQL Access Advisor は アプリケーションのパフォーマンスを向上させるために パーティション化の方針に関する推奨事項を提供するように強化されました 最後に ストリームの構成を検証し 管理者がパフォーマンスのボトルネックを解決するのを支援するために 新しいアドバイザが Oracle Database 11g に導入されました Database Replay のテクノロジにより 実際の本番データベース アクティビティが記録されます 取得された記録は 更新およびパフォーマンスのテストのために テスト データベースで再実行できます Database Replay パフォーマンスおよび処理能力の管理に成功するには システム変更の影響分析を正しく実装する必要があります IT 管理者は 常に本番ワークロードを正確に表すテスト用シナリオの作成に取り組んでいます 通常 管理者は自動化されたテスト スクリプトを実行するか アプリケーションの機能をテストするために ユーザーを使用して本番ワークロードをシミュレートします これらの方法は 本質的に制限があり 本番ワークロードを正確に表せないので 徹底的な影響分析を実行するには不十分であることが証明されています 多くの場合 このような不完全さが原因で 本番パフォーマンスの低下や不安定性が生じます Oracle Database 11g には Database Replay が組み込まれています これは 従来の変更分析におけるテスト技術の不完全さを克服するテクノロジです DBA が起動する際 Database Replay は本番データベースのデータベース ワークロード アクティビティを取得します 取得されたワークロードのデータは 実際の本番ワークロードをシミュレートするために 本番データベースのコピーを実行しているテスト サーバーで再実行されます 本番ワークロードを人工的に " シミュレート " する他のワークロード取得テクノロジとは異なり Database Replay は 最も低い詳細レベルで本番ワークロード全体を取得して初めて 顧客がテスト環境で本格的なワークロードを実行できるようにします 柔軟性を考慮して設計された Database Replay テクノロジは Oracle データベース更新のテストおよびプラットフォーム移行中は極めて有効です ワークロードのデータは データベースの異なるバージョン さらに異なるプラットフォームでも取得し 再実行できます SQL プラン管理 Oracle のコストベース オプティマイザ (CBO) は CBO バージョン CBO パラメータ オブジェクト統計 システム設定など 複数の要素に基づいて SQL 実行計画を生成します これらのコンポーネントのいずれかが変更されると オプティマイザが特定の SQL 文に対して異なる実行計画を生成します プラン スタビリティを支援するために オプティマイザ ヒントやストアド アウトラインなど さまざまな機能が提供されています SQL プラン管理機能により Oracle Database 11g は プラン スタビリティを次のレベルに進めます この新機能を使用して Oracle は過去の実行計画の履歴を自動的に維持し 動的な計画の変更が SQL の実行に悪影響を与えないことを確実にするために この情報を使用します Oracle Database 11g パフォーマンスとスケーラビリティ 15

16 データ量 データ配信 システム構成の変更 または他の変更が行われる中で この機能を使用することでアプリケーションが一貫して機能し続けることを確認できます 結論 企業は IT にますます依存するようになっています テクノロジに対する要求は増大し IT 組織は アプリケーション データベース IT インフラストラクチャのスケーラビリティとパフォーマンスを保証する任務を背負っています 30 年以上の技術革新を基盤とする Oracle Database 11g は 企業アプリケーションに次世代のパフォーマンスとスケーラビリティを提供します Oracle Database 11g は IT インフラストラクチャに課されている強力な要求を満たすために 進化を続けるテクノロジ傾向を十分に反映するように設計されています Oracle Database 11g によって 企業はユーザーや顧客を満足させることができ ビジネスの成功への基盤となり これからのテクノロジを先導する役目を果たすことになります Oracle Database 11g パフォーマンスとスケーラビリティ 16

17 Oracle Database 11g パフォーマンスとスケーラビリティ 2007 年 6 月著者 : William Hodak 共著者 : Sushil Kumar Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. 海外からのお問合せ窓口 : 電話 : ファクシミリ : Copyright 2007, Oracle.All rights reserved. 本文書は情報提供のみを目的として提供されており ここに記載される内容は予告なく変更されることがあります 本文書は一切間違いがないことを保証するものではなく さらに 口述による明示または法律による黙示を問わず 特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み いかなる他の保証や条件も提供するものではありません オラクル社は本文書に関するいかなる法的責任も明確に否認し 本文書によって直接的または間接的に確立される契約義務はないものとします 本文書はオラクル社の書面による許可を前もって得ることなく いかなる目的のためにも 電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません Oracle JD Edwards PeopleSoft および Siebel は 米国 Oracle Corporation およびその子会社 関連会社の登録商標です その他の名称はそれぞれの会社の商標です