1. データベース開発ガイド
  2. データベース開発の基礎
  3. パフォーマンスとスケーラビリティ

3 パフォーマンスとスケーラビリティ

この章では、パフォーマンスとスケーラビリティをデータベースおよびデータベース・アプリケーションに組み込む設計技術について説明します。

トピック:

パフォーマンス戦略

トピック:

実行するデータ・モデルの効率的な設計

ここでは、データ・モデリングの重要な概念について簡単に説明します。この点については各種の参考書籍があるため、詳細やガイドについてはそれらを参照してください。

次の基本手順に従って、最も頻繁に実行する重要な問合せのパフォーマンスを最適化するためのデータ・モデルを設計します。

  1. アプリケーションのデータ要件の分析
  2. アプリケーションのデータベース設計の作成
  3. データベース・アプリケーションの実装
  4. データベースとデータベース・アプリケーションのメンテナンス
アプリケーションのデータ要件の分析

アプリケーションのデータ要件を次の基本手順に従って分析します。

  1. データを収集します。

    インタビューを通じてビジネスの内容、アプリケーションの性質、情報の使用者と使用方法、エンドユーザーの要求を把握します。人事フォーム、請求フォーム、注文フォームなどのビジネス・ドキュメントを収集して、ビジネスにおける情報の使用方法を学びます。

  2. 収集したデータを分析します。

    このボトムアップ・プロセスには、データの正規化、エンティティ関連のモデリングおよびトランザクション分析が含まれます。

  3. データの機能分析を行います。

    このトップダウン・プロセスの結果はデータ・フロー・ダイアグラムで、メインのプロセス・ブロックと、各ブロックでの存続期間中のデータの出入りが示されます。

アプリケーションのデータベース設計の作成

データベース設計を作成するには、まず最初に論理設計を作成し、次にこの論理設計を物理設計に変換します。

トピック:

関連項目:

パフォーマンスを考慮した設計と開発の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください

論理設計の作成

論理設計はデータベースのグラフィカルな表現です。論理設計は、アプリケーションのデータベース・オブジェクトとトランザクション・アクティビティ間の両方の関係をモデル化します。効果的な論理設計では、データの所有、アクセス、更新を必要とするユーザーごとに要件を考慮します。

データベース・オブジェクト間の関係をモデル化する手順:

  1. データ要件をデータ項目(列)に変換します。
  2. 関連列を表内にグループ化します。
  3. 列と表の間の関係をマッピングして、各表に対する主キーおよび外部キー属性を決定します。
  4. 冗長性と依存性を最小限にするために表を正規化します。

トランザクション・アクティビティをモデル化する手順:

  • 代表的なトランザクションと、ユーザーにとって最重要と想定されるトランザクションを理解します。

  • 論理モデルを通じてトランザクション・パスを追跡します。

  • SQLでトランザクションをプロトタイプ化し、データベースのサイズを示すボリューム表を開発します。

  • どのユーザーがどの順序でどの表にアクセスするか、そしてどのトランザクションがデータを読み取り、どのトランザクションがデータを書き込むかを決定します。

  • アプリケーションがデータの読取りと書込みのどちらを主に行うかを決定します。

物理設計の作成

物理設計は、物理データベースでの論理設計の実装です。

論理設計は、表と列、表間や表内の関係、および既知のすべてのトランザクション・アクティビティに関する情報を統合するため、データベースがどのようにデータを表に格納し、索引などのその他の構造をどのように作成するかを理解できます。

この知識を使用することで、スキーマ定義の作成にSQLデータ定義言語(DDL)を使用するスクリプトを作成し、必要な順序にデータベース・オブジェクトを定義して、仕様に応じたストレージ要件などを定義します。

データベース・アプリケーションの実装

データベース・アプリケーションを次の基本手順に従って実装します。

  1. アプリケーションをテスト環境で実装します。

    本番環境と可能なかぎり一致するテスト環境で、物理データベース設計を実装するスクリプトを作成します。データを物理スキーマ内にロードします。アプリケーションを開発するためのプログラミング言語を選択し、ユーザー・インタフェースを開発して、トランザクションの作成とテストなどを行います。

  2. アプリケーションが仕様に即して稼働するようにします。

    すべてのコンポーネントが機能していること、アプリケーションが完全に動作すること、そしてアプリケーションで使用されるデータベース機能が適切に構成されていることを確認します。

  3. アプリケーションでベンチマーク・テストを実行します。

    ベンチマーク・テストでは、データおよびユーザーの追加など、リアルタイムの操作をシミュレーションすることで様々なワークロード(ピーク・アクティビティを含む)下で予定どおりにアプリケーションが稼働するかどうかを確認できます。アプリケーションが幅広く順応することを確認します。

    アプリケーションがベンチマークを下回る場合、最初はワークロードがない状態から徐々にワークロードを増やすことで、最適に動作するようにSQL文を調整します。

  4. アプリケーションを本番環境で実装します。

関連項目:

データベースとデータベース・アプリケーションのメンテナンス

データベース、データベース・アプリケーション、オペレーティング・システムのメンテナンスは、データベース管理者、アプリケーション開発者およびシステム管理者がそれぞれ行う継続的なタスクです。ビジネスがメンテナンスに割り当てるリソースは、データベースとデータベース・アプリケーションの重要性、成長に関する潜在的な能力、対応が必要なユーザー数などによって異なります。

メンテナンスの担当者は、システムを定期的に監視し、メンテナンス期間をスケジューリングして、予定されているメンテナンス期間をユーザーに通知する必要があります。メンテナンス期間に停止時間が必要な場合は、データベース・アクティビティがないか少ない時間帯にスケジューリングします。

アプリケーションのメンテナンスには、不具合の修正、パッチの適用、アップグレードのリリースが含まれます。メンテナンス作業は、本番システムに実装する前に、テスト環境で事前にテストして問題を捕捉して解決します。

パフォーマンス目標(メトリック)の設定

次のようなパフォーマンス目標(メトリック)を設定して、アプリケーション開発プロジェクトを開始します。

  • 予想されるアプリケーション・ユーザー数

  • 予想されるピーク・ロード時の1秒当たりのトランザクション数

  • 予想されるピーク・ロード時の問合せレスポンス時間

  • 予想される単位時間(1日、1か月、1年など)当たりの表ごとのレコード数

これらのメトリックを使用してベンチマーク・テストを作成します。

アプリケーションのベンチマーク

ベンチマークは、アプリケーションの性能の局面を測定するテストです。ベンチマークの結果によって、アプリケーション設計が検証されるか、アプリケーションの本番稼働前に解決できる問題が発見されます。

通常は、他の要因による干渉を最小限にするために、分離した単一のユーザー・システムに対して最初にベンチマークを実行します。ベンチマークの結果は、アプリケーションのパフォーマンス・ベースラインになります。意味のあるベンチマーク結果を得るには、アプリケーションを実行する予定の環境でアプリケーションをテストする必要があります。

最も重要なトランザクションのパフォーマンスを測定し、パフォーマンス上の問題に対する複数のソリューションを比較して、パフォーマンスに影響し得る設計上の問題の解決を手助けする小さいベンチマークを作成できます。

ピークのユーザー負荷時やピークのトランザクション負荷時、あるいはその両方でアプリケーションのパフォーマンスを測定するには、それより大きい複雑なベンチマークを開発する必要があります。このようなベンチマークは、ユーザーまたはトランザクションの負荷が徐々に増加する場合は特に重要です。このベンチマークの予算を確保し、計画する必要があります。

アプリケーションの本番環境での稼働後、本番環境でベンチマークを定期的に実行してその結果をデータベース表に保存します。各ベンチマークの実行後、パフォーマンスの低下を許容できないトランザクションの旧レコードと新レコードを比較します。この方式を使用することで、問題の発生時にそれを隔離できます。ユーザーがパフォーマンスに関する不満を述べるまで待っていると、問題の発生時点を判断できなくなる可能性があります。

関連項目:

アプリケーションのベンチマークの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください

パフォーマンスのためのツール

トピック:

アプリケーションに関する実行時パフォーマンス情報をレポートするツールがいくつかあります。

関連項目:

データベースのチューニング用のツールに関する詳細は、『Oracle Database Testingガイド』を参照してください

DBMS_APPLICATION_INFOパッケージ

SQLトレース機能およびOracle TraceとともにDBMS_APPLICATION_INFOパッケージを使用して、実行しているモジュールまたはトランザクションの名前をデータベースに記録します。システム管理者およびパフォーマンス・チューニング担当者はこの記録された情報を使用して、個々のモジュールのパフォーマンスをデバッグ目的のために追跡できます。システム管理者は、モジュール別のリソース使用率をこの情報から追跡することもできます。

アプリケーションをデータベースに登録すると、その名前およびアクションがV$SESSIONおよびV$SQLAREAのビューに記録されます。

DBMS_APPLICATION_INFOパッケージは、V$SESSIONビューで次の列を設定するサブプログラムを提供します。

  • MODULE (アプリケーションまたはパッケージの名前)

  • ACTION (トランザクションまたはパッケージされたサブプログラムの名前)

  • CLIENT_INFO (現在のセッションの初期バインド変数値などの、クライアント・アプリケーションに関する追加情報)

DBMS_APPLICATION_INFOパッケージは、現在のセッションの先行するV$SESSION列から情報を返すサブプログラムも提供します。

DBMS_APPLICATION_INFOパッケージは、結果の表示に数秒以上かかるコマンド(索引の作成や多数の行の更新など)の進行状況の追跡にも使用できます。DBMS_APPLICATION_INFOパッケージは、コマンドに関する情報をV$SESSION_LONGOPSビューに保存するサブプログラムを提供します。V$SESSION_LONGOPSビューには、コマンドの開始時刻、処理の進んだ段階、完了までの推定時間などが表示されます。

関連項目:

SQLトレース機能(SQL_TRACE)

アプリケーションで実行されるすべてのSQL文とPL/SQLブロックを追跡するには、SQLのトレース機能であるSQL_TRACEを使用します。単一の文またはモジュールに対してSQLトレース機能を有効にし、文またはモジュールの実行後に無効にすると、その文またはモジュールのみのトレース情報を取得できます。

最適な結果を得るには、SQLトレース機能をTKPROFおよびEXPLAIN PLAN文とともに使用します。SQLトレース機能は、個々のSQL文に関するパフォーマンス情報を提供します。TKPROFはトレース・ファイルの内容を読取り可能なファイルにフォーマットします。EXPLAIN PLAN文は、オプティマイザによって選択された実行計画を表示し、現在のセッションで実行された場合には指定したSQL文の実行計画を表示します。

