設定 Data Guard broker 產生 ORA-16698 錯誤

Oracle 版本: 12.2.0.1.170814

OS 版本: Windows Server 2016

問題描述:

建立 Data Guard Broker Configuration 的時候產生以下錯誤 :

DGMGRL> create configuration 'orcl_dg' as primary database is 'orcl' connect identifier is orcl; Error: ORA-16698: LOG_ARCHIVE_DEST_2 parameter set for object to be added

問題分析:

在建立 Data Guard 時如果不使用 Data Guard Broker 就需要設定 log_archive_dest_1 與 log_archive_dest_2 兩個參數，一般來說 log_archive_dest_1 為本地 archive log 設定， log_archive_dest_2 為 Remote Log Shipping 設定。從 Oracle 12c 版本之後，如果使用 Data Guard Broker 來設定 Data Guard ，則不需要自行設定 log_archive_dest_2 ，這個參數須完全交由 Data Guard Broker 自行綁定，如果在建立 Data Guard Broker Configuration 已經設定了 log_archive_dest_2 參數，就會出現 ORA-16698 錯誤。

解決方法:

將參數檔中的 log_archive_dest_2 設定移除，只需保留 log_archive_dest_1 的設定就好。

 

從 NFS restore control file 失敗

Oracle 版本: 19.15

OS 版本: AIX 7.2

問題描述:

從 NFS 執行 restore controlfile 發生 RMAN-06172 錯誤 :

RMAN> restore controlfile from '/backup/rman/ORCL_0h1d5s04_1_1.ctl'; Starting restore at 19-NOV-2022 00:32:30 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=600 device type=DISK RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 11/19/2022 00:32:31 RMAN-06172: no AUTOBACKUP found or specified handle is not a valid copy or piece

問題分析:

將備份檔 ORCL_0h1d5s04_1_1.ctl 複製到 local directory 並嘗試 restore controlfile 是可以成功 :

RMAN> restore controlfile from '/u01/app/backup/ORCL_0h1d5s04_1_1.ctl'; Starting restore at 19-NOV-2022 00:50:21 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=120 device type=DISK channel ORA_DISK_1: restoring control file channel ORA_DISK_1: restore complete, elapsed time: 00:00:02 output filename=/u01/oradata/orcl/control01.ctl output filename=/u01/oradata/orcl/control02.ctl Finished restore at 19-NOV-2022

由此驗證問題是出在 NFS 的 mount option 上，檢查發現 NFS 沒有調整任何的 mount option :

# mount |grep backup 172.26.18.110 /backup/rman   /backup  nfs3

解決方法:

使用正確的 mount option 重新 mount NFS 即可 :

# mount 172.26.18.110:/backup /backup/rman –o cio,rw,bg,hard,nointr,rsize=32768,wsize=32768,proto=tcp,noac,vers=3,timeo=600

如果是 Linux 系統，則使用以下 options :

rw,bg,hard,nointr,rsize=32768,wsize=32768,tcp,actimeo=0,vers=3,timeo=600

RMAN 產生 ENQ: CF - CONTENTION 等待案例

Oracle 版本: 19.14

OS 版本: Linux 7.9

問題描述:

DB 在 RMAN 執行備份時段發生 hang 的情況，約有 2 分鐘無法進行任何操作與連線，此時 RMAN 正好在執行 rman delete obsolete 。

問題分析:

由 ASH 分析在事件時段存在著 ENQ: CF – CONTENTION 與 CONTROL FILE PARALLEL WRITE 等待事件 :

這個現象與 Bug 33727983 所描述的情況相符，原因在於需要 delete obsolete 的物件過多，需要花費較長的時間掃描 control file ，在多個 channel 同時作用下，便產生了 control file 爭用的情況發生。由 RMAN 的 log 可以看到 delete 超過萬個 obsolete 物件 :

解決方法:

Bug 33727983 於 19.17 之後的版本修復，將 DB apply RU 至 19.17 之後的版本，或者是單獨 apply 33727983 的 one-off patch 。暫時的 workaround 可以只使用單一個 channel 執行 delete obsolete ，這樣就可以避免多個 channel 執行同一個操作而造成 control file 爭用。

datapatch 產生 ORA-29913 錯誤

