設計およびデプロイメント方法

13 設計およびデプロイメント方法

この章では、Oracle Real Application Clusters(Oracle RAC)環境でのデータベースの設計およびデプロイメント方法について簡単に説明します。また、高可用性を実現するための考慮事項を説明し、Oracle RACの様々なデプロイメントに関する一般的なガイドラインを示します。

この章の内容は次のとおりです。

高可用性を実現するOracle RACのデプロイ

多数のお客様がOracle RACを実装してそれぞれのOracle Databaseアプリケーションで高可用性を実現しています。真の高可用性を得るには、アプリケーションのインフラストラクチャ全体を高可用性にする必要があります。これには、インフラストラクチャ全体でシングル・ポイント障害の発生をなくすための詳細な計画が必要です。Oracle RACによってデータベースが高可用性になったとしても、重要なアプリケーションが使用不可になれば、ビジネスに悪影響が生じる可能性があります。たとえば、認証にLightweight Directory Access Protocol(LDAP)を使用する場合は、LDAPサーバーを高可用性にする必要があります。データベースが起動していても、LDAPサーバーへのアクセスに障害があってユーザーがデータベースに接続できないと、ユーザーにはシステム全体が停止しているように見えます。

この項には次のトピックが含まれます:

高可用性システムの設計について

ミッション・クリティカルなシステムの場合は、フェイルオーバーとリカバリが実行可能であることに加えて、あらゆるタイプの障害に対して環境にリジリエンスがある必要があります。

ミッション・クリティカルなシステムの場合は、フェイルオーバーとリカバリが実行可能であることに加えて、あらゆるタイプの障害に対して環境にリジリエンスがある必要があります。これらの目標に到達するには、ビジネスのサービス・レベルの要件を定義することから始めます。この要件には、データ・センター内の障害(ノード障害など)または障害時リカバリ(データ・センター全体に障害が発生した場合)に対する最大のトランザクション応答時間およびリカバリ予測の定義が含まれる必要があります。通常、サービス・レベルの目標は、障害の内容にかかわらず、作業の目標応答時間になります。各冗長コンポーネントにリカバリ時間を設定します。アクティブ/アクティブ・モードで実行されている複数のハードウェア・コンポーネントがある場合でも、1つのコンポーネントに障害が発生したときに、そのコンポーネントの修理中に、他のハードウェア・コンポーネントが稼働状態を保持できるとは想定しないでください。また、コンポーネントがアクティブ・モードまたはパッシブ・モードで実行されている場合は、通常のテストを実行してフェイルオーバー時間を検証します。たとえば、ストレージ・チャネルのリカバリ時間は、何分もかかる場合があります。停止時間がビジネスのサービス・レベル契約の範囲内であることを確認し、この範囲を超えている場合は、ハードウェア・ベンダーと協力して構成および設定をチューニングします。

ミッション・クリティカルなシステムをデプロイする場合は、テストに機能試験、破壊試験および性能試験を含める必要があります。破壊試験では、システム内に様々な障害を発生させてリカバリをテストし、サービス・レベルの要件に適合しているかどうかを確認します。また、破壊試験によって、本番システム用の操作手順を作成できます。

ミッション・クリティカルなシステムまたは高可用性システムの設計と実装を支援するため、Oracleでは規模に関係なくすべての組織に適用可能な様々なソリューションを提供しています。小規模な作業グループとグローバル企業が同じように組織の重要なビジネス・アプリケーションの可用性を拡張できます。Oracleとインターネットを使用することで、現在では常にどこからでも確実にアプリケーションとそのデータにアクセスできます。Oracle Maximum Availability Architecture(MAA)は、Oracleの実証済高可用性テクノロジと推奨事項に基づいたOracleのベスト・プラクティスのブループリントです。MAAの目的は、最適な高可用性アーキテクチャの設計から複雑な仕組みを排除することです。

関連項目

Oracle Maximum Availability Architecture(MAA)

高可用性環境でOracle RACをデプロイするためのベスト・プラクティス

アプリケーションは、Oracle Database、Oracle ClusterwareおよびOracle RACの多数の機能を使用してOracle RAC環境の障害を最小限に抑えたり、マスクすることができます。たとえば、次のことが可能です。

