B Oracle Key Vaultのトラブルシューティング

この項では、Key Vaultの迅速なインストールとデプロイに役立つ、チェックリストとよく発生するエラーに関するヒントを示します。

• Key Vaultのインストール前のチェックリスト
  
• Audit Vault Database Firewallの統合の手順
  
• RESTfulサービスのトラブルシューティングのヘルプ
  
• エラー: Cannot Open Keystoreメッセージ
  
• KMIPエラー: Invalid Field
  
• WARNING: Could Not Store Private Keyエラー
  
• Oracle Key Vaultのアップグレード後のエラー
  
• エラー: Failed to Open Wallet
  
• エラー: /usr/bin/javaが存在しない場合のプロビジョニング・コマンドの失敗
  
• トランザクション・チェック・エラー: 診断生成ユーティリティ
  
• ファスト・スタート・フェイルオーバー(FSFO)の一時停止(ORA-16818)
  
• SSHトンネル追加の障害
  
• TDEエンドポイント統合の問題
  
• 高可用性モードでのフェイルオーバーの状況
  

関連項目:

• Oracle Walletのアップロードとダウンロードでの推奨事項

• JKSおよびJCEKSキーストアのアップロードおよびダウンロードに関する推奨事項

• 資格証明ファイルのアップロードとダウンロードでの推奨事項

B.1 Key Vaultのインストール前のチェックリスト

インストール前のチェックリストには、Key Vaultを正常にインストールするためのすべての要件が示されています。

表B-1 Oracle Key Vaultのインストール前のチェックリスト

項目#	チェック	タスク
1. [ x ]	システム要件	システム要件の説明に従い、十分なCPU、メモリーおよびディスクがあることを確認します
2. [ x ]	ファイアウォールですべての必要なネットワーク・ポートを開く	ネットワーク・ポートの詳細は、ネットワーク・ポートを参照してください
3. [ x ]	サポートされているエンドポイント・プラットフォーム	サポートされているエンドポイント・プラットフォームにリストされているように、プラットフォームのサポートは拡大されています
4. [ x ]	オンライン・マスター・キー(以前のTDE直接接続)のCOMPATIBLE初期化パラメータの設定	Oracle Database 11.2.0.0以降のこのパラメータの設定方法は、サポートされているエンドポイント・プラットフォームを参照してください
5. [ x ]	ネットワーク管理者からの固定IPアドレス、ネットワーク・マスクおよびゲートウェイ・アドレスの取得	これは、インストール・プロセスのタスク1 (「Oracle Key Vaultアプライアンスのインストール」を参照)のステップ9で必要になります

B.2 Audit Vault Database Firewallの統合の手順

Audit Vault and Database Firewall (AVDF)の監査をOracle Key Vaultと統合するには、次のようにAVDFとKey Vaultを統合する必要があります。

1. AVDF 12.2サーバーをインストールして、AV管理者および監査者ユーザーを設定します。
2. OKV 12.2サーバーをインストールします。その後、システム管理者としてログインして、sshアクセスを有効化します。
3. OKVサーバーをセキュア・ターゲットとしてAVDFサーバーに登録します。AV管理者(avadmin)としてログインし、「Secured Targets」→「Register」と移動します。名前として、OKVサーバー名を入力します。Oracle Key Vaultプラグインに対するタイプを設定し、接続文字列jdbc:oracle:thin:@//127.0.0.1:1521/dbfwdbを使用します。ユーザー名とパスワードには、avcollector/<integration_password>を使用します。セキュア・ターゲットに関する収集属性を設定します。

   av.collector.securedTargetVersion 12.2.0.0.0
   av.collector.TimeZoneOffset +5:30 
   

   注意: 状況に応じて任意のオフセットを使用できます。

