既知の問題

詳細: 合成モニタリングでは、ブラウザおよびスクリプト化ブラウザ・モニターで、フレームを使用するアプリケーションの実行に失敗することがあります。

回避策: 問題を認識しており、解決に取り組んでいます。スクリプト化ブラウザ・モニターの場合、.sideスクリプトのindex=<frame-index>をid=<id-of-frame>またはname=<name-of-frame>に置き換えることで、この問題を回避できます。

たとえば、次のスクリプトが元のバージョンの場合:

{
      "id": "23956f51-8812-40e6-ac91-1d608871ee4c",
      "comment": "",
      "command": "selectFrame",
      "target": "index=0",
      "targets": [
        ["index=0"]
      ],
      "value": ""
    }

次のスクリプトが変更後のバージョンになります:

{
      "id": "23956f51-8812-40e6-ac91-1d608871ee4c",
      "comment": "",
      "command": "selectFrame",
      "target": "id=frame1",
      "targets": [
        ["id=frame1"]
      ],
      "value": ""
    }

この問題への直接リンク: ブラウザおよびスクリプト化ブラウザ・モニターで、フレームを使用するアプリケーションが実行されない場合がある

詳細: apm-domainsリソース・タグに基づく認可ポリシーは、トレース・エクスプローラおよび合成モニタリングAPIでは機能しないため、認可は失敗します。

回避策: 問題を認識しており、解決に取り組んでいます。

この問題への直接リンク: apm-domainsリソース・タグに基づく認可ポリシーに関する問題

詳細: ボールト暗号化キーを使用するよう構成されたボリュームのリージョン間レプリケーションを有効化しようとすると、次のエラー・メッセージが表示されます: ボリュームの編集エラー: ボリューム<volume_ID>ではボールト暗号化キーが使用されているため、リージョン間レプリケーションを有効化できません。

回避策: 解決に向けて取り組んでいます。顧客管理キーで暗号化されたボリュームでは、リージョン間レプリケーションがサポートされません。レプリケーションを有効化するための回避策として、ボリュームからボールト暗号化キーの割当てを解除してください。このシナリオでは、ボリュームはOracle管理キーで暗号化されます。

この問題への直接リンク: 顧客管理キーで暗号化されたボリュームで、リージョン間レプリケーションがサポートされない

詳細: 超高パフォーマンス用に構成されたボリュームの最適なパフォーマンス・レベルを達成するには、ボリューム・アタッチメントがマルチパス対応である必要があります。VMインスタンスに対するマルチパス対応のアタッチメントは、16個以上のOCPUを持つシェイプに基づくインスタンスでのみサポートされます。

16個未満のOCPUを持つインスタンスがある場合、OCPUが16個以上になるようにインスタンスのサイズを変更することで、マルチパス対応のアタッチメントをサポートできます。このステップは、元のOCPU数が8未満でボリューム・アタッチメントが準仮想化されているインスタンスに対しては効果がありません。このシナリオでは、ボリュームがデタッチされて再アタッチされた後、インスタンスがマルチパス対応のアタッチメントをサポートしていても、ボリューム・アタッチメントはマルチパス対応になりません。

回避策: 回避策として、16個以上のOCPUを持つシェイプに基づいて新しいインスタンスを作成してから、ボリュームを新しいインスタンスにアタッチすることをお薦めします。

この問題への直接リンク: インスタンスのサイズ変更後に準仮想化ボリューム・アタッチメントがマルチパス対応ではない

詳細: 最大数のブロック・ボリュームを小さいVM.Standard.A1.Flexインスタンスにアタッチしようとすると、ボリュームのアタッチに失敗する場合があります。これは、基盤となる物理ホスト構成に制限があるために発生します。

回避策: 解決に向けて取り組んでいます。回避策として、VMのサイズ変更によりVMのサイズを拡大してから、ボリュームの接続を再試行することをお薦めします。

この問題への直接リンク: 最大数のブロック・ボリュームを小さいVM.Standard.A1.Flexインスタンスにアタッチすると失敗する場合がある

詳細: ボールト・サービスの暗号化キーを使用して暗号化されたボリュームのリージョン間コピーに対して有効になっているバックアップ・ポリシーを使用して、ボリュームおよびボリューム・グループのバックアップをスケジュールすると、暗号化キーはボリューム・バックアップとともに宛先リージョンにコピーされません。宛先リージョン内のボリューム・バックアップ・コピーは、かわりにOracle提供のキーを使用して暗号化されます。

回避策: 解決に向けて取り組んでいます。回避策として、手動またはスクリプトを使用してボリューム・バックアップおよびボリューム・グループ・バックアップをリージョン間でコピーし、コピー操作のターゲット・リージョンでキー管理キーIDを指定できます。手動でのリージョン間コピーの詳細は、リージョン間でのボリューム・バックアップのコピーを参照してください。

この問題への直接リンク: スケジュール済のリージョン間バックアップ・コピーでボールト暗号化キーが宛先リージョンにコピーされない

詳細: Windowsブート・ボリュームをデータ・ボリュームとして別のインスタンスにアタッチする場合、「ブロック・ボリュームに接続」に示すステップを使用してボリュームに接続しようとすると、ボリュームのアタッチに失敗し、次のエラーが発生する可能性があります:

Connect-IscsiTarget : The target has already been logged in via an iSCSI session.

回避策: コンソールからコピーしたConnect-IscsiTargetコマンドに、次のものを追加する必要があります:

-IsMultipathEnabled $True

この問題への直接リンク: Windowsブート・ボリュームをデータ・ボリュームとして別のインスタンスにアタッチすることは失敗します

詳細: GetInstanceをコールすると、InstanceSourceViaImageDetailsのbootVolumeSizeInGBs属性がnullです。

回避策: 解決に向けて取り組んでいます。この問題を回避するには、GetBootVolumeをコールして、BootVolumeのsizeInGBs属性を使用します。

この問題への直接リンク: bootVolumeSizeInGBs属性がnullです

詳細: Firefoxを使用してコンソールにアクセスしようとした場合、コンソール・ページがブラウザにロードされません。この問題は、Firefoxユーザー・プロファイルの破損が原因であると考えられます。

回避策: 新しいFirefoxユーザー・プロファイルを次のように作成します:

1. Firefoxの最新バージョンを使用していることを確認します。そうでない場合、最新バージョンに更新します。
2. 新しいユーザー・プロファイルを作成し、古いユーザー・プロファイルを削除します。ユーザー・プロファイルを作成および削除する手順は、Mozillaサポートを参照してください: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles。
3. 新しいプロファイルでFirefoxを開きます。

または、他のサポートされているブラウザのいずれかを使用できます。

この問題への直接リンク: Firefoxブラウザのバグにより、コンソールがロードされない場合があります

