oracle数据库常见故障处理解决办法

实例管理类    
等待事件类    
“TX,TM,DX”锁应急处理    
“Latch free”应急处理    
“Cache buffer chains”应急处理    
“Library cache lock”应急处理    
“gc buffer busy”应急处理    
“cursor: pin S wait on X”事件应急处理    
“latch: undo global data”事件应急处理    
“enq:US-content” or 回滚表空间使用过度事件应急处理    
“gc buffer busy”问题    
资源消耗类    
高资源消耗进程应急处理    
IO非常高    
PGA使用过大    
CPU使用过高应急处理    
大表索引被删除导致CPU 100%的应急处理    
网络连接类    
连接不上数据库    
客户端不定时断开连接    
通过监听无法连接数据库    
空间管理类    
表空间故障应急处理    
SYSAUX表空间爆满没有存储扩容应急处理    
文件系统使用率达到或超过95%应急处理    
临时表空间过度事件应急处理    
undo表空间无法自动扩展    
undo表空间无法扩展    
数据库恢复类    
CRS资源异常类    
RAC数据库CRS无法正常启动    
VIP资源DOWN异常处理    
数据库HANG类    
数据库HANG异常处理    
数据库CRASH类    
实例CRASH应急处理    
应用操作类    
SQL执行计划变化应急处理    
使用绑定变量SQL突然运行缓慢的应急处理    
其他分类    
升级PSU系统报错    
数据库在执行过程中使用动态采样    
通过srvctl查看数据库的状态时反应缓慢    


实例管理类
等待事件类
“TX,TM,DX”锁应急处理
现象描述：
数据库大量锁异常等待，系统资源消耗高，cpu负载高 （针对大量'TX,TM,DX'等类型的锁造成的大量异常等待）

影响因素:
多个事务争用造成。

解决方法
以下语句列出是谁造成了阻塞
 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 
/

按照这个语句多查询几次，如果Holder不变，则KILL掉。操作前记录相关日志

“Latch free”应急处理
现象描述：
数据库大量latch free等待，系统资源消耗高，cpu负载接近100%

影响因素:

解决方法:
1.查询当前active的会话模块：
select username,machine,count(*) from v$session where status='ACTIVE' having count(*)>6 group by username,machine order by 1;
将会话数量过多的模块通知开发商，让他们切换部分业务到另外一个节点
然后进行系统资源监控和数据库监控

“Cache buffer chains”应急处理
现象描述：
数据库大量cache buffer chains等待，系统资源消耗高，cpu负载高

