既知の問題

次のリストに、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サーバーを継承しない

アプリケーション・パフォーマンス・モニタリング

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

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

回避策: 問題を認識しており、解決に取り組んでいます。スクリプト化ブラウザ・モニターの場合、.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リソース・タグに基づく認可ポリシーに関する問題

アーティファクト・レジストリ

アーティファクト・レジストリの既知の問題は、既知の問題を参照してください。

監査

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

Automated CEMLI Execution

Automated CEMLI Executionの既知の問題は、既知の問題を参照してください。

要塞

要塞の既知の問題は、既知の問題を参照してください。

ビッグ・データ

ビッグ・データ・サービスの既知の問題は、既知の問題を参照してください。

ブロック・ボリューム

顧客管理キーで暗号化されたボリュームで、リージョン間レプリケーションがサポートされない

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-IsMultipathEnabled $True

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

bootVolumeSizeInGBs属性がnullです

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

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

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

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

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

証明書

証明書の既知の問題は、既知の問題を参照してください。

クラシック移行

クラシック移行サービスの既知の問題は、既知の問題を参照してください。

コンピュートCloud@Customer

Compute Cloud@Customerの既知の問題は、既知の問題を参照してください。

コンソール

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

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)による問題の解決

externalTrafficPolicy: Localを使用するLoadBalancerサービスを介したトラフィックのソース・クライアントIPが保持されない

詳細: VCNネイティブ・ポッド・ネットワークを使用している場合、ポッドへのインバウンド・リクエストのソース・クライアントIPアドレスが予想どおりに保持されないことがあります。かわりに、マニフェスト・ファイルでexternalTrafficPolicy: Localが設定されているLoadBalancerタイプのKubernetesサービスを介して受信したインバウンド・リクエストは、ワーカー・ノードのIPアドレスから送信されたものとして表示される場合があります。

回避策: マニフェスト・ファイルにoci.oraclecloud.com/load-balancer-type: "lb"注釈があるLoadBalancerタイプのKubernetesサービスを介して受信したインバウンドTCPリクエストの場合、X-Forwarded-ForまたはX-Real-IPヘッダーからソース・クライアントIPアドレスを取得します。

この問題への直接リンク: externalTrafficPolicy: Localを使用するLoadBalancerサービスを介したトラフィックのソース・クライアントIPが保持されない

ベア・メタル・インスタンスでのポッド・ネットワーク接続の問題

詳細: VCNネイティブ・ポッド・ネットワークを使用している場合、クラスタ内の1つ以上のノード・プールのワーカー・ノードにベア・メタル・シェイプを指定すると、ポッドはネットワーク経由で通信できない可能性があります。

回避策: VCNネイティブ・ポッド・ネットワークを使用している場合、クラスタ内のすべてのノード・プールのワーカー・ノードにVMシェイプを指定します。

この問題への直接リンク: ベア・メタル・インスタンスでのポッド・ネットワーク接続の問題

フレキシブル・シェイプのノード当たりの最大ポッド数の制限が正しくない

詳細: VCNネイティブ・ポッド・ネットワークを使用している場合、ノード・プールに選択したフレキシブル・シェイプに指定したOCPUの数に関係なく、ノード・プールのワーカー・ノード当たりのポッドの最大数は31に制限されることがあります。

回避策: ノード・プールのワーカー・ノード当たり31個を超えるポッドが必要な場合は、ノード・プールのワーカー・ノードに別のシェイプを選択します。

この問題への直接リンク: フレキシブル・シェイプのノード当たりの最大ポッド数の制限が正しくない

CIDRブロックが追加されたVCNでのポッド・ネットワーク接続の問題

詳細: VCNネイティブ・ポッド・ネットワークを使用している場合、VCNに指定された最初のCIDRブロック外のCIDRブロックを持つポッド・サブネットに接続されているワーカー・ノードで実行されているポッドは、Kubernetesサービスと通信できない可能性があります。

回避策: VCNに指定された最初のCIDRブロック内にCIDRブロックを持つポッド・サブネットを作成します。