VIPアドレスを使用してデータベースに接続することで、TCP/IPのタイムアウト待機時間をなくします。
詳細な操作手順を作成し、インフラストラクチャ内のすべてのコンポーネントに対して、定義されたサービス・レベルを満たす適切で有効なサポート契約があることを確認します。
接続時フェイルオーバー、高速接続フェイルオーバー、高速アプリケーション通知、ロード・バランシング・アドバイザなどのOracle RACの自動ワークロード管理機能を使用します。
個別のボリューム・グループに投票ディスクを配置して、I/Oスループットの低下による停止を減らします。x個の投票デバイスの障害に対応するには、2x + 1個のミラーを構成します。
Oracle Database Quality of Service Management (Oracle Database QoS Management)を使用して、システムを監視し、パフォーマンスのボトルネックを検出します。
約2ミリ秒(ms)以下のI/Oサービス時間でOCRを配置します。
FAST_START_MTTR_TARGET初期化パラメータを使用してデータベース・リカバリをチューニングします。
Oracle Automatic Storage Management(Oracle ASM)を使用してデータベース記憶域を管理します。
厳密変更制御手順が有効であることを確認します。
LDAP、NIS、DNSなどの周辺のインフラストラクチャに高可用性およびリジリエンスがあることを確認します。これらのエンティティは、Oracle RACデータベースの可用性に影響します。可能な場合は、ローカルのバックアップ手順を定期的に実行します。
Oracle Enterprise Managerを使用して、Oracle RACデータベースのみでなく、Oracle RAC環境全体を管理します。Oracle Enterprise Managerを使用して、サービスの作成と変更、およびクラスタ・データベース・インスタンスとクラスタ・データベースの起動と停止を実行できます。
Recovery Manager (RMAN)を使用して、データ・ファイル、制御ファイル、サーバー・パラメータ・ファイル(SPFILE)およびアーカイブREDOログ・ファイルのバックアップ、リストアおよびリカバリを実行します。RMANをメディア・マネージャとともに使用すると、ファイルを外部記憶域にバックアップできます。また、Oracle RACデータベースのバックアップまたはリカバリの実行時にパラレル化を構成できます。Oracle RACでは、RMANのチャネルは、すべてのOracle RACインスタンス間で動的に割り当てられます。チャネルのフェイルオーバーによって、1つのノード上で失敗した操作を別のノードで継続できます。RMANは、Oracle Enterprise Manager Backup Managerまたはコマンドラインから実行できます。
順序番号を使用している場合、常にNOORDERオプションを指定したCACHEを使用することによって、順序番号生成のパフォーマンスを最適化します。ただし、CACHEオプションを使用すると、連続しない順序番号が生成される場合があります。連続しない順序番号を使用できない環境では、NOCACHEオプションを使用するか、または順序番号の事前生成を検討してください。アプリケーションでは順序番号の順序付けが必要で、連続しない順序番号を使用できる場合は、CACHEおよびORDERを使用して、Oracle RACの順序番号のキャッシュおよび順序付けを行います。アプリケーションで連続した順序番号の順序付けが必要な場合は、NOCACHEおよびORDERを使用します。NOCACHEとORDERの組合せは、その他のキャッシュおよび順序付けの組合せと比較すると、パフォーマンスに最も大きな影響を及ぼします。

ノート:
連続しない順序番号を使用できない環境では、順序番号の事前生成を検討するか、またはORDERおよびCACHEオプションを使用してください。

Oracle Database 18c以降では、大規模な順序キャッシュを構成するかわりに、スケーラブルな順序を使用して、データのロードのスケーラビリティを向上させることができます。特に順序値が表の主キー列の移入に使用される場合、スケーラブルな順序により同時データ・ロード操作のパフォーマンスが向上します。
索引を使用する場合は、逆キー索引などの方法を検討してパフォーマンスを最適化します。逆キー索引は、挿入日付に基づいた索引のように、索引の一方に頻繁に挿入を行う場合に特に有効です。

関連項目

クラスタ内の単一または複数のデータベースでの複数のアプリケーションの統合

多くのユーザーは、複数のアプリケーションの単一データベースへの統合および複数のデータベースの単一クラスタへの統合を望んでいます。Oracle ClusterwareおよびOracle RACは、両方のタイプの統合をサポートしています。

Oracle ASMによって管理された単一の記憶域のプールでクラスタを作成すると、インフラストラクチャで複数のデータベースを(シングル・インスタンス・データベースか、またはOracle RACデータベースかに関係なく)管理できます。

統合時の容量管理

Oracle RACデータベースの場合は、ワークロードの要件に基づいてインスタンスの数、および指定されたデータベースのインスタンスを実行するノードを調整できます。クラスタで管理されるサービスなどの機能を使用すると、単一データベースまたは複数のデータベース間で複数のワークロードを管理できます。