トレースする内容と、本番稼働前のアプリケーションのパフォーマンス状況がわかるように、SQLトレース機能はアプリケーションの設計時に使用します。本番環境でパフォーマンス上の問題が大きくなるまで待つと、アプリケーション構造が原因でSQLトレース機能を使用するのがほとんど不可能になる可能性があります。

関連項目:

  • EXPLAIN PLAN文

  • SQL_TRACEおよびTKPROFの詳細は、Oracle Database SQLチューニング・ガイドを参照してください

EXPLAIN PLAN文

SQL文を実行すると、オプティマイザは可能な実行計画をいくつか生成して、各計画のコストを計算し、最もコストの低い計画を使用します。

計画のコストは、SQL文がアクセスする表、索引およびパーティションのデータ分散および記憶特性などの統計に基づいて計算されます。アクセス・パスや結合順序のコストは、I/O、CPU、メモリーなどのコンピュータ・リソースの使用見積りに基づいています。

EXPLAIN PLAN FOR statement文をstatementの実行前に使用すると、EXPLAIN PLAN文はstatementの実行計画を計画表に格納します。計画表を問い合せると、オプティマイザで選択された実行計画を調べることができます。

計画表は実行計画を行ソース・ツリーとして表し、これはSQL文を実行するためにOracle Databaseで使用されるステップを示します。行ソース・ツリーには、文が表を参照する順序、結合操作に影響される表の結合メソッドの他に、フィルタ、ソート、集計などのデータ操作が示されます。また計画表には、最適化に関する情報(各操作のコストやカーディナリティなど)、パーティショニング情報(アクセスされるパーティションのセットなど)、およびパラレル実行情報(結合入力の分散メソッドなど)が含まれます。この情報からは、オプティマイザが実行計画を選択した経緯と理由について、重要な洞察を得ることができます。

データについてオプティマイザで認識されていない情報がある場合、オプティマイザにヒントを提供すると、実行計画が変更されるときがあります。テストによってそのヒントがパフォーマンスを向上させることが確認された場合は、コードでそのヒントを維持します。

注意:

データベースの状態の変化や以降のリリースにおける問合せパフォーマンスの向上によって、ヒントがパフォーマンスに及ぼす影響が大きく変化する場合があるため、ヒントが含まれるコードは定期的にテストする必要があります。

EXPLAIN PLAN文は、EXPLAINされたSQL文をOracle Databaseがどのように実行するかのみを示します。実行環境またはEXPLAIN PLAN環境が変化する場合、オプティマイザは別の実行計画を使用する可能性があります。したがって、SQL計画管理を使用して、SQL計画ベースライン(許容されたSQL文の一連の実行計画)を作成することをお薦めします。

最初に、EXPLAIN PLAN文を使用して文の実行計画を参照します。次に、実行計画をテストし、文の実際のリソース使用量を考慮しながらその適性を検証します。最後に、計画が最適ならば、SQL計画管理を使用します。

関連項目:

  • クエリー・オプティマイザの詳細は、Oracle Database SQLチューニング・ガイドを参照してください

  • 問合せ実行計画の詳細は、Oracle Database SQLチューニング・ガイドを参照してください

  • オプティマイザに対するヒントの影響の詳細は、Oracle Database SQLチューニング・ガイドを参照してください

  • SQL計画管理の詳細は、Oracle Database SQLチューニング・ガイドを参照してください

データベース・パフォーマンスの監視

Oracle Databaseには、データベースの管理とチューニングが可能なアドバイザおよび強力なツールが用意されています。

トピック:

自動データベース診断モニター(ADDM)

自動データベース診断モニター(ADDM)は、自動ワークロード・リポジトリ(AWR)で取得されたデータの分析を行うアドバイザです。ADDMとAWRはOracle Diagnostic Packの一部です。

ADDMはデータベース・パフォーマンス上の問題が存在する可能性がある場所と、実際に存在する場所を判断し、その修正事項を推奨します。

ADDMは各AWRスナップショットの後に分析を実行し、結果をデータベースに保存します。デフォルトでは、AWRスナップショットの間隔は1時間で、ADDM結果の保存期間は8日間です。

Oracle Enterprise Manager Cloud Control (Cloud Control)ではADDM結果が「データベース」ホームページに表示されます。このAWRスナップショット・データではADDM結果を確認できますが、ADDMで提供される分析と推奨事項はありません。(AWRスナップショット・データは、データベース管理者がパフォーマンス分析のために使用したStatspackデータと同様です。)

関連項目:

ADDMの構成、ADDM分析の確認、ADDM結果の解釈、ADDM推奨事項の実装、およびEnterprise Managerによるスナップショット統計の表示の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください

リアルタイムなデータベースのパフォーマンスの監視

Oracle Enterprise Manager Cloud Control (Cloud Control)を使用すると、「パフォーマンス」ページからリアルタイムのデータベース・パフォーマンスを監視できます。「パフォーマンス」ページから、パフォーマンス上の問題を特定するページにアクセスし、次のADDM分析を待たずにその問題を解決することができます。

関連項目:

データベースのパフォーマンスのリアルタイムの監視の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください

パフォーマンス関連のアラートに対する対応

Oracle Enterprise Manager Cloud Control (Cloud Control)の「データベース」ホームページには、データベースによって生成されたパフォーマンス関連のアラートが表示されます。これらのアラートによって示された問題を解決すると、データベース・パフォーマンスが向上します。Oracle Databaseのデフォルトでは、表領域の使用状況、古すぎるスナップショット、リカバリ領域の空き容量低下、再開可能なセッションの一時停止などについてアラートが有効です。メトリックとしきい値の表示、メトリックしきい値の設定、アラートへの対応、アラートのクリア、アラートのダイレクト電子メール通知などを実行できます。このような組込みのアラート・インフラストラクチャを使用すれば、パフォーマンス関連の特殊なアラートについて通知を受信できます。

関連項目:

  • アラートを使用してデータベースの監視とチューニングを行い、アラートを管理する方法の詳細は、『Oracle Database管理者ガイド』を参照してください

  • パフォーマンス・アラートの監視の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください

SQLアドバイザとメモリー・アドバイザ

Oracle Databaseには、データベース・パフォーマンスの向上に効果を発揮するSQLアドバイザとメモリー・アドバイザが用意されています。

SQLアドバイザには、SQLチューニング・アドバイザとSQLアクセス・アドバイザがあり、どちらもOracle Database Tuning Packの一部です。

SQLチューニング・アドバイザは、1つ以上のSQL文を入力として受け取り、特定のチューニング推奨を返します。各推奨には論理および予測されるメリットが含まれます。推奨事項は、オブジェクト統計、新しい索引の作成、SQL文の再構成、およびSQLプロファイルの作成に基づいています。

SQLアクセス・アドバイザを使用すると、指定したSQLワークロードに対して一連のマテリアライズド・ビュー、ビュー・ログ、索引およびパーティションが推奨されるため、SQL問合せのデータ・アクセス・パスを最適化できます。

メモリー・アドバイザには、メモリー・アドバイザ、SGAアドバイザ、共有プール・アドバイザ、バッファ・キャッシュ・アドバイザおよびPGAアドバイザがあります。メモリー・アドバイザは、合計メモリーのターゲット設定、SGAおよびPGAターゲット設定、およびSGAコンポーネントのサイズ設定の分析結果をグラフィカルに表示します。この分析結果は、データベース・パフォーマンスのチューニングや可能性のある状況の計画に使用できます。

関連項目:

  • 各パフォーマンス・アドバイザの簡単な説明も含め、アドバイザを使用してデータベース・パフォーマンスを最適化する方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください

  • メモリー・アドバイザを使用してメモリー使用状況を最適化する方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください

  • データベースのチューニングに使用するツールの詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください

  • SQLチューニング・アドバイザの詳細は、Oracle Database SQLチューニング・ガイドを参照してください

  • SQLチューニング・アドバイザの詳細は、Oracle Database SQLチューニング・ガイドを参照してください

パフォーマンスのテスト

アプリケーションのパフォーマンスをテストする際は、次のガイドラインに従います。

  • 自動データベース診断モニター(ADDM)とSQLチューニング・アドバイザを使用した設計の検証。

    ADDMはデータベース・パフォーマンス上の問題が存在する可能性がある場所を判断し、修正事項を推奨します。たとえば、ADDMが負荷の高いSQL文を発見した場合は、SQLチューニング・アドバイザを使用してその文を分析し、チューニングの推奨を提供できます。

  • 現実的なデータ量とデータ配分によるテスト

    テスト用データベースには、本番システムと同様のデータを入れておく必要があります。表は完全に移入され、本番システムで使用される表間のデータ量やカーディナリティを表すものである必要があります。本番と同様の索引をすべて作成し、スキーマ統計を正しく入力する必要があります。

  • 本番環境で使用されるオプティマイザ・モードによるテスト。

    Oracle Databaseの研究開発の取組みは問合せオプティマイザに重点が置かれているため、テスト環境および本番環境の両方で問合せオプティマイザを使用することをお薦めします。

  • シングル・ユーザーのパフォーマンスの最初のテスト。

    アイドル状態または使用率の低いデータベースで、シングル・ユーザーのテストから開始します。シングル・ユーザーのパフォーマンスが理想的な条件下で許容範囲に達しない場合、実際の条件下で複数のユーザーが許容可能なパフォーマンスを得ることはできません。

  • 各SQL文の実行計画の取得。

    オプティマイザが最適な実行計画を使用しているか、および各SQL文の相対コストがCPU時間と物理I/O数の観点から把握されているかを検証します。最もチューニングを活用する、頻繁に使用されるトランザクションを識別します。

  • 複数のユーザーでのテスト。

    ユーザーのワークロードやプロファイルがまだ完全に定量化されていない可能性があるため、このテストを正確に実行するのは困難です。しかし、複数ユーザー環境でDMLトランザクションをテストして、ロックの競合やシリアライズの問題がないことを確認する必要があります。

  • 可能なかぎり本番システムに近いハードウェア構成でのテスト。

    実際的なシステムでのテストは、ネットワーク待機時間、I/Oサブシステム帯域幅およびプロセッサのタイプと速度についてテストする場合に特に重要です。非現実的なシステムでのテストでは、潜在的なパフォーマンスの問題を見落とす可能性があります。

  • 安定した状態でのパフォーマンスの測定

    各ベンチマークの実行には開始フェーズが必要です。このフェーズでは、ユーザーがデータベースに接続し、アプリケーションを使用して開始します。このフェーズによって、安定した状態に達する前に、頻繁にキャッシュされるデータをキャッシュに初期化し、1回のみ実行する操作(解析など)を完了しておくことができます。同様に、各ベンチマークの実行終了時には終了フェーズが必要です。このフェーズでは、リソースをシステムから解放し、ユーザーはアプリケーションを終了してデータベースから接続を切断します。