4. OKVサーバーをホストとしてAVDFマシンに登録します。「Hosts」→「Register」に移動して、追加します。OKVサーバーのIPが必要になります。ホストを追加した後、新しいエントリがエージェント・アクティブ化キーとともに表示されることに注意してください。この値をコピーして、任意の場所に保存します。
5. AVDFエージェントをダウンロードします。「Hosts」→「Agent」→「Agent Release」に移動して、エージェント(リストの最初の項目)を取得します。agent.jarという名前を付けて保存し、scpを使用してOKVサーバーにアップロードします。
6. OKVサーバー上にagent.jarをインストールします。
   1. OKVコマンドラインにサポートとしてログオンし、suでrootに切り替えてディレクトリを作成し、エージェントを取得して、権限を設定します。

      cd /usr/local/okv
      mkdir avdf
      cp /home/support/agent.jar /usr/local/okv/avdf
      chown oracle:oinstall /usr/local/okv/avdf /usr/local/okv/avdf/*

   2. suでoracleに切り替えて、エージェントを抽出します。

      su - oracle
      cd /usr/local/okv/avdf
      java -jar agent.jar -d /usr/local/okv/avdf

   3. oracleとしてエージェントを起動し、ADVFのエージェント・アクティブ化キーを入力します。

      cd /usr/local/okv/avdf/bin
      ./agentctl start -k

   4. OKVのブラウザベースのコンソールを使用して、データベース・ユーザーを有効化します。データベース・ユーザーを有効化するには、「System」→「System Settings」に移動します。「Oracle Audit Vault Integration」セクションで「Enable」をオンにします。統合パスワードを入力します。
7. AVDFに監査証跡を追加します。AV管理者(avadmin)ユーザーとしてログインします。「Secured Targets」→「Audit Trails」→「Add」と移動して、新しい監査証跡を追加します。タイプをTABLEとして選択し、作成したセキュア・ターゲットおよびホストを選択します。表名をkeyvault.audit_trailに設定します。保存後、監査証跡を選択して収集を開始します。
8. AVDFによって収集されたデータを表示します。avauditorとしてAVDFにログインし、「Reports」→「All Activity」→「All Activity Report」と移動します。

B.3 RESTfulサービスのトラブルシューティングのヘルプ

Key Vaultログファイルには、サーバーによって送信されるすべてのエラー・メッセージが取得されます。エラー・メッセージは、/var/log/messagesファイルに書き込まれます。デバッグの最初のステップは、messagesファイルに目を通すことです。

ログ・ファイルのエラーを確認するには、ルート・ユーザーとして次のことを実行します。

root# vi /var/log/messages

B.4 エラー: Cannot Open Keystoreメッセージ

Cannot Open Keystoreエラーは、JavaキーストアをOracle Key Vaultサーバーにアップロードしようとしたときに発生する場合があります。

次の解決策を実行できます。

• PATH環境変数が正しく設定されていることを確認します。

• シェルで次のコマンドを入力して、keytoolとJavaの参照先を確認します。

  which keytool
  which java
  

  Oracle Javaが使用されていることを確認します。

B.5 KMIPエラー: Invalid Field

「Invalid Field」KMIPエラーは、複数のエンドポイントにある仮想ウォレットにOracle Walletをアップロードしようとしたときに発生する場合があります。

1. 2つ以上のエンドポイント(たとえば、エンドポイントAとエンドポイントB)を構成して、ウォレット(Oracle Wallet C)を共有します(これにより、ウォレット・キーも共有されます)。
2. Oracle Key VaultにエンドポイントAおよびBを登録します。
3. エンドポイントAのデフォルト・ウォレット(仮想ウォレットA)、エンドポイントBのデフォルト・ウォレット(仮想ウォレットB)の順に作成します。各仮想ウォレットには、対応するエンドポイントのみがアクセスできます。たとえば、エンドポイントBは仮想ウォレットAにアクセスできません。
4. Oracle Wallet CをエンドポイントAの仮想ウォレットAにアップロードします。
5. エンドポイントBの仮想ウォレットBに、エンドポイントBからOracle Wallet Cのアップロードを試みます。

同じキーのコピーが2つ作成され、エンドポイントBにはどちらも表示されないため、KMIPのエラーが発生します。エンドポイントAが最初のキーの再アップロードを試みると、Oracle Key Vaultはこの操作を検出して対応します。しかし、ステップ5でエンドポイントBは最初のキーを表示できないので、Oracle Key Vaultは2つのOracle Walletに対して必要な調整を行えません。

これは予期された動作です。かわりに、エンドポイント・グループを作成すれば、ウォレットを複数のエンドポイントで共有できます。詳細は、エンドポイント・グループの管理を参照してください。

注意:

KMIPエラーが発生する可能性は他の場合でもありますが、このシナリオが最も一般的です。

B.6 WARNING: Could Not Store Private Keyエラー

同じファイル名で内容が異なる2つのキーストアをアップロードすると、WARNING: Could not store private keyエラーが生成されます。

これは、各keytoolコマンドで同じ別名(-alias slserver)を使用している場合に発生します。JKSの別名は一意にする必要があるので、このような同じ別名を持つ2つのキーストアをダウンロードすると、okvutil downloadプロセスは2つ目のキーストアを無視します。一意の別名を使用して2つ目のキーストアをダウンロードしてください。

関連項目:

JKSまたはJCEKSキーストアのダウンロード

B.7 Oracle Key Vaultのアップグレード後のエラー

スタンドアロン・サーバーでOracle Key Vaultのアップグレードを実行した後、/var/log/messagesログ・ファイルにORA-1109、ORA-00313およびORA-00312のエラー・メッセージが記録されることがあります。

これらのメッセージは無視しても問題ありません。エラー・メッセージは、/var/log/debugファイルにも記録されます。

B.8 エラー: Failed to Open Wallet

オンライン・マスター・キー(以前のTDE直接接続)を試行しているときに、「Failed to Open Wallet」エラーが発生した場合は、まず環境変数ORACLE_BASEを確認する必要があります。Oracle Key Vaultと新しいTDE対応データベースの間での接続の構成のステップ1を参照してください。

次のように、PKCS #11ライブラリに必要な環境変数ORACLE_SID、ORACLE_HOMEおよびOKV_HOMEを設定する必要もあります。

1. USERのシステムENV変数を設定します。
2. DBを停止します。
3. サービスを再起動します。
4. DBを再起動します。

B.9 エラー: /usr/bin/javaが存在しない場合のプロビジョニング・コマンドの失敗

エンドポイントをプロビジョニングするためのRESTfulサービス・コマンドは、ソフト・リンク/usr/bin/javaが存在しないか、正しいJavaディレクトリを参照していない場合に失敗します。Javaのバージョンは、1.4以降である必要があります。

Javaホーム・ディレクトリへのソフト・リンクを作成する手順:

ln -s <your_Java_home_directory>/bin/java /usr/bin/java

B.10 トランザクション・チェック・エラー: 診断生成ユーティリティ

Oracle Key Vaultをアップグレードしようとすると、トランザクション・チェック・エラーが表示されることがあります。

次に例を示します。

file /usr/local/dbfw/etc/dbfw-diagnostics-package.yml from install of
appliance-18.1.0.0.0-52_190425.2253.d.x86_64 conflicts with file from
package okv-diagnostic-12.2.0.8.0-40_181013.1730.x86_64 

この問題は、診断生成ユーティリティがアップグレード・プロセスを妨げているために発生します。アップグレードする前に、診断生成ユーティリティを削除する必要があります。

B.11 ファスト・スタート・フェイルオーバー(FSFO)の一時停止(ORA-16818)

プラグを抜くのではなく電源オフをクリックするなど、制御された方法でプライマリが正常に停止された場合、ファスト・スタート・フェイルオーバーは実行されません。正常な停止では、プライマリ・サーバーのフェイルオーバー・ステータスは一時停止状態になり、スタンバイはプライマリが復帰するまで無期限に待機します。これはFSFOの予期された動作で、スプリット・ブレイン・シナリオを回避するために、Oracle DataGuardで定義されています。FSFOは、プライマリが予期せず停止した場合にのみ発生するように設計されています。shutdown immediate (またはshutdown normal)を実行した場合、FSFOは発生しません。

B.12 SSHトンネル追加の障害

SSHトンネルを設定しようとしているときに、次のエラー・メッセージが表示されることがあります。

Failed to establish SSH tunnel.Refer to Oracle documentation.

図B-1 SSHトンネル追加の障害

「図B-1 SSHトンネル追加の障害」の説明

これらの1つ以上が障害の原因となることがあります。

• 無効なトンネル名

• 無効なIPアドレス

• 無効なポート

• 無効なユーザー名

• 公開SSH Key Vaultキーが、Database as a Serviceインスタンス上のokvユーザーのauthorized_keysファイルにコピーされていない

• ネットワークに過負荷によってDatabase as a Serviceインスタンスに到達できない

入力値と接続を確認して、再試行します。

B.13 TDEエンドポイント統合の問題

この項では、TDEエンドポイント統合に関する一般的な問題およびそれらの解決方法について説明します。

Oracle Key Vaultライブラリのインストールに関する注意事項

• 複数のOracle DatabaseがあるマシンにOracle Key Vaultライブラリをインストールするには、root.shを1度だけ実行する必要があります

• アップグレード中、ライブラリをアップグレードするには、すべてのエンドポイントを停止する必要があります。現在、Oracle Key Vaultサーバーには、エンドポイント・ライブラリに対して後方互換性があります。

データベースの管理にSVRCTLツールを使用している場合

svrctlツールを使用してデータベースを管理する場合、ツールによってORACLE_BASEがNULLに設定される場合があることに注意してください。環境内でORACLE_BASEを使用していない場合は、ORACLE_BASEをORACLE_HOMEに設定することをお薦めします。

プライマリとスタンバイでセキュリティ・オブジェクトを管理する方法の統一

高可用性構成では、プライマリ・サーバーとスタンバイ・サーバーの両方で同じメカニズムを使用してセキュリティ・オブジェクトを管理する必要があります。両方でウォレットを使用するか、両方でOracle Key Vaultを使用する必要があります。

B.14 高可用性モードでのフェイルオーバーの状況

次のセクションでは、Oracle Key Vaultの各種バージョンおよび読取り専用制限モードが無効および有効なOracle Key Vault 12.2.0.5.0の高可用性モード・デプロイメントで発生する一般的なフェイルオーバー・シナリオについて説明します。

• フェイルオーバーの状況のタイプ
  
• 読取り制限モードなしでのフェイルオーバーの状況
  
• 読取り制限モードでのフェイルオーバーの状況
  
• 計画停止の実行
  

B.14.1のフェイルオーバーの状況のタイプ

フェイルオーバーの状況のタイプは次のとおりです。

• プライマリ・サーバーの計画停止: アップグレードまたはメンテナンス期間中にシステム管理者によってプライマリ・サーバーが停止されます。

• スタンバイ・サーバーの計画停止:アップグレードまたはメンテナンス期間中にシステム管理者によってスタンバイ・サーバーが停止されます。

• プライマリ・サーバーの計画外停止: 電源の切断やネットワーク障害などの予期せぬ事態のためにプライマリ・サーバーがオフラインです。

• スタンバイ・サーバーの計画外停止: 電源の切断やネットワーク障害などの予期せぬ事態のためにスタンバイ・サーバーがオフラインです。

B.14.2 読取り専用制限モードなしでのフェイルオーバーの状況

次の表に、次のバージョンのOracle Key Vaultで発生する可能性のある、様々なフェイルオーバーの状況を示します。

• 12.2.0.0.0

• 12.2.0.1.0

• 12.2.0.2.0

• 12.2.0.3.0

• 12.2.0.4.0

• 12.2.0.5.0 (読取り制限モードなし)

表B-2 読取り制限モードなしでのフェイルオーバーの状況

番号	フェイルオーバーの状況	プライマリ・サーバーの状態	スタンバイ・サーバーの状態	フェイルオーバーが発生するかどうか	詳細	リカバリ・ステップ
1	プライマリ・サーバー: アップグレード中の計画停止	停止	稼働中	なし	アップグレード中にプライマリ・サーバーがオフラインになると、スタンバイ・サーバーはプライマリ・サーバーがオンラインに戻るのを読取りモードで待機します。アップグレード中は、Oracle Key Vault管理コンソールにアクセスできません。 フェイルオーバーは発生しません。 アップグレード中のプライマリ・サーバーの計画停止の実行の詳細は、「アップグレード中のプライマリ・サーバーの計画停止の実行」を参照してください。	アップグレード後にプライマリ・サーバーがオンラインに戻ると、スタンバイ・サーバーはプライマリ・サーバーと自動的に同期されます。プライマリ・サーバーとスタンバイ・サーバーは以前のロールを保持し、両方とも引き続き高可用性モードで動作します。
2	プライマリ・サーバー: メンテナンス中の計画停止	停止	稼働中	あり	メンテナンス中にプライマリ・サーバーの電源が切断されたり再起動された場合、スタンバイ・サーバーがプライマリ・サーバーから後を引き継ぎます。 注意: メンテナンス中のプライマリ・サーバーの計画停止の実行の詳細は、「メンテナンス中のプライマリ・サーバーの計画停止の実行」を参照してください。	スタンバイ・サーバーが新しいプライマリ・サーバーになります。メンテナンス後に古いプライマリ・サーバーがオンラインに戻ると、新しいプライマリ・サーバーと自動的に同期し、スタンバイ・サーバーのロールを引き継ぎます。どちらのサーバーも引き続き高可用性モードで動作します。 注意: プライマリ・サーバーがオフラインの場合、データ・レプリケーションは無効です。新しいスタンバイ・サーバーと同期する前に新しいプライマリ・サーバーがオフラインになった場合、重要なデータが失われることがあります。
3	スタンバイ・サーバー: 計画停止	稼働中で動作可能	停止	なし	アップグレードまたはメンテナンス中にスタンバイ・サーバーの電源が切断された場合、プライマリ・サーバーは引き続きプライマリ・サーバーとして動作します。読取り/書込み操作は可能です。 アップグレード中のスタンバイ・サーバーの計画停止の実行の詳細は、「アップグレード中のスタンバイ・サーバーの計画停止の実行」を参照してください。 メンテナンス中のスタンバイ・サーバーの計画停止の実行の詳細は、「メンテナンス中のスタンバイ・サーバーの計画停止の実行」を参照してください。	アップグレード後にスタンバイ・サーバーがオンラインに戻ると、プライマリ・サーバーはスタンバイ・サーバーと自動的に同期されます。プライマリ・サーバーとスタンバイ・サーバーは以前のロールを保持し、両方とも引き続き高可用性モードで動作します。 注意: スタンバイ・サーバーがオフラインの場合、データ・レプリケーションは無効です。スタンバイ・サーバーと同期する前にプライマリ・サーバーがオフラインになった場合、重要なデータが失われることがあります。
4	プライマリ・サーバー: 計画外停止	停止	稼働中	あり	電源の切断、ネットワーク障害、ハードウェア障害などによってプライマリ・サーバーがオフラインになると、スタンバイ・サーバーは「Configure High Availability」ページの「Fast Start Failover Threshold」フィールドで指定された時間だけ待機します。指定された時間が過ぎてもプライマリ・サーバーにアクセスできない場合、スタンバイ・サーバーがプライマリ・サーバーから後を引き継ぎます。	スタンバイ・サーバーが新しいプライマリ・サーバーになります。サーバーを再起動するかネットワーク接続を復元して、プライマリ・サーバーに影響を与えた障害を修正します。プライマリ・サーバーがオンラインに戻ると、新しいプライマリ・サーバーと自動的に同期し、スタンバイ・サーバーのロールを引き継ぎます。
5	スタンバイ・サーバー: 計画外停止	稼働中	停止	なし	電源の切断、ネットワーク障害またはハードウェア障害によってスタンバイ・サーバーがオフラインになると、プライマリ・サーバーは使用できなくなります。すべての操作が無効になります。	サーバーを再起動するかネットワーク接続を復元して、スタンバイ・サーバーに影響を与えた障害を修正します。スタンバイ・サーバーがオンラインに戻ると、プライマリ・サーバーと自動的に同期します。プライマリ・サーバーとスタンバイ・サーバーの間で同期またはネットワーク接続を再確立できない場合は、Oracleサポートに問い合せてください。

B.14.3 読取り専用制限モードでのフェイルオーバーの状況

次の表に、Oracle Key Vault 12.2.0.5.0以降(読取り専用制限モードが有効化された)で発生する可能性のある、様々なフェイルオーバーの状況を示します。

表B-3 12.2.0.5.0以降(読取り専用制限モードが有効化された)でのフェイルオーバーの状況

番号	フェイルオーバーの状況	プライマリ・サーバーの状態	スタンバイ・サーバーの状態	フェイルオーバーが発生するかどうか	詳細	リカバリ・ステップ
1	プライマリ・サーバー: アップグレード中の計画停止	停止	稼働中	なし	アップグレード中にプライマリ・サーバーがオフラインになると、スタンバイ・サーバーは読取り専用モードになり、プライマリ・サーバーがオンラインに戻るのを待機します。アップグレード中は、Oracle Key Vault管理コンソールにアクセスできません。 フェイルオーバーは発生しません。 アップグレード中のプライマリ・サーバーの計画停止の実行の詳細は、「アップグレード中のプライマリ・サーバーの計画停止の実行」を参照してください。	アップグレード後にプライマリ・サーバーがオンラインに戻ると、スタンバイ・サーバーはプライマリ・サーバーと自動的に同期されます。プライマリ・サーバーとスタンバイ・サーバーは以前のロールを保持し、両方とも引き続き高可用性モードで動作します。
2	プライマリ・サーバー: メンテナンス中の計画停止	停止	稼働中	あり	メンテナンス中にプライマリ・サーバーの電源が切断されたり再起動された場合、スタンバイ・サーバーは読取り専用モードになり、プライマリ・サーバーから後を引き継ぎます。Oracle Key Vault管理コンソールに警告が表示されます。 メンテナンス中のプライマリ・サーバーの計画停止の実行の詳細は、「メンテナンス中のプライマリ・サーバーの計画停止の実行」を参照してください。	スタンバイ・サーバーが新しいプライマリ・サーバーになります。メンテナンス後に古いプライマリ・サーバーがオンラインに戻ると、新しいプライマリ・サーバーと自動的に同期し、スタンバイ・サーバーのロールを引き継ぎます。どちらのサーバーも引き続き高可用性モードで動作します。
3	スタンバイ・サーバー: 計画停止	稼働中で動作可能	停止	なし	アップグレードまたはメンテナンス中にスタンバイ・サーバーの電源が切断された場合、プライマリ・サーバーは読取り専用モードになり、引き続きプライマリ・サーバーとして動作します。Oracle Key Vault管理コンソールに警告が表示されます。 アップグレード中のスタンバイ・サーバーの計画停止の実行の詳細は、「アップグレード中のスタンバイ・サーバーの計画停止の実行」を参照してください。 メンテナンス中のスタンバイ・サーバーの計画停止の実行の詳細は、「メンテナンス中のスタンバイ・サーバーの計画停止の実行」を参照してください。	アップグレード後にスタンバイ・サーバーがオンラインに戻ると、プライマリ・サーバーはスタンバイ・サーバーと自動的に同期されます。プライマリ・サーバーとスタンバイ・サーバーは以前のロールを保持し、両方とも引き続き高可用性モードで動作します。
4	プライマリ・サーバー: 計画外停止	停止	稼働中	あり	電源の切断、ネットワーク障害、ハードウェア障害などによってプライマリ・サーバーがオフラインになると、スタンバイ・サーバーは「Configure High Availability」ページの「Fast Start Failover Threshold」フィールドで指定された時間だけ待機します。指定された時間が過ぎてもプライマリ・サーバーにアクセスできない場合、スタンバイ・サーバーは読取り専用モードになり、プライマリ・サーバーから後を引き継ぎます。	スタンバイ・サーバーが新しいプライマリ・サーバーになります。サーバーを再起動するかネットワーク接続を復元して、プライマリ・サーバーに影響を与えた障害を修正します。プライマリ・サーバーがオンラインに戻ると、新しいプライマリ・サーバーと自動的に同期し、スタンバイ・サーバーのロールを引き継ぎます。
5	スタンバイ・サーバー: 計画外停止	稼働中	停止	なし	電源の切断、ネットワーク障害、ハードウェア障害などによってスタンバイ・サーバーがオフラインになると、プライマリ・サーバーは「Configure High Availability」ページの「Fast Start Failover Threshold」フィールドで指定された時間だけ待機します。指定された時間が過ぎてもスタンバイ・サーバーにアクセスできない場合、プライマリ・サーバーは読取り専用モードになり、引き続きプライマリ・サーバーとして動作します。	サーバーを再起動するかネットワーク接続を復元して、スタンバイ・サーバーに影響を与えた障害を修正します。スタンバイ・サーバーがオンラインに戻ると、プライマリ・サーバーと自動的に同期します。プライマリ・サーバーとスタンバイ・サーバーの間で同期またはネットワーク接続を再確立できない場合は、Oracleサポートに問い合せてください。

B.14.4 計画停止の実行

計画停止は、アップグレードまたはメンテナンス期間中にシステム管理者によって実行されます。

• プライマリ・サーバーの計画停止
  
• スタンバイ・サーバーの計画停止
  

B.14.4.1 プライマリ・サーバーの計画停止

プライマリ・サーバーの計画停止は、アップグレードまたはメンテナンス期間中にシステム管理者によって実行されます。

注意:

アップグレード後、プライマリ・サーバーとスタンバイ・サーバーは古いロールを保持します。メンテナンス期間後、プライマリ・サーバーとスタンバイ・サーバーはロールを切り替えます。

• アップグレード中のプライマリ・サーバーの計画停止の実行
  
• メンテナンス中のプライマリ・サーバーの計画停止の実行
  

B.14.4.1.1 アップグレード中のプライマリ・サーバーの計画停止の実行

アップグレード中にプライマリ・サーバーの計画停止を実行するには、「高可用性デプロイメントにおけるKey Vaultサーバーのペアのアップグレード」の手順に従います。

アップグレード中、フェイルオーバーは発生しません。アップグレード後にプライマリ・サーバーがオンラインに戻った後、プライマリ・サーバーとスタンバイ・サーバーの以前のロールは保持されます。

B.14.4.1.2 メンテナンス中のプライマリ・サーバーの計画停止の実行

メンテナンス中にプライマリ・サーバーの計画停止を実行するには、Oracle Key Vaultの電源を切断するか再起動します。

「Settings」ページで「Power Off」ボタンをクリックして、Oracle Key Vaultの電源を切断します。ターミナルを使用してOracle Key Vaultの電源を切断することもできます。

「Settings」ページで「Reboot」ボタンをクリックして、Oracle Key Vaultを再起動します。ターミナルを使用してOracle Key Vaultを再起動することもできます。

プライマリ・サーバーが停止されると、スタンバイ・サーバーは「Configure High Availability」ページの「Fast Start Failover Threshold」フィールドで指定された時間だけ待機します。その時間が過ぎると、スタンバイ・サーバーにフェイルオーバーされ、スタンバイ・サーバーがプライマリ・サーバーから後を引き継ぎます。スタンバイ・サーバーが新しいプライマリ・サーバーになります。

古いプライマリ・サーバーがメンテナンス後にオンラインに戻ると、スタンバイ・サーバーのロールを引き継ぎます。

B.14.4.2 スタンバイ・サーバーの計画停止

スタンバイ・サーバーの計画停止は、メンテナンス期間中にシステム管理者によって実行されます。アップグレード中、スタンバイ・サーバーは自動的に停止され、手動によるステップは不要です。

• アップグレード中のスタンバイ・サーバーの計画停止の実行
  
• メンテナンス中のスタンバイ・サーバーの計画停止の実行
  

B.14.4.2.1 アップグレード中のスタンバイ・サーバーの計画停止の実行

アップグレード中にスタンバイ・サーバーの計画停止を実行するには、「高可用性デプロイメントにおけるKey Vaultサーバーのペアのアップグレード」の手順に従います。

注意:

アップグレード中にスタンバイ・サーバーを再起動すると、アップグレード・スクリプトは自動停止を開始します。スタンバイ・サーバーが再起動された後に実行する手動によるステップはありません。

B.14.4.2.2 メンテナンス中のスタンバイ・サーバーの計画停止の実行

メンテナンス中にスタンバイ・サーバーの計画停止を実行するには:

1. SSHを使用してユーザーsupportとしてスタンバイ・サーバー・ターミナルにログインして、ユーザー(su)をrootに切り替えます。
2. ユーザー(su)をoracleに切り替えます。
3. SQL *Plusを開き、データベースで次のコマンドを実行します。

   alter database recover managed standby database cancel
   shutdown immediate

4. スタンバイ・サーバーの電源をオフにします。