作業を追加する場合は、クラスタの容量を適切に管理することが重要です。クラスタを管理するプロセス(Oracle Clusterwareとデータベースの両方からのプロセスを含む)は、CPUのリソースを適時に取得できる必要があり、システム内で優先度が高く設定される必要があります。Oracle Database Quality of Service Management(Oracle Database QoS Management)は、パフォーマンス目標を満たすようにCPUリソースを動的に割り当てることで、クラスタまたはデータベース内での複数のアプリケーション統合を支援します。クラスタ構成ポリシーを使用して、クラスタ・レベルのリソースを管理することもできます。

関連項目

Oracle Database Quality of Service Managementユーザーズ・ガイド

統合時のグローバル・キャッシュ・サービス・プロセスの管理

サーバー上のリアルタイム・グローバル・キャッシュ・サービス・プロセス(LMSn)の数は、プロセッサ数と同じか、それより少なくすることをお薦めします。(これは、コアを含めて認識されるCPUの数です。たとえば、デュアル・コアCPUは、2つのCPUとみなされます。)ノード上にインスタンスを追加するときは、システムで負荷試験を実行して、ワークロードをサポートするのに必要な容量があることを確認することが重要です。

多数の小規模なデータベースをクラスタに統合する場合は、Oracle RACインスタンスによって作成されるLMSnの数を減らす必要がある場合があります。デフォルトでは、サーバーで検出されるCPUの数に基づいてプロセスの数がOracle Databaseによって算出されます。この計算の結果、LMSnプロセスがOracle RACインスタンスで必要とされるプロセス数より多くなることがあります。1つのLMSプロセスは、最大4個のCPUで対応できます。LMSnプロセスの数を減らすには、GC_SERVER_PROCESSES初期化パラメータを手動で最小限度の1の値に設定します。CPU4個ごとに、アプリケーションで必要とされるプロセスを1つ追加します。通常は、ビジー状態のLMSnプロセスを少なくすることをお薦めします。Oracle Databaseはインスタンスの起動時にプロセスの数を算出するため、その値を変更するにはインスタンスを再起動する必要があります。

統合へのDatabase Cloudの使用

データベース・クラウドは、Global Data Servicesフレームワークによって、単一の仮想サーバーに統合された一連のデータベースであり、1つ以上のグローバル・サービスを提供すると同時に、高いパフォーマンス、可用性、およびリソースの使用率の最適化を実現します。

Global Data Servicesでは、これらの仮想化リソースを最小限の管理オーバーヘッドで管理し、追加のクライアント要求を処理するために迅速にデータベース・クラウドを拡張できます。クラウドを構成するデータベースは、グローバルに分散させることができ、クライアントは、サービス名を指定するのみでデータベース・クラウドに接続でき、クラウドのコンポーネントやトポロジを把握する必要はありません。

データベース・クラウドは、複数のデータベース・プールで構成できます。データベース・プールは、データベース・クラウド内の一連のデータベースであり、一意のグローバル・サービス・セットを提供し、特定の管理ドメインに属しています。クラウド・データベースを複数のプールにパーティション化すると、サービス管理が簡素化され、かつ、各プールを異なる管理者が管理できることによって、セキュリティが向上します。データベース・クラウドは、複数の地理的リージョンにまたがることができます。リージョンは、互いに近くに存在すると考えられるデータベース・クライアントおよびサーバーが含まれる論理的な境界です。通常、1つのリージョンが1つのデータ・センターに対応しますが、データ・センター間のネットワーク待機時間が、これらのデータ・センターにアクセスするアプリケーションの品質保証契約を満たす場合、複数のデータ・センターを同じリージョンに配置できます。

グローバル・サービスによって、ローカルまたはグローバルに分散している、疎結合の異機種データベースを、スケーラブルで可用性の高いプライベート・データベース・クラウドに統合できます。このデータベース・クラウドは、地球上のすべてのクライアントで共有できます。プライベート・データベース・クラウドを使用すると、使用可能なリソースの使用率が最適化され、データベース・サービスのプロビジョニングが簡素化されます。

関連項目

Oracle Database Global Data Services概要および管理ガイド

Oracle RACのスケーラビリティ

Oracle RACでは、複数のシステムからデータの個別コピーへのトランザクションに一貫性のある同時アクセスが可能です。単一のサーバーの容量を超えたスケーラビリティも実現します。アプリケーションが対称マルチプロセッシング(SMP)サーバーで透過的にスケール変更する場合は、そのアプリケーションはアプリケーション・コードを変更しなくてもOracle RACで適切にスケール変更すると想定できます。

従来、データベース・サーバーが容量を超えて実行される場合は、より大きな新しいサーバーに置き換えられてきました。サーバーの容量が大きくなると、価格も上がります。ただし、Oracle RACデータベースには、容量を増やすための別の手段があります。

