您好,登錄后才能下訂單哦!
這篇文章主要介紹“怎么修復Oracle 11.2.0.1 dblink訪問ORA-600”,在日常操作中,相信很多人在怎么修復Oracle 11.2.0.1 dblink訪問ORA-600問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”怎么修復Oracle 11.2.0.1 dblink訪問ORA-600”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
db alert log
2019-08-12 15:46:15.334000 +08:00 Errors in file /oracle/app/oracle/diag/rdbms/anbob/anbob/trace/anbob_ora_14800.trc (incident=320040): ORA-00600: internal error code, arguments: [2252], [5579], [3110485746], [], [], [], [], [], [], [], [], [] Incident details in: /oracle/app/oracle/diag/rdbms/anbob/anbob/incident/incdir_320040/anbob_ora_14800_i320040.trc 2019-08-12 15:46:17.000000 +08:00 Trace dumping is performing id=[cdmp_20190812154617] Sweep [inc][320040]: completed Sweep [inc2][320040]: completed
trace file
adrci> show incident -all ADR Home = /oracle/app/oracle/diag/rdbms/anbob/anbob: ************************************************************************* INCIDENT_ID PROBLEM_KEY CREATE_TIME -------------------- ----------------------------------------------------------- ---------------------------------------- ... 320037 ORA 600 [2252] 2019-08-08 09:35:59.628000 +08:00 304310 ORA 600 [2252] 2019-08-08 09:39:21.668000 +08:00 304295 ORA 600 [2252] 2019-08-08 09:59:10.141000 +08:00 304302 ORA 600 [2252] 2019-08-08 14:38:15.196000 +08:00 304253 ORA 600 [2252] 2019-08-09 11:04:34.003000 +08:00 320038 ORA 600 [2252] 2019-08-09 11:40:43.692000 +08:00 304289 ORA 600 [2252] 2019-08-09 15:02:21.345000 +08:00 320039 ORA 600 [2252] 2019-08-12 10:05:07.925000 +08:00 304303 ORA 600 [2252] 2019-08-12 11:21:54.489000 +08:00 320040 ORA 600 [2252] 2019-08-12 15:46:15.334000 +08:00 50 rows fetched adrci> show trace file /oracle/app/oracle/diag/rdbms/anbob/anbob/trace/anbob_ora_14800.trc Dump continued from file: /oracle/app/oracle/diag/rdbms/anbob/anbob/trace/anbob_ora_14800.trc 1> ***** Error Stack ***** ORA-00600: internal error code, arguments: [2252], [5579], [3110485746], [], [], [], [], [], [], [], [], [] 1< ***** Error Stack ***** 1> ***** Dump for incident 320040 (ORA 600 [2252]) ***** *** 2019-08-12 15:46:15.336 dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0) 2> ***** SQL Statement (None) ***** Current SQL information unavailable - no cursor. ***** Call Stack Trace ***** calling call entry location type point -------------------- -------- -------------------- skdstdst()+36 call kgdsdst() ksedst1()+98 call skdstdst() ksedst()+34 call ksedst1() dbkedDefDump()+2736 call ksedst() ksedmp()+36 call dbkedDefDump() ksfdmp()+64 call ksedmp() dbgexPhaseII()+1764 call ksfdmp() dbgexProcessError() call dbgexPhaseII() +2279 dbgeExecuteForError call dbgexProcessError() ()+83 dbgePostErrorKGE()+ call dbgeExecuteForError 1615 () dbkePostKGE_kgsf()+ call dbgePostErrorKGE() 63 kgeade()+350 call dbkePostKGE_kgsf() kgeriv_int()+98 call kgeade() kgeriv()+12 call kgeriv_int() kgesiv()+110 call kgeriv() ksesic2()+194 call kgesiv() kcmchk()+113 call ksesic2() kcsadjn()+315 call kcmchk() k2serv()+390 call kcsadjn() opiodr()+1149 call k2serv() ttcpip()+1251 call opiodr() opitsk()+1628 call ttcpip()
臨時斷開dblink 后
SQL> select version, to_char(SYSDATE, 'YYYY/MM/DD HH24:MI:SS') DATE_TIME, (((( ((to_number(to_char(sysdate, 'YYYY')) - 1988) * 12 * 31 * 24 * 60 * 60) + ((to_number(to_char(sysdate, 'MM')) - 1) * 31 * 24 * 60 * 60) + (((to_number(to_char(sysdate, 'DD')) - 1)) * 24 * 60 * 60) + (to_number(to_char(sysdate, 'HH24')) * 60 * 60) + (to_number(to_char(sysdate, 'MI')) * 60) + (to_number(to_char(sysdate, 'SS'))) ) * (16 * 1024)) - dbms_flashback.get_system_change_number) / (16 * 1024 * 60 * 60 * 24) ) indicator from v$instance ; VERSION DATE_TIME INDICATOR ----------------- ------------------- ---------- 11.2.0.1.0 2019/08/12 17:31:20 13.1391809
下載補丁
[oracle@localhost ~]$ ls
p12419378_112010_Linux-x86-64.zip
p6880880_112000_Linux-x86-64.zip
p14121009_112016_Linux-x86-64.zip
安裝11.2.0.1 PSU
$ export PATH=$PATH:$ORACLE_HOME/OPatch $ opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ./12419378 $ opatch apply SQL> @?/rdbms/admin/catbundle psu apply
note:
Opatch warning: overriding ….This is a warning only which opatch is reporting. The Patch has applied successfully and the warning output can be safely ignored.
安裝one-off patch
[oracle@localhost 14121009]$ opatch prereq CheckConflictAgainstOHWithDetail -ph ./ [oracle@localhost 14121009]$ opatch apply SQL> @?/sqlpatch/14121009/postinstall.sql
檢查
SQL> select * from registry$history; SQL> @scn_compat_check.sql Current datatime:20190814 10:38:33 Oracle Version:Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production Database role:PRIMARY Instance starttime: 20190814 10:34:43 RSL=35937836695552 headroom_in_scn=19308210069494 headroom_in_sec=196413269 CUR_SCN_COMPAT=3 MAX_SCN_COMPAT=3 auto_rollover_ts=2019-06-23 target_compat=3 Auto_rollover is enabled! SCN compat had Auto rollover ! PL/SQL procedure successfully completed.
到此,關于“怎么修復Oracle 11.2.0.1 dblink訪問ORA-600”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。