既知の問題

次のリストに、Oracle Cloud Infrastructureの既知の問題を示します。

お知らせ

現在、お知らせの既知の問題はありません。

APIゲートウェイ

APIゲートウェイがサブネットからカスタムDNSサーバーを継承しない

詳細: デフォルトのOracle Cloud Infrastructureリゾルバは、パブリックURLエンドポイント(およびパブリック・ホスト名を持つURLエンドポイント)をIPアドレスに解決します。さらに、サブネットは、内部ホスト名(およびプライベート・ホスト名)のURLエンドポイントをIPアドレスに解決するカスタムDNSサーバーを使用して構成できます。ただし、APIゲートウェイ・サービスで作成するAPIゲートウェイは、サブネットからカスタムDNSサーバーを継承しません。かわりに、APIゲートウェイでは、内部/プライベート・ホスト名URLエンドポイントを解決しないデフォルトのOracle Cloud Infrastructureリゾルバが使用されます。

この制限により、HTTPまたはHTTPS URLバック・エンドとして内部/プライベート・ホスト名URLエンドポイントを持つAPIゲートウェイを作成すると、ホスト名をIPアドレスに解決できないため、APIへのコールは失敗します。

回避策: 問題を認識しており、解決に取り組んでいます。当面は、HTTPまたはHTTPS URLバック・エンドとして内部/プライベートURLエンドポイントを持つAPIゲートウェイを作成する場合に、ホスト名ではなく、URLでホストのIPアドレスを指定する必要があります。また、バック・エンドがHTTPS URLの場合は、コンソールで「SSL検証の無効化」オプションを選択する(またはAPIデプロイメント仕様のJSONファイルにisSSLVerifyDisabled: trueを含める)必要があります。

この問題への直接リンク: APIゲートウェイがサブネットからカスタムDNSサーバーを継承しない

アプリケーションの移行

長い名前を持つOracle Java Cloud Serviceアプリケーションの移行が失敗する

詳細: アプリケーションの移行では、名前が28文字を超えるOracle Java Cloud Serviceアプリケーションの移行はサポートされていません。

回避策: 問題を認識しており、解決に取り組んでいます。Oracle Java Cloud Serviceアプリケーションの移行を開始する前に、名前が28文字未満になるようにアプリケーションの名前を変更します。

この問題への直接リンク: 長い名前を持つOracle Java Cloud Serviceアプリケーションの移行が失敗する

Oracle Analytics Cloud - Classicアプリケーションでサポートされていない属性

詳細: APIまたはCLIを使用してOracle Analytics Cloud - Classicアプリケーションの移行を作成する場合は、serviceInstanceUser属性およびserviceInstancePassword属性の値を指定する必要があります。ただし、アプリケーションの移行ではこれらの値が無視されます。

回避策: 問題を認識しており、解決に取り組んでいます。これらの属性には、「未使用」などの任意の値を入力できます。

この問題への直接リンク: Oracle Analytics Cloud - Classicアプリケーションでサポートされていない属性

listSourceApplicationsコマンドでサポートされていない問合せパラメータ

詳細: listSourceApplicationsコマンドでは、limitpagesortOrderおよびsortBy問合せパラメータはサポートされません。

回避策: 問題を認識しており、解決に取り組んでいます。これらの問合せパラメータを使用して検索結果をフィルタしないでください。

この問題への直接リンク: listSourceApplications操作でサポートされていない問合せパラメータ

listMigrationsコマンドでサポートされていない問合せパラメータ

詳細: listMigrationsコマンドでは、lifecycleState問合せパラメータはサポートされません。

回避策: 問題を認識しており、解決に取り組んでいます。この問合せパラメータを使用して検索結果をフィルタしないでください。

この問題への直接リンク: listMigrationsコマンドでサポートされていない問合せパラメータ

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": ""
    }

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

apm-domainsリソース・タグに基づく認可ポリシーに関する問題

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

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

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

監査

現在、監査の既知の問題はありません。

Bastion

Ubuntuインスタンスの管理対象SSHセッションが失敗します

詳細:コンピュート・インスタンスの管理対象SSHセッションを作成するには、Bastionプラグインを有効にして実行する必要があります。このプラグインは、Oracle Cloud Agentバージョン1.11以上で使用できます。Ubuntuインスタンスで1.11より古いバージョンが実行されている場合、管理対象SSHセッションの作成は失敗します。

回避策:

管理対象SSHセッションをサポートするように既存のUbuntuコンピュート・インスタンスを更新するには:

  1. NATゲートウェイを、インスタンスを作成したVCN (仮想クラウド・ネットワーク)に追加します(まだ存在しない場合)。  NATゲートウェイの設定を参照してください
  2. 要塞から、インスタンスのSSHポート(デフォルトでは22)へのポート転送セッション(SSHトンネル)を作成します。「セッションの管理」を参照してください。
  3. ポート転送セッションを使用してインスタンスに接続します。セッションへの接続を参照してください。
  4. 最新のOracle Cloudエージェントをインストールするには、インスタンスで次のコマンドを実行します。
    sudo snap refresh oracle-cloud-agent

    詳細は、Oracle Cloud Agentソフトウェアのインストールを参照してください。

  5. インスタンスでBastionプラグインを有効にします。Managing Plugins Using the Consoleを参照してください。
  6. 要塞から、インスタンスへの管理対象SSHセッションを作成します。

別のUbuntuインスタンスを作成する場合、別の回避策として、インスタンスの起動時にcloud-initスクリプトを指定します。このスクリプトでは、同じコマンドを使用して最新のOracle Cloudエージェントをインストールします。

sudo snap refresh oracle-cloud-agent

cloud-initスクリプトの詳細は、Oracle Cloudエージェント・ソフトウェアのインストールを参照してください

この問題への直接リンク: Ubuntuインスタンスの管理対象SSHセッションが失敗します

管理対象SSHセッションは、Oracle Linuxを実行している場合にのみArmインスタンスでサポートされます。

詳細:管理対象SSHセッションは、次の条件をすべて満たすコンピュート・インスタンスではサポートされていません:

  • ArmベースAmpere A1 Computeシェイプを使用して作成されます。
  • UbuntuなどのOracle Linux以外のオペレーティング・システムの実行。

管理対象SSHセッションを作成するには、Bastionプラグインを有効にして実行する必要があります。このプラグインは一部のArmベースのインスタンスで正しく有効になっていないため、セッションの作成は失敗します。

回避策: ポート転送セッションを作成して、Ampere A1 Computeシェイプを使用し、Oracle Linuxを実行していないインスタンスに接続します。

この問題への直接リンク: 管理対象SSHセッションは、Oracle Linuxを実行している場合にのみArmインスタンスでサポートされます

Big Data

Apache Ambariでワイルドカード文字を指定する場合、ハイブ・データベース・タスクの同期に失敗しました

詳細: Apache Hadoopを含むOracle Distributionを使用したビッグ・データ・クラスタで、Apache Ambariを使用してSynchronize Hive Databasesプロパティにワイルドカード文字*を指定してハイブ・データベースを同期すると、Hiveメタデータの同期が失敗したことを示すエラーが表示されます。

回避策:問題を認識しており、解決作業中です。一方、Synchronize Hive Databasesプロパティにはワイルドカード文字*を使用しないでくださいが、カンマ区切りの空白リストとして同期化するHiveデータベースを明示的に指定します。例: db1、db2

この問題への直接リンク: Apache Ambariでワイルドカード文字を指定すると、データベースの同期タスクが失敗します

請求

統合請求を使用してテナンシをリンクした後、予算アラートはトリガーされません

詳細: 統合請求を使用してテナンシがリンクされた後に、予算に関する既知の問題があります。受信者がUnified Billingからの招待を受け入れると、リンクされたテナンシが予算アラートしきい値を超えていても、その予算アラートはトリガーされません。

回避策:予想される予算アラートを取得できない可能性があるため、コスト分析を使用してコストをモニターする必要があります。

この問題への直接リンク: 統合請求を使用してテナンシがリンクされた後に予算アラートはトリガーされません

ブロック・ボリューム

ブロック・ボリュームの最大数を小さいVM.Standard.A1.Flexインスタンスにアタッチすると、失敗する可能性があります。

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

回避策: 問題を認識しており、解決に取り組んでいます。回避策として、VMのサイズを変更してVMのサイズを増やしてから、ボリュームのアタッチを再試行することをお薦めします。

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

Python SDKコンポジット操作では、操作が成功した場合でも404 NotAuthorizedOrNotFoundエラーがスローされます。

詳細: BlockStorageクライアント・コンポジット操作のcopy_boot_volume_backup_and_wait_for_stateおよびcopy_volume_backup_and_wait_for_stateは、あるリージョンから別のリージョンにバックアップをコピーするときに404 /NotAuthorizedOrNotFoundをスローします。詳細は、https://github.com/oracle/oci-python-sdk/issues/344を参照してください。

回避策:複合操作を使用するかわりに、この操作に2つの異なるクライアントを使用します。ソース・リージョンの1つのクライアントは、リージョンAからリージョンBへのバックアップのコピー・リクエストを送信し、宛先リージョンの2つ目のクライアントは、バックアップが使用可能になるまで待機します。次の例を参照してください。https://github.com/oracle/oci-python-sdk/blob/master/examples/copy_volume_backup_example.py

この問題への直接リンク: Python SDKコンポジット操作は、操作が成功しても404 NotAuthorizedOrNotFoundエラーをスローします

スケジュール済クロス・リージョン・バックアップ・コピーの宛先リージョンにコピーされないボールト暗号化キー

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

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

この問題への直接リンク: スケジュールされたクロスリージョン・バックアップ・コピーの宛先リージョンにVault暗号化キーがコピーされませ

ブロック・ボリュームとブート・ボリュームでコンパートメント変更の終了イベントが発行されません

詳細: com.oraclecloud.blockvolumes.changevolumecompartment.endおよびcom.oraclecloud.blockvolumes.changebootvolumecompartment.endイベントが、操作が正常に完了しても、対応する開始イベントの後にブロック・ボリューム・サービスによって発行されません。

回避策: 問題を認識しており、解決に取り組んでいます。リソースが新規コンパートメントに移動されたことを直接確認してください。

この問題への直接リンク: ブロック・ボリュームとブート・ボリュームでコンパートメント変更の終了イベントが発行されません

updatevolumekmskeyおよびupdatebootvolumekmskeyイベントにブロック・ボリュームとブート・ボリュームの情報が欠落しています

詳細: com.oraclecloud.blockvolumes.updatevolumekmskey.beginおよびcom.oraclecloud.blockvolumes.updatebootvolumekmskey.beginイベントにcurrentフィールドがありません。これには、ボリューム用に構成する新しいキーのKMSキーIDが含まれている必要があります。かわりに、previousフィールドに以前のKMSキーIDが含まれている必要がある場合、previousフィールドにこの値が含まれます。

回避策: 問題を認識しており、解決に取り組んでいます。更新後にリソースに予期されたKMSキーIDがあることを確認してください。

この問題への直接リンク: updatevolumekmskeyおよびupdatebootvolumekmskeyイベントにブロック・ボリュームとブート・ボリュームの情報が欠落しています

手動のボリュームおよびブート・ボリュームのバックアップを使用した作成イベントでvolumeIdフィールドの形式が正しくありません

詳細: com.oraclecloud.blockvolumes.createvolumebackup.endおよびcom.oraclecloud.blockvolumes.createbootvolumebackup.endイベントのadditionalDetailsにあるvolumeIdフィールドが、手動作成されたバックアップ用の文字列としてではなく、オブジェクトとして書式設定されます。つまり、このフィールドでトリガーされるように設定されているルールが、手動作成されたバックアップに対してトリガーされません。このフィールドは、スケジュール済バックアップ用の文字列として正しく書式設定されます。

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

この問題への直接リンク: 手動のボリュームおよびブート・ボリュームのバックアップを使用した作成イベントでvolumeIdフィールドの形式が正しくありません

copyvolumebackup.beginおよびcopyvolumebackup.endイベントのadditionalDetails情報がありません

詳細: com.oraclecloud.blockvolumes.copyvolumebackup.beginおよびcom.oraclecloud.blockvolumes.copyvolumebackup.endイベントのsourceBackupIdフィールドとdestinationRegionフィールドがadditionalDetails内にないため、これらのフィールドに基づいてトリガーするように設定されているルールがトリガーされません。

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

この問題への直接リンク: copyvolumebackup.beginおよびcopyvolumebackup.endイベントのadditionalDetails情報がありません

デバイス・パス・オプションは、2019年1月11日より前に起動されたインスタンスには使用できません

詳細: 2019年1月11日より前に起動されたインスタンスにブロック・ボリュームをアタッチする場合、デバイス・パスを指定できません。

この問題への直接リンク: デバイス・パス・オプションは、2019年1月11日より前に起動されたインスタンスには使用できません

ボリュームのクローニング中に409エラーが発生します

詳細: インスタンスにアタッチされているボリュームをクローニングし、クローンを削除してからボリュームを再度クローニングすると、次のエラーが発生する可能性があります:

ボリューム<volume-OCID>はアタッチ中はパラレルにクローニングできません

このエラーは、409レスポンス・コードとともに返されることもあります。

回避策: API、CLI、SDKまたはTerraformを使用している場合、削除したクローンのisHydrated属性をモニターする必要があります。この属性値がtrueになるまで、2番目のクローンを作成しないでください。コンソールを使用している場合は、削除したクローンについて「ブロック・ボリュームの詳細」ページの「ハイドレーション」フィールドをモニターします。このフィールドの値がtrueになるまで、2番目のクローンを作成しないでください。

この問題への直接リンク: ボリュームのクローニング中に409エラーが発生します

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

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

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

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

-IsMultipathEnabled $True

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

CLIを使用したWindowsインスタンスでのボリューム・グループの作成操作が失敗します

詳細: WindowsのCLIを使用してボリューム・グループを作成し、source-detailsパラメータにインラインJSON入力を指定すると、操作に失敗します。

回避策: 問題を認識しており、解決に取り組んでいます。この問題を回避するには、インラインJSONを一重引用符ではなく二重引用符で囲みます。JSON自体で二重引用符をエスケープする必要もあります。たとえば、次のコード部分はLinuxインスタンスで動作します:

--source-details '{"type": "volumeIds", 

これをWindowsインスタンスで動作させるには、これを変更します:

--source-details "{\"type\": \"volumeIds\", 

この問題への直接リンク: CLIを使用したWindowsインスタンスでのボリューム・グループの作成操作が失敗します

CLIを使用したクローニングおよびバックアップからのリストアでブート・ボリュームのサイズ変更が失敗します

詳細: CLIを使用してブート・ボリュームのクローンを作成したり、ブート・ボリュームをバックアップからリストアしたりする場合、ボリュームのサイズを変更できません。

回避策: 問題を認識しており、解決に取り組んでいます。この問題を回避するには、サイズ変更せずにブート・ボリュームをクローニングするか、バックアップからリストアし、クローン操作またはリストア操作の完了後にボリュームのサイズを変更します。

この問題への直接リンク: CLIを使用したクローニングおよびバックアップからのリストアでブート・ボリュームのサイズ変更が失敗します

ボリュームおよびブート・ボリュームの作成コマンドのCLIヘルプ・テキストが正しくありません

詳細: size-in-gbsオプションとsize-in-mbsオプションのヘルプ・テキストが、oci bv volume createおよびoci bv boot-volume create CLIコマンドで正しくありません。ボリュームのクローニング時またはバックアップからのボリュームのリストア時に、これらのオプションを指定できないという誤った記述があります。これは誤っており、これらは、ボリュームをクローニングしたり、バックアップからボリュームをリストアして元のソース・ボリュームより大きいサイズのボリュームにしたりするときに指定できます。元のソース・ボリュームのサイズより小さい値は指定できません。

回避策: 問題を認識しており、解決に取り組んでいます。これらのコマンド・オプションのヘルプ・テキストは無視できます。

この問題への直接リンク: ボリュームおよびブート・ボリュームの作成コマンドのCLIヘルプ・テキストが正しくありません

bootVolumeSizeInGBs属性がnullです

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

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

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

ブロックチェーン・プラットフォーム

ブロックチェーン・プラットフォームの既知の問題は、既知の問題を参照してください。

クラウド・ガード

レポート・リージョンを変更できません

詳細: レポート・リージョンは、クラウド・ガードの有効化中に割り当てられます。この設定は、一度割り当てられると、クラウド・ガードの無効化時および有効化時でも変更できません。

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

この問題への直接リンク: レポート・リージョンを変更できません

条件グループの値チェックがありません

詳細: ディテクタおよびレスポンダ・ルールは、特定のリソース・タイプに適用されます。条件グループを使用すると、そのタイプの特定のリソースをルールの適用に含めるか除外するかを指定できます。

シナリオ1: カスタム値として、または管理対象リスト内で条件グループにリソースOCIDを指定できます。クラウド・ガードは、これらの値の妥当性をチェックしません。

シナリオ2: 国またはリージョンを条件グループ・パラメータとしてアクティビティ・ディテクタに追加する場合、クラウド・ガードはこれらの値の有効性をチェックしません。

回避策: 前述の両方のシナリオで、有効な値を指定していることを確認します。有効な国とリージョンの値のリストは、クローニングされたディテクタ・レシピの変更ディテクタでの条件グループの使用を参照してください。

この問題への直接リンク: 条件グループの値チェックがありません

クラウド・シェル

コンプライアンス・ドキュメント

現在、コンプライアンス・ドキュメントの既知の問題はありません。

コンピュート

Linux 7.xでの再起動後のPCR値の変更

