既知の問題
次のリストに、Oracle Cloud Infrastructureの既知の問題を示します。
お知らせ
現在、お知らせの既知の問題はありません。
異常検出 🔗
現在、異常検出サービスに既知の問題はありません。
APIゲートウェイ 🔗
APIゲートウェイの既知の問題は、APIゲートウェイの既知の問題を参照してください。
Application Performance Monitoring 🔗
詳細: 合成モニタリングでは、ブラウザおよびスクリプト化ブラウザ・モニターで、フレームを使用するアプリケーションの実行に失敗することがあります。
回避策: 問題を認識しており、解決に取り組んでいます。スクリプト化ブラウザ・モニターの場合、.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": ""
}
この問題への直接リンク: ブラウザおよびスクリプト化ブラウザ・モニターで、フレームを使用するアプリケーションが実行されない場合がある
アーティファクト・レジストリ 🔗
アーティファクト・レジストリの既知の問題は、既知の問題を参照してください。
監査 🔗
現在、監査の既知の問題はありません。
Automated CEMLI Execution 🔗
Automated CEMLI Executionの既知の問題は、既知の問題を参照してください。
Autonomous Linux 🔗
Autonomous Linuxの既知の問題は、既知の問題を参照してください。
要塞 🔗
要塞の既知の問題は、既知の問題を参照してください。
ビッグ・データ 🔗
ビッグ・データ・サービスの既知の問題は、既知の問題を参照してください。
請求およびコストの管理 🔗
請求およびコストの管理の既知の問題は、請求およびコストの管理の既知の問題を参照してください。
ブロック・ボリューム 🔗
詳細: ボールト暗号化キーを使用するよう構成されたボリュームのリージョン間レプリケーションを有効化しようとすると、次のエラー・メッセージが表示されます: ボリュームの編集エラー: ボリューム<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です
ブロックチェーン・プラットフォーム 🔗
ブロックチェーン・プラットフォームの既知の問題は、既知の問題を参照してください。
証明書 🔗
証明書の既知の問題は、既知の問題を参照してください。
クラウド・ガード 🔗
クラウド・ガードの既知の問題は、クラウド・ガードの既知の問題を参照してください。
クラウド・シェル 🔗
Cloud Shellの既知の問題は、Cloud Shellの既知の問題を参照してください。
クラスタ配置グループ 🔗
クラスタ配置グループの既知の問題は、既知の問題を参照してください。
コンパートメントの割当て 🔗
コンパートメント割当て制限の既知の問題は、コンパートメント割当て制限の既知の問題を参照してください。
コンプライアンス・ドキュメント 🔗
コンプライアンス・ドキュメントの既知の問題については、コンプライアンス・ドキュメントの既知の問題を参照してください。
コンピュート 🔗
コンピュートの既知の問題は、コンピュートの既知の問題を参照してください。
Compute Cloud@Customer 🔗
Compute Cloud@Customerの既知の問題は、既知の問題を参照してください。
コネクタ・ハブ 🔗
コネクタ・ハブの既知の問題は、コネクタ・ハブの既知の問題を参照してください。
コンソール 🔗
詳細: Firefoxを使用してコンソールにアクセスしようとした場合、コンソール・ページがブラウザにロードされません。この問題は、Firefoxユーザー・プロファイルの破損が原因であると考えられます。
回避策: 新しいFirefoxユーザー・プロファイルを次のように作成します:
- Firefoxの最新バージョンを使用していることを確認します。そうでない場合、最新バージョンに更新します。
- 新しいユーザー・プロファイルを作成し、古いユーザー・プロファイルを削除します。ユーザー・プロファイルを作成および削除する手順は、Mozillaサポートを参照してください: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles。
- 新しいプロファイルでFirefoxを開きます。
または、他のサポートされているブラウザのいずれかを使用できます。
この問題への直接リンク: Firefoxブラウザのバグにより、コンソールがロードされない場合があります
コンソール・ダッシュボード 🔗
コンソール・ダッシュボードの既知の問題は、コンソール・ダッシュボードの既知の問題を参照してください。
コンテナ・インスタンス 🔗
コンテナ・インスタンスの既知の問題については、コンテナ・インスタンスの既知の問題を参照してください。
コンテナ・レジストリ 🔗
コンテナ・レジストリの既知の問題は、既知の問題を参照してください。
データ・カタログ 🔗
データ・カタログの既知の問題は、既知の問題を参照してください。
データ・フロー 🔗
データ・フローの既知の問題は、既知の問題を参照してください。
データ統合 🔗
データ統合の既知の問題は、既知の問題を参照してください。
データ・ラベリング 🔗
データ・ラベリングの既知の問題は、既知の問題を参照してください。
データ・サイエンス 🔗
現在、データ・サイエンス・サービスに既知の問題はありません。
Data Transfer 🔗
現在、データ転送の既知の問題はありません。
データベース 🔗
詳細: 新しく作成されたデータベースに既存の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)を適用し、操作を再試行してください
--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リリース1 (12.1.0.2)で顧客管理キーベースのTDEウォレットをファイルベースのTDEウォレットに移行すると、次のエラーで失敗します:
[FATAL] [DBAAS-11014] - 必要なパッチ(30128047)がOracleホーム<ORACLE_HOME>に存在しません。
処置: 必要なパッチ(30128047)を適用し、操作を再試行してください
--skip_patch_check true
フラグとともに使用して、バグ30128047のパッチの検証をスキップします。Oracleホームでバグ29667994のパッチが適用されていることを確認してから、次のdbaascli
コマンドを実行します: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ウォレットに移行します:
- 次のように、データベースでいずれかの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表領域がある場合は、次のステップに進みます。
- 次のように、UNDO表領域またはTEMP表領域を暗号化解除します:
UNDO表領域が暗号化されている場合
次のように、既存のUNDO表領域を暗号化解除します:SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;
暗号化されたすべてのUNDO表領域に対して、この手順を繰り返します。
TEMP表領域が暗号化されている場合- 次のように、デフォルトの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表領域を作成および設定します。
- 次のように、
encrypt_new_tablespaces
パラメータをDDLに設定します:SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;
- 次のように、現在のTEMP表領域の仕様でTEMP表領域を作成します:
SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;
- 次のように、新しいTEMP表領域をデータベースのデフォルトのTEMP表領域として設定します:
SQL> alter database default temporary tablespace <temp_tablespace_name>;
- 次のように、既存のTEMP表領域を削除します:
SQL> drop tablespace <temp_tablespace_name>;
暗号化されたすべてのTEMP表領域に対して、この手順を繰り返します。
データベースは、暗号化されていないデフォルトのUNDO表領域およびTEMP表領域で実行され、古いTEMP表領域およびUNDO表領域も復号化されます。
次のように、encrypt_new_tablespaces
を元の値に設定します:SQL> alter system set "encrypt_new_tablespaces" = cloud_only;
顧客管理キーへのキーストアの移行に進みます。
- 次のように、デフォルトのTEMP表領域を確認します:
- いずれのプラガブル・データベースにも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ウォレットに移行します:
- 次のように、データベースでいずれかの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表領域がある場合は、次のステップに進みます。
- 次のように、UNDO表領域またはTEMP表領域を暗号化解除します:
UNDO表領域が暗号化されている場合
次のように、既存のUNDO表領域を暗号化解除します:SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;
暗号化されたすべてのUNDO表領域に対して、この手順を繰り返します。
TEMP表領域が暗号化されている場合- 次のように、デフォルトの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表領域を作成および設定します。
- 次のように、
encrypt_new_tablespaces
パラメータをDDLに設定します:SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;
- 次のように、現在のTEMP表領域の仕様でTEMP表領域を作成します:
SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;
- 次のように、新しいTEMP表領域をデータベースのデフォルトのTEMP表領域として設定します:
SQL> alter database default temporary tablespace <temp_tablespace_name>;
- 次のように、既存のTEMP表領域を削除します:
SQL> drop tablespace <temp_tablespace_name>;
暗号化されたすべてのTEMP表領域に対して、この手順を繰り返します。
データベースは、暗号化されていないデフォルトのUNDO表領域およびTEMP表領域で実行され、古いTEMP表領域およびUNDO表領域も復号化されます。
次のように、encrypt_new_tablespaces
を元の値に設定します:SQL> alter system set "encrypt_new_tablespaces" = cloud_only;
顧客管理キーへのキーストアの移行に進みます。
- 次のように、デフォルトのTEMP表領域を確認します:
- いずれのプラガブル・データベースにも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>サービスというサービス・ゲートウェイの概要を使用すると、サービス・ゲートウェイによりOracle YUMリポジトリへのアクセスが可能になります。ただし、サービス・ゲートウェイを介してYUMサービスにアクセスする場合は引き続き問題が発生する可能性があります。この問題には解決策があります。詳細は、サービス・ゲートウェイを介してインスタンスがOracle yumサービスにアクセスする際の問題を参照してください。
この問題への直接リンク: サービス・ゲートウェイでは、現在OSの更新がサポートされていません
ベア・メタルおよび仮想マシンのDBシステムのみ
詳細: データベース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のバックアップ・ログ・ファイルで前述のエラーを確認します:
-
失敗したバックアップ・ジョブの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
-
失敗したジョブの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モジュールを更新します:
-
データベースがバックアップに使用するSwiftのオブジェクト・ストアIDおよびユーザーを確認します。
-
dbcli list-databases
コマンドを実行して、データベースのIDを確認します。 -
データベースIDを使用して、バックアップ構成ID (
backupConfigId
)を確認します。dbcli list-databases dbcli describe-database -i <database_ID> -j
-
前のステップでメモしたバックアップ構成IDを使用して、オブジェクト・ストアID (
objectStoreId
)を確認します。dbcli list-backupconfigs dbcli describe-backupconfig –i <backupconfig_ID> -j
-
前のステップでメモしたオブジェクト・ストアIDを使用して、オブジェクト・ストア・ユーザー(
userName
)を確認します。dbcli list-objectstoreswifts dbcli describe-objectstoreswift –i <objectstore_ID> -j
-
-
ステップ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のデータベース・エディション属性の重大な変更が導入されています。
回避策: 重大な変更の詳細は、次の言語固有のドキュメントを参照し、該当する場合は既存のコードを更新してください:
言語 | バージョン | ドキュメント |
---|---|---|
Java | 1.2.49 | https://github.com/oracle/oci-java-sdk/releases |
Python | 2.0.6 | https://github.com/oracle/oci-python-sdk/releases |
Ruby | 2.3.9 | https://github.com/oracle/oci-ruby-sdk/releases |
Go | 2.7.0 | https://github.com/oracle/oci-go-sdk/releases |
この問題への直接リンク: データベース・サービスSDKの重大な変更
詳細: コンソールまたはAPIを使用しているときに、バックアップおよびリストア操作がDBシステムで機能しない可能性があります。
回避策: Oracle Database Cloud Backupモジュールをインストールしてから、Oracle Support Servicesに連絡して詳細な指示を確認します。
Oracle Database Cloud Backupモジュールをインストールするには:
-
DBシステムにSSHで接続し、opcとしてログインします。
ssh -i <SSH_key> opc@<DB_system_IP address> login as: opc
または、opc @<DB_system_hostname>を使用してログインします。
- http://www.oracle.com/technetwork/database/availability/oracle-cloud-backup-2162729.htmlからOracle Database Cloud Backupモジュールをダウンロードします。
- opc_installer.zipの内容をターゲット・ディレクトリ(例: /home/opc)に抽出します。
- テナンシで、一時ユーザーを作成し、テナンシのオブジェクト・ストレージにアクセスする権限を付与します。
- この一時ユーザーの場合は、「認証トークンの作業」を作成し、パスワードをノートにとります。
-
次のcurlコマンドを実行して、資格証明が機能することを確認します:
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のいずれかの成功ステータス・レスポンス・コードが返される必要があります。その他のステータス・コードは、オブジェクト・ストレージへの接続中に問題が発生したことを示します。
-
次のコマンドを実行します。
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など)が表示されます。
-
ディレクトリをターゲット・ディレクトリに変更して、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を使用することが必要な場合があります。)
-
次のコマンドを実行して、指定したディレクトリが存在するかどうかを確認します:
ls /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
このディレクトリが存在する場合は、次のステップを実行します:
/opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
ディレクトリにファイルをバックアップします。-
次の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
-
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.
- (オプション)一時ユーザーと、バックアップ・モジュールのインストールに使用したターゲット・ディレクトリを削除します。
手順が完了したら、Oracle Supportまたはテナント管理者に連絡して詳細な指示を確認してください。バックアップを有効にするDBシステムのOCIDを指定する必要があります。
この問題への直接リンク: DBシステムで管理対象バックアップを使用できません
詳細: VM.Standard1.1シェイプを実行しているホスト・マシンのメモリー制限によって、Oracle Cloud Infrastructureで管理される自動データベース・バックアップ・ジョブ(コンソールまたはAPIのいずれかを使用して管理されるジョブ)に障害が発生することがあります。システムのメモリー・パラメータを変更して、この問題を解決できます。
回避策: システムのメモリー・パラメータを次のように変更します:
-
オペレーティング・システムのoracleユーザーに切り替えます。
[opc@hostname ~]$ sudo su - oracle
-
データベース・インスタンスにログインするように環境変数を設定します。例:
[oracle@hostname ~]$ . oraenv ORACLE_SID = [oracle] ? orcl
-
SQL*Plusを起動します。
[oracle@hostname ~]$ sqlplus / as sysdba
-
初期メモリー・パラメータを次のように変更します:
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
-
データベース・インスタンスを再起動します。
[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_HOME/OPatch/opatch lspatches
をoracleユーザーとして実行するか、dbcli list-dbhomes
をrootユーザーとして実行します。
この問題への直接リンク: Oracle Data Pumpの操作で「ORA-00439: 機能は有効ではありません」が返されます
詳細: 適切な権限が自動的に適用されなかったため、1ノードのDBシステムからEM Expressコンソールに接続しようとすると、「セキュアな接続が失敗しました。」というエラー・メッセージが表示される場合があります。
回避策: DBシステムのウォレット・ディレクトリに対するasmadminグループの読取り権限を追加してから、接続を再試行します:
-
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
-
次のコマンド出力に赤色で示されているウォレット・ディレクトリの場所を確認します。
[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))
-
opcユーザーに戻り、oracleユーザーに切り替えて、ウォレット・ディレクトリに変更します。
[opc@dbsysHost ~]$ sudo su - oracle [oracle@dbsysHost ~]$ cd /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet
-
ディレクトリの内容をリストし、権限をメモします。
[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
-
権限を変更します:
[oracle@dbsysHost xdb_wallet]$ chmod 640 /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet/*
-
読取り権限が追加されたことを確認します。
[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 DBシステムのみ
詳細: 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モジュールが古い証明書をまだ参照していると、オブジェクト・ストレージへのバックアップが失敗する可能性があります。
この項の適切な回避策を使用する前に、Exadata Cloud Serviceインスタンスでのツールの更新のステップに従って、
dbaastools_exa
の最新バージョンがシステムにインストールされていることを確認します。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バンドルを適用します。
-
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.
-
投票ディスクの破損が原因で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
-
SQL*Plusを使用して、投票ディスクが破損していることを確認することもできます:
-
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
-
SYSASM
としてSQL*Plusにログインします。$ORACLE_HOME/bin/sqlplus / as sysasm
-
次の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つ以上の投票ディスクが破損しています。
-
-
投票ディスクが破損している場合は、投票ディスクを含むグリッド・ディスクをオフラインにします。セルは、不良投票ディスクを他のグリッド・ディスクに自動的に移動し、その投票ディスクをオンラインにします。
-
次のコマンドで、
DATAC01_CD_05_SCAQAE08CELADM13
というグリッド・ディスクをオフラインにします。SQL> alter diskgroup DATAC01 offline disk DATAC01_CD_05_SCAQAE08CELADM13; Diskgroup altered.
-
30秒待機してからステップ3cの2つの問合せを再実行し、投票ディスクが新しいグリッド・ディスクに移行され、正常であることを確認します。
-
オフラインにしたグリッド・ディスクがオンラインになったことを確認します:
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
-
-
バンドル・パッチなしの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エージェントをインストールするには:
- rootとしてノードにログオンします。
-
次のコマンドを実行して、エージェントをインストールします:
[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
-
エージェントがインストールされ、実行されていることを確認します。
[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
- 残りのノードでステップ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で必要な一時ファイルが削除されたため、様々なデータベース・ワークフロー障害が発生します
通常のデータ・ストレージまたはリカバリ領域(RECO)ストレージを10,240GB (10TB)未満の値から10,240GBを超える値にスケーリングする場合は、2つの操作でスケーリングを実行します。最初に、システムを10,240GBにスケーリングします。この最初のスケーリング操作が完了し、システムが"使用可能"状態になったら、2番目のスケーリング操作を実行して、10,240GBを超えるターゲット・ストレージ値を指定します。1回の操作で10,240GB未満の値から10,240GBを超える値までスケーリングしようとすると、スケーリング操作に失敗する可能性があります。スケーリングの手順については、仮想マシンDBシステムのストレージのスケール・アップを参照してください。
詳細: より大きなシステム・シェイプを使用するように仮想マシンDBシステムをスケーリングする場合、DB_Cache_nX
パラメータが0 (ゼロ)に設定されていないと、スケーリング操作が失敗します。
回避策: 仮想DBシステムをスケーリングする場合は、すべてのDB_Cache_nX
パラメータ(DB_nK_CACHE_SIZE
など)が0に設定されていることを確認します。
Database Migration 🔗
データベース移行に関する既知の問題については、データベース移行の既知の問題を参照してください。
OCI Database with PostgreSQL 🔗
PostgreSQLを使用したOCIデータベースの既知の問題は、PostgreSQLの既知の問題があるOCIデータベースを参照してください。
開発者ツール 🔗
開発者ツールの既知の問題については、開発者ツールの既知の問題を参照してください。
DNS 🔗
現在、DNSの既知の問題はありません。
Document Understanding 🔗
ドキュメントの理解の既知の問題は、既知の問題を参照してください。
電子メール配信 🔗
既知の問題は、電子メール配信の既知の問題を参照してください。
イベント 🔗
現在、イベントの既知の問題はありません。
ファイル・ストレージ 🔗
ファイル・ストレージの既知の問題については、ファイル・ストレージの既知の問題を参照してください。
フリート・アプリケーション管理 🔗
フリート・アプリケーション管理の既知の問題は、フリート・アプリケーション管理の既知の問題を参照してください。
フル・スタック・ディザスタ・リカバリ 🔗
詳細: 同じリージョン内の別々のADでコンピュートおよびストレージのDR操作を実行するときにボリューム・グループ・バックアップを使用する場合、DR移行を行き来すると、コンピュートおよび関連するブロック・ストレージ(ボリューム・グループ・バックアップを使用)が毎回違うADにアクセスする原因となります。
回避策: この問題は、ボリューム・グループ・レプリケーションを使用してレプリケートされたブロック・ストレージには影響しません。
詳細: ブロック・ストレージ・ボリュームのパフォーマンスの自動チューニング設定が、DR操作中に継承されません。
回避策: パフォーマンスの自動チューニングが有効になっているブロック・ストレージ・ボリュームでは、Full Stack DRにより、これらのブロック・ストレージ・ボリュームが別のリージョンに移行された後に、設定を再度有効にする必要があります。
詳細: フル・スタックDRで保護されたリソースの変更直後にフェイルオーバー操作を実行した場合、リソースのリカバリが失敗するか、リソースが正しくリカバリされない可能性があります。たとえば、DR保護グループに追加したボリューム・グループのレプリケーション・ターゲットまたはその他のプロパティを変更し、その後すぐにプライマリ・リージョンが停止した場合、Full Stack DRはボリューム・グループのレプリケーション設定の変更を検出できず、そのボリューム・グループのリカバリに影響を与えます。
回避策: DR保護下のリソースに変更を加えた直後に、スイッチオーバー事前チェックを実行します。
詳細: Full Stack DRでは、Oracle Cloud Agent (OCA)のコマンドの実行ユーティリティを使用してインスタンスでローカル・スクリプトが実行されます。Microsoft Windowsインスタンスでローカル・スクリプトを実行するようにユーザー定義ステップを構成する場合は、フル・スタックDRの「実行ユーザー」機能を使用して別のuseridを指定し、インスタンスに存在するローカル・スクリプトを実行できます。
回避策: Microsoft Windowsインスタンスでスクリプトを実行できるのは、Oracle Cloud Agentのコマンドの実行ユーティリティで使用されるデフォルトのocarunユーザーIDのみです。この制限は、Oracle Linuxインスタンスには影響しません。
詳細: Full Stack DRでは、Oracle Cloud Agent (OCA)のコマンドの実行ユーティリティを使用してインスタンスでローカル・スクリプトが実行されます。デフォルトでは、これらのスクリプトは、ocarunユーザーとして実行されます。
回避策: Microsoft Windowsインスタンスでは、DR計画でユーザー定義ステップとして実行するよう構成されたローカル・スクリプトは、このocarunユーザーIDでアクセスして実行できる必要があります。
詳細: DR計画のユーザー定義ステップを使用してローカル・スクリプトを実行する場合、スクリプト・インタプリタまたはスクリプトへのフル・パスを指定しないと、フル・スタックDRでエラーがスローされます。
回避策: DR計画で、インスタンスに存在するローカル・スクリプトを実行するようユーザー定義ステップを構成する際は、スクリプト名の前に付いているインタプリタへのフル・パスと、スクリプトへのフル・パスを必ず指定してください。
sh myscript.sh arg1 arg2
ではなく、/bin/sh /path/to/myscript.sh arg1 arg2
と指定します
詳細: 宛先サブネットのCIDRブロックがソース・サブネットのCIDRブロックと一致し、インスタンスの元のプライベートIPがまだ割り当てられていない場合、フル・スタックDRでは、DR操作中に、インスタンスに割り当てられた元のプライベートIPの再割当てが試行されます。
フル・スタックDRを使用してOCFS2クラスタ内のすべてのノードを再配置し、どのクラスタ・ノードのプライベートIPも再割当てできない場合、スタンバイ・リージョンでそのノードが起動されると、OCFS2クラスタからそれらのクラスタ・ノードがデタッチされます。
回避策: 宛先サブネットのCIDRブロックとソース・サブネットのCIDRブロックが一致し、クラスタ・ノードに必要なすべてのプライベートIPアドレスが宛先サブネットで使用可能であることを確認してください。
詳細: フル・スタックDRがインスタンスを別のリージョンに再配置した後、インスタンス・アクセスに関して、インスタンスのリソース・ページに次のメッセージが表示される場合があります:
このイメージを使用するインスタンスへの接続方法が不明です
回避策: このメッセージは無視します。元のSSHキーファイルを使用してインスタンスに接続し、認証を行うと、インスタンスへのSSH接続が正常に機能します。
詳細: Full Stack DRがインスタンスを別のリージョンに再配置した後、ブート・ボリュームのイメージの部分についてインスタンスのリソース・ページに正しくない情報が表示されます。
たとえば、「イメージ情報」列に、「データのロード中にエラーが発生しました」というメッセージが表示される場合があります
回避策: このエラー・メッセージはイメージ名の表示用ですが、インスタンスまたはそのブート・ボリュームの操作には影響しません。
詳細: nohup
コマンドのスリープ時間がない場合、run
コマンドは実行に失敗し、ステータスを正常にレポートできません。
sleep
を追加します。nohup sh enabler.sh &> enabler.log &
sleep 10
exit 0
詳細: DR移行中、ブロック・ボリュームを別のリージョンに移動しても、パフォーマンス設定(IOPSおよびスループット)はレプリケートされず、自動的にリストアされません。これらのパフォーマンス設定の再構成が必要になる場合があります。
回避方法: DR計画を実行したあと、パフォーマンス設定を手動で構成します。
ファンクション 🔗
ファンクションの既知の問題は、OCIファンクションの既知の問題を参照してください。
グローバルに分散した自律型データベース 🔗
Globally Distributed Autonomous Databaseの既知の問題は、既知の問題を参照してください。
GoldenGate 🔗
ヘルス・チェック 🔗
ヘルス・チェックの既知の問題は、ヘルス・チェックの既知の問題を参照してください。
IAM 🔗
アイデンティティ・ドメインの問題があるIAMは、アイデンティティ・ドメインを使用したIAMの既知の問題を参照してください。
アイデンティティ・ドメインの問題がないIAMは、アイデンティティ・ドメインを使用しないIAMの既知の問題を参照してください。
統合 🔗
Java管理 🔗
Java管理サービスの既知の問題の詳細は、既知の問題を参照してください。
Kubernetes Engine 🔗
Kubernetes Engineの既知の問題は、Kubernetes Engine (OKE)の既知の問題を参照してください。
言語 🔗
現在、言語サービスに既知の問題はありません。
ロード・バランサ 🔗
ロード・バランサ・サービスの既知の問題は、既知の問題を参照してください。
ログ 🔗
ロギングの既知の問題は、ロギングの既知の問題を参照してください。
ログ・アナリティクス 🔗
詳細: 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
フォルダのパスに置き換え、エージェントを再起動します。
- 管理エージェントのヒープ・サイズを増やします。ファイル数が多いディレクトリの場合、必要なヒープ・サイズはファイル数とともに増加します。管理エージェントのドキュメントを参照してください。
- 管理エージェントが保持する必要がある多数の状態ファイルの処理に十分なディスク領域およびiノードが使用可能であることを確認します。これは、使用されるログ・ソースおよびパーサーのタイプによって異なります。パーサーがヘッダー詳細関数を使用する場合、元のログ・ファイルが存在するかぎり、エージェントはヘッダーを作成してキャッシュ・ファイルに格納します。
- 開いているファイルの数のオペレーティング・システム設定で、大きいフォルダおよび多数の状態ファイルの読取りを管理エージェントがサポートできることを確認します。
この問題への直接リンク:大きいフォルダのログをモニターする場合の特別な処理
管理対象アクセス 🔗
管理対象アクセスの既知の問題は、既知の問題を参照してください。
Managed Cloud Self Serviceプラットフォーム 🔗
Managed Cloud Self Serviceプラットフォームの既知の問題は、既知の問題を参照してください。
Management Agent 🔗
現在、管理エージェントの既知の問題はありません。
マーケットプレイス 🔗
マーケットプレイスの既知の問題は、既知の問題を参照してください。
メディア・サービス 🔗
モニタリング 🔗
モニタリングの既知の問題は、モニタリングの既知の問題を参照してください。
ネットワーク・ロード・バランサ 🔗
ネットワーク・ロード・バランサの既知の問題は、既知の問題を参照してください。
ネットワーキング 🔗
ネットワーキングの既知の問題は、ネットワーキングの既知の問題を参照してください。
通知 🔗
通知の既知の問題は、通知の既知の問題を参照してください。
オブジェクト・ストレージ 🔗
オブジェクト・ストレージの既知の問題は、オブジェクト・ストレージの既知の問題を参照してください。
OCIコントロール・センター 🔗
OCIコントロール・センターの既知の問題は、既知の問題を参照してください。
Opsインサイト 🔗
現在、Opsインサイトの既知の問題はありません。
OS管理 🔗
OS管理サービスの既知の問題の詳細は、OS管理の既知の問題を参照してください。
OS管理ハブ 🔗
OS管理ハブの既知の問題は、既知の問題を参照してください。
プロセス自動化 🔗
プロセス自動化サービスの既知の問題の詳細は、既知の問題を参照してください。
キューに入れる 🔗
現在、キューの既知の問題はありません。
リソース・マネージャ 🔗
リソース・マネージャの既知の問題については、リソース・マネージャの既知の問題を参照してください。
Roving Edge Infrastructure 🔗
現在、Roving Edge Infrastructureの既知の問題はありません。
セキュア・デスクトップ 🔗
セキュア・デスクトップの既知の問題は、既知の問題を参照してください。
検索 🔗
検索の既知の問題は、既知の問題を参照してください。
OpenSearchを使用した検索 🔗
OpenSearchを使用した検索の既知の問題は、既知の問題を参照してください。
セキュリティ・ゾーン 🔗
セキュリティ・ゾーンの既知の問題は、既知の問題を参照してください。
サービス・メッシュ 🔗
サービス・メッシュの既知の問題は、既知の問題を参照してください。
サービス・カタログ 🔗
サービス・カタログの既知の問題は、既知の問題を参照してください。
音声 🔗
現在、音声サービスに既知の問題はありません。
ストリーム 🔗
ストリーミングの既知の問題は、ストリーミングの既知の問題を参照してください。
タグ付け 🔗
タグ付けの既知の問題は、タグ付けの既知の問題を参照してください
テナンシ管理 🔗
テナンシ管理の既知の問題は、既知の問題を参照してください。
脅威インテリジェンス 🔗
脅威インテリジェンスの既知の問題は、既知の問題を参照してください。
トラフィック管理 🔗
現在、トラフィック管理の既知の問題はありません。
ボールト 🔗
現在、ボールト・サービスの既知の問題はありません。
ビジョン 🔗
ビジョンの既知の問題は、既知の問題を参照してください。
Visual Builder 🔗
Visual Builderに関する既知の問題は、Oracle Visual Builderの既知の問題を参照してください。
Visual Builder Studio 🔗
Visual Builder Studioの既知の問題は、Oracle Visual Builder Studioの既知の問題を参照してください。
Webアプリケーション・ファイアウォール(WAF) 🔗
Webアプリケーション・ファイアウォールの既知の問題は、Webアプリケーション・ファイアウォール - 既知の問題を参照してください。
Webアプリケーション・アクセラレーション 🔗
Webアプリケーション・アクセラレーションの既知の問題は、既知の問題を参照してください。
Zero Trust Packet Routing 🔗
ゼロ・トラスト・パケット・ルーティングの既知の問題は、既知の問題を参照してください。