この問題への直接リンク: CIDRブロックが追加されたVCNでのポッド・ネットワーク接続の問題

Node Doctorスクリプトで、FileNotFoundError: [Errno 2] exceptionと表示されます

詳細: Node Doctorスクリプトを使用してノードの問題をトラブルシューティングする場合、スクリプトに次のような例外エラー・メッセージが表示されることがあります:

FileNotFoundError: [Errno 2] No such file or directory: ’/home/opc/vendor/pip…

Node Doctorスクリプトは引き続き実行され、メッセージGenerating node doctor bundleが表示されてトラブルシューティング出力が生成されます。

回避策: 問題を認識しており、解決に取り組んでいます。その間、Node DoctorスクリプトでメッセージGenerating node doctor bundleが表示される場合は、トラブルシューティング出力がまだ有効であることに注意してください。

Node DoctorスクリプトでFileNotFoundError: [Errno 2]...例外エラー・メッセージが表示されないようにする場合は、次のように入力してNode Doctorスクリプトを更新します:

node-doctor.sh --update

Node Doctorスクリプトとその更新方法の詳細は、Node Doctorスクリプトを使用したKubernetesクラスタのノード問題のトラブルシューティングを参照してください。

この問題への直接リンク: Node Doctorスクリプトで、FileNotFoundError: [Errno 2] exceptionと表示されます

解決済: VCNネイティブ・ポッド・ネットワーキングを使用するクラスタでDNS解決が失敗することがある

詳細: クラスタでVCNネイティブ・ポッド・ネットワーキングが使用され、ワークロード・ポッドとCoreDNSポッドの両方が同じワーカー・ノードで実行されている場合、トラフィックが誤ってNATedであるため、DNS解決が失敗することがあります。

解決策: 2023年3月21日に、この問題を解決したOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインの更新がリリースされました。OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインの更新の手順に従って、更新をデプロイします。

この問題への直接リンク: 解決済: VCNネイティブ・ポッド・ネットワーキングを使用するクラスタでDNS解決が失敗することがある

RESOLVED: VCNネイティブ・ポッド・ネットワーキングを使用するクラスタで、Oracle Linux 8を実行しているワーカー・ノードでのポッドの起動に失敗することがある

詳細: クラスタがVCNネイティブ・ポッド・ネットワーキングを使用し、ワーカー・ノードがOracle Linux 8 (OL8)を実行している場合、ワーカー・ノードの1つでポッドの起動に失敗することがあります。この問題の特性は次のとおりです:

  • ワーカー・ノードがOL8イメージを実行しています。
  • ホスト・ネットワーク関連のポッドはワーカー・ノードで予期したとおりに実行されますが、他のすべてのポッドは起動に失敗します。
  • crictlログには、メッセージAdding address to IPVLAN parent device (IPアドレスがワーカー・ノードのセカンダリVNICにアタッチされていることを示す)が含まれ、その後にエラー・メッセージError adding secondary VNIC IPが続きます。
  • ワーカー・ノードでLinux IP addressコマンドを実行すると、1つ(または複数)のセカンダリVNICにIPアドレスがアタッチされていないことが示されます。
  • その他すべて(またはほとんど)のワーカー・ノードは期待どおりに動作しています。

この問題で特定される可能性の高い原因は、ネットワーク・デバイスおよび接続を管理するNetworkManagerに関連しています。場合によっては、NetworkManagerによって、1つ以上のワーカー・ノードのセカンダリVNICにアタッチされているIPアドレスがデタッチされ、OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインが失敗します。

解決策: 2023年3月21日に、この問題を解決したOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインの更新がリリースされました。OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインの更新の手順に従って、更新をデプロイします。

この問題への直接リンク: 解決済: VCNネイティブ・ポッド・ネットワーキングを使用するクラスタで、Oracle Linux 8を実行しているワーカー・ノードでのポッドの起動に失敗することがある

Oracle Linux 8.7またはOracle Linux 8.8をKubernetesバージョン1.24.1、1.25.4または1.26.2で実行すると、ワーカー・ノードのステータスが予期せずNotReadyに変わります

