既知の問題

この記事では、ベース・データベース・サービスの既知の問題に関する情報を提供します。

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

新規データベース内の既存のプラガブル・データベース
ライセンス・タイプ変更時の請求の問題
dbcliを使用したオブジェクト・ストレージへのバックアップは、証明書の変更のために失敗します
RMANを使用したオブジェクト・ストレージへのバックアップは、証明書の変更のために失敗します
データベース・サービスSDKの重大な変更
DBシステムで管理対象バックアップを使用できません
プロセス・クラッシュのために管理対象自動バックアップがVM.Standard 1.1シェイプで失敗します
Oracle Data Pumpの操作での「ORA-00439: 機能は有効ではありません」が返されます
1ノードのDBシステムからEM Expressコンソールに接続できません
dbaascliを使用する場合、コンソール情報がData Guard対応データベースに対して同期されない
Grid Infrastructureが、ディスクをオフラインにしてからオンラインにすると起動しません
DBシステム・ストレージのスケーリングの失敗
DBシステム・シェイプのスケーリング失敗

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

詳細:

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

回避方法:

なし。

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

詳細:

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

回避方法:

私たちは決議に取り組んでいます。

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

詳細:

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

回避方法:

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

RMANのバックアップ・ログ・ファイルで前述のエラーを確認します:

次のコマンドを実行して、失敗したバックアップ・ジョブのIDを判別します。

dbcli list-jobs

この出力例では、失敗したバックアップ・ジョブのIDは、"f59d8470-6c37-49e4-a372-4788c984ea59"です。

root@<node name> ~]# dbcli list-jobs

ID                                       Description                                                                     Created                             Status
---------------------------------------- ------------------------------------------------------------------------------- ----------------------------------- ----------
cbe852de-c0f3-4807-85e8-7523647ec78c     Authentication key update for DCS_ADMIN                                         March 30, 2018 4:10:21 AM UTC       Success
db83fdc4-5245-4307-88a7-178f8a0efa48     Provisioning service creation                                                   March 30, 2018 4:12:01 AM UTC       Success
c1511a7a-3c2e-4e42-9520-f156b1b4cf0e     SSH keys update                                                                 March 30, 2018 4:48:24 AM UTC       Success
22adf146-9779-4a2c-8682-7fd04d7520b2     SSH key delete                                                                  March 30, 2018 4:50:02 AM UTC       Success
6f2be750-9823-4ed5-b5ff-8e49f136dd22     create object store:bV0wqIaoLA4xLT4dGjOu                                        March 30, 2018 5:33:38 AM UTC       Success
0716f464-1a10-40df-a303-cadee0302b1b     create backup config:bV0wqIaoLA4xLT4dGjOu_BC                                    March 30, 2018 5:33:49 AM UTC       Success
e08b21c3-cd09-4e3a-944c-d1da96cb21d8     update database : hfdb1                                                         March 30, 2018 5:34:04 AM UTC       Success
1c3d7c58-79c3-4039-8f48-787057ce7c6e     Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname>    March 30, 2018 5:37:11 AM UTC       Success
f59d8470-6c37-49e4-a372-4788c984ea59     Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname>    March 30, 2018 5:43:45 AM UTC       Failure

失敗したジョブのIDを使用して、確認するログ・ファイルの場所を取得します。

dbcli describe-job -i <failed_job_ID>

describe-jobコマンドからの関連出力は次のようになります:

Message: DCS-10001:Internal error encountered: Failed to run Rman statement.
Refer log in Node <node_name>: /opt/oracle/dcs/log/<node_name>/rman/bkup/<db_unique_name>/rman_backup/<date>/rman_backup_<date>.log.

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

詳細:

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

回避方法:

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の重大な変更

詳細:

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

回避方法:

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

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

詳細:

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

回避方法:

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

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

