已知問題

本文提供基準資料庫服務中已知問題的相關資訊。

基準資料庫服務中有下列已知問題：

相關主題

新資料庫中的現有可插式資料庫

詳細資訊

現有的可插拔資料庫 (PDB) 不會顯示在新建立的資料庫中，而且在 OCI 主控台中最多可能需要數小時的時間。這包括新資料庫的預設 PDB，以及複製或回復之資料庫的現有 PDB。就地回復至舊版本時，會以類似方式更新 PDB 清單，而且可能會有所延遲。

解決方法

無。

現有資料保全組態中的 PDB

詳細資訊

不允許透過 OCI 主控台或 API 在主要資料庫中建立及複製 PDB。

解決方法

您可以使用 SQL*Plus 在主要資料庫中建立或複製 PDB，並於稍後在 OCI 主控台中同步。

變更授權類型時發生帳單問題

詳細資訊

當您將資料庫或資料庫系統的授權類型從 BYOL 變更為包含授權，或者以其他方式變更時，系統會向您收取前一小時的兩種授權類型費用。之後，系統就會根據您更新的授權類型向您收取費用。

解決方法

我們正在努力解決方法。

使用 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

為了回應兩個常見的 Web 瀏覽器所實行有關 Symantec 憑證的原則，Oracle 最近變更了用於 Oracle Cloud Infrastructure 的憑證授權機構。如果 Oracle Database Cloud Backup Module 仍指向舊的憑證，導致 SSL 憑證的變更可能會導致物件儲存的備份失敗。

解決方法

請查看日誌檔瞭解列出的錯誤，如果找到，請更新備份模組。

  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 模組：

    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

為了回應兩個常見的 Web 瀏覽器所實行有關 Symantec 憑證的原則，Oracle 最近變更了用於 Oracle Cloud Infrastructure 的憑證授權機構。如果 Oracle Database Cloud Backup Module 仍指向舊的憑證，導致 SSL 憑證的變更可能會導致物件儲存的備份失敗。

解決方法

請查看 RMAN 日誌檔以瞭解列出的錯誤訊息。如果找到，請以 oracle 使用者身分登入主機，然後使用您的 Swift 證明資料重新安裝備份模組。

附註：

Swift 密碼現在稱為「Auth 記號」。如需詳細資訊，請參閱管理使用者證明資料。 
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 模組」的詳細資訊，請參閱使用 Oracle Database Backup Cloud Service 。

中斷資料庫服務 SDK 的變更

詳細資訊

2018 年 10 月 18 日發行的 SDK 導入資料庫備份 API 中資料庫大小與資料庫版本屬性的程式碼破解變更。

解決方法

如需有關分隔變更的詳細資訊，請參閱語言特定文件，並視適用情況更新您現有的代碼。

無法在您的資料庫系統中使用受管理備份

詳細資訊

當您使用 OCI 主控台或 API 時，備份與回復作業可能無法在您的資料庫系統中運作。

解決方法

安裝 Oracle Database Cloud Backup Module，然後聯絡 Oracle Support Services 以取得進一步的指示。

執行下列步驟來安裝 Oracle Database Cloud Backup Module：

  1. 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 密碼現在稱為「Auth 記號」。

  6. 執行下列 curl 命令以驗證證明資料是否正常運作：

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

    若要判斷正確的區域，請參閱物件儲存常見問題。

    此命令應傳回 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

    (您可能必須將 sudo 與複製命令搭配使用，才能以 root 的身分執行。)

  9. 執行下列指令以檢查指定的目錄是否存在：

    ls /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs

    如果目錄存在，請執行下列步驟：

    1. 備份 /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs 目錄中的檔案。

    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 或您的租用戶管理員以取得進一步的指示。您必須提供要對其啟用備份的資料庫系統 OCID。

VM.Standard1.1 資源配置的受管理自動備份失敗，因為處理作業損毀

詳細資訊

執行 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: feature not enabled"

詳細資訊

在高效能和極致效能資料庫系統中，使用壓縮和 (或) 平行機制的資料汲取公用程式作業可能會失敗，並且傳回錯誤 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 月的修正程式套用至資料庫系統和資料庫本位目錄。

附註：