詳細: Linux 7.xを使用してシールド・インスタンスを作成してからインスタンスを再起動すると、PCR値が変更され、赤いシールドが表示されます。

回避策: 問題を認識しており、解決に取り組んでいます。一部のPCR値は実行時に変更されます。この変更は予想されます。回避策として、ゴールデン測定をリセットします。

この問題への直接リンク: Linux 7.xでの再起動後のPCR値の変更

BM.Standard.A1.160インスタンスは、ソケット1のCPUで実行されているアプリケーションに対してネットワーク・パフォーマンスを低下させます

詳細: BM.Standard.A1.160シェイプを使用するベア・メタル・インスタンスでは、ソケット1のCPUで実行されているワークロードのネットワーク・パフォーマンスが低下します。

回避策: 問題を認識しており、解決に取り組んでいます。ネットワークからのパケットを処理するアプリケーションの場合は、ソケット0からCPUにバインドします。

この問題への直接リンク: BM.Standard.A1.160インスタンスでは、ソケット1のCPUで実行されているアプリケーションのネットワーク・パフォーマンスが低下します

Oracle Cloud Agentはサービス・ゲートウェイのみがアタッチされたプライベート・サブネットのWindowsインスタンス上にメトリックをポストしません

詳細:サービス・ゲートウェイがアタッチされたプライベート・サブネット内のWindowsにコンピュート・インスタンスをプロビジョニングする場合、Oracle Cloud Agentプラグインはメトリックを発行しない可能性があります。

回避策: Microsoftの既知の問題記事のステップに従います。DigiCert Global Root G2ルート証明書がインストールされていない場合の接続性の問題

この問題への直接リンク: Oracle Cloud Agentは、サービス・ゲートウェイのみがアタッチされたプライベート・サブネット内のWindowsインスタンスにメトリックをポストしません

Oracle Cloud Agentバージョン1.11.0では自動的には更新されません。

詳細: Oracle Cloudエージェント・ソフトウェア自体は自動的に更新されません。この問題は、Oracle Cloudエージェントがインストールされているイメージに応じて、次のバージョンのOracle Cloudエージェントに影響します。

  • Windows Server: Oracle Cloud Agentのバージョン1.11.0.xに影響します。
  • Oracle Linux 7、Oracle Linux 8、CentOS 7、CentOS8: Oracle Cloud Agentのバージョン1.11.0.xおよび1.11.1.xに影響します。

回避策: Oracle Cloudエージェントを最新バージョンに手動で更新します。

この問題への直接リンク: Oracle Cloud Agentバージョン1.11.0が自動的に更新されませ

VM.Standard.A1.Flexインスタンスは、準仮想化ネットワーク起動オプションのみをサポートします

詳細:ハードウェア支援(SR - IOV)ネットワークでVM.Standard.A1.Flexシェイプを使用するインスタンスでは、パフォーマンスの問題が発生する可能性があり、まれにデータが破損することがあります。これを防ぐために、Ampere A1 Compute (aarch64)のプラットフォーム・イメージは、準仮想化ネットワークのみを使用するように構成されています。プラットフォーム・イメージを使用してインスタンスを作成し、ハードウェア支援ネットワークを指定すると、起動はFailed to validate instance launch optionsのようなメッセージで失敗します。

Ampere A1 Computeと互換性のあるカスタム・イメージの場合、起動は成功しますが、潜在的なパフォーマンスおよびデータ破損の問題を回避するために、ハードウェア支援ネットワークを選択しないことを強くお薦めします。

回避策: 問題を認識しており、解決に取り組んでいます。プラットフォーム・イメージを使用してVM.Standard.A1.Flexインスタンスを作成する場合、Oracleで推奨されるネットワーク起動タイプを選択します。カスタム・イメージの場合は、ハードウェア支援(SR - IOV)ネットワークを使用しないでください。

この問題への直接リンク: VM.Standard.A1.Flexインスタンスでは、準仮想化ネットワーク起動オプションのみがサポートされます

Terraformを使用したIntelおよびAMDインスタンスの作成時に無効なシェイプおよびイメージ・エラー

詳細: Terraformを使用し、Linuxプラットフォーム・イメージを使用してIntelまたはAMDコンピュート・インスタンスを作成すると、操作が失敗し、エラー・コードInvalidParameterShape <<shape_name> is not valid for image <<image_OCID>のようなメッセージが表示されることがあります。

これは、Terraformがイメージdisplay_nameに基づいて最新のイメージを識別した場合に発生します。IntelおよびAMDシェイプ(x86プロセッサ・アーキテクチャ)のイメージは、アームベースのシェイプ(aarch64プロセッサ・アーキテクチャ)のイメージと同じ名前ですが、イメージはプロセッサ・アーキテクチャ間で相互互換性がありません。最新イメージがaarch64イメージの場合、Terraformはx86シェイプのaarch64イメージを選択するため、操作は失敗します。

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

回避策として、次のTerraformファイルを変更します。
  • /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/global/global.datasources.tf
  • /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/pd/pd.datasources.tf
  • /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/nonpd/nonpd.datasources.tf
  • /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/globalDR/globalDR.datasources.tf
  • /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/pdDR/pdDR.datasources.tf

ファイル内のイメージを識別する正規表現を更新して、アームベースのシェイプのすべてのイメージを除外します。アームベースのシェイプのイメージでは、イメージ名にaarchが含まれます。

たとえば、Oracle Linux 8イメージの場合は、次のように更新します。

  • 現在の正規表現: values = ["^.*Oracle-Linux-8[.]*[\\d]*-[^G].*$"]
  • 更新された正規表現: values = ["^.*Oracle-Linux-8[.][0-9]*-[\\d]{4}.[\\d]{2}.[\\d]{2}-[\\d]*$"]

この問題への直接リンク: Terraformを使用してIntelおよびAMDインスタンスを作成する際の無効なシェイプおよびイメージのエラー

Oracle Linux Cloud DeveloperイメージはOS管理サービスで管理できません

詳細: Oracle Linux Cloud Developerイメージを使用するインスタンスはOS管理サービスで管理できません。

回避策: 問題を認識しており、解決に取り組んでいます。Oracle Linux Cloud DeveloperインスタンスにOS管理サービス・エージェント(osms-agent)をインストールしないでください。

この問題への直接リンク: Oracle Linux Cloud DeveloperイメージはOS管理サービスで管理できません

カスタム・イメージのインポートまたはエクスポート時のbucketNameエラーが無効です

詳細: オブジェクト・ストレージ・バケットからカスタム・イメージをインポートまたはエクスポートしようとすると、次のようなエラーが発生する可能性があります:

Invalid bucketName: Specified namespace or bucket to export image does not exist

このエラーは、フェデレーテッド・ユーザーと、動的グループに関連付けられたインスタンス・プリンシパルで認証するユーザーの場合に発生します。

回避策:この問題を回避するには、事前認証済リクエストを作成し、事前認証済リクエストを使用してイメージをインポートまたはエクスポートします。事前認証済リクエストによって、ユーザーは独自の資格証明を持たずにバケットまたはオブジェクトにアクセスできるようになります。事前認証済リクエストの作成および使用方法の詳細なステップは、事前認証済リクエストおよび事前認証済リクエストの使用を参照してください。

この問題へのリンク: カスタム・イメージのインポートまたはエクスポート時のbucketNameエラーが無効です

ブート・ボリュームのバックアップからインスタンスを作成できません

詳細: コンソールでブート・ボリューム・バックアップからインスタンスを作成しようとすると、次のようなエラーが発生することがあります。

インスタンスを作成するためのソース・イメージのロード中にエラーが発生しました。このイメージにアクセスする権限がないか、別のリージョンにある可能性があります。イメージが別のリージョンにある場合でも、インスタンスの起動は可能です。

このエラーは、ブート・ボリューム・バックアップに使用される削除済イメージ・メタデータを含むコンパートメントも削除されている場合に発生することがあります。

回避策:コンパートメントが削除されている場合、CLIを使用してインスタンスを作成します。CLIの使用の詳細は、コマンド・ライン・インタフェース(CLI)を参照してください。

CLIを使用してブート・ボリュームからインスタンスを作成するには、コマンド・プロンプトを開き、起動コマンドを実行します。イメージまたはブート・ボリュームを使用してインスタンスを起動するには、--source-detailsパラメータを含めます。

oci compute instance launch --availability-domain <AVAILABILITY_DOMAIN> --compartment-id, -c <COMPARTMENT_OCID> --shape <SHAPE> --subnet-id <SUBNET_ID> --source-details <file://path/to/file>

この問題への直接リンク: ブート・ボリューム・バックアップからインスタンスを作成できません

Terraformを使用して容量予約からインスタンスを削除できません

詳細: Terraformを使用して容量予約からインスタンスを削除することはできません。

回避策: 問題を認識しており、解決に取り組んでいます。回避策として、コンソール、CLIまたはSDKを使用して、容量予約からインスタンスを削除します。

この問題への直接リンク: Terraformを使用した容量予約からインスタンスを削除できません

30を超える容量構成を作成すると、内部エラーが発生します

詳細: 生産能力予約で30を超える生産能力構成を作成すると、内部エラーが発生します。エラーが発生した後、容量予約に対してインスタンスを起動することはできません。

回避策: 問題を認識しており、解決に取り組んでいます。この問題を回避するには、容量予約に30を超える容量構成を追加しないでください。

この問題への直接リンク: 30を超える容量構成を作成すると、内部エラーが発生します

容量予約のサービス制限が正しくありません

詳細: <<shape>-core-reserved-countサービス制限数が不正確です。「サービス制限」列の数値には、1,000,000,000またはN/Aが表示されます。「使用可能」列の数値は、1,000,000,000から「使用」列の数値またはN/Aを引いて表示される場合があります。1,000,000,000の値は最大値を表し、異なる場合があります。

回避策: 問題を認識しており、解決に取り組んでいます。正確なサービス制限については、Compute Capacity Reservationsを参照してください。

この問題への直接リンク: 容量予約サービス制限が正しくありません

サービス制限の引上げをリクエストする際に、容量予約のサービス・カテゴリがありません

詳細:サービス制限の引上げをリクエストした場合、「サービス・カテゴリ」メニューにはキャパシティ予約のカテゴリは含まれません。

回避策:サービス制限更新のリクエスト」フォームで、次の手順を実行します。

  • サービス・カテゴリ」で、「その他」を選択します。
  • リソース」で、「その他の制限」を選択します。
  • 「リクエストの理由」フィールドに、増やす特定の制限を入力します。

この問題への直接リンク: サービス制限の引上げをリクエストしたときに、キャパシティ予約のサービス・カテゴリがありません

32 OCPUを超えるVM.Standard.E3.FlexインスタンスでWindows Serverが失敗する

詳細: VM.Standard.E3.Flexシェイプを使用してWindows Serverインスタンスを作成する場合、インスタンスに32を超えるOCPUを割り当てると、インスタンスの起動に失敗します。

VM.Standard.E3.Flexシェイプ上の既存のWindows Serverインスタンスのサイズを32を超えるOCPUに変更すると、インスタンスで停止エラー(青い画面)が発生します。

回避策: 問題を認識しており、解決に取り組んでいます。この問題を回避するには、インスタンスのサイズを32 OCPU以下に変更します

この問題への直接リンク: 32 OCPUを超えるVM.Standard.E3.FlexインスタンスでWindows Serverに障害が発生する

リソースにデフォルト・タグが含まれる場合、インスタンス・プールの作成は失敗します

詳細:インスタンス・プールを作成しようとすると、インスタンス・プールの作成がエラー"Authorization failed or requested resource not found"で失敗します。これは、インスタンス・プールで使用されるリソースにデフォルト・タグが含まれており、ユーザーにタグ・ネームスペースに対する権限がないために発生します。

回避策:この問題を回避するには、インスタンス・プールのユーザー・グループ権限をタグ・ネームスペースOracle-Tagsに付与するポリシー・ステートメントを追加します:

Allow group InstancePoolUsers to use tag-namespaces in tenancy where target.tag-namespace.name = 'oracle-tags'

ポリシーの詳細は、コンピュート・インスタンス構成、インスタンス・プールおよびクラスタ・ネットワークをユーザーに管理させるを参照してください。デフォルト・タグの詳細は、「自動タグのデフォルトの理解」を参照してください。

この問題への直接リンク: リソースにデフォルト・タグが含まれている場合、インスタンス・プールの作成に失敗します

コンピュート・インスタンスの作成時にホスト容量不足エラーが発生しました

詳細:インスタンスを作成しようとすると、インスタンスの起動が失敗し、エラー・コードInternalErrorおよびOut of host capacityのようなメッセージが表示されます。これは、リクエストされたフォルト・ドメインおよび可用性ドメインのシェイプの容量が不足しているために発生します。

回避策:通常、容量はほとんどのシェイプですぐに使用可能になります。この問題を回避するには、次を実行します:

  • 前の世代のシェイプを使用している場合は、かわりに現在の世代のシェイプを使用してインスタンスを作成します。容量は前の世代のシェイプに制限されています。
  • 別の可用性ドメインにインスタンスを作成します。
  • フォルト・ドメインを指定せずにインスタンスを作成します。
  • 小さいシェイプを使用するか、別のシリーズのシェイプを使用してインスタンスを作成します。
  • 数分待ってから、再試行してください。

この問題への直接リンク: コンピュート・インスタンスの作成時のホスト容量不足エラー

ブート・ボリューム・アタッチメントの転送中暗号化が、イメージでサポートされていない場合に編集できます

詳細: イメージの転送中暗号化値がnullの場合に、イメージから作成されたインスタンスの転送中暗号化値をnull以外の値に設定できます。

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

この問題への直接リンク: ブート・ボリューム・アタッチメントの転送中暗号化が、イメージでサポートされていない場合に編集できます

Oracle Cloud Agentプラグインはドメイン・コントローラでは使用できません

詳細: Windows Serverインスタンスをドメイン・コントローラとして使用する場合に、モニタリング・サービスやOS管理サービスなど、Oracle Cloudエージェントに依存する機能を使用できません。この状況は、Oracle Cloud AgentによってWindowsにインストールされたサービスが仮想アカウントで実行されるが、仮想アカウントがドメイン・コントローラ・スコープでサポートされていないために発生します。

回避策:使用するOracle Cloudエージェント機能ごとに、services.mscを使用して、ドメイン・サービスまたはユーザー・アカウントを使用するように、該当するNTサービスに対して実行されているユーザーを更新します。次に、次の表に示すように、該当するドメイン・ローカル・グループにユーザーを追加します。

Oracle Cloud Agentの機能 NTサービス・ユーザー ターゲット勘定科目種別 ターゲット・ドメイン・ローカル・グループ
Oracle Cloud Agent NTサービス(コンピュート・インスタンス・モニタリング・プラグインを含む) NT Service\OCA ドメイン・サービス・アカウントまたはユーザー・アカウント パフォーマンス監視グループ
コンピュート・インスタンス実行コマンド・プラグイン NT Service\OCARUN ドメイン・サービス・アカウントまたはローカル管理権限を持つドメイン・ユーザー・アカウント Administratorsグループ
カスタム・ログ・モニタリング・プラグイン NT Service\OCAUM ドメイン・サービス・アカウントまたはローカル管理権限を持つドメイン・ユーザー・アカウント Administratorsグループ
OS管理サービス・エージェント・プラグイン NT Service\OCAOSMS ドメイン・サービス・アカウントまたはローカル管理権限を持つドメイン・ユーザー・アカウント Administratorsグループ
Oracle Cloud Agentアップデータ NT Service\OCAU ドメイン・サービス・アカウントまたはローカル管理権限を持つドメイン・ユーザー・アカウント Administratorsグループ

この問題への直接リンク: Oracle Cloudエージェント・プラグインはドメイン・コントローラで使用できません

予想よりも大きいブート・ボリューム・バックアップ・サイズ

詳細: 最近変更されたコンピュート・サービスでのイメージの処理方法が原因で、ブート・ボリューム・バックアップを作成すると、バックアップが予想より大きくなります。ブート・ボリューム・バックアップがブート・ボリューム・サイズより大きくなる場合もあります。

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

この問題への直接リンク: 予想よりも大きいブート・ボリューム・バックアップ・サイズ

SSHアクセス、DNS参照、およびメタデータ・サービスへのアクセスに関する断続的な問題

詳細:

コンピュート・インスタンスで次のいずれかに関する断続的エラーが発生することがあります:

  • SSHを使用したインスタンスへの接続。

  • DNS参照の実行

  • http://169.254.169.254/*でのメタデータ・サービスへのアクセス。

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

この問題を一時的に回避するには、インスタンスで次のコマンドを実行します:

sudo ethtool -G ens3 tx 513 && sudo ethtool -G ens3 tx 512

この問題への直接リンク: SSHアクセス、DNS参照、およびメタデータ・サービスへのアクセスに関する断続的な問題

iSCSIにアタッチされたボリュームが再起動時に接続しません

詳細: 2019年3月22日から2019年4月9日までのOracle Linux 7 yumリポジトリを使用してインスタンスでyum更新を実行した場合、インスタンスの再起動後にiSCSIにアタッチされたブロック・ボリュームが使用できないという問題が発生する可能性があります。

回避策: これは、再起動時にインスタンスがiSCSIノードに自動的にログインするように構成されていない場合に発生します。自動ログインを構成するには、次のコマンドを実行してiscsi-initiator-utilsパッケージのバージョンを更新します:

sudo yum update -y iscsi-initiator-utils-6.2.0.874-10.0.7.el7

この問題への直接リンク: iSCSIボリュームが再起動時に接続しません

