ORACLE等待事件：direct path write

    2015年4月27日，晚上6点左右，电渠3g2库ORACLE RAC系统节点1出现大量的direct path write等待事件，导致大量的会话堆积，节点1几乎无法使用，应用受到影响，相关处理流程如下：
    环境：
    操作系统：hp-unix
    数据库版本：10.2.0.5
    故障描述：开始是27号上午9左右，应用开发有人执行update语句，发现执行好长时间没有完成，然后在数据库中查询并试图杀死会话，但是执行杀会话后再操作系统中依然有相关会话存在，
然后，试图使用kill -9杀进程，发现相关进程依然无法杀死；接下来，到晚上6点是相关会话大量积压的过程，数据库服务器实在无法承受会话继续积压（24800个），晚上7点左右与业务方沟通后
决定重启数据库，发现数据库无法正常的shutdown immediate，又尝试shutdown abort，但是startup的时候实例无法启动，查明是update的相关进程很多都积压在后台，决定重启主机服务器，节点1重启后正常，节点2又出现节点1类似的征兆，为了处理故障，避免累次重启无法解决故障，先保护现场待故障处理完成。
    接下来的故障定位如下：
    从dba_hist_active_sess_history视图查询数据库采样变化发现上午10点左右开始出现会话堆积：

select sample_time,count(*) from dba_hist_active_sess_history where dbid=3965601902 and
snap_id>49716 and snap_id
and sample_time>to_date('20150527 10:18:00','yyyymmdd hh24:mi:ss') group by sample_time 
order by sample_time;

SAMPLE_TIME                                COUNT(*)
---------------------------------------- ----------
27-MAY-15 10.18.04.924 AM                         4
27-MAY-15 10.18.12.694 AM                         3
27-MAY-15 10.18.15.024 AM                         3
27-MAY-15 10.18.22.794 AM                         1
27-MAY-15 10.18.25.124 AM                         4
27-MAY-15 10.18.35.224 AM                         3
27-MAY-15 10.18.45.324 AM                         1
27-MAY-15 10.18.55.434 AM                         2
27-MAY-15 10.19.03.204 AM                         1
27-MAY-15 10.19.13.304 AM                         1
27-MAY-15 10.19.23.404 AM                         2
27-MAY-15 10.19.35.834 AM                         2
27-MAY-15 10.19.43.614 AM                         1
27-MAY-15 10.19.45.934 AM                         1
27-MAY-15 10.19.53.714 AM                         2
27-MAY-15 10.19.56.044 AM                         2
27-MAY-15 10.20.03.814 AM                         1
27-MAY-15 10.20.06.144 AM                         1
27-MAY-15 10.20.13.914 AM                         1
27-MAY-15 10.20.16.244 AM                         1
27-MAY-15 10.20.24.014 AM                         3
27-MAY-15 10.20.26.343 AM                         2
27-MAY-15 10.20.34.114 AM                         1
27-MAY-15 10.20.36.443 AM                         3
27-MAY-15 10.20.44.224 AM                         1
27-MAY-15 10.20.46.553 AM                         1
27-MAY-15 10.20.54.324 AM                         9
27-MAY-15 10.21.04.424 AM                        13
27-MAY-15 10.21.06.753 AM                         7
27-MAY-15 10.21.14.525 AM                        21
27-MAY-15 10.21.16.853 AM                        17
27-MAY-15 10.21.24.624 AM                        32
27-MAY-15 10.21.26.953 AM                         1
27-MAY-15 10.21.34.814 AM                        50
27-MAY-15 10.21.37.053 AM                         2
27-MAY-15 10.21.44.914 AM                        49
27-MAY-15 10.21.47.163 AM                         2
27-MAY-15 10.21.55.014 AM                        61
27-MAY-15 10.21.57.263 AM                         2
27-MAY-15 10.22.05.116 AM                        69
27-MAY-15 10.22.07.363 AM                        12
27-MAY-15 10.22.15.216 AM                        77
27-MAY-15 10.22.17.463 AM                        12
27-MAY-15 10.22.25.316 AM                        87
27-MAY-15 10.22.27.562 AM                        13
27-MAY-15 10.22.35.426 AM                       112
27-MAY-15 10.22.37.662 AM                        47
27-MAY-15 10.22.45.526 AM                       121
27-MAY-15 10.22.47.772 AM                         7
27-MAY-15 10.22.55.626 AM                       129
27-MAY-15 10.22.57.872 AM                        10

    从上表可以发现，正常情况下4s对会话等待事件采样的记录从10点30左右开始增加，从会话采样历史视图查看相关等待事件如下：