従来はより大きいSMPサーバーで実行していたアプリケーションを移行して、小規模なサーバーのクラスタで実行できます。
現行のハードウェアへの投資を維持し、新しいサーバーをクラスタに追加する(あるいは新しいクラスタを作成または追加する)ことで、容量を増やすことができます。

Oracle ClusterwareおよびOracle RACを使用してクラスタにサーバーを追加する場合、停止は必要ありません。新規インスタンスが起動されると同時に、アプリケーションは追加された容量を使用できます。

クラスタ内のすべてのサーバーは、同じオペレーティング・システムと同じバージョンのOracle Databaseを実行する必要がありますが、各サーバーの容量を揃える必要はありません。Oracle RACを使用すると、要件にあったクラスタ(デュアルCPUの汎用サーバーで構成されるクラスタや、32または64のCPUが組み込まれたサーバーで構成されるクラスタなど)を構築できます。Oracleのパラレル実行機能を使用すると、1つのSQL文を複数のプロセスに分割でき、それぞれのプロセスで作業のサブセットが実行されます。Oracle RAC環境では、パラレル・プロセスをユーザーが接続されているインスタンスでのみ実行するように定義したり、クラスタ内の複数のインスタンス間で実行するように定義することができます。

関連項目

Oracle RACの設計に関する一般的な考慮事項

この項では、Oracle RAC環境でのデータベースの設計およびデプロイメント方法について簡単に説明します。また、高可用性を実現するための考慮事項を説明し、Oracle RACの様々なデプロイメントに関する一般的なガイドラインを示します。

Oracle RACデータベース上にデプロイするアプリケーションの設計および開発時には、次のステップの実行を検討してください。

設計とアプリケーションのチューニング
メモリーとI/Oのチューニング
競合のチューニング
オペレーティング・システムのチューニング

ノート:

アプリケーションをSMPシステムで拡張できない場合は、アプリケーションをOracle RACデータベースに移動してもパフォーマンスは向上しません。

挿入集中型オンライン・トランザクション処理(OLTP)アプリケーションには、ハッシュ・パーティション化を使用することを検討します。ハッシュ・パーティション化の特長は次のとおりです。

単一データベース構造への同時挿入による競合を軽減します。
索引がローカルで表を使用してパーティション化され、表が順序ベースのキーでパーティション化されている場合、順序ベースの索引に適用されます。
アプリケーションに対して透過的です。

OLTP環境に対して表および索引のハッシュ・パーティション化を使用すると、Oracle RACデータベースでのパフォーマンスが大幅に向上します。ハッシュ・パーティション化された索引では、索引レンジ・スキャンは使用できないことに注意してください。

Oracle RACでのデータベースの一般的なデプロイメント

この項では、Oracle RACデータベースをデプロイする際の考慮事項について説明します。ここで説明する方法を採用しない場合でも、Oracle RACデータベースのパフォーマンスが低下することはありません。効率的な非クラスタ設計であれば、アプリケーションはOracle RACデータベースで効率的に実行されます。

この項には次のトピックが含まれます:

Oracle RACでの表領域の使用

ローカル管理表領域の使用の他に、自動セグメント領域管理(ASSM)および自動UNDO管理を使用して領域管理をさらに簡単にすることができます。

ASSMでは、挿入を行うためのブロックの各インスタンスのサブセット間にインスタンスのワークロードが分散されます。これによってブロック転送が最小限に抑えられるため、Oracle RACパフォーマンスが向上します。自動UNDO管理をOracle RAC環境にデプロイするには、各インスタンスに固有のUNDO表領域が必要です。

Oracle RACでのオブジェクトの作成およびパフォーマンス

原則として、DDL文の使用はメンテナンス・タスクのみに限定し、システム操作のピーク時には実行しないようにします。ほとんどのシステムでは、新しいオブジェクトの生成量とその他のDDL文に対する制限が必要です。非クラスタのOracle Databaseの場合と同様に、オブジェクトの作成と削除が多くなるとパフォーマンスのオーバーヘッドが増加する可能性があります。

Oracle RACでのノードの追加と削除およびSYSAUX表領域

Oracle RACデータベース環境にノードを追加する場合は、SYSAUX表領域のサイズを大きくする必要があります。また、クラスタ・データベースのノードを削除する場合は、SYSAUX表領域のサイズを小さくできる場合もあります。

分散トランザクションおよびOracle RAC