関連項目:

クライアント結果キャッシュの使用

トピック:

クライアント結果キャッシュの使用の概要

C、C++、Java (JDBC-OCI)、PHP、Python、RubyおよびPerlを含むOCIライブラリに基づいて構築されたOracle Databaseドライバおよびアダプタを使用するアプリケーションでは、クライアント結果キャッシュを使用することで、繰返しの問合せレスポンス時間を改善できます。

クライアント結果キャッシュにより、クライアント側でのSQL問合せ(SELECT文)結果セットのクライアント・メモリーへのキャッシュが可能になります。クライアント・プロセスから結果を取り出す処理は、データベースのコールおよび問合せの再実行よりも高速で行われるため、頻繁な問合せの実行では、結果がキャッシュされている場合パフォーマンスが大幅に向上します。クライアント結果キャッシュは、問合せの処理で使用されていたサーバーCPU時間も短縮するため、サーバーのスケーラビリティが向上します。

スキーマ、SQLテキスト、バインド変数、セッション設定が類似している場合には、複数のセッションのOCI文が、OCIプロセス・メモリーにキャッシュされた同じ結果セットに一致することもあります。そうでない場合には、問合せの実行はサーバーに送られます。

クライアント結果キャッシュはアプリケーションに対して透過的であり、結果セット・データのキャッシュは、結果セット・データに影響するセッションまたはデータベースの変更内容と整合性が保たれます。

クライアント結果キャッシュを使用するアプリケーションでは、キャッシュ・ヒットがある問合せのパフォーマンスが向上します。このようなアプリケーションは、クライアントまたは中間層でキャッシュされた同じ結果セットを使用します。

クライアント結果キャッシュは、OCIセッション・プール、OCI接続プール、DRCP、およびOCI透過的アプリケーション・フェイルオーバー(TAF)などのOCI機能と連携します。

クライアント結果キャッシュを使用する場合、アプリケーション・レベルでもOCI文キャッシュまたはキャッシュ文を有効化する必要があります。

関連項目:

クライアント結果キャッシュの利点

クライアント結果キャッシュの利点は次のとおりです。

  • クライアント結果キャッシュはクライアント上にあるため、キャッシュ・ヒットが起こると、フェッチ(OCIStmtFetch2())と実行(OCIStmtExecute())の呼出しがローカルで処理され、サーバーのラウンド・トリップは不要になります。サーバーのラウンド・トリップが不要になることで、サーバー・リソース(サーバーCPUやサーバーI/Oなど)の使用量が減少し、パフォーマンスが大幅に向上します。

  • クライアント結果キャッシュは透過的で一貫性があります。

  • クライアント結果キャッシュはあらゆるプロセスに使用可能なため、複数のクライアント・セッションで一致するキャッシュ内の結果セットを同時に使用できます。

  • クライアント結果キャッシュにより、各OCIアプリケーションが独自のカスタム結果キャッシュを持つ必要性が最小限に抑えられます。

  • クライアント結果キャッシュは次の局面を透過的に管理します。

    • 複数のスレッド、複数の文、複数のセッションによる同時アクセス

    • データベースの変更による影響を受けている、キャッシュされた結果セットの無効化

    • キャッシュされた結果セットのリフレッシュ

    • キャッシュ・メモリー管理

  • クライアント結果キャッシュは、JDBC OCI、ODP.NET、OCCI、Pro*C/C++、Pro*COBOLおよびODBCなどの、OCIライブラリを使用するアプリケーションおよびドライバで自動的に使用可能になります。

  • クライアント結果キャッシュでは、サーバー・メモリーよりコストがかからないOCIクライアント・メモリーが使用されます。

  • クライアントのローカル・キャッシュでは、そのクライアントにより実行される問合せについて参照の局所性が向上します。

関連項目:

『Oracle Call Interfaceプログラマーズ・ガイド』のOCIStmtExecute()とOCIStmtFetch2()を参照してください

クライアント結果キャッシュ使用のガイドライン

クライアント結果キャッシュは、次の3つのレベル(優先度が降順で示されています)で有効化または無効化できます。

  1. 問合せ:

    特定の問合せについて、SQLヒントでクライアント結果キャッシュを有効化または無効化できます。SQLヒントを追加または変更するには、アプリケーションを変更する必要があります。

  2. 表

    特定の表に対するすべての問合せについて、アプリケーションを変更せずに表注釈でクライアント結果キャッシュを有効化または無効化できます。

  3. セッション

    データベース・セッション内のすべての問合せについて、アプリケーションを変更せずにセッション・パラメータでクライアント結果キャッシュを有効化または無効化できます。

上位レベルの設定は下位レベルの設定より優先されます。

クライアント結果キャッシュは、読取り専用の表と、ほとんど更新されない表(めったに更新されない表)での問合せに対してのみ、有効化することをお薦めします。つまり、次の場合にクライアント結果キャッシュを有効化します。

  • 読取り専用の表と、ほとんど読み取られない表の問合せに対する問合せレベルのみ

  • 読取り専用の表と、ほとんど読み取られない表に対する表レベルのみ

  • 読取り専用の表、またはほとんど読み取られない表のみを問い合せるアプリケーションを実行中のセッション・レベルのみ

結果セットが大きい、またはバインド値のセット数が多い問合せに対してクライアント結果キャッシュを有効にすると、大量のクライアント結果キャッシュ・メモリーが使用されることがあります。バインド値の各セットでは、(同じSQLテキストに対して)異なるキャッシュ結果セットが作成されます。

クライアントの結果キャッシュが問合せに対して有効な場合、クライアント、サーバー、またはその両方で結果セットをキャッシュできます。クライアント結果キャッシュは、サーバー結果キャッシュ(デフォルトで有効)が無効化されている場合でも有効化できます。

OCIの場合、すべてのOCI文ハンドル・コールにおける最初のOCIStmtExecute()のコールは、キャッシュ内に有効な結果セットがある場合でも、必ずサーバーに対して行われます。各文ハンドルをキャッシュ内の結果セットと照合できるようにするには、OCIStmtExecute()をコールする必要があります。アプリケーションがOCI文ハンドルについて独自の文キャッシュを持つようにするか、またはOCI文キャッシュを使用し、OCIStmtPrepare2()が一度実行されたOCI文ハンドルを戻せるようにすることをお薦めします。同一または異なるセッションからの複数のOCI文ハンドルは、キャッシュ内の同一の結果セットからデータを同時にフェッチできます。

OCIに対して結果セットをキャッシュする場合は、このキャッシュ結果セットを透過的に作成するOCIStmtExecute()コールまたはOCIStmtFetch2()コールで、ORA-01403(「データが見つかりません。」)が返されるまで行をフェッチする必要があります。ローカルにキャッシュされた結果セットと一致する後続のOCIStmtExecute()またはOCIStmtFetch2()のコールでは、最後までフェッチする必要はありません。

関連項目:

トピック:

SQLヒント

SQLヒントRESULT_CACHEまたはNO_RESULT_CACHEは単一の問合せに適用され、そのためにクライアント結果キャッシュが有効化または無効化されます。これらのヒントは、両方の表注釈とRESULT_CACHE_MODEサーバー初期化パラメータよりも優先されます。

OCIの場合、OCIStmtPrepare()コールとOCIStmtPrepare2()コールに渡されるSQLテキストで、SQLヒントの/*+ result_cache */または/*+ no_result_cache */を設定する必要があります。

JDBC OCIの場合、問合せ文字列の一部として、SQLヒント/*+ result_cache */または/*+ no_result_cache */が問合せ(SELECT文)に含まれます。

関連項目:

表注釈

表注釈は特定の表におけるすべての問合せのクライアント結果キャッシュを有効化または無効化します。表注釈はRESULT_CACHE_MODEサーバー初期化パラメータよりも優先されますが、SQLヒント/*+ RESULT_CACHE */および/*+ NO_RESULT_CACHE */は表注釈よりも優先されます。

RESULT_CACHE句を使用して、CREATE TABLEまたはALTER TABLE文のどちらかで表に注釈を付けます。クライアント結果キャッシュを有効にするには、RESULT_CACHE (MODE FORCE)を指定します。無効にするには、RESULT_CACHE (MODE DEFAULT)を使用します。

表3-1に、表注釈の結果キャッシュ・モードをまとめます。

表3-1 表注釈の結果キャッシュ・モード

モード 説明:

DEFAULT

デフォルト値です。結果キャッシュは表レベルでは決定されません。この値を使用して、表注釈を消去できます。

FORCE

問合せのすべての表名がこの設定になっている場合は、問合せにNO_RESULT_CACHEヒントが指定されていないかぎり、その問合せ結果は常にキャッシュの対象となります。問合せで指定した1つ以上の表がDEFAULTに設定されている場合、この問合せにおける有効な表の注釈はDEFAULTです。

関連項目:

セッション・パラメータ

セッション・パラメータRESULT_CACHE_MODEは、データベース・セッションにおけるすべての問合せのクライアント結果キャッシュを有効化または無効化します。RESULT_CACHE_MODEは、特定の表については表注釈より、特定の問合せについてはSQLヒントより優先度が下がります。

RESULT_CACHE_MODEは、サーバー・パラメータ・ファイル(init.ora)、あるいはALTER SESSIONまたはALTER SYSTEM文のいずれかに設定できます。クライアント結果キャッシュを有効にするにはRESULT_CACHE_MODEをFORCEに設定し、無効にするにはRESULT_CACHE_MODEをMANUALに設定します。

関連項目:

RESULT_CACHE_MODEの詳細は、『Oracle Databaseリファレンス』を参照してください

有効な表結果キャッシュ・モード

表の有効な結果キャッシュ・モードは、表3-2に示すように、表注釈の結果キャッシュ・モードとRESULT_CACHE_MODEセッション・パラメータ設定の双方によって異なります。

表3-2 有効な結果キャッシュ表モード

表注釈の結果キャッシュ・モード RESULT_CACHE_MODE = MANUAL RESULT_CACHE_MODE = FORCE

FORCE

FORCE

FORCE

DEFAULT

MANUAL

FORCE

有効なモードがFORCEの場合、問合せにNO_RESULT_CACHEヒントがないかぎり全問合せが結果キャッシュの対象となりますが、実際の結果キャッシュはクライアントおよびサーバーのキャッシュの内部制限、問合せの再利用可能性、およびクライアント結果キャッシュで使用可能な領域によって異なります。