詳細: 新しく作成されたデータベースに既存のPDBは表示されません。また、コンソールに表示されるまでに数時間かかる場合があります。これには、新規データベースの場合はデフォルトのPDBが含まれ、クローニングまたはリストアされたデータベースの場合は既存のPDBが含まれます。旧バージョンへのインプレース・リストアの場合、PDBリストは同様に更新され、遅延が発生する可能性があります。

回避策: なし

この問題への直接リンク: 新規データベース内の既存のPDB

詳細: コンソールまたはAPIでは、プライマリ・データベースでのPDBの作成およびクローニングは許可されていません。

回避策: プライマリ・データベースでのPDBの作成またはクローニングには、sqlplusを使用できます。これらは後でOCIコンソールで同期されます。

この問題への直接リンク: 既存のData Guard構成におけるPDB

詳細: データベース・サービスAPIを使用して、Oracle Database 12cリリース1 (12.1.0.2)でファイルベースのTDEウォレットを顧客管理キーベースのTDEウォレットに移行すると、次のエラーで失敗します:

[FATAL] [DBAAS-11014] - 必要なパッチ(30128047)がOracleホーム<ORACLE_HOME>に存在しません。
処置: 必要なパッチ(30128047)を適用し、操作を再試行してください

nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

前述のコマンドの<kms_key_ocid>は、使用している顧客管理キーのOCIDです。

詳細: データベース・サービスAPIを使用して、Oracle Database 12cリリース1 (12.1.0.2)で顧客管理キーベースのTDEウォレットをファイルベースのTDEウォレットに移行すると、次のエラーで失敗します:

[FATAL] [DBAAS-11014] - 必要なパッチ(30128047)がOracleホーム<ORACLE_HOME>に存在しません。
処置: 必要なパッチ(30128047)を適用し、操作を再試行してください

nohup /var/opt/oracle/dbaascli/dbaascli tde hsm_to_file --dbname <database_name> --skip_patch_check true &

詳細: データベース・サービスAPIを使用して、Oracle Database 12cリリース2 (12.2.0.1)でファイルベースのTDEウォレットを顧客管理キーベースのTDEウォレットに移行すると、次のエラーで失敗します:

[FATAL] [DBAAS-11014] - 必要なパッチ(30128047)がOracleホーム<ORACLE_HOME>に存在しません。
処置: 必要なパッチ(30128047)を適用し、操作を再試行してください

回避策: 次のように、ファイルベースのTDEウォレットを顧客管理キーベースのTDEウォレットに移行します:

1. 次のように、データベースでいずれかのAutonomous DatabaseまたはCDB$ROOTのUNDO表領域またはTEMP表領域が暗号化されているかどうかを確認します:
   CDB$ROOTから次の問合せを実行して、すべてのAutonomous Databaseに含まれているすべての暗号化された表領域をリストします:

   SQL> select tstab.con_id, tstab.name from v$tablespace tstab, v$encrypted_tablespaces enctstab where tstab.ts# = enctstab.ts# and encryptedts = 'YES';

   次に、問合せの結果の「NAME」列で、UNDO表領域およびTEMP表領域の名前を検索します。暗号化されたUNDO表領域またはTEMP表領域がある場合は、次のステップに進みます。

2. 次のように、UNDO表領域またはTEMP表領域を暗号化解除します:

   UNDO表領域が暗号化されている場合

   次のように、既存のUNDO表領域を暗号化解除します:

   SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

   暗号化されたすべてのUNDO表領域に対して、この手順を繰り返します。

   TEMP表領域が暗号化されている場合

   1. 次のように、デフォルトのTEMP表領域を確認します:

      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';

      デフォルトのTEMP表領域は暗号化されていないが、他のTEMP表領域が暗号化されている場合は、次のように、他のTEMP表領域を削除します:

      SQL> drop tablespace <temp_tablespace_name>;

      この手順の残りのステップはスキップします。

      デフォルトのTEMP表領域が暗号化されている場合は、残りの手順に進み、暗号化されていないデフォルトのTEMP表領域を作成および設定します。

   2. 次のように、encrypt_new_tablespacesパラメータをDDLに設定します:

      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;

   3. 次のように、現在のTEMP表領域の仕様でTEMP表領域を作成します:

      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;

   4. 次のように、新しいTEMP表領域をデータベースのデフォルトのTEMP表領域として設定します:

      SQL> alter database default temporary tablespace <temp_tablespace_name>;

   5. 次のように、既存のTEMP表領域を削除します:

      SQL> drop tablespace <temp_tablespace_name>;

   暗号化されたすべてのTEMP表領域に対して、この手順を繰り返します。

   データベースは、暗号化されていないデフォルトのUNDO表領域およびTEMP表領域で実行され、古いTEMP表領域およびUNDO表領域も復号化されます。

   次のように、encrypt_new_tablespacesを元の値に設定します:

   SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

   顧客管理キーへのキーストアの移行に進みます。

3. いずれのプラガブル・データベースにもCDB$ROOTにも暗号化されたUNDO表領域またはTEMP表領域がないことを確認したら、DBAASCLIユーティリティを--skip_patch_check trueフラグとともに使用して、バグ30128047のパッチの検証をスキップします。Oracleホームでバグ31527103のパッチが適用されていることを確認してから、次のdbaascliコマンドを実行します:

   nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

   前述のコマンドの<kms_key_ocid>は、使用している顧客管理キーのOCIDです。

詳細: データベース・サービスAPIを使用して、Oracle Database 12cリリース2 (12.2.0.1)で顧客管理キーベースのTDEウォレットをファイルベースのTDEウォレットに移行すると、次のエラーで失敗します:

[FATAL] [DBAAS-11014] - 必要なパッチ(30128047)がOracleホーム<ORACLE_HOME>に存在しません。
処置: 必要なパッチ(30128047)を適用し、操作を再試行してください

回避策: 次のように、顧客管理キーベースのTDEウォレットをファイルベースのTDEウォレットに移行します:

1. 次のように、データベースでいずれかのAutonomous DatabaseまたはCDB$ROOTのUNDO表領域またはTEMP表領域が暗号化されているかどうかを確認します:
   CDB$ROOTから次の問合せを実行して、すべてのAutonomous Databaseに含まれているすべての暗号化された表領域をリストします:

   SQL> select tstab.con_id, tstab.name from v$tablespace tstab, v$encrypted_tablespaces enctstab where tstab.ts# = enctstab.ts# and encryptedts = 'YES';

   次に、問合せの結果の「NAME」列で、UNDO表領域およびTEMP表領域の名前を検索します。暗号化されたUNDO表領域またはTEMP表領域がある場合は、次のステップに進みます。