Oracle RAC環境でXAトランザクションを実行しているときに、そのパフォーマンスが低い場合は、1つ以上のOracle RACインスタンスでの複数のOracle Distributed Transaction Processing (DTP)サービスの作成により、密結合分散トランザクションのすべてのブランチを同じインスタンスに割り当てます。

各DTPサービスは、1つのみのOracle RACインスタンスで使用可能な単一のサービスです。分散トランザクション処理のためのデータベース・サーバーへのアクセスは、すべてDTPサービスを経由する必要があります。単一のグローバル分散トランザクションのすべてのブランチが、同じDTPサービスを使用することを確認してください。つまり、TNS名やJDBC URLなどのネットワーク接続記述子には、分散トランザクション処理をサポートするためにDTPサービスを使用する必要があります。

関連項目

Oracle RACでのOLTPアプリケーションのデプロイ

Oracle RACデータベースはキャッシュ・フュージョンによって、オンライン・トランザクション処理(OLTP)アプリケーションに最適なデプロイメント・サーバーになります。これは、これらのアプリケーションには次の要件があるためです。

障害発生時の高可用性
増加するシステム需要に対応するためのスケーラビリティ
需要変動に応じたロード・バランシング

Oracle DatabaseおよびOracle RACの高可用性機能は、処理を中断することなく、障害が発生していないインスタンスにワークロードを再分散し、ロード・バランシングを実行できます。さらに、Oracle RACは、優れたスケーラビリティも提供するため、ノードを追加または置換した場合、Oracle Databaseは、リソースを再マスター化してロードの処理を再分散します。

キャッシュ・フュージョンによる柔軟な実装

オンライン・トランザクション処理システムの頻繁に変化するワークロードに対応するには、Oracle RACは、システム負荷やシステム可用性が変化しても、柔軟かつ動的に対応します。Oracle RACは、たとえば次のような原因で変動する幅広いサービス・レベルに対応します。

ユーザーの需要の変化
取引の集中(大量取引の発生)など、ピーク時のスケーラビリティの問題
システム・リソースの可用性の変化

Oracle RACでのデータ・ウェアハウス・アプリケーションのデプロイ

この項では、Oracle RAC環境でのデータ・ウェアハウス・システムのデプロイ方法について説明します。また、共有ディスク・アーキテクチャで使用可能なデータ・ウェアハウス機能についても説明します。

この項には次のトピックが含まれます:

Oracle RACでのデータ・ウェアハウス・アプリケーションのスピードアップ

Oracle RACは、Oracle Databaseの非クラスタのメリットを拡大するため、データ・ウェアハウス・アプリケーションには理想的です。Oracle RACは、Oracle RACデータベースに属するすべてのノード上で使用可能な処理能力を最大限に活用して、データ・ウェアハウス・システムをスピードアップおよびスケールアップすることによって、Oracleのシングル・インスタンスのメリットを拡大します。

クエリー・オプティマイザは、最適な実行計画の判断に、パラレル実行を検討します。クエリー・オプティマイザのデフォルトのコスト・モデルはCPU+I/Oで、コスト単位は時間です。Oracle RACでは、クエリー・オプティマイザが、プロセッサ数に基づいてパラレル化の適切なデフォルト値を動的に計算します。代替アクセス・パスのコスト評価(表スキャンと索引アクセスなど)では、操作に使用できる並列度が考慮されます。これによってOracle Databaseは、Oracle RAC構成用に最適化された実行計画を選択します。

データ・ウェアハウス・システムおよびOracle RACにおけるパラレル実行

パラレル実行は、複数のプロセスを使用して1つ以上のCPUでSQL文を実行し、また、非クラスタOracle DatabaseとOracle RACデータベースの両方で使用可能です。

Oracle RACは、パラレル処理をすべての利用可能なインスタンスに分散することによってパラレル実行を十分に活用します。パラレル操作に使用できるプロセスの数は、各表または索引に割り当てられる並列度によって異なります。

関連項目

Oracle RACでのデータ・セキュリティの考慮事項

この項では、2つのOracle RACセキュリティの考慮事項について説明します。内容は次のとおりです。

透過的データ暗号化およびキーストア

Oracle Databaseでは、Oracle RACノードはキーストア(ウォレット)を共有できます。これにより、すべてのノードにわたってキーストアを手動でコピーし同期化する必要がなくなります。共有ファイル・システム上にキーストアを作成することをお薦めします。これにより、すべてのインスタンスが同じ共有キーストアにアクセスできます。

Oracle RACは、次の方法でキーストアを使用します。