DBシステムにSSHでアクセスし、opcとしてログインします
```
ssh -i <SSH_key> opc@<DB_system_IP address>
login as: opc
```
または、opc@<DB_system_hostname>を使用してログインします。
Oracle Database Cloud Backup ModuleからOracle Database Cloud Backup Moduleをダウンロードします。
opc_installer.zipの内容をターゲット・ディレクトリ(例: /home/opc)に抽出します
テナンシで、一時ユーザーを作成し、テナンシのオブジェクト・ストレージにアクセスするための権限を付与します。
この一時ユーザーの場合は、認証トークンを作成し、パスワードをノートにとります。認証トークンの作成の詳細は、ユーザー資格証明の管理を参照してください。

ノート: Swiftパスワードは「承認トークン」と呼ばれるようになりました。
次のcurlコマンドを実行して、資格証明が機能することを確認します:
```
curl -v -X HEAD -u  <user_id>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>
```
正しいリージョンを決定するには、Object StorageのFAQを参照してください。

コマンドにより、HTTP 200またはHTTP 204 No Content成功ステータス・レスポンス・コードが返されます。その他のステータス・コードは、オブジェクト・ストレージへの接続の問題を示します。
次のコマンドを実行します:
```
java -jar opc_install.jar -opcid <user_id> -opcPass '<auth_token>' -libDir <target_dir> -walletDir <target_dir> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -configFile config.txt
```
<target_dir>は、ステップ3でopc_installer.zipを抽出するディレクトリであることに注意してください。

