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

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

Oracle RACを設計およびデプロイする方法について学習します。

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

高可用性を実現するOracle RACのデプロイ
高可用性を実現するためにOracle RACをデプロイする方法について説明します。
Oracle RACの設計に関する一般的な考慮事項
Oracle RACの設計に関する考慮事項について説明します。
Oracle RACでのデータベースの一般的なデプロイメント
表領域の使用、オブジェクトの作成、分散トランザクションなど、Oracle RACの様々なデプロイメントに関する考慮事項について説明します。
ブロッカ・リゾルバの概要
ブロッカ・リゾルバは、遅延を自律的に解決し、リソースの可用性を維持するOracle Real Application Clusters (Oracle RAC)の環境機能です。

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

高可用性を実現するためにOracle RACをデプロイする方法を学習します。

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

高可用性システムの設計について
ミッション・クリティカルなシステムの場合は、フェイルオーバーとリカバリが実行可能であることに加えて、あらゆるタイプの障害に対して環境にリジリエンスがある必要があります。
高可用性環境にOracle RACをデプロイするためのベスト・プラクティス
ここで説明するベスト・プラクティスに従うことで、Oracle RAC環境のパフォーマンスを向上させることができます。
クラスタ・データベースにおける複数のアプリケーションの統合
Oracle RACデータベースでのアプリケーションの統合について説明します。
Oracle RACのスケーラビリティ
Oracle RACのスケーラビリティを向上させるための選択肢について説明します。

親トピック: 設計およびデプロイメント方法

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

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

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

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

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

関連トピック

Oracle Maximum Availability Architecture(MAA)

親トピック: 高可用性を実現するOracle RACのデプロイ

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

ここで説明するベスト・プラクティスに従うことで、Oracle RAC環境のパフォーマンスを向上させることができます。

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

VIPアドレスを使用してデータベースに接続することで、TCP/IPのタイムアウト待機時間をなくします。
詳細な操作手順を作成し、インフラストラクチャ内のすべてのコンポーネントに対して、定義されたサービス・レベルを満たす適切で有効なサポート契約があることを確認します。
接続時フェイルオーバー、高速接続フェイルオーバー、高速アプリケーション通知、ロード・バランシング・アドバイザなどのOracle RACの自動ワークロード管理機能を使用します。
個別のボリューム・グループに投票ディスクを配置して、I/Oスループットの低下による停止を減らします。x個の投票デバイスの障害後も機能を維持するには、2x + 1個のミラーを構成します。
約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 RACのデプロイ

クラスタ・データベースにおける複数のアプリケーションの統合

Oracle RACデータベースでのアプリケーションの統合について学習します。

多くのユーザーが1つのクラスタ内での複数のデータベースの統合を必要とします。Oracle ClusterwareおよびOracle RACは、両方のタイプの統合をサポートしています。

Oracle ASMによって管理される単一の記憶域のプールでクラスタを作成すると、シングル・インスタンス・データベースであろうとOracle RACデータベースであろうと複数のデータベースを管理するためのインフラストラクチャが提供されます。

統合時の容量管理
統合時の容量の管理方法について説明します。
統合時のグローバル・キャッシュ・サービス・プロセスの管理
統合時にグローバル・キャッシュ・サービス・プロセスを管理する方法について説明します。
統合へのOracle Database Cloudの使用
データベース・クラウドは、Global Data Servicesフレームワークによって単一の仮想サーバーに統合された一連のデータベースであり、1つ以上のグローバル・サービスを提供すると同時に、高いパフォーマンス、可用性、およびリソースの最適な使用を実現します。

親トピック: 高可用性を実現するOracle RACのデプロイ

統合時の容量管理

統合時の容量の管理方法を学習します。

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

作業を追加する場合は、クラスタの容量を適切に管理することが重要です。クラスタを管理するプロセス(Oracle Clusterwareとデータベースの両方のプロセスを含む)は、CPUリソースを適時に取得できる必要があり、システム内で優先度が高く設定される必要があります。クラスタ構成ポリシーを使用して、クラスタ・レベルのリソースを管理できます。