詳細:ノード・プールにOracle Linux 8.7またはOracle Linux 8.8を指定した場合(Oracle Linux 8.7またはOracle Linux 8.8プラットフォーム・イメージ、またはOracle Linux 8.7またはOracle Linux 8.8上に構築されたOKEワーカー・ノード・イメージを選択)、ノード・プールのワーカー・ノードのステータスが予期せずNotReadyに変更される可能性があります。この問題の特性は次のとおりです:

  • ワーカー・ノードでは、Oracle Linux 8.7またはOracle Linux 8.8が実行されています。
  • ワーカー・ノードでは、Kubernetesバージョン1.24.1、1.25.4または1.26.2が実行されています。(Kubernetesバージョン1.25.12、1.26.7および1.27を実行しているワーカー・ノードは影響を受けません。)
  • 存続期間の短いポッドはワーカー・ノードに頻繁にデプロイされます。
  • ノード・プールのワーカー・ノードにデプロイされたポッドは、予想より長くContainerCreatingステータスのままになることもあります。

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

その間に、この問題が発生した場合は、次の回避策のうち要件に最も適したものを使用してください:

  • ノード・プールのOracle Linux 7イメージを指定します。
  • ノード・プールのOracle Linux 8.6イメージ(または以前のOracle Linux 8イメージ)を指定します。
  • ノード・プールの新しいバージョンのKubernetesを指定します。(Kubernetesバージョン1.25.12、1.26.7および1.27を実行しているワーカー・ノードは影響を受けません。)

コンソールに表示されなくなったイメージのOCIDを取得するには:

この問題への直接リンク: Kubernetesバージョン1.24.1、1.25.4または1.26.2でOracle Linux 8.7またはOracle Linux 8.8を実行している場合、ワーカー・ノードのステータスがNotReadyに予期せず変化します

VCNネイティブのポッド・ネットワーキングを使用したクラスタでの新規ワーカー・ノードのプロビジョニングに予想よりも時間がかかる

詳細: VCNネイティブのポッド・ネットワーキングを使用する2023年6月26日より前に作成されたクラスタでは、新しいワーカー・ノードのプロビジョニングに遅延が表示される場合があります。

OCI VCN-Native Pod Networking CNIプラグインを使用してワーカー・ノードをブートストラップする場合、Container Engine for Kubernetesは、各コンピュート・インスタンスにKubernetesカスタム・リソース(NativePodNetworkまたはNPN、リソース)をデプロイします。ワーカー・ノードが正常にブートストラップされると、Container Engine for Kubernetesによって、コンピュート・インスタンスに関連付けられたNPNリソースにSUCCESSのステータスが付与されます。

場合によっては、コンピュート・インスタンスがContainer Engine for Kubernetesが関連付けられたNPNリソースにSUCCESSのステータスを付与する前に終了した場合、NPNリソースは無期限にBACKOFFまたはIN_PROGRESSステータスのままになります。このような失効したリソースが存在すると、新しいワーカー・ノードのプロビジョニングが遅延する可能性があります。

解決:この問題は、2023-06-26の後に作成されたクラスタで修正されています。2023-06-26より前に作成されたクラスタの問題を解決するには、この項の手順に従って、1回かぎりのアクションを実行して古いリソースを削除します。

開始する前に、システムが次の前提条件を満たしていることを確認してください。

