1. Oracle数据库无响应故障处理方式
Oracle数据库无响应故障处理方式
Oracle数据库无响应故障，简单地讲就是数据库实例不能响应客户端发起的请求，客户端提交一个sql后，就一直处于等待数据库实例返回结果的状态。更严重的现象是客户端根本不能连接到数据库，发起一个连接请求后，一直处于等待状态。Oracle数据库无响应故障怎么处理呢?下面跟我一起来学习Oracle数据库无响应故障的处理方法吧!
无响应的故障现象一般有以下几种：
1.Oracle的进程在等待某个资源或事件
这种现象一般可以从V$SESSION_WAT、V$LATCH、V$LATCHHOLDER等动态视图中检查进程正在等待的资源或事件，而被等待的资源或事件，一直都不能被获取，甚至是很长时间都不可获得。如果这个正在等待的进程持有了其他的资源，则会引起其他的进程等待，这样就很可能引起实例中大范围的会话发生等待。由于进程在等待资源或事件时，通常都处于SLEEP状态，消耗的CPU资源非常少(在等待latch时要稍微多消耗一些CPU资源)，所以从OS来看，CPU的消耗并不高，甚至是非常低。
这种因为等待而引起的个别进程Hang，相对比较容易处理。
2. OracleProcess Spins
所谓Spin，就是指Oracle进程中的代码在执行某个过程时，陷入了循环。在V$SESSION视图中，往往可以看到Hang住的会话，一直处于“ACTIVE”状态。对于这样的会话，用“alter system kill session ‘sid,serial#’”命令也不能完全断开会话，会话只能被标记为“killed”，会话会继续消耗大量的CPU。进程Spins由于是在做循环，CPU的消耗非常大，从OS上明显可以看到这样的进程，通常会消耗整个CPU的资源。
而对于这样的Hang住的会话，处理起来相对比较复杂，并且为了从根本上解决问题，需要超过DBA日常维护所需要的技能。
从故障范围来看，无响应故障可以分为以下几种情况：
1. 单个或部分会话(进程)Hang住
这种情况属于小范围的故障，业务影响相对较小，一般来说只会影响业务系统的个别模块。在一个多应用系统的数据库上面，如果Hang住的会话比较多，则影响的可能是其中的一个应用系统。这里有一个例外，如果Hang住的进程是系统后台进程，如pmon、smon等，则影响的范围就非常大了，最终甚至会影响整个数据库及所有应用系统。还有值得注意的是，即使是少部分会话Hang住，也要及时处理，否则极有可能会扩散到整个系统。
2. 单个数据库实例Hang住
这种情况造成的影响非常大。在这个实例上的所有应用系统均受到严重影响，并且在找到根源并最终解决问题之前，数据库实例往往须要重启。
3. OPS或RAC中的多个实例或所有实例都Hang住
在这种情况下，即使是OPS或RAC，都已经没办法提供高可用特性了。使用这个数据库的所有应用系统将不能继续提供服务，这种情况往往须要重启。
无响应故障成因分析
Oracle数据库无响应，一般主要由以下几种原因引起：
1. 数据库主机负载过高，严重超过主机承受能力
比如应用设计不当，数据库性能低下，活动会话数的大量增加，导致数据库主机的负载迅速增加，数据库不能正常操作，并最终Hang住;主机物理内存严重不足，引起大量的换页，特别是在SGA中的内存被大量换出到虚拟内存时，数据库实例往往就会Hang住。
2. 日常维护不当、不正确的操作引起数据库Hang住
比如归档日志的存储空间满，导致数据库不能归档，引起数据库Hang住;在一个大并发的繁忙的系
统上，对DML操作比较多的大表进行move、增加外键约束等操作也可能使系统在短时间内负载大幅升高，并引起数据库系统Hang住;不正确的资源计划(Resource Plan)配置，使进程得不到足够的CPU等。
3. Oracle数据库的Bug
几乎每个版本都存在着会导致数据库系统Hang住的Bug，这些Bug会在一些特定的条件下触发，特别是在RAC数据库中，引起数据库Hang住的Bug比较多。
4. 其他方面的一些原因
比如在RAC数据库中，如果一个节点退出或加入到RAC的过程中，当进行Resource Reconfiguration时，会使系统冻结一段时间，也有可能使系统Hang住。
以上所描述的几种常见的会导致Oracle数据库实例Hang住的原因中，大部分的情况是可以避免的，只要维护得当，一般不会出现这种故障。对于Oracle数据库Bug所导致的数据库无响应故障，由于是在特定的情况下才会触发，所以如果能够尽量对数据库打上最新版本的补丁，并且熟悉当前版本中会导致系统Hang住的Bug以及触发条件，就能够最大限度地避免这种故障的发生，提高系统的可用性。
那么，在数据库Hang住的情况下，如何去分析并发现导致问题的根源?一方面，由于系统Hang住会导致业务系统不可用，为了能够尽快地恢复业务，须快速地判断问题所在，然后Kill掉引起故障的会话和进程，或者数据库实例不得不重启以迅速恢复业务;但另一方面，如果只是重启数据库或Kill会话和进程来解决问题，在很多情况下是治标不治本的办法，在以后故障随时可能会出现。如何在二者之间进行抉择呢?对于数据库Hang故障的处理，首先是尽可能地收集到系统Hang住时的状态数据，然后尽快地恢复业务，恢复业务后分析收集到的数据，找到数据库系统Hang住的真正原因，然后再进行相应的处理。下一节将详细描述数据库系统Hang住后的处理流程。
无响应故障处理流程
对于Oracle无响应故障的处理，我们可以按下图所示的流程进行。
值得注意的是，上图并不是一个完整的Oracle数据库故障处理流程图，只是处理Oralce数据库无响应这一类特定的故障的流程，只列出了针对这一特定类型故障处理时的关键处理点。不过既然是故障，所以这类故障的处理流程与其他故障的处理流程，有着非常相似的地方。
下面是整个流程的详细说明：
1. 在出现数据库无响应故障后，首先确认系统的影响范围，如上节所描述的'，是部分业务系统或模块还是所有的业务系统都受影响，是不是整个实例或多个实例都无响应。同时应询问系统维护和开发人员，受影响的系统在出现故障前是否有过变动，包括主机硬件、操作系统、网络、数据库以及应用等。有时一个细小的变动就可能导致出现数据库Hang住这样严重的故障。曾经遇到一个库，应用只是修改了一个SELECT语句就导致了数据库Hang住。
2. 为了避免由于网络、数据库监听或客户端因素影响分析，建议都登录到主机上进行操作。
3. 如果主机不能登录(为了避免干扰流程主线，这里不讨论如网络问题这样也会导致不能连接的故障)，尝试关闭出现问题的业务系统，甚至是所有的业务系统。如果关闭了所有的业务系统之后，仍然不能连接，则只有考虑重新启动数据库主机。在数据库主机重新启动后，使用操作系统工具或OSW等长期监控操作系统的资源使用，同时监控Oracle数据库的性能和等待等。
4. 登录上主机后，先用top、topas等命令简单观察一下系统。看看系统的CPU使用、物理内存和虚拟内存的使用、IO使用等情况。
5. 使用SQLPLUS连接数据库，如果不能连接，则只能从操作系统上观察系统中是否有异常的现象，比如占用CPU过高的进程。使用gdb、dbx等debugger工具对数据库进行system state mp;使用strace、truss等工具检查异常进程的系统调用;使用pstack、procstack等工具察看异常进程的call stack等。
6. 使用SQLPLUS连接上数据库后，进行hanganalyze、system state mp等操作;或检查等待事件、异常会话等正在执行的SQL等待。
7. 找到故障产生的原因，如果暂时找不到原因，尽量收集数据。
8.确良如果应用急须恢复，可通过Kill会话、重启数据库实例等方式，先恢复应用。
9. 根据最终诊断结果，对数据库升级打补丁，或者修改应用等方式从根本上解决问题。
怎样避免数据库出现无响应故障
作为Oracle数据库DBA，除了处理故障之外，更重要的是如何预防故障的发生。根据前面对数据库无响应故障的成因分析，在日常的维护工作中，须做到以下几点：
1. 进行正确的维护操作
很多的数据库无响应故障都是由于不正确的维护操作引起的。应避免在业务高峰期做大的维护操作，比如像move、加主外键约束等会长时间锁表的操作。如果的确需要，尽量使用正确的操作方法。比如用ONLINE方式重建索引;建主键、唯一键约束时先建索引，然后在建约束时指定新建的索引，等等。也就是保证系统的并发性、可伸缩性，避免系统串行操作的出现。
2. 优化应用设计，优化数据库性能
为避免性能问题导致在业务高峰期数据库不能及时有效处理来自业务的请求，甚至于完全Hang住。对于数据库中存在串行访问的部分进行优化，比如latch、enqueue，还包括不合理的sequence设计等。特别是在RAC数据库中，严重串行访问等待往往更容易引起严重的性能问题。优化应用设计，使数据库具有更好的可伸缩性和并行处理能力，能够有效地避免性能问题引起的数据库Hang住。
3. 利用监控系统随时监控系统负载
遇到系统负载过高，内存不足，OS中虚拟内存换页很频繁等情况时，及时采取措施;监控Oracle数据库的核心进程，如pmon、smon等，看是否有异常，如过高的CPU消耗。出现异常应立即处理;监控归档空间和日志切换;监控数据库中的等待事件，比如是否有大量的enqueue、log file switch (archiving needed)、resmgr:become active等待事件等。
4. 为数据库打上补丁
很多的无响应故障是由于Oracle的Bug引起的，数据库DBA应关注当前版本中有哪些Bug会导致数据库Hang住，尽量为数据库打上解决这些Bug的补丁。
;2. ORACLE数据库出现大量LOG FILE SYNCS等待事件，怎么办
本文主要讨论 RAC 数据库中的'log file sync' 等待事件。RAC 数据库中的'log file sync' 等待事件要比单机数据库中的'log file sync' 等待事件复杂，主要原因是由于RAC 数据库需要将SCN同步到所有实例。
首先，回顾一下单机数据库中的'log file sync' 等待事件，当user session 提交（commit）时，user session会通知LGWR进程将redo buffer中的信息写入到redo log file，当LGWR进程完成写操作后，LGWR再post（通知）user session 写操作已经完成，user session 接收到LGWR的通知后提交操作才完成。因此user session 在没有收到LGWR post（通知）之前一致处于等待状态，具体的等待事件为'log file sync'。
在RAC数据库中为了一致性读，需要将Commit SCN同步/传播到所有的节点上。SCN同步/传播的主要方法有两种：Lamport SCN 和 immediate commit propagation (BOC)。
10gR1 及以下版本默认使用Lamport SCN，Lamport SCN方式即一个节点上的commit SCN 不保证立刻同步/传播到所有节点，也就是说可能延时同步/传播，对于一些实时性要求高的RAC数据库Lamport SCN方式是不可取的。如果希望commit SCN 立刻同步/传播到所有节点，手动修改参数MAX_COMMIT_PROPAGATION_DELAY=1
从10gR2开始默认使用immediate commit propagation (BOC)，BOC即一个节点上的commit SCN 立刻同步/传播到所有节点。
介绍 immediate commit propagation (BOC)的工作原理
1. user session 执行提交（commit），user session会通知LGWR进程将redo buffer中的信息写入到redo log file。
2. LGWR进程收到user session通知后，将redo buffer中的信息写入redo log file，同时LGWR 将COMMIT SCN 同步/传播给远程的数据库实例的LMS 进程。
3. 远程数据库实例的LMS将commit SCN同步到本地SCN，然后通知commit实例的LMS，表示SCN 同步已经完成。
4. 当commit 实例的LMS接收到所有远程数据库实例的LMS的通知后，commit 实例的LMS再通知本地的LGWR 所有节点SCN同步已经完成。
5. LGWR 在完成了IO 操作和LMS进程通知后，LGWR通知user session commit 成功。user session在没有收到LGWR通知前，一直处于等待log file sync。
通过以上原理的说明，我们不难看出来导致'log file sync' 等待事件的主要原因有：
1. 磁盘IO 慢导致LGWR进程将redo buffer中的信息写入到redo log file速度慢。
2. user session commit过于频繁。
3. 本地或者远程服务器CPU资源不足，导致LMS和/或者LGWR不能及时得到CPU调度，不能正常工作。
4. RAC私有网络性能差，导致LMS同步commit SCN慢。
5. ORACLE BUG.
分析处理'log file sync' 等待事件时的重要log/信息
1. AWR
例如：AWR中log file sync 的等待时间与log file parallel write的时间基本相同，因此是由于IO问题导致的log file sync.
2. LGWR and LMS process trace file
例如：LGWR trace文件中报出下面的信息，很有可能是IO慢导致的。
Warning: log write time 1000ms, size 2KB
3. OSWatcher <--- 可以帮助我们确认服务器CPU资源使用情况
例如：下面的是OSW中vmstat 的输出，其中runQ中的进程达到48个，表明当时CPU资源是非常紧张的，会导致LMS/LGWR不能获得CPU 调度，导致Log file sync等待。
procs memory page faults cpu
r b w avm free re at pi po fr de sr in sy cs us sy id
48 22 0 23877753 30244459 0 0 0 0 0 0 0 153454 2184632 114234 38 60 2
48 22 0 23877753 30244094 0 0 0 0 0 0 0 153694 2181493 114887 36 61 3
注：关于OSW的安装配置请参考BLOG中的文章：
https://blogs.oracle.com/Database4CN/entry/%E5%88%A9%E5%99%A8osw_oswatcher_black_box_%E4%B9%8B%E7%AE%80%E4%BB%8B%E7%AF%87
4. Alert log
5. Script to Collect Log File Sync Diagnostic Information (lfsdiag.sql) [Document 1064487.1]
解决'log file sync' 等待事件主要方法
1. 提高磁盘IO速度
2. 采用批量提交，减少应用commit次数
3. 安装OSWatcher 定位CPU使用率高的进程
4. 采用专用网络，正确设置网络UDP buffer参数
5. 安装最新版本数据库避免bug，具体bug修复的版本参考文档：
WAITEVENT: "log file sync" Reference Note (Doc ID 34592.1)
如果自己搞不定可以找ASKMACLEAN专业数据库修复团队成员帮您恢复!
3. oracle数据库运行sql很卡很慢很顿，看等待事件都是cursor:pin s on x,这是啥
详解cursor: pin S wait on X等待事件 ‘cursor: pin * events’等待事件 该类等待事件一般是为了pin相关的子游标 ‘Cursor: pin S on X’ 最常见的等待事件， 进程为了共享操作例如执行pin游标而以SHRD S mode申请mutex， 但是未立即获得。原因是该游标被其他进程以EXCL X mode 持有了。 实际该 cursor: pin S wait on X等待事件往往是由于其他因素诱发的。Mutex争用仅仅是问题的症状，但根本原因需要Database Consultant 进一步挖掘。 下面我们列出一些已知的常见案例， 在这些例子中可以看到 我上面提到的 Mutex的争用仅仅是伪争用: 过多的子游标 High Version Counts 过多的子游标版本Version Count可能导致Mutex 争用，一般一个SQL的Version Count不要高于500。 检查High Version Count很简单， 在AWR里就有SQL ordered by High Version Count，也可以写SQL查V$SQL、V$SQLAREA 昂贵的X$、V$视图查询 一些对于V$、X$视图的查询，需要访问X$KGL*之类的fixed table，可能触发Mutex争用。 Mutex持有者得不到CPU Mutex持有者若得不到足够的CPU片可能一直阻塞他人，直到它拿到需要的CPU。 这种情况可能由于OS操作系统的实际情况或者使用Resource Manager而引起。需要配合AWR中的Host CPU、Instance CPu一起看。 已经被KILLED的SESSION仍持有Mutex 当session正持有Mutex，而其对应的Process被强制KILL掉， 则直到PMON彻底清理掉该Dead Process并释放Mutex，其他session才能不再等待。 诊断该类问题，最好能检查PMON的TRACE。 当然也存在部分BUG会导致PMON清理过程非常慢。 举例来说，bug 9312879描述了一种场景：PMON 需要获得某个Mutex以便清理某个dead process，但是该Mutex又被其他进程持有，则PMON甚至无法开始真正清理并释放Mutex。 如果自己搞不定可以找ASKMACLEAN专业ORACLE优化团队成员帮您搞定!
4. oracle数据库里出现很多enq: TX – index contention等待事件是怎么回事
等待事件
当索引块分裂发生时， 负责实施分裂 split 的进程会持有 相关的队列锁enqueue TX 锁，
直到该进程完成Split操作才会释放该enqueue Tx，在这个过程中负责split的进程需要找到合适的新块并将对应的数据移动到该新块中。
若在此split过程中，有其他进程INSERT数据到该索引块中，则将进入 enq: TX – index
contention等待事件，直到split结束enqueue TX被释放。
负责split的进程需要找到一个合适的新块， 其会优先寻找本index 已分配的空间中的 free block， 这些free
block应当是100% free的，但是在Oracle 的segment bitmap block 中只区分 0%-25%，25%-50%,
50%-75%, 75%-100% 使用率的数据块， 即无法直接区分 0%-25%使用率的数据块中哪些是100% free的数据块，
Oracle这样做的目的是 为了重用数据块，以避免过度分配空间。 当oracle发现没有可重用的数据块时才会扩展索引空间并移动分裂数据。
这个在split 过程中 寻找可复用的free block的过程称之为failed probes on index block
reclamation，在正常的情况下这种找寻可复用块的过程是很快的 ，但是如果 恰好遇到 物理读缓慢或者
全局的数据块争用时，该过程可能变得很慢，这将直接导致split 变慢， 进而导致大量INSERT进程长时间等待enq: TX – index
contention。
from askmaclean
5. 如何查看oracle的等待事件常见的等待事件以及可能的原因是什么
有专门介绍等待事件的书啊。一般也只是介绍一些常用的等待事件啊。
答题不易，互相帮助，手机提问的朋友在客户端右上角评价点满意即可.
如认可我的回答，请点击采纳为满意回答按钮.
6. oracle 有哪些空闲等待事件
Oracle的
等待事件是衡量Oracle运行状况的重要依据及指标。等待事件的概念是在Oracle7.0.1.2中引入的，大致有100个等待事件。在Oracle
8.0中这个数目增加到了大约150个，在Oracle8i中大约有200个事件,在Oracle9i中大约有360个等待事件。主要有两种类别的等待事
件，即空闲(idle)等待事件和非空闲(non-idle)等待事件。
空闲事件指Oracle正等待某种工作,在诊断和优化数据库的时候,我们不用过多注意这部分事件。
常见的空闲事件有:
• dispatcher timer
• lock element cleanup
• Null event
• parallel query dequeue wait
• parallel query idle wait - Slaves
• pipe get
• PL/SQL lock timer
• pmon timer- pmon
• rdbms ipc message
• slave wait
• smon timer
• SQL*Net break/reset to client
• SQL*Net message from client
• SQL*Net message to client
• SQL*Net more data to client
• virtual circuit status
• client message
非空闲等待事件专门针对Oracle的活动,指数据库任务或应用运行过程中发生的等待，这些等待事件是我们在调整数据库的时候应该关注与研究的。
一些常见的非空闲等待事件有:
• db file scattered read
• db file sequential read
• buffer busy waits
• free buffer waits
• enqueue
• latch free
• log file parallel write
• log file sync
7. oracle 9i 怎么查看等待事件的sql
oracle 查询最近执行过的 SQL语句
select sql_text,last_load_time from v$sql order by last_load_time desc;
SELECT sql_text, last_load_time FROM v$sql WHERE last_load_time IS NOT NULL and sql_text like 'select%' ORDER BY last_load_time DESC;
SELECT sql_text, last_load_time FROM v$sql WHERE last_load_time IS NOT NULL and sql_text like 'update%' ORDER BY last_load_time DESC;
SELECT sql_text, last_load_time FROM v$sql WHERE last_load_time IS NOT NULL and last_load_time like' 14-06-09%' ORDER BY last_load_time DESC;
8. oracle数据库运行sql很卡很慢很顿，看等待事件都是cursor:pin s on x,这是啥
详解cursor: pin S wait on X等待事件
‘cursor: pin * events’等待事件
该类等待事件一般是为了pin相关的子游标
‘Cursor: pin S on X’ 最常见的等待事件， 进程为了共享操作例如执行pin游标而以SHRD S mode申请mutex， 但是未立即获得。原因是该游标被其他进程以EXCL X mode 持有了。
实际该 cursor: pin S wait on X等待事件往往是由于其他因素诱发的。Mutex争用仅仅是问题的症状，但根本原因需要Database Consultant 进一步挖掘。
下面我们列出一些已知的常见案例， 在这些例子中可以看到 我上面提到的 Mutex的争用仅仅是伪争用:
过多的子游标 High Version Counts
过多的子游标版本Version Count可能导致Mutex 争用，一般一个SQL的Version Count不要高于500。
检查High Version Count很简单， 在AWR里就有SQL ordered by High Version Count，也可以写SQL查V$SQL、V$SQLAREA
昂贵的X$、V$视图查询
一些对于V$、X$视图的查询，需要访问X$KGL*之类的fixed table，可能触发Mutex争用。
Mutex持有者得不到CPU
Mutex持有者若得不到足够的CPU片可能一直阻塞他人，直到它拿到需要的CPU。
这种情况可能由于OS操作系统的实际情况或者使用Resource Manager而引起。需要配合AWR中的Host CPU、Instance CPu一起看。
已经被KILLED的SESSION仍持有Mutex
当session正持有Mutex，而其对应的Process被强制KILL掉， 则直到PMON彻底清理掉该Dead Process并释放Mutex，其他session才能不再等待。 诊断该类问题，最好能检查PMON的TRACE。 当然也存在部分BUG会导致PMON清理过程非常慢。
举例来说，bug 9312879描述了一种场景：PMON 需要获得某个Mutex以便清理某个dead process，但是该Mutex又被其他进程持有，则PMON甚至无法开始真正清理并释放Mutex。
如果自己搞不定可以找ASKMACLEAN专业ORACLE优化团队成员帮您搞定!
9. Oracle的sql语句中wait的含义
nowait：立即执行，如果另有会话正在修改该记录会立即报告错误：ORA-00054: 资源正忙，要求指定 NOWAIT；如果不选择nowait选项则会一直处理等待状态。
wait [n]：等待n秒，如果另有会话正在修改该记录会报告错误：ORA-30006: 资源已被占用; 执行操作时出现 WAIT 超时
＝>另外，还有一个skip locked。
skip locked：跳过已被别的会话锁定的记录
10. oracle数据库等待事件和性能有什么影响
这是一个很容易引起误导的等待事件，实际上这个等待事件和并行操作（比如并行查询，并行DML）没有关系。 这个事件发生在数据库恢复的时候，当有一些数据块需要恢复的时候，Oracle会以并行的方式把他们从数据文件中读入到内存中进行恢复操作。这个等待事件包含三个参数：
Files： 操作需要读取的文件个数。
Blocks： 操作需要读取的数据块个数。
Requests：操作需要执行的I/O次数。