親トピック: クラスタ・データベースにおける複数のアプリケーションの統合

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

統合時にグローバル・キャッシュ・サービス・プロセスを管理する方法を学習します。

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

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

親トピック: クラスタ・データベースにおける複数のアプリケーションの統合

統合へのOracle Database Cloudの使用

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

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

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

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

関連トピック

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

親トピック: クラスタ・データベースにおける複数のアプリケーションの統合

Oracle RACのスケーラビリティ

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

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

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

ノート:

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

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

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

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

親トピック: 設計およびデプロイメント方法

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

表領域の使用、オブジェクトの作成、分散トランザクションなど、Oracle RACの様々なデプロイメントに関する考慮事項について学習します。

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

Oracle RACでの表領域の使用
Oracle RACで表領域の使用を最適化する方法について説明します。
Oracle RACでのオブジェクトの作成およびパフォーマンス
Oracle RACでのオブジェクトの作成およびパフォーマンスについて説明します。
Oracle RACでのノードの追加と削除およびSYSAUX表領域
Oracle RACでノードの追加および削除がSYSAUX表領域にどのように影響を与えるかについて説明します。
分散トランザクションおよびOracle RAC
Oracle RACでの分散トランザクションについて説明します。
Oracle RACでのOLTPアプリケーションのデプロイ
Oracle RACでのOTLPアプリケーションのデプロイについて説明します。
キャッシュ・フュージョンによる柔軟な実装
Oracle RACでのキャッシュ・フュージョンによる柔軟なワークロードの実装について説明します。
Oracle RACでのデータ・ウェアハウス・アプリケーションのデプロイ
Oracle RACでデータ・ウェアハウス・アプリケーションをデプロイする方法について説明します
Oracle RACでのデータ・セキュリティの考慮事項
透過的データ暗号化と、Oracle RACデータ・セキュリティに関するMicrosoft Windowsファイアウォールの考慮事項について説明します。

親トピック: 設計およびデプロイメント方法

Oracle RACでの表領域の使用

Oracle RACで表領域の使用を最適化する方法を学習します。

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

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

親トピック: Oracle RACでのデータベースの一般的なデプロイメント

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

Oracle RACでのオブジェクトの作成およびパフォーマンスについて学習します。

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

親トピック: Oracle RACでのデータベースの一般的なデプロイメント

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

Oracle RACでノードの追加および削除がSYSAUX表領域にどのように影響を与えるかについて学習します。

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

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

Oracle RACでの分散トランザクションについて学習します。

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

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

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

Oracle RACでのOTLPアプリケーションのデプロイについて学習します。

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

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

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

親トピック: Oracle RACでのデータベースの一般的なデプロイメント

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

Oracle RACでのキャッシュ・フュージョンによる柔軟なワークロードの実装について学習します。

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

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

親トピック: Oracle RACでのデータベースの一般的なデプロイメント

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

Oracle RACでデータ・ウェアハウス・アプリケーションをデプロイする方法について学習します

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

Oracle RACでのデータ・ウェアハウス・アプリケーションの並列処理
Oracle RACでのデータ・ウェアハウス・アプリケーションの並列処理について説明します。
データ・ウェアハウス・システムおよびOracle RACにおけるパラレル処理
パラレル処理を使用して、Oracle RACでのデータ・ウェアハウスのパフォーマンスを向上させます。

親トピック: Oracle RACでのデータベースの一般的なデプロイメント

Oracle RACでのデータ・ウェアハウス・アプリケーションの並列処理

Oracle RACでのデータ・ウェアハウス・アプリケーションの並列処理について学習します。

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

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

親トピック: Oracle RACでのデータ・ウェアハウス・アプリケーションのデプロイ

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

パラレル処理を使用して、Oracle RACでのデータ・ウェアハウスのパフォーマンスを向上させます。

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

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

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