影响因素:
A.低效的SQL语句是发生 cache buffers chains(热块争用），锁存器争用的最重要原因。
B.多个进程同时扫描大范围的索引或表时，可能广泛引发cache buffers chains 锁存器争用。
C.应用程序打开执行相同的低效率SQL语句的多个并发会话，并且这些SQL语句都设法得到相同的数据集，这种情景十分普遍。

解决方法:
1.查看 latch: cache buffers chains 事件相关的会话信息;
select sid,username,machine,program,p1raw,sql_id,logon_time,last_call_et from v$session where event='latch: cache buffers chains';
使用ora命令  ora get_kill_sh &sql_id &username 进行查杀.
查杀后记录该sql语句,丢给相应的开发商处理

2、查看哪个SQL执行的次数最多
select sql_id,count(*) from v$session where event='latch: cache buffers chains' group by sql_id order by 2;

“Library cache lock”应急处理
现象描述：
数据库大量library cache lock等待，系统资源消耗高，cpu的idle为0

影响因素:
library cache lock出现的情况比较复杂，例如：
A、大量对某个对象访问；
B、shared pool有问题；

解决方法:
1、看看是不是某条SQL引起
select sql_id,count(*) from v$session where event='library cache lock' group by sql_id order by 2;
然后分析SQL中的对象和执行计划等，再跟开发商确认，用ora get_kill_sh进行杀
2、shared pool的内部结构造成，再开一个窗口用topas监控系统资源，然后清理shared pool
alter system flush shared pool; （该操作需要向直属领导确认）

“gc buffer busy”应急处理
现象描述：
一般的现象为CPU较高，IO较忙，处理方法与cache buffer chains应急处理一样

影响因素:
gc buffer busy出现在RAC中，出现概率并不高，因为BOSS是对业务做了分离的，是由于多节点同时大量访问某些数据块引起的

解决方法:
1.查看 latch: cache buffers chains 事件相关的会话信息;
select sid,serial#, username,machine,program,p1raw,sql_id,logon_time,last_call_et from v$session where event='gc buffer busy';
使用ora命令alter system kill session 'sid,serial#' 进行查杀.
查杀后记录该sql语句,丢给相应的开发商处理
2、查看哪个SQL执行的次数最多
select sql_id,count(*) from v$session where event=' gc buffer busy ' group by sql_id order by 2;

“cursor: pin S wait on X”事件应急处理
现象描述：

影响因素：
一般包含以下几种：
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=31;
3、根据阻塞者的SQL分析产生原因。

“latch: undo global data”事件应急处理
现象描述：
一个大事务对某个表进行DML操作，使用大量undo空间。大量并发语句发起对这个表的操作，由于一致性读，需要使用undo记录进行回滚，产生latch:undo global data等待，cpu使用率上升

影响因素：
一般包含以下几种：
1、大事务对某个表进行DML操作

解决方法：
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、大事务对数据库和应用影响还不大得情况下，可以采取的方法：
   a.查找v$session_longops，评估是让事务进行还是Kill发起大事务的session各自的代价，选择其中一个代价较低的方式。
   b.如果是选择kill掉session，可以开启并发回滚事务的特性，加快事务回滚。

3、大量并发语句，大量’latch:undo global data’等待，应用已经无法响应，CPU使用90%以上的情况：
   a.此时不管是采用何种回滚特性（并发回滚、单进程回滚）,由于已经没有cpu资源，回滚都非常耗时。
   b.联系应用确认是否可以空表暂时代替，如果可以，可以再kill掉session后，将表rename掉，重新建一种空表，让应用临时使用。
   c.后续使用分批提交的方式，将源表数据回插空表。
   d.如不能空表代替，则只能暂停应用，kill掉等待session，cpu恢复正常后并发回滚，或建空表回插数据。
4、事件处理完毕后，对发起大事务的程序发给应用侧修改，如果是个人发起，则加强培训。

“enq:US-content” or 回滚表空间使用过度事件应急处理
现象描述：

影响因素：

一般包含以下几种：
1、 回滚表空间使用过度，session发起新事务查找回滚段时需要排队等待
2、 Oracle Bug

解决方法：
1、查找undo表空间使用情况的SQL：
select b.tablespace_name,
       nvl(used_undo,0) "USED_UNDO(M)",
       total_undo "Total_undo(M)",
       trunc(nvl(used_undo,0) / total_undo * 100, 2) || '%' used_PCT
  from (select nvl(sum(bytes / 1024 / 1024), 0) used_undo, tablespace_name
          from dba_undo_extents
         where status in ( 'ACTIVE','UNEXPIRED')
         group by tablespace_name) a,
       (select tablespace_name, sum(bytes / 1024 / 1024) total_undo
          from dba_data_files
         where tablespace_name in
               (select value
                  from v$spparameter
                 where name = 'undo_tablespace'
                   and (sid = (select instance_name from v$instance) or
                       sid = '*'))
         group by tablespace_name) b
 where a.tablespace_name (+)= b.tablespace_name
/
2、回滚表空间中大部分都是ACTIVE extent的情况
   a.查询是哪些session引起，用“二十”中提供的SQL
   b.临时新增undo数据文件解决
   c.事后根据查找到的session对提交应用侧修改程序。个人引起则加强培训 
3、回滚表空间中大部分都是UNEXPIRED extent的情况
   a.减小undo_retention值
b.如果undo_retention的值正常，则新增undo数据文件，加大undo表空间 
  回滚表空间使用情况正常
a.查看undo相关的隐含参数是否设置正确。

“gc buffer busy”问题
现象描述：
    环境：SunOS 5.9(64bit, sparc)+RAC+oracle 10.2.0.3
    场景：话务性能库不断报出 gc buffer busy ，系统资源消耗较高。

影响因素:
    以下几点可导致此事件：
    A、Hot Blocks；
    B、低效率的查询；

解决方法:
    1、查询事件相关用户，sql
    select sid,username,machine,program,p1raw,sql_id,logon_time,last_call_et from v$session where event='gc buffer busy';

    2、根据sql_id,username查询出sql，分析执行效率，与厂商协商解决。
select sql_text from v$session from v$sqlarea where sql_id = 'xx';

资源消耗类
高资源消耗进程应急处理
现象描述：
某个oracle process  CPU使用率非常高。 
某个oracle process  MEM使用率非常高。

影响因素：
暂无

解决方法：
1、使用TOPAS观察哪个进程CPU使用率高，找出相关进程号，通过以下命令定位数据库SID号. 
Select sid,sql_id,event,status from v$session where paddr in (select addr from v$process where spid=&进程号);
2、使用以下命令查看oracle会话使用内存超过100M的用户
set line 180
col MACHINE for a10
col PROGRAM for a25
col USERNAME for a15
select s.sid, s.serial#, s.username, s.machine, s.program,s.process, s.sql_id, p.pga_alloc_mem/1048576 size_m, p.spid
 from v$session s, v$process p where s.paddr=p.addr 
 and p.pga_alloc_mem>104857600 order by 7 desc;

3、对相关进程和会话进行分析，决定是否kill.

IO非常高
现象描述：
数据库登陆缓慢，或者根本不可用，无法登陆数据库进行查询等操作。表空间满或者文件系统满了（一般情况下不会发生，因为我们有监控告警）。这里主要是针对异常sql引起数据库hang的情况

影响因素:
分析IO高的原因，例如：
A、大量的并行；
B、长事务；
C、物理读高


解决方法:
在操作系统使用命令: ps -ef|grep LOCAL=NO |awk '{print $2}' |xargs kill -9
kill所有非本地进程,然后检查系统资源状态，检查数据库状态

PGA使用过大
现象描述：
影响SQL执行的效率

影响因素:
PGA使用过大

解决方法：
1、查询当前PGA使用大小：
select sum(pga_alloc_mem)/1048576/1024 size_gb from v$process ;
 
2.查询使用PGA较大的具体进程
例如以下语句可以查出具体占用内存大于100m的进程信息:(例如）
set line 180
col MACHINE for a10
col PROGRAM for a25
col USERNAME for a15
select s.sid, s.serial#, s.username, s.machine, s.program,s.process, s.sql_id, p.pga_alloc_mem/1048576 size_m, p.spid
 from v$session s, v$process p where s.paddr=p.addr 
 and p.pga_alloc_mem>104857600 order by 7 desc;

3.咨询开发商是否可以删除语句
alter system kill session 'sid,serial#';

CPU使用过高应急处理
现象描述：
CPU中 usr%使用率达到90以上

影响因素：
CPU使用过高，一般表现在以下几点：
A、不良SQL造成的大量等待事件
B、大量的短连接造成CPU负载高。
C、BUG引起

解决方法：
1、当CPU出现高负载的时候，首先我们要检查当前的数据库里是否有大量异常等待，例如：latch free, library cache lock/pin 等待事件。
select event,count(*),wait _class from v$session group by event,wait_class order by 2;
如果有，根据相关等待事件分析问题。也可以通过HANG分析，进行阻塞源头会话定位。
2、当CPU出现高负载的时候，检查发现当前数据库并无任何异常等待事件，我们就要参考平时的CPU使用率指标，然后通过会话、事务量来衡量。
3、当CPU出现高负载的时候，检查发现当前数据库并无任何异常等待事件，当前活动SQL语句与平时差别很大，我们可以关闭监听，检查是否由于连接造成的。

大表索引被删除导致CPU 100%的应急处理
现象描述：

CPU使用率90%以上

影响因素：

大表上索引被删除，部分SQL全表扫描导致资源集聚消耗。

解决方法：
1、查找某个实例上等待session的信息，定位低效SQL：
select to_char(a.logon_time,'yyyy-mm-dd hh24:mi') logon_time,
       a.sql_id,
       a.event,
       a.username,
       a.osuser,
       a.process,
       a.machine,
       a.program,a.module,
       b.sql_text,
       b.LAST_LOAD_TIME,
       to_char(b.last_active_time,'yyyy-mm-dd hh24:mi:ss') last_active_time,
       c.owner,c.object_name,
       a.last_call_et,
       a.sid,a.SQL_CHILD_NUMBER,
       c.object_type,p.PGA_ALLOC_MEM,a.p1,a.p2,a.p3,
       'kill -9 '||p.spid killstr
  from v$session a, v$sql b, dba_objects c,v$process p
 where a.wait_class <> 'Idle' and a.status='ACTIVE' and p.addr=a.paddr
   and a.sql_id = b.sql_id(+) 
   and a.sql_child_number = b.CHILD_NUMBER(+)
   and a.row_wait_obj# = c.object_id(+)
   and a.type='USER'
 order by a.sql_id,a.event;
2、非rac环境 
a.部分大表索引删除，导致全表扫面，cpu 100%
   b.此时数据库基本处于hang状态，应用已经无法响应
   c.停止相关应用，kill掉这些等待session, 新建索引（parallel nologging）
   d.如果无法停止应用，停止数据库的监听，kill掉等待session，新建索引（parallel nologging）
3、rac环境 
a.部分大表索引删除，导致全表扫面，cpu 100%
   b.此时该节点基本处于hang状态，应用已经无法响应
   c.停止相关应用，kill掉这些等待session, 新建索引（parallel nologging）
   d.如果无法停止应用，停止所有节点的监听，kill掉等待session，新建索引（parallel nologging）

网络连接类
连接不上数据库
现象描述：
数据库无法连接

影响因素:
客户报连接不上数据库，例如：
1、连接数达到上限；
2、监听有问题；

解决方法:
1、看看连接数
show parameter session;
select count(*) from v$session;
若我们用sqlplus / as sysdba也无法连接，则先KILL掉几个LOCAL=NO的会话，然后再进去分析是哪个模块的连接较多，然后通知开发商处理
ps -ef | grep LOCAL=NO  --找出PID，KILL掉几个
select machine,program,count(*) 
from v$session group by machine,program order by 3;  --找出较多的模块

2、查看监听
lsnrctl status
看看状态是不是ready，或者reload一次，看看故障是否能恢复

客户端不定时断开连接
现象描述：
    环境：Aix+RAC+ORACLE 11.2.0.2.0
    现象：PL/SQL等开发工具连接数据库后，会不定时的断开连接，断开后界面无反应，经过长时间才能重连，影响开发工作。根据现场观察到的故障现象：
    1、检查数据库的各项相关设置，包括系统超时限制、用户资源限制和网络超时限制等方面，均未发现异常。
    2、在不同网段进行模拟，发现所有网段均有断开连接现象发生。
    3、经过长时间和全方面的模拟测试，发现断开规律为idle超过10分钟的数据库连接会被自动断开。

影响因素:
    一般情况下，为网络、防火墙策略限制.

解决方法:
    重新修改网管防火墙相关限制项。

通过监听无法连接数据库
现象描述：
    环境：Redhat+RAC+ORACLE 11.2.0.1.0
    现象：数据库工作状态正常，监听器工作状态也正常。并且，监听服务也已经注册了。但即使在服务器本地，通过监听无法访问数据库。通过tns访问数据库时，总是报lost connect的错误信息。直接登陆时没有问题。

现象分析:
    这个问题可能是oracle的一个bug，在排除了常用的解决办法办法之后，可以考虑修改$ORACLE_HOME/bin/oracle文件的权限。
    但这个问题在许多数据库并无法重现，在遇到这样的问题时，可以偿试这样解决一下。

解决方法:
    将$ORACLE_HOME/bin/oracle的权限更改为6571

空间管理类
表空间故障应急处理
现象描述：
场景一：在RAC环境下进行表空间扩容（添加数据文件）时，只在一个节点上对数据文件建立了软连接，另一个节点没有建立软连接。

场景二：在RAC环境下进行表空间扩容（添加数据文件）时，两个节点都没有建立软连接，只在一个节点的本地文件系统添加了数据文件，或者添加数据文件时有空格等特殊字符

场景三：不小心将其他环境的裸设备加到到当前的环境中。（绝不允许出现此类错误）


影响因素:
一般情况下，都属于人为错误.

解决方法:
（场景一）解决方法：
1、 将两个节点数据文件改为离线状态
alter database datafile 'XXX' offline;
2、 在问题节点对数据文件建立软连接
ln -s 裸设备 数据文件
3、 在问题节点恢复数据文件
recover datafile 'XXX';
4、 将数据文件改为在线状态
alter database datafile 'XXX' online;
5、 确认数据库告警日志无报错。

（场景二）解决方法：
1、 将问题节点数据文件改为离线状态
alter database datafile 'XXX' offline;
2、 在各节点对数据文件建立软连接
ln -s 裸设备 数据文件
3、 通过ALTER DATABASE CREATE DATAFILE ‘源文件’ AS ‘目标文件’;  
copy数据文件至目标位置
ALTER DATABASE CREATE DATAFILE '源文件' AS '目标文件';
4、 恢复数据文件
recover datafile '目标文件';
5、 将数据文件改为在线状态
alter database datafile '目标文件' online;
6、 将错误的本地数据文件移到其他路径，避免“/oracle”文件系统使用比率达到告警值。
7、 确认数据库告警日志无报错。

（场景三）解决方法：
1、 除了恢复，没有太好的方法。需要备份、归档都在。

SYSAUX表空间爆满没有存储扩容应急处理
现象描述：
如果SYSAUX 表空间不可用时，数据库的核心功能还是可以继续运行的。只是一些存放在SYSAUX表空间里的功能收到限制，比如OEM。

影响因素：
一般包含以下几种：
A、业务表被放在SYSAUX表空间
B、一些辅助表的数据量太大

解决方法：
检查SYSAUX中的对象，是哪个对象占用了大量空间.检查时业务表还是辅助表，确认该对象是否可以清理.
col segment_name format a30
col segment_type format a30
set linesize 300
select OWNER,SEGMENT_NAME,SEGMENT_TYPE,BYTES/1024/1024/1024 GB 
from dba_segments
where TABLESPACE_NAME='SYSAUX'
order by 4;

文件系统使用率达到或超过95%应急处理
现象描述：
使用df 命令查看文件系统使用率达到95%

影响因素：
备份文件、dump文件、trace文件等大量产生造成.

解决方法：
检查相关文件系统下面的文件大小：
例如：查看/u01目录下每个子目录的大小
du -sh /u01/* 
*/

根据需求进行清理.

临时表空间过度事件应急处理
现象描述：
临时表空间使用过度，需要使用临时表空间的SQL运行缓慢。

影响因素：
一般包含以下几种：
1、部分SQL大量使用临时段

解决方法：
1、查找单节点temp表空间使用情况的SQL：
SELECT A.tablespace_name tablespace,
       D.mb_total,
       SUM(A.used_blocks * D.block_size) / 1024 / 1024 mb_used,
       D.mb_total - SUM(A.used_blocks * D.block_size) / 1024 / 1024 mb_free
  FROM v$sort_segment A,
       (SELECT B.name, C.block_size, SUM(C.bytes) / 1024 / 1024 mb_total
          FROM v$tablespace B, v$tempfile C
         WHERE B.ts# = C.ts#
         GROUP BY B.name, C.block_size) D
 WHERE A.tablespace_name = D.name
 GROUP by A.tablespace_name, D.mb_total;

2、查询session使用temp段的情况：
   SELECT S.sid || ',' || S.serial# sid_serial,
       S.username,
       S.osuser,
       P.spid,
       S.module,
       S.program,
       s.sql_id
       SUM(T.blocks) * TBS.block_size / 1024  mb_used,
       T.tablespace,
       COUNT(*) sort_ops
  FROM v$sort_usage T, v$session S, dba_tablespaces TBS, v$process P
 WHERE T.session_addr = S.saddr
   AND S.paddr = P.addr
   AND T.tablespace = TBS.tablespace_name
 GROUP BY S.sid,
          S.serial#,
          S.username,
          S.osuser,
          P.spid,
          S.module,
          S.program,
          TBS.block_size,
          T.tablespace
 ORDER BY sid_serial;

3、 如果是某些session使用temp段过度引起
a. 联系应用停止相关程序 or kill掉这些session
4、 如果session使用temp情况都属正常情况  
b. 加大临时表空间

undo表空间无法自动扩展
现象描述：
环境：Aix+RAC+oracle 10.2.0.3.0
场景：数据库节点一，后台alter日志报：ORA-1628: max # extents  reached for rollback segment错误信息，使数据库的调度任务无法完成。

影响因素:
回滚段的maxextens数达到参数设置的最大值，造成不能分配下一个extent

解决方法
1.新建立一个表空间undo2，修改节点1的undo表空间为undo2后问题排除。
2.修改增大undo的maxextents参数值

undo表空间无法扩展
现象描述：
环境：Linux+ oracle 11.2.0.1.0
场景：在向数据库插入一条记录时，数据库频繁出现ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS1'的报错信息，无法插入记录。

影响因素:
产生该错误，通常是由于当前的UNDO表空间很小，并且在同时有一个很大的事务存在。并且，在Oracle看来，这种提示并不是一种异常。因此，您无法在该ORA报错的同时在alert文件中看到相关的信息，你只能通过相应的trace文件来看到这类的信息。
    当数据库产生上述信息时，在alert中会留下这样的信息：
    kdidelleafblks -- encountered error 30036. See trace file for details
    相应的trace文件中，会有这样的描述：
ORA-30036 DIAGNOSTIC 
   This diagnostic information is dumped to trace file at 
   most once every 24 hours, it does not indicate any error.
************************************************************
ORA-30036 happens when trying to extend undo segment _SYSSMU12_710107609$ (usn=12) by 8 blocks
Reason: Cannot Wrap, Fail to Steal
Current undo tablespace UNDOTBS1 (tsn=2)
undo tablespace current size 262144 blks, maxsize 262144 blks, fixed sized
Undo Retention (reactive):568, Max Query Length:1383
Parameter Undo Retention:900, Tuned Undo Retention:568, High threshold Undo Retention:-2 autotune:1
Retention Guarantee FALSE
Current Time is 1351615156
    同时，在该trace文件的Info about Undo Segments in this undo tablespace信息列表中，将会很容易找到当前存在的大事务。如：
  Undo Segment 1: HW Ext=2, 1st Active Ext=-1, Total Extents=3
  Extent Info of Undo Segment 1
  ExtID    Status     Size        CmtTime 
  ========================================
     0     Active        7      1351614703
     1     Active        8      1351614760
     2   Unexpired     128      1351614760
     2   Unexp wmql    128      1351614760
  ========================================
_SYSSMU1_2861643892$ (usn 1) is INUSE (act=16, une=128, exp=0)
(unewmql=128, expwmql=0)
    
解决方法：
    1、通过分析上述trace文件，可以找到当前存在的大事务，对该事务进行适当分解，减少对UNDO表空间的资源需求量。
    2、增大UNDO表空间的大小。

紧急措施：
    1、增大UNDO表空间

数据库恢复类
CRS资源异常类
RAC数据库CRS无法正常启动
现象描述：
CRS集群堆栈无法正常启动，CRSCTL STAT RES -T命令无法正常输出。

影响因素:
影响crs正常启动的因素较多，不能正常启动，数据库集群无法使用。但检查crs各项配置均正常。

解决方法:
检查crs alert日志，alert日志位置为$ORACLE_HOME/log/alert_homename.log。

VIP资源DOWN异常处理
现象描述：
环境：AIX+ oracle 11.2.0.3.0
CRS集群在运行过程中VIP资源DOWN，通过crsctl stat res -t 命令查看资源状态时VIP资源状态为OFFLINE

影响因素:
BUG1458429导致VIP出现异常。

解决方法:
1.应急情况下可以通过手动启动VIP资源如：
crsctl start res oggvip5
crsctl start res oggvip7
crsctl start res oggvip9
crsctl start res oggvip11
crsctl start res oggvip13
2.通过升级集群到11.2.0.4版本解决问题
数据库HANG类
数据库HANG异常处理
现象描述:
数据库无法登陆

影响因素:
A、大量异常阻塞
B、资源耗尽

解决方法:
1.进行HANG分析，查找顶级阻塞的会话。

全局的HANG分析：
oradebug setmypid (oradebug setospid 3188)
oradebug unlimit
oradebug setinst all
oradebug -g def hanganalyze 3
oradebug tracefile_name

2.紧急情况下，在操作系统使用命令: 
ps -ef|grep LOCAL=NO |awk '{print $2}' | xargs kill -9
kill所有非本地进程,然后检查系统资源状态，检查数据库状态

数据库CRASH类
实例CRASH应急处理
现象描述：
RAC环境单节点crash ，RAC环境所有节点crash

影响因素：
暂无,CRASH问题涉及到的问题比较复杂，以后将逐步更新。

解决方法：
遇到实例crash之后，首先看是否能重启启动：
1、能重新启动的情况下，知会相关领导, 事后分析重启原因。
2、不能重启的情况下：
    A、RAC之单节点无法重启，通知相关领导， 评估正常节点负载，应用切换至正常节点。相关技术人员进行故障处理。
    B、RAC之全节点无法重启，通知相关领导， 考虑是否切换应急库。相关技术人员进行故障处理。

应用操作类
SQL执行计划变化应急处理
现象描述：
一个SQL的执行计划的不稳定，

影响因素:
常见原因包含以下两种：
1、统计信息的变化
2、SQL语句的变化

解决方法：
1、通过SQL_ID确认统计信息是否一致 （该语句会将AWR中所有的信息查找出来）
set lines 155
col execs for 999,999,999
col avg_etime for 999,999.999
col avg_lio for 999,999,999.9
col begin_interval_time for a30
col node for 99999
break on plan_hash_value on startup_time skip 1
select ss.snap_id,
       ss.instance_number node,
       begin_interval_time,
       sql_id,
       plan_hash_value,
       nvl(executions_delta, 0) execs,
       (elapsed_time_delta /
       decode(nvl(executions_delta, 0), 0, 1, executions_delta)) / 1000000 avg_etime,
       (buffer_gets_delta /
       decode(nvl(buffer_gets_delta, 0), 0, 1, executions_delta)) avg_lio,
       (disk_reads_delta /
       decode(nvl(buffer_gets_delta, 0), 0, 1, executions_delta)) avg_pio
  from DBA_HIST_SQLSTAT S, DBA_HIST_SNAPSHOT SS
 where sql_id = nvl('&sql_id', '4dqs2k5tynk61')
   and ss.snap_id = S.snap_id
   and ss.instance_number = S.instance_number
   and s.instance_number like nvl('&instance_number', s.instance_number)
   and executions_delta > 0
 order by 1, 2, 3
/

2、如果不一致，我们需要检查统计信息是否最新，如果统计信息更新时间比当前时间有些遥远，收集统计信息。

3、如果统计信息正常，我们需要确认数据量是否有大量增加。

4、如果数据量增加的情况下，我们就要考虑清理数据或SQL优化。
使用绑定变量SQL突然运行缓慢的应急处理
现象描述：
一个session可能一某种方式变的非常消耗CPU,并且没有任何有意义的wait event. SQL的执行计划没有改变过

影响因素：
一般包含以下几种：
1、 SQL代入的绑定变量值极端
2、 等待的块有问题

解决方法：
1、 查看SQL的执行计划，及等待事件。
2、 等待事件是否正常，如果为块等待，则可以采样等待的块，通过采样的块，定位对应的表和索引，进行分析。
3、 使用errorstack定位这个SQL的绑定变量值进行分析。

其他分类
升级PSU系统报错
现象描述：
在打补丁的过程中，出现如下的报错信息：
Running prerequisite checks...
Prerequisite check "CheckActiveFilesAndExecutables" failed.
The details are:

Following executables are active :
/oracle/app/oracle/product/10.2.0/bin/tnslsnr
UtilSession failed: Prerequisite check "CheckActiveFilesAndExecutables" failed.

OPatch failed with error code 73 

影响因素:
    通过日志可以发现，导致当前升级PSU出错的原因是当前的监听器没有关闭。因此，当务之急，是将监听手工关闭。
    但事实上，在出现上述错误之前，工程已经将监听关闭了。但由于该PSU只跟数据库相关，与集群没有关系。因此，他在升级该PSU时，只是通过CRS关闭了监听，过了一段时间以后，监群又自动将监听拉起来了，这就导致升级PSU时，监听仍然是ACTIVE状态。
因而，在升级补丁或PSU时，需要通过lsnrctl stop的方式关闭监听器。

解决方法：
通过lsnrctl stop的方式关闭监听器。

数据库在执行过程中使用动态采样
现象描述：
    一个SQL在执行过程中异常缓慢，通过查看其执行计划发现，该SQL在执行过程中使用动态采样。
Note
-----
   - dynamic sampling used for this statement

现象分析:
    动态采样本身是Oracle的一个特性，用于在没有统计信息的情况下，自动收集相关表的统计信息。但在某些情况下，他仍然使用动态采样，并进而导致执行效率低下。

解决方法：
1、通过hint禁用动态采样。/*+dynamic_sampling(t 0) */
    2、这是Oracle的一个bug，请打补丁9272549。

通过srvctl查看数据库的状态时反应缓慢
现象描述：
    数据库状态正常，但在执行"srvctl status database -d db1"时，其节点一需要很长时间才能出结果，节点二正常。查看alert日志，也并未发现有告警的信息。

现象分析:
    通过类似的命令查看或启动某个资源时，由于并无相应的日志，因此给我们的判断带来一些麻烦。解决此类问题，我们可以采用跟踪的办法来分析其内部的相应过程。

解决方法：
1、strace -frT -o /tmp/strace2.log srvctl status database -d db1，根据其生成的trace文件分析内部过程，并解决。
2、使用sh -x shell.sh的方式去debug命令的执行过程，发现问题。
3、使用truss等命令进行时间分析。

修改字符集 
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 2137886720 bytes
Fixed Size                  2254952 bytes
Variable Size            1207961496 bytes
Database Buffers          922746880 bytes
Redo Buffers                4923392 bytes
Database mounted.

SQL>  alter system enable restricted session;

System altered.

SQL> alter system set job_queue_processes=0;

System altered.

SQL> alter database open;

Database altered.

SQL> alter database character set ZHS16GBK;
alter database character set ZHS16GBK
*
ERROR at line 1:
ORA-12712: new character set must be a superset of old character set


SQL> alter database character set internal_use ZHS16GBK;

Database altered.

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.



SQL> startup mount
ORACLE instance started.

Total System Global Area 2137886720 bytes
Fixed Size                  2254952 bytes
Variable Size            1207961496 bytes
Database Buffers          922746880 bytes
Redo Buffers                4923392 bytes
Database mounted.
SQL> alter system set job_queue_processes=1000;

System altered.

SQL> alter database open;

Database altered.

SQL>  select userenv('language') from dual;

USERENV('LANGUAGE')
----------------------------------------------------
AMERICAN_AMERICA.ZHS16GBK