-
3D Cloud
asm mount asm恢复 bbed bootstrap$ dmp损坏 dul In Memory kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01190 ORA-01555 ORA-01578 ORA-08103 ORA-600 2662 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kccpb_sanity_check_2 ORA-15042 ORACLE 12C oracle dul ORACLE PATCH oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 redo异常 sql加密恢复 undo异常 YOUR FILES ARE ENCRYPTED _ALLOW_RESETLOGS_CORRUPTION 勒索恢复 数据库恢复 比特币 oracle 比特币加密
文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (87)
- 数据库 (1,321)
- DB2 (22)
- MySQL (57)
- Oracle (1,207)
- Data Guard (39)
- EXADATA (7)
- GoldenGate (19)
- ORA-xxxxx (145)
- ORACLE 12C (71)
- ORACLE 18C (6)
- ORACLE 19C (8)
- Oracle ASM (56)
- Oracle Bug (7)
- Oracle RAC (40)
- Oracle 安全 (6)
- Oracle 开发 (25)
- Oracle 监听 (26)
- Oracle备份恢复 (396)
- Oracle安装升级 (55)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (45)
- PostgreSQL (10)
- SQL Server (26)
- SQL Server恢复 (7)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (23)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (6)
-
最近发表
- ORA-00742 ORA-00312 故障恢复
- 硬件故障导致ORA-600 2662错误处理
- ORA-00600: internal error code, arguments: [16513], [1403] 恢复
- .IQ0003后缀名勒索恢复
- .Globeimposter-Alpha666qqz加密恢复
- Assistant: Download Reference for Oracle Database/GI PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases-202101
- .sql文件被加密恢复
- ORA-600 3020错误引起ORA-600 2663
- Alpha865qqz.id 加密数据库恢复
- incaseformat 病毒删除文件恢复
- xfs文件系统mysql删库恢复
- 对恢复案例:因对工作调整不满,链家一员工删除公司 9 TB数据:被判7年事件有感
- Oracle Recovery Tools 解决ORA-01190 ORA-01248等故障
- Oracle Recovery Tools 12月份更新
- -bash: /bin/rm: Argument list too long
- ORA-27303: failure occurred at: skgpwinit6
- ORA-600 kffmLoad_1 kffmVerify_4
- ORA-00600 kfrHtAdd01
- ORA-00600 [2662]和ORA-00600 [4194]恢复
- 记录oracle安装的两个小问题(INS-30060和弹出子窗口异常)
友情链接
分类目录归档:Data Guard
ORA-04020导致adg异常
今日早上有客户反馈adg停止同步了,通过检查alert日志发现
Tue Dec 24 18:17:41 2019 Media Recovery Waiting for thread 1 sequence 56655 (in transit) Recovery of Online Redo Log: Thread 1 Group 11 Seq 56655 Reading mem 0 Mem# 0: Y:\ORACLE\ORADATA\ORACLE11\STD_REDO11.LOG Archived Log entry 56248 added for thread 1 sequence 56654 ID 0x5b6bcf9b dest 1: Tue Dec 24 18:18:11 2019 Errors in file C:\APP\ADMINISTRATOR\diag\rdbms\oracle11dg\oracle11\trace\oracle11_lgwr_3252.trc: ORA-04020: deadlock detected while trying to lock object SYS.orcl LGWR (ospid: 3252): terminating the instance due to error 4020 Tue Dec 24 18:18:11 2019 System state dump requested by (instance=1, osid=3252 (LGWR)), summary=[abnormal instance termination]. System State dumped to trace file C:\APP\ADMINISTRATOR\diag\rdbms\oracle11dg\trace\oracle11_diag_3236_20191224181811.trc Dumping diagnostic data in directory=[cdmp_20191224181811], requested by (instance=1, osid=3252 (LGWR)), summary=[abnormal instance termination]. Instance terminated by LGWR, pid = 3252
由于lgwr进程遭遇ORA-04020,从而使得lgwr进程异常,进而整个数据库crash.
分析trace文件
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options Windows NT Version V6.1 Service Pack 1 CPU : 8 - type 8664, 8 Physical Cores Process Affinity : 0x0x0000000000000000 Memory (Avail/Total): Ph:8395M/32733M, Ph+PgF:41002M/65464M Instance name: oracle11 Redo thread mounted by this instance: 1 Oracle process number: 10 Windows thread id: 3252, image: ORACLE.EXE (LGWR) *** 2019-12-24 18:18:11.072 *** SESSION ID:(384.1) 2019-12-24 18:18:11.072 *** CLIENT ID:() 2019-12-24 18:18:11.072 *** SERVICE NAME:(SYS$BACKGROUND) 2019-12-24 18:18:11.072 *** MODULE NAME:() 2019-12-24 18:18:11.072 *** ACTION NAME:() 2019-12-24 18:18:11.072 A deadlock among DDL and parse locks is detected. This deadlock is usually due to user errors in the design of an application or from issuing a set of concurrent statements which can cause a deadlock. This should not be reported to Oracle Support. The following information may aid in finding the errors which cause the deadlock: ORA-04020: deadlock detected while trying to lock object SYS.orcl -------------------------------------------------------- object waiting waiting blocking blocking handle session lock mode session lock mode -------- -------- -------- ---- -------- -------- ---- 0000000676C20F08 000000066D22BE10 00000006738AB970 X 000000066D22BE10 00000006738A04B0 S 0000000677DF2E80 00000006792E2880 0000000673B13AE8 X 000000066D22BE10 00000006738A19B8 S -------------------------------------------------------- ---------- DUMP OF WAITING AND BLOCKING LOCKS ---------- -------------------------------------------------------- ------------- WAITING LOCK ------------- ---------------------------------------- SO: 0x00000006738AB970, type: 78, owner: 0x000000065D440498, flag: INIT/-/-/0x00 if: 0x3 c: 0x3 proc=0x000000066CDE7AD0, name=LIBRARY OBJECT LOCK, file=kgl.h LINE:8751, pg=0 LibraryObjectLock:Address=00000006738AB970 Handle=0000000676C20F08 RequestMode=X CanBeBrokenCount=2 Incarnation=3 ExecutionCount=0 ……………… SO: 0x00000006738A19B8, type: 78, owner: 0x000000065A38D6C0, flag: INIT/-/-/0x00 if: 0x3 c: 0x3 proc=0x000000066CDE7AD0, name=LIBRARY OBJECT LOCK, file=kgl.h LINE:8751, pg=0 LibraryObjectLock:Address=00000006738A19B8 Handle=0000000677DF2E80 Mode=S CanBeBrokenCount=1 Incarnation=1 ExecutionCount=0 User=000000066D22BE10 Session=000000066D22BE10 ReferenceCount=1 Flags=CNB/[0001] SavepointNum=1b749 LibraryHandle: Address=0000000677DF2E80 Hash=675351da LockMode=S PinMode=0 LoadLockMode=0 Status=0 ObjectName: Name=SYS.orcl FullHashValue=285b654fe3f440652c403c98675351da Namespace=DBINSTANCE(74) Type=CURSOR(00) Identifier=1 OwnerIdn=0 Statistics: InvalidationCount=0 ExecutionCount=0 LoadCount=0 ActiveLocks=1 TotalLockCount=74719 TotalPinCount=0 Counters: BrokenCount=1 RevocablePointer=1 KeepDependency=0 Version=0 BucketInUse=2 HandleInUse=2 HandleReferenceCount=0 Concurrency: DependencyMutex=0000000677DF2F30(0, 0, 0, 0) Mutex=0000000677DF2FC0(0, 149471, 1, 0) Flags=RON/PIN/KEP/BSO/[00810003] WaitersLists: Lock=0000000677DF2F10[0000000673B13B58,000000067382E2F0] Pin=0000000677DF2EF0[0000000677DF2EF0,0000000677DF2EF0] LoadLock=0000000677DF2F68[0000000677DF2F68,0000000677DF2F68] Timestamp: HandleReference: Address=0000000677DF3030 Handle=0000000000000000 Flags=[00] --------------------------------- This lock request was aborted. error 4020 detected in background process ORA-04020: deadlock detected while trying to lock object SYS.orcl kjzduptcctx: Notifying DIAG for crash event ----- Abridged Call Stack Trace ----- ksedsts()+585<-kjzdssdmp()+329<-kjzduptcctx()+288<-kjzdicrshnfy()+99<-ksuitm()+1525<-ksbrdp()+4578<-opirip() +853<-opidrv()+906<-sou2o()+98<-opimai_real()+280<-opimai()+191 <-BackgroundThreadStart()+646<-0000000076CF59CD<-0000000076E2A561 ----- End of Abridged Call Stack Trace ----- *** 2019-12-24 18:18:11.165 LGWR (ospid: 3252): terminating the instance due to error 4020 *** 2019-12-24 18:18:17.483 ksuitm: waiting up to [5] seconds before killing DIAG(3236)
日志显示由于lgwr进程等待LIBRARY OBJECT LOCK超时,从而引起异常,根据经验此类问题一般是由于bug导致,查询mos发现匹配bug信息Bug 18515268 ORA-4020 in ADG Standby Database causing instance crash by LGWR
可以根据需要打上相关Patch 18515268: ACTIVE DATAGUARD STANDBY CRASHES DUE TO AN ORA-4020 ENCOUNTERED BY LGWR
oracle active dataguard修改密码备库延迟生效
在oracle dataguard环境中,当主库修改密码之后,备库不会立即生效,需要flush shared pool之后才会生效
主库创建用户并尝试登录
[oracle@primary ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Tue Sep 3 17:24:12 2019 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options SQL> select open_mode,database_role from v$database; OPEN_MODE DATABASE_ROLE -------------------- ---------------- READ WRITE PRIMARY SQL> create user xff identified by oracle; User created. SQL> grant dba to xff; Grant succeeded. SQL> conn xff/oracle Connected.
备库登录信息
[oracle@standby ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Tue Sep 3 17:17:47 2019 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> select database_role,open_mode from v$database; DATABASE_ROLE OPEN_MODE ---------------- -------------------- PHYSICAL STANDBY READ ONLY WITH APPLY [oracle@standby ~]$ ss SQL*Plus: Release 11.2.0.4.0 Production on Tue Sep 3 17:25:58 2019 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> conn xff/oracle Connected.
主库修改密码
[oracle@primary ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Tue Sep 3 17:17:47 2019 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> alter user xff identified by xff; User altered. SQL> conn xff/xff Connected.
备库尝试登录
SQL> conn xff/xff; ERROR: ORA-01017: invalid username/password; logon denied Warning: You are no longer connected to ORACLE. SQL> conn xff/oracle Connected.
备库原密码可以登录修改之后的密码无法登录
备库刷新shared pool,新密码登录成功
SQL> conn / as sysdba Connected. SQL> alter system flush shared_pool; System altered. SQL> conn xff/oracle ERROR: ORA-01017: invalid username/password; logon denied Warning: You are no longer connected to ORACLE. SQL> conn xff/xff Connected.
发表在 Data Guard
评论关闭
12.2 standby 报ORA-01110
12.2备库报错
2018-06-13T19:29:00.302767+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 1: '/u01/app/oracle/oradata/xifenfei/system01.dbf' 2018-06-13T19:29:00.829861+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 2: '/u01/app/oracle/oradata/xifenfei/rich101.dbf' 2018-06-13T19:29:00.930632+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 3: '/u01/app/oracle/oradata/xifenfei/sysaux01.dbf' 2018-06-13T19:29:01.010230+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 4: '/u01/app/oracle/oradata/xifenfei/undotbs01.dbf' 2018-06-13T11:29:01.055975+00:00 Archived Log entry 5072 added for T-1.S-5020 ID 0x6a8e9d72 LAD:1 RFS[18]: Selected log 10 for T-1.S-5024 dbid 1787743346 branch 957530932 2018-06-13T19:29:01.091059+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 5: '/u01/app/oracle/oradata/xifenfei/richman01.dbf' 2018-06-13T19:29:01.172613+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 7: '/u01/app/oracle/oradata/xifenfei/users01.dbf' 2018-06-13T19:29:01.251906+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 8: '/u01/app/oracle/oradata/xifenfei/r_index01.dbf'
trace文件
*** 2018-06-13T19:29:00.282836+08:00 *** SESSION ID:(2281.15120) 2018-06-13T19:29:00.282868+08:00 *** CLIENT ID:() 2018-06-13T19:29:00.282873+08:00 *** SERVICE NAME:(SYS$BACKGROUND) 2018-06-13T19:29:00.282878+08:00 *** MODULE NAME:(MMON_SLAVE) 2018-06-13T19:29:00.282883+08:00 *** ACTION NAME:(DDE async action) 2018-06-13T19:29:00.282888+08:00 *** CLIENT DRIVER:() 2018-06-13T19:29:00.282892+08:00 ========= Dump for error ORA 312 (no incident) ======== ----- DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (Async) ----- dbkh_reactive_run_check: BEGIN dbkh_reactive_run_check:; incident_id=0 dbkh_run_check_internal: BEGIN; check_namep=DB Structure Integrity Check, run_namep=<null> dbkh_run_check_internal: BEGIN; timeout=0 dbkh_run_check_internal: AFTER RUN CREATE; run_id=1841 *** 2018-06-13T19:29:00.302510+08:00 DDE previous invocation failed before phase II DDE was called in a 'No Invocation Mode' ----- Start Diag Diagnostic Dump ----- Diagnostic dump is performed due to an error in the diagfw code during error handling. Dump error and call stack for the diagnostic dump: *** 2018-06-13T19:29:00.302576+08:00 dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=1, mask=0x0) ----- Error Stack Dump ----- ORA-01110: data file 1: '/u01/app/oracle/oradata/xifenfei/system01.dbf' ----- SQL Statement (None) ----- Current SQL information unavailable - no cursor. ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- ksedst()+119 call kgdsdst() 7FFF1A0D6C68 000000002 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 000000082 ? dbkedDefDump()+1200 call ksedst() 000000000 000000002 ? 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 ? 000000082 ? ksedmp()+259 call dbkedDefDump() 000000001 000000000 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 ? 000000082 ? dbgexExecuteIntDiag call ksedmp() 000000001 000000000 ? Dmp()+1457 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 ? 000000082 ? dbgeBeginInvoke()+3 call dbgexExecuteIntDiag 7F5A00000003 7F5A99B856C0 59 Dmp() 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 ? 000000082 ? dbgePostErrorKGE()+ call dbgeBeginInvoke() 7F5A99B856C0 7FFF1A0D7D20 1676 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 ? 000000082 ? dbkePostKGE_kgsf()+ call dbgePostErrorKGE() 7F5A99BC59A0 7F5A99AA0048 90 000000456 7FFF1A0B87E8 ? 000000000 ? 000000082 ? kgeade()+432 call dbkePostKGE_kgsf() 7F5A99BC59A0 7F5A99AA0048 000000456 7FFF1A0B87E8 ? 000000000 ? 000000082 ? kgerelv()+144 call kgeade() 7F5A99BC59A0 ? 7F5A99BC5BE8 ? 7F5A99AA0048 ? 000000456 ? 000000000 000000000 kgerev()+36 call kgerelv() 7F5A99BC59A0 ? 7F5A99AA0048 ? 7F5A99AA0048 ? 000000456 ? 012E79CF4 ? 000000002 ? kserec2()+185 call kgerev() 7F5A99BC59A0 ? 7F5A99AA0048 ? 7F5A99AA0048 ? 000000456 ? 7FFF1A0D8000 000000002 ? kcf_record_fn()+634 call kserec2() 7F5A99BC59A0 ? 000000000 000000001 000000001 00000002C 141E0C518 kcvvra_dfh()+5278 call kcf_record_fn() 000000001 151622BB8 000000000 7FFF1A0DA5D8 00000002C ? 141E0C518 ? kcidr_file_header_c call kcvvra_dfh() 7FFF1A0DA460 ? 7FFF1A0D9FE8 ? heck_common()+4669 000000000 ? 7FFF1A0D9398 7F5A94379000 ? 000000001 ? kcidr_file_header_a call kcidr_file_header_c 7F5A99A9F7A0 7F5A94379000 ll_check_common()+2 heck_common() 000000001 000000000 259 7F5A94379000 ? 000000000 kcidr_cross_check() call kcidr_file_header_a 7F5A99A9F7A0 7FFF1A0DABE4 +566 ll_check_common() 000000001 ? 000000000 ? 7F5A94379000 ? 000000000 ? dbkird_cross_check( call kcidr_cross_check() 7F5A99A9F7A0 7FFF1A0DABE4 ? )+557 7F5A99BC5BE8 000000000 ? 7F5A94379000 ? 000000000 ? dbkh_run_check_inte call dbkird_cross_check( 7F5A99A9F7A0 7FFF1A0DABE4 ? rnal()+2228 ) 7F5A99BC5BE8 ? 000000000 ? 7F5A94379000 ? 000000000 ? dbkh_reactive_run_c call dbkh_run_check_inte 7FFF1A0DB970 000000000 heck()+3011 rnal() 000000002 000000000 000000000 000000000 dbgdaAsyncReceive() call dbkh_reactive_run_c 7F5A99B856C0 7FFF1A0DBC90 +279 heck() 000000002 ? 000000000 ? 000000000 ? 000000000 ? dbgea_exec_()+1739 call dbgdaAsyncReceive() 7F5A99B856C0 0020C0029 7FFF1A0E7CA0 7FFF1A0E7D20 000000002 000000000 ? dbgea_exec()+621 call dbgea_exec_() 7F5A99B856C0 7F5A94984D18 0000000E8 000000000 000000002 ? 000000000 ? dbkea_exec()+1718 call dbgea_exec() 7F5A99B856C0 7F5A94984D18 0000000E8 000000000 000000002 ? 000000000 ? dbkea_slave_exec()+ call dbkea_exec() 7F5A99B856C0 ? 7F5A94984D18 ? 518 0000000E8 ? 000000000 ? 000000002 ? 000000000 ? kebm_slave_cb()+64 call dbkea_slave_exec() 1453D7248 7F5A94984D18 ? 0000000E8 ? 000000000 ? 000000002 ? 000000000 ? kebm_slave_main()+7 call kebm_slave_cb() 1453D7248 ? 7F5A94984D18 ? 72 0000000E8 ? 000000000 ? 000000002 ? 000000000 ? ksvrdp_int()+2010 call kebm_slave_main() 1453D7248 ? 1453D7248 0000000E8 ? 000000000 ? 000000002 ? 000000000 ? opirip()+602 call ksvrdp_int() 000000000 ? 000000000 ? 0000000E8 ? 000000000 ? 000000002 ? 000000000 ? opidrv()+602 call opirip() 000000032 000000004 7FFF1A0EAD98 000000000 ? 000000002 ? 000000000 ? sou2o()+145 call opidrv() 000000032 000000004 7FFF1A0EAD98 000000000 ? 000000002 ? 000000000 ? opimai_real()+202 call sou2o() 7FFF1A0EAD70 000000032 000000004 7FFF1A0EAD98 000000002 ? 000000000 ? ssthrdmain()+417 call opimai_real() 000000000 7FFF1A0EB080 000000004 ? 7FFF1A0EAD98 ? 000000002 ? 000000000 ? main()+262 call ssthrdmain() 000000000 000000003 7FFF1A0EB080 000000001 000000000 000000000 ? __libc_start_main() call main() 000000000 7FFF1A0EB2B8 +245 7FFF1A0EB080 ? 000000001 ? 000000000 ? 000000000 ? _start()+41 call __libc_start_main() 000D05240 000000001 7FFF1A0EB2B8 7F5A95015C05 ? 000000000 ? 000000000 ? --------------------- Binary Stack Dump ---------------------
BUG:24844841 – PHSB:CDB M000 REPORTED ORA-1110 ON ADG WHEN A DATAFILE IS ADDED ON PRIMARY
@ The M000 messages is a false alarm as well. It is a false alarm by DRA check
@ that doesn’t consider standby media recovery properly. Adding a file happens
@ to trigger the timing for the false alarm.
@ One way to fix this is to skip file header check if standby recovery is
@ running inside kcidr_file_header_all_check_common.
M000进程检查数据库文件头信息,由于bug原因报ORA-01110错误.
处理建议
1.打上补丁24844841
2.19.1版本修复该问题
3.重启备库,启动mgr
4.暂时忽略该问题(目前没有发现影响数据库同步)
参考:ORA-01110 For All Files In Standby Database (Doc ID 2322290.1)