2. 次のように、UNDO表領域またはTEMP表領域を暗号化解除します:

   UNDO表領域が暗号化されている場合

   次のように、既存のUNDO表領域を暗号化解除します:

   SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

   暗号化されたすべてのUNDO表領域に対して、この手順を繰り返します。

   TEMP表領域が暗号化されている場合

   1. 次のように、デフォルトのTEMP表領域を確認します:

      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';

      デフォルトのTEMP表領域は暗号化されていないが、他のTEMP表領域が暗号化されている場合は、次のように、他のTEMP表領域を削除します:

      SQL> drop tablespace <temp_tablespace_name>;

      この手順の残りのステップはスキップします。

      デフォルトのTEMP表領域が暗号化されている場合は、残りの手順に進み、暗号化されていないデフォルトのTEMP表領域を作成および設定します。

   2. 次のように、encrypt_new_tablespacesパラメータをDDLに設定します:

      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;

   3. 次のように、現在のTEMP表領域の仕様でTEMP表領域を作成します:

      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;

   4. 次のように、新しいTEMP表領域をデータベースのデフォルトのTEMP表領域として設定します:

      SQL> alter database default temporary tablespace <temp_tablespace_name>;

   5. 次のように、既存のTEMP表領域を削除します:

      SQL> drop tablespace <temp_tablespace_name>;

   暗号化されたすべてのTEMP表領域に対して、この手順を繰り返します。

   データベースは、暗号化されていないデフォルトのUNDO表領域およびTEMP表領域で実行され、古いTEMP表領域およびUNDO表領域も復号化されます。

   次のように、encrypt_new_tablespacesを元の値に設定します:

   SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

   顧客管理キーへのキーストアの移行に進みます。

3. いずれのプラガブル・データベースにもCDB$ROOTにも暗号化されたUNDO表領域またはTEMP表領域がないことを確認したら、DBAASCLIユーティリティを--skip_patch_check trueフラグとともに使用して、バグ30128047のパッチの検証をスキップします。Oracleホームでバグ29667994のパッチが適用されていることを確認してから、次のdbaascliコマンドを実行します:

   nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

   前述のコマンドの<kms_key_ocid>は、使用している顧客管理キーのOCIDです。

詳細: BYOLから付属のライセンスに、またはその逆にデータベースまたはDBシステムのライセンス・タイプを変更すると、最初の1時間は両方のタイプのライセンスに対して請求されます。その後は、更新されたライセンス・タイプに従って請求されます。

回避策: 解決に向けて取り組んでいます。

この問題への直接リンク: ライセンス・タイプ変更時の請求の問題

詳細: サービス・ゲートウェイを使用してVCNを構成する場合、プライベート・サブネットによって、OSの更新に必要なYUMリポジトリへのアクセスがブロックされます。この問題は、すべてのタイプのDBシステムに影響を与えます。

回避策: この問題は解決されました。問題の解決前に推奨されていた回避策は次のとおりです:

Oracle Services Networkのすべての<region>サービスという使用可能なサービスCIDRラベルを使用すると、サービス・ゲートウェイによりOracle YUMリポジトリへのアクセスが可能になります。ただし、サービス・ゲートウェイを介してYUMサービスにアクセスする場合は引き続き問題が発生する可能性があります。この問題には解決策があります。詳細は、サービス・ゲートウェイを介してインスタンスがOracle yumサービスにアクセスする際の問題を参照してください。

この問題への直接リンク: サービス・ゲートウェイでは、現在OSの更新がサポートされていません

詳細: データベースCLI (dbcli)またはRMANを使用したオブジェクト・ストレージへの管理対象外のバックアップが次のエラーで失敗します:

-> Oracle Error Codes found:
-> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> KBHS-00712: ORA-29024 received from local HTTP service
-> ORA-27023: skgfqsbi: media manager protocol error

Symantec証明書に関して、2つの共通のWebブラウザによって実装されるポリシーに従い、Oracleでは、Oracle Cloud Infrastructureで使用される認証局が最近変更されました。SSL証明書が変更された結果、Oracle Database Cloud Backupモジュールが古い証明書をまだ参照していると、オブジェクト・ストレージへのバックアップが失敗する可能性があります。

dbcliの回避策: ログ・ファイルで、リストされたエラーを確認し、見つかった場合はバックアップ・モジュールを更新します。

RMANのバックアップ・ログ・ファイルで前述のエラーを確認します:

1. 失敗したバックアップ・ジョブのIDを確認します。

   dbcli list-jobs

   この出力例では、失敗したバックアップ・ジョブのIDは、"f59d8470-6c37-49e4-a372-4788c984ea59"です。

   root@<node name> ~]# dbcli list-jobs
    
   ID                                       Description                                                                 Created                             Status
   ---------------------------------------- --------------------------------------------------------------------------- ----------------------------------- ----------
   cbe852de-c0f3-4807-85e8-7523647ec78c     Authentication key update for DCS_ADMIN                                     March 30, 2018 4:10:21 AM UTC       Success
   db83fdc4-5245-4307-88a7-178f8a0efa48     Provisioning service creation                                               March 30, 2018 4:12:01 AM UTC       Success
   c1511a7a-3c2e-4e42-9520-f156b1b4cf0e     SSH keys update                                                             March 30, 2018 4:48:24 AM UTC       Success
   22adf146-9779-4a2c-8682-7fd04d7520b2     SSH key delete                                                              March 30, 2018 4:50:02 AM UTC       Success
   6f2be750-9823-4ed5-b5ff-8e49f136dd22     create object store:bV0wqIaoLA4xLT4dGjOu                                    March 30, 2018 5:33:38 AM UTC       Success
   0716f464-1a10-40df-a303-cadee0302b1b     create backup config:bV0wqIaoLA4xLT4dGjOu_BC                                March 30, 2018 5:33:49 AM UTC       Success
   e08b21c3-cd09-4e3a-944c-d1da96cb21d8     update database : hfdb1                                                     March 30, 2018 5:34:04 AM UTC       Success
   1c3d7c58-79c3-4039-8f48-787057ce7c6e     Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname>    March 30, 2018 5:37:11 AM UTC       Success
   f59d8470-6c37-49e4-a372-4788c984ea59     Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname>    March 30, 2018 5:43:45 AM UTC       Failure

2. 失敗したジョブのIDを使用して、確認するログ・ファイルの場所を取得します。

   
   dbcli describe-job -i <failed_job_ID>

   describe-jobコマンドからの関連出力は次のようになります:

   Message: DCS-10001:Internal error encountered: Failed to run Rman statement.
   Refer log in Node <node_name>: /opt/oracle/dcs/log/<node_name>/rman/bkup/<db_unique_name>/rman_backup/<date>/rman_backup_<date>.log.

Oracle Database Cloud Backupモジュールを更新します:

1. データベースがバックアップに使用するSwiftのオブジェクト・ストアIDおよびユーザーを確認します。

   1. dbcli list-databasesコマンドを実行して、データベースのIDを確認します。

   2. データベースIDを使用して、バックアップ構成ID (backupConfigId)を確認します。

      dbcli list-databases
      dbcli describe-database -i <database_ID> -j

   3. 前のステップでメモしたバックアップ構成IDを使用して、オブジェクト・ストアID (objectStoreId)を確認します。

      dbcli list-backupconfigs
      dbcli describe-backupconfig –i <backupconfig_ID> -j

   4. 前のステップでメモしたオブジェクト・ストアIDを使用して、オブジェクト・ストア・ユーザー(userName)を確認します。

      dbcli list-objectstoreswifts
      dbcli describe-objectstoreswift –i <objectstore_ID> -j

2. ステップ1で取得したオブジェクト・ストア資格証明を使用して、バックアップ・モジュールを更新します。

   dbcli update-objectstoreswift –i <objectstore_ID> -p –u <user_name>

RMANの回避策: RMANのログ・ファイルで、リストされたエラー・メッセージを確認します。見つかった場合は、oracleユーザーとしてホストにログオンし、Swiftの資格証明を使用してバックアップ・モジュールを再インストールします。

java -jar <opc_install.jar_path> -opcId '<swift_user_ID>' -opcPass '<auth_token>' -container <objectstore_container> -walletDir <wallet_directory> -configfile <config_file> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -import-all-trustcerts

マルチノードDBシステムでは、クラスタ内のすべてのノードで回避策を実行してください。

このコマンドの使用方法の詳細は、Oracle Database Cloud Backupモジュールに関するドキュメントを参照してください。

この問題への直接リンク: dbcliまたはRMANを使用したオブジェクト・ストレージへのバックアップが証明書の変更のために失敗します

詳細: 2018年10月18日にリリースされたSDKでは、データベース・サイズとデータベース・バックアップAPIのデータベース・エディション属性の重大な変更が導入されています。

回避策: 重大な変更の詳細は、次の言語固有のドキュメントを参照し、該当する場合は既存のコードを更新してください:

この問題への直接リンク: データベース・サービスSDKの重大な変更

詳細: コンソールまたはAPIを使用しているときに、バックアップおよびリストア操作がDBシステムで機能しない可能性があります。

回避策: Oracle Database Cloud Backupモジュールをインストールしてから、Oracle Support Servicesに連絡して詳細な指示を確認します。

Oracle Database Cloud Backupモジュールをインストールするには:

1. DBシステムにSSHで接続し、opcとしてログインします。

   
   ssh -i <SSH_key> opc@<DB_system_IP address>
   login as: opc

   または、opc @<DB_system_hostname>を使用してログインします。

2. http://www.oracle.com/technetwork/database/availability/oracle-cloud-backup-2162729.htmlからOracle Database Cloud Backupモジュールをダウンロードします。
3. opc_installer.zipの内容をターゲット・ディレクトリ(例: /home/opc)に抽出します。
4. テナンシで、一時ユーザーを作成し、テナンシのオブジェクト・ストレージにアクセスする権限を付与します。
5. この一時ユーザーの場合は、「認証トークンの作業」を作成し、パスワードをノートにとります。

6. 次のcurlコマンドを実行して、資格証明が機能することを確認します:

   ノート
   
   Swiftパスワードは「認証トークン」と呼ばれるようになりました。詳細は、「Swiftでの認証トークンの使用」を参照してください。

   curl -v -X HEAD -u  <user_id>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>

   正しいリージョンを使用するように、https://cloud.oracle.com/infrastructure/storage/object-storage/faqを参照してください。

   コマンドにより、HTTP 200またはHTTP 204 No Contentのいずれかの成功ステータス・レスポンス・コードが返される必要があります。その他のステータス・コードは、オブジェクト・ストレージへの接続中に問題が発生したことを示します。

7. 次のコマンドを実行します。

   java -jar opc_install.jar -opcid <user_id> -opcPass '<auth_token>' -libDir <target_dir> -walletDir <target_dir> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -configFile config.txt

   <target_dir>は、ステップ3でopc_installer.zipを抽出したディレクトリです。

   このコマンドは、libopc.soなどのファイルをダウンロードするため、完了するまでに数分かかることがあります。コマンドが完了すると、ターゲット・ディレクトリに複数のファイル(libopc.soなど)が表示されます。

8. ディレクトリをターゲット・ディレクトリに変更して、lipopc.soおよびopc_install.jarファイルを/opt/oracle/oak/pkgrepos/oss/odbcsディレクトリにコピーします。

   cp libopc.so /opt/oracle/oak/pkgrepos/oss/odbcs

   
   
   cp opc_install.jar /opt/oracle/oak/pkgrepos/oss/odbcs

   (rootとして実行するために、コピー・コマンドとともにsudoを使用することが必要な場合があります。)

9. 次のコマンドを実行して、指定したディレクトリが存在するかどうかを確認します:

   
   
   ls /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs

   このディレクトリが存在する場合は、次のステップを実行します:

   1. /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcsディレクトリにファイルをバックアップします。

   2. 次の2つのコマンドを実行して、このディレクトリ内の既存のlibopc.soファイルとopc_install.jarファイルを置き換えます:

      
      cp libopc.so /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
      cp opc_install.jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs

10. opc_install.jarのバージョンを確認します。

    
    java -jar /opt/oracle/oak/pkgrepos/oss/odbcs/opc_install.jar |grep -i build
    

    /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcsが存在する場合は、次のコマンドも実行します:

    
    java -jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs/opc_install.jar |grep -i build

    どちらのコマンドでも、次の出力が返されます:

    Oracle Database Cloud Backup Module Install Tool, build MAIN_2017-08-16.

11. (オプション)一時ユーザーと、バックアップ・モジュールのインストールに使用したターゲット・ディレクトリを削除します。

手順が完了したら、Oracle Supportまたはテナント管理者に連絡して詳細な指示を確認してください。バックアップを有効にするDBシステムのOCIDを指定する必要があります。

この問題への直接リンク: DBシステムで管理対象バックアップを使用できません

詳細: VM.Standard1.1シェイプを実行しているホスト・マシンのメモリー制限によって、Oracle Cloud Infrastructureで管理される自動データベース・バックアップ・ジョブ(コンソールまたはAPIのいずれかを使用して管理されるジョブ)に障害が発生することがあります。システムのメモリー・パラメータを変更して、この問題を解決できます。

回避策: システムのメモリー・パラメータを次のように変更します:

1. オペレーティング・システムのoracleユーザーに切り替えます。

   [opc@hostname ~]$ sudo su - oracle

2. データベース・インスタンスにログインするように環境変数を設定します。例:

   
   [oracle@hostname ~]$ . oraenv
    ORACLE_SID = [oracle] ? orcl
   				

3. SQL*Plusを起動します。

   [oracle@hostname ~]$ sqlplus / as sysdba