select sample_time,event,count(*) from dba_hist_active_sess_history where dbid=3965601902 and
snap_id>49716 and snap_id
and sample_time>to_date('20150527 10:20:00','yyyymmdd hh24:mi:ss') group by sample_time,event 
order by sample_time;

SAMPLE_TIME                              EVENT                                      COUNT(*)
---------------------------------------- ---------------------------------------- ----------
27-MAY-15 10.20.03.814 AM                                                                  1
27-MAY-15 10.20.06.144 AM                db file sequential read                           1
27-MAY-15 10.20.13.914 AM                                                                  1
27-MAY-15 10.20.16.244 AM                                                                  1
27-MAY-15 10.20.24.014 AM                db file sequential read                           1
27-MAY-15 10.20.24.014 AM                                                                  2
27-MAY-15 10.20.26.343 AM                                                                  2
27-MAY-15 10.20.34.114 AM                db file sequential read                           1
27-MAY-15 10.20.36.443 AM                                                                  3
27-MAY-15 10.20.44.224 AM                                                                  1
27-MAY-15 10.20.46.553 AM                                                                  1
27-MAY-15 10.20.54.324 AM                db file sequential read                           1
27-MAY-15 10.20.54.324 AM                direct path write                                 8
27-MAY-15 10.21.04.424 AM                db file sequential read                           1
27-MAY-15 10.21.04.424 AM                direct path write                                10
27-MAY-15 10.21.04.424 AM                enq: TX - row lock contention                     1
27-MAY-15 10.21.04.424 AM                                                                  1
27-MAY-15 10.21.06.753 AM                db file sequential read                           1
27-MAY-15 10.21.06.753 AM                                                                  6
27-MAY-15 10.21.14.525 AM                db file sequential read                           1
27-MAY-15 10.21.14.525 AM                direct path write                                17
27-MAY-15 10.21.14.525 AM                enq: TX - row lock contention                     2
27-MAY-15 10.21.14.525 AM                                                                  1
27-MAY-15 10.21.16.853 AM                gc current block 2-way                            1
27-MAY-15 10.21.16.853 AM                gc current grant 2-way                            1
27-MAY-15 10.21.16.853 AM                kjbdrmcvtq lmon drm quiesce: ping completion      1                                         
27-MAY-15 10.21.16.853 AM                log file sync                                     8
27-MAY-15 10.21.16.853 AM                wait for scn ack                                  1
27-MAY-15 10.21.16.853 AM                                                                  5
27-MAY-15 10.21.24.624 AM                db file sequential read                           1
27-MAY-15 10.21.24.624 AM                direct path write                                26
27-MAY-15 10.21.24.624 AM                enq: TX - row lock contention                     3
27-MAY-15 10.21.24.624 AM                gcs drm freeze in enter server mode               1
27-MAY-15 10.21.24.624 AM                                                                  1
27-MAY-15 10.21.26.953 AM                                                                  1
27-MAY-15 10.21.34.814 AM                db file sequential read                           1
27-MAY-15 10.21.34.814 AM                direct path write                                33
27-MAY-15 10.21.34.814 AM                enq: TX - row lock contention                     4
27-MAY-15 10.21.34.814 AM                gcs drm freeze in enter server mode               1
27-MAY-15 10.21.34.814 AM                row cache lock                                   10
27-MAY-15 10.21.34.814 AM                                                                  1
27-MAY-15 10.21.37.053 AM                db file sequential read                           1
27-MAY-15 10.21.37.053 AM                                                                  1
27-MAY-15 10.21.44.914 AM                db file sequential read                           1
27-MAY-15 10.21.44.914 AM                direct path write                                42
27-MAY-15 10.21.44.914 AM                enq: TX - row lock contention                     4
27-MAY-15 10.21.44.914 AM                enq: US - contention                              1
27-MAY-15 10.21.44.914 AM                gcs drm freeze in enter server mode               1
27-MAY-15 10.21.47.163 AM                log file parallel write                           1
27-MAY-15 10.21.47.163 AM                                                                  1
27-MAY-15 10.21.55.014 AM                db file sequential read                           1
27-MAY-15 10.21.55.014 AM                direct path write                                42
27-MAY-15 10.21.55.014 AM                enq: TX - row lock contention                     5
27-MAY-15 10.21.55.014 AM                gc current block 2-way                            1
27-MAY-15 10.21.55.014 AM                gc current grant 2-way                            2
27-MAY-15 10.21.55.014 AM                kjbdrmcvtq lmon drm quiesce: ping completion      1                                         
27-MAY-15 10.21.55.014 AM                log file sync                                     3
27-MAY-15 10.21.55.014 AM                wait for scn ack                                  1
27-MAY-15 10.21.55.014 AM                                                                  5
27-MAY-15 10.21.57.263 AM                db file parallel write                            1
27-MAY-15 10.21.57.263 AM                                                                  1

    如上表所示，从上午10:20开始出现等待事件direct path write，紧接着出现 enq: TX - row lock contention等待事件，direct path write持续增加导致大量会话积压。
    接下来查询等待事件direct path write等待的实例、资源的id号、等待次数的积压情况：