このコマンドは、libopc.soなどのファイルをダウンロードするため、完了するまでに数分かかることがあります。コマンドが完了すると、ターゲット・ディレクトリに複数のファイル(libopc.soなど)が表示されます。
ディレクトリをターゲット・ディレクトリに変更して、lipopc.soおよびopc_install.jarファイルを/opt/oracle/oak/pkgrepos/oss/odbcsディレクトリにコピーします。
```
cp libopc.so /opt/oracle/oak/pkgrepos/oss/odbcs
```
```
cp opc_install.jar /opt/oracle/oak/pkgrepos/oss/odbcs
```
(rootとして実行するために、コピー・コマンドとともにsudoを使用することが必要な場合があります。)
次のコマンドを実行して、指定したディレクトリが存在するかどうかを確認します:
```
ls /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
```
このディレクトリが存在する場合は、次のステップを実行します:
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
```

opc_install.jarのバージョンを確認します。

java -jar /opt/oracle/oak/pkgrepos/oss/odbcs/opc_install.jar |grep -i build

/opt/oracle/dcs/commonstore/pkgrepos/oss/odbcsが存在する場合は、次のコマンドも実行します:

java -jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs/opc_install.jar |grep -i build

どちらのコマンドでも、次の出力が返されます:

Oracle Database Cloud Backup Module Install Tool, build MAIN_2017-08-16.

(オプション)一時ユーザーと、バックアップ・モジュールのインストールに使用したターゲット・ディレクトリを削除します。

手順が完了したら、Oracle Supportまたはテナント管理者に連絡して詳細な指示を確認してください。バックアップを有効にするDBシステムのOCIDを指定する必要があります。

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

詳細:

VM.Standard1.1シェイプを実行しているホスト・マシンのメモリー制限によって、Oracle Cloud Infrastructureで管理される自動データベース・バックアップ・ジョブ(OCIコンソールまたはAPIのいずれかを使用して管理されるジョブのジョブ)に障害が発生することがあります。システム・メモリー・パラメータを変更して、この問題を解決できます。

回避方法:

システムのメモリー・パラメータを次のように変更します:

オペレーティング・システムのoracleユーザーに切り替えます。
```
[opc@hostname ~]$ sudo su - oracle
```
データベース・インスタンスにログインするように環境変数を設定します。たとえば:
```
oracle@hostname ~]$ . oraenv
ORACLE_SID = [oracle] ? orcl
```

SQL*Plusを起動します。

[oracle@hostname ~]$ sqlplus / as sysdba

初期メモリー・パラメータを次のように変更します。

SQL> ALTER SYSTEM SET SGA_TARGET = 1228M scope=spfile;
SQL> ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 1228M;
SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT = 2457M;
SQL> exit

データベース・インスタンスを再起動します。

[oracle@hostname ~]$ srvctl stop database -d db_unique_name -o immediate
[oracle@hostname ~]$ srvctl start database -d db_unique_name -o open

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

詳細:

High PerformanceおよびExtreme Performance DBシステムでは、圧縮または並列性(あるいはその両方)を使用するData Pumpユーティリティ操作が失敗し、エラーORA-00439: feature not enabledが返されます。この問題は、データベース・バージョン12.1.0.2.161018および12.1.0.2.170117に影響します。

回避方法:

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

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

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

詳細:

適切な権限が自動的に適用されなかったため、1ノードのDBシステムからEM Expressコンソールに接続しようとすると、「セキュア接続が失敗しました。」と呼ばれるエラー・メッセージが表示される場合があります。

回避方法:

DBシステムのウォレット・ディレクトリに対するasmadminグループの読取り権限を追加してから、接続を再試行します。読取り権限を追加するには、次のステップを実行します。

DBシステム・ホストにSSHで接続して、opcとしてログインし、gridユーザーにsudoを実行します。

[opc@dbsysHost ~]$ sudo su - grid
[grid@dbsysHost ~]$ . oraenv
ORACLE_SID = [+ASM1] ?
The Oracle base has been set to /u01/app/grid

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))

opcユーザーに戻り、oracleユーザーに切り替え、walletディレクトリに変更します。

[opc@dbsysHost ~]$ sudo su - oracle
[oracle@dbsysHost ~]$ cd /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet

ディレクトリの内容をリストし、権限に注目します。

[oracle@dbsysHost xdb_wallet]$ ls -ltr
total 8
-rw------- 1 oracle asmadmin 3881 Apr  6 16:32 ewallet.p12
-rw------- 1 oracle asmadmin 3926 Apr  6 16:32 cwallet.sso

権限を変更します

[oracle@dbsysHost xdb_wallet]$ chmod 640 /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet/*

読取り権限が追加されたことを確認します。

[oracle@dbsysHost xdb_wallet]$ ls -ltr
total 8
-rw-r----- 1 oracle asmadmin 3881 Apr  6 16:32 ewallet.p12
-rw-r----- 1 oracle asmadmin 3926 Apr  6 16:32 cwallet.sso

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

詳細:

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

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

回避方法:

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

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

詳細:

これは、バンドル・パッチのないOracle Grid Infrastructure (GI)バージョンが12.2.0.1の場合にのみ発生するクラスタウェアの問題です。この問題は、投票ディスクをオフラインにしてからオンラインにした後に、そのディスクが破損することによって発生します。

回避方法:

GIのバージョンと、投票ディスクが破損しているかどうかを確認します。ディスクを修復し(該当する場合)、最新のGIバンドルを適用します。

次のステップを実行します:

バンドル・パッチが適用されていないGIバージョンが 12.2.0.1であることを確認します。

[root@rmstest-udaau1 ~]# su - grid
[grid@rmstest-udaau1 ~]$ . oraenv
ORACLE_SID = [+ASM1] ? +ASM1
The Oracle base has been set to /u01/app/grid
[grid@rmstest-udaau1 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory
Oracle Interim Patch Installer version 12.2.0.1.6
Copyright (c) 2018, Oracle Corporation.  All rights reserved.

Oracle Home       : /u01/app/12.2.0.1/grid
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/12.2.0.1/grid/oraInst.loc
OPatch version    : 12.2.0.1.6
OUI version       : 12.2.0.1.4
Log file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/opatch2018-01-15_22-11-10PM_1.log
Lsinventory Output file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/lsinv/lsinventory2018-01-15_22-11-10PM.txt
--------------------------------------------------------------------------------
Local Machine Information::
Hostname: rmstest-udaau1.exaagclient.sretest.oraclevcn.com
ARU platform id: 226
ARU platform description:: Linux x86-64
Installed Top-level Products (1):
Oracle Grid Infrastructure 12c                                       12.2.0.1.0
There are 1 products installed in this Oracle Home.
There are no Interim patches installed in this Oracle Home.
--------------------------------------------------------------------------------
OPatch succeeded.

投票ディスクの破損が原因でGIが起動できなかったことの証拠を見つけるには、/u01/app/grid/diag/crs/<hostname>/crs/trace/ocssd.trcファイルを確認します:

ocssd.trc

2017-01-17 23:45:11.955 :    CSSD:3807860480: clssnmvDiskCheck:: configured
Sites = 1, Incative sites = 1, Mininum Sites required = 1
2017-01-17 23:45:11.955 :    CSSD:3807860480: (:CSSNM00018:)clssnmvDiskCheck:
Aborting, 2 of 5 configured voting disks available, need 3
......
.
2017-01-17 23:45:11.956 :    CSSD:3807860480: clssnmCheckForNetworkFailure:
skipping 31 defined 0
2017-01-17 23:45:11.956 :    CSSD:3807860480: clssnmRemoveNodeInTerm: node 4,
slcc05db08 terminated. Removing from its own member and connected bitmaps
2017-01-17 23:45:11.956 :    CSSD:3807860480:
###################################
2017-01-17 23:45:11.956 :    CSSD:3807860480: clssscExit: CSSD aborting from
thread clssnmvDiskPingMonitorThread
2017-01-17 23:45:11.956 :    CSSD:3807860480:
###################################
2017-01-17 23:45:11.956 :    CSSD:3807860480: (:CSSSC00012:)clssscExit: A
fatal error occurred and the CSS daemon is terminating abnormally
------------
2017-01-19 19:00:32.689 :    CSSD:3469420288: clssnmFindVF: Duplicate voting disk found in the queue of previously configured disks
queued(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009
cbd]),
found(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009c
bd]), is not corrupted
2017-01-19 19:01:06.467 :    CSSD:3452057344: clssnmvVoteDiskValidation:
Voting disk(o/192.168.10.19/PCW_CD_02_slcc05cel11) is corrupted

SQL*Plusを使用して、投票ディスクが破損していることを確認することもできます:

gridユーザーとしてログインし、環境をASMに設定します。

[root@rmstest-udaau1 ~]# su - grid
[grid@rmstest-udaau1 ~]$ . oraenv
ORACLE_SID = [+ASM1] ? +ASM1
The Oracle base has been set to /u01/app/grid

SYSASMとしてSQL*Plusにログインします。
```
$ORACLE_HOME/bin/sqlplus / as sysasm
```

次の2つの問合せを実行します:

SQL> select name, voting_file from v$asm_disk where VOTING_FILE='Y' and group_number !=0;
SQL> select  CC.name, count(*) from x$kfdat AA JOIN (select disk_number, name from v$asm_disk where VOTING_FILE='Y' and group_number !=0) CC ON CC.disk_number = AA.NUMBER_KFDAT where AA.FNUM_KFDAT= 1048572 group by CC.name;

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

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つ以上の投票ディスクが破損しています。

投票ディスクが破損している場合は、投票ディスクを含むグリッド・ディスクをオフラインにします。セルは、不良投票ディスクを他のグリッド・ディスクに自動的に移動し、その投票ディスクをオンラインにします。
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
```
バンドル・パッチなしでOracle GIバージョン12.2.0.1を使用している場合は、投票ディスクが破損したかどうかに関係なく、GIバージョンを最新のGIバンドルにアップグレードする必要があります。

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

詳細:

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

回避方法:

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

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

詳細:

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

回避方法:

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