4. 初期メモリー・パラメータを次のように変更します:

   
   SQL> ALTER SYSTEM SET SGA_TARGET = 1228M scope=spfile;
   SQL> ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 1228M;
   SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT = 2457M;
   SQL> exit
   							

5. データベース・インスタンスを再起動します。

   
   [oracle@hostname ~]$ srvctl stop database -d db_unique_name -o immediate
   [oracle@hostname ~]$ srvctl start database -d db_unique_name -o open								

この問題への直接リンク: プロセス・クラッシュのために管理対象自動バックアップがVM.Standard1.1シェイプで失敗します

詳細: High PerformanceおよびExtreme Performance DBシステムで、圧縮または並列(あるいはその両方)を使用するデータ・ポンプ・ユーティリティ操作が失敗することがあり、エラー「ORA-00439: 機能は有効ではありません」が返されます。この問題は、データベース・バージョン12.1.0.2.161018および12.1.0.2.170117に影響します。

回避策: データベース・バージョン12.1.0.2.161018または12.1.0.2.170117のOracle Databaseホームにそれぞれパッチ25579568または25891266を適用します。または、コンソールを使用して、2017年4月のパッチをDBシステムとデータベース・ホームに適用します。

この問題への直接リンク: Oracle Data Pumpの操作で「ORA-00439: 機能は有効ではありません」が返されます

詳細: 適切な権限が自動的に適用されなかったため、1ノードのDBシステムからEM Expressコンソールに接続しようとすると、「セキュアな接続が失敗しました。」というエラー・メッセージが表示される場合があります。

回避策: DBシステムのウォレット・ディレクトリに対するasmadminグループの読取り権限を追加してから、接続を再試行します:

1. DBシステム・ホストにSSHで接続し、opcとしてログインし、sudoでgridユーザーに移行します。

   [opc@dbsysHost ~]$ sudo su - grid
   [grid@dbsysHost ~]$ . oraenv
   ORACLE_SID = [+ASM1] ?
   The Oracle base has been set to /u01/app/grid
   

2. 次のコマンド出力に赤色で示されているウォレット・ディレクトリの場所を確認します。

   [grid@dbsysHost ~]$ lsnrctl status | grep xdb_wallet
   
   (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=dbsysHost.sub04061528182.dbsysapril6.oraclevcn.com)(PORT=5500))(Security=(my_wallet_directory=/u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet))(Presentation=HTTP)(Session=RAW))

3. opcユーザーに戻り、oracleユーザーに切り替えて、ウォレット・ディレクトリに変更します。

   [opc@dbsysHost ~]$ sudo su - oracle
   [oracle@dbsysHost ~]$ cd /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet

4. ディレクトリの内容をリストし、権限をメモします。

   
   [oracle@dbsysHost xdb_wallet]$ ls -ltr
   total 8
   -rw------- 1 oracle asmadmin 3881 Apr  6 16:32 ewallet.p12
   -rw------- 1 oracle asmadmin 3926 Apr  6 16:32 cwallet.sso
   

