逐渐变慢
突然变慢
不定时变慢
第一种情况 逐渐变慢 要建立一个长期的监控机制 比如 写个shell脚本每天的忙时(通常 ~ etc )定时收集os neork db的信息 每个星期出report对收集到的信息进行分析 这些数据的积累 可以决定后期的优化决策 并且可以是DBA说服manager采用自己决策的重要数据 DBA的价值 就在每个星期的report中体现
第二种情况 突然变慢 也是最容易解决的 先从业务的角度看是DB的使用跟以前有何不同 然后做进一步判断 硬件/网络故障通常也会引起DB性能的突然下降
第一步: 察看DB/OS/NEORK的系统log 排除硬件/网络问题
第二步 察看数据库的等待事件 根据等待事件来判断可能出问题的环节 如果 没有等待事件 可以排除数据库的问题 如果有等待时间 根据不同的等待事件 来找引起这些事件的根源
比如latch free等跟SQL parse有关系的等待事件 OS的表现是CPU 的占用率高
db file scattered read等跟SQL disk read有关系的等待时间 OS的表现是iostat可以看到磁盘读写量增加
第三步: 察看os的信息 CPU/IO/MEMORY等
a Cpu 的占用率
CPU占用率与数据库性能不成反比 CPU占用率高 不能说明数据库性能慢 通常情况 一个优化很好 而且业务量确实很大的数据库 CPU的占用率都会高 而且会平均分布在每个进程上 反过来 CPU的占用率都会高也不代表数据库性能就好 要结合数据库的等待事件来判断CPU占用率高是否合理
如果某个进程的cpu占用高 肯定是这个进程有问题 如果 不是oracle的进程 可以让application察看是否程序有死循环等漏洞 如果 是oracle的进程 可以根据pid查找oracle数据字典看看这个进程的发起程序 正在执行的sql语句 以及等待事件 然后 不同情况使用不同的方法来解决
b IO
排除硬件的IO问题 数据库突然变慢 一般来说 都是一个或几个SQL语句引起的
如果IO很频繁 可以通过优化disk reads高的TOP SQL来解决 当然这也是解决IO问题的最笨也是最有效的办法
OS以及存储的配置也是影响IO的一个重要的原因
比如 最常见的HP unix下异步IO的问题 如果DBA GROUP没有MLOCK的权限 ORACLE是不使用AIO的 偏偏OS与DB的两方的admin如果配合不够好地话 这个配置就很容易给漏掉了
c Memory
第二种情况与memory的关系比较小 只要SGA区配置合理没有变化 一般来说 只要不是Application Memory leak 不会引起突然变慢的现象
第三种情况 不定时变慢 是最难解决的 现场出现的问题原因也是五花八门千奇百怪 最重要的是 出现慢的现象时 以最快的速度抓取到最多的信息以供分析 先写好抓取数据的shell 脚本 并在现象发生时及时按下回车键
一个例子
数据库突然变慢
背景: 一个新应用上线后 数据库突然变慢
第一步 调查新应用
据开发人员讲新应用访问的都是新建立的表 表的数据量很小 没有复杂的SQL查询
查询 v$sqlarea 分别按照disk_reads / buffer_gets / executions 排序 TOP SQL 中没有新应用的SQL 排除新应用数据库访问照成的性能问题
第二步 察看数据库log/ OS log
数据库log中可以看到大量的ORA 错误 以及大量的dump文件 分析dump文件(时间久了 没有dump文件可参考 具体细节没法描述下来 ) 发现是新应用通过dblink访问remote DB时生成的dump文件 应用开发人说没法修改 Oracle也没有相应的patch解决
OS log中没有错误信息
第三步 察看statspack report
从wait events中看到 Top event是 buffer busy waits db file parallel write 等于IO相关的等待事件
从buffer busy waits 的统计信息来看 是等待data block
还有些physical reads等信息与从前比没有太多的异常
Tablespace 的IO reads/writes也没有异常 但是wait明显增加
初步确定是IO问题
第四步 察看OS的信息
top 命令(输出为实验室数据 仅作格式参考)
load averages: : :
processes: sleeping zombie stopped on cpu
CPU states: % idle % user % kernel % iowait % swap
Memory: M real M free M swap in use M swap free
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU MAND
a K K cpu/ : % top
mpgj M K sleep : % view_server
当时现场数据显示 iowait 值与以前相比大很多 没有异常进程
sar –d (输出为实验室数据 仅作格式参考)
SunOS sc Generic_ sun u / /
: : device %busy avque r+w/s blks/s avwait avserv
sd
sd a
sd b
sd c
sd g
当时现场数据显示 放数据文件的设备 avwait avque blks/s值偏大
第五步 察看数据库的等待事件
一个大业务量的数据库如果性能不好的话 一般来说都会有大量的等待事件 上百个等待事件很常见 我通常会按照EVENT进行group
Select count(*) event from v$session_wait where event not in ( *** on timer pmon timer rdbms ipc message SQL*Net message from client ) group by event order by desc
输出结果显示最多的等待事件是buffer busy waits
进一步分析 找出等待的原因
Select count(*) p p p from v$session_wait where event = buffer busy waits group by p p p
在buffer busy waits等待事件中
P = file#
P = block#
P = id ( 此id对应为等待的原因)
按照p p p group是为了明确buffer busy waits的等待集中在哪些对象上
Metalink对buffer busy waits等待事件的描述有如下一段话
If P shows that the buffer busy wait is waiting for a block read to plete then the blocking session is likely to be waiting on an IO wait (eg: db file sequential read or db file scattered read for the same file# and block#
输出结果显示 等待分布在多个不同的对象上 等待原因为 waiting for a block read to plete 进一步分析为IO的问题
如果 buffer busy waits等待集中在某个对象上 说明有hot block 通过重新rebuild这个对象增加freelist来解决 RAC环境增加freelist group
通过以下SQL可以找到具体的object
Select owner segment_name segment_type from dba_extents where file_id=P and P beeen block_id and block_id+blocks
P P 是上面v$session_wait查出的具体的值
第六步 明确原因 找出解决步骤
分析
磁盘的IO流量增加
磁盘的IO等待增加
DB的IO流量没有增加
DB的IO等待增加
由 可以推出 有数据库以外的IO访问磁盘
察看磁盘配置 该VG只存放了数据库数据文件和数据库系统文件 排除数据文件 产生IO的是数据库系统文件
数据库系统文件一般来说不会产生IO 有IO读写的地方只有log和dump文件
结论 ora 产生的大量core dump文件堵塞IO
解决办法
消除ora (应用不改的情况下 无法解决)
把dump目录指向别的VG
让oracle尽量少的去写core dump文件
background_core_dump = partial
lishixinzhi/Article/program/Oracle/201311/18969数据库慢一般有三种情况第一种情况 逐渐变慢 要建立一个长期的监控机制 比如 写个shell脚本每天的忙时(通常 ~ etc )定时收集os neork db的信息 每个星期出report对收集到的信息进行分析 这些数据的积累 可以决定后期的优化决策 并且可以是DBA说服manager采用自己决策的重要数据 DBA的价值 就在每个星期的report中体现
第二种情况 突然变慢 也是最容易解决的 先从业务的角度看是DB的使用跟以前有何不同 然后做进一步判断 硬件/网络故障通常也会引起DB性能的突然下降
第一步: 察看DB/OS/NEORK的系统log 排除硬件/网络问题
第二步 察看数据库的等待事件 根据等待事件来判断可能出问题的环节 如果 没有等待事件 可以排除数据库的问题 如果有等待时间 根据不同的等待事件 来找引起这些事件的根源
比如latch free等跟SQL parse有关系的等待事件 OS的表现是CPU 的占用率高
db file scattered read等跟SQL disk read有关系的等待时间 OS的表现是iostat可以看到磁盘读写量增加
第三步: 察看os的信息 CPU/IO/MEMORY等
a Cpu 的占用率
CPU占用率与数据库性能不成反比 CPU占用率高 不能说明数据库性能慢 通常情况 一个优化很好 而且业务量确实很大的数据库 CPU的占用率都会高 而且会平均分布在每个进程上 反过来 CPU的占用率都会高也不代表数据库性能就好 要结合数据库的等待事件来判断CPU占用率高是否合理
如果某个进程的cpu占用高 肯定是这个进程有问题 如果 不是oracle的进程 可以让application察看是否程序有死循环等漏洞 如果 是oracle的进程 可以根据pid查找oracle数据字典看看这个进程的发起程序 正在执行的sql语句 以及等待事件 然后 不同情况使用不同的方法来解决
b IO
排除硬件的IO问题 数据库突然变慢 一般来说 都是一个或几个SQL语句引起的
如果IO很频繁 可以通过优化disk reads高的TOP SQL来解决 当然这也是解决IO问题的最笨也是最有效的办法
OS以及存储的配置也是影响IO的一个重要的原因
比如 最常见的HP unix下异步IO的问题 如果DBA GROUP没有MLOCK的权限 ORACLE是不使用AIO的 偏偏OS与DB的两方的admin如果配合不够好地话 这个配置就很容易给漏掉了
c Memory
第二种情况与memory的关系比较小 只要SGA区配置合理没有变化 一般来说 只要不是Application Memory leak 不会引起突然变慢的现象
第三种情况 不定时变慢 是最难解决的 现场出现的问题原因也是五花八门千奇百怪 最重要的是 出现慢的现象时 以最快的速度抓取到最多的信息以供分析 先写好抓取数据的shell 脚本 并在现象发生时及时按下回车键
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 dump使用strace、truss等工具检查异常进程的系统调用使用pstack、procstack等工具察看异常进程的call stack等。
6. 使用SQLPLUS连接上数据库后，进行hanganalyze、system state dump等 *** 作或检查等待事件、异常会话等正在执行的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的补丁。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）