iscsidサービスは自動的に再起動するように構成する必要があります

詳細: Oracle Cloud Infrastructureでは、コンピュート・インスタンスに対してiSCSIにアタッチされたリモート・ブート・ボリュームとブロック・ボリュームがサポートされます。これらのiSCSIにアタッチされたボリュームは、iscsidサービスによって管理されます。サービスがクラッシュしたり、システム管理者が誤ってサービスを停止したりするなど、なんらかの理由でこのサービスが停止した場合に備え、インフラストラクチャの安定性を高めるためにiscsidサービスを自動的に再起動することが重要です。

回避策: 自動的に再起動するようにiscsidサービスを構成する方法のステップは、「Linux iSCSIサービスの更新後の自動再起動」を参照してください。

この問題への直接リンク: iscsidサービスは自動的に再起動するように構成する必要があります

仮想マシン(VM)インスタンスは、ipxeScript属性の値を指定すると、iSCSIにアタッチされたブート・ボリュームで起動します

詳細: 仮想マシン(VM)インスタンス用のインスタンスipxeScript属性に値を指定すると、インスタンスは準仮想化アタッチメントのかわりにブート・ボリュームのiSCSIアタッチメントで起動します。

この問題への直接リンク: 仮想マシン(VM)インスタンスは、ipxeScript属性の値を指定すると、iSCSIにアタッチされたブート・ボリュームで起動します

firewall-cmd --reloadの実行後にインスタンスでシステム・ハングが発生します

詳細:コンピュート・インスタンスでは、ファイアウォールをリロードするために次のコマンドを実行した後に、システム・ハングすることがあります:

firewall-cmd --reload

実行中のインスタンスでこのコマンドを使用してファイアウォールをリロードすると、ファイアウォール・ルールがリロードされる順序に基づいて、インスタンスのブート・ボリュームがiSCSI接続を失ってクラッシュする可能性があります。

回避策: この発生を回避するには、firewall-cmdに対してreloadパラメータを使用しないでください。かわりに、iSCSI接続を失わないように、最初にコールするときにpermanentパラメータを使用してfirewall-cmdコマンドを2回実行してください。

例:

firewall-cmd --permanent
firewall-cmd

この問題への直接リンク: firewall-cmd --reloadの実行後にインスタンスでシステム・ハングが発生します

Windows 2016インスタンスのネットワーク・アイコンに正しくないステータスが表示されます

詳細: Windows 2016を実行しているインスタンスで、インスタンスのネットワーク接続に問題がない場合でも、タスク・バーのネットワーク接続アイコンに赤色の「x」が表示されます。

回避策: 問題を認識しており、解決に取り組んでいます。explorer.exeプロセスをリサイクルすると、アイコンに正しいステータスが表示されます。ただし、これは永続的な修正ではありません。インスタンスを再起動すると、赤色の「x」が再表示されます。

この問題への直接リンク: Windows 2016インスタンスのネットワーク・アイコンに正しくないステータスが表示されます

2018年10月リリースのUbuntu 18.04を実行しているインスタンスでシステム・ハングが発生します

詳細: Ubuntu 18.04プラットフォーム・イメージの10月2018リリースでは、iSCSIdはデフォルトで無効になっています。そのため、このオペレーティング・システムを使用しているインスタンスでは、iSCSI通信が瞬間的に中断した場合、システム・ハングが発生することがあります。

回避策: この問題を回避するには、次のコマンドを実行して、インスタンスでiSCSIdを有効にします:

sudo systemctl enable iscsid && sudo systemctl start iscsid

この問題への直接リンク: 2018年10月リリースのUbuntu 18.04を実行しているインスタンスでシステム・ハングが発生します

kmsKeyId属性がnullです

詳細: GetInstanceまたはListInstances操作をコールすると、InstanceSourceViaImageDetailskmsKeyId属性がnullです。

回避策: この問題を回避するには、GetBootVolume操作をコールして、BootVolumekmsKeyId属性から値を取得します。

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

Ubuntuインスタンスが、Uncomplicated Firewall (UFW)を有効にした後で再起動に失敗します

詳細: Ubuntuを実行しているコンピュート・インスタンスでUFWを有効にすると、インスタンスが正常に再起動されません。

回避策: UFWを使用してファイアウォール・ルールを編集しないでください。プラットフォーム・イメージは、インスタンスがそのブート・ボリュームとブロック・ボリュームに発信接続できるように、ファイアウォール・ルールで事前構成されています。詳細は、「必須のファイアウォール・ルール」を参照してください。UFWがこれらのルールを削除すると、再起動中にインスタンスがブート・ボリュームとブロック・ボリュームに接続できなくなります。

新しいファイアウォール・ルールを変更または追加するには、かわりに/etc/iptables/rules.v4ファイルを更新します。ここでファイアウォール・ルールを変更すると、再起動後に有効になります。ルールを即座に有効にするには、次を実行します:

$ sudo su -
# iptables-restore < /etc/iptables/rules.v4

この問題への直接リンク: インスタンスが、UFWを有効にした後で再起動に失敗します

新しい汎用Windowsカスタム・イメージから起動されたインスタンスにログインできません

詳細: 新しく作成されたカスタムWindowsイメージから起動されたインスタンスにログインできません。

回避策: これは、WMF 5.0へのアップグレード後にSysprepに問題が発生したため、イメージの一般化プロセスが失敗した結果です。この問題を回避するには、「WMF 5.0のインストール後にSysprepが失敗」に記載されたステップを実行します。

この問題への直接リンク: 新しいWindowsカスタム・イメージから起動されたインスタンスにログインできません

Windowsインスタンスから作成されたカスタム・イメージにより、Windowsがセーフ・モードで起動する可能性があります

詳細: Windowsカスタム・イメージを作成した後、イメージから起動された初期インスタンスは、セーフ・モードまたはリカバリ・モードで起動する可能性があります。いずれかのモードで起動したインスタンスは、RDPに応答しません。これは、カスタム・イメージが取得される前にインスタンスが完全に停止できない場合に発生する可能性があります。この場合でも、「VNCコンソールに接続」で説明しているステップを使用してVNCコンソールに接続することで、インスタンスにアクセスできます。

回避策: この問題を回避するには、カスタム・イメージを作成する前に、RDPを使用してインスタンスに接続してログインし、そこからシャットダウンを開始します。

この問題への直接リンク: Windowsインスタンスから作成されたカスタム・イメージにより、Windowsがセーフ・モードで起動する可能性があります

Ubuntu 16カスタム・イメージから起動されたインスタンスには、カスタム・ネットワーク構成が必要です

詳細: Ubuntu 16 LTSおよび新しいリリースのUbuntuをインポートする場合、DHCPはゲートウェイ構成を取得できないため、VNICのゲートウェイへのデフォルト・ルートの設定に失敗します。