有効な表結果キャッシュ・モードFORCEは、双方が単なるリクエストであるという点で、SQLヒントRESULT_CACHEに類似しています。

有効な表結果キャッシュ・モードの表示

1つ以上の表の結果キャッシュ・モードを表示するには、*_TABLES静的データ・ディクショナリ・ビューのRESULT_CACHE列を参照してください。例:

  • この問合せは表Tの結果キャッシュ・モードを表示します。 

    SELECT result_cache FROM all_tables WHERE table_name = 'T'

  • この問合せは所有するすべてのリレーショナル表の結果キャッシュ・モードを表示します。

    SELECT table_name, result_cache FROM user_tables

結果キャッシュ・モードがDEFAULTの場合、表に注釈は付けられません。

結果キャッシュ・モードがFORCEの場合、表はCREATE TABLEまたはALTER TABLE文のRESULT_CACHE (MODE FORCE)句で注釈が付けられます。

結果キャッシュ・モードがMANUALの場合、セッション・パラメータRESULT_CACHE_MODEは、サーバー・パラメータ・ファイル(init.ora)、あるいはALTER SESSIONまたはALTER SYSTEM文のいずれかでMANUALに設定されています。

関連項目:

静的データ・ディクショナリ・ビュー*_TABLESの詳細は、『Oracle Databaseリファレンス』を参照してください

結果キャッシュ・モードの使用例

SQLヒントが表注釈およびRESULT_CACHE_MODEセッション・パラメータより優先される場合の例を次に示します。

  • emp表がALTER TABLE emp RESULT_CACHE (MODE FORCE)として注釈され、セッション・パラメータがデフォルト値のMANUALである場合は、empに対する問合せは結果キャッシュの対象となります。

    ただし、問合せSELECT /*+ no_result_cache */ empno FROM empの結果はキャッシュされません。これは、SQLヒントが表注釈およびセッション・パラメータより優先されているためです。

  • emp表が注釈されていないか、ALTER TABLE emp RESULT_CACHE (MODE DEFAULT)として注釈され、セッション・パラメータがデフォルト値のMANUALである場合は、empに対する問合せは結果キャッシュされません。

    ただし、問合せSELECT /*+ result_cache */ * FROM empの結果はキャッシュの対象となります。これは、SQLヒントが表注釈およびセッション・パラメータより優先されているためです。

  • セッション・パラメータRESULT_CACHE_MODEがFORCEに設定され、それより優先される表注釈もSQLヒントもない場合は、すべての表に対するすべての問合せが問合せキャッシュの対象となります。

クライアント結果キャッシュで結果がキャッシュされない問合せ

次の問合せの結果は、(問合せにRESULT_CACHEヒントが含まれる場合でも)クライアント結果キャッシュではキャッシュされません。

  • 次のいずれかが含まれる問合せ:

    • リモート・オブジェクト

    • 選択リストの複合型

    • PL/SQL関数

  • スナップショットベースの問合せ

  • フラッシュバック問合せ

  • シリアライズ可能の読取り専用トランザクション内で実行される問合せ

  • 仮想プライベート・データベース(VPD)ポリシーが有効な表の問合せ

サーバーの結果キャッシュ機能が有効である場合、こうした問合せはデータベースにキャッシュされる可能性があります。詳細は、『Oracle Database概要』を参照してください。

クライアント結果キャッシュの一貫性

クライアント結果キャッシュでは、結果セットに影響を与えるすべてのデータベースまたはセッション状態の変更と一致するように、結果セットを透過的に維持します。

トランザクションにより、キャッシュされた結果セットの作成に使用されたデータベース・オブジェクトのデータまたはメタデータが変更された場合、そのキャッシュされた結果セットの無効化が、サーバーへの次のラウンド・トリップ時に送信されます。アプリケーションで一定時間にわたりデータベース・コールが行われない場合、こうした無効化の有無を確認するため、クライアント結果キャッシュの遅延設定により次のOCIStmtExecute()コールによるデータベース・コールが強制的に実行されます。

データベースの無効化に関連するキャッシュされた結果セットはただちに無効化されます。キャッシュされた結果セットからフェッチしているOCI文ハンドルは、その無効化の受信時にフェッチを続行できますが、後続のOCIStmtExecute()コールは結果セットと照合されません。

クライアント結果キャッシュに使用可能な領域がある場合、プロセスによる次回のOCIStmtExecute()コールにより、新規結果セットをキャッシュできます。クライアント結果キャッシュでは、未使用のメモリーが定期的に再生されます。

セッションにオープン・トランザクションがある場合、OCIでは、このトランザクションで変更されたデータベース・オブジェクトを参照する問合せが、クライアント結果キャッシュではなくサーバーに対して行われます。

一貫性を保つこのメカニズムにより、クライアント結果キャッシュはコミットされたデータベースの変更に常に近い状態になります。キャッシュできない問合せ(DML、OCILobコールなど)のため、データベース・ラウンド・トリップに伴う比較的頻繁なコールをアプリケーションが実行する場合、これらのコールによりクライアント結果キャッシュがデータベースの変更と整合するように透過的に保たれます。

表が変更されるとき、トリガーにより別の表が変更されることがあります。クライアント結果キャッシュは、このような変化の影響を受けやすい性質があります。

セッション状態が変わる、たとえばNLSセッション・パラメータが変更されると、問合せ結果が異なる場合があります。クライアント結果キャッシュはこのような変化の影響を受けやすく、それ以降に問合せを実行すると、正しい結果セットが返されます。ただし、プロセス内の他のセッションが一致するように、クライアント結果キャッシュは現在のキャッシュされた結果セットを維持します(そして、無効化しません)。他のプロセスが一致しない場合、これらの結果セットはしばらくして「支配」状態になります。新しいセッション状態に対応する結果セットがキャッシュされます。

アプリケーションにとって、問合せ結果セットに影響するデータベースおよびセッション状態の変化を追跡することは煩雑でエラーも起きやすい処理ですが、クライアント結果キャッシュはそのような変化と結果セットの一貫性を透過的に保ちます。

クライアント結果キャッシュでは、クライアントにおけるスレッドのサポートは必要ありません。

関連項目:

『Oracle Call Interfaceプログラマーズ・ガイド』のOCIStmtExecute()を参照してください

クライアント結果キャッシュに関するデプロイメント時設定

アプリケーションをデプロイする際は、(アプリケーションに変更を加えることなく)クライアント結果キャッシュについて次の要素を設定できます。

  • サーバー初期化パラメータ

  • クライアント構成パラメータ

  • 表注釈

  • RESULT_CACHE_MODEセッション・パラメータ

関連項目:

サーバー初期化パラメータ

アプリケーションのデプロイ時に、クライアント結果キャッシュに設定するサーバー初期化パラメータを次に示します。

COMPATIBLE

互換性を維持しておくOracle Databaseのリリースを指定します。クライアント結果キャッシュを有効にするには、COMPATIBLEが11.0.0.0以上である必要があります。ビューのクライアント結果キャッシュを有効にするには、COMPATIBLEが11.2.0.0以上である必要があります。

CLIENT_RESULT_CACHE_SIZE

OCIクライアント・プロセスごとにクライアント結果セット・キャッシュの最大サイズを指定します。デフォルト値は0(ゼロ)であり、クライアント結果キャッシュが無効であることを示します。クライアント結果キャッシュを有効にするには、CLIENT_RESULT_CACHE_SIZEを32768バイト(32KB)以上に設定します。

CLIENT_RESULT_CACHE_SIZEによってクライアント結果キャッシュがサーバーで有効化されている場合、その値はsqlnet.ora構成パラメータOCI_RESULT_CACHE_MAX_SIZEによって上書きできます。クライアント結果キャッシュがサーバーで無効化されている場合、OCI_RESULT_CACHE_MAX_SIZEは無視され、クライアント結果キャッシュはクライアントで有効化できません。

すべてのOracle Real Application Clusters (Oracle RAC)ノードでクライアント結果キャッシュを有効にするか、すべてのOracle RACノードでクライアント結果キャッシュを無効にすることをお薦めします。そうしないと、1つのクライアント・プロセス内で、一部のセッションではキャッシュが有効で、他のセッションではキャッシュが無効である(したがってサーバーから最新の結果を取得する)可能性があります。この組合せによって、データベースの一貫性のないビューがアプリケーションに提供されることがあります。

CLIENT_RESULT_CACHE_SIZEは静的パラメータです。したがって、ALTER SYSTEM文を使用してCLIENT_RESULT_CACHE_SIZEの値を変更する場合は、SCOPE = SPFILE句を含める必要があり、変更を有効にするにはデータベースの再起動が必要です。

CLIENT_RESULT_CACHE_SIZEの最大値は次の値以上になります。

  • 使用可能なクライアント・メモリー

  • ((キャッシュされる結果セットの可能な数) * (結果セット内の行の平均サイズ) * (結果セット内の行の平均数))

  • 2ギガバイト(GB)

    2GBより大きい値を指定すると、値は2GBになります。

注意:

データベースの作成中は、CLIENT_RESULT_CACHE_SIZEパラメータを設定しないでください。エラーになる場合があります。

CLIENT_RESULT_CACHE_LAG

結果セットに影響するデータベース内の変更からクライアント結果キャッシュが遅延できる最大時間をミリ秒で指定します。デフォルトは、3000ミリ秒です。

CLIENT_RESULT_CACHE_LAGは静的パラメータです。したがって、ALTER SYSTEM文を使用してCLIENT_RESULT_CACHE_LAGの値を変更する場合は、SCOPE = SPFILE句を含める必要があり、変更を有効にするにはデータベースの再起動が必要です。

クライアント構成パラメータ

クライアント構成パラメータはオプションですが、設定されていると、サーバー初期化ファイルinit.ora内の等価のパラメータを上書きします。

クライアント構成パラメータは、oraaccess.xmlファイル、sqlnet.oraファイル、あるいはその両方で設定できます。等価のパラメータを両方のファイルで設定した場合、oraaccess.xml設定の方が、対応するsqlnet.oraの設定より優先されます。パラメータがoraaccess.xmlで設定されていないと、プロセスはsqlnet.ora内の設定を検索します。

クライアント構成パラメータをoraaccess.xmlおよびsqlnet.oraの両方で設定できる場合は、oraaccess.xmlでパラメータを設定することをお薦めします。ただし、ネットワーク構成の場合は、oraaccess.xmlがネットワーク・レベル設定をサポートしないため、sqlnet.oraがプライマリ・ファイルです。

表3-3では、等価のoraaccess.xmlおよびsqlnet.oraクライアント構成パラメータについて説明します。

表3-3 クライアント構成パラメータ(オプション)