Oracle 版本: 12.2.0.1.181016

OS 版本: Solaris 10

問題描述:

將資料庫由 12.2.0.1.181016 patch 至 12.2.0.1.200714 ，在最後階段執行 datapatch 時失敗產生了 ORA-29913 錯誤 :

-bash-3.2$ ./datapatch -verbose SQL Patching tool version 12.2.0.1.0 Production on Thu Sep 17 18:59:01 2020 Copyright (c) 2012, 2020, Oracle.  All rights reserved. Log file for this invocation: /oracle/app/cfgtoollogs/sqlpatch/sqlpatch_23713_2020_09_17_18_59_01 /sqlpatch_invocation.log Connecting to database...OK Bootstrapping registry and package to current versions...done DBD::Oracle::db selectrow_array failed: ORA-29913: error in executing  ODCIEXTTABLEFETCH callout ORA-00607: Internal error occurred while making a change to a data block ORA-00600: internal error code, arguments: [kdBlkCheckError], [3], [50181], [63053], [], [], [], [], [], [], [], [] (DBD ERROR: error possibly near <*> indicator at char 7 in 'SELECT <*> dbms_sqlpatch.verify_queryable_inventory FROM dual') [for Statement "SELECT dbms_sqlpatch.verify_queryable_inventory FROM dual"] at /oracle/app/product/12.2.0/sqlpatch/sqlpatch.pm line 6027, <LOGFILE> line 107.

問題分析:

由錯誤訊息中可知 datapatch 過程中在執行 dbms_sqlpatch.verify_queryable_inventory 時發生了錯誤，此時以 sqlplus 進行測試也同樣發生了 ORA-29913 錯誤 :

SQL> SELECT dbms_sqlpatch.verify_queryable_inventory FROM dual  2  ; SELECT dbms_sqlpatch.verify_queryable_inventory        * ERROR at line 1: ORA-29913: error in executing ODCIEXTTABLEFETCH callout ORA-00607: Internal error occurred while making a change to a data block ORA-00600: internal error code, arguments: [kdBlkCheckError], [3], [50181], [63053], [], [], [], [], [], [], [], []

由 trace file 發現 LOB Segments 有 Corrupt Block 所以才造成錯誤 :

Corrupt Block Found TIME STAMP (GMT) = 09/17/2020 19:02:17 CONT = 0, TSN = 1, TSNAME = SYSAUX RFN = 3, BLK = 50181, RDBA = 12633093 OBJN = 10486, OBJD = 10486, OBJECT = SYS_LOB0000010485C00001$$, SUBOBJECT = SEGMENT OWNER = SYS, SEGMENT TYPE = Lob Segment Errors in file /oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_24528.trc  (incident=1080037): ORA-00600: internal error code, arguments: [kdBlkCheckError], [3], [50181], [63053], [], [], [], [], [],[], [], [] Incident details in: /oracle/app/diag/rdbms/orcl/orcl/incident/incdir_1080037 /orcl_ora_24528_i1080037.trc

查詢這個 LOB Segment ，發現它是屬於 OPATCH_XINV_TAB 這個 table :

SQL> select table_name,column_name,TABLESPACE_NAME from dba_lobs where owner='SYS' and segment_name='SYS_LOB0000010485C00001$$'; TABLE_NAME              COLUMN_NAME      TABLESPACE_NAME ----------------------------------------------------------------- OPATCH_XINV_TAB     XML_INVENTORY    SYSAUX

經由分析可知是由於 OPATCH_XINV_TAB 有 corrupt block 造成 datapatch 執行失敗。

解決方法:

將此 LOB Segments 進行一次搬移，避開這個 corrupt block :

SQL> alter table sys.opatch_xinv_tab move lob(xml_inventory) store as (tablespace sysaux); Table altered.

Move 之後確認物件狀態為 Valid :

SQL> select owner,object_name,object_type,status from dba_objects where object_name in ('DBMS_QOPATCH','OPATCH_XML_INV'); OWNER         OBJECT_NAME         OBJECT_TYPE           STATUS ----------- ------------------ ------------------- ------- SYS            DBMS_QOPATCH       PACKAGE                 VALID SYS            DBMS_QOPATCH       PACKAGE BODY           VALID SYS            OPATCH_XML_INV     TABLE                   VALID