失効したリソースを次のように特定して削除します。

  1. システムがすべての前提条件を満たしていることを検証します。
    1. 次のスクリプトをpre-req-check.shという名前のファイルに保存します。
      #!/bin/bash
      echo Validating cluster access to get npn resources
      ACTIVE_RESOURCES=($(kubectl get npn -o json | jq '[.items[] | select(.status.state == "SUCCESS")]' | jq -r '.[] | .metadata.name'))
      if [[ -z "$ACTIVE_RESOURCES" ]] || [ ${#ACTIVE_RESOURCES[@]} == 0 ]
      then
        echo No active NPN resources found. Make sure you have cluster access and this is an OCI VCN-Native CNI cluster. '\'nPlease check prerequisites and retry.
        exit
      fi
       
      cr_name=${ACTIVE_RESOURCES[0]}
      echo Validating access to get compute instance
      INSTANCE_ID=$(kubectl get npn $cr_name -o json | jq -r '. | .spec.id')
      INSTANCE_STATE=$(oci compute instance get --instance-id $INSTANCE_ID | jq -r '. | .data."lifecycle-state"')
       
      if [[ -z "$INSTANCE_STATE" ]]
      then
        echo Unable to get instance details, please check prerequisites and retry.
      else
        echo All prerequisites in place, please proceed to cleaning up stale resources.
      fi
    2. 次のように入力して、pre-req-check.shスクリプトを実行します:
      sh pre-req-check.sh
  2. ステータスがSUCCESSでないために削除可能なNPNリソースを識別します。
    1. 次のように入力して、SUCCESSのステータスを持たないNPNリソースのリストを potential_stale_resources.txtという名前のテキスト・ファイルに出力します。
      kubectl get npn -o json | jq '[.items[] | select(.status.state != "SUCCESS")]' | jq -r '.[] | .metadata.name' >> potential_stale_resources.txt
    2. オプションで、次のように入力して、potential_stale_resources.txtの候補となるNPNリソースのリストを表示します。
      cat potential_stale_resources.txt

      たとえば、potential_stale_resources.txtには次のものが含まれます。

      anyhqljth4...trq
      anyhqljth4...snq
      anyhqljth4...qhq
  3. 使用できない、または終了したコンピュート・インスタンスに関連付けられている候補NPNリソースを決定することで、削除する失効したNPNリソースを特定します。
    1. 次のスクリプトをget_stale_resources.shという名前のファイルに保存します。
      #!/bin/bash
      resources=$1
      echo Reading resources from $1
      while read  -r cr_name
      do
        echo verifying NPN resource $cr_name
        INSTANCE_ID=$(kubectl get npn $cr_name -o json | jq -r '. | .spec.id')
        if [  -z $INSTANCE_ID ]
        then
          echo Unable to get npn resource details. Please check prerequisites and retry from step 2.
          exit
        fi
        echo Associated instance is $INSTANCE_ID
        INSTANCE_STATE=$(oci compute instance get --instance-id $INSTANCE_ID | jq -r '. | .data."lifecycle-state"')
        if [  -z $INSTANCE_STATE ]
        then
          # check for 404 for tombstoned instances
          STATUS=$(oci compute instance get --instance-id $INSTANCE_ID 2>&1 | tail -n +2 | jq .status)
          if [ $STATUS == 404 ]
          then
            echo 404 getting instance $INSTANCE_ID, Instance has been tombstoned. Adding resource $cr_name to stale_resources.txt '\'n
            echo $cr_name >> stale_resources.txt
          fi
        else
          echo Instance $INSTANCE_ID in $INSTANCE_STATE state
          if [ $INSTANCE_STATE == "TERMINATED" ]
          then
            echo Adding resource $cr_name to stale_resources.txt '\'n
            echo $cr_name >> stale_resources.txt
          else
            echo Instance $INSTANCE_ID not terminated. '\'nSkipping resource $cr_name '\'n
          fi
        fi
      done < $1
    2. 次のように入力して、get_stale_resources.shスクリプトを実行します:
      sh get_stale_resources.sh potential_stale_resources.txt

      get_stale_resources.shスクリプトは、削除する失効したNPNリソースを識別し、処理メッセージを画面に出力し、失効したNPNリソースの名前をstale_resources.txtという名前のファイルに書き込みます。例:

      Reading resources from potential_stale_resources.txt
      verifying NPN resource anyhqljth4...trq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...trq
      Instance ocid1.instance.oc1.phx.anyhqljth4...trq in RUNNING state
      Instance ocid1.instance.oc1.phx.anyhqljth4...trq not terminated.
      Skipping resource anyhqljth4...trq
       
      verifying NPN resource anyhqljth4...snq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...snq
      Instance ocid1.instance.oc1.phx.anyhqljth4...snq in TERMINATED state
      Adding resource anyhqljth4...snq to stale_resources
       
      verifying NPN resource anyhqljth4...qhq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...qhq
      ServiceError:
      {
          "client_version": "Oracle-PythonSDK/2.104.2, Oracle-PythonCLI/3.29.0",
          "code": "NotAuthorizedOrNotFound",
          "logging_tips": "Please run the OCI CLI command using --debug flag to find more debug information.",
          "message": "instance ocid1.instance.oc1.phx.anyhqljth4...qhq not found",
          "opc-request-id": "CCB8D1925...38ECB8",
          "operation_name": "get_instance",
          "request_endpoint": "GET https://iaas.us-phoenix-1.oraclecloud.com/20160918/instances/ocid1.instance.oc1.phx.anyhqljth4...qhq",
          "status": 404,
          "target_service": "compute",
          "timestamp": "2023-06-27T20:24:28.992241+00:00",
          "troubleshooting_tips": "See [https://docs.oracle.com/iaas/Content/API/References/apierrors.htm] for more information about resolving this error. If you are unable to resolve this issue, run this CLI command with --debug option and contact Oracle support and provide them the full error message."
      }
      404 getting instance ocid1.instance.oc1.phx.anyhqljth4...qhq, Instance has been tombstoned
      Adding resource anyhqljth4...qhq to stale_resources
    3. オプションで、次のように入力して、stale_resources.txt内の失効したNPNリソースのリストを表示します:
      cat stale_resources.txt

      たとえば、stale_resources.txtには次のものが含まれます。

      anyhqljth4...snq
      anyhqljth4...qhq
  4. stale_resources.txtファイルにリストされている失効したNPNリソースを削除します。
    1. 次のスクリプトをdelete_stale_resources.shという名前のファイルに保存します。
      #!/bin/bash
      resources=$1
      echo Reading resources from $1
      while read -r cr_name
      do
          echo Deleting $cr_name
          kubectl delete npn $cr_name
      done < $1
    2. 次のように入力して、delete_stale_resources.shスクリプトを実行します:
      sh delete_stale_resources.sh stale_resources.txt

      delete_stale_resources.shスクリプトは、stale_resources.txtファイルにリストされている失効したNPNリソースを削除し、処理メッセージを画面に出力します。例:

      Reading resources from stale_resources.txt
      Deleting anyhqljth4...snq
      nativepodnetwork.oci.oraclecloud.com "anyhqljth4...snq" deleted
  5. ハウスキーピングの適切な方法として、前に作成したstale_resources.txtおよびpotential_stale_resources.txtファイルを削除します。

この問題への直接リンク: VCNネイティブ・ポッド・ネットワーキングを使用したクラスタでの新規ワーカー・ノードのプロビジョニングには、予想よりも時間がかかります

Armプロセッサで実行するようにポッドがスケジュールされている場合、AMD64として表示される仮想ノード・アーキテクチャ

詳細:仮想ノードのArmシェイプを指定すると、ノード上でスケジュールされたポッドが、意図したとおりにArmプロセッサで実行されます。ただし、kubectl describe nodeコマンドまたはKubernetes APIを使用して仮想ノードを確認した場合、ノードでスケジュールされたポッドがArmプロセッサで実行されていても、ノードのアーキテクチャ・プロパティにはAMD64と表示されます。

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

一方、この問題が発生した場合は、仮想ノードの「アーキテクチャ」プロパティーの値を無視します。

この問題への直接リンク: Armプロセッサで実行するようにスケジュールされたポッドの場合、AMD64として表示される仮想ノード・アーキテクチャ

データ・カタログ

データ・カタログの既知の問題は、既知の問題を参照してください。

データ・フロー

データ・フローの既知の問題は、既知の問題を参照してください。

データ統合

データ統合の既知の問題は、既知の問題を参照してください。

データ・ラベリング

データ・ラベリングの既知の問題は、既知の問題を参照してください。

データ・サイエンス

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

データ転送

現在、データ転送の既知の問題はありません。

データベース

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

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

回避策: なし

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

既存のData Guard構成におけるPDB

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

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

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

Oracle Database 12c R1でファイルベースのTDEウォレットを顧客管理キーベースの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ホームでバグ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です。

Oracle Database 12c R1で顧客管理キーベースのTDEウォレットをファイルベースの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を使用して、Oracle Database 12cリリース2 (12.2.0.1)でファイルベースのTDEウォレットを顧客管理キーベースのTDEウォレットに移行すると、次のエラーで失敗します:

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

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

  1. 次のように、データベースでいずれかのAutonomous DatabaseまたはCDB$ROOTのUNDO表領域またはTEMP表領域が暗号化されているかどうかを確認します:
    CDB$ROOTから次の問合せを実行して、すべてのAutonomous Databaseに含まれているすべての暗号化された表領域をリストします:
    SQL> select tstab.con_id, tstab.name from v$tablespace tstab, v$encrypted_tablespaces enctstab where tstab.ts# = enctstab.ts# and encryptedts = 'YES';

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

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

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

    次のように、既存のUNDO表領域を暗号化解除します:
    SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

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

    TEMP表領域が暗号化されている場合
    1. 次のように、デフォルトのTEMP表領域を確認します:
      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';
      デフォルトのTEMP表領域は暗号化されていないが、他のTEMP表領域が暗号化されている場合は、次のように、他のTEMP表領域を削除します:
      SQL> drop tablespace <temp_tablespace_name>;

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

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

    2. 次のように、encrypt_new_tablespacesパラメータをDDLに設定します:
      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;
    3. 次のように、現在のTEMP表領域の仕様でTEMP表領域を作成します:
      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;
    4. 次のように、新しいTEMP表領域をデータベースのデフォルトのTEMP表領域として設定します:
      SQL> alter database default temporary tablespace <temp_tablespace_name>;
    5. 次のように、既存のTEMP表領域を削除します:
      SQL> drop tablespace <temp_tablespace_name>;

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

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

    次のように、encrypt_new_tablespacesを元の値に設定します:
    SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

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

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

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

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

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

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

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

  1. 次のように、データベースでいずれかのAutonomous DatabaseまたはCDB$ROOTのUNDO表領域またはTEMP表領域が暗号化されているかどうかを確認します:
    CDB$ROOTから次の問合せを実行して、すべてのAutonomous Databaseに含まれているすべての暗号化された表領域をリストします:
    SQL> select tstab.con_id, tstab.name from v$tablespace tstab, v$encrypted_tablespaces enctstab where tstab.ts# = enctstab.ts# and encryptedts = 'YES';

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

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

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

    次のように、既存のUNDO表領域を暗号化解除します:
    SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

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

    TEMP表領域が暗号化されている場合
    1. 次のように、デフォルトのTEMP表領域を確認します:
      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';
      デフォルトのTEMP表領域は暗号化されていないが、他のTEMP表領域が暗号化されている場合は、次のように、他のTEMP表領域を削除します:
      SQL> drop tablespace <temp_tablespace_name>;

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

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

    2. 次のように、encrypt_new_tablespacesパラメータをDDLに設定します:
      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;
    3. 次のように、現在のTEMP表領域の仕様でTEMP表領域を作成します:
      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;
    4. 次のように、新しいTEMP表領域をデータベースのデフォルトのTEMP表領域として設定します:
      SQL> alter database default temporary tablespace <temp_tablespace_name>;
    5. 次のように、既存のTEMP表領域を削除します:
      SQL> drop tablespace <temp_tablespace_name>;

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

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

    次のように、encrypt_new_tablespacesを元の値に設定します:
    SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

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

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

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

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

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

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

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

解決済: サービス・ゲートウェイでは、現在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モジュールが古い証明書をまだ参照していると、オブジェクト・ストレージへのバックアップが失敗する可能性があります。

重要

この項の適切な回避策を使用する前に、Exadata Cloud Serviceインスタンスでのツールの更新のステップに従って、dbaastools_exaの最新バージョンがシステムにインストールされていることを確認します。

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

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

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

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

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

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

ノート

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 Database Service on Dedicated InfrastructureでOracle Grid InfrastructureおよびOracle Databaseのパッチ適用操作を実行する方法の詳細は、dbaascliを使用したOracle Grid InfrastructureおよびOracle Databaseのパッチ適用を参照してください。

この問題への直接リンク: 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 Cloud Serviceでのバックアップの前提条件を参照してください。

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

  1. rootとしてノードにログオンします。
  2. 次のコマンドを実行して、エージェントをインストールします:

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

    出力例:

    [root@<node_n>~]# rpm -ivh dbcs-agent-2.5-3.x86_64.rpm
    Preparing...                ########################################### [100%]
    Checking for dbaastools_exa rpm on the system
    Current dbaastools_exa version = dbaastools_exa-1.0-1+18.1.4.1.0_180725.0000.x86_64
    dbaastools_exa version dbaastools_exa-1.0-1+18.1.4.1.0_180725.0000.x86_64 is good. Continuing with dbcs-agent installation
       1:dbcs-agent             ########################################### [100%]
    initctl: Unknown instance:
    initctl: Unknown instance:
    initzookeeper start/running, process 85821
    initdbcsagent stop/waiting
    initdbcsadmin stop/waiting
    initdbcsagent start/running, process 85833
    initdbcsadmin start/running, process 85836
    
  3. エージェントがインストールされ、実行されていることを確認します。

    [root@<node_n>~]# rpm -qa | grep dbcs-agent
    dbcs-agent-2.5-0.x86_64
    [root@<node_n>~]# initctl status initdbcsagent
    initdbcsagent start/running, process 97832
  4. 残りのノードでステップ1から3を繰り返します。

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

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

パッチ適用構成ファイルが間違ったリージョンを参照します

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

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

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

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

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

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

仮想マシンDBシステム・ストレージのスケーリング

通常のデータ・ストレージまたはリカバリ領域(RECO)ストレージを10,240GB (10TB)未満の値から10,240GBを超える値にスケーリングする場合は、2つの操作でスケーリングを実行します。最初に、システムを10,240GBにスケーリングします。この最初のスケーリング操作が完了し、システムが"使用可能"状態になったら、2番目のスケーリング操作を実行して、10,240GBを超えるターゲット・ストレージ値を指定します。1回の操作で10,240GB未満の値から10,240GBを超える値までスケーリングしようとすると、スケーリング操作に失敗する可能性があります。スケーリングの手順については、仮想マシンDBシステムのストレージのスケール・アップを参照してください。

DB_Cache_nXパラメータが0 (ゼロ)でないために仮想マシンDBシステムのシェイプのスケーリングが失敗する

詳細: より大きなシステム・シェイプを使用するように仮想マシンDBシステムをスケーリングする場合、DB_Cache_nXパラメータが0 (ゼロ)に設定されていないと、スケーリング操作が失敗します。

回避策: 仮想DBシステムをスケーリングする場合は、すべてのDB_Cache_nXパラメータ(DB_nK_CACHE_SIZEなど)が0に設定されていることを確認します。

DNS

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

ドキュメントの理解

ドキュメントの理解の既知の問題は、既知の問題を参照してください。

イベント

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

フル・スタック・ディザスタ・リカバリ

リージョン内のADをまたいでDRを実行するためのボリューム・グループ・バックアップ

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

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

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

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

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

フル・スタックDRで保護されたリソースに変更を加えると、フェイルオーバーの特定の状況で問題が発生することがある

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

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

Microsoft Windowsインスタンスのユーザー定義ステップで、ローカル・スクリプトの実行時に実行ユーザーを使用できない

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

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

Microsoft Windowsインスタンスのユーザー定義ステップで、ocarunユーザーIDでアクセスできないスクリプトを使用できない

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

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

ユーザー定義ステップを使用してローカル・スクリプトを実行する場合、フル・パスを指定しないとエラーが発生する

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

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

sh myscript.sh arg1 arg2ではなく、/bin/sh /path/to/myscript.sh arg1 arg2と指定します
OCFS2クラスタ・ノードのプライベートIPをスタンバイ・リージョンで再割当てできない場合は、クラスタ・ノードがクラスタからデタッチされます

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

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

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

DR操作後、インスタンス・アクセスに関して、コンピュート・インスタンスに正しくない情報が表示されることがある

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

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

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

DR操作後、インスタンスのブート・ボリュームに正しいイメージ情報が表示されないことがある

詳細: フル・スタックDRによってインスタンスが別のリージョンに再配置された後、ブート・ボリュームのイメージの部分に関して、インスタンスのリソース・ページに正しく表示されない場合があります。

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

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

ユーザー定義ステップでバックグラウンド・ジョブを実行するコマンドが失敗する

詳細: nohupコマンドのスリープ時間がない場合、runコマンドの実行に失敗し、ステータスが正常にレポートされません。

回避策: バックグラウンドでプロセスを開始するには、次に示すように、ラッパー・スクリプトにsleepを追加します:
nohup sh enabler.sh  &> enabler.log &
sleep 10
exit 0

ファンクション

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

統合

Integration Generation 2の既知の問題は、既知の問題を参照してください。

統合 3の既知の問題は、既知の問題を参照してください。

Java管理

Java管理サービスの既知の問題の詳細は、既知の問題を参照してください。

言語

現在、言語サービスに既知の問題はありません。

ロード・バランサ

ロード・バランサ・サービスの既知の問題は、既知の問題を参照してください。

ログ・アナリティクス

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

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

管理対象アクセス

管理対象アクセスの既知の問題は、既知の問題を参照してください。

Managed Cloud Self Serviceプラットフォーム

Managed Cloud Self Serviceプラットフォームの既知の問題は、既知の問題を参照してください。

管理エージェント

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

マーケットプレイス

マーケットプレイスの既知の問題は、既知の問題を参照してください。

メディア・フロー

メディア・フローの既知の問題は、既知の問題を参照してください。

メディア・ストリーム

メディア・ストリームの既知の問題は、既知の問題を参照してください。

ネットワーク・ロード・バランサ

ネットワーク・ロード・バランサの既知の問題は、既知の問題を参照してください。

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

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

OCIコントロール・センター

OCI Control Centerの既知の問題は、既知の問題を参照してください。

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

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

Oracle Cloud Marketplace

Oracle Cloud Marketplaceの既知の問題は、既知の問題を参照してください。

OS管理

OS管理サービスの既知の問題の詳細は、既知の問題を参照してください。

OS管理ハブ

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

Roving Edge Infrastructure

現在、Roving Edge Infrastructureの既知の問題はありません。

セキュア・デスクトップ

セキュアデスクトップの既知の問題については、Known Issuesを参照してください。

OpenSearchを使用した検索

OpenSearchを使用した検索の既知の問題は、既知の問題を参照してください。

セキュリティ・ゾーン

セキュリティ・ゾーンの既知の問題は、既知の問題を参照してください。

サービス・メッシュ

サービス・メッシュの既知の問題は、既知の問題を参照してください。

サービス・カタログ

サービス・カタログの既知の問題は、既知の問題を参照してください。

音声

現在、音声サービスに既知の問題はありません。

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

ストレージ・ゲートウェイの既知の問題は、既知の問題を参照してください。

脅威インテリジェンス

脅威インテリジェンスの既知の問題は、既知の問題を参照してください。

トラフィック管理ステアリング・ポリシー

現在、トラフィック管理の既知の問題はありません。

ボールト

現在、ボールト・サービスの既知の問題はありません。

Vision

Visionの既知の問題は、既知の問題を参照してください。

Webアプリケーション・アクセラレーション

Webアプリケーション・アクセラレーションの既知の問題は、既知の問題を参照してください。