oraacess.xmlパラメータ sqlnet.oraパラメータ 説明:

max_size

OCI_RESULT_CACHE_MAX_SIZE

各プロセスのクライアント結果キャッシュの最大サイズ(バイト数)。

sqlnet.oraで32768未満のサイズを指定すると、sqlnet.oraを読み取るクライアント・プロセスのクライアント結果キャッシュが無効になります。

max_rset_size

OCI_RESULT_CACHE_MAX_RSET_SIZE

各プロセスのクライアント結果キャッシュ内の結果セットの最大サイズ(バイト数)。

max_rset_rows

OCI_RESULT_CACHE_MAX_RSET_ROWS

各プロセスのクライアント結果キャッシュ内の結果セットの最大サイズ(行数)。

クライアントでは結果キャッシュの遅延を設定できません。

クライアント結果キャッシュの統計

OCIクライアントからサーバーへのラウンド・トリップで、OCIはクライアント結果キャッシュ統計を定期的にサーバーに送信します。この統計は、CLIENT_RESULT_CACHE_STATS$ビューで示され、正常にキャッシュされた結果セット数、キャッシュ・ヒット数および無効化されたキャッシュ内の結果セット数などが含まれます。問合せのキャッシュ・ミスの数は、クライアント結果キャッシュ統計内の作成数の数以上になります。より正確には、キャッシュ・ミス数はサーバーの自動ワークロード・リポジトリ(AWR)レポート内のサーバー実行数と等しくなります。

関連項目:

  • CLIENT_RESULT_CACHE_STAT$ビューの詳細は、『Oracle Databaseリファレンス』を参照してください

  • クライアント結果キャッシュを実行しているセッションのクライアント・プロセスIDおよびセッションIDについては、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

クライアント結果キャッシュの検証

クライアント結果キャッシュの検証手段を次に示します。

実行時間の測定

まず、RESULT_CACHEヒントなしで問合せの実行時間を測定します。次に、RESULT_CACHEヒントを問合せに追加して、実行時間を再測定します。実行時間の差異がパフォーマンスの向上分に該当します。

V$MYSTATの問合せ

注意:

V$MYSTATビューを問い合せるには、そのビューでのSELECT権限が必要です。

  1. 次の問合せを5回実行します。
    SELECT count(*) FROM table_name
  2. V$MYSTATを問い合せます。
    SELECT * FROM V$MYSTAT
  3. 次の問合せを5回実行します。
    SELECT /*+ result_cache */ count(*) FROM table_name

    問合せ結果はキャッシュされているため、このステップで必要なクライアントおよびサーバー間のラウンド・トリップ数はステップ1の場合より少なくなります。

  4. V$MYSTATを問い合せます。
    SELECT * FROM V$MYSTAT

    この問合せの列の値を、ステップ2の問合せの列の値と比較します。

ステップ3の問合せにヒントを追加するかわりに、ステップ3で表注釈RESULT_CACHE (MODE FORCE)をtable_nameに追加してから、ステップ1の問合せを数回実行できます。

V$SQLAREAの問合せ

注意:

V$SQLAREAビューを問い合せるには、そのビューでのSELECT権限が必要です。

  1. 次の問合せを5回実行します。
    SELECT count(*) FROM table_name
  2. V$SQLAREAを問い合せます。
    SELECT executions, fetches, parse_calls FROM V$SQLAREA
  WHERE sql_text LIKE '% FROM table_name'
  3. 次の問合せを5回実行します。
    SELECT /*+ result_cache */ count(*) FROM table_name
  4. V$SQLAREAを問い合せます。
    SELECT executions, fetches, parse_calls FROM V$SQLAREA
  WHERE sql_text LIKE '% FROM table_name'

    この問合せの列executions、fetchesおよびparse_callsの値を、ステップ2の問合せの列の値と比較します。実行時間の差異がパフォーマンスの向上分に該当します。

ステップ3の問合せにヒントを追加するかわりに、ステップ3で表注釈RESULT_CACHE (MODE FORCE)をtable_nameに追加してから、ステップ1の問合せを数回実行できます。

クライアント結果キャッシュとサーバー結果キャッシュ

クライアント結果キャッシュは、サーバー結果キャッシュとは異なります。クライアント結果キャッシュでは、トップレベルのSQL問合せの結果がOCIクライアント・メモリーにキャッシュされますが、サーバー結果キャッシュでは、結果セットおよび問合せの断片がサーバーSGAメモリーにキャッシュされます。

クライアント結果キャッシュはサーバー結果キャッシュとは関係なく有効化できますが、どちらも結果キャッシュSQLヒント、表注釈、セッション・パラメータRESULT_CACHE_MODEを共有します。表3-4に、結果キャッシュ・パラメータ、PL/SQLパッケージDBMS_RESULT_CACHEおよび結果キャッシュ・ビューに対する結果キャッシュの関連付けを示します。

関連項目:

Oracle Database概要

表3-4 クライアント結果キャッシュとサーバー結果キャッシュの設定

パラメータ、PL/SQLパッケージおよびデータベース・ビュー 結果キャッシュの関連付け

CLIENT_RESULT_CACHE_*パラメータ:

  • CLIENT_RESULT_CACHE_SIZE

  • CLIENT_RESULT_CACHE_LAG

クライアント結果キャッシュ

SQLヒント:

  • RESULT_CACHE

  • NO_RESULT_CACHE

クライアント結果キャッシュ、サーバー結果キャッシュ

sqlnet.ora OCI_RESULT_CACHE*パラメータ:

  • OCI_RESULT_CACHE_MAX_SIZE

  • OCI_RESULT_CACHE_MAX_RSET_SIZE

  • OCI_RESULT_CACHE_MAX_RSET_ROWS

クライアント結果キャッシュ

CLIENT_RESULT_CACHE_STATS$ビュー

クライアント結果キャッシュ

RESULT_CACHE_MODEパラメータ

クライアント結果キャッシュ、サーバー結果キャッシュ

他のすべてのRESULT_CACHE_*パラメータ(RESULT_CACHE_MAX_SIZEなど)

サーバー結果キャッシュ

DBMS_RESULT_CACHEパッケージ

サーバー結果キャッシュ

V$RESULT_CACHE_*およびGV$RESULT_CACHE_*ビュー(V$RESULT_CACHE_STATISTICSおよびGV$RESULT_CACHE_MEMORYなど)

サーバー結果キャッシュ

CREATE TABLE注釈

クライアント結果キャッシュ、サーバー結果キャッシュ

ALTER TABLE注釈

クライアント結果キャッシュ、サーバー結果キャッシュ

クライアント結果キャッシュ・デモ・ファイル

OCIアプリケーションの場合、クライアント結果キャッシュのデモ用ファイルは、cdemoqc.sql、cdemoqc.cおよびcdemoqc2.cです(オペレーティング・システムのdemoディレクトリ内)。

クライアント結果キャッシュの以前のリリースとの互換性

クライアント結果キャッシュを使用するには、アプリケーションのリンクをOracle Database 11gリリース1 (11.1)以上のクライアント・ライブラリに再設定し、Oracle Database 11gリリース1 (11.1)以上のデータベース・サーバーに接続する必要があります。クライアント結果キャッシュは、JDBC Type IIドライバ、OCCI、Pro*C/C++およびODP.NETを含むすべてのOCIアプリケーションで使用できます。OCIドライバは、SQLヒントRESULT_CACHEをOCIStmtPrepare()およびOCIStmtPrepare2()コールに自動的に渡します。

関連項目:

『Oracle Call Interfaceプログラマーズ・ガイド』のOCIStmtPrepare()、OCIStmtPrepare2()を参照してください

文キャッシング

文キャッシュは、セッションごとの文のキャッシュを確立して管理する機能です。サーバーでは、文キャッシュによって文を再解析しなくてもカーソルを使用できるので、繰り返して文を解析する必要がなくなります。文キャッシュは、接続プーリングおよびセッション・プーリングの両方とともに使用でき、パフォーマンスおよびスケーラビリティが向上します。文キャッシュは、セッション・プーリングを使用せずにOCIで、あるいは接続プーリングを使用せずにOCCIで使用でき、またJDBCインタフェースやODP.NETインタフェースでも使用できます。また、動的SQL文を使用するOracleプリコンパイラ・アプリケーション、たとえばPro*C/C++やProCOBOLなどでは、動的SQL文キャッシュも使用できます。

JDBCインタフェースでは、暗黙的および明示的な文キャッシュを互いに関係なく有効または無効にできます。どちらかを使用するか、どちらも使用しないか、または両方とも使用することもできます。暗黙的文キャッシュと明示的文キャッシュは、各接続に対して1つのキャッシュを共有します。特定の文に対して暗黙的なキャッシュを無効にすることも可能です。

関連項目:

OCIクライアント文キャッシュの自動チューニング

OCIクライアント文キャッシュの自動チューニングは、中間層アプリケーションのOCIクライアント・セッション機能を最適化することで、OCIアプリケーションを変更することなく、パフォーマンスを向上できます。

自動チューニングを使用しないと、OCIクライアントの文キャッシュ・サイズ設定は最適状態に及ばなくなる可能性があります。たとえば、ワークロードの変更によってSQL文の別のワーキング・セットが発生する場合です。サイズが小さすぎると、ネットワーク・アクティビティが過剰になり、サーバーでの解析量が増大します。サイズが大きすぎると、メモリーの使用量が超過します。クライアント・アプリケーションが、キャッシュ・サイズを最適に維持することは困難です。

自動チューニングでは、OCI文キャッシュ・サイズが定期的に自動で再構成されることで、このようなパフォーマンス上の潜在的な問題が解決されます。

自動チューニングは、OCI文キャッシュを再構成するオプションを提供するデプロイメント時間設定を指定することで行われます。これらの設定は、クライアントのoraaccess.xmlファイルで接続文字列に基づくデプロイ設定として用意されており、OCI機能のユーザー構成に対するプログラム設定より優先されます。

中間層アプリケーションの開発者とデータベース管理者(DBA)は、それぞれのシステムでOCIクライアントの文キャッシュ・パラメータ設定を自動チューニングすることによって、パフォーマンス上の問題の診断と修正に要する時間と労力の軽減を期待できます。

関連項目:

クライアント側デプロイメント・パラメータ

Oracle Database 12c リリース1 (12.1.0.1)以降では、OCIデプロイメント・パラメータを新しい構成ファイル(oraaccess.xml)で使用できます。

関連項目:

『Oracle Call Interfaceプログラマーズ・ガイド』

問合せ変更通知の使用

