数据库版本：11.2.0.4
操作系统内核版本：CentOS Linux release 7.4.1708 (Core)
数据库架构：11G R2 RAC环境
巡检发现数据库最近发生了重启，通过GV$DATABASE视图查到具体的时间点，初步定为认为是数据库负载过大导致的，尝试打印相应的awr报告和通过对应时间点的alter日志查看是否有报错。
找到最近一次重启的时间点，按照时间点打印对应的awr或是ash报告分析数据库负载。
▼▼▼set feedback off
set linesize 256
set pagesize 50000
set long 999999999
alter session set nls_date_format=yyyy-mm-dd hh24:mi:ss;
alter session set NLS_TIMESTAMP_FORMAT=YYYY-MM-DD HH24:MI:SS.FF;
alter session set NLS_TIMESTAMP_TZ_FORMAT=YYYY-MM-DD HH24:MI:SS.FF TZH:TZM;
select d.inst_id,d.name,i.instance_name,i.startup_time,i.status,d.open_mode from gv$database d,gv$instance i where d.inst_id=i.inst_id;
通过打印AWR报告发现12号当天固定时间点出现断点，从awr报告的断点中可以知道12号0点，2点，4点，6点直到当天的14点，固定整点发生节点一重启问题。
less log.xml
查询/ORA-07445报错，核实对应时间点都有ORA-07445报错，初步猜测数据库一节点自动重启和这个报错相关，时间点刚好吻合。
发现trace日志中有一个存储过程，采用拼接的方式绑定大量变量，绑定变量的个数查过数据库上线65535。
按照截图收缩可以找到对应的mos文章737378.1。核实数据库触发了 Bug 12578873
，此bug完全符合此场景。
经核实目前11.2.4版本，此bug提供的修复平台只有exadata和windows平台，因此只能采取Workaround给出的建议，协调开发修改存储过程逻辑，减少变量的绑定，避免触发此bug，最终开发修改了相关逻辑，数据库因此导致的宕机问题消除。
Workaround
更多精彩干货分享
点击下方名片关注
IT那活儿
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/129861.html
摘要：新晋技术专家下面是墨天轮部分新晋的技术专家。大家可以点击往期阅读墨天轮技术专家邀请函了解详情，申请成为我们的技术专家，加入专家团队，与我们一起创建一个开放互助的数据库技术社区。新关联公众号墨天轮是一个开放互助的数据库技术社区。 引言 近期我们在DBASK小程序增加了数据库 MongoDB、Redis、 Elasticsearch、DB2、Weblogic 等新的的专题栏目和一些新的技术...
RAC补丁日常更新成功反遇异常处理 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; m...
阅读 1343·2023-01-11 13:20
阅读 1679·2023-01-11 13:20
阅读 1130·2023-01-11 13:20
阅读 1852·2023-01-11 13:20
阅读 4095·2023-01-11 13:20
阅读 2703·2023-01-11 13:20
阅读 1383·2023-01-11 13:20
阅读 3590·2023-01-11 13:20