任意の1つのOracle RACインスタンスで実行されるキーストアのオープンやクローズなどの任意のキーストア操作は、他のすべてのOracle RACインスタンスに適用されます。つまり、1つのインスタンスでキーストアをオープンおよびクローズすると、すべてのOracle RACインスタンスでキーストアがオープンおよびクローズされます。
共有ファイル・システムを使用する場合は、すべてのOracle RACインスタンスのENCRYPTION_WALLET_LOCATIONパラメータが、必ず同じ共有キーストアの場所を指すようにします。また、セキュリティ管理者は、適切なディレクトリ権限を割り当てることによって、共有キーストアのセキュリティを確保する必要もあります。
ノート:

オペレーティング・システムでOracle Automatic Storage Management Cluster File System (Oracle ACFS)が使用可能な場合は、キーストアをOracle ACFSに格納することをお薦めします。Oracle ASMにOracle ACFSがない場合は、Oracle ASMコンフィギュレーション・アシスタント(ASMCA)を使用して作成してください。次のように、各インスタンスのsqlnet.oraファイルに、マウント・ポイントを追加する必要があります。
```
ENCRYPTION_WALLET_LOCATION=
  (SOURCE = (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY = /opt/oracle/acfsmounts/data_keystore)))
```
このファイル・システムは、インスタンスの起動時に自動的にマウントされます。キーストアのオープンとクローズ(およびTDEマスター暗号化キーの設定またはキー更新およびローテーションを行うコマンド)は、すべてのノード間で同期化されています。
ある1つのインスタンスで実行されるmaster key rekeyは、すべてのインスタンスに適用されます。新しいOracle RACノードは、起動されると、現在のキーストアの状態(オープンまたはクローズ)を認識します。
マスター・キーを設定または変更している場合は、キーストアのADMINISTER KEY MANAGEMENT SET KEYSTORE OPENまたはCLOSE SQL文は発行しないでください。

Oracleでは、Oracle RACノードごとの個別のTDEウォレットの使用はサポートされていません。かわりに、Oracle RAC環境でTDE用の共有ウォレットを使用してください。これによってすべてのインスタンスが、同じ共有ソフトウェア・キーストアにアクセスできます。

関連項目

Oracle Database Advanced Securityガイド

Windowsファイアウォールの考慮事項

デフォルトにより、Windows Server 2003 Service Pack 1以上のすべてのインストレーションにおいて、Windowsファイアウォールは、着信接続に対するほとんどすべてのTCPネットワーク・ポートをブロックできます。そのため、TCPポート上で着信接続をリスニングするOracle製品はすべて、これらのどの接続要求も受信せず、これらの接続を行っているクライアントはエラーを報告します。

インストールするOracle製品およびその使用方法によって、Windows Server 2003でファイアウォール製品が機能するように、Windowsのインストール後の追加の構成作業を実行する必要があります。

ウォレットを使用してONSクライアントを安全に実行

SSL証明書を構成および使用して、データベース層のONSサーバーと中間層の通知クライアント間の認証を設定できます。

JDBC接続プールまたはOracle Universal Connection Poolなどで使用する高速接続フェイルオーバーなどのOracle RAC機能は、Oracle RACノードで実行されているOracle Notification Service (ONS)の通知をサブスクライブします。これらの接続は通常認証されません。

Oracle Database 18c以降、Oracle Grid Infrastructureのインストールにデフォルトのウォレットが作成されます。
中間層でクライアント側ONSデーモンを実行している場合は、次の2つの構成が可能です。
- (OracleAS 10.1.3.xなどの) OPMNからONSを起動する場合。この構成にはopmn.xmlを使用します。
- (ONSCTLの使用時など)スタンドアロンでONSを起動する場合。この構成にはons.configを使用します。
最初の構成については、Oracle Application ServerリリースのOPMN管理者ガイドを参照してください。この構成では、ウォレットの場所を指定するために、opmn.xmlファイルを変更します。

2つ目の構成については、クライアント側ONSデーモンが異なるサーバー上で実行される可能性があります。ステップ1のウォレットをクライアント側サーバーにコピーし、そのクライアント側サーバー上のパスをons.configファイルまたはopmn.xmlファイルに指定します。
クライアント側のONSデーモンなしでリモートONS構成を実行する場合は、クライアント側のサーバーを構成します。
1. クライアント・クラスタにONSリソースをエクスポートします。
  次のようなコマンドを使用します。cluster_nameはリモート・クラスタの名前です。また、filenameは、資格証明のデータを書き込むファイルの名前です。
```
$ srvctl export ons -clientcluster cluster_name -clientdata filename
```
2. クライアント側サーバーでパスを指定します。
  ons.configファイルまたはopmn.xmlファイルを変更して、コピーしたファイルの場所を指すようにします。

関連項目