select instance_number,p1,count(*)  from dba_hist_active_sess_history where dbid=3965601902 and
snap_id>49716 and snap_id
and event='direct path write'
and sample_time>to_date('20150527 10:20:00','yyyymmdd hh24:mi:ss') 
group by instance_number,p1 order by 3 ;

INSTANCE_NUMBER         P1   COUNT(*)
--------------- ---------- ----------
              1        461          1
              1        494          1
              1        372          1
              1        495          1
              2        581          1
              2        285          1
              1        479          1
              2        495          1
              2        317          1
              1        587          1
              1        543          1
              2        316          1
              2        438          1
              2        498          1
              2        497          1
              2        499          2
              1        520          2
              2        437          2
              1        466          2
              2        496          2
              1        556          2
              1        439          2
              1        438          2
              1        316          2
              1        498          2
              2        439          3
              1        474          3
              1        436          3
              1        519          3
              1        496          4
              1        475          4
              1        497          4
              2        475          4
              2        494          4
              2        436          4
              1        499          5
              1        437          6
              2        474          7
              1        589      59128
              2        588      84346

    从上表可以开出，rac两个节点均有由于direct path write等待的资源并且有大量的等待，接下来查询对象589、588对应的物理设备：

SQL> select file_name,tablespace_name from dba_data_files where file_id=&file;
Enter value for file: 588
old   1: select file_name,tablespace_name from dba_data_files where file_id=&file
new   1: select file_name,tablespace_name from dba_data_files where file_id=588

