Oracle故障处理秘籍（一）

Oracle故障处理秘籍（一）

Whoami：5年+金融、政府、医疗领域工作经验的DBA
Certificate：OCP、PCP
Skill：Oracle、Mysql、PostgreSQL
Platform：CSDN、墨天伦、公众号（呆呆的私房菜）

业务范围：数据库安装部署、日常维护、主备切换、故障处理、性能优化、技术培训等。
需要的伙伴或者商业合作请移步 公众号【呆呆的私房菜】获取联系方式。

阅读本文可以了解Oracle常见故障及解决办法，帮助DBA快速排查和解决生产故障问题。

01 TX、TM、DX

现象：数据库大量锁异常等待，系统资源消耗高，CPU负载高。
原因：数据库存在多个事务争用。
解决方法：使用如下SQL查询，定位到长时间不变的holder，kill相关会话。

column event format a30  
column sess format a20
set linesize 250
set pagesize 0
break on id1 skip 1
select decode(request,0,'Holder:',' Waiter:') || s.inst_id || ':' || s.sid||','|| s.serial# sess,
      id1, id2, lmode, request, l.type, ctime, s.username,s.sql_id, s.event, s.service_name
  from gv$lock l, gv$session s
  where (id1, id2, l.type) in
    (select id1, id2, type from gv$lock where request>0
    )
   and l.sid=s.sid
   and l.inst_id=s.inst_id    
  order by id1, ctime desc, request 
/

alter system kill session '<sid>,<serial#>' immediate;

02 Cache buffer chains

现象：数据库大量cache buffer chains等待，系统资源消耗高，CPU负载高。
原因：

1. 低效的SQL语句是最重要原因
2. 多个进程同时扫描大范围的索引或表
3. 应用程序并发执行相同低效率SQL

解决方法：定位该事件相关的会话信息，手工kill会话，记录该会话让对应开发商优化。

select sid,username,machine,program,p1raw,sql_id,logon_time,last_call_et from v$session where event='latch: cache buffers chains';
alter system kill session '<sid>,<serial#>' immediate;

03 library cache lock

现象：数据库大量library cache lock等待，系统资源消耗高，cpu负载接近100%。
原因：

1. 大量对某个对象访问
2. shared pool问题

解决方法：定位引发“library cache lock”的会话，分析SQL中相关对象和执行计划，与开发商确认后kill会话。若由于shared pool内部结构问题引发，则使用清空共享池方式处理。

select sql_id,count(*) from v$session where event='library cache lock' group by sql_id order by 2;
alter system kill session '<sid>,<serial#>' immediate;

# 下列命令，谨慎操作
alter system flush shared pool;

04 gc buffer busy

现象：数据库大量gc buffer busy等待，cpu占用高，IO繁忙。
原因：rac中多节点同时大量访问某些数据块引发
解决方法：

1. 查看gc buffer busy 事件相关会话
select sid,serial#, username,machine,program,p1raw,sql_id,logon_time,last_call_et from v$session where event='gc buffer busy';

2. 查看哪个sql执行次数最多
select sql_id,count(*) from v$session where event=' gc buffer busy ' group by sql_id order by 2;

3. 手动kill session
alter system kill session '<sid>,<serial#>' immediate;

05 cursor: pin S wait on X

现象：数据库性能下降，cpu和内存占用变高。
原因：

1. 硬解析
2. high version counts
3. bug

解决方法：

1. 查找等待事件的阻塞者
select p2raw, to_number(substr(to_char(rawtohex(p2raw)),1,8),'XXXXXXXX') sid from v$session where event = 'cursor: pin S wait on X';

2. 查看阻塞者在做什么
select sid,serial#,SQL_ID,BLOCKING_SESSION,BLOCKING_SESSION_STATUS,EVENT from v$session where SID=&SID;

3. 根据阻塞者的SQL分析产生原因

06 latch: undo global data

现象：数据库大量latch: undo global data等待，cpu使用率上升。
原因：一个大事务对某个表进行DML操作，使用大量undo空间。大量并发语句发起对这个表的操作时，由于一致性读，需要使用undo记录进行回滚，产生了该等待。
解决方法：

1. 定位session使用undo量的sql
SELECT r.name rbs,
       nvl(s.username, 'None') oracle_user,
       s.osuser client_user,
       p.username unix_user,
       s.sid,
       s.serial#,
       p.spid unix_pid,
       t.used_ublk * TO_NUMBER(x.value) / 1024 / 1024 as undo_mb ,
       TO_CHAR(s.logon_time, 'mm/dd/yy hh24:mi:ss') as login_time,
       TO_CHAR(sysdate - (s.last_call_et) / 86400, 'mm/dd/yy hh24:mi:ss') as last_txn,
       t.START_TIME transaction_starttime
 FROM v$process      p,
       v$rollname    r,
       v$session     s,
       v$transaction t,
       v$parameter   x 
 WHERE s.taddr = t.addr 
   AND s.paddr = p.addr 
   AND r.usn = t.xidusn(+) 
   AND x.name = 'db_block_size' 
 ORDER by undo_mb desc
/

2. 大事务对数据库和应用影响还不大的情况下，可以采用的办法：
① 查找v$session_longops，评估是让事务继续执行或kill的代价，选择较低代价。
② 如果选择kill会话，可以开启并发回滚事务的特性，加快事务回滚。

3. 大量并发语句，大量"latch: undo global data'等待，应用已经无法响应，cpu使用率达到90%以上的情况：
① 联系应用是否可以使用空表临时代替，可以的话，kill session后，将表进行rename，重建空表，让应用临时使用，后续采用分批提交的方式，将原表数据插入到空表。
② 如果不能空表替代，只能暂停应用，kill会话等待cpu恢复正常后并发回滚。