連続問合せ通知(CQN)を使用すると、クライアント・アプリケーションがデータベースに問合せを登録し、オブジェクトに対するDMLまたはDDL変更の通知(オブジェクト変更通知(OCN))、あるいは問合せに関連付けられた結果セット変更の通知(問合せ結果変更通知(QRCN))を受信できます。データベースは、DMLトランザクションまたはDDLトランザクションのコミット時に通知を発行します。

CQN登録により、1つ以上の問合せが通知タイプ(OCNまたはQRCN)および通知ハンドラに関連付けられます。CQN登録は、次の方法で作成できます。

  • PL/SQLインタフェース

    PL/SQLインタフェースを使用する場合、通知ハンドラはサーバー側PL/SQLストアド・プロシージャです。PL/SQL登録は、PHPのような非スレッド型の言語およびシステムで使用できます。PHPの場合、PL/SQLリスナーがデータベース通知を受信した段階でPHPコールバックを呼び出します。

  • Oracle Call Interface(OCI)

    OCIを使用する場合、通知ハンドラはクライアント側Cコールバック・プロシージャです。

  • Javaデータベース接続(JDBC)インタフェース

    JDBCインタフェースを使用する場合は、JDBCドライバによってサーバー上に登録が作成されます。JDBCドライバは、サーバーからの通知を(専用チャネルを介して)リスニングする新しいスレッドを起動し、それをJavaイベントに変換してから、この登録に登録されているすべてのリスナーに通知を送ります。

関連項目:

データベース常駐接続プールの使用

データベース常駐接続プール(DRCP)は、データベース接続を取得し、比較的短時間データベースで作業した後、接続を解放するような一般的なWebアプリケーション使用に対して、データベース・サーバーの接続プールを提供します。

トピック:

データベース常駐接続プールの理解

DRCPプール・サーバーのプロセスは、それぞれが専用サーバー・プロセスとデータベース・セッションを組み合せたものと同等であり、これをプール・サーバーと呼びます。プール・サーバーは、同じホストまたは複数のホストで実行されている複数のアプリケーションによる共有が可能です。接続ブローカ・プロセスは、プール・サーバーをデータベース・インスタンスのレベルで管理します。

DRCPはアプリケーション実行時に選択される構成可能な機能です。従来型とDRCPベースの接続アーキテクチャを同時に使用できるようになります。

DRCPは、中間層接続プーリングを実行できないマルチプロセス・シングル・スレッド・アプリケーション・サーバー(PHPやApacheなど)を含むアーキテクチャに特に有効です。DRCPは、数百から数千単位のWebサーバーまたは中間層がデータベース・アクセスとクライアント側プールを必要とする大規模なWebデプロイメントでもきわめて効果的です(Javaのようなマルチスレッド・システムと言語でも)。DRCPを使用すると、データベースは同時接続数を数万にまで増やすことができます。多数の接続に伴ってデータベースWebアプリケーションのスケーリングが必要な場合、接続プーリング・ソリューションとしてDRCPが適しています。

DRCPは、中間層プロセス内のスレッド間で接続を共有する中間層接続プールを補完します。また、DRCPを使用すると、同じ中間層ホスト上の中間層プロセス間でも、複数の中間層ホスト間でも、あるいは複数の中間層(Webサーバー、コンテナ)間でもデータベース接続を共有でき、異なる言語で書かれたアプリケーションにも対応できます。この共有によって、大量のクライアント接続をサポートするために必要となるデータベース・リソースが大幅に減少するため、データベース層のメモリー・フットプリントが縮小し、中間層とデータベース層の両方のスケーラビリティが向上します。すぐに使用できるサーバーのプールを保持することで、クライアント接続の作成と解放のコストも削減されます。

クライアントはDRCPから接続を取得し、これは接続ブローカと呼ばれるOracle Databaseバックグラウンド・プロセスに接続されます。接続ブローカはプール機能を実装し、クライアントからの永続インバウンド接続間でプール・サーバーを多重化します。

クライアントでデータベース・アクセスが必要な場合、接続ブローカがプールからサーバー・プロセスを取得してクライアントに渡します。クライアントはその後、サーバーに直接接続されます。サーバーがクライアント・プロセスを実行すると、サーバー・プロセスはプールに戻され、クライアントからの接続は、接続ブローカに対してクライアント・プロセスからの永続インバウンド接続としてリストアされます。DRCPでは、リソースを解放しても、セッションはそのまま残されますが、接続(サーバー・プロセス)との関連付けは失われます。このセッションは、システム・グローバル領域(SGA)ではなくプログラム・グローバル領域(PGA)にユーザー・グローバル領域(UGA)を格納するため、クライアントはアクティビティの検出時に透過的に接続を再確立できます。

DRCPは通常、接続数の多いアプリケーションで多用されます。共有サーバーは接続数が中程度のアプリケーションに効果的であり、専用セッションは接続数が少ないアプリケーションに適しています。しきい値サイズは、データベース・ホストで使用できるメモリー量によって異なります。

DRCPには次の利点があります。

  • DRCPでは複数のクライアント・アプリケーション間と、中間層アプリケーション・サーバー間でリソース共有が可能です。

  • DRCPではデータベース・ホストでリソース使用量が減少するため、データベースとアプリケーションのスケーラビリティが向上します。

クライアント側接続プーリングおよび共有サーバーと比較した場合は次のとおりです。

  • DRCPは、クライアント側接続プーリングによって用意されるデータベース・サーバーへの直接接続を提供します(クライアント側接続プーリングと同様だが、共有サーバーとは異なる)。

  • DRCPは、データベース・サーバーをプールできます(クライアント側接続プーリングおよび共有サーバーと同様)。

  • DRCPは、セッションをプールできます(クライアント側接続プーリングと同様だが、共有サーバーとは異なる)。

  • DRCPは、中間層の境界間で接続を共有できます(クライアント側接続プーリングとは異なる)。

DRCPは、データベース・リソースの使用率を最小限に抑えたまま、多数の接続が必要となる環境でのスケーラビリティ要件に対応できる、独自の接続プーリング・ソリューションです。

関連項目:

  • DRCPアーキテクチャの詳細は、『Oracle Database概要』を参照してください

  • 切替えサービス拡張の詳細は、『Oracle Database管理者ガイド』を参照してください。

DRCPの構成

DRCPはデフォルトでインストールされますが、DBAはDBMS_CONNECTION_POOLパッケージを使用してDRCPを起動および構成する必要があります。構成オプションには、プール・サーバーの最小数と最大数、接続ブローカの数、各接続ブローカが処理する接続の最大数などがあります。

Oracle Database 12c リリース2 (12.2.0.1)以降では、新しいMAX_TXN_THINK_TIMEパラメータを使用して、オープンになっているトランザクションのあるクライアントが終了する前に許可される非アクティブの最大時間を指定します。これは、トランザクションのないクライアントよりも長い時間を許可するように設定できます(MAX_THINK_TIMEパラメータ値を指定)。これにより、効率的なプールの再利用が可能ですが、不完全なトランザクションの終了に長時間かかります。

OCIセッション・プールAPIは、DRCPと相互運用するために拡張されています。

関連項目:

プロキシ・セッションの共有

Oracle Database 12c リリース2 (12.2.0.1)以降では、DRCPのプロキシ・セッションが同じスキーマに接続されているアプリケーション間で共有されます。

DRCPでのJDBCの使用

Oracle Database 12cリリース1 (12.1.0.1)から、Oracle JDBCドライバはDRCPをサポートしています。DRCPの実装によってサーバー側にプールが作成され、それが複数のクライアント・プール間で共有されます。これらのクライアント・プールは、JDBCのユニバーサル接続プールを使用します。ユニバーサル接続プールを使用することで、(サーバー上でサーバー・プロセスの数が減少するために)メモリー消費量が少なくなり、データベース・サーバーのスケーラビリティが向上します。

サーバー側接続のチェックインおよびチェックアウト操作を追跡するために、Javaアプリケーションはクライアント側プール(JDBCのユニバーサル接続プールまたは任意のサードパーティのJava接続プールなど)を使用する必要があります。

クライアント側でDRCPを有効にするには、次の操作を行う必要があります。

  • NULL以外で空でないString値を接続プロパティoracle.jdbc.DRCPConnectionClassに渡します。

  • 長い接続文字列で(SERVER=POOLED)を渡します。

次のように、短いURLフォームでも(SERVER=POOLED)を指定できます。 

jdbc:oracle:thin:@//<host>:<port>/<service_name>[:POOLED]

例:

jdbc:oracle:thin:@//localhost:5221/orcl:POOLED

接続プロパティoracle.jdbc.DRCPConnectionClassを使用して、サーバー上のすべてのプール・サーバー・プロセスに同じDRCP接続クラス名を設定すると、複数の接続プール間でサーバー上のプール・サーバー・プロセスを共有できます。

DRCPでは、特定の接続にタグを適用し、タグ付き接続を後から簡単に取得することもできます。

関連項目:

DRCPでのOCIセッション・プールAPIの使用

OCIセッション・プールAPIのOCISessionPoolCreate()、OCISessionGet()およびOCISessionRelease()は、DRCPと相互運用されます。

OCIアプリケーションは、OCISessionPoolCreate()を呼び出して、DRCP用のOCIセッション・プールの環境を初期化します。これは『Oracle Call Interfaceプログラマーズ・ガイド』に説明があります。

DRCP用のOCIセッション・プールからセッションを取得するため、OCIアプリケーションはOCI_SESSGET_SPOOLをmodeパラメータに指定してOCISessionGet()を呼び出します。

DRCP用のOCIセッション・プールにセッションを解放するため、OCIアプリケーションはOCISessionRelease()を呼び出します。

パフォーマンスを向上するため、OCIセッション・プールは接続ブローカへの接続を透過的にキャッシュできます。OCIアプリケーションは、authInfopパラメータをOCI_ATTR_CONNECTION_CLASSに設定してOCISessionGet()を呼び出し、接続クラス名を指定するか、またはOCISessionGet()を呼び出す前にOCIAuthInfoハンドルを使用することで、類似の状態でアプリケーションがセッションを終了したセッションを再利用できます。

DRCPは、タグ付け、文キャッシュおよびTAFなどの、従来のクライアント側OCIセッション・プールにより提供されていた機能もサポートします。

関連項目:

セッション純正値および接続クラス

Oracle Database 11gリリース1 (11.1)では、OCISessionGet()を使用してセッションを取得するときに指定できる2つの設定、つまりセッション純正値と接続クラスがOCIに導入されました。

トピック:

セッション純正値

セッション純正値では、OCIアプリケーションがプールされたセッションを再利用できる(OCI_SESSGET_PURITY_SELF)か、新しいセッションを使用する必要がある(OCI_SESSGET_PURITY_NEW)かを指定します。