ハング・マネージャの概要

ハング・マネージャは、ハングを自律的に解決し、リソースの可用性を維持するOracle Real Application Clusters (Oracle RAC)環境の機能です。

ハング・マネージャはデフォルトで有効になっており、次の処理を実行します。

データベースのハングおよびデッドロックの確実な検出
データベースのハングおよびデッドロックの自律的な解決
Oracle Database QoSのパフォーマンス・クラス、ランクおよびSLAを維持するためのポリシーのサポート
すべての検出および解決のログ記録
感度(Normal/High)およびトレース・ファイルのサイズを構成するためのSQLインタフェースの提供

データベースは、セッションによって1つ以上のセッションのチェーンがブロックされた場合にハングします。ブロックしているセッションによってロックやラッチなどのリソースが保持され、ブロックされているセッションの進捗が妨げられます。セッションのチェーンには、チェーン内のその他すべてのセッションをブロックするルートまたは最終ブロッカ・セッションがあります。ハング・マネージャは、ハングを検出して解決することによって、これらの問題を自律的に解決します。

ハング・マネージャのアーキテクチャ

ハング・マネージャは、データベース内のDIA0タスクとして自律的に実行されます。

ハング・マネージャは、次の3つのフェーズで機能します。

検出: このフェーズでは、ハング・マネージャによってすべてのノードのデータが収集され、別のセッションで保持されているリソースを待機しているセッションが検出されます。
分析: このフェーズでは、ハング・マネージャによって検出フェーズで検出されたセッションが分析され、セッションが潜在的な遅延の一部であるかどうかが判別されます。セッションが遅延している可能性がある場合、ハング・マネージャは特定のしきい値期間の間待機して、セッションが遅延していることを確認します。
検証: このフェーズでは、しきい値期間の経過後に、ハング・マネージャによってセッションが遅延していることが検証され、遅延の原因となっているセッションが選択されます。

遅延の原因となっているセッションを選択すると、ハング・マネージャによってそのセッションに解決方法が適用されます。セッションのチェーンまたは遅延が自動的に解決された場合は、ハング・マネージャによって遅延の解決方法は適用されません。ただし、遅延が自動的に解決されない場合、ハング・マネージャは遅延の原因となっているセッションを終了することで遅延を解決します。セッションの終了が失敗した場合は、ハング・マネージャによってセッションのプロセスが終了されます。このプロセス全体は自律型であり、リソースを長期間ブロックせず、パフォーマンスに影響を与えません。

たとえば、遅延したセッションのチェーンに高ランクのセッションが含まれている場合は、ハング・マネージャにより、遅延の原因となっているセッションの終了が迅速に実行されます。遅延の原因となっているセッションの終了によって、高ランクのセッションが長時間待機することが回避され、高ランクのセッションのパフォーマンス目標が維持されます。

ハング・マネージャのオプションの構成

感度を調整し、ハング・マネージャで使用されるログ・ファイルのサイズと数を制御できます。

感度

ハング・マネージャが遅延を検出した場合、セッションが遅延していることを確認するために、特定のしきい値期間の間待機します。しきい値期間を変更するには、DBMS_HANG_MANAGERを使用してsensitivityパラメータをNormalまたはHighに設定します。sensitivityパラメータがNormalに設定されている場合、ハング・マネージャはデフォルトの期間待機します。ただし、sensitivityがHighに設定されている場合は、期間が50%削減されます。

デフォルトでは、sensitivityパラメータはNormalに設定されています。ハング・マネージャの感度を設定するには、SQL*PlusでSYSユーザーとして次のコマンドを実行します。

sensitivityパラメータをNormalに設定するには、次のようにします。

exec dbms_hang_manager.set(dbms_hang_manager.sensitivity, dbms_hang_manager.sensitivity_normal);

sensitivityパラメータをHighに設定するには、次のようにします。

exec dbms_hang_manager.set(dbms_hang_manager.sensitivity, dbms_hang_manager.sensitivity_high);

トレース・ログ・ファイルのサイズ

ハング・マネージャは、ファイル名に_base_を含むトレース・ファイルに、遅延の詳細な診断を記録します。base_file_size_limitパラメータを使用して、トレース・ファイルのサイズ(バイト単位)を変更します。SQL*Plusで次のコマンドを実行して、たとえば、トレース・ファイルのサイズを100 MBに設定します。

exec dbms_hang_manager.set(dbms_hang_manager.base_file_size_limit, 104857600);

トレース・ログ・ファイルの数