回避策: 問題を認識しており、解決に取り組んでいます。この問題を回避するには、インポート後にデフォルト・ルートを静的に構成します。これを行うには:

  1. 次のスクリプトを作成します:

    #! /bin/bash -e
    								ROUTER_IP=$(/usr/bin/curl --silent http://169.254.169.254/opc/v1/vnics/ | grep "virtualRouterIp" | grep -oP "\d+\.\d+\.\d+\.\d+" | head -n 1)
    								echo "Found Router IP $ROUTER_IP"
    
    							ip route add default via $ROUTER_IP

    これを/usr/local/bin/configure_default_route.shに保存します

  2. 次のコマンドを実行して、スクリプトを実行可能にします:

    sudo chmod +x /usr/local/bin/configure_default_route.sh
  3. システムが起動するたびに起動されるように、次を/etc/network/interfacesに追加します:

    # OCI Emulated boot network interface
    								auto ens3
    								iface ens3 inet dhcp
    							post-up /usr/local/bin/configure_default_route.sh

この問題への直接リンク: Ubuntu 16カスタム・イメージから起動されたインスタンスには、カスタム・ネットワーク構成が必要です

インポートされたカスタム・イメージから起動されたインスタンスで、セカンダリVNICのデタッチがタイムアウトする場合があります

詳細: インポートされたカスタム・イメージから起動されたインスタンスからセカンダリVNICをデタッチすると、操作がタイムアウトする場合があります。

回避策: ホット・プラグ・モジュールのacpiphpをロードして、セカンダリVNICをLinuxで正しくデタッチする必要があります。VNICのデタッチに失敗した場合、lsmodコマンドを実行してロード済モジュールのリストを表示し、acpiphpのリストを確認します。リストに表示されない場合は、次のコマンドを実行してモジュールをロードします:

modprobe acpiphp

セカンダリVNICのデタッチ操作を再試行してください。操作を正常に完了するために、システムを再起動することが必要な場合があります。

この問題への直接リンク: インポートされたカスタム・イメージから起動されたインスタンスで、セカンダリVNICのデタッチがタイムアウトする場合があります

セカンダリVNICは、以前のCentOS、Oracle LinuxおよびRHELイメージに対して機能しない場合があります

詳細: カーネルのバグのため、次のオペレーティング・システムではセカンダリVNIC機能はサポートされていません:

  • CentOS 4、5

  • Oracle Linux 4、5

  • RHEL 4、5

再起動後、セカンダリVNICは動作しなくなります。

この問題への直接リンク: セカンダリVNICは、以前のCentOS、Oracle LinuxおよびRHELイメージに対して機能しない場合があります

イメージのエクスポート時の無効なイメージ・エラー

詳細: イメージをエクスポートしようとすると、エクスポートは失敗し、イメージが無効であることを示すエラーが表示されます。このエラーは、US West (Phoenix)リージョンでのみ発生します。

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

  1. エクスポートしようとしているイメージに基づいて新規インスタンスを起動し、イメージに次のシェイプのいずれかを指定します:

    • BM.Standard1.36

    • BM.DenseIO1.36

    • VM.DenseIO1.4

    • VM.DenseIO1.8

    • VM.DenseIO1.16

  2. 「カスタム・イメージを作成するには」で説明しているステップを使用して、カスタム・イメージを作成します。

カスタム・イメージを作成した後、この新規イメージをエクスポートできます。

この問題への直接リンク: イメージのエクスポート時の無効なイメージ・エラー

ベア・メタル・インスタンスのシリアル・コンソールに接続すると、認証エラーが発生します

詳細: ベア・メタル・インスタンスへのSSH接続を確立する場合、SSHクライアントは最初に正しいキーを送信する必要があります。~/.sshまたは~/.ssh/configファイルで複数のSSHキーが構成されている場合、クライアントが最初の認可試行で正しいキーを送信しないと、次のエラー・メッセージが表示されることがあります:

Received disconnect from UNKNOWN port 65535:2: Too many authentication failures.

回避策: 問題を認識しており、解決に取り組んでいます。この問題を回避するには、次の例に示すように、SSHコマンドの接続文字列を変更して、構成ファイル・フラグの-Fを使用してデフォルト構成ファイルをオーバーライドし、-o IdentitiesOnly=yesオプションを使用してSSHクライアントに指定のキーを強制的に使用させ、アイデンティティ・ファイル・フラグの-iを使用して使用するSSHキーを指定します:

ssh -F /dev/null -o IdentitiesOnly=yes -i /<path>/<ssh_key> -o ProxyCommand='ssh -i /<path>/<ssh_key> -W %h:%p -p 443...

この問題への直接リンク: ベア・メタル・インスタンスのシリアル・コンソールに接続すると、認証エラーが発生します

デフォルト・タイム・ゾーンの変更時にWindows VMインスタンスのシステム時間が正しくありません

詳細: タイム・ゾーンをWindows VMインスタンスのデフォルト設定から変更した場合、インスタンスが再起動するかハードウェア・クロックと同期するときに、システム時間がデフォルト・タイム・ゾーンの時間に戻ります。ただし、タイム・ゾーンの設定は新しいタイム・ゾーンに設定されたままであるため、システム・クロックが正しくなくなります。

また、イベント・ログには、システム時間が次の詳細で変更されたことを示すイベントが表示されます:

Change Reason: System time synchronized with the hardware clock.

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

  1. レジストリ・エディタを開いて移動します:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
  2. RealTimeIsUniversalという名前の新しいDWORDキーを作成し、値を1に設定します。

  3. インスタンスを再起動します。
  4. 時間とタイム・ゾーンを手動でリセットします。

この問題への直接リンク: デフォルト・タイム・ゾーンの変更時にWindows VMインスタンスのシステム時間が正しくありません

シリアル・コンソール接続が古いインスタンスに対して機能しません

VMインスタンスの詳細: 2017年8月26日以降に起動された仮想マシン(VM)インスタンスに対するシリアル・コンソール接続のみを作成できます。

ベア・メタル・インスタンスの詳細: 2017年10月21日以降に起動されたベア・メタル・インスタンスに対するシリアル・コンソール接続のみを作成できます。

回避策: VMインスタンスとベア・メタル・インスタンスに指定された日付より前に起動されたインスタンスへのシリアル・コンソール・アクセスが必要な場合、インスタンスのカスタム・イメージを作成することで、この問題を回避できます。カスタム・イメージに基づいて新規インスタンスを起動すると、新規インスタンスからシリアル・コンソールにアクセスできるようになります。カスタム・イメージの作成の詳細は、「カスタム・イメージの管理」を参照してください。

この問題への直接リンク: シリアル・コンソール接続が古いインスタンスに対して機能しません

非アクティブなlistImageパラメータと欠落しているImageレスポンス・フィールド

詳細: コンピュートAPIのListImages操作には、operatingSystemおよびoperatingSystemVersionに対するサーバー側のフィルタリング用パラメータが含まれます。ただし、これらのパラメータは現在非アクティブです。また、Imageレスポンス・オブジェクトのドキュメントにはoperatingSystemおよびoperatingSystemVersion属性が含まれますが、現在、オブジェクトはこれらのフィールドを戻しません。

回避策:プラットフォーム・イメージの表示名には、オペレーティング・システムとオペレーティング・システム・バージョンが含まれます(例: Oracle-Linux-7.2-2016.09.18-0 )。"Oracle Linux"はオペレーティング・システムで、バージョンは"7.2"です。

欠落は認識されており、これらのパラメータと属性をサポートすることが予定されています。

この問題への直接リンク: 非アクティブなlistImageパラメータと欠落しているImageレスポンス・フィールド

ネットワーク・マネージャ・サービスがインストールされている場合、インスタンスの再起動に失敗します

詳細: ネットワーク・マネージャ・サービスがインストールされている場合、インスタンスの再起動が失敗する可能性があります。

回避策: ネットワーク・マネージャ・サービスが必要ない場合は、アンインストールできます。ネットワーク・マネージャ・サービスが必要な場合は、インスタンスを再起動する前にネットワーク・インタフェース構成ファイルを変更します。NM_CONTROLLED構成キーをnoに設定します:

NM_CONTROLLED="no"

通常、ネットワーク・インタフェース構成ファイルは、次の場所にあります:

/etc/sysconfig/network-scripts/ifcfg-<interface_name>

この問題への直接リンク: ネットワーク・マネージャ・サービスがインストールされている場合、インスタンスの再起動に失敗します

インスタンス名にASCII以外の文字があると、Windowsの起動に失敗する可能性があります

詳細: Windowsインスタンス名にASCII以外の文字が含まれる場合、インスタンスが起動に失敗する可能性があります。これは、インスタンスの作成時にWindowsコンピュータ名の設定にインスタンス名が使用されるためです。Windowsではコンピュータ名で許可される文字が制限されますが、ASCII以外の文字はWindowsインスタンスの作成に失敗する原因となることがあります。

回避策: 問題を認識しており、解決に取り組んでいます。この問題を一時的に回避するには、WindowsインスタンスにASCII文字の大文字(A-Z)、小文字(a-z)、数字(0-9)およびハイフン(-)のみを使用して名前を付けます。

この問題への直接リンク: インスタンス名にASCII以外の文字があると、Windowsの起動に失敗する可能性があります

Oracle Kspliceを使用した自動更新が一部のFastConnectネットワーキング設定で失敗します

詳細: 一部のFastConnectネットワーキング設定では、Oracle Kspliceなどのユーティリティの自動パッチ更新ができません。

回避策: /etc/uptrack/uptrack.confファイルで、次のすべてのインスタンスを置き換えます:
oraclecloud-updates-ksplice.oracle.com
次のようにします。
updates.ksplice.<region>.oci.oraclecloud.com 
たとえば、ホーム・リージョンがUS West (Phoenix)の場合は、次のように置き換えます。
oraclecloud-updates-ksplice.oracle.com
次のようにします。
updates.ksplice.us-phoenix-1.oci.oracle.com

この回避策はサービス・ゲートウェイに適用されます。プライベート・エンドポイントには適用されません。

この問題への直接リンク: Oracle Kspliceを使用した自動更新が一部のFastConnectネットワーキング設定で失敗します

2019年9月より前に作成されたインスタンスのOS管理サービスに欠落フラグが必要です

詳細: 2019年9月より前に作成されたOracle LinuxインスタンスでOS管理サービスを使用している場合、サービスが有効になっていないと、「インスタンスの詳細」ページにOS管理サービス(Oracle Cloud Management Agent: 有効)が誤って表示されることがあります。

この問題は、コンピュート・インスタンスのメタデータでisManagementDisabledフラグより前に作成されたインスタンスに影響します。このフラグが存在しないため、これらのインスタンスのメタデータはOS管理サービスに対して正しく設定されません。

回避策: この問題を解決するには、isManagementDisabledフラグをfalseに設定します:

  1. インスタンスのエージェント構成で、isManagementDisabledオプションをfalseに設定します:

    oci compute instance update --instance-id <instance_OCID> --agent-config '{"isManagementDisabled": false, "isMonitoringDisabled": false}'
  2. CLIを使用して、フラグが更新されていることを確認します:

    oci compute instance get --instance-id <instance_OCID>

    出力では、更新されたフラグは"is-management-disabled": falseとして表示されます。

    {
      "data":
        "agent-config": {
          "is-management-disabled": false,
          "is-monitoring-disabled": false
        },
    ...
    }
  3. SSHを使用してインスタンスに接続し、cURLを使用してインスタンス・メタデータ・サービスをコールし、コンピュート・インスタンス内でフラグが更新されていることを確認します:

    curl http://169.254.169.254/opc/v1/instance/

    出力では、更新されたフラグは"managementDisabled" : falseとして表示されます。

    {
      ...
      "agentConfig" : {
        "monitoringDisabled" : false,
        "managementDisabled" : false
      }
    }

この問題への直接リンク: 2019年9月より前に作成されたインスタンスのOS管理サービスに欠落フラグが必要です

RESOLVED:いくつかのシェイプに対して不正なストレージ・サイズが表示されます。

詳細:次のコンピュート・シェイプのリストでは、NVMeドライブのサイズに正しくない値がコンソールに表示され、ListShapes API操作によって返されます。

  • BM.DenseIO1.36
  • BM.DenseIO2.52
  • BM.GPU4.8
  • BM.HighIO1.36
  • BM.HPC2.36
  • VM.DenseIO1.4
  • VM.DenseIO2.8

回避策: この問題は解決されました。

この問題への直接リンク: 解決済:一部のシェイプに対して正しくないストレージ・サイズが表示されます

RESOLVED:マーケットプレイスHPCイメージはRDMAクラスタ・ネットワーク上のOptimized3シェイプをサポートしていません

詳細: Marketplace HPCイメージはBM.HPC2インスタンス・シェイプ用に構築されており、新しいBM.Optimized3シェイプと互換性がありません。

回避策: この問題は解決されました。

この問題への直接リンク: 解決済:マーケットプレイスHPCイメージでは、RDMAクラスタ・ネットワーク上のOptimized3シェイプはサポートされていません

RESOLVED: Oracle Autonomous LinuxイメージはOS管理サービスで管理できません

詳細: Oracle Autonomous Linuxイメージを使用するインスタンスはOS管理サービスで管理できません。

回避策:この問題は、2021年8月Oracle Autonomous Linuxプラットフォーム・イメージから解決されます。

この問題への直接リンク: Oracle Autonomous LinuxイメージはOS管理サービスで管理できません

RESOLVED: Ampere A1コンピュート・インスタンスのVNCコンソール接続は読取り専用です

詳細: VM.Standard.A1.FlexシェイプまたはBM.Standard.A1.160シェイプを使用するインスタンスへのVNCコンソール接続を作成する場合、コンソール接続は読取り専用です。

回避策: この問題は解決されました。

この問題への直接リンク: RESOLVED: Ampere A1コンピュート・インスタンス上のVNCコンソール接続が読取り専用です

コンソール

Firefoxブラウザのバグにより、コンソールがロードされない場合があります

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

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

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

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

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

Container Engine for Kubernetes

ワーカー・ノード・プロパティが更新されたノード・プール・プロパティと同期しません

詳細: ノード・プールで開始する新しいワーカー・ノードのプロパティは、ノード・プールのプロパティに対する最新の変更を反映しません。UpdateNodePoolDetails API操作を使用してノード・プールのプロパティを更新する際に、非推奨のquantityPerSubnetおよびsubnetIds属性が使用されていることが原因となっている可能性があります。

回避策: 次のいずれかを実行します:
  • UpdateNodePoolDetails API操作を使用する場合は、nodeConfigDetails属性の使用を開始します。最初に、quantityPerSubnetを使用してノード・プールを0にスケーリングします。次に、subnetIdsおよびquantityPerSubnet属性の使用を停止し、かわりにnodeConfigDetails属性を使用します。
  • Oracle Supportに連絡して、同期を担当するバックエンド・コンポーネント(テナント・エージェント・コンポーネント)を再起動します。

この問題への直接リンク: ワーカー・ノード・プロパティが更新されたノード・プール・プロパティと同期しません

Kubernetesダッシュボードを起動できません

詳細: Kubernetesダッシュボードを起動するとき、状況によっては、"net/http: TLS handshake timeout"や"connection reset by peer"というエラー・メッセージがWebブラウザに表示されることがあります。この問題は、Kubernetesバージョン1.11を実行している新規作成されたクラスタでのみ発生しています。関連するKubernetes問題の詳細は、https://github.com/kubernetes/dashboard/issues/3038を参照してください。

回避策:

  1. ターミナル・ウィンドウで入力します:

    $ kubectl -n kube-system port-forward svc/kubernetes-dashboard 8443:443
  2. Webブラウザでhttps://localhost:8443に移動します

この問題への直接リンク: Kubernetesダッシュボードを起動できません

クラスタ内のHelmにアクセスできません

詳細: Kubeconfigトークン・バージョン2.0.0を使用してバージョン2.11より前のHelm/Tillerバージョンにアクセスすると、次のいずれかのエラーが発生します:

  • Error: Unauthorized
  • Error: could not get Kubernetes client: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1beta1"

回避策: Helm /Tillerを次のようにアップグレードします:

  1. ターミナル・ウィンドウで、次のコマンドを入力してKubeconfigトークン・バージョン1.0.0をダウンロードします:

    $ oci ce cluster create-kubeconfig --token-version=1.0.0 --cluster-id=<cluster_ocid>
  2. クラスタのリージョンでOracle Cloud Infrastructure Registryレジストリの指定に使用するリージョン・キーを識別します(リージョンごとの可用性を参照)。たとえば、クラスタが米国東部(アッシュバーン)にある場合、iadはそのリージョンでレジストリを指定するために使用するリージョン・キーです。

  3. 次のコマンドを入力してTillerをアップグレードします:

    $ helm init --upgrade -i <region-key>.ocir.io/odx-oke/oke-public/tiller:v2.14.3

    ここで、<region-key>は前のステップで識別したキーです。

  4. ブラウザでhttps://helm.sh/docs/using_helm/#installing-the-helm-clientに移動し、指示に従ってHelmクライアント・バイナリをダウンロードしてインストールします。

  5. アップグレードされたHelm/Tillerで、次のコマンドを入力してKubeconfigトークン・バージョン2.0.0をダウンロードします:

    $ oci ce cluster create-kubeconfig --token-version=2.0.0 --cluster-id=<cluster_ocid>

この問題への直接リンク: クラスタ内のHelmにアクセスできません

一部のKubernetes機能(メトリック・サーバーなど)では、http/2経由でkubeletと通信できません

詳細: Container Engine for Kubernetes 1.8.0リリースには、顧客のワーカー・ノードで実行されているkubeletの暗号強度を向上するためのセキュリティの強化が含まれていました。2019年8月20日から2019年9月16日の間に作成された新しいワーカー・ノードには、この構成が含まれます。新しい暗号セットでは、http/2を介したkubeletへの接続は許可されません。この制限は、メトリック・サーバーと、メトリック・サーバーに依存するHorizontal Pod Autoscalerにも影響します。

回避策:

既存の各ワーカー・ノードで順番に:

  1. 新しいポッドが開始されないようにし、kubectl drain <node_name>を入力してワーカー・ノードの既存のポッドを削除します。詳細情報:

    推奨: アプリケーションに応じてポッド中断の予算を活用し、ドレイン操作全体を通じて十分な数のレプリカ・ポッドが実行されていることを確認してください。

  2. ワーカー・ノードを削除します(たとえば、コンソールで終了します)。
  3. 代替ワーカー・ノードが起動するのを待機します。

代替ワーカー・ノードには、kubeletとの通信を可能にする新しい設定が含まれます。

この問題への直接リンク: 一部のKubernetes機能(メトリック・サーバーなど)では、http/2経由でkubeletと通信できません

タイムアウトが原因でKubernetesポッドがボリュームのマウントに失敗します

詳細: クラスタ内のワーカー・ノードで新しいポッドが起動すると、状況によってはタイムアウトが原因でポッドがノードにアタッチされたすべてのボリュームのマウントに失敗し、次のようなメッセージが表示されます:

Unable to mount volumes for pod "<pod_name>(<pod_uid>)": timeout expired waiting for volumes to attach or mount for pod "<namespace>"/"<pod_name>". list of unmounted volumes=[<failed_volume>]. list of unattached volumes=[<… list of volumes >]

この問題に対して特定されている考えられる原因の1つは、ポッド仕様のsecurityContextフィールドにfsGroupフィールドが含まれている場合です。コンテナが非rootユーザーとしてワーカー・ノードで実行されている場合、securityContextfsGroupフィールドを設定すると、Kubernetesが所有権を変更する必要があるファイルの数が原因でタイムアウトが発生する可能性があります(https://github.com/kubernetes/kubernetes/issues/67014を参照)。

ポッド仕様のsecurityContextfsgroupフィールドが含まれていない場合、原因は不明です。

回避策:

ポッド仕様のsecurityContextfsgroupフィールドが含まれていて、コンテナが非rootユーザーで実行されている場合は、次の回避策を検討してください:

  • securityContextからfsgroupフィールドを削除します。
  • (fsgroupのかわりに) securityContextsupplementalGroupsフィールドを使用し、supplementalGroupsをボリューム識別子に設定します。
  • コンテナがルートとして実行されるようにポッド仕様を変更します。

ポッド仕様のsecurityContextfsgroupフィールドが含まれていないか、コンテナがすでにrootとして実行されている場合は、ワーカー・ノードを再起動または置換する必要があります。たとえば、インスタンスを停止して起動するか、インスタンスを再起動するか、インスタンスを終了して新しいインスタンスを起動します。必要に応じて、インスタンスの停止および起動またはインスタンスの終了の手順に従って、コンソールまたはAPIを使用します。または、次の例のようなCLIコマンドを使用してインスタンスを終了することもできます:

$ INSTANCE_OCID=$(kubectl get node <name> -ojsonpath='{.spec.providerID}')
$ oci compute instance terminate --instance-id $INSTANCE_OCID

<name>は、インスタンスの「プライベートIPアドレス」プロパティから導出されたワーカー・ノード名です(たとえば、10.0.10.5)。

この問題への直接リンク: タイムアウトが原因でKubernetesポッドがボリュームのマウントに失敗します

Kubernetesバージョン1.17で導入された新しいラベルはノードに追加されません

詳細:多数のbeta.kubernetes.ioノード・ラベルはKubernetesバージョン1.17で非推奨になり、GAと同等のものが推奨されます。具体的には、次のとおりです。

非推奨のラベル Kubernetesバージョン1.17での同等のラベル
beta.kubernetes.io/instance-type node.kubernetes.io/instance-type
failure-domain.beta.kubernetes.io/region topology.kubernetes.io/region
failure-domain.beta.kubernetes.io/zone topology.kubernetes.io/zone

ただし、Container Engine for Kubernetesでは、GAの同等のラベルではなく、非推奨のラベルがワーカー・ノードに引き続き追加されます。

回避策:

オラクル社では問題を認識しており、解決に取り組んでいます。

この問題への直接リンク: Kubernetesバージョン1.17で導入された新しいラベルはノードに追加されません

OS管理により、Kubernetesクラスタ・ノード・プールが失敗します

詳細: OS管理サービスを使用してOracle Cloud Infrastructureインスタンスのオペレーティング・システムの更新およびパッチを管理する場合、Container Engine for Kubernetesによって作成されたクラスタ・ノード・プールがオンラインにならない場合があります。

回避策:

次の2つの回避方法を使用できます。

  • 回避策1: OS管理を使用してOracle Cloud Infrastructureインスタンスを管理する場合は、OS管理でOracle Enterprise Linuxを有効にします。ソフトウェア・ソースの管理を参照してください。
  • 回避策2: OS管理を使用してOracle Cloud Infrastructureインスタンスを管理しない場合は、OS管理の実行を許可するポリシーがないことを確認します。具体的には、インスタンスの動的グループにOS管理サービスへのアクセス権を付与するポリシーを削除します。OS管理のポリシーの設定を参照してください。

この問題への直接リンク: OS管理により、Kubernetesクラスタ・ノード・プールで障害が発生します

Kubernetesバージョン1.19 (以降)を実行しているマスター・ノードと、Kubernetesバージョン1.18 (以前)を実行しているワーカー・ノードを含むノード・プールでのボリューム・マウントの問題

詳細: ノード・プールでKubernetesバージョン1.19 (以降)を実行しているマスター・ノードと、Kubernetesバージョン1.18 (またはそれ以前)を実行しているワーカー・ノードがある場合、FlexVolumeボリューム・プラグインを使用してクラスタにアタッチされたマウント・ブロック・ボリュームが期待どおりに動作しないことがあります。たとえば、次のように表示されます。

  • ブロック・ボリュームが正常にアタッチされている場合でも、ワーカー・ノードで実行されているポッドのイベントにおけるFailedMount警告メッセージ。
  • ワーカー・ノードで実行されているkubeletのログ内のVolume not attached according to node status for volumeエラー・メッセージ。

回避策:

  1. Kubernetesバージョン1.19 (以降)を実行しているワーカー・ノードがあるクラスタ内にノード・プールがまだ存在しない場合は、ここでノード・プールを追加します。
  2. Kubernetesバージョン1.18 (またはそれ以前)を実行している、影響を受けるワーカー・ノードを次のように削除します。
    1. 新しいポッドが開始されないようにし、kubectl drain <node_name>を入力して、影響を受けるワーカー・ノードの既存のポッドを削除します。詳細情報:
    2. 影響を受けるワーカー・ノードを削除します(たとえば、コンソールで終了します)。

この問題への直接リンク: Kubernetesバージョン1.19 (以降)を実行しているマスター・ノードと、Kubernetesバージョン1.18 (以前)を実行しているワーカー・ノードを含むノード・プールでのボリューム・マウントの問題

DNS (nslookup、dig、またはcurl)による解決の問題
詳細: Bridge Netfilterカーネル・モジュールが有効になっていない場合、localhostとのトラフィック通信は正常にルーティングされません。例:
/ # nslookup www.oracle.com
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; connection timed out; no servers could be reached 
この問題を確認するには、インスタンスでターミナル・ウィンドウを開いて次のコマンドを実行します。
sudo /usr/sbin/lsmod | grep br_netfilter 

結果が返されない場合は、Bridge Netfilterカーネルモジュールが有効になっていません。Bridge Netfilterカーネル・モジュールは、KubernetesポッドのVxLANトラフィックをマスカレードするために必要です。

回避方法: Bridge Netfilterカーネルモジュールを有効にします。インスタンス上でターミナル・ウィンドウを開き、次のコマンドを実行します:
sudo modprobe br_netfilter 
sudo sh -c 'echo "br_netfilter" > /etc/modules-load.d/br_netfilter.conf'

この問題への直接リンク: DNSでの解決の問題(nslookup、digまたはcurl)

データ・カタログ

用語集のエクスポートまたはインポート時にリッチ・テキスト書式の一部が失われます

詳細:用語集をエクスポートまたはインポートするときに、説明フィールドに適用されているリッチテキスト書式が失われます。

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

この問題への直接リンク: 用語集のエクスポート時にリッチテキスト書式が失われる

Autonomous Databaseデータ・アセットの増分収集

詳細: Autonomous Databaseデータ・アセットの収集に増分収集オプションを使用すると、Oracle Databaseのコメント列への変更はデータ・カタログによって識別されません。

回避策: 増分収集オプションを選択しないでデータ・アセットを再収集してください。これにより、データ・アセットの最新状態がデータ・カタログに反映されます。

この問題への直接リンク: Autonomous Databaseデータ・アセットの増分収集

カスタム・プロパティ値のインポート・ジョブは警告なしで成功します

詳細:無効なカスタム・プロパティ値を持つMicrosoft Excelファイルをインポートすると、ジョブ・ログに検証エラーが表示されるにもかかわらず、ジョブは警告なしで成功します。

回避策: 問題を認識しており、解決に取り組んでいます。インポートしたカスタム・プロパティ値がオブジェクトのサマリー・ページで見つからない場合は、ジョブ・ログを調べて、検証エラーがあるかどうかを確認します。

この問題への直接リンク: インポート・カスタム・プロパティ値ジョブは警告なしで成功します。

オブジェクトのカスタム・プロパティの設定値を削除した後、変更を保存できません

詳細:データ・カタログ・オブジェクトの編集中に、一連の値が定義されているカスタム・プロパティの設定値を削除し、変更を保存しようとすると、編集対象の唯一のカスタム・プロパティである場合、その設定はできません。

回避方法:編集中のプロパティーとともに、もう1つのカスタムプロパティーを変更します。「変更の保存」ボタンが有効になり、変更を保存できます。

この問題への直接リンク: 一連の値で定義されたカスタム・プロパティの設定値を削除した後で保存できません

データ・フロー

各アプリケーションに必要なファイルは、そのアプリケーションが作成されたのと同じリージョンにある必要がある。

詳細: アプリケーションは、正常に実行するために必要なすべての関連ファイル、jarおよび構成を含むオブジェクト・ストア・バケットと同じリージョンに作成する必要があります。クロス・リージョン・シナリオはサポートされていません。

回避策: オラクル社では、この問題について認識しています。回避策はありませんが、すべてのファイル、jar、構成などが同じリージョン内にあることを確認してください。

この問題への直接リンク: 各アプリケーションに必要なファイルは、そのアプリケーションが作成されたのと同じリージョンにある必要がある。

高スループット・データのストリーム処理は現在サポートされていません。

詳細: 高スループットのライブ・データを処理するためにSparkストリーミングのサポートを必要とするアプリケーションはサポートされません。

回避策: オラクル社ではこの問題を認識していますが、回避策はありません。

この問題への直接リンク: 高スループット・データのストリーム処理は現在サポートされていない。

Spark UIエラー

詳細: Spark UIにアクセスするときにエラーが発生することがあります。このエラーの一般的な原因は、Sparkアプリケーションが終了していることです。

回避策: エラーが発生した場合は、Spark UIに再度アクセスする前に1分待ってください。

この問題への直接リンク: Spark UIエラー

データ統合

AWS S3から読み取るOCIデータ・フロー・アプリケーションの実行に失敗する

詳細: AWS S3を読み取るOCIデータ・フロー・アプリケーションに関連付けられているOCIデータ・フロー・タスクを実行すると、OCIデータ・フローでアプリケーション実行が失敗します。データ統合とOCIデータ・フローのHadoopバージョンの不一致により、Sparkエラーがスローされます。

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

この問題への直接リンク: AWS S3から読み取るOCIデータ・フロー・アプリケーションの実行に失敗します

パターン一致マクロ式によって変換された属性でマージ変換が失敗します

詳細:マージ属性変換を、パターン一致マクロ式(%MACRO_INPUT%)を使用して変換が適用された1つ以上の属性に適用すると、データ・エクスプローラによって例外エラーが返されます。例:

DIS_DATA_XPLORER_0007 Caused by: Exception occurred during parsing of expression: cannot resolve EXPRESSION_1.MACRO_1.<entity>.<entity_attribute>

回避策:問題を認識しており、解決作業中です。一方、パターン・マクロ式ではなく属性名を選択して変換を適用します。

この問題への直接リンク: パターン一致マクロ式によって変換された属性に対するマージ変換の失敗

式演算子を使用して「データ型の変更」処理によって変換された属性に対する操作は失敗します

詳細: 1つ以上の属性の式演算子を使用して「データ型の変更」アクションを適用すると、データ統合によってパターン・マクロ式(%MACRO_INPUT%)が追加されます。マクロ式によって変換された属性に対する後続の操作は失敗し、次のような例外エラーメッセージが表示されます。

DIS_DATA_XPLORER_0007 Caused by: Exception occurred during parsing of expression: cannot extract value from FILTER_1.MACRO_1.<entity>.<entity_attribute>

回避策:問題を認識しており、解決作業中です。一方、「データ」タブを使用して、1つ以上の属性に対するアクションを選択して、データ型の変更変換を適用します。

この問題への直接リンク: 式演算子を使用して「データ型の変更」アクションによって変換された属性に対する操作は失敗します

システム・パラメータが渡されると、パイプラインでのSQLタスク実行が失敗します

詳細: SQLタスクで、TIMESTAMP入力パラメータの値をパイプライン・システム・パラメータに構成すると、そのタスクを使用するパイプラインでのSQLタスクの実行に失敗します。

回避策:問題を認識しており、解決作業中です。

この問題への直接リンク: システム・パラメータが渡されたときに、パイプラインでのSQLタスク実行が失敗します

ワークスペースのアップタイムが既存のワークスペースに対して正しくありません

詳細:「ワークスペースのモニター」ページに表示されるワークスペース稼働時間は、ワークスペースが最後に起動されてから稼働していた時間です。この値は新しいワークスペースに対してのみ正確です。

回避策:問題を認識しており、解決作業中です。

この問題への直接リンク: 既存のワークスペースに対するワークスペース・アップタイムが正しくありません

データ・サイエンス

現在、データ・サイエンス・サービスに既知の問題はありません。

データベース

すべてのDBシステム

新規データベース内の既存のPDB

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

回避方法:ありません

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

既存のData Guard構成のPDB

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

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

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

Oracle Database 12c R1上の顧客管理キーベースのTDEウォレットへのファイルベースTDEウォレットの移行

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

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

回避策: 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を指します。

顧客管理のキーベースのTDEウォレットをOracle Database 12c R1のファイルベースのTDEウォレットに移行

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

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

回避策: DBAASCLIユーティリティを--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 &
Oracle Database 12c R2上の顧客管理キーベースのTDEウォレットへのファイルベースTDEウォレットの移行

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

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

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

  1. 次のように、データベースに暗号化された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を指します。

顧客管理のキーベースのTDEウォレットをOracle Database 12c R2のファイルベースのTDEウォレットに移行

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

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

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

  1. 次のように、データベースに暗号化された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時間は両方のタイプのライセンスに対して請求されます。その後は、更新されたライセンス・タイプに従って請求されます。

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

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

解決済: サービス・ゲートウェイでは、現在OSの更新がサポートされていません

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

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

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

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

ベア・メタルおよび仮想マシンのDBシステムのみ

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

詳細: データベース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の資格証明を使用してバックアップ・モジュールを再インストールします。

ノート

Swiftパスワードは「認証トークン」と呼ばれるようになりました。詳細は、「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を使用したオブジェクト・ストレージへのバックアップが証明書の変更のために失敗します

データベース・サービスSDKの重大な変更

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

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

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

DBシステムで管理対象バックアップを使用できません

詳細: コンソールまたは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シェイプで失敗します

詳細: 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シェイプで失敗します

Oracle Data Pumpの操作で「ORA-00439: 機能は有効ではありません」が返されます

詳細: 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 lspatchesoracleユーザーとして実行するか、dbcli list-dbhomesrootユーザーとして実行します。

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

1ノードのDBシステムからEM Expressコンソールに接続できません

詳細: 適切な権限が自動的に適用されなかったため、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 DBシステムのみ

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

詳細: 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モジュールが古い証明書をまだ参照していると、オブジェクト・ストレージへのバックアップが失敗する可能性があります。

重要

この項の適切な回避策を使用する前に、「各コンピュート・ノードでのクラウド・ツールの手動更新」のステップに従って、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の資格証明を使用してバックアップ・モジュールを再インストールします。

ノート

Swiftパスワードは「認証トークン」と呼ばれるようになりました。詳細は、「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を使用したオブジェクト・ストレージへのバックアップが証明書の変更のために失敗します

dbaascliを使用する場合、コンソール情報がData Guard対応データベースに対して同期されない

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

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

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

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

Grid Infrastructureが、ディスクをオフラインにしてからオンラインにすると起動しません

詳細: これは、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_statusONLINEである必要があり、voting_fileYではない必要があります。

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

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

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

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

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

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

詳細: 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エージェントをインストールするには:

  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以下の場合に発生します。

回避策: 「各コンピュート・ノードでのクラウド・ツールの手動更新」の手順に従って、ツール・パッケージのリリース・バージョンが17430以下であることを確認し、最新バージョンに更新します。

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

Oracle Linux 7で必要な一時ファイルが削除されたため、様々なデータベース・ワークフロー障害が発生します

詳細: 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で必要な一時ファイルが削除されたため、様々なデータベース・ワークフロー障害が発生します

開発者ツール

SDKや他のツールを使用した一部のOCIサービスのオペレーションにおけるレイテンシ問題の増加

詳細: SDK、Terraform、AnsibleおよびCLIを使用して、一部のOCIサービスに対して行われた操作のレイテンシが増加することがあります。この問題はOCIストリーミング・サービスに影響を及ぼすことが確認され、電子メール配信、ヘルス・チェック、NoSQL Database Cloud、レジストリ、汎用アーティファクト、Webアプリケーション・アクセラレーションおよびセキュリティ・サービスにも影響する可能性があります。このリストは包括的ではなく、他のOCIサービスに対しても問題が発生する可能性があります。この問題はOCI Object StorageおよびFunctionサービスに影響を及ぼさないことが確認されました。

次のSDKおよびツールが影響を受けます。

  • Go SDK (バージョン41.2.0以上)
  • .NET SDK (バージョン14.2.0以上)
  • Java SDK (バージョン2.0.0以上)
  • Python SDK (バージョン2.38.4以降)
  • CLI (バージョン2.25.0以上)
  • PowerShellモジュール(バージョン9.2.0以降)
  • Ansibleモジュール(バージョン2.23.0以上)
  • Terraformプロバイダ(バージョン4.30.0以上)

回避策と詳細情報:この問題の修正に積極的に取り組んでいます。詳細および考えられる回避策については、次を参照してください。

この問題への直接リンク: SDKおよびその他のツールを使用した一部のOCIサービスにおける操作のレイテンシ問題の増加

Python SDKコンポジット操作では、操作が成功した場合でも404 NotAuthorizedOrNotFoundエラーがスローされます。

詳細: BlockStorageクライアント・コンポジット操作のcopy_boot_volume_backup_and_wait_for_stateおよびcopy_volume_backup_and_wait_for_stateは、あるリージョンから別のリージョンにバックアップをコピーするときに404 /NotAuthorizedOrNotFoundをスローします。詳細は、https://github.com/oracle/oci-python-sdk/issues/344を参照してください。

回避策:複合操作を使用するかわりに、この操作に2つの異なるクライアントを使用します。ソース・リージョンの1つのクライアントは、リージョンAからリージョンBへのバックアップのコピー・リクエストを送信し、宛先リージョンの2つ目のクライアントは、バックアップが使用可能になるまで待機します。次の例を参照してください。https://github.com/oracle/oci-python-sdk/blob/master/examples/copy_volume_backup_example.py

この問題への直接リンク: Python SDKコンポジット操作は、操作が成功しても404 NotAuthorizedOrNotFoundエラーをスローします

OCI SDK for TypeScriptとJavaScriptによる大きな数値のデータ丸めの問題

詳細: OCI SDK for TypeScriptおよびJavaScriptには、JavaScriptのNumber.MAX_SAFE_INTEGERより大きい数値に関する既知の問題があります。Number.MAX_SAFE_INTEGERより大きい数値を指定すると、丸め処理が行われます。

回避策: APIレスポンスがJavaScriptのNumber.MAX_SAFE_INTERGERより大きい数値を返送する可能性があるという問題に注意してください。現時点では、数値の丸めの問題はAPIの呼び出しには影響しません。

この問題への直接リンク: OCI SDK for TypeScriptおよびJavaScriptでの大きい数値の潜在的なデータ丸めの問題

RefreshableOnNotAuthenticatedProviderを使用したバイナリ・データ・アップロードでのOCI Java SDKによる潜在的なデータ破損の問題

詳細:同期および非同期でデータのストリームをアップロードするバージョン1.25.1以前のOCI Java SDKクライアント(ObjectStorageClientFunctionsInvokeClientなど)を使用していて、RefreshableOnNotAuthenticatedProvider(リソース・プリンシパルやインスタンス・プリンシパルなど)を使用している場合、サイレント・データ破損の影響を受ける可能性があります。

回避策: OCI Java SDKクライアントをバージョン1.25.2以上に更新します。この問題および回避策の詳細は、「RefreshableOnNotAuthenticatedProviderを使用したバイナリ・データのアップロードでのOCI Java SDKの潜在的なデータ破損の問題」を参照してください。

この問題へのリンク: RefreshableOnNotAuthenticatedProviderを使用したバイナリ・データ・アップロードでのOCI Java SDKでの潜在的なデータ破損の問題

RefreshableOnNotAuthenticatedProviderを使用したバイナリ・データ・アップロードでのOCI HDFSコネクタによる潜在的なデータ破損の問題

詳細:バージョン3.2.1.1以前のOCI HDFSコネクタ・クライアントを使用していて、RefreshableOnNotAuthenticatedProvider (たとえば、InstancePrincipalsCustomAuthenticator、またはリソース・プリンシパルやインスタンス・プリンシパル)を使用している場合、サイレント・データ破損の影響を受ける可能性があります。

回避策: OCI HDFSコネクタ・クライアントをバージョン3.2.1.3以上に更新します。この問題および回避策の詳細は、「RefreshableOnNotAuthenticatedProviderでのOCI HDFSコネクタの潜在的なデータ破損の問題」を参照してください。

この問題への直接リンク: RefreshableOnNotAuthenticatedProviderを使用したバイナリ・データ・アップロードでのOCI HDFSコネクタの潜在的なデータ破損の問題

バイナリ・アップロードでのSDK for Pythonによる潜在的なデータ破損

詳細: 再試行が有効になっているか、UploadManager.upload_fileを使用している場合、SDK for Pythonを使用してバイナリ・アップロード操作を実行する際にデータの破損の問題が発生することがあります。

回避策: 問題を認識しており、解決に取り組んでいます。この問題および回避策の詳細は、バイナリ・データのアップロードでのPythonSDKの再試行に関する潜在的なデータ破損の問題を参照してください。

この問題への直接リンク: バイナリ・アップロードでのSDK for Pythonによる潜在的なデータ破損

DNS

現在、DNSの既知の問題はありません。

電子メール配信

古いフェデレーテッド・テナンシのSMTP資格証明にアクセスできません

詳細: フェデレーテッド・ユーザーは、System for Cross-domain Identity Management (SCIM)を使用しない古いテナンシを除き、電子メール配信でサポートされます。SCIMは、すべてのアイデンティティ情報アクセスの標準です。2018年12月より後のすべてのテナンシはSCIMです。

回避策: Oracle Cloud Infrastructureテナンシの管理者に問い合せて、電子メール配信サービスで使用する新規ユーザーをコンソールで作成します。コンソールに(フェデレーテッドではなく)直接ログインすると、ユーザー設定とSMTP資格証明にアクセスできるようになります。

この問題への直接リンク: フェデレーテッド・テナンシのSMTP資格証明にアクセスできません

ルート以外のコンパートメントから抑制を追加しようとしたときにエラーが発生します

詳細: コンソールで、ルート以外のコンパートメントを選択してから「電子メールの抑制リスト」に移動し、抑制を追加しようとすると次のエラーが発生します:

Error: The required compartmentId ocid1.compartment.oc1..aaaaaaaacq3ztcbrxvgfb35zj6wztdpwlkmzfh4rnsq63sugge624qr5cdla must be the root compartment for suppressions

回避策: 承認済送信者ページに移動し、ルート・コンパートメントを選択してから「電子メールの抑制リスト」に戻ります。

この問題への直接リンク: ルート以外のコンパートメントから抑制を追加しようとしたときにエラーが発生します

JavaMailの問題は、複数の受信者がEメールで設定され、1つ以上のEメール・アドレスが抑制された場合に発生します。

詳細: JavaMailライブラリを使用してクライアントで複数の受信者に電子メールを送信する場合、電子メール配信サービスは254 SMTPステータス・コードを返します。このエラーは、抑制されている受信者アドレスでEメールが送信されたことを示します。

JavaMailライブラリには、受信者のリストを受け入れ、sendPartialフラグを設定して有効な受信者のみを送信する機能があります。ただし、このコードは抑制のために新しいサーバー・ステータス・コードを検出し、抑制されたアドレスのみを削除することはできません。かわりに、送信全体を中断して例外を返します。アプリケーションでは、この例外を捕捉し、抑制された受信者を受信者リストから削除して、セットからのみ有効な受信者に送信する必要があります。つまり、アプリケーション・コードは、com.sun.mail.smtp.SMTPAddressFailedExceptionを捕捉し、例外オブジェクトを指定してex.getAddress()をコールして削除するアドレスを取得し、それらを削除して再送信できます。

回避策:抑制リストをアクティブに監視し、送信リストを適宜更新して、抑制されたアドレスが電子メール送信リストに含まれないようにします。詳細は、抑制リストの管理を参照してください。

この問題への直接リンク: 複数の受信者がEメールに設定され、1つ以上のEメール・アドレスが抑制されると、JavaMailの問題が発生します

SHA-1ルート証明書を持つリージョナル・エンドポイントに接続すると、特定のクライアントでSSLハンドシェイク・エラーが発生します

詳細: SHA-1ルート証明書を持つOCIリージョナル・エンドポイントへのSMTP接続を確立する場合、クライアントがデフォルトでこの証明書を許可しないことがあります。次のエラーが発生する場合があります。

SSLV3_ALERT_HANDSHAKE_FAILURE on smtplib.SMTP.starttls()

TLS 1.2仕様は、クライアント指定のsigalgsでSHA-1が許可されていない場合にSHA-1ルート証明書が許可されているかどうかが不明でした。TLS 1.3仕様では、すべての中間証明書がSHA-256を使用するかぎり、サーバーはこのようなクライアントでSHA-1ルート証明書を使用できることが明らかになっていました。一部の新しいクライアント(Ubuntu 20.04でのopensslなど)では、デフォルトでSHA-1の禁止が開始されています。

次のコマンドを実行して、問題を特定します。

openssl s_client -starttls smtp -crlf -connect <endpoint>:587 -no_tls1_3 -sigalgs "RSA+SHA256"
openssl s_client -starttls smtp -crlf -connect <endpoint>:587 -no_tls1_3 -sigalgs "RSA+SHA256:RSA+SHA1"

2番目のコマンドでエラーが発生しない場合は、この問題の影響を受けるリージョンに接続していることを示します。

このエラーは、次のリージョンで発生する可能性があります。

  • ap-sydney-1
  • ap -melbourne-1
  • sa-saopaulo-1
  • ca -montreal-1
  • ca-toronto-1
  • eu-frankfurt-1
  • ap -hyderabad-1
  • ap-mumbai-1
  • ap-osaka-1
  • ap-tokyo-1
  • eu -amsterdam-1
  • me -jeddah-1
  • ap-seoul-1
  • eu-zurich-1
  • uk-london-1

回避策: 問題を認識しており、解決に取り組んでいます。この問題を回避するには、次を実行します:

  • 異なるバージョンのクライアントを使用するか、別の電子メール配信エンドポイントに接続してください。
  • Pythonクライアントの場合、この問題はPython 3 .8.5で発生します。かわりにPython 3 .7.1を使用してください。
    • 関数からPythonクライアントを実行する場合は、func.yamlファイルのランタイム・オプションをpython3.7.1に変更します。例:
      schema_version: 20180708
      name: oci-email-send-python
      version: 0.0.39
      runtime: python3.7.1
      entrypoint: /python/bin/fdk /function/func.py handler
      memory: 256

この問題への直接リンク: SHA-1ルート証明書を持つリージョナル・エンドポイントへの接続時に、特定のクライアントでSSLハンドシェイク・エラーが発生します

イベント

現在、イベントの既知の問題はありません。

ファイル・ストレージ

ファイル・ストレージは現在アクセス制御リスト(ACL)をサポートしていません
詳細: ファイル・ストレージは、ファイル・レベルのアクセス制御リスト(ACL)をサポートしていません。usergroupおよびworld権限のみがサポートされています。ファイル・ストレージでは、ACLのサポートを含まないNFSv3プロトコルが使用されます。setfaclは、マウントされたファイル・システムで失敗します。getfaclは、標準権限のみを返します。
ノート

一部の実装では、NFSv3プロトコルが拡張され、個別のrpcプログラムの一部としてACLのサポートが追加される場合があります。

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

この問題への直接リンク: ファイル・ストレージは現在アクセス制御リスト(ACL)をサポートしていません

Windowsコマンドラインを使用してスナップショットを作成すると、セマフォ・タイムアウト・エラーが発生します

詳細: Windows CMDでmkdirコマンドを使用して、マウントされたファイル・システムのスナップショットを作成すると、エラーが表示されます。例: 

C:\>mkdir X:\.snapshot\snapshot1

セマフォがタイムアウトしました。

エラーは表示されますが、スナップショットは正常に作成されます。

回避策: コンソールAPIまたはCLIを使用してスナップショットを作成します。

この問題への直接リンク: Windowsコマンドラインを使用してスナップショットを作成すると、セマフォ・タイムアウト・エラーが発生します

ファイル・ストレージ・リソースを別のコンパートメントに移動できません

詳細: ファイル・システムまたはマウント・ターゲットをあるコンパートメントから別のコンパートメントに移動すると、操作に失敗します。ユーザーは、管理者グループのメンバーである必要があります。

回避策: 問題を認識しており、解決に取り組んでいます。この問題を回避するには、ユーザーが管理者グループのメンバーであることを確認します。詳細は、「グループの管理」を参照してください。

この問題への直接リンク: ファイル・ストレージ・リソースを別のコンパートメントに移動できません。

ファイル・システムまたはマウント・ターゲットの作成または移動時に409エラーが発生します

詳細: ファイル・システムまたはマウント・ターゲットを作成するか、あるコンパートメントから別のコンパートメントに移動すると、次の409 APIエラーのいずれかが発生する場合があります:

ファイル・システムの作成:

oci.exceptions.ServiceError: {'opc-request-id': <<OPC REQUEST ID>>, 'code': 'Conflict', 'message': 'Another filesystem is currently being provisioned, try again later', 'status': 409}

ファイル・システムの移動:

oci.exceptions.ServiceError: {'opc-request-id': <<OPC REQUEST ID>>, 'code': 'Conflict', 'message': 'filesystem <<FILE SYSTEM OCID>> is currently being modified, try again later', 'status': 409}

マウント・ターゲットの作成:

oci.exceptions.ServiceError: {'opc-request-id': <<OPC REQUEST ID>>, 'code': 'Conflict', 'message': 'Another mount target is currently being provisioned, try again later', 'status': 409}

マウント・ターゲットの移動:

oci.exceptions.ServiceError: {'opc-request-id': <<OPC REQUEST ID>>, 'code': 'Conflict', 'message': 'mount target<<MOUNT TARGET OCID>> is currently being modified, try again later', 'status': 409}

コンパートメント割当て機能では、テナンシがファイル・システムで実行できる同時操作とリージョン内のマウント・ターゲット・リソースの数を制限する制約が導入されます:

  • リージョン内の各テナンシは、一度に1つのCreateFileSystem またはChangeFilesystemCompartment操作を進行中にできます。
  • リージョン内の各テナンシは、一度に1つのCreateMountTargetまたはChangeMountTargetCompartment操作を進行中にできます。

テナンシが複数の同時操作を試行すると、1つの操作が成功し、他の操作は409エラー・レスポンス・コードを受け取ります。OCI SDKのデフォルトの再試行戦略は、409競合を再試行しないようにすることです。SDKの動作 - 再試行を参照してください。

回避策: 問題を認識しており、解決に取り組んでいます。この問題を回避するには、409で再試行するカスタム再試行戦略を作成します。カスタム再試行戦略のいくつかの作成例は、https://github.com/oracle/oci-python-sdk/blob/master/examples/retries.pyを参照してください。

この問題への直接リンク: ファイル・システムまたはマウント・ターゲットの作成または移動時に409エラーが発生します

ファイル・ストレージの転送中暗号化は現在DNSホスト名をサポートしていません

転送中の暗号化を使用するファイルシステムは、DNSホスト名を使用してマウントできません。転送中の暗号化を使用してファイルシステムをマウントするには、IPアドレスのみを使用できます。

詳細:現在、oci-fss-utils転送中暗号化ツールでは、ファイルシステムのマウントにDNSホスト名を使用できません。

回避策: 問題を認識しており、解決に取り組んでいます。この問題が解決されるまで、oci-fss-utilsマウント・コマンドでマウント・ターゲットのIPアドレスを使用します。例:
sudo mount -t oci-fss 10.x.x.x:/fs-export-path /mnt/yourmountpoint
10.x.x.x:を、マウント・ターゲットに割り当てられたローカル・サブネットIPアドレスに置き換え、fs-export-pathを、マウント・ターゲットにファイル・システムを関連付ける際に指定したエクスポート・パスに置き換え、yourmountpointをローカル・マウント・ポイントへのパスに置き換えます。エクスポート・パスは、ファイル・システムへのパス(マウント・ターゲットのIPアドレスに対して相対的)です。詳細は、転送中暗号化の使用を参照してください。

この問題への直接リンク:ファイル・ストレージ転送中暗号化では、現在DNSホスト名はサポートされていません

ファンクション

現在、ファンクションの既知の問題はありません。

ヘルス・チェック

現在、ヘルス・チェックの既知の問題はありません。

IAM

リソース・タイプの新しい権限は伝播されません

詳細:新しい権限が既存のリソース・タイプに追加された場合、その権限はそのリソース・タイプを含むポリシーに伝播されません。これは、ポリシー・ステートメントが変更されないかぎり、IAMがポリシーを再コンパイルしないために発生します。

回避策:リソース・タイプを使用する既存のポリシーの場合、新しい権限がリソース・タイプに追加されたら、空白を追加してポリシーを編集します。次に、ポリシーを保存します。

この問題への直接リンク: リソース・タイプの新しい権限が伝播されない

Microsoft Active Directoryを使用して新規フェデレーションを設定できません

詳細: 設定プロセス中に、Oracle Cloud Infrastructureフェデレーション・メタデータ・ドキュメントをアップロードすると、Microsoft AD FSではアサーション暗号化が自動的に有効になります。Oracle Cloud Infrastructureでは、現時点では暗号化がサポートされていないため、設定に失敗します。

回避策: この問題は解決されました。IAMサービスでは、アサーション暗号化をサポートするようになりました。Microsoft Active Directoryのフェデレートを参照してください。

この問題への直接リンク: Microsoft Active Directoryを使用して新規フェデレーションを設定できません

削除したコンパートメントがサービス制限に対して引き続きカウントされます

詳細: 削除したコンパートメントが、テナンシのコンパートメント・サービス制限に対して引き続きカウントされます。削除されたコンパートメントは365日後にカウントから削除されます。これは、削除されたコンパートメントがコンソールに表示されたままになる期間も指定する設定です。

回避策: この問題が解決されるまで、コンパートメントのサービス制限を増やすようにリクエストできます。「サービス制限の引上げのリクエスト」を参照してください。

この問題への直接リンク: 削除したコンパートメントがサービス制限に対して引き続きカウントされます

Java管理

Java Management Serviceの既知の問題の詳細は、「既知の問題」を参照してください。

ロード・バランシング

Load Balancerで、コンソール・バックエンド・セットのヘルス・インジケータに「不明」と表示される

詳細: コンソールでLoad Balancerチェックを実行する際、ロード・バランサが正常に実行されている場合でも、バックエンド・セットのヘルス・ステータスが「不明」と表示されることがあります。「不明」ステータスはデータ・パスに影響しません。

回避策: ロード・バランサのバックエンド・セットのヘルスを正確に示すために、Oracle Cloud Infrastructureコンソールのパブリック・テレメトリ・グラフを参照します。

この問題への直接リンク: Load Balancerで、コンソール・バックエンド・セットのヘルス・インジケータに「不明」と表示される

LOGGING

一部のエージェント警告は無視できます

詳細: Oracle Fluentベースのエージェントでは、次のような無害な警告が発生する可能性があります。

Sep 22 05:47:43 ociutv3mgftp02 ruby[1278962]: /opt/unified-monitoring-agent/embedded/lib/ruby/gems/2.6.0/gems/oci-2.9.0.1125/lib/oci/identity/models/base_tag_definition_validator.rb:23: warning: already initialized constant OCI::Identity::Models::BaseTagDefinitionValidator::VALIDATOR_TYPE_ENUM
Sep 22 05:47:43 ociutv3mgftp02 ruby[1278962]: /opt/unified-monitoring-agent/embedded/lib/ruby/gems/2.6.0/gems/oci-2.9.0.1125/lib/oci/identity/models/base_tag_definition_validator.rb:24: warning: previous definition of VALIDATOR_TYPE_ENUM was here

無害な警告は無視できます。これらの警告は、エージェントの機能には影響しません。

この問題への直接リンク:一部のエージェントの警告は無視できます

ログ・アナリティクス

zipファイルを使用してWindowsマシンからのオンデマンド・アップロード

詳細: 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を超えるファイルを含むフォルダは、ログ収集の問題(およびオペレーティング・システムの問題)を引き起こす可能性があります。

管理エージェント・ログ・アナリティクス・プラグインで大きなフォルダが検出されると、次の例のようなメッセージが管理エージェントmgmt_agent.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.

解決策: 大きなフォルダは避けることをお薦めします。

ただし、大きなフォルダのログのモニタリングを続行する場合は、次のアクションを実行してmgmt_agent.logファイルに示されているプロパティを有効にできます:

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

INSTALL_DIRECTORYagent_instフォルダのパスに置き換えます。

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

管理エージェント

現在、管理エージェントの既知の問題はありません。

マーケットプレイス

現在、マーケットプレイスの既知の問題はありません。

モニタリング

アラーム・メッセージは、Oracle Platform Services管理コンパートメントで受信されていません

詳細: Oracle Platform Services管理コンパートメント(ManagedCompartmentForPaas)トピックに送信されたアラーム・メッセージは受信されません。 この問題は、モニタリング・サービスにそのコンパートメントのトピックを使用する権限がない場合に発生します。

回避策: 問題を認識しており、解決に取り組んでいます。この問題を回避するには、アラームを非管理対象コンパートメントに移動し、アラームの通知先を更新して非管理対象コンパートメントのトピックを使用します。

この問題への直接リンク: アラーム・メッセージがOracle Platform Services Managed Compartmentsで受信されない

ネットワーキング

LinuxでのセカンダリVNICの構成

詳細: Oracleがhttps://docs.cloud.oracle.com/iaas/Content/Resources/Assets/secondary_vnic_all_configure.shで使用できるようにするスクリプトは、ハイパーバイザ以外のコンピュート・インスタンスに追加のVNICおよびIPアドレスを割り当てる必要がある状況で使用することを目的としています。このスクリプトは、ベア・メタル・インスタンス上のカーネルベースの仮想マシン(KVM)アプリケーションには役立ちません。

回避策: 次のアクションを実行します: ベア・メタル・インスタンス上のKVMアプリケーションの場合は、ホワイト・ペーパー「マルチVNICを使用したベア・メタル・インスタンスへのKVMのインストールおよび構成」を参照してください。

この問題への直接リンク: LinuxでのセカンダリVNICの構成

CPE構成ヘルパー: CPEベンダーの指定

詳細: 次のことが発生した場合、Oracle Consoleでは、CPEにベンダー情報(デバイス・タイプ)が欠落しています。というエラーが表示されます。CPEを更新し、ベンダー情報を追加してください:

  • CPE構成ヘルパー機能がリリースされる前に存在していたCPEがある。
  • Oracle ConsoleでCPEをまだ編集しておらず、どのベンダーがCPEを作成するかを指定した。
  • CPEまたはそのCPEを使用するIPSec接続のヘルパー・コンテンツを生成しようとしている。

回避策: 次のアクションを実行します:

  1. Oracle Consoleで、CPEを表示します。
  2. 「編集」をクリックします。
  3. CPEベンダー情報」セクションで、CPEを作成するベンダーを選択します。CPEの作成ベンダーがわからない場合、またはリストにない場合、「その他」を選択します。
  4. プロンプトが表示されたら、「プラットフォーム/バージョン」の値を選択します。ガイドラインを次に示します:

    • 可能な場合は、ルートベースの構成を使用することをお薦めします。
    • リストに特定のCPEプラットフォームまたはバージョンが表示されない場合は、CPEバージョンより前の最も近いプラットフォーム/バージョンを選択します。
  5. 「変更の保存」をクリックします。ベンダーの値を変更していなくても、これをクリックすることが重要です。

その後、CPEまたはそのCPEを使用するIPSec接続のヘルパー・コンテンツを正常に生成できます。

この問題への直接リンク: CPE構成ヘルパー: CPEベンダーの指定

RESOLVED: Site-to-Site VPN: US East (Ashburn)でのNAT-Tのサポート

詳細: NAT - Tは、US East (Ashburn)リージョン内のすべてのサイト間VPNトンネルに対してまだ完全にサポートされていません。

回避策: この問題は解決されました。

この問題への直接リンク:解決済:サイト間VPN:米国東部(アッシュバーン)でのNAT - Tのサポート

Site-to-Site VPN:複数のモニタリング・チャートのデータが正しくありません

詳細: サイト間VPNトンネルのいくつかのモニタリング・チャートには誤ったデータが表示されるため、トンネルの最近のトラフィック・レベルを特定するために使用しないでください。

要約すると、サイト間VPNトンネルで使用可能なモニタリング・チャートは次のとおりです。

  • IPSecトンネルの状態: このチャートは正確で、トンネルの稼働または停止状態を正しく表示しています。
  • 送受信されたバイトまたはパケット: これらの4つのチャートは不正確で、トンネル経由で送受信されるバイトまたはパケットの正しいレベルを表示していません。
  • エラーのあるパケット: このチャートは不正確で、エラーが発生してドロップされたパケットの正確な数を表示していません。

チャートの詳細は、「サイト間VPNメトリック」を参照してください。

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

この問題への直接リンク: サイト間VPN:いくつかのモニタリング・チャートのデータが正しくありません

RESOLVED: Site-to-Site VPN:リージョナルNAT-Tの可用性とLibreswanの問題

詳細: 次のすべてに該当する場合:

  • Site - to - Site VPNのCPEとしてLibreswanを使用している
  • CPEはNATデバイスの背後にあります
  • Oracle Cloud InfrastructureリージョンのUS East (Ashburn)South Korea Central (Seoul)Japan East (Tokyo)またはCanada Southeast (Toronto)のいずれかに接続しています

NATトラバーサル(NAT - T)ではこれらのリージョンにあるOracleルーターの現在のソフトウェアとの相互運用性に問題があるため、サイト間VPNの接続性問題が発生する可能性があります。

オラクル社は問題を認識しており、この問題を解決するためにソフトウェアを更新中です。

背景: Oracleでは、US East (Ashburn)いくつかのサイト間VPNルーターと、South Korea Central (Seoul)Japan East (Tokyo)およびCanada Southeast (Toronto)のすべてのルーターに対してNATトラバーサル(NAT - T)が有効化されています。ただし、これらのルーターに含まれる現在のバージョンのソフトウェアには、NAT-Tとの相互運用性の問題があります。CPEでNAT-Tを有効にしないよう指示しているOracleの現在のドキュメントに従っている場合は、この問題に関連する問題は発生しません。

ただし、CPEでLibreswanを使用し、NATデバイスの背後にCPEが存在しており、これらのリージョンのいずれかに接続している場合、Oracleがルーター・ソフトウェアを更新している間、接続の問題が発生することがあります。特に、トンネルは起動しますが、トラフィックを通過させることができません。

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

影響を受けるリージョン内の該当するLibreswanユーザー(接続に問題がある場合):

A.CPEでNAT-Tを有効にします:

  1. 関連する接続のipsec.confファイルで、encapsulationの値をnoからyesに変更します。
  2. Libreswanサービスを再起動します。

接続の問題が続く場合:

B.接続を再設定します:

  1. Oracle ConsoleでIPSec接続を再作成します。
  2. 新しいIPSec接続の情報を使用して、Librewswan構成を再作成します。
  3. Libreswanサービスをリロードします。

接続の問題が続く場合:

C.My Oracle Supportに連絡して支援を依頼してください。詳細は、サポート・サービス・リクエストを開くを参照してください。

この問題への直接リンク: 解決済:サイト間VPN:リージョナルNAT - Tの可用性とLibreswanの問題

オンプレミス・ネットワーク用のサービス・ゲートウェイを介したOracle Analytics Cloudへのプライベート・アクセスの問題
詳細: 次のすべてを実行すると、オンプレミス・ネットワークとOracle Analytics Cloudの間のトラフィックで非対称ルーティングが発生する可能性があります: 非対称ルーティングとは、リクエスト・トラフィックとレスポンス・トラフィックが異なるパスを経由することを意味します。非対称ルーティングが発生する理由の詳細は次を参照してください: Oracle Analytics Cloudがオンプレミス・ネットワーク内のクライアントへの接続を開始する場合、接続リクエストはパブリック・パス(インターネットまたはFastConnectパブリック・ピアリング)を経由する必要があります。ただし、レスポンスは、オンプレミス・ネットワークからOracleへのトラフィックのルーティング・プリファレンスの推奨に基づいて、プライベート・パスを経由します。

回避策: 2つのオプションがあります:

  • オプション1 (推奨): Oracle Analytics Cloudで、リモート・データ・コネクタの使用をデータ・ゲートウェイに切り替えます。
  • オプション2: Oracle Analytics Cloudのリージョナル・ソースIPアドレスに静的ルートを追加して、インターネットまたはFastConnectパブリック・ピアリング・パスのいずれかを優先するように顧客構内機器(CPE)を構成します。このようにすると、Oracle Analytics Cloudへのレスポンス・トラフィックは、着信接続リクエストと同じパスに返されます。

回避策が必要となるのは、オンプレミス・ネットワークでクライアントへの接続を開始し、ネットワークでデータ・ゲートウェイをまだ使用しないようにOracle Analytics Cloudを使用する場合のみです。

この問題への直接リンク: オンプレミス・ネットワーク用のサービス・ゲートウェイを介したOracle Analytics Cloudへのプライベート・アクセスの問題

Oracleサービスからサービス・ゲートウェイを介してパブリック・インスタンスにアクセスする場合の問題
詳細: VCNのパブリック・サブネットに関連付けられたルート表に、次の2つの競合するルート・ルールが含まれている場合、Oracleサービスは、そのサブネットのパブリック・インスタンスにアクセスできないことがあります。
  1. 「ターゲット・タイプ」「インターネット・ゲートウェイ」に設定されたルート・ルール。
  2. 「宛先サービス」Oracle Services Networkのすべての<region>サービスに、「ターゲット・タイプ」「サービス・ゲートウェイ」に設定されたルート・ルール。
前述の2つのルート・ルールは、OracleサービスによってVCN内のパブリック・インスタンスへの接続が開始される場合に、非対称ルーティングにつながる可能性があります。Oracle Cloud Infrastructureでは、同じルート表内でこれらのルールが同時にサポートされません。Oracleでは、サービスAPIおよびコンソールが更新され、この構成のサポートが無効になりました。

回避策: 「宛先サービス」Oracle Services Networkのすべての<region>サービスに設定され、「ターゲット・タイプ」「サービス・ゲートウェイ」に設定されたルート・ルールを削除することをお薦めします。Oracle Services Networkのサービス・ゲートウェイを選択する前に使用していた構成に戻してください。この変更により、パブリック・インスタンスは、インターネット・ゲートウェイを介してすべてのOracleサービスにアクセスできるようになります。Oracleサービスは、継続的にパブリック・インスタンスにアクセスできます。

ただし、パブリック・サブネット内のインスタンスは、サービス・ゲートウェイを介してオブジェクト・ストレージに継続的にアクセスできます。「宛先サービス」OCI <region>オブジェクト・ストレージに設定され、「ターゲット」がVCNのサービス・ゲートウェイに設定されたルート・ルールを含めるようにサブネットのルート表を更新してください。

この既知の問題は、インターネット・ゲートウェイにアクセス可能なパブリック・サブネットにのみ適用されます。プライベート・サブネットについて: VCNのサービス・ゲートウェイを介してOracle Services Networkのすべての<region>サービスまたはOCI <region>オブジェクト・ストレージへのアクセスを提供するようにプライベート・サブネットのルート表を構成することもできます。

この問題への直接リンク: Oracleサービスからサービス・ゲートウェイを介してパブリック・インスタンスにアクセスする場合の問題

2つのVCNをブリッジするためのネットワーク仮想アプライアンス仮想マシンのデプロイ

詳細: Network Virtual Appliance仮想マシンをデプロイして2つのVCNをブリッジし、ルート・ルールをインストールした場合、Oracleサービスがそのサブネット内のパブリック・インスタンスにアクセスできないことがあります。

回避策: Oracle CIDRに固有の静的ルートを追加して、トラフィックを元のVCNにトラバースします。

解決済: サービス・ゲートウェイのルート・ルールおよびコンソールの制限

詳細: コンソールを使用して、サービス・ゲートウェイをターゲットとして使用するルート・ルールを設定する場合、ルールの宛先サービスは、そのゲートウェイに対して有効なサービスCIDRラベルに一致する必要があります。例: コンソールを使用して、サービス・ゲートウェイでOracle Services Networkのすべての<region>サービスというラベルを有効にするとします。次に、コンソールを使用してルート・ルールを設定し、サービス・ゲートウェイに指定したサービスCIDRラベルのかわりに、宛先サービスにOCI <region>オブジェクト・ストレージを選択します。ルート・ルールのターゲットを設定しようとすると、サービス・ゲートウェイが、選択対象のサービス・ゲートウェイのリストに表示されません。これは、コンソールでルールに指定した宛先サービスが使用され、そのサービスCIDRが有効になっているサービス・ゲートウェイのみが表示されるためです。VCNに含めることができるサービス・ゲートウェイは1つのみであり、この場合、そのロジックと一致しません。この制限は、コンソールでルート・ルールを設定する場合にのみ存在します。他のインタフェース(SDK、CLI、Terraform)にはこの制限がありません。この制限は、コンソール・インタフェースから削除される予定です。

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

サービス・ゲートウェイとルート・ルールの宛先サービスに同じサービスCIDRラベルを使用します。または、必要に応じて、制限のない別のインタフェース(CLIなど)を使用します。セキュリティ・リストを使用してインスタンス間のトラフィックをフィルタしたり、セキュリティ・リスト・ルールで任意のサービスCIDRラベル(または特定のCIDR)を使用できることにも留意してください。

この問題への直接リンク: サービス・ゲートウェイのルート・ルールおよびコンソールの制限

サービス・ゲートウェイを介したOracle yumサービスへのアクセスの問題
詳細: インターネット・アクセスにインターネット・ゲートウェイまたはNATゲートウェイを同時に使用せずにVCNとともにサービス・ゲートウェイを使用する場合、インスタンスが適切なリージョナルOracle yumサーバーにアクセスできない可能性があります。2つの問題が考えられます:
  • 2018年11月より前に作成されたインスタンスでは、そのリポジトリがサービス・ゲートウェイを介してアクセスできないURLを参照していることがあります
  • 以前はローカル・リージョンのyumサーバーに接続できなかったインスタンスが、yum.oracle.comを使用するように戻され、サービス・ゲートウェイを介してアクセスできなくなることがあります
前提条件: 次のいずれかの軽減策を使用するには、リージョンのyumサーバーに接続できるように、サービス・ゲートウェイ、NATゲートウェイまたはインターネット・ゲートウェイのいずれかのゲートウェイを構成する必要があります。

自動軽減策:

次の自動軽減策を試してみてください。なんらかの理由で失敗した場合は、後続の手動軽減策の方法を使用してください。

次のスクリプトをローカル・システムにコピーして実行します。スクリプトは、既存のリポジトリを無効にし、repoファイルをダウンロードします。このファイルによって、システムはサービス・ゲートウェイを介してアクセス可能なリージョンのローカルyumサーバーに接続されます。

#!/bin/bash
REPODIR='/etc/yum.repos.d'
REPOS=$REPODIR/*
REGION=$(curl -sfm 3 http://169.254.169.254/opc/v1/instance/ | jq -r '.region' | cut -d '-' -f 2)
VERSION=$(egrep '^VERSION_ID' /etc/os-release | cut -d '"' -f 2 | cut -d '.' -f 1)
REPOURL="http://yum-${REGION}.oracle.com/yum-${REGION}-ol${VERSION}.repo"

echo "Disabling existing repos"
for i in $REPOS
do
  if [[ "$i" != *".disabled" ]]; then
    mv $i $i.disabled
    echo "$i disabled"
  else
    echo "$i repofile already disabled"
  fi
done
yum clean all
echo "Pulling new regional repository file"
wget -q $REPOURL -O "$REPODIR/yum-${REGION}-ol${VERSION}.repo"
retval=$?
if [[ "$retval" -ne 0 ]]; then
  echo "Unable to pull repo file, please run manual steps"
  exit 1
fi
yum makecache fast
手動軽減策:

自動軽減策が失敗した場合は、問題を手動で軽減できます。ここでは、既存のrepoファイルを無効化し、リージョンのyumサーバーから最新のrepoファイルを取得します。インスタンスのリージョン・キーを確認するには、「リージョンと可用性ドメイン」のリージョン・リストを参照してください。

既存のrepoファイルを無効化するには、/etc/yum.repos.dディレクトリに移動し、ファイル名の最後に.disabledが含まれるように、存在するすべてのファイルの名前を変更します。

例:

ls /etc/yum.repos.d ksplice-uptrack.repo.disabled public-yum-ol7.repo.disabled

ローカル・システムにリージョンのrepoファイルをダウンロードします。次の例では、Ashburn (リージョン・キーiad)を使用します。iadは、インスタンスにとって適切なリージョン・キーに置き換えてください。

cd /etc/yum.repos.d/
wget http://yum-iad.oracle.com/yum-iad-ol7.repo
chown root:root yum-iad-ol7.repo
yum makecache fast

この問題への直接リンク: 特定のイメージのサービス・ゲートウェイを介したYumサービスへのアクセス

解決済: サブネット内の既存のインスタンスが、DHCPオプションのDNSサーバーの更新されたリストを取得しません

詳細: サブネットのDHCPオプションのセットでDNSサーバーのリストを更新すると、そのサブネット内に後から作成された新しいインスタンス/VNICは更新されたDNSサーバーのリストを取得しますが、サブネット内の既存のインスタンス/VNICは取得しません。

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

サブネットに新規インスタンスを作成して、既存のインスタンスを置換できます。別のオプションとして、次の情報を用意してMy Oracle Supportに連絡してください:

  • VCNのOCID
  • サブネットのOCID
  • 影響を受けるインスタンスのOCID

この特定のインスタンスの問題は、通常、1日以内に解決できます。

この問題への直接リンク: サブネット内の既存のインスタンスが、DHCPオプションのDNSサーバーの更新されたリストを取得しません

WindowsインスタンスではアクティブなFTPはサポートされていません

詳細: Microsoft Windowsによって提供されるデフォルトのFTPクライアントは、アクティブ・モードのFTPのみをサポートします。これは、Oracleのステートフルなファイアウォール・ルールまたはNATゲートウェイの背後にデプロイされたインスタンスでは機能しません。

回避策: Oracleでは、パッシブ・モードで実行されているサードパーティのFTPクライアントをWindowsインスタンスで使用することをお薦めします。

この問題への直接リンク:アクティブFTPはWindowsインスタンスでサポートされていません

通知

現在、通知の既知の問題はありません。

オブジェクト・ストレージ

現在、オブジェクト・ストレージの既知の問題はありません。

オペレーション・インサイト

現在、オペレーション・インサイトの既知の問題はありません。

OS管理

RESOLVED:「Other」としてカテゴリ化されたすべてのWindows更新プログラムを管理対象インスタンス・グループに適用できません。

詳細: OS管理では、現在、「その他」として分類されたすべてのWindows更新プログラムを管理対象インスタンス・グループに適用するアクションは提供されていません。

回避策:この問題は解決されました。「その他」カテゴリが管理対象インスタンス・グループの更新に使用できるようになりました。詳細は、Windowsインスタンスでの更新プログラムのインストールを参照してください。

この問題への直接リンク: 「その他」として分類されたすべてのWindows更新プログラムを管理対象インスタンス・グループに適用できません

Oracle Linux 8でAppStreamsを管理できません

詳細: Oracle Linux 8の場合、OS管理サービスは現在、モジュールまたはモジュール・ストリームとも呼ばれるAppStreamsをサポートしていません。

回避策: 問題を認識しており、解決に取り組んでいます。個々のRPMパッケージを更新できますが、この方法を使用すると、モジュールに関連付けられたバージョン管理は無視されます。AppStreamsの詳細は、Oracle Linux 8: Oracle Linuxでのソフトウェアの管理を参照してください。

この問題への直接リンク: Oracle Linux 8でAppStreamsを管理できません

OS管理コンソールおよびAPIと比較してコントロール・パネルに表示されるWindows更新プログラムの相違

詳細: 「コントロール パネル」に表示されるWindows更新プログラムがOS管理コンソールおよびAPIと異なっている場合があります。

OS管理サービスは、Windows Update Agent (WUA) APIから受け取ったデータに依存します。WUA APIを使用する場合、OS管理サービスには、Windows Server Update Service (WSUS) APIを使用する場合と同様に、使用可能なすべてのAPIへの完全なアクセス権がありません。何を実行できるかを制御するポリシーは、アップストリームのMicrosoft更新サービスにアクセスする場合とWSUSを使用して独自のポリシーを作成する場合とで異なります。

回避策: 現時点では、この動作は予期されたものです。この問題を認識し、改善点を調査しています。

この問題への直接リンク: OS管理コンソールおよびAPIと比較してコントロール・パネルに表示されるWindows更新プログラムの相違

ソフトウェア・ソースがコンソールに最初にロードされるまで数分かかることがある

詳細: コンソールにソフトウェアのソースを表示する場合、ソフトウェアのソースは最初のロードに数分かかることがあり、HTTPタイムアウトが発生することがあります。

回避策: HTTPタイムアウト・エラーが発生した場合は、ブラウザをリフレッシュします。

この問題への直接リンク: ソフトウェア・ソースがコンソールに最初にロードされるまで数分かかることがある

ManagedCompartmentForPaaSコンパートメントで見つかったインスタンスでOS管理サービスを使用できません

詳細: OS管理サービスは、ManagedCompartmentForPaaSコンパートメントで見つかったインスタンスでは使用できません。このコンパートメントは、Oracle Cloud Infrastructure上のOracle Platform Servicesで使用するユーザーのかわりに作成されます。このコンパートメントの詳細は、サポートされているPlatform Servicesに関する情報を参照してください。

OS管理は、Database Cloud Serviceインスタンスの更新の管理にも使用できません。DBシステムの更新の詳細は、DBシステムの更新を参照してください。

この問題への直接リンク: ManagedCompartmentForPaaSコンパートメントで見つかったインスタンスでOS管理サービスを使用できません

UEK R6のソフトウェア・ソースがデフォルトでアタッチされていません

詳細: 2020年10月に起動されたOracle Linux 7プラットフォーム・イメージ以降、Unbreakable Enterprise Kernelリリース6 (UEK R6)がOracle Linux 7インスタンスのデフォルト・カーネルになります。ただし、OS管理サービスは、これらのイメージのソフトウェア・ソースとしてUnbreakable Enterprise Kernelリリース5 (UEK R5)をアタッチします。その結果、インスタンスで使用可能なすべての更新を受信するわけではありません。

回避策:パッケージの更新を適用するには、UEK R6ソフトウェア・ソースをアタッチします。

この問題への直接リンク: UEK R6のソフトウェア・ソースがデフォルトでアタッチされない

サード・パーティ・ソフトウェア・リポジトリを使用してパッケージをインストールすると、Oracle CloudエージェントのOS管理サービス・エージェント・プラグインが失敗します

詳細: Python Package Index (PyPI)などのサードパーティ・ソフトウェア・リポジトリからパッケージをインストールすると、OS管理サービス・エージェント・プラグインのパッケージ依存性要件など、基礎となるプラットフォーム配布に必要なパッケージが上書きされる場合があります。

回避策:システム依存性が上書きされないようにするには、Python開発作業に仮想環境を使用します。仮想環境の詳細は、最新のPythonドキュメントを参照してください。

この問題への直接リンク:サード・パーティのソフトウェア・リポジトリを使用してパッケージをインストールすると、Oracle CloudエージェントのOS管理サービス・エージェント・プラグインが失敗します。

レジストリ

2019年9月30日以前に、イメージ・タグおよびDockerログイン資格証明にテナンシ名ではなくテナンシ・ネームスペースを使用します

詳細:これまで、Oracle Cloud Infrastructure Registryにログインするとき、およびコンテナ・レジストリのイメージに対して操作を実行するときは、テナンシ名またはテナンシ・ネームスペースのいずれかを使用することができました。

2019年9月30日より後は、Oracle Cloud Infrastructure Registryの使用時にテナンシ名ではなくテナンシ・ネームスペースを使用する必要があります。

背景: 2019年9月30日より後は、次のことができなくなります:

  • Oracle Cloud Infrastructure Registryにログインするときにテナンシ名を指定します。
  • リポジトリ・パスにテナンシ名を含むイメージに対する操作を実行します。

かわりに、Oracle Cloud Infrastructure Registryの使用時にテナンシ名ではなくテナンシ・ネームスペースを使用する必要があります。

テナンシ・ネームスペースは、自動生成された英数字の不変ランダム文字列です。たとえば、acme-devテナンシのネームスペースはansh81vru1zpです。テナンシ・ネームスペースは、コンソールの「コンテナ・レジストリ」ページで確認できます。

一部の古いテナンシでは、テナンシ・ネームスペースがテナンシ名と同じである可能性があります。その場合、処置は必要ありません。

2019年9月30日以前は、テナンシ・ネームスペースとテナンシ名が異なる場合、次が必要です:

  • Oracle Cloud Infrastructure Registryにログインするときに、テナンシ名のかわりにテナンシ・ネームスペースの指定を開始します。
  • Oracle Cloud Infrastructure Registryに新規イメージをプッシュするときに、テナンシ名のかわりにテナンシ・ネームスペースの指定を開始します。
  • パスにテナンシ名を含むOracle Cloud Infrastructure Registryの既存のイメージを移行します。

次の回避策と例での前提:

  • テナンシ名はacme-devです
  • テナンシ・ネームスペースはansh81vru1zpです
  • ユーザー名はjdoe@acme.comです

Oracle Cloud Infrastructure Registryにログインする場合の回避策: 以前は、Oracle Cloud Infrastructure Registryにログインするときに、ユーザー名を求められ、<tenancy-name>/<username>という形式で入力できました。

例:

$ docker login phx.ocir.io

Username: acme-dev/jdoe@acme.com
Password:

2019年9月30日以前に、Oracle Cloud Infrastructure Registryへのログイン時に、テナンシ名のかわりにテナンシ・ネームスペースの使用を開始する必要があります。ユーザー名を求められたら、<tenancy-namespace>/<username>という形式で入力します。

例:

$ docker login phx.ocir.io

Username: ansh81vru1zp/jdoe@acme.com
Password:

Oracle Cloud Infrastructure Registryに新規イメージをプッシュする場合の回避策: 以前は、Oracle Cloud Infrastructure Registryに新規イメージをプッシュするときに、docker pushコマンドのリポジトリ・パスの一部としてテナンシ名を指定できました。この形式でコマンドを入力できました:

$ docker push <region-key>.ocir.io/<tenancy-name>/<image-name>:<tag>

例:

$ docker push phx.ocir.io/acme-dev/helloworld:latest

2019年9月30日以前に、新規イメージのプッシュ時に、docker pushコマンドでテナンシ名のかわりにテナンシ・ネームスペースの使用を開始する必要があります。この形式でコマンドを入力します:

$ docker push <region-key>.ocir.io/<tenancy-namespace>/<image-name>:<tag>

例:

$ docker push phx.ocir.io/ansh81vru1zp/helloworld:latest

リポジトリ・パスにテナンシ名を含むOracle Cloud Infrastructure Registryの既存のイメージの回避策: 以前にOracle Cloud Infrastructure Registryにイメージをプッシュした場合、それらの既存のイメージにリポジトリ・パスの一部としてテナンシ名が含まれている可能性があります。たとえば、phx.ocir.io/acme-dev/helloworld:latestです。

2019年9月30日より後は、リポジトリ・パスにテナンシ名を含むコンテナ・レジストリの既存のイメージに対して操作を実行できなくなります。

そのため、2019年9月30日以前に、リポジトリ・パスにテナンシ名を含む既存のすべてのイメージを対象に、テナンシ名をテナンシ・ネームスペースに置き換える必要があります。

既存のイメージのリポジトリ・パスにあるテナンシ名をテナンシ・ネームスペースに置き換えるには:

  1. 次を入力してイメージをプルします:

    $ docker pull <region-key>.ocir.io/<tenancy-name>/<image-name>:<tag>

    例:

    $ docker pull phx.ocir.io/acme-dev/helloworld:latest
  2. 次を入力し、docker tagコマンドを使用してリポジトリ・パスを変更します:

    $ docker tag <region-key>.ocir.io/<tenancy-name>/<image-name>:<tag> <region-key>.ocir.io/<tenancy-namespace>/<image-name>:<tag>

    例:

    $ docker tag phx.ocir.io/acme-dev/helloworld:latest phx.ocir.io/ansh81vru1zp/helloworld:latest
  3. 次を入力し、新しいリポジトリ・パスを使用してイメージをコンテナ・レジストリにプッシュします:

    $ docker push <region-key>.ocir.io/<tenancy-namespace>/<image-name>:<tag>

    例:

    $ docker push phx.ocir.io/ansh81vru1zp/helloworld:latest
  4. リポジトリ・パスにテナンシ名を含む既存のすべてのイメージについて、前述のステップを繰り返します。

この問題への直接リンク: 2019年9月30日以前に、イメージ・タグおよびDockerログイン資格証明にテナンシ名ではなくテナンシ・ネームスペースを使用します

リソース・マネージャ

新しいスタックでは、オブジェクト・ストレージ・バケットをコンソールで使用できない場合があります

詳細: コンソールを使用してオブジェクト・ストレージのバケットからスタックを作成する場合、オブジェクト・ストレージ・バケットの値リストは、バケット・ネームスペースがテナンシ名と同じ場合にのみ使用できます。

回避策:かわりにSDK、CLIまたはAPIを使用してスタックを作成します。オラクル社では問題を認識しており、解決に取り組んでいます。

この問題への直接リンク: オブジェクト・ストレージ・バケットがコンソールで新しいスタックに使用できない場合があります

リソース検出に失敗(権限の問題)

詳細: リソース検出を使用してコンパートメントからスタックを作成すると、作業リクエストが失敗します。

考えられる原因:スタックを作成しているユーザーに、テナンシのコンパートメントを検査する権限がありません。

回避策: この問題を回避するには、スタックを作成しているユーザーにテナンシのコンパートメントを検査する権限があることを確認します。ユーザーが属するグループに対して、次のポリシーを作成します。

Allow group <group name> to inspect compartments in tenancy

この問題への直接リンク: リソース検出に失敗します

検出される一部のリソースに属性がありません

詳細: リソース検出を使用して取得された一部のサポートされているリソースに属性がありません。

サービス リソース・タイプ 欠落フィールド(oci Terraformプロバイダのドキュメントへのリンクを含む)
ビッグ・データ インスタンス

cluster_admin_password

cluster_public_key

ブロック・ボリューム(コア) ボリューム volume_backup_id
コンピュート(コア) イメージ instance_id

image_source_details

コンピュート(コア) インスタンス構成 instance_id

source

コンピュート(コア) インスタンス・コンソール接続 public_key
コンピュート(コア) インスタンス

hostname_label (非推奨)

is_pv_encryption_in_transit_enabled

subnet_id (非推奨)

コンピュート(コア) ボリューム・アタッチメント use_chap
Container Engine for Kubernetes ノード・プール node_source_details
データ・カタログ 接続 enc_properties
データベース Autonomous Container Databases maintenance_window_details
データベース Autonomous Database

admin_password

autonomous_database_backup_id

autonomous_database_id

clone_type

is_preview_version_with_service_terms_accepted

source

source_id

timestamp

データベース Autonomous Exadata Infrastructures maintenance_window_details
データベース データベース

admin_password

backup_id

backup_tde_password

db_version

source

データベース DBホーム

admin_password

backup_id

backup_tde_password

source

データベース DBシステム

admin_password

backup_id

backup_tde_password

maintenance_window_details

IAM アイデンティティ・プロバイダ metadata
ロード・バランシング ロード・バランサ ip_mode
マーケットプレイス 同意された契約 signature
ネットワーキング(コア) クロス・コネクト

far_cross_connect_or_cross_connect_group_id

near_cross_connect_or_cross_connect_group_id

NoSQLデータベース・クラウド 索引 is_if_not_exists
オブジェクト・ストレージ オブジェクト

cache_control

content

content_disposition

content_encoding

content_language

source

source_uri_details

Webアプリケーション・アクセラレーションおよびセキュリティ 証明書

certificate_data

is_trust_verification_disabled

private_key_data

Webアプリケーション・アクセラレーションおよびセキュリティ ポリシー

are_redirects_challenged

is_case_sensitive

is_nat_enabled (human_interaction_challenge)

is_nat_enabled (js_challenge)

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

この問題への直接リンク: 検出される一部のリソースに属性がありません

RESOLVED:リソース検出に失敗(アーティファクトの問題)

詳細: リソース検出を使用してコンパートメントからスタックを作成すると、作業リクエストが失敗します。

考えられる原因:リソース検出にartifacts (oci_artifacts_container_configurationタイプのリソースを含むサービス)が含まれる場合、リソース・マネージャでエラー条件が発生します。このサービスは、すべてのサービスがリソース検出用に指定されている場合に含まれます。

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

必要なサービスのリソース検出をフィルタし(ステップを参照)、artifacts (タイプoci_artifacts_container_configurationのリソースを含むサービス)を必ず省略してください。オラクル社では問題を認識しており、解決に取り組んでいます。

この問題への直接リンク:解決済:リソース検出に失敗します(アーティファクトの問題)

RESOLVED: oci:core:image:id型は移入されません

詳細: oci:core:image:id型は、イメージOCID値の予期されるドロップダウン・リストではなく、入力テキスト・フィールドとしてレンダリングされます。

回避策: この問題は解決されました。

この問題への直接リンク: RESOLVED: oci: core: image: id型は移入されません

解決済: ドリフト検出の実行中にエラーが発生します

詳細: スタックでドリフト検出を実行しようとすると、エラーが発生します。

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

この問題を回避するには、スタックを更新してリージョン変数を含めてから再試行してください。リージョン変数の例: {"region": "eu-frankfurt-1"}

この問題への直接リンク: 解決済: ドリフト検出の実行中にエラーが発生します

サービス・コネクタ・ハブ

単一の通知に複数のSMSメッセージ

詳細:単一のSMSメッセージでサポートされる最大文字数を超える通知は、分割されて複数のSMSメッセージとして送信され、請求に影響します。

この問題は、SMSサブスクリプションを含むトピックを参照する通知ターゲットを使用するサービス・コネクタにストリーミング・ソースが指定されている場合に発生します。

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

この問題への直接リンク: 単一の通知に対する複数のSMSメッセージ

ストレージ・ゲートウェイ

POSIXコンプライアンスの例外

詳細: 次のファイルからオブジェクトへの変換は、サポートされていません:

  • ACL
  • シンボリック・リンク、ハード・リンク、名前付きパイプおよび特殊デバイス
  • スティッキー・ビット

回避策: 特殊なファイルをオブジェクト・ストレージにコピーする必要がある場合は、そのファイルのtarアーカイブを作成します。

この問題への直接リンク: POSIXコンプライアンスの例外

dfコマンドで正確なサイズと容量をレポートできません

詳細: NFSクライアントのファイルシステム上でdfコマンドを実行すると、dfによりファイルシステム・サイズは0 (ゼロ)バイトで、容量は8EB (最大容量)であるとレポートされます。オブジェクト・ストレージには割当て制限がなく、データを無制限に格納できるため、ファイルシステム・サイズをレポートする方法はありません。オブジェクト・ストレージ・バケットはストレージ使用量をレポートしないため、容量をレポートする方法はありません。

回避策: duコマンドを実行して使用量を取得できますが、このコマンドはメタデータを大量に使用するため、使用量のレポートに時間がかかります。オブジェクト・ストレージ内のすべてのオブジェクトをリストし、現在のオブジェクト・ストレージ使用量を確認するためにオブジェクト・サイズを追加することもできます。ただし、この方法では、ファイルシステム・キャッシュに格納されるデータ量は考慮されません。また、ストレージ使用量を概算するアウトオブバンド・メカニズムも検討できます。

この問題への直接リンク: dfコマンドで正確なサイズと容量をレポートできません

タグ付け

タグのデフォルトの作成が、特定の条件で失敗します

詳細: 次の両方の条件が満たされる場合、タグのデフォルトの作成は失敗します: タグ・ネームスペースにアクティブなキー定義が1つのみが含まれ、かつ、タグ・ネームスペースに複数の廃止済のタグ・キー定義が含まれます。

回避策: この問題を回避するには、タグ・ネームスペースに別のタグ・キー定義を作成します。

この問題への直接リンク: タグのデフォルトの作成が、特定の条件で失敗します

タグのデフォルトの削除が、タグが廃止されている場合に失敗します

詳細: 廃止されているタグのデフォルトを削除しようとすると、エラーが発生します。

回避策: タグ定義を再アクティブ化してから、タグのデフォルトを削除します。

この問題への直接リンク: タグのデフォルトの削除が、タグが廃止されている場合に失敗します

Terraform状態がタグのデフォルトおよびセカンダリ・リソースのタグで一定しない

詳細: 一部のTerraformビルドでは、セカンダリ・リソースに対してタグが作成されず、コンパートメントに対して構成されているデフォルト・タグがリソースに自動的に適用されません。この結果、デフォルト・タグおよびプライマリ・リソースと一致するタグを持たないセカンダリ・リソースが失われる可能性があります。状況によっては、Terraformが無限ループに移行することもあります。

回避策: 潜在的なタグ付けの問題に関して、Terraformスクリプトおよびテナンシ内の各コンパートメントを評価します。

  1. Terraformスクリプトを評価します

    • タグを含むことがわかったすべてのプライマリ・リソースで、フリーフォームまたは定義済のタグをセカンダリ・リソースにコピーします。たとえば、Terraform構成にコンピュート・インスタンスなどのプライマリ・リソースや、アタッチされているVNICなどのネストされたセカンダリ・リソースがある場合、コンピュート・インスタンスのタグをVNICにコピーします。VCNやインスタンス・プールも、セカンダリ・リソースを作成できるプライマリ・リソースです。

  2. 作成するテナンシのディレクトリ・ツリーを評価します

    1. ルート・コンパートメントから開始し、コンパートメントにデフォルト・タグが構成されているかどうかを確認します。タグ値はオプションですが、タグのデフォルトでは、タグに値が必須であることを指定できます。

    2. タグのデフォルトは特定のコンパートメントに対して定義されます。コンソールでは、コンパートメントの詳細ページで管理します。

      このスクリーンショットは、コンソールの「コンパートメントの詳細」ページを示しています

    3. コンパートメントに、そのコンパートメントで作成されたリソースに対するデフォルト・タグが含まれる場合は、それらのデフォルトで作成されるタグおよび必須のタグ値を、Terraformスクリプトで作成するすべてのリソースに適用します。タグ継承のため、デフォルト・タグは、コンパートメントで作成されるすべてのリソース(子コンパートメントおよび子コンパートメントで作成されるリソースを含む)に適用されます。タグ継承を参照してください。
    4. すべての子コンパートメントに対してこれらのステップを繰り返し、デフォルト・タグを考慮するようにTerraformスクリプトを更新します。

この問題への直接リンク: Terraform状態がタグのデフォルトおよびセカンダリ・リソースのタグで一定しない

トラフィック管理ステアリング・ポリシー

現在、トラフィック管理ステアリング・ポリシーの既知の問題はありません。

ボールト

現在、ボールト・サービスの既知の問題はありません。

Webアプリケーション・ファイアウォール(WAF)

APIで作成されたWAFポリシーにデフォルトのオリジンを追加できません

詳細: APIを使用してWAFポリシーを作成する場合、デフォルトの起点を指定しないと、後でコンソールまたはAPIを使用してデフォルトの起点を追加できません。この問題は、コンソールを使用して作成されたポリシーには適用されません。

回避策:デフォルトの起点なしで作成されたポリシーを削除し、デフォルトの起点を指定して新しいポリシーを作成します。

この問題への直接リンク: APIで作成されたWAFポリシーにデフォルト・オリジンを追加できません

TLSバージョンTLS_V1およびTLS_V1_1は非推奨になりました

詳細: TLSバージョンTLS_V1およびTLS_V1_1は非推奨であり、ポリシー構成では使用できません。これらのバージョンを使用すると、検証が行われる場合があります。

回避策:この問題を回避するには、バージョンTLS_V1_2またはTLS_V1_3、あるいはその両方を使用するようにポリシー構成を更新します。

この問題への直接リンク: TLSバージョンTLS_V1およびTLS_V1_1は非推奨になりました

グローバルDNSの変更により、新しいサブネットがホワイトリストにない場合、サービスが中断されます

詳細: 2019年12月から始まるすべてのOracle Web Application Firewall (WAF)の顧客に対して、グローバルDNSの変更が行われます。オリジン・ロックダウン(明示的なIPホワイトリストの使用)があり、新しいサブネットをホワイトリストに登録しないすべての顧客に対して、停止時間とサービス低下が発生します。

回避策: (アクションが必要)お客様は、サービスの中断を回避するために新しいサブネットをホワイトリストに登録する必要があります。APIドキュメントは、ListEdgeSubnetsを参照してください。

OCI WAF拡張ホワイトリスト

130.35.0.0/20

130.35.128.0/20

130.35.240.0/20

138.1.32.0/21

138.1.128.0/19

147.154.96.0/19

192.29.96.0/20

130.35.16.0/20

130.35.48.0/20

130.35.64.0/19

130.35.96.0/20

130.35.120.0/21

130.35.144.0/20

130.35.176.0/20

130.35.192.0/19

130.35.224.0/22

130.35.232.0/21

138.1.48.0/21

147.154.0.0/18

147.154.64.0/20

147.154.80.0/21

130.35.112.0/22

138.1.16.0/20

138.1.80.0/20

138.1.208.0/20

138.1.224.0/19

147.154.224.0/19

138.1.0.0/20

138.1.40.0/21

138.1.64.0/20

138.1.96.0/21

138.1.104.0/22

138.1.160.0/19

138.1.192.0/20

147.154.128.0/18

147.154.192.0/20

147.154.208.0/21

192.29.0.0/20

192.29.64.0/20

192.29.128.0/21

192.29.144.0/21

192.29.16.0/21

192.29.32.0/21

192.29.48.0/21

192.29.56.0/21

この問題への直接リンク: グローバルDNSの変更により、新しいサブネットがホワイトリストにない場合、サービスが中断されます