| Oracle Real Application Clusters管理およびデプロイメント・ガイド 11gリリース1（11.1） E05738-05 |
|
 戻る |
 次へ |
この章では、Oracle Real Application Clusters（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 Database、Oracle ClusterwareおよびOracle RACの多数の機能を使用してOracle RAC環境の障害を最小限に抑えたり、マスクすることができます。次に例を示します。
VIPアドレスを使用してデータベースに接続することで、TCP/IPのタイムアウトをなくします。
詳細な操作手順を作成し、インフラストラクチャ内のすべてのコンポーネントに対して、定義されたサービス・レベルを満たす適切で有効なサポート契約があることを確認します。
接続時フェイルオーバー、高速接続フェイルオーバー、高速アプリケーション通知、ロード・バランシング・アドバイザなどのOracle RACの自動ワークロード管理機能を使用します。詳細は、第4章「自動ワークロード管理の概要」を参照してください。
個別のボリューム・グループに投票ディスクを配置して、I/Oスループットの低下による停止を減らします。 x個の投票デバイスの障害に対応するには、2x + 1個のミラーを構成します。
約2ms以下のI/Oサービス時間でOCRを配置します。
FAST_START_MTTR_TARGET初期化パラメータを使用してデータベース・リカバリをチューニングします。
ASMを使用してデータベース記憶域を管理します。
厳密変更制御手順が有効であることを確認します。
LDAP、NIS、DNSなどの周辺のインフラストラクチャに高可用性およびリジリエンスがあることを確認します。これらのエンティティは、Oracle RACデータベースの可用性に影響します。可能な場合は、ローカルのバックアップ手順を定期的に実行します。
Oracle Enterprise Managerを使用して、Oracle RACデータベースのみでなく、Oracle RAC環境全体を管理します。Oracle Enterprise Managerを使用して、サービスの作成と変更、およびクラスタ・データベース・インスタンスとクラスタ・データベースの起動と停止を実行できます。Oracle RAC環境でOracle Enterprise Managerを使用する方法の詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。
Recovery Managerを使用して、データ・ファイル、制御ファイル、サーバー・パラメータ・ファイル（SPFILE）およびアーカイブREDOログ・ファイルのバックアップ、リストアおよびリカバリを実行します。Recovery Managerをメディア・マネージャとともに使用すると、ファイルを外部記憶域にバックアップできます。また、Oracle RACデータベースのバックアップまたはリカバリの実行時にパラレル化を構成できます。Oracle RACでは、Recovery Managerのチャネルは、すべてのOracle RACインスタンス間で動的に割り当てられます。チャネルのフェイルオーバーによって、1つのノード上で失敗した操作を別のノードで継続できます。Oracle RACでは、Recovery Managerは、Oracle Enterprise ManagerのBackup Managerまたはコマンドラインから実行できます。 Recovery Managerの詳細は、第9章「Recovery Managerの構成およびアーカイブ」を参照してください。
順序番号を使用している場合、常にNOORDERオプションを指定したCACHEを使用することによって、順序番号生成のパフォーマンスを最適化します。ただし、CACHEオプションを使用すると、連続しない順序番号が生成される場合があります。連続しない順序番号を使用できない環境では、NOCACHEオプションを使用するか、または順序番号の事前生成を検討してください。アプリケーションでは順序番号の順序付けが必要で、連続しない順序番号を使用できる場合は、CACHEおよびORDERを使用して、Oracle RACの順序番号のキャッシュおよび順序付けを行います。アプリケーションで連続した順序番号の順序付けが必要な場合は、NOCACHEおよびORDERを使用します。この組合せは、その他のキャッシュおよび順序付けの組合せと比較すると、パフォーマンスに最も大きな影響を及ぼします。
索引を使用する場合は、逆キー索引などの方法を検討してパフォーマンスを最適化します。逆キー索引は、挿入日付に基づいた索引のように、索引の一方に頻繁に挿入を行う場合に特に有効です。
多くのユーザーは、複数のアプリケーションの単一データベースへの統合および複数のデータベースの単一クラスタへの統合を望んでいます。Oracle ClusterwareおよびOracle RACは、両方のタイプの統合をサポートしています。
ASMによって管理された単一の記憶域のプールでクラスタを作成すると、インフラストラクチャで複数のデータベースを（シングル・インスタンス・データベースか、またはOracle RACデータベースかに関係なく）管理できます。
Oracle RACデータベースの場合は、ワークロードの要件に基づいてインスタンスの数、および指定されたデータベースのインスタンスを実行するノードを調整できます。クラスタで管理されるサービスなどの機能を使用すると、単一データベースまたは複数のデータベース間で複数のワークロードを管理できます。作業を追加する場合は、クラスタの容量を適切に管理することが重要です。クラスタを管理するプロセス（Oracle Clusterwareとデータベースの両方からのプロセスを含む）は、CPUのリソースを適時に取得できる必要があります。また、システム内でこれらのプロセスの優先度が高く設定される必要があります。
サーバー上のリアルタイムLMSnプロセスの数は、プロセッサの数と同じか、または少なくすることをお薦めします。（これは、コアを含む認識されるCPUの数です。たとえば、デュアル・コアCPUは、2つのCPUと認識されます）。ノード上にインスタンスを追加するときは、システムで負荷試験を実行してワークロードをサポートするのに必要な容量があることを確認することが重要です。
多数の小規模なデータベースをクラスタに統合する場合は、Oracle RACインスタンスによって作成されるグローバル・キャッシュ・サービス・プロセス（Global Cache Service Processes: LMSn）の数を減らす必要が生じる場合があります。デフォルトでは、サーバーで検出されるCPUの数に基づいてプロセスの数がOracle Databaseによって算出されます。この計算の結果、LMSnプロセスがOracle RACインスタンスに必要とされるプロセス数より多くなることがあります。1つのLMSプロセスには、最大4個のCPUで対応できます。LMSnプロセスの数を削減するには、GC_SERVER_PROCESSES初期化パラメータを手動で最小限度の1の値に設定します。4個のCPUごとにアプリケーションで必要とされるプロセスを1つ追加します。通常は、ビジーのLMSnプロセスを少なくすることをお薦めします。インスタンスが起動されると、Oracle Databaseによってプロセスの数が算出されます。値を変更する場合は、インスタンスを再起動する必要があります。
Oracle RACでは、複数のシステムからデータの個別コピーへのトランザクションに一貫性のある同時アクセスが可能です。また、単一のサーバーの容量を超えたスケーラビリティも実現します。対称マルチプロセッシング（SMP）サーバーで透過的に動作するアプリケーションは、アプリケーション・コードを変更しなくても、Oracle RACで適切に動作すると想定できます。
従来、データベース・サーバーが容量を超えて実行される場合は、より大きな新しいサーバーに置き換えられてきました。サーバーの容量が大きくなると、価格も上がります。ただし、Oracle RACデータベースには、容量を増やすための別の手段があります。
現行のハードウェアへの投資を維持し、新しいサーバーをクラスタに追加する（あるいは新しいクラスタを作成または追加する）ことで、容量を増やすことができます。
Oracle ClusterwareおよびOracle RACを使用してクラスタにサーバーを追加する場合、停止は必要ありません。新規インスタンスが起動されると同時に、アプリケーションは追加された容量を使用できます。
クラスタ内のすべてのサーバーは、同じオペレーティング・システムと、同じバージョンのOracle Databaseを実行する必要がありますが、各サーバーの容量を完全に揃える必要はありません。Oracle RACを使用すると、要件にあったクラスタ（それぞれがデュアルCPUの汎用サーバーで構成されるクラスタ、それぞれに32または64のCPUが組み込まれたサーバーのクラスタなど）を構築できます。Oracleのパラレル実行機能を使用すると、1つのSQL文をマルチ・プロセスに分割できます。この場合、それぞれのプロセスによって作業のサブセットが実行されます。Oracle RAC環境では、パラレル・プロセスをユーザーが接続されているインスタンスでのみ実行するように定義したり、クラスタ内の複数のインスタンス間で実行するように定義することができます。
この項では、Oracle RAC環境でのデータベースの設計およびデプロイメント方法について簡単に説明します。また、高可用性を実現するための考慮事項およびOracle RACの様々なデプロイメントに関する一般的なガイドラインについても説明します。
Oracle RACデータベース上にデプロイするアプリケーションの設計および開発時には、次の手順の実行を検討してください。
設計とアプリケーションのチューニング
メモリーとI/Oのチューニング
競合のチューニング
オペレーティング・システムのチューニング
|
注意: アプリケーションをSMPシステムで拡張できない場合は、アプリケーションをOracle RACデータベースに移動してもパフォーマンスは向上しません。 |
挿入集中型オンライン・トランザクション処理（OLTP）アプリケーションには、ハッシュ・パーティション化を使用することを検討します。ハッシュ・パーティション化の特長は次のとおりです。
単一データベース構造への同時挿入による競合を軽減します。
索引がローカルで表を使用してパーティション化され、表が順序ベースのキーでパーティション化されている場合、順序ベースの索引に適用されます。
アプリケーションに対して透過的です。
OLTP環境に対して表および索引をハッシュ・パーティション化すると、Oracle RACデータベースでのパフォーマンスが大幅に向上します。ハッシュ・パーティション化された索引では、索引レンジ・スキャンは使用できないことに注意してください。
順序番号を使用している場合、常にCACHEオプションを使用します。CACHEオプションを指定して順序番号を使用する場合は、次のことに注意してください。
システムの順序番号が失われる場合があります。
順序番号の順序付けは保証されません。
|
注意: 連続しない順序番号を使用できない環境では、順序番号の事前生成を検討するか、またはORDERおよびCACHEオプションを使用してください。 |
この項では、Oracle RACデータベースをデプロイする際の考慮事項について説明します。ここで説明する方法を採用しない場合でも、Oracle RACデータベースのパフォーマンスが低下することはありません。効率的なシングル・インスタンス設計であれば、アプリケーションはOracle RACデータベースで効率的に実行されます。この項の内容は次のとおりです。
ローカル管理表領域の使用の他に、自動セグメント領域管理（ASSM）および自動UNDO管理を使用して領域管理をさらに簡単にすることができます。
ASSMでは、挿入を行うためのブロックの各インスタンスのサブセット間にインスタンスのワークロードが分散されます。これによってブロック転送が最小限に抑えられるため、Oracle RACパフォーマンスが向上します。自動UNDO管理をOracle RAC環境にデプロイするには、各インスタンスに固有のUNDO表領域が必要です。
原則として、DDL文の使用はメンテナンス・タスクのみに限定し、システム操作のピーク時には実行しないようにします。ほとんどのシステムでは、新しいオブジェクトの生成量とその他のDDL文に対する制限が必要です。シングル・インスタンスのOracle Databaseの場合と同様に、オブジェクトの作成と削除が多くなるとパフォーマンスのオーバーヘッドが増加する可能性があります。
Oracle RACデータベース環境にノードを追加する場合は、SYSAUX表領域のサイズを大きくする必要があります。また、クラスタ・データベースのノードを削除する場合は、SYSAUX表領域のサイズを小さくできる場合もあります。
|
関連項目: 複数のインスタンスに対するSYSAUX表領域のサイズの設定方法については、プラットフォーム固有のOracle Real Application Clustersのインストレーション・ガイドを参照してください。 |
Oracle RAC環境でXAトランザクションを実行しているときに、そのパフォーマンスが低い場合は、密結合分散トランザクションのすべてのブランチを同じインスタンスに割り当てます。
これを実現するには、1つ以上のOracle RACインスタンスで複数のOracle分散トランザクション処理（DTP）サービスを作成します。各DTPサービスは、1つのみのOracle RACインスタンスで使用可能な単一のサービスです。分散トランザクション処理のためのデータベース・サーバーへのアクセスは、すべてDTPサービスを経由する必要があります。単一のグローバル分散トランザクションのすべてのブランチが、同じDTPサービスを使用することを確認してください。つまり、TNS名やJDBC URLなどのネットワーク接続記述子には、分散トランザクション処理をサポートするためにDTPサービスを使用する必要があります。
|
関連項目: サービスおよび分散トランザクションの有効化の詳細は、「Oracle Real Application Clustersのサービスおよび分散トランザクション処理」を参照してください。Oracle RACでの分散トランザクションの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。 |
Oracle RACデータベースはキャッシュ・フュージョンによって、オンライン・トランザクション処理（OLTP）アプリケーションに最適なデプロイメント・サーバーになります。これは、これらのアプリケーションには次の要件があるためです。
障害時の高可用性
増加するシステム需要に対応するためのスケーラビリティ
需要変動に応じたロード・バランシング
Oracle DatabaseおよびOracle RACの高可用性機能は、処理を中断することなく、障害が発生していないインスタンスにワークロードを再分散してロード・バランシングを実行します。Oracle RACは、優れたスケーラビリティも提供します。これによって、ノードを追加または置換した場合、Oracle Databaseは、リソースを再マスター化してワークロードを再分散します。
オンライン・トランザクション処理システムのワークロードは、頻繁に変化します。Oracle RACは、システム負荷とシステム可用性の変化に対して柔軟にかつ動的に対応します。Oracle RACは、次のような原因で変動する幅広いサービス・レベルに対応します。
ユーザーの需要の変化
取引の集中（大量取引の発生）など、ピーク時のスケーラビリティの問題
システム・リソースの可用性の変化
この項では、Oracle RAC環境でのデータ・ウェアハウス・システムのデプロイ方法について説明します。また、共有ディスク・アーキテクチャで使用可能なデータ・ウェアハウス機能についても説明します。この項の内容は次のとおりです。
Oracle Real Application Clustersでのデータ・ウェアハウス・アプリケーションのスピードアップ
データ・ウェアハウス・システムおよびOracle Real Application Clustersにおけるパラレル実行
Oracle RACは、Oracle Databaseのシングル・インスタンスのメリットを拡大するため、データ・ウェアハウス・アプリケーションには理想的です。Oracle RACは、Oracle RACデータベースに属するすべてのノード上で使用可能な処理能力を最大限に活用して、データ・ウェアハウス・システムをスピードアップおよびスケールアップすることによって、Oracleのシングル・インスタンスのメリットを拡大します。
クエリー・オプティマイザは、最適な実行計画の判断に、パラレル実行を検討します。クエリー・オプティマイザのデフォルトのコスト・モデルはCPU+I/Oで、コスト単位は時間です。Oracle RACでは、クエリー・オプティマイザが、プロセッサ数に基づいてパラレル化の適切なデフォルト値を動的に計算します。代替アクセス・パスのコスト評価（表スキャンと索引アクセスなど）では、操作に使用できる並列度（DOP）が考慮されます。これによってOracle Databaseは、Oracle RAC構成用に最適化された実行計画を選択します。
Oracle Databaseのパラレル実行機能では、マルチ・プロセスを使用して1つ以上のCPUでSQL文を実行します。パラレル実行は、シングル・インスタンスのOracle DatabaseおよびOracle RACデータベースの両方で使用できます。
Oracle RACは、パラレル処理をすべての利用可能なインスタンスに分散することによってパラレル実行を十分に活用します。パラレル操作に使用できるプロセスの数は、各表または索引に割り当てられるDOPによって異なります。
|
関連項目: クエリー・オプティマイザの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
この項では、2つのOracle RACセキュリティの考慮事項について説明します。内容は次のとおりです。
Oracle RACインスタンスで透過的データ暗号化に使用するウォレットには、共通ウォレットのローカル・コピー、直接アクセスされる共有メディア上で共有される共通ウォレット、またはハードウェア・セキュリティ・モジュール（HSM）ベースのウォレットのいずれかを使用できます。いずれの場合でも、各Oracle RACインスタンスでウォレットを開いてから、透過的データ暗号化を使用する必要があります。
Oracle RACにウォレットを設定し、マスター・キーを再設定するには、次の手順を実行します。
透過的データ暗号化を次の手順で有効にします。
最初は1つのOracle RACインスタンスにのみマスター・キーを設定します。これを行うには、コマンドラインまたはOracle Enterprise Managerで対象のインスタンスに対し次のSQL文を実行します。
インスタンス固有のウォレットの場合:
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "wallet_password";
HSMデバイスで生成および格納されたマスター・キーの場合:
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "user_ID:HSM_password";
インスタンス固有のウォレットの場合は、Oracle RACデータベースのすべてのインスタンスに対するウォレットを、各インスタンスのsqlnet.oraファイルで示されるウォレット格納場所に手動でコピーします。ウォレットのコピーが完了したら、すべてのインスタンスでウォレットを開きます。HSMデバイスに格納されたマスター・キーの場合は、インスタンスごとにウォレットを開きます。
|
注意: 表領域暗号化用のマスター・キーもHSMデバイスに格納できます。ただし、ソフトウェア・ウォレットに格納されているマスター・キーで表領域が事前に暗号化されていない場合のみです。 |
各ノードにウォレットをコピーするかわりに、HSMデバイスを使用してマスター暗号化キーを格納できます。HSMデバイスを使用すると、マスター・キーが自動的にクローニングされ、すべてのインスタンスで使用可能になるため、ネットワーク・デバイスの共有記憶域ではHSMデバイスを使用することをお薦めします。
|
注意: マスター暗号化キーの格納にHSMが使用される場合（マスター・キーを再設定した後にすべてのインスタンスでウォレットを開く必要がある場合など）でも、HSMを使用してマスター・キーを格納する透過的データ暗号化にはこれらの手順が適用されます。 |
手順3の説明に従って、Oracle RACデータベースのすべてのインスタンスでウォレットを開きます。
マスター・キーを再設定します。コマンドラインまたはOracle Enterprise Managerを使用して、次のSQL文を1つのOracle RACインスタンスでのみ実行します。
インスタンス固有のウォレットのマスター・キーの場合:
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "wallet_password";
HSMデバイスに格納されているマスター・キーの場合:
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "user_ID:HSM_password";
コマンドが正常に実行されたら、インスタンス固有のウォレットをOracle RACデータベースのすべてのインスタンスにコピーします。コピーの終了後、ウォレットを再度開きます。すべてのインスタンスでウォレットが再度開かれた後、再度、マスター・キーを再設定してみます。
|
注意: マスター・キーの設定または変更中、次のSQL文は実行しないでください。ALTER SYSTEM SET ENCRYPTION WALLET CLOSE; ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "wallet_password"; ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "user_ID:HSM_password"; ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "wallet_password"; ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "user_ID:HSM_password"; |
Oracle RACデータベースでウォレットを開くために、Oracle RACデータベースのすべてのインスタンスでウォレットを開きます。これを行うには、コマンドラインまたはOracle Enterprise Managerで次のSQL文を実行します。
ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "wallet_password";
または
ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "user_ID:HSM_password";
Oracle RACデータベースでウォレットを閉じるために、Oracle RACデータベースのすべてのインスタンスでウォレットを閉じます。これを行うには、コマンドラインまたはOracle Enterprise Managerで次のSQL文を実行します。
ALTER SYSTEM SET ENCRYPTION WALLET CLOSE;
共有記憶域が存在しないデプロイメントでは、各Oracle RACノードでローカル・ウォレットを保持する必要があります。
|
注意: キーへの共有アクセスでは、HSMデバイスの使用をお薦めします。ネットワーク・ファイル・システム上に存在する共有コピーの使用はお薦めしません。これは、1つのインスタンスによってマスター・キーが再設定されると、他のインスタンスに変更が通知されず、列キーを復号化できない古いマスター・キーが使用されてしまうためです。Oracle RAC環境でキーの再設定が必要な場合は、他のすべてのインスタンスにウォレットをコピーし、各インスタンスでウォレットを閉じてから再度開く必要があります。 |
単一のノードでウォレットを作成およびプロビジョニングした後、次のようにウォレットをコピーして他のすべてのノードで使用可能にする必要があります。
暗号化されたウォレットとともに透過的データ暗号化を使用するシステムでは、任意の標準ファイル転送プロトコルを使用できますが、保護されたファイル転送を使用することをお薦めします。
不明瞭にされたウォレットとともに透過的データ暗号化を使用するシステムでは、保護されたチャネルを介してファイルを転送することをお薦めします。
ウォレットが存在するディレクトリを指定するには、sqlnet.oraファイル内のWALLET_LOCATIONパラメータまたはENCRYPTION_WALLET_LOCATIONパラメータを設定します。SQL文ALTER SYSTEM SET ENCRYPTION KEYを使用してサーバー・キーが再設定されるまで、透過的データ暗号化の使用中にウォレットのローカル・コピーを同期化する必要はありません。データベース・インスタンスでALTER SYSTEM SET ENCRYPTION KEY文を実行するたびに、ノードに存在するウォレットを再度コピーし、他のすべてのノードで使用可能にする必要があります。次に、各ノードでウォレットを閉じてから再度開く必要があります。不要な管理オーバーヘッドを回避するために、サーバー・マスター・キーのセキュリティが低下したり、キーを再設定しないと重大なセキュリティ問題が発生することが明確な例外的な場合のためにキーの再設定を予約します。
|
関連項目: ウォレットの作成およびプロビジョニングの詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。 |
デフォルトでは、Windows Server 2003 サービス・パック 1以上のすべてのインストールでは、Windows ファイアウォールによって、受信する接続に対してすべてのTCPネットワーク・ポートを事実上ブロックできます。その結果、TCPポートで受信する接続をリスニングするOracle製品は、いずれの接続要求も受信しなくなります。接続を行っているクライアントにはエラーが表示されます。
インストールするOracle製品およびその使用方法によって、Windows Server 2003でファイアウォール製品が機能するように、Windowsのインストール後の追加の構成作業を実行する必要があります。
この項では、次の内容について説明します。
表11-1に、WindowsのTCPポートをリスニングするOracle Database 10g Release 1 (10.1)以上の実行可能ファイルを示します。それらの実行可能ファイルが使用中で、リモート・クライアント・コンピュータからの接続を受信している場合は、適切な処理が行えるように、それらをWindowsファイアウォールの例外リストに追加することをお薦めします。特に記述がないかぎり、それらはORACLE_HOME\binにあります。
表11-1に示すRMIレジストリ・アプリケーションおよびデーモン実行可能ファイルは、Oracle Ultra Searchがリモート・クローラを起動するために使用します。Ultra Searchのリモート・クローラ機能を使用しており、Windowsファイアウォールが有効なコンピュータでリモート・クローラを実行している場合は、Windowsファイアウォールの例外リストにそれらの実行可能ファイルを追加する必要があります。
|
注意: 複数のOracleホームを使用している場合、同じ実行可能ファイルにいくつかのファイアウォールの例外（実行可能ファイルがロードされる各ホームに1つ）が必要になります。 |
表11-1 Windowsファイアウォール例外を必要とするOracle実行可能ファイル
| ファイル名 | 実行可能ファイル名 |
|---|---|
|
|
OracleCRService |
|
|
OracleEVMService |
|
|
イベント・マネージャ・ロギング・デーモン |
|
|
Oracle Object Link Manager（GUIバージョン） |
|
|
OracleCSService |
|
|
Oracle Object Link Manager（CLIバージョン） |
|
|
Virtual Internet Protocol Configuration Assistant |
|
|
Oracle Cluster Volume Service |
|
|
Data Guard Manager |
|
|
Oracle Database Control |
|
|
外部プロシージャ |
|
|
汎用接続性 |
|
|
Oracle Internet Directory LDAP Server |
|
|
Microsoftトランザクション・サーバー用のOracleサービス |
|
|
Oracle Database |
|
|
Apache Webサーバー |
|
|
Oracle Enterprise Managerエージェント |
|
|
Microsoftトランザクション・サーバー用のOracleサービス |
|
|
Oracle |
|
|
RACG |
|
|
Oracleリスナー |
|
|
Java Virtual Machine |
|
|
RMIデーモン実行可能ファイル |
|
|
RMIレジストリ・アプリケーション |
|
|
RMIレジストリ・アプリケーション |
|
|
Oracle Notification Services |
|
|
Oracle Process Manager |
|
|
Oracle Procedural Gateway for APPC |
|
|
Oracle Procedural Gateway for Websphere MQ |
|
|
Oracle Procedural Gateway for Websphere MQ |
|
|
Oracle Procedural Gateway for APPC |
|
|
Oracle Transparent Gateway for DRDA |
|
|
Oracle Transparent Gateway for MS-SQL Server |
|
|
Oracle Transparent Gateway for SYBASE |
|
|
Oracle Transparent Gateway for Teradata |
|
|
Oracle TNSリスナー |
|
|
Oracle Cluster File System用のシステム・ファイル |
次のすべての条件が満たされる場合、Windowsファイアウォールのインストール後の構成を行う必要があります。
Oracleサーバー側のコンポーネントがインストールされている。
これらのコンポーネントには、Oracle Database、ネットワーク・リスナー、Webサーバーまたはサービスが含まれます。
コンピュータがネットワーク上の他のコンピュータからの接続を提供する。
Oracleソフトウェアがインストールされたコンピュータに他のコンピュータが接続しない場合、インストール後の構成手順は必要ありません。Oracleソフトウェアは予想通りに機能します。
Windowsファイアウォールが有効になっている。
Windowsファイアウォールが有効になってない場合、インストール後の構成手順は必要ありません。
選択したポートへの接続要求を受信できるように、ファイアウォールの特定の静的TCPポートを開くか、または特定の実行可能ファイルの例外を作成して、Windowsファイアウォールを構成できます。 ファイアウォールを構成するには、「コントロール パネル」→「Windows ファイアウォール」→「例外」を選択するか、コマンドラインでnetsh firewall add...と入力します。
または、フォアグランド・アプリケーションがポートをリスニングしているかどうかがWindowsによって通知され、その実行可能ファイルの例外を作成するかどうかが尋ねられます。この場合、コントロール パネルまたはコマンドラインから実行可能ファイルの例外を作成した場合と同じ効果があります。
表11-1に示す実行可能ファイルの例外を許可しても接続が確立できない場合、次の手順に従って、インストールのトラブルシューティングを行います。
Oracle構成ファイル（*.confファイルなど）、WindowsレジストリのOracleキー、ORACLE_HOME\network\adminのネットワーク構成ファイルを調べます。
ORACLE_HOME\network\admin\listener.oraのPROGRAM=句に示された実行可能ファイルを確認します。TNSリスナーを介してその実行可能ファイルへの接続を確立できるため、各実行可能ファイルでWindowsファイアウォールの例外が許可される必要があります。
Oracleトレース・ファイル、ログ・ファイル、および診断情報に関する他のソースで、失敗した接続に関する詳細を調べます。データベース・クライアント・コンピュータのログ・ファイルおよびトレース・ファイルには、失敗した接続のエラー・コードまたはトラブルシューティング情報が含まれます。サーバーのWindowsファイアウォールのログ・ファイルにも有効な情報が含まれる場合があります。
前述のトラブルシューティング手順ではWindows XP サービス・パック 2の特定の構成の問題が解決できない場合、診断と問題解決のために、netsh firewall show state verbose=enableコマンドの出力をOracleサポート・サービス提供します。
|
関連項目:
|