重新測試 dbms_sqlpatch.verify_queryable_inventory 就沒有發生錯誤了 :

SQL> select dbms_sqlpatch.verify_queryable_inventory from dual; VERIFY_QUERYABLE_INVENTORY -------------------------------------------------- OK

此時再重新執行一次 datapatch 即可通過。

impdp 產生 ORA-39384 錯誤案例

Oracle 版本: 19.15

OS 版本: Aix 7.2

問題描述:

以 schema level 將 11.2.0.4 的使用者 expdp 出來後，將其 impdp 至 19.15 產生了 ORA-39384: Warning: User SCOTT Has Been Locked And The Password Expired 這個錯誤:

Export From 11g DB: $ expdp \'/ as sysdba\' directory=expdir schemas=scott dumpfile=exp_scott%U.dmp logfile=exp_scott.log Import to 19c DB: $ impdp \'/ as sysdba\' directory=impdir dumpfile= exp_scott%U.dmp logfile=imp_scott.log Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved. Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Master table "SYS"."SYS_IMPORT_FULL_01" successfully loaded/unloaded Starting "SYS"."SYS_IMPORT_FULL_01":  "/******** AS SYSDBA" directory=impdir dumpfile=exp_scott%U.dmp logfile=imp_scott.log  Processing object type SCHEMA_EXPORT/USER ORA-39384: Warning: User SCOTT Has Been Locked And The Password Expired …

問題分析:

在 impdp 的過程當中，如果資料庫不存在需要的使用者，則會先行建立此使用者，這個訊息就是 impdp 一開始建立使用者的時候發生錯誤，使用者沒有建立起來，後續的物件自然也無法 import 成功。

ORA-39384 顯示使用者被 Locked 或者是密碼過期，可是檢查來源端 11g 的使用者卻沒有 Locked 或是密碼過期，為何 impdp 會無法建立此 User ?

這個問題來自於 Oracle 12c 之後對於安全性的嚴謹度加強，早期資料庫的使用者如果它的 password_versions (select password_versions from dba_users) 為 10G 或是更舊，那麼此使用者 impdp 到 12c 以上的資料庫就會產生此問題。

解決方法:

這個問題的解決思路在於讓 12c 以上的資料庫可以相容於舊資料庫的設定，於 $ORACLE_HOME/network/admin 底下的 sqlnet.ora 設定如下即可正常 impdp :

sqlnet.allowed_logon_version_server = 10 sqlnet.allowed_logon_version_client = 10

ORA-28040: No matching authentication

Oracle 版本: 12.2.0.1

OS 版本: Aix 7.1

問題描述:

在資料庫升級到 12.2.0.1 (或以上版本) 之後， Client 無法連線並出現 ORA-28040: No matching authentication 錯誤。

問題分析:

在資料庫升級之後， Client 端的版本 (Oracle Client 、 JDBC …etc) 沒有一併升級導致兩者不相容所產生的連線問題。

解決方法:

於 $ORACLE_HOME/network/admin 底下的 sqlnet.ora 設定如下，讓資料庫可以相容舊版本的 Client 即可:

sqlnet.allowed_logon_version_server = 8 sqlnet.allowed_logon_version_client = 8

grant 產生 ORA-4021 錯誤案例

Oracle 版本: 12.1.0.2.0 ， RAC

OS 版本: AIX 5.3

問題描述:

於針對 gv_$ 開頭的 view 授予權限時， session 會 hang 住，最終出現 ORA-04021 timeout occurred while waiting to lock object ，無法 grant 成功 。

SQL> grant select on gv_$instance to scott;                  * ERROR at line 1: ORA-04021: timeout occurred while waiting to lock object (此命令 hang 住，最終出現 ORA-04021 的 timeout 錯誤)

問題分析:

針對 grant select on gv_$instance to scott 語法進行 hanganalyze 與 systemstate dump 分析:

SQL> oradebug setospid 515; SQL> oradebug hanganalyze 3; SQL> oradebug dump systemstate 266; SQL> oradebug hanganalyze 3;

由 trace 顯示此 grant session 遭遇到 library cache lock 的等待，並且被 sid 為 344 的 session 阻塞 :

