既知の問題

次のリストに、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コマンドでサポートされていない問合せパラメータ

監査

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

ブロック・ボリューム

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

詳細: 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日より前に起動されたインスタンスには使用できません
ボリュームのクローニング中に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です

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

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

クラウド・ガード

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

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

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

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

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

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

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

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

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

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

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

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

コンピュート

継続的に負荷が高い場合、CentOS 6インスタンスはネットワーク接続を失います

詳細: CentOS 6カーネルで、継続的な高負荷状態で動作しているVMインスタンスに影響する競合状態が検出されました。このような競合が発生すると、インスタンスのネットワーク接続が失われる可能性があります。

回避策: 問題を認識しており、解決に取り組んでいます。回避策として、インスタンスで次のコマンドを実行して、カーネル・コマンドラインからirqpollを削除します:

sudo sed -i.backup 's/irqpoll//g' /etc/grub.conf /boot/efi/EFI/redhat/grub.conf

これにより、関連するファイルが変更され、元の状態のバックアップ・コピーが残ります。ファイルが変更されたら、インスタンスを再起動します。

この問題への直接リンク: 継続的に負荷が高い場合、CentOS 6インスタンスはネットワーク接続を失います

解決済: コンソールで、VM.Standard.E2シリーズとの間でのシェイプの変更が失敗します
ブート・ボリューム・アタッチメントの転送中暗号化が、イメージでサポートされていない場合に編集できます
モニタリングおよびOS管理をドメイン・コントローラで使用できません

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

回避策: 次の回避策を使用してください:

  • モニタリング・サービス: Oracle Cloud Agent NTサービス(モニタリングを含む)は、NT Service\OCAとして実行されます。services.mscを使用して、NTサービスに対して実行されているユーザーを、ドメイン・サービスまたはユーザー・アカウントを使用するように更新します。次に、ドメインのローカル・グループPerformance Monitoring Groupsにユーザーを追加します。
  • OS管理およびOracle Cloud Agentアップデータ・サービス:

    • OS管理NTサービスは、NT Service\OCAOSMSとして実行されます。services.mscを使用して、NTサービスに対して実行中のユーザーを更新し、ドメイン・サービス・アカウントまたはローカル管理権限を持つドメイン・ユーザー・アカウントを使用します。次に、ユーザーをドメインのローカル管理者グループに追加します。
    • Oracle Cloud Agent Updater NTサービスは、NT Service\OCAUとして実行されます。services.mscを使用して、NTサービスに対して実行中のユーザーを更新し、ドメイン・サービス・アカウントまたはローカル管理権限を持つドメイン・ユーザー・アカウントを使用します。次に、ユーザーをドメインのローカル管理者グループに追加します。

この問題への直接リンク: モニタリングおよびOS管理をドメイン・コントローラで使用できません

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

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

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

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

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) DenseIOインスタンスは、iSCSIにアタッチされたブート・ボリュームで起動します

詳細: 次のいずれかのシェイプを使用してインスタンスを作成する場合:

  • VM.DenseIO1.4

  • VM.DenseIO1.8

  • VM.DenseIO1.16

  • VM.DenseIO2.8

  • VM.DenseIO2.16

  • VM.DenseIO2.24

インスタンスは、準仮想化アタッチメントのかわりにブート・ボリューム用のiSCSIアタッチメントで起動します。つまり、転送中暗号化など、準仮想化ブート・ボリューム・アタッチメントを必要とする機能は使用できません。

この問題への直接リンク: 仮想マシン(VM) DenseIOインスタンスは、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を実行しているインスタンスでシステム・ハングが発生します

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

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

sudo systemctl enable iscsid && sudo systemctl start iscsid

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

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

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

回避策: UFWを使用してファイアウォール・ルールを編集しないでください。Oracle提供のイメージは、インスタンスがそのブート・ボリュームとブロック・ボリュームに発信接続できるように、ファイアウォール・ルールで事前構成されています。詳細は、「必須のファイアウォール・ルール」を参照してください。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イメージに対して機能しない場合があります
イメージのエクスポート時の無効なイメージ・エラー

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

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

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

    • BM.Standard1.36

    • BM.DenseIO1.36

    • VM.DenseIO1.4

    • VM.DenseIO1.8

    • VM.DenseIO1.16

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

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

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