FILE_NAME                                       TABLESPACE_NAME
---------------------------------                     ------------------------------
/dev/essdb2vg5/rdb2vg5_10_lv001      TBS_TRADE_D10
SQL> /
Enter value for file: 589
old   1: select file_name,tablespace_name from dba_data_files where file_id=&file
new   1: select file_name,tablespace_name from dba_data_files where file_id=589
FILE_NAME                                       TABLESPACE_NAME
---------------------------------                      ------------------------------
/dev/essdb2vg5/rdb2vg5_10_lv002      TBS_TRADE_D09

    经系统维护责任人确认，这两个裸设备是昨天晚上新扩容的4块盘，先两块盘做raid0，再两个raid0组raid1，然后划分的每10G大小共40个的裸设备，然后对数据库表空间扩的容；通过现场硬件同事的反应，换上去的4块盘，有两块盘是旧盘，又经存储工程师确认新加的raid1组被锁住了。由此可知，由于存储RAID被锁，相关的磁盘无法写入，数据库才会出现direct path write等待事件导致大量会话积压。
    后续处理：由于这是电商平台，业务对数据很敏感，考虑先进行备份，查明有问题的两个裸设备分别属于两个不同的表空间，2个表空间是2个不同方案下相同名称的分区表的photo字段分区。先检验是否能读，方法如下，结果是读失败，所以排除掉备份（无论是exp、expdp、rman）；由于业务方要求28号上午9点必须恢复业务，经过多次尝试，时间已是27号晚上10点多，进行数据库rman全备恢复消耗时间不可控，考虑基于归档的恢复。
    select /*+ parallel(t 8)*/* from "UCR_TRADE_03"."TF_F_IDCARD" partition(PAR_TF_B_IDCARD_VERIFY_8) t;
    基于归档的恢复操作流程，通知存储工程师，准备2个与故障裸设备相同容积的裸设备，指定好数据库用户权限，在数据库中将2个有问题的裸设备进行下线，然后重定向到新的裸设备，再将节点2上从今天早上开始对数据库扩容的时间6:00时的归档拷贝到节点1上，进行recover。
    新的裸设备如下：
/dev/essdb2vg7/rdb2vg7_10_lv001
/dev/essdb2vg7/rdb2vg7_10_lv002
    表空间下线后重定向：
SQL> alter database create datafile 588 as '/dev/essdb2vg7/rdb2vg7_10_lv001'; 
SQL> alter database create datafile 589 as '/dev/essdb2vg7/rdb2vg7_10_lv002'; 
    基于归档恢复：
SQL> recover datafile '/dev/essdb2vg7/rdb2vg7_10_lv001';
SQL> recover datafile '/dev/essdb2vg7/rdb2vg7_10_lv002';
    恢复完毕后将数据文件上线：
SQL> alter database datafile '/dev/essdb2vg7/rdb2vg7_10_lv001' online;
SQL> alter database datafile '/dev/essdb2vg7/rdb2vg7_10_lv002' online; 
    如果有必要，回退到故障点：
停止数据库
shutdown immediate；
startup mount；

alter database rename file '/dev/essdb2vg5/rdb2vg5_10_lv038' to '/dev/essdb2vg5/rdb2vg5_10_lv001';
alter database rename file '/dev/essdb2vg5/rdb2vg5_10_lv039' to '/dev/essdb2vg5/rdb2vg5_10_lv002';

alter database open；
    幸运的是，基于归档的数据文件恢复是成功的。

时间： 2024-10-13 23:00:21

ORACLE等待事件：direct path write的相关文章

Oracle 等待事件 一

以前一直想整理一下关于Oracle 的等待事件,总是没时间.现在觉得应该着手做了,其中的一些知识来自于自己的一点研究,如有错误,望大家指正..... 一 Oracle等待事件主要有两类事件: 1 空闲等待  空闲等待意味着Oracle正在等待某种动作的发生,实际上并不是因为繁忙而等待,而是因为没有事情做所以等待,如:smon timer,SMON进程的一些操作时每隔一段实际循环执行的,即使系统不忙,此事件也不立即发生,而是等待计时器达到一定的时间才执行,此时出现的smon timer 等待事件,

oracle等待事件10——I/O上的等待事件 下篇