同樣的方法 trace sid 為 344 的 session ，此 session 正在進行 virtual circuit next request 的等待 :

virtual circuit next request 是一個 idle 的等待事件，當資料庫有設定 EM Express ，使用者經由網頁開啟並登入，此時資料庫會進行如下操作來撈取相關資訊顯示在 EM Express 上 :

begin :rept := dbms_report.get_report(:report_ref, :content, :comp);  end;

若使用者沒有登出 Web 頁面， EM Express 的 session 就會出現 virtual circuit next request 這個 idle 的等待事件。由於此時 EM Express 尚未釋放相關的 LibraryHandle ，造成其它 session 對於 gv$instance 的操作產生了 library cache lock ，一直沒有等到 lock 釋放而出現了 ORA-04021 的錯誤。

解決方法:

將登入進 EM Express 的使用者 session kill ，或者是由 EM Express 的網頁進行登出的動作，再重新進行 grant 操作便可成功。

CRS-2675 無法停止 vip 案例

Oracle 版本: 11.2.0.4 ， RAC

OS 版本: Linux 5.7

問題描述:

停止 vip 服務時出現 CRS 錯誤， vip 無法停止。

# cd /opt/app/11.2.0/grid/bin # ./srvctl stop vip –i tacp1 –f PRCR-1065 : Failed to stop resource ora.tacp1.vip CRS-2645: Stop of 'ora.tacp1.vip' on 'tac1' failed

問題分析:

檢查 orarootagent_root.log ，在停止 vip 服務當下產生了錯誤如下 :

CRS-5007: Cannot remove the primary IP 192.168.49.111 from the network interface

Oracle Cluster 的 vip 是在服務啟動後才將 vip 綁定在網卡上，停止 vip 服務時會將此 vip 從網卡上移除。

從 orarootagent_root.log 顯示的錯誤訊息表示停止 vip 服務的當下，此 vip 無法從網卡上移除，原因是此 vip 為網卡上主要的 IP 。

檢查網卡與 IP 的設定，正常情況 vip 所綁定的網卡會以 <網卡>:n 來表示， eth1 所綁定的 vip 網卡名稱為 eth1:1 ，但是 192.168.49.111 卻綁定在實體網卡 eth2 上 :

所以這個問題是 vip 本身設定錯誤的問題，誤將 vip 設定成網卡上的實體 IP 了。

解決方法:

將網卡 eth2 disable 之後，調整實體 IP 與 vip 的設定，將兩者設定為不同 IP ，重啟服務後回復正常。

ORA-16532: Oracle Data Guard broker configuration does not exist

Oracle 版本: 12.1.0.2

OS 版本: Linux 7.5

問題描述:

Primary 為 RAC 架構， Standby 端為 Single Instance ，使用 Data Guard Broker ，設定完 Data Guard Broker 後 show configuration 出現以下告警 :

DGMGRL>  show configuration Configuration – ORCL_DG   Protection Mode: MaxPerformance   Members:   ORLC_P - Primary database     Warning: ORA-16532: Oracle Data Guard broker configuration does not exist      ORCL_S - Physical standby database Fast-Start Failover:  Disabled Configuration Status: ERROR   (status updated 40 seconds ago)

問題分析:

ORA-16532: Oracle Data Guard broker configuration does not exist 這個訊息大多與 Data Guard Broker 的設定檔有關，也就是參數 dg_broker_config_file1 與 dg_broker_config_file2 所設定的 .dat 檔，這個檔案預設會設定在 $ORACLE_HOME/dbs 底下，在 RAC 架構下，必須要把此檔案設定在所有節點可共享的位置，例如 ASM ，否則就有可能會出現 DG Broker 找不到設定檔的訊息。

解決方法:

將參數 dg_broker_config_file1 與 dg_broker_config_file2 重新設定在 ASM ，並重新 disable configuration 與 enable configuration 之後此告警訊息消失。

SQL> alter system set dg_broker_config_file1='+DATAC1/ORCL/dr1ORCL.dat'; SQL> alter system set dg_broker_config_file2='+DATAC1/ORCL/dr2ORCL.dat'; DGMGRL> disable configuration; DGMGRL> enable configuration;