若要判斷資料庫本位目錄中的資料庫版本，請以 oracle 使用者身分執行 $ORACLE_HOME/OPatch/opatch lspatches，或以 root 使用者身分執行 dbcli list-dbhomes。

無法從您的 1 節點資料庫系統連線至 EM Express 主控台

詳細資訊

嘗試從 1 節點資料庫系統連線至 EM Express 主控台時，可能會收到「安全連線失敗」錯誤訊息，因為未自動套用正確的權限。

解決方法

在資料庫系統的公事包目錄上新增 asmadmin 群組的讀取權限，然後重試連線。請執行下列步驟來新增讀取權限。

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

使用 dbaascli 時，未同步啟用資料保全之資料庫的 OCI 主控台資訊

詳細資訊

OCI 主控台會同步並顯示使用 dbaasapi 和 dbaascli 公用程式建立及管理之資料庫的相關資訊。不過，在下列情況下，已設定「資料保全」的資料庫不會在 OCI 主控台中顯示正確的資訊：

  • 如果使用 OCI 主控台啟用 Data Guard，然後使用 dbaascli 對主要或待命資料庫進行變更 (例如將資料庫移至其他本位目錄)，則結果不會反映在 OCI 主控台中。
  • 如果手動設定 Data Guard，OCI 主控台就不會顯示兩個資料庫之間的 Data Guard 關聯。

解決方法

我們深知問題並處理解決方法。同時，Oracle 建議您只使用 OCI 主控台或只使用命令行公用程式來管理啟用 Data Guard 的資料庫。

Grid Infrastructure 不會在磁碟離線和內嵌之後啟動

詳細資訊

這是只有在 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. 檢查 /u01/app/grid/diag/crs/<hostname>/crs/trace/ocssd.trc 檔案，瞭解 GI 因仲裁磁碟損毀而無法啟動的證據： 

    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. 執行下列兩個查詢：

      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

      在狀況良好的系統中，第一個查詢中所傳回的每個仲裁磁碟也應在第二個查詢中傳回，而所有磁碟的計數不應為零。否則，您的一或多個仲裁磁碟已損毀。

  4. 如果仲裁磁碟損毀，請將包含仲裁磁碟的網格磁碟離線。儲存格會自動將不好的仲裁磁碟移至其他網格磁碟，以及將仲裁磁碟上線。

    1. 下列指令會離線名為 DATAC01_CD_05_SCAQAE08CELADM13 的網格磁碟。

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

    2. 等待 30 秒，然後重新執行步驟 3c 中的兩個查詢，以驗證仲裁磁碟是否已移轉至新的網格磁碟，以及是否正常。

    3. 確認您離線的網格磁碟已上線：

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

      mode_status 應為「線上」，且 voting_file 不應為 Y。

    針對每個包含損毀仲裁磁碟的剩餘網格磁碟，重複步驟 4a 到 4c。

    附註：

    如果 CRS 因仲裁磁碟損毀而未啟動，請在步驟 4 執行命令之前，先使用「專用」模式啟動它。

    crsctl start crs -excl

  5. 如果您使用的是不含任何組合修正程式的 Oracle GI 版本 12.2.0.1，則無論仲裁磁碟是否損毀，都必須將 GI 版本升級成最新的 GI 組合。

資料庫系統儲存調整失敗

詳細資訊

嘗試在單一作業中從小於 10,240 GB 的值擴展至高於 10,240 GB 的值，可能會導致調整作業失敗。

解決方法

如果您要將一般資料儲存體或復原區域 (RECO) 儲存體從小於 10,240 GB (10 TB) 的值擴展至超過 10,240 GB 的值，請在兩個作業中執行擴展。首先，將系統調整為 10,240 GB。第一個調整作業完成且系統處於「可用」狀態之後，請執行第二個調整作業，指定超過 10,240 GB 的目標儲存值。

資料庫系統資源配置調整失敗

詳細資訊

將資料庫系統調整為使用較大的系統資源配置時，如果 DB_Cache_nX 參數未設為 0 (零)，則調整作業會失敗。

解決方法

調整資料庫系統規模時，請確定所有 DB_Cache_nX 參數 (例如 DB_nK_CACHE_SIZE) 都設為 0 (零)。