5.direct path read temp / direct path write temp 为了排序工作在临时区域读写时,等待direct path read temp.direct path write temp事件.这个等待时间是从10g开始被分类的.9i之前是通过direct path read .direct path write 等特观察的.排序段上的direct path I/O是在需要排序的数据比为排序所分配的PGA内存区大时发生的.因此若排序工作时大量发生direct pa

oracle等待事件3——高速缓冲内enq锁

6. enq:TC-contention 在手动执行检查点操作中,一部分需要获得TC锁(thread checkpointlock 或 tablespace checkpointlock )在获得TC锁过程中,若发生争用,则需要等待enq:TC-contention 事件.事实上获得TC锁的过程稍微复杂. 1) 服务器进程首先以X模式获得TC锁 2) 服务器进程将已获得的TC锁变更为SSX模式.同时,CKPT进程以SS模式获得该锁.CKPT获得锁后执行检查点操作. 3) 服务器欲重新以X模式获得

oracle等待事件9——I/O上的等待事件 上篇

1.db file scattered read oracle在执行全表扫描(FTS:full table scan)或全索引扫描(index full scan)时,为保障性能,尽量一次性读取多个块,这称为Multi Block I/O.每次执行multi block I/O,都会等待物理I/O结束,此时等待db file scattered read 事件.利用db file scattered read等待事件的P1=file#,P2=初始block#,P3=要读取的块数的信息,可以确认哪

oracle等待事件7——事务上的等待事件

1.enq:TM-contention 执行DML期间,为防止对DML相关的对象进行修改,执行DML的进程必须对该表获得TM锁,若获得TM锁的过程发生争用,则等待enq:TM-contention事件. TM锁其用途十分明确,但是准确的概念及定义方面有容易混淆的一面.oracle的手册上关于锁的分类说明如下: DML锁:Date lock.执行DML时保护数据的锁.Row Lock(TX)保护特定行,Table Lock(TM)保护整个表,可以通过dba_kml_locks观察. DDL锁:Da

oracle等待事件2——高速缓冲内等待事件

1.cache buffers lru chain 要想查看或修改工作组(LRU+LRUW)进程,始终要持有管理相应工作组的cache buffers lru chain 锁存器,若在此过程中发生争用,则要等待:latch:cache buffers lru chain 事件. 在下面两类情况下我们必须首先获得cache buffers lru chain锁存器: (1)进程想要读取还没有装载到内存上的块时,通过查询LRU列分配到所需空闲缓冲区,再次过程中需要cache buffers lru

oracle等待事件5——库高速缓存上的等待事件 中

3.library cache lock 和 library cache pin library cache lock 的定义:访问或修改库高速缓冲区的对象时,对库高速缓冲区句柄(handle)获得的锁,在获得library cache lock 的过程中,如果发生争用,则等待library cache lock事件. 通过library cache lock 事件的P1=handle address  P2=lock address  P3=mode*100+namespace,可以掌握对哪个

oracle等待事件8——段上的等待事件

1.enq:HW-contention 为防止多个进程同时修改HWM而提供的锁称为HW锁(官方文档解释:Space management operations on a specific segment).想要移动HWM的进程必须获得HW锁.HW锁争用大部分是因为大量执行insert所引发的,偶尔也会因大量执行update在回滚段中发生HW锁争用现象.若是update,表中段的扩展的大小虽然不多,但在创建回滚数据的过程中,需要回滚段的急速扩张.HW锁争用是在段的急速空间扩张时普遍出现的等待现象,

oracle等待事件11——重做缓冲区上的等待事件

1.latch:redo writing  , latch :redo allocation  ,latch:redo copy oracle 为了保护将重做记录复制到重做缓冲区的一连串过程,使用以下三个锁存器: 1)rodo writing 锁存器:为了占有重做缓冲区内的空间,向LGWR请求写入工作的进程需要获得redo writing锁存器.因为LGWR的写入工作不能同时执行,所以自然在整个实例上只有一个.redo writing锁存器是因为独立锁存器,所以可以通过v$latch_paren