ADG terminated by LGWR, terminating the instance

11.2.0.4 RAC TO RAC FOR ADG环境。由于历史原因,备库节点二一直没有启动,一直是启动节点一对外提供服务。节点一alert报错,lgwr进行kill实例操作并自行重启。
Mon Dec 24 16:11:24 2018
Archived Log entry 262740 added for thread 2 sequence 185858 ID 0x92570693 dest 1:
Mon Dec 24 16:12:28 2018
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x7FFCD7489FF8] [PC:0x9899B16, qcsAnalyzeBooleanExpr()+144] [flags: 0x0, count: 1]
Errors in file /u01/app/oracle/diag/rdbms/qdb/qdb1/trace/qdb1_ora_18912.trc (incident=580470):
ORA-07445: exception encountered: core dump [qcsAnalyzeBooleanExpr()+144] [SIGSEGV] [ADDR:0x7FFCD7489FF8] [PC:0x9899B16] [Address not mapped to object] []
Incident details in: /u01/app/oracle/diag/rdbms/qdb/qdb1/incident/incdir_580470/qdb1_ora_18912_i580470.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.

根据抛出的trc文件,我们可以追踪到时间段内的某条SQL

** 2018-12-24 16:12:28.596
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x3, level=3, mask=0x0)
----- Current SQL Statement for this session (sql_id=34vxxxxxx) -----
select
from MSS.T_MSS_MOBILE_LOGIN_ADDR where UUID in (‘7xxxxx4xxxxxx‘, ‘48xxxxxxx, 。。。。。。
整个trc文件190M,文本内容UUID几乎占了整个文件。

new 2: where owner = ‘MSS‘ and segment_name = ‘T_MSS_MOBILE_LOGIN_ADDR‘

OWNER SEGMENT_NAME SEGMENT_TYPE Total_Bytes(MB)



MSS T_MSS_MOBILE_LOGIN_ADDR TABLE PARTITION 230054

[[email protected] trace]$ du -sh /u01/app/oracle/diag/rdbms/qdb/qdb1/incident/incdir_580470/qdb1_ora_18912_i580470.trc
190M /u01/app/oracle/diag/rdbms/qdb/qdb1/incident/incdir_580470/qdb1_ora_18912_i580470.trc

紧接着系统报了4021错误代码
Mon Dec 24 16:30:17 2018
System State dumped to trace file /u01/app/oracle/diag/rdbms/qdb/qdb1/trace/qdb1_ora_67693.trc
Mon Dec 24 16:32:32 2018
Errors in file /u01/app/oracle/diag/rdbms/qdb/qdb1/trace/qdb1_lgwr_39157.trc:
ORA-04021: timeout occurred while waiting to lock object
LGWR (ospid: 39157): terminating the instance due to error 4021
一直到最后的kill 实例,自动重启
Mon Dec 24 16:32:39 2018
License high water mark = 1203
Instance terminated by LGWR, pid = 39157
USER (ospid: 6702): terminating the instance
Instance terminated by USER, pid = 6702
Mon Dec 24 16:32:48 2018
Starting ORACLE instance (normal)

查询MOS相关文档,有一篇文档与我们的环境相符
ORA-04021: timeout occurred while waiting to lock object : DR Instance terminated by LGWR (文档 ID 2183882.1)

命中了BUG了。根据bug描述,需要修改参数
SQL> show parameter cursor_sharing

NAME TYPE VALUE



cursor_sharing string EXACT
在cursor设置为exact时,两条sql语句如果存在一点不同,就不会共享cursor,而进行两次硬解析。
设置为force时Oracle对输入的SQL值,会将where条件取值自动替换为绑定变量。以后在输入相同的结构SQL语句时,会进行cursor sharing共享游标
根据这个临时方案,我做了一个小实验。我在主库创建了一个t表作为该参数的测试

14:35:02 [email protected](bapdb1)> create table t as select * from dba_objects;

Table created.

然后到备库进行具体实验。


Mark一下,择日进行参数修改。

原文地址:http://blog.51cto.com/yangjunfeng/2335176

时间: 2024-10-19 12:22:33

ADG terminated by LGWR, terminating the instance的相关文章

微软云azure部署oracle报错:PMON (ospid: 7504): terminating the instance due to error 822

oracle11g启动报错,startup nomount失败,后台alert报错日志如下: [[email protected] dbs]$ more /oracle/app/oracle/diag/rdbms/pdunq/powerdes/trace/alert_powerdes.log Wed Feb 03 20:56:28 2016 Starting ORACLE instance (normal) .... dispatchers = "(PROTOCOL=TCP) (SERVICE=

oracle 数据库无法启动,报错 terminating the instance due to error 16014

前言: 早晨上班,开发告知数据库连接不上,说是报内存溢出,查看内存空余空间确实不足,遂将高内存进程结束,但结束后还是连接不上,重启数据库,悲剧发生了,数据库居然启不来了,因前一天改了下dastart文件,已为是文件改动的问题,但使用sqlpuls /as nolog登陆后 conn /as sysdba连接数据再startup也是启不来. 之前没有接触过oracle数据库,想先找找错误日志吧,看看有没有报错,结果一顿找,也没找到错误日志在哪,不过后来找到一个启动日志/oracle/app/ora

terminating the instance due to error 119

RAC安装过程一切正常,关机重启后,GI启动正常,实例没起来. [[email protected] network-scripts]# crsctl stat res -t -------------------------------------------------------------------------------- NAME           TARGET  STATE        SERVER                   STATE_DETAILS ------

解决terminating the instance due to error 481导致ASM无法启动故障

1.现象描述 一个RAC数据库,意外DOWN机后,第一个节点正常启动,但是第二个节点却无法启动ASM和CRS资源. 2.分析原因 由于ASM磁盘组无法启动,查看ASM日志发现如下信息: MMNL started with pid=21,OS id=14028 lmon registered with NM -instance number 2 (internal mem no 1) Tue Nov 18 14:48:50 2014 PMON (ospid:13986): terminating

PMON (ospid: 2853): terminating the instance due to error 471

今早发现oracle数据库宕库 ,重新启动数据库正常,之后查询alter日志发现在 23点出现 PMON (ospid: 2853): terminating the instance due to error 471 导致数据库停止 日志截图 alter log日志 Wed Mar 08 23:36:02 2017System state dump requested by (instance=1, osid=2853 (PMON)), summary=[abnormal instance t

private 网络不稳定引起的Evicting instance 2 from cluster

环境:双节点RAC, oracle 11.2.3 客户电话RAC实例2异常,现场查看日志: 实例2: Fri Aug 25 09:45:16 2017 Received an instance abort message from instance 1Received an instance abort message from instance 1 Please check instance 1 alert and LMON trace files for detail.Please chec

一条命令搞定ADG

最近一直在搭建ORACLE 12C ADG ,其中包括单机到单机的ADG, RAC到RAC的ADG,还有RAC到单机的ADG,遇到不少小问题,在此做一下记录. Oracle 12c R1 RAC 修改启动方式 $srvctl modify database -d orcldg -s nomount  orcldg为数据库名 $srvctl modify database -d orcldg -s mount $srvctl modify database -d orcldg -s open 置完

Oracle12cR1 Data Guard 实施文档

目录 1. Data Guard概述. 5 1.1 DG 日志传递模式-图文并茂. 5 2. DG 搭建过程. 6 2.1 主数据检查. 6 2.2 主数据库添加standby redo log 7 2.3 主数据库创建参数文件. 8 2.4 备数据库启动到nomount状态. 8 2.5 主数据库创建备库控制文件. 10 2.6 主数据库配置网络参数. 11 2.7 备数据库网络参数配置. 13 2.8 备库密码文件. 15 2.9 主备数据库网络测试. 15 2.10 主数据库全库备份. 1

Oracle Study之--DataGuard 最大保护模式故障(ORA-16198)

Oracle Study之--DataGuard 最大保护模式故障(ORA-16198) 系统环境:     操作系统:RedHat EL5     Oracle:   Oracle 11gR2 (11.2.0.1.0) 故障现象: Physical Standby在从Maximum Performance转换到Maximum Protection时,出现以下故障: 10:13:06 [email protected] prod1>startup force mount; ORACLE inst