5. 権限を変更します:

   
   [oracle@dbsysHost xdb_wallet]$ chmod 640 /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet/*

6. 読取り権限が追加されたことを確認します。

   [oracle@dbsysHost xdb_wallet]$ ls -ltr
   total 8
   -rw-r----- 1 oracle asmadmin 3881 Apr  6 16:32 ewallet.p12
   -rw-r----- 1 oracle asmadmin 3926 Apr  6 16:32 cwallet.sso
   

この問題への直接リンク: 1ノードのDBシステムからEM Expressコンソールに接続できません

詳細: Exadataバックアップ・ユーティリティ(bkup_api)またはRMANを使用したオブジェクト・ストレージへのバックアップ操作が次のエラーで失敗します:

* DBaaS Error trace:
-> API::ERROR -> KBHS-00715: HTTP error occurred 'oracle-error'
-> API::ERROR -> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> API::ERROR -> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> API::ERROR -> ORA-27023: skgfqsbi: media manager protocol error
-> API::ERROR Unable to verify the backup pieces
-> Oracle Error Codes found:
-> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> KBHS-00712: ORA-29024 received from local HTTP service
-> ORA-27023: skgfqsbi: media manager protocol error

Symantec証明書に関して、2つの共通のWebブラウザによって実装されるポリシーに従い、Oracleでは、Oracle Cloud Infrastructureで使用される認証局が最近変更されました。SSL証明書が変更された結果、Oracle Database Cloud Backupモジュールが古い証明書をまだ参照していると、オブジェクト・ストレージへのバックアップが失敗する可能性があります。

bkup_apiの回避策: ログ・ファイルで、前にリストされたエラーを確認し、見つかった場合はバックアップ・モジュールを再インストールします。

次のコマンドを使用して、失敗したバックアップのステータスを確認します:

/var/opt/oracle/bkup_api/bkup_api bkup_status --dbname=<database_name>

次のコマンドを実行して、バックアップ・モジュールを再インストールします:

/var/opt/oracle/ocde/assistants/bkup/bkup -dbname=<database_name>

RMANの回避策: RMANのログ・ファイルで、リストされたエラー・メッセージを確認します。見つかった場合は、oracleユーザーとしてホストにログオンし、Swiftの資格証明を使用してバックアップ・モジュールを再インストールします。

java -jar <opc_install.jar_path> -opcId '<Swift_user_ID>' -opcPass '<auth_token>' -container <objectstore_container> -walletDir <wallet_directory> -configfile <config_file> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -import-all-trustcerts

クラスタ内のすべてのノードでこの回避策を実行してください。

このコマンドの使用方法の詳細は、Oracle Database Cloud Backupモジュールに関するドキュメントを参照してください。

この問題への直接リンク: bkup_apiまたはRMANを使用したオブジェクト・ストレージへのバックアップが証明書の変更のために失敗します

詳細: Exadata DBシステム用の共有データベース・ホーム機能のリリースにより、コンソールでも、dbaasapiおよびdbaascliユーティリティを使用して作成および管理されるデータベースに関する情報が同期化されて表示されるようになりました。ただし、Data Guardが構成されているデータベースでは、次の条件下で正しい情報がコンソールに表示されません:

• Data Guardがコンソールを使用して有効化されており、dbaascliを使用してプライマリまたはスタンバイ・データベースが変更された場合(データベースを別のホームに移動するなど)、結果はコンソールに反映されません。
• Data Guardが手動で構成された場合、コンソールに2つのデータベース間のData Guardアソシエーションは表示されません。

回避策: 問題を認識しており、解決に取り組んでいます。当面は、コンソールのみまたはコマンドライン・ユーティリティのみを使用してData Guard対応データベースを管理することをお薦めします。

この問題への直接リンク: dbaascliを使用する場合、コンソール情報がData Guard対応データベースに対して同期されない

詳細: これは、Oracle GIのバージョンがバンドル・パッチなしの12.2.0.1の場合にのみ発生するクラスタウェアの問題です。この問題は、投票ディスクをオフラインにしてからオンラインにした後に、そのディスクが破損することによって発生します。

回避策: GIのバージョンと、投票ディスクが破損しているかどうかを確認します。ディスクを修復し(該当する場合)、最新のGIバンドルを適用します。

1. GIバージョンが、バンドル・パッチが適用されていない12.2.0.1であることを確認します:

   
   [root@rmstest-udaau1 ~]# su - grid
   [grid@rmstest-udaau1 ~]$ . oraenv
   ORACLE_SID = [+ASM1] ? +ASM1
   The Oracle base has been set to /u01/app/grid
   [grid@rmstest-udaau1 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory
   Oracle Interim Patch Installer version 12.2.0.1.6
   Copyright (c) 2018, Oracle Corporation.  All rights reserved.
   
   
   Oracle Home       : /u01/app/12.2.0.1/grid
   Central Inventory : /u01/app/oraInventory
      from           : /u01/app/12.2.0.1/grid/oraInst.loc
   OPatch version    : 12.2.0.1.6
   OUI version       : 12.2.0.1.4
   Log file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/opatch2018-01-15_22-11-10PM_1.log
   
   Lsinventory Output file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/lsinv/lsinventory2018-01-15_22-11-10PM.txt
   
   --------------------------------------------------------------------------------
   Local Machine Information::
   Hostname: rmstest-udaau1.exaagclient.sretest.oraclevcn.com
   ARU platform id: 226
   ARU platform description:: Linux x86-64
   
   Installed Top-level Products (1):
   
   Oracle Grid Infrastructure 12c                                       12.2.0.1.0
   There are 1 products installed in this Oracle Home.
   
   
   There are no Interim patches installed in this Oracle Home.
   
   
   --------------------------------------------------------------------------------
   
   OPatch succeeded.

2. 投票ディスクの破損が原因でGIが起動できなかったことの証拠を見つけるには、/u01/app/grid/diag/crs/<hostname>/crs/trace/ocssd.trcファイルを確認します:

   ocssd.trc
    
   2017-01-17 23:45:11.955 :    CSSD:3807860480: clssnmvDiskCheck:: configured 
   Sites = 1, Incative sites = 1, Mininum Sites required = 1 
   2017-01-17 23:45:11.955 :    CSSD:3807860480: (:CSSNM00018:)clssnmvDiskCheck: 
   Aborting, 2 of 5 configured voting disks available, need 3 
   ...... 
   . 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: clssnmCheckForNetworkFailure: 
   skipping 31 defined 0 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: clssnmRemoveNodeInTerm: node 4, 
   slcc05db08 terminated. Removing from its own member and connected bitmaps 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: 
   ################################### 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: clssscExit: CSSD aborting from 
   thread clssnmvDiskPingMonitorThread 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: 
   ################################### 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: (:CSSSC00012:)clssscExit: A 
   fatal error occurred and the CSS daemon is terminating abnormally 
    
   ------------
    
   2017-01-19 19:00:32.689 :    CSSD:3469420288: clssnmFindVF: Duplicate voting disk found in the queue of previously configured disks 
   queued(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009 
   cbd]), 
   found(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009c 
   bd]), is not corrupted 
   2017-01-19 19:01:06.467 :    CSSD:3452057344: clssnmvVoteDiskValidation: 
   Voting disk(o/192.168.10.19/PCW_CD_02_slcc05cel11) is corrupted

3. SQL*Plusを使用して、投票ディスクが破損していることを確認することもできます:

   1. gridユーザーとしてログインし、環境をASMに設定します。

      [root@rmstest-udaau1 ~]# su - grid
      [grid@rmstest-udaau1 ~]$ . oraenv
      ORACLE_SID = [+ASM1] ? +ASM1
      The Oracle base has been set to /u01/app/grid

   2. SYSASMとしてSQL*Plusにログインします。

      $ORACLE_HOME/bin/sqlplus / as sysasm

   3. 次の2つの問合せを実行します:

      SQL> select name, voting_file from v$asm_disk where VOTING_FILE='Y' and group_number !=0;
      SQL> select  CC.name, count(*) from x$kfdat AA JOIN (select disk_number, name from v$asm_disk where VOTING_FILE='Y' and group_number !=0) CC ON CC.disk_number = AA.NUMBER_KFDAT where AA.FNUM_KFDAT= 1048572 group by CC.name;

      システムが正常である場合、結果は次の例のようになります:

      問合せ1の結果

      NAME                           VOTING_FILE
      ------------------------------ ---------------
      DBFSC3_CD_02_SLCLCX0788        Y
      DBFSC3_CD_09_SLCLCX0787        Y
      DBFSC3_CD_04_SLCLCX0786        Y

      問合せ2の結果

      NAME                           COUNT(*)
      ------------------------------ ---------------
      DBFSC3_CD_02_SLCLCX0788        8
      DBFSC3_CD_09_SLCLCX0787        8
      DBFSC3_CD_04_SLCLCX0786        8

      正常なシステムでは、最初の問合せで返されたすべての投票ディスクが2番目の問合せでも返される必要があり、すべてのディスクのカウントがゼロ以外である必要があります。それ以外の場合、1つ以上の投票ディスクが破損しています。

4. 投票ディスクが破損している場合は、投票ディスクを含むグリッド・ディスクをオフラインにします。セルは、不良投票ディスクを他のグリッド・ディスクに自動的に移動し、その投票ディスクをオンラインにします。

   1. 次のコマンドで、DATAC01_CD_05_SCAQAE08CELADM13というグリッド・ディスクをオフラインにします。

      SQL> alter diskgroup DATAC01 offline disk DATAC01_CD_05_SCAQAE08CELADM13;
           Diskgroup altered.

   2. 30秒待機してからステップ3cの2つの問合せを再実行し、投票ディスクが新しいグリッド・ディスクに移行され、正常であることを確認します。

   3. オフラインにしたグリッド・ディスクがオンラインになったことを確認します:

      SQL> select name, mode_status, voting_file from v$asm_disk where name='DATAC01_CD_05_SCAQAE08CELADM13';

      mode_statusはONLINEである必要があり、voting_fileはYではない必要があります。

   破損した投票ディスクが含まれる残りの各グリッド・ディスクについて、ステップ4aから4cを繰り返します。

   ノート
   
   

   投票ディスクの破損が原因でCRSが起動しない場合は、ステップ4でコマンドを実行する前に、排他モードで起動してください。

   crsctl start crs -excl

    

5. バンドル・パッチなしのOracle GIバージョン12.2.0.1を使用している場合、投票ディスクが破損していたかどうかにかかわらず、GIバージョンを最新のGIバンドルにアップグレードする必要があります。

   dbaascliユーティリティを使用してExadata Database Service on Dedicated InfrastructureでOracle Grid InfrastructureおよびOracle Databaseのパッチ適用操作を実行する方法の詳細は、dbaascliを使用したOracle Grid InfrastructureおよびOracle Databaseのパッチ適用を参照してください。

この問題への直接リンク: Grid Infrastructureが、ディスクをオフラインにしてからオンラインにすると起動しません

詳細: 2018年6月15日以降に起動されたExadata DBシステムには、コンソール、APIまたはOracle Cloud Infrastructure CLIを使用してデータベースを作成、リストおよび削除する機能が自動的に含まれます。ただし、この日付よりも前にプロビジョニングされたシステムでは、この機能を有効化するための追加ステップが必要です。

追加ステップなしでこの機能を使用しようとすると、次のエラー・メッセージが表示されます:

• データベースの作成時 - このExadata DBシステムでは「データベースの作成」はサポートされていません。この機能を有効化するには、Oracle Supportに連絡してください。
• データベースの終了時 - このExadata DBシステムではDeleteDbHomeはサポートされていません。この機能を有効化するには、Oracle Supportに連絡してください。

回避策: ExadataエージェントをExadata DBシステムの各ノードにインストールする必要があります。

最初に、Oracle Support Servicesから支援を受けるためにサービス・リクエストを作成します。Oracle Supportは、エージェントを取得できるOracle Cloud Infrastructure Object Storageの場所に対する事前認証済URLを提供して応答します。

Exadataエージェントをインストールする前に:

• Exadata DBシステムのすべてのノード上でツール(dbaastools rpm)を最新バージョンにアップグレードします。Exadata Cloud Serviceインスタンスでのツールの更新を参照してください。
• DBシステムが作成されたリージョンに必要なセキュリティ・リストがあるOracle Cloud Infrastructure Object Storageにアクセスできるように、システムが構成されていることを確認します。Oracle Cloud Infrastructure Object Storageへの接続の詳細は、Exadata Cloud Serviceでのバックアップの前提条件を参照してください。

Exadataエージェントをインストールするには:

1. rootとしてノードにログオンします。

2. 次のコマンドを実行して、エージェントをインストールします:

   [root@<node_n>~]# cd /tmp
   [root@<node_n>~]# wget https://objectstorage.<region_name>.oraclecloud.com/p/1q523eOkAOYBJVP9RYji3V5APlMFHIv1_6bAMmxsS4E/n/dbaaspatchstore/b/dbaasexadatacustomersea1/o/backfill_agent_package_iwwva.tar
   [root@<node_n>~]# tar -xvf /tmp/backfill_agent_package_*.tar -C /tmp
   [root@<node_n>~]# rpm -ivh /tmp/dbcs-agent-2.5-3.x86_64.rpm

   出力例:

   [root@<node_n>~]# rpm -ivh dbcs-agent-2.5-3.x86_64.rpm
   Preparing...                ########################################### [100%]
   Checking for dbaastools_exa rpm on the system
   Current dbaastools_exa version = dbaastools_exa-1.0-1+18.1.4.1.0_180725.0000.x86_64
   dbaastools_exa version dbaastools_exa-1.0-1+18.1.4.1.0_180725.0000.x86_64 is good. Continuing with dbcs-agent installation
      1:dbcs-agent             ########################################### [100%]
   initctl: Unknown instance:
   initctl: Unknown instance:
   initzookeeper start/running, process 85821
   initdbcsagent stop/waiting
   initdbcsadmin stop/waiting
   initdbcsagent start/running, process 85833
   initdbcsadmin start/running, process 85836
   

3. エージェントがインストールされ、実行されていることを確認します。

   [root@<node_n>~]# rpm -qa | grep dbcs-agent
   dbcs-agent-2.5-0.x86_64
   [root@<node_n>~]# initctl status initdbcsagent
   initdbcsagent start/running, process 97832

4. 残りのノードでステップ1から3を繰り返します。

エージェントをすべてのノードにインストールした後、エージェントを最新バージョンにアップグレードしたり、エージェント資格証明をローテーションするなど、Oracleが追加ワークフロー・タスクを完了するために最大30分かかります。プロセスが完了すると、コンソール、APIまたはOracle Cloud Infrastructure CLIでExadata管理対象機能を使用できるようになります。

この問題への直接リンク: 2018年6月15日より前にプロビジョニングされたシステムでは管理対象機能が有効になりません

詳細: パッチ適用構成ファイル(/var/opt/oracle/exapatch/exadbcpatch.cfg)が、Exadata DBシステムが別のリージョンにデプロイされている場合でも、us-phoenix-1リージョンのオブジェクト・ストアを参照します。

この問題は、データベース・ツール・パッケージ(dbaastools_exa)のリリース・バージョンが17430以下の場合に発生します。

回避策: Exadata Cloud Serviceインスタンスでのツールの更新の手順に従って、ツール・パッケージのリリース・バージョンが17430以下であることを確認し、最新バージョンに更新します。

この問題への直接リンク: パッチ適用構成ファイルが間違ったリージョンを参照します

詳細: Oracle Linux 7で一時ファイルを処理する方法が変更されたため、/var/tmp/.oracleディレクトリから必要なソケット・ファイルが削除されることがあります。この問題は、バージョン19.1.2のオペレーティング・システム・イメージを実行しているExadata DBシステムにのみ影響します。

回避策: opcユーザーとしてsudo /usr/local/bin/imageinfoを実行し、オペレーティング・システム・イメージのバージョンを確認します。イメージのバージョンが19.1.2.0.0.190306の場合は、ドキュメントID 2498572.1の指示に従って問題を修正します。

この問題への直接リンク: Oracle Linux 7で必要な一時ファイルが削除されたため、様々なデータベース・ワークフロー障害が発生します

詳細: 同じリージョン内の別々のADでコンピュートおよびストレージのDR操作を実行するときにボリューム・グループ・バックアップを使用する場合、DR移行を行き来すると、コンピュートおよび関連するブロック・ストレージ(ボリューム・グループ・バックアップを使用)が毎回違うADにアクセスする原因となります。

回避策: この問題は、ボリューム・グループ・レプリケーションを使用してレプリケートされたブロック・ストレージには影響しません。

詳細: ブロック・ストレージ・ボリュームのパフォーマンスの自動チューニング設定が、DR操作中に継承されません。

回避策: パフォーマンスの自動チューニングが有効になっているブロック・ストレージ・ボリュームでは、フル・スタックDRによって、これらのブロック・ストレージ・ボリュームが別のリージョンに移行された後に、設定を再度有効にする必要があります。

詳細: フル・スタックのDRで保護されたリソースの変更直後にフェイルオーバー操作を実行した場合、リソースのリカバリが失敗するか、リソースが正しくリカバリされない可能性があります。たとえば、DR保護グループに追加したボリューム・グループのレプリケーション・ターゲットまたはその他のプロパティを変更し、その後すぐにプライマリ・リージョンが停止した場合、フル・スタックDRではボリューム・グループのレプリケーション設定の変更が検出されず、そのボリューム・グループのリカバリに影響します。

回避策: DR保護下のリソースに変更を加えた直後に、スイッチオーバー事前チェックを実行します。

詳細: フル・スタックDRでは、Oracle Cloud Agent (OCA)のコマンドの実行ユーティリティを使用して、インスタンスでローカル・スクリプトが実行されます。Microsoft Windowsインスタンスでローカル・スクリプトを実行するようにユーザー定義ステップを構成する場合は、フル・スタックDRの「実行ユーザー」機能を使用して別のuseridを指定し、インスタンスに存在するローカル・スクリプトを実行することができません。

回避策: Microsoft Windowsインスタンスでスクリプトを実行できるのは、Oracle Cloud Agentのコマンドの実行ユーティリティで使用されるデフォルトのocarunユーザーIDのみです。この制限は、Oracle Linuxインスタンスには影響しません。

詳細: フル・スタックDRでは、Oracle Cloud Agent (OCA)のコマンドの実行ユーティリティを使用して、インスタンスでローカル・スクリプトが実行されます。デフォルトでは、これらのスクリプトは、ocarunユーザーとして実行されます。

回避策: Microsoft Windowsインスタンスでは、DR計画でユーザー定義ステップとして実行するよう構成されたローカル・スクリプトは、このocarunユーザーIDでアクセスして実行できる必要があります。

詳細: DR計画のユーザー定義ステップを使用してローカル・スクリプトを実行する場合、スクリプト・インタプリタまたはスクリプトへのフル・パスを指定しないと、フル・スタックDRでエラーがスローされます。

回避策: DR計画で、インスタンスに存在するローカル・スクリプトを実行するようユーザー定義ステップを構成する際は、スクリプト名の前に付いているインタプリタへのフル・パスと、スクリプトへのフル・パスを必ず指定してください。

詳細: DR操作中に、宛先サブネットのCIDRブロックとソース・サブネットのCIDRブロックが一致し、インスタンスの元のプライベートIPがまだ割り当てられていない場合、Full Stack DRは、インスタンスに割り当てられた元のプライベートIPの再割当てを試みます。

OCFS2クラスタ内のすべてのノードをフル・スタックDRを使用して再配置し、いずれかのクラスタ・ノードのプライベートIPを再割当てできない場合、スタンバイ・リージョンでノードが起動された後に、OCFS2クラスタからそれらのクラスタ・ノードがデタッチされます。

回避策: 宛先サブネットのCIDRブロックとソース・サブネットのCIDRブロックが一致し、クラスタ・ノードに必要なすべてのプライベートIPアドレスが宛先サブネットで使用可能であることを確認してください。

詳細: Full Stack DRがインスタンスを別のリージョンに再配置した後、インスタンス・アクセスに関して、インスタンスのリソース・ページに次のメッセージが表示される場合があります:

このイメージを使用するインスタンスへの接続方法が不明です

回避策: このメッセージは無視します。元のSSHキーファイルを使用してインスタンスに接続し、認証を行うと、インスタンスへのSSH接続が正常に機能します。

詳細: Full Stack DRがインスタンスを別のリージョンに再配置した後、ブート・ボリュームのイメージ部分について、インスタンスのリソース・ページに正しくない情報が表示される場合があります。

たとえば、「イメージ情報」列に、「データのロード中にエラーが発生しました」というメッセージが表示される場合があります

回避策: このエラー・メッセージはイメージ名の表示用ですが、インスタンスまたはそのブート・ボリュームの操作には影響しません。

詳細: nohupコマンドのスリープ時間がない場合、runコマンドは実行に失敗し、ステータスを正常に報告できません。

nohup sh enabler.sh  &> enabler.log &
sleep 10
exit 0

詳細: DR遷移中に、ブロック・ボリュームを別のリージョンに移動すると、パフォーマンス設定(IOPSおよびスループット)は自動的にレプリケートおよびリストアされません。これらのパフォーマンス設定の再構成が必要になる場合があります。

回避方法: DR計画の実行後、パフォーマンス設定を手動で構成します。

詳細: Windowsマシンで作成されたzipファイルのオンデマンド・アップロードで、ログ・コンテンツのアップロードに失敗することがあります。失敗の理由は、Windowsで作成されたzipの最終変更時間がファイルの作成時間と同じであることです。そのため、ファイルが解凍されると、ファイルの最終変更時間がファイルの作成時間として設定されますが、それがログ・ファイル内のログ・エントリのタイムスタンプより古い可能性があります。このような場合、ファイルの最終変更時刻より新しいタイムスタンプを持つログ・エントリはアップロードされません。

問題の例:

ログ・エントリのタイムスタンプ: 2020-10-12 21:12:06

ログ・ファイルの最終変更時間: 2020-10-10 08:00:00

回避策: ログ・ファイルを新しいフォルダにコピーし、zipファイルを作成します。このアクションにより、ファイルの最終変更時間がログ・エントリのタイムスタンプより新しくなります。この新しいzipファイルをオンデマンド・アップロードに使用します。

回避策の実施後に、前の例を使用:

ログ・エントリのタイムスタンプ: 2020-10-12 21:12:06

ログ・ファイルの最終変更時間: 2021-03-31 08:00:00

この問題への直接リンク: zipファイルを使用したWindowsマシンからのオンデマンド・アップロード

詳細: 10,000を超えるファイルを含むフォルダでは、管理エージェントによるリソース(メモリー/ストレージ/CPU)の使用率が高くなる可能性があります。これにより、ログ収集が遅くなり、管理エージェントの他の機能に影響し、ホスト・マシンの速度が低下する可能性があります。

管理エージェント・ログ・アナリティクス・プラグインで大きなフォルダが検出されると、次の例のようなメッセージが管理エージェントmgmt_agent_logan.logファイルに追加されます:

2020-07-30 14:46:51,653 [LOG.Executor.2388 (LA_TASK_os_file)-61850] INFO - ignore large dir /u01/service/database/logs. set property loganalytics.enable_large_dir to enable. 

解決策: 大きなフォルダは避けることをお薦めします。クリーン・アップ・メカニズムを使用して、ファイルが収集された直後にファイルを削除し、管理エージェントがファイルを再度収集するのに十分な時間を持つようにします。

ただし、大きなフォルダのログのモニタリングを続行する場合は、次のアクションを実行してサポートを有効にできます:

sudo -u mgmt_agent echo "loganalytics.enable_large_dir=true" >> INSTALL_DIRECTORY/agent_inst/config/emd.properties

INSTALL_DIRECTORYをagent_instフォルダのパスに置き換え、エージェントを再起動します。

この問題への直接リンク:大きいフォルダのログをモニターする場合の特別な処理