CentOS 6.xインスタンスで、ext2、ext3、ext4ファイル・システムの作成時に遅延やクラッシュが発生します

詳細: CentOS 6.xインスタンス用にローカル・アタッチされたNVMeドライブでext2、ext3、ext4ファイル・システムを作成する際に、次のシェイプで遅延やクラッシュが発生します:

  • VM.DenseIO1.4
  • VM.DenseIO1.8
  • VM.DenseIO1.16
  • BM.DenseIO1.36

回避策: CentOS 6.xインスタンスでは、「詳細」にリストされているシェイプではext2、ext3、ext4ファイル・システムはサポートされていません。別のファイル・システムの使用をお薦めします。

この問題への直接リンク: CentOS 6.xインスタンスで、ext2、ext3、ext4ファイル・システムの作成時に遅延やクラッシュが発生します

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

詳細: ベア・メタル・インスタンスへの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提供のイメージの表示名には、オペレーティング・システムとオペレーティング・システム・バージョンが含まれます(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の起動に失敗する可能性があります

インスタンス・プールおよびクラスタ・ネットワークは、関連するインスタンス構成またはロード・バランサに定義済のタグが含まれる場合、起動に失敗します

詳細: 定義済のタグを含むインスタンス構成からインスタンス・プールまたはクラスタ・ネットワークを起動しようとすると、インスタンスを起動できません。インスタンスの起動は、プールまたはクラスタ・ネットワーク内のインスタンスを、定義済のタグを含むロード・バランサにアタッチしようとした場合にも失敗します。インスタンスの起動に失敗すると、次のいずれかのエラー・メッセージが表示されます:

The following tag namespaces / keys are not authorized or not found: Policies not set for the tenancy.
Failed to launch instance in pool <instance_pool_OCID> because the defined tags could not be operated on.
Failed to create instance pool in cluster network <cluster_network_OCID> because the defined tags could not be operated on.
Failed to create backend in load balancer: <load_balancer_OCID> because the defined tags could not be operated on.

インスタンス構成では、これはコンピュート・サービスがプールまたはクラスタ・ネットワーク内のインスタンスに定義済のタグを伝播できないために発生します。ロード・バランサでは、これはコンピュート・サービスがインスタンスにタグを適用できないために発生します。

回避策: 問題を認識しており、解決に取り組んでいます。回避策として、コンピュート・サービスに対し、ユーザーのかわりにタグ・ネームスペースを管理する権限を付与する必要があります。次のいずれかのポリシーを追加します:

  • テナンシ内のすべてのコンパートメントでタグ・ネームスペースを使用するようにサービスに権限を付与するには:

    Allow service compute_management to use tag-namespace in tenancy
  • アクセス範囲をコンパートメントごとに縮小するには、次のステートメントを使用します:

    Allow service compute_management to use tag-namespace in compartment <compartment_name>

この問題への直接リンク: インスタンス・プールおよびクラスタ・ネットワークは、関連するインスタンス構成またはロード・バランサに定義済のタグが含まれる場合、起動に失敗します

Oracle Kspliceを使用した自動更新が一部のFastConnectネットワーキング設定で失敗します
Oracle Autonomous LinuxイメージはOS管理サービスで管理できません

詳細: Oracle Autonomous LinuxインスタンスはOS管理サービスで管理できません。

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

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

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管理サービスに欠落フラグが必要です

コンソール

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ポッドがボリュームのマウントに失敗します

データ・カタログ

大きなビジネス用語集ファイルをインポートできない

詳細: 大きな用語集をインポートすると、インポート操作が失敗します。

回避策: 問題を認識しており、解決に取り組んでいます。用語集ファイルを100用語未満の小さいファイルに分割し、各ファイルをデータ・カタログにインポートします。

この問題への直接リンク: 大きなビジネス用語集ファイルをインポートできない

用語集のエクスポート時にリッチテキスト書式が失われる

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

回避策: 問題を認識しており、解決に取り組んでいます。エクスポートしたファイルに必要な書式を手動で適用します。

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

大規模なデータ・アセットの部分的な削除

詳細: データ・エンティティの数が多いデータ・アセットを削除すると、エラー通知が発行されます。

回避策: 問題を認識しており、解決に取り組んでいます。正常に削除されたという通知を受信するまで、削除操作を再試行してください。

この問題への直接リンク: 大規模なデータ・アセットの部分的な削除

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

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

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

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

解決済: データ・アセットの増分収集に関する問題

詳細: データ・アセットの収集に増分収集オプションを使用すると、特定のデータ・エンティティ、特にExcelファイル・ソースに対して正しく機能しません。さらに、データ・アセットを再収集する際に、データ・ソースで削除されたデータ・エンティティがデータ・カタログにまだ存在します。

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

この問題への直接リンク: データ・アセットの増分収集に関する問題

データ・フロー

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

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

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

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

ログ出力(特にドライバやエグゼキュータのログ)は、実行が完了してからデータ・フロー・コンソールに表示されるまで約12分かかります。

詳細: アプリケーションの各実行では、出力ログのセット(stdoutやstderrなどのアプリケーション・ログ、およびSparkドライバやエグゼキュータのログなどの診断ログ)が生成されます。アプリケーション・ログはデータ・フロー・コンソールですぐに使用できますが、診断ログが表示されるまで最大12分かかる可能性があります。

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

この問題への直接リンク: ログ出力(特にドライバやエグゼキュータのログ)は、実行が完了してからデータ・フロー・コンソールに表示されるまで約12分かかる。

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

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

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

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

データ統合

エラー・メッセージに、オペレータのデータ・エンティティの問題として、停止したデータベースが原因で統合タスクが失敗したことが誤って示されます: SOURCE_1。

詳細: データベースが停止しているため、統合タスクが失敗しましたが、エラー・メッセージが次のように誤って通知されます:

There was as an issue with the data entity for operator: SOURCE_1. Either no data entity was selected, or you no longer have access to the selected data entity, connection, schema, or data asset. Check the operator or data asset details.

回避策: 問題を認識しており、解決に取り組んでいます。このエラー・メッセージが表示されないようにするには、データベースを確認し、必要に応じて再起動します。

この問題への直接リンク:エラー・メッセージに、オペレータのデータ・エンティティの問題として、停止したデータベースが原因で統合タスクが失敗したことが誤って示されます: SOURCE_1。

regexが一致しない抽出変換によって生成されたノードでは、データ・エクスプローラに空白値が表示されます。

詳細: すべてのレコードに一致しない正規表現を使用してオブジェクト・ストレージ・データ・アセットに対して抽出変換を実行すると、結果の式演算子/ノードのデータ・エクスプローラに結果が空白値として表示されます。

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

この問題への直接リンク: regexが一致しない抽出変換によって生成されたノードでは、データ・エクスプローラに空白値が表示されます。

無効なデータ・アセットが原因で失敗した統合タスクのログが表示されません。

詳細: データ・アセットに無効なホストが入力され、そのデータ・アセットがデータ・フローで使用されている場合、データ・フローに関連付けられた統合タスクは実行時に失敗します。タスク実行の「ログ・メッセージ」パネルには、次のエラー・メッセージが表示されます:

Cannot find the schema with name <schema_name> using connection DI Object <connection_name_uid_details>.
No logs available.

回避策: 正しいデータ・アセットおよび接続詳細が指定されていることを確認して、このスキーマが存在することを確認します。オラクル社では問題を認識しており、解決に取り組んでいます。

この問題への直接リンク: 無効なデータ・アセットが原因で失敗した統合タスクのログが表示されません。

挿入レコードの数は、Oracle Database、Autonomous Transaction ProcessingおよびAutonomous Data Warehouseのタスク実行表に0 (ゼロ)と表示されます。

詳細: Oracle DatabaseAutonomous Transaction ProcessingおよびAutonomous Data Warehouseの場合、挿入レコードが存在する場合でも、タスク実行表の「挿入」列にゼロが表示されます。

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

この問題への直接リンク: 挿入レコードの数は、Oracle DatabaseAutonomous Transaction ProcessingおよびAutonomous Data Warehouseのタスク実行表に0 (ゼロ)と表示されます。

スケールと長さを指定した場合、オブジェクト・ストレージのターゲット属性は合計の移入に失敗し、結果の単純な集計値が文字制限を超えます。

詳細: オブジェクト・ストレージで単純な集計のスケールおよび長さを指定する場合、結果の合計は指定した長さおよびスケール内に収まる必要があります。合計が指定された長さおよびスケールを超えると、データ・エクスプローラにnull値が戻され、ターゲット出力に何も表示されません。

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

この問題への直接リンク: スケールと長さを指定した場合、オブジェクト・ストレージのターゲット属性は合計の移入に失敗し、結果の単純な集計値が文字制限を超えます。

データ・エクスプローラは、部分的に設計されたデータ・フローをサポートしていません。

詳細: データ・フローに2つのソース演算子のみを追加し、いずれかのソース演算子の「データ」タブをクリックすると、データ・エクスプローラに接続取得文字列エラーが表示されます。

回避策: 「データ」タブをクリックする前に、両方のソース演算子のデータ・エンティティを選択していることを確認します。オラクル社では問題を認識しており、解決に取り組んでいます。

この問題への直接リンク: データ・エクスプローラは、部分的に設計されたデータ・フローをサポートしていません。

エラー・メッセージは、タスクでサポートされていないデータ型が原因で発生した障害を、データ・エクスプローラ・データのフェッチの問題として誤って説明します。

詳細: データ・エクスプローラの使用中またはタスクの実行中に、サポートされていないデータ型を使用するデータ・エンティティを選択すると、エラー・メッセージにデータ・エクスプローラ・データのフェッチの問題として誤って表示されます。次に示すOracle Databaseデータ型はサポートされません:

  • ROWID
  • UROWID
  • BFILE
  • TIMESTAMP WITH LOCAL TIMEZONE
  • INTERVAL DAY TO SECOND
  • INTERVAL YEAR TO MONTH
  • XMLTYPE
  • SDO_GEOMETRY

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

この問題への直接リンク: エラー・メッセージは、タスクでサポートされていないデータ型が原因で発生した障害を、データ・エクスプローラ・データのフェッチの問題として誤って説明します。

null値を含む1つ以上の属性を使用する場合、属性のマージ変換の適用後にデリミタ値のみが表示されます。

詳細: Oracleデータベースをソースとしてデータ・フローまたはデータ・ローダー・タスクを作成するとします。属性のマージ変換は、1つ以上の属性(null値がある少なくとも1つの属性と、null以外の値がある他の属性)に対して実行します。結果には、指定されたデリミタのみが含まれ、値は含まれません。

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

この問題への直接リンク: null値を含む1つ以上の属性を使用する場合、属性のマージ変換の適用後にデリミタ値のみが表示されます。

「データ」タブの表示中に「プロパティ」パネルを展開すると、データ・エクスプローラは元のサイズのままになります。

詳細: 「データ」タブの表示中に「プロパティ」パネルを展開した場合、データ・エクスプローラは一緒に展開されません。行数は同じままで、他の行を参照するための垂直スクロールバーが表示されます。

回避策: パネル・グリッド全体を表示するには、Chromeまたは新しいバージョンのFirefox (69より新しい)を使用します。古いバージョンのFirefox (69より古い)を使用している場合は、「プロパティ」パネルで列をクリックし、別のタブに移動してから戻ります。オラクル社では問題を認識しており、解決に取り組んでいます。

この問題への直接リンク: 「データ」タブの表示中に「プロパティ」パネルを展開すると、データ・エクスプローラは元のサイズのままになります。

キーを指定せずにREST APIを使用してタスク実行を作成すると、内部エラーが発生します。

詳細: REST APIを使用してタスク実行を作成する場合、そのタスク実行のキーを指定していないと内部エラーが生成されます。

回避策: REST APIを使用してタスク実行を作成する場合は、必ずキーを指定してください。オラクル社では問題を認識しており、解決に取り組んでいます。

この問題への直接リンク: キーを指定せずにREST APIを使用してタスク実行を作成すると、内部エラーが発生します。

データ・サイエンス

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

データベース

すべてのDBシステム

ライセンス・タイプ変更時の請求の問題

詳細: 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バンドルにアップグレードする必要があります。

    exadbcpatchmultiユーティリティを使用してExadata DBシステムでOracle Grid InfrastructureおよびOracle Databaseのパッチ適用操作を実行する方法の詳細は、手動によるExadata DBシステムへのパッチ適用を参照してください。

この問題への直接リンク: 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 DBシステムでのツールの更新」を参照してください。
  • 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 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

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

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

イベント

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

ファイル・ストレージ

ファイル・ストレージは現在アクセス制御リスト(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エラーが発生します

ファンクション

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

ヘルス・チェック

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

IAM

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

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

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

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

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

詳細: 削除したコンパートメントが、テナンシのコンパートメント・サービス制限に対して引き続きカウントされます。削除したコンパートメントは、「監査保持期間」の設定で指定された日数(90-365日)の経過後にカウントから除外されます。これは、削除したコンパートメントの期間をコンソールに引き続き表示するように指定する設定でもあります。

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

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

ロード・バランシング

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

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

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

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

ログ・アナリティクス

大きいフォルダのログをモニターする場合の特別な処理

詳細: 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フォルダのパスに置き換えます。

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

管理エージェント

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

マーケットプレイス

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

モニタリング

現在、モニタリングの既知の問題はありません。

ネットワーキング

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ベンダーの指定

解決済: VPN接続: 米国西部(アッシュバーン)でのNAT-Tのサポート
VPN接続: いくつかのモニタリング・チャートのデータが正しくありません

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

まとめると、これらがVPN接続トンネルの参照可能なモニタリング・チャートです:

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

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

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

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

解決済: VPN接続: リージョナルNAT-Tの可用性とLibreswanの問題

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

  • 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サービスからサービス・ゲートウェイを介してパブリック・インスタンスにアクセスする場合の問題

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

詳細: コンソールを使用して、サービス・ゲートウェイをターゲットとして使用するルート・ルールを設定する場合、ルールの宛先サービスは、そのゲートウェイに対して有効なサービス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サーバーの更新されたリストを取得しません

通知

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

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

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

OS管理

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

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

回避策: 問題を認識しており、解決に取り組んでいます。「その他」に分類された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更新プログラムの相違

ソフトウェア・ソースがコンソールに最初にロードされるまで数分かかることがある
ManagedCompartmentForPaaSコンパートメントで見つかったインスタンスでOS管理サービスを使用できません

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

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

レジストリ

レジストリAPIが使用できません

詳細: リポジトリを作成および管理するためのレジストリ機能は、APIで公開されません。

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

この問題への直接リンク: レジストリAPIが使用できません

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ログイン資格証明にテナンシ名ではなくテナンシ・ネームスペースを使用します

リソース・マネージャ

oci:core:image:id型は移入されません

詳細: oci:core:image:id型は、イメージOCID値の予期されるドロップダウン・リストではなく、入力テキスト・フィールドとしてレンダリングされます。

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

この問題への直接リンク: oci:core:image:id型は移入されません

リソース検出に失敗します

詳細: リソース検出を使用してコンパートメントからスタックを作成すると、作業リクエストが失敗します。

回避策: この問題を回避するには、スタックを作成しているユーザーにテナンシのコンパートメントを検査する権限があることを確認します。ユーザーが属するグループに対して、次のポリシーを作成します。

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)

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

この問題への直接リンク: 検出される一部のリソースに属性がありません

解決済: ドリフト検出の実行中にエラーが発生します

詳細: スタックでドリフト検出を実行しようとすると、エラーが発生します。

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

この問題を回避するには、スタックを更新してリージョン変数を含めてから再試行してください。リージョン変数の例: {"region": "eu-frankfurt-1"}

この問題への直接リンク: 解決済: ドリフト検出の実行中にエラーが発生します

サービス・コネクタ・ハブ

現在、サービス・コネクタ・ハブの既知の問題はありません。

ストレージ・ゲートウェイ

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)

グローバル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の変更により、新しいサブネットがホワイトリストにない場合、サービスが中断されます