アプリケーションは、OCISessionGet()を呼び出す前にOCIAuthInfoハンドルで、あるいはOCISessionGet()を呼び出すときにmodeパラメータ内で、セッション純正値を設定できます。

関連項目:

  • 接続プーリング・アプリケーションで新規セッションを設定する方法は、例3-1を参照してください。

例3-1 新規セッションのセッション純正値の設定

/* OCIAttrSet method */
ub4 purity = OCI_ATTR_PURITY_NEW; 
OCIAttrSet(authInfop, OCI_HTYPE_AUTHINFO, &purity, (ub4)sizeof(purity) OCI_ATTR_PURITY, errhp);

/*  OCISessionGet mode method */  
OCISessionGet (envhp, errhp, &svchp, authInfop, poolName, poolNameLen, NULL, 0, NULL, NULL, NULL, OCI_SESSGET_SPOOL);
/* poolName is the name returned by OCISessionPoolCreate() */

注意:

プールされたセッションを再利用する場合、サーバーのNLS属性がクライアントのNLS属性よりも優先されます。

たとえば、クライアントでNLS_LANGがfrench_france.us7asciiに設定されており、プールからドイツ語のセッションが割り当てられている場合、クライアント・セッションはドイツ語となります。

この問題を回避するには、接続クラスを使用して共有を制限します。

Connectionクラス

接続クラスには、OCIアプリケーションで必要な接続のタイプの論理名を定義します。プールされたセッションに接続クラスがある場合、OCIはセッションがその接続クラス外で共有されないように保証します。

たとえば、接続クラスはプールされたセッションを次の要素が共有することを防止します。

  • 異なるユーザー

    (ユーザーHRに対して最初に作成されたセッションは、ユーザーHRによる後続のリクエストのみに割り当てられます。)

  • 同じユーザーの異なるセッション

  • 同じユーザーによって実行中の異なるアプリケーション

    (各アプリケーションは固有の接続クラスを保有できます。)

接続クラスを設定するには、OCIAuthInfoハンドルのOCI_ATTR_CONNECTION_CLASS属性を使用できます。接続クラス名は最大長1024バイトの文字列で、アスタリスク(*)は使用できません。

例: 接続クラスをHRMSとして設定

接続クラスをHRMSとして設定するには、OCISessionPoolCreate APIを使用できます。

例3-2は、HRMSアプリケーションが接続クラスHRMSのセッションを必要としていることを示します。

例3-2 接続クラスをHRMSとして設定

OCISessionPoolCreate (envhp, errhp, spoolhp, &poolName, &poolNameLen, "HRDB",
    strlen("HRDB"), 0, 10, 1, "HR", strlen("HR"), "HR", strlen("HR"),
    OCI_SPC_HOMOGENEOUS);
 
OCIAttrSet (authInfop, OCI_HTYPE_AUTHINFO, "HRMS", strlen ("HRMS"),
    OCI_ATTR_CONNECTION_CLASS, errhp);
OCISessionGet (envhp, errhp, &svchp, authInfop, poolName, poolNameLen, NULL, 0,
    NULL, NULL, NULL, OCI_SESSGET_SPOOL);
例: 接続クラスをRECMSとして設定

接続クラスをRECMSとして作成するには、OCISessionPoolCreate APIを使用できます。

例3-3は、採用アプリケーションが接続クラスRECMSのセッションを必要としていることを示します。

例3-3 接続クラスをRECMSとして設定

OCISessionPoolCreate (envhp, errhp, spoolhp, &poolName, &poolNameLen, "HRDB",
    strlen("HRDB"), 0, 10, 1, "HR", strlen("HR"), "HR", strlen("HR"),
    OCI_SPC_HOMOGENEOUS);
 
OCIAttrSet (authInfop, OCI_HTYPE_AUTHINFO,  "RECMS", strlen("RECMS"),
    OCI_ATTR_CONNECTION_CLASS, errhp);
OCISessionGet (envhp, errhp, &svchp, authInfop, poolName, poolNameLen, NULL, 0,
    NULL, NULL, NULL, OCI_SESSGET_SPOOL);
セッション純正値および接続クラスのデフォルト

表3-5に、OCIアプリケーションがOCIセッション・プール(OCISessionGet()を使用して)および他のソースから取得する接続の属性および設定のデフォルトを示します。

表3-5 セッション純正値および接続クラスのデフォルト

属性または設定 OCIセッション・プールからの接続のデフォルト値 OCIセッション・プール以外からの接続のデフォルト値

OCI_ATTR_PURITY

OCI_ATTR_PURITY_SELF

OCI_ATTR_PURITY_NEW

OCI_ATTR_CONNECTION_CLASS

OCIセッション・プールのすべての接続についてデフォルトの接続クラスとして使用されるクライアント側の各セッション・プールに対する、OCIで生成されたグローバル一意名

SHARED

セッションの共有

OCIセッション・プールからのセッションを要求するスレッド

SHARED接続クラスを保有する特定のデータベースへの接続

データベース常駐接続プールの開始

DBAはSYSDBAとしてログオンし、DBMS_CONNECTION_POOL.START_POOLをデフォルト設定で使用して、デフォルト・プールSYS_DEFAULT_CONNECTION_POOLを開始する必要があります。

関連項目:

DRCPの有効化

アプリケーションでDRCPを有効にするには、簡易接続文字列で:POOLEDを指定(例3-4を参照)するか、TNS接続文字列で(SERVER=POOLED)を指定(例3-5を参照)します。

例3-4 簡易接続文字列で:POOLEDを指定してDRCPを有効化

oraclehost.company.com:1521/books.company.com:POOLED

例3-5 TNS接続文字列でSERVER=POOLEDを指定してDRCPを有効化

BOOKSDB = (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=oraclehost.company.com)
 (PORT=1521))(CONNECT_DATA = (SERVICE_NAME=books.company.com)(SERVER=POOLED)))

OCIアプリケーションにおけるDRCPの拡張性による利点

次のOCIアプリケーション・シナリオと、DRCPがそれぞれにもたらすメリットについて検討します。

  • アプリケーションがOCIセッション・プールを使用せず、接続クラスや純正値設定も指定(またはPURITY=NEWを指定)しない場合。

    アプリケーションはDRCPから新規セッションを取得します。アプリケーションが接続をプールに戻す場合、デフォルトによりこのセッションは同じアプリケーションの他のインスタンスと共有されません。したがって、クライアント・セッションが存続する間、プールされたサーバーはクライアントに割り当てられたままになります。(SQL*Plusは、OCIセッション・プールを使用しないクライアントの一例です。SQL*Plusは接続がアイドルのときでも、接続を保持し続けます。)

    アプリケーションは既存のプール・サーバーを再利用できるというメリットを得られます。

  • アプリケーションがOCIセッション・プール外のOCISessionGet()を呼び出すか、接続クラスおよびPURITY=SELFを指定する場合。

    アプリケーションは、DRCPプール・サーバーおよびセッションを両方とも再利用できます。ただし、OCISessionRelease()コールの後、OCIは接続ブローカへの接続を終了します。次回のOCISessionGet()コールでは、アプリケーションはブローカに再接続して、DRCPは指定された接続クラスに属するプール・サーバー(およびセッション)を割り当てます。再接続では接続の確立および再認証のコストが発生します。

    アプリケーションはDRCPリソース(プロセスおよびセッション)をより効率的に共有できますが、接続ブローカへの接続のキャッシュからメリットは得られません。

  • アプリケーションがOCIセッション・プールAPIを使用し、接続クラスを指定し、PURITY=SELFを指定する場合。

    アプリケーションは、プール・サーバーおよび関連付けられたセッションの両方を再利用して、接続ブローカへのキャッシュされた接続からメリットを得ることで、すべてのDRCP機能を使用します。キャッシュされた接続では、OCISessionGet()コールで再認証のコストが発生しません。

関連項目:

OCISessionPoolCreate()

OCISessionGet()

OCISessionRelease(),

OCISessionPoolDestroy()

JavaアプリケーションにおけるDRCPのスケーラビリティの利用

ユニバーサル接続プール(UCP)を使用する、または接続ファクトリとしてConnectionPoolDataSourceを使用しているユーザーは、(コードではなく)構成のみを変更することでDRCPを使用するようにアップグレードできます。

関連項目:

DRCPの使用に関するベスト・プラクティス

DRCPを最大限に活用できるアプリケーションを設計するステップは、OCIセッション・プールを使用するアプリケーションに必要なステップとよく似ています。

唯一の追加ステップとして、DRCPとともに動作するようデプロイされた場合、最大限のパフォーマンスを得るために、アプリケーションで明示的に接続クラスを指定する必要があります。

最大限のパフォーマンスを得て、さらにDRCPリソースの共有機能を強化するため、同じアプリケーションの複数のインスタンスは、同じ接続クラスを指定する必要があります。アプリケーションの複数のインスタンスでデータベース・セッションを共有できることを確認してください。

例3-6は、DRCPアプリケーションを示しています。

関連項目:

例3-6 DRCPアプリケーション

/* Assume that all necessary handles are allocated. */
 
/*   This middle tier uses a single database user. Create a homogeneous
     client-side session pool */
OCISessionPoolCreate (envhp, errhp, spoolhp, &poolName, &poolNameLen, "BOOKSDB",
    strlen("BOOKSDB"), 0, 10, 1, "SCOTT", strlen("SCOTT"), "password",
    strlen("password"), OCI_SPC_HOMOGENEOUS);
 
while (1)
{
   /* Process a client request */
   WaitForClientRequest();
   /* Application function */
 
   /* Set the Connection Class on the OCIAuthInfo handle that is passed as
      argument to OCISessionGet*/
   
   OCIAttrSet (authInfop, OCI_HTYPE_AUTHINFO,  "BOOKSTORE", strlen("BOOKSTORE"),
               OCI_ATTR_CONNECTION_CLASS, errhp);
 
   /* Purity need not be set, as default is OCI_ATTR_PURITY_SELF
      for OCISessionPool connections */
 
   /* You can get a SCOTT session released by Middle-tier 2 */
   OCISessionGet(envhp, errhp, &svchp, authInfop, poolName, poolNameLen, NULL, 0,
                 NULL, NULL, NULL, OCI_SESSGET_SPOOL); 
 
   /* Database calls using the svchp obtained above  */
   OCIStmtExecute(...)
 
   /* This releases the pooled server on the database for reuse */
   OCISessionRelease (svchp, errhp, NULL, 0, OCI_DEFAULT);
}
 
/* Middle tier is done - exiting */
OCISessionPoolDestroy (spoolhp, errhp, OCI_DEFAULT);

