既知の問題

この記事では、ベース・データベース・サービスの既知の問題について説明します。

ベース・データベース・サービスでは、次の既知の問題が識別されます。

関連項目

新規データベース内の既存のプラガブル・データベース

Details

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

回避策

なし。

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

Details

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

回避策

SQL*Plusを使用して、プライマリ・データベースでのPDBの作成またはクローニングを行うことができ、これらは後でOCI Consoleで同期されます。

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

Details

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

回避策

解決に向けて取り組んでいます。

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

Details

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

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

回避策

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

  1. 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.

  2. Oracle Database Cloud Backup Moduleを更新します:

    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を使用したオブジェクト・ストレージへのバックアップは、証明書の変更により失敗します。

Details

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

回避策

RMANのログ・ファイルで、リストされたエラー・メッセージを確認します。見つかった場合は、oracleユーザーとしてホストにログオンし、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 Moduleの詳細は、Oracle Database Backup Cloud Serviceの使用を参照してください。

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

Details

2018年10月18日にリリースされたSDKには、データベース・バックアップAPIのデータベース・サイズおよびデータベース・エディション属性に対するコードブレイクの変更が導入されています。

回避策

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

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

Details

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

回避策

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

次のステップを実行して、Oracle Database Cloud Backup Moduleをインストールします。

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

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

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

  2. Oracle Database Cloud Backup ModuleからOracle Database Cloud Backup Moduleをダウンロードします。
  3. opc_installer.zipの内容をターゲット・ディレクトリ(例: /home/opc)に抽出します
  4. テナンシで、一時ユーザーを作成し、テナンシのオブジェクト・ストレージにアクセスする権限をユーザーに付与します。
  5. この一時ユーザーの場合は、認証トークンを作成し、パスワードをノートにとります。認証トークンの作成の詳細は、ユーザー資格証明の管理を参照してください。

    ノート:

    Swiftパスワードは「承認トークン」と呼ばれるようになりました。

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

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

    正しいリージョンを決定するには、オブジェクト・ストレージの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を指定する必要があります。

プロセス・クラッシュのために管理対象自動バックアップがVM.Standard1.1シェイプで失敗します

Details

VM.Standard1.1シェイプを実行しているホスト・マシンのメモリー制限によって、Oracle Cloud Infrastructureで管理される自動データベース・バックアップ・ジョブ(OCIコンソールまたは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

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

Details

High PerformanceおよびExtreme Performance DBシステムでは、圧縮またはパラレル化(あるいはその両方)を使用するData Pumpユーティリティ操作が失敗し、エラーORA-00439: 機能が有効になっていません。この問題は、データベース・バージョン12.1.0.2.161018および12.1.0.2.170117に影響します。

回避策

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

ノート:

データベース・ホームにあるデータベースのバージョンを確認するには、$ORACLE_HOME/OPatch/opatch lspatchesをoracleユーザーとして実行するか、dbcli list-dbhomesをrootユーザーとして実行します。

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

Details

適切な権限が自動的に適用されなかったため、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. walletディレクトリの場所を取得します。次のコマンド出力のmy_wallet_directoryの値です。 

    [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ユーザーに切り替えて、walletディレクトリに変更します。 

    [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

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

Details

OCIコンソールは、dbaasapiおよびdbaascliユーティリティを使用して作成および管理されるデータベースに関する情報を同期して表示します。ただし、Data Guardが構成されているデータベースの場合、次の条件下で正しい情報がOCIコンソールに表示されません:

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

回避策

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

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

Details

これは、バンドル・パッチなしでOracle Grid Infrastructure (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;

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

      Query 1 Results
NAME                           VOTING_FILE
------------------------------ ---------------
DBFSC3_CD_02_SLCLCX0788        Y
DBFSC3_CD_09_SLCLCX0787        Y
DBFSC3_CD_04_SLCLCX0786        Y

Query 2 Results
NAME                           COUNT(*)
------------------------------ ---------------
DBFSC3_CD_02_SLCLCX0788        8
DBFSC3_CD_09_SLCLCX0787        8
DBFSC3_CD_04_SLCLCX0786        8

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

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

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

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

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

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

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

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

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

    ノート:

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

    crsctl start crs -excl

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

DBシステム・ストレージのスケーリングの失敗

Details

1つの操作で10,240GB未満の値から10,240GBを超える値にスケーリングしようとすると、スケーリング操作は失敗する可能性があります。

回避策

通常のデータ・ストレージまたはリカバリ領域(RECO)ストレージを10,240GB (10TB)未満の値から10,240GBを超える値にスケーリングする場合は、2つの操作でスケーリングを実行します。最初に、システムを10,240GBにスケーリングします。この最初のスケーリング操作が完了し、システムが「使用可能」な状態になったら、2番目のスケーリング操作を実行して、10,240GBを超えるターゲット・ストレージ値を指定します。

DBシステム・シェイプのスケーリングに失敗しました

Details

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

回避策

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