透過的データ暗号化と、Oracle RACデータ・セキュリティに関するMicrosoft Windowsファイアウォールの考慮事項について学習します。

透過的データ暗号化およびキーストア
Oracle RACでの透過的データ暗号化およびキーストアについて説明します。
Windowsファイアウォールの考慮事項
Microsoft Windowsファイアウォールの考慮事項について説明します。
ウォレットを使用してONSクライアントを安全に実行
SSL証明書を構成および使用して、データベース層のONSサーバーと中間層の通知クライアント間の認証を設定できます。

親トピック: Oracle RACでのデータベースの一般的なデプロイメント

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

Oracle RACでの透過的データ暗号化およびキーストアについて学習します。

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

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

任意の1つのOracle RACインスタンスで実行される任意のキーストア操作(キーストアのオープンやクローズなど)は、他のすべてのOracle RACインスタンスに適用されます。つまり、1つのインスタンスでキーストアをオープンおよびクローズすると、すべてのOracle RACインスタンスでキーストアがオープンおよびクローズされます。
Oracle Database 23ai以降、パラメータENCRYPTION_WALLET_LOCATIONはサポートされていません。
TDEウォレットを格納および取得するには、WALLET_ROOT構造(Oracle Database 18cで導入)を使用します。
ある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ガイド

親トピック: Oracle RACでのデータ・セキュリティの考慮事項

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

Microsoft Windowsファイアウォールの考慮事項について学習します。

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

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

親トピック: Oracle RACでのデータ・セキュリティの考慮事項

ウォレットを使用して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 RACでのデータ・セキュリティの考慮事項

ブロッカ・リゾルバの概要

ブロッカ・リゾルバは、遅延を自律的に解決し、リソースの可用性を維持するOracle Real Application Clusters (Oracle RAC)の環境機能です。

ブロッカ・リゾルバはデフォルトで有効になっており、次の処理を実行します:

データベースの遅延およびデッドロックの確実な検出
データベースの遅延およびデッドロックの自律的な解決
すべての検出および解決のログ記録
感度(Normal/High)およびトレース・ファイルのサイズを構成するためのSQLインタフェースの提供

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

ブロッカ・リゾルバのアーキテクチャ
ブロッカ・リゾルバは、データベース内のDIA0タスクとして自律的に実行されます。
ブロッカ・リゾルバのオプション構成
感度を調整し、ブロッカ・リゾルバで使用されるログ・ファイルのサイズと数を制御できます。
ブロッカ・リゾルバの診断およロギング
ブロッカ・リゾルバは自律的に遅延を解決し、解決内容をデータベースのアラート・ログに、診断をトレース・ファイルに継続的に記録します。

親トピック: 設計およびデプロイメント方法

ブロッカ・リゾルバのアーキテクチャ

ブロッカ・リゾルバは、データベース内のDIA0タスクとして自律的に実行されます。

ブロッカ・リゾルバは、次の3つのフェーズで機能します:

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

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

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

親トピック: ブロッカ・リゾルバの概要

ブロッカ・リゾルバのオプションの構成

感度を調整し、ブロッカ・リゾルバで使用されるログ・ファイルのサイズと数を制御できます。

ノート:

DBMS_HANG_MANAGERパッケージは、Oracle Database 23aiでは非推奨です。かわりにDBMS_BLOCKER_RESOLVERを使用します。DBMS_HANG_MANAGERパッケージは、セッションの問題に対処するために一部の構成パラメータおよび制約を変更する方法を提供します。このパッケージはDBMS_BLOCKER_RESOLVERに置き換えられます。DBMS_HANG_MANAGERは、将来のリリースで削除される可能性があります。

感度

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

デフォルトでは、sensitivityパラメータはNormalに設定されています。ブロッカ・リゾルバの感度を設定するには、SQL*PlusでSYSユーザーとして次のコマンドを実行します。

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

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

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

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

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

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

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

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

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

exec dbms_blocker_resolver.set(dbms_blocker_resolver.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.

親トピック: ブロッカ・リゾルバの概要