ハング・マネージャのベース・トレース・ファイルはトレース・ファイル・セットの一部です。base_file_set_countパラメータを使用して、トレース・ファイル・セット内のトレース・ファイルの数を変更します。SQL*Plusで次のコマンドを実行して、たとえば、トレース・ファイル・セット内のトレース・ファイルの数を6に設定します。

exec dbms_hang_manager.set(dbms_hang_manager.base_file_set_count,6);

デフォルトでは、base_file_set_countパラメータは5に設定されています。

ハング・マネージャの診断およびロギング

ハング・マネージャは自律的に遅延を解決し、解決内容をデータベースのアラート・ログに、診断をトレース・ファイルに継続的に記録します。

ハング・マネージャは、インシデント・コードORA-32701の自動診断リポジトリ(ADR)インシデントとして、解決をデータベースのアラート・ログに記録します。

また、遅延の検出に関する詳細な診断をトレース・ファイルで確認できます。トレース・ファイルとアラート・ログのファイル名はdatabase instance_dia0_で始まります。

トレース・ファイルは$ ADR_BASE/diag/rdbms/database name/database instance/incident/incdir_xxxxxxディレクトリに格納されます。
アラート・ログは$ ADR_BASE/diag/rdbms/database name/database instance/traceディレクトリに格納されます。

例13-1 ローカル・インスタンスのハング・マネージャ・トレース・ファイル

この例では、ローカル・データベース・インスタンスのハング・マネージャで表示される出力例を示します

Trace Log File .../oracle/log/diag/rdbms/hm1/hm11/incident/incdir_111/hm11_dia0_11111_i111.trc
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
...
*** 2016-07-16T12:39:02.715475-07:00
HM: Hang Statistics - only statistics with non-zero values are listed

            current number of active sessions 3
              current number of hung sessions 1
  instance health (in terms of hung sessions) 66.67%
       number of cluster-wide active sessions 9
         number of cluster-wide hung sessions 5
   cluster health (in terms of hung sessions) 44.45%

*** 2016-07-16T12:39:02.715681-07:00
Resolvable Hangs in the System
                      Root       Chain Total               Hang
   Hang Hang          Inst Root  #hung #hung  Hang   Hang  Resolution
     ID Type Status   Num  Sess   Sess  Sess  Conf   Span  Action
  ----- ---- -------- ---- ----- ----- ----- ------ ------ -------------------
      1 HANG RSLNPEND    3    44     3     5   HIGH GLOBAL Terminate Process
  Hang Resolution Reason: Although hangs of this root type are typically
    self-resolving, the previously ignored hang was automatically resolved.

例13-2 ハングしたセッションを示すアラート・ログ内のエラー・メッセージ

この例では、プライマリ・インスタンスに関するハング・マネージャのアラート・ログの例を示します

2016-07-16T12:39:02.616573-07:00
Errors in file .../oracle/log/diag/rdbms/hm1/hm1/trace/hm1_dia0_i1111.trc  (incident=1111):
ORA-32701: Possible hangs up to hang ID=1 detected
Incident details in: .../oracle/log/diag/rdbms/hm1/hm1/incident/incdir_1111/hm1_dia0_11111_i1111.trc
2016-07-16T12:39:02.674061-07:00
DIA0 requesting termination of session sid:44 with serial # 23456 (ospid:34569) on instance 3
     due to a GLOBAL, HIGH confidence hang with ID=1.
     Hang Resolution Reason: Although hangs of this root type are typically
    self-resolving, the previously ignored hang was automatically resolved.
DIA0: Examine the alert log on instance 3 for session termination status of hang with ID=1.

例13-3 ハング・マネージャによって解決されたセッションの遅延を示すアラート・ログ内のエラー・メッセージ

この例は、解決された遅延に関するローカル・インスタンスのハング・マネージャのアラート・ログの例を示します

2016-07-16T12:39:02.707822-07:00
Errors in file .../oracle/log/diag/rdbms/hm1/hm11/trace/hm11_dia0_11111.trc  (incident=169):
ORA-32701: Possible hangs up to hang ID=1 detected
Incident details in: .../oracle/log/diag/rdbms/hm1/hm11/incident/incdir_169/hm11_dia0_30676_i169.trc
2016-07-16T12:39:05.086593-07:00
DIA0 terminating blocker (ospid: 30872 sid: 44 ser#: 23456) of hang with ID = 1
     requested by master DIA0 process on instance 1
     Hang Resolution Reason: Although hangs of this root type are typically
    self-resolving, the previously ignored hang was automatically resolved.
     by terminating session sid:44 with serial # 23456 (ospid:34569)
...
DIA0 successfully terminated session sid:44 with serial # 23456 (ospid:34569) with status 0.