例3-7と例3-8では、例3-6からBOOKSTOREアプリケーションを提供する10個の中間層ホストにコードをデプロイする接続文字列を示しています。

例3-7では、データベースが専用サーバー・モードでDRCPは有効化されていないOracle Database 12c (またはそれ以下)であり、クライアントに12cライブラリがあると仮定しています。アプリケーションはデータベースから専用サーバー接続を取得します。

例3-7 専用サーバー・モードでDRCPを使用しないデプロイメントに対する接続文字列

BOOKSDB = (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=oraclehost.company.com)
 (PORT=1521))(CONNECT_DATA = (SERVICE_NAME=books.company.com)))

例3-8では、Oracle Database 12cデータベースでDRCPが有効であると仮定します。すべての中間層プロセスがDRCPのプーリング機能を利用できます。DRCPのデータベース・リソース要件は、専用サーバー・モードでの要件より大幅に少なくなります。

例3-8 DRCPを使用するデプロイメントに対する接続文字列

BOOKSDB = (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=oraclehost.company.com)
 (PORT=1521))(CONNECT_DATA = (SERVICE_NAME=books.company.com)(SERVER=POOLED)))

互換性と移行

Oracle Database 12cクライアント・ライブラリにリンクされたOCIアプリケーションは、次のそれぞれに対して変更なしで動作します。

  • DRCPを無効にしたOracle Database 12cデータベース

  • Oracle Database 12cより前のリリースのデータベース・サーバー

  • DRCPを有効にしたOracle Database 12cデータベース・サーバー(DRCP接続文字列を使用してデプロイした場合)

前述のとおりにOCIセッション・プールAPIを接続クラスおよび純正値設定とともに使用するようクライアントが適切に変更されていれば、そのクライアントはDRCPにより提供される高度なスケーラビリティを利用できます。

関連項目:

DRCPの制限事項

プール・サーバーでは、次の操作を実行できません。

  • データベースの停止

  • DRCPの停止

  • 接続済ユーザーのパスワードの変更

  • 共有データベース・リンクを使用した、異なるインスタンスにあるDRCPへの接続

  • TCPSによるアドバンスト・セキュリティ・オプション(ASO)の使用

  • DRCPによるエンタープライズ・ユーザー・セキュリティの使用

  • (OCI_MIGRATEオプションを使用して)直接的に、または(OCISessionPoolCreate()を起動して)間接的に、サーバー側の移行可能なセッションを使用

  • 初期クライアント・ロールの使用

  • (OCI_ATTR_APPCTX_NAMEおよびOCI_ATTR_APPCTX_VALUEなどの)アプリケーション・コンテキスト属性の使用

DDL文実行の前に作成されたセッションは、DDL文実行後にクライアントに割当てできます。したがって、プール内のデータベース・ユーザーに影響するDDL文の実行時は注意してください。たとえば、ユーザーを削除する前に、そのユーザーのセッションがプール内に存在せず、そのユーザーとして認証されたブローカへの接続がないことを確認します。

明示的なロールが有効なセッションがプールに解放される場合、後でデフォルトのログイン・ロールを必要とする(同じユーザーの)接続に割り当てることができます。したがって、明示的なロールのあるセッションは解放せずに、かわりにセッションを終了してください。

注意:

暗号化やDRCPを使用した厳密認証などのOracle Advanced Security機能を使用できます。

ユーザーは、データの暗号化とデータの整合性の組合せを混在させることができます。ただし、ユーザーは接続クラスを使用して、このような組合せをそれぞれ分離する必要があります。たとえば、ユーザー・アプリケーションが、暗号化メカニズムとして、ある接続セットにAES256を指定し、別の接続セットにはDESを指定する必要がある場合、アプリケーションは各セットに異なる接続クラスを指定する必要があります。

カスタム・プールでのDRCPの使用

すでにDRCP、FANおよびRLBと統合されている、OCIセッション・プールを使用することを強くお薦めします。ただし、次のいずれかがtrueの場合、OCIセッション・プールを使用しないアプリケーションではDRCPを引き続き使用できます。

  • アプリケーションが独自のカスタム接続プールを使用して作成されている場合。

  • アプリケーションでプールは使用されないが、セッションを使用しない期間があり(したがってそれをプールに解放でき)、同じセッションを取り戻すことに依存しない場合

DRCPをこのようなアプリケーションで使用するには、セッションがステートフルである必要があります。つまり、セッションにOCI_ATTR_SESSION_STATE属性が必要です。アプリケーションがステートフルでDRCPが有効な場合、OCIはDRCPプールから適切なセッションを透過的に割り当てます。アプリケーションがステートレス(OCI_SESSION_STATELESS属性がある)でDRCPが有効な場合、OCIはセッションを透過的にDRCPプールに返します。

基本のデータベース・リソースの効率的な利用のために、アプリケーションではセッション状態をできるだけ速やかに識別する必要があります。

注意:

属性OCI_ATTR_SESSION_STATEまたはOCI_SESSION_STATELESSを指定するアプリケーションは、セッション純正値および接続クラスも指定する必要があります。

関連項目:

明示的なステートフルまたはステートレス・セッションのマーキング

通常、アプリケーションは、1つの作業単位の期間において特定のデータベース・セッションを必要とします。この期間中、セッションはステートフルです。この期間の後、後続の作業単位のために特定のセッションを維持することにアプリケーションが依存しない場合、セッションはステートレスです。

ステートフルからステートレス(あるいは逆)へのセッションの変化をアプリケーションまたはコール元が検出すると、アプリケーションはOCI_ATTR_SESSION_STATEまたはOCI_SESSION_STATELESS属性を使用して変化をOCIに明示的に通知できます。この情報によってOCIおよびOracle Databaseは、アプリケーションが使用していないセッションを別のユーザーに再度割り当てて、必要になった場合はアプリケーションに新規セッションを割り当てるなどの、スケーラビリティ最適化を透過的に実行します。

関連項目:

カスタム・プールでのDRCPの使用

例3-9は、セッションの状態を明示的にマークするコードの一部を示しています。

例3-9 明示的なステートフルまたはステートレス・セッションのマーキング

wait_for_transaction_request();
do {
 
ub1 state;
 
/* mark  database session as STATEFUL  */
state = OCI_SESSION_STATEFUL;
checkerr(errhp, OCIAttrSet(usrhp, OCI_HTYPE_SESSION,
        &state, 0, OCI_ATTR_SESSION_STATE, errhp));
/* do database work consisting of one or more related calls to the database */
 
...
 
/* done with database work, mark session as stateless */
state = OCI_SESSION_STATELESS;
checkerr(errhp, OCIAttrSet(usrhp, OCI_HTYPE_SESSION,
         &state, 0,OCI_ATTR_SESSION_STATE, errhp));
 
wait_for_transaction_request();
 
} while(not _done);

OCIセッション・プールの外部で取得されたセッションは、OCI_SESSION_STATEFULとマークされ、アプリケーションによって明示的にOCI_SESSION_STATELESSとマークされないかぎり、OCI_SESSION_STATEFULが保たれます。

OCIセッション・プールから取得されたセッションは、最初のコールがそのセッションで開始されるときに、デフォルトでOCI_SESSION_STATEFULとマークされます。セッションがプールに解放されるときは、デフォルトでOCI_SESSION_STATELESSとマークされます。したがって、OCIセッション・プールの使用時はセッションをステートフルまたはステートレスとして明示的にマークする必要はありません。

関連項目:

OCI_ATTR_SESSION_STATEの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください

Oracle Real Application ClustersでのDRCPの使用方法

Oracle Real Application Clusters (Oracle RAC)は、単一データベースを複数ノードにある複数インスタンスで管理するデータベース・オプションです。Oracle RAC環境のデータベースでDRCPが構成されているとき、プールの構成は各データベース・インスタンスに適用されます。1つのインスタンスでプールを起動または停止すると、すべてのインスタンスのプールが起動または停止されます。

プラガブル・データベースでのDRCPの使用

注意:

マルチテナント・コンテナ・データベースは、Oracle Database 20cでサポートされる唯一のアーキテクチャです。ドキュメントが改訂されている間は、従来の用語が残っている可能性があります。ほとんどの場合、「データベース」と「非CDB」は、コンテキストに応じてCDBまたはPDBを指しています。アップグレードなどのコンテキストでは、「非CDB」が以前のリリースの非CDBを指す場合もあります。

マルチテナント・コンテナ・データベース(CDB)でのDRCPは、ルート・コンテナで構成および管理されます。プールの構成、開始および停止は、ルート・コンテナに接続しているときに実行できます。このプールは、クライアントが様々なサービス名を使用して接続する、様々なプラガブル・データベースのプール・サーバーを管理します。

DRCPとData Guard

Data Guard環境でDRCPが動作する場合は次のようになります。

  • フィジカル・スタンバイ・データベースの場合、次のように実行します。

    • プールを起動できるのは、プールがプライマリ・データベースで実行中の場合のみです。

    • プールを停止できるのは、プールがプライマリ・データベースで停止している場合のみです。

    • プール・パラメータの構成、デフォルトへの復元または変更を行うことはできません。

    物理スタンバイ・データベースがプライマリ・データベースになると、前述した制限事項は物理スタンバイ・データベースに適用されなくなります。

  • ロジカル・スタンバイ・データベースでは、すべてのプール操作を行うことができます。

Memoptimizeプール

このプールでは、SELECT文の読取り操作が最適化されます

Memoptimize Rowstoreは、MEMOPTIMIZE FOR READ句で指定した表の高パフォーマンスの読取りを実行します。

注意:

遅延挿入は、標準のロックとREDOのメカニズムが使用されないため、ロールバックできません

関連トピック

Oracle RACシャーディング

この項では、Oracle RACのシャーディングについて説明します

Oracle RACシャーディングでは、最小限のアプリケーション変更でOracle RACデータベースのパフォーマンスおよびスケーラビリティが向上します。表パーティションをOracle RACインスタンスと結び付け、データベース・リクエストをルーティングします。これは、対応するパーティションを論理的に保持するインスタンスへのパーティション化キーを指定します。これにより、キャッシュ利用が効率的になり、インスタンスにまたがるブロックpingが削減されます。パーティション化キーは、最大パフォーマンス・クリティカル・リクエストに対してのみ追加できます。キーを指定しないリクエストは透過的に機能し、どのインスタンスにもルーティングできます。この機能は、ALTER SYSTEMコマンドを実行して使用可能にすることができ、データベース・スキーマおよびSQL文を変更する必要はありません。

注意:

データベース接続を要求するときには、パーティション化キーの値を指定する必要があります。

関連トピック