How To Automate Cleanup Of Dead Connections And INACTIVE Sessions [ID 206007.1]

Modified 25-JUN-2009     Type HOWTO     Status PUBLISHED

PURPOSE
-------

This note explains the difference between a dead connection and an
INACTIVE session in v$session.  It also discusses the mechanisms
provided to automate the cleanup of each.

SCOPE & APPLICATION
-------------------

This note is intended for any DBA who wants to automate the cleanup of
dead connections and/or INACTIVE sessions.

Difference between INACTIVE sessions and Dead Connections
---------------------------------------------------------

Dead connections and INACTIVE sessions are different issues. Oracle
provides separate mechanisms to automate the cleanup of each.

(1) Dead connections:

    These are previously valid connections with the database but the
    connection between the client and server processes has terminated
    abnormally.

    Examples of a dead connection:

    - A user reboots/turns-off their machine without logging off
      or disconnecting from the database.
    - A network problem prevents communication between the client
      and the server.

    In these cases, the shadow process running on the server and the
    session in the database may not terminate. To automate the cleanup
    of these sessions, you can use the Dead Connection Detection (DCD)
    feature of Net8.

    When DCD is enabled, Net8 (server-side) sends a packet to the client.
    If the client is active, the packet is discarded. If the client has
    terminated, the server will receive an error and Net8 (server-side)
    will end that session.

    Refer to Note:151972.1: Dead Connection Detection (DCD) Explained,
    for details regarding DCD.

(2) INACTIVE Sessions:

    These are sessions that remain connected to the database with a
    status in v$session of INACTIVE.

    Example of an INACTIVE session:

    - A user starts a program/session, then leaves it running and idle
      for an extended period of time.

    To automate cleanup of INACTIVE sessions you can create a profile
    with an appropriate IDLE_TIME setting and assign that profile to
    the users.

    Note:159978.1: How To Automate Disconnection of Idle Sessions,
    outlines the steps to setup IDLE_TIME for this.

- The End -

相关日志

• 2010/05/13 -- Oracle 10g/11g Latch机制的变化
• 2010/05/13 -- Latch Free（闩锁释放）
• 2010/05/13 -- Enqueue （队列等待）
• 2010/05/13 -- 日志文件相关等待
• 2010/04/12 -- direct path read/write （直接路径读／写）

QQREADERF129F7D46654828B

随机日志

• 2010/04/09 -- 自动负载信息库：AWR的引入
• 2010/02/01 -- 使用Flashback Query恢复误删除数据
• 2009/12/05 -- LIBRARY CACHE PIN 等待事件
• 2009/12/14 -- 产生多少Redo
• 2009/12/23 -- 回滚段的前世今生

在Oracle 10.2..0.1中一个新的参数_kks_use_mutex_pin被引入，不过缺省值为False：

sys@TQGZS> select x.ksppinm name, y.ksppstvl value, x.ksppdesc describ
  2  from sys.x$ksppi x , sys.x$ksppcv y
  3  where x.indx = y.indx
  4  and x.ksppinm like '%&par%'
  5  /
Enter value for par: kks
old   4: and x.ksppinm like '%&par%'
new   4: and x.ksppinm like '%kks%'
NAME                      VALUE           DESCRIB
------------------------- --------------- --------------------------------------------------------
_kks_use_mutex_pin        FALSE           Turning on this will make KKS use mutex for cursor pins.

这意味着新的Mutex机制已经准备好了用于应付Cursor Pin处理。在Oracle 10gR2/11gR1随后的版本中，这个参数被设置为Ture：

sys@CCDB> select * from v$version where rownum < 2;
BANNER
----------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
sys@CCDB> @GetHidPar.sql
Enter value for par: mutex
old   4: AND x.ksppinm LIKE '%&par%'
new   4: AND x.ksppinm LIKE '%mutex%'
NAME                           VALUE                DESCRIB
------------------------------ -------------------- --------------------------------------------------------
_kks_use_mutex_pin             TRUE                 Turning on this will make KKS use mutex for cursor pins.

Mutex机制首先被引入用于替代Library Cache Latch以及Library Cache Pin等机制。使用Mutex Pin机制Oracle能够使用更少的CPU资源获得更好的性能。由于Mutex Pin机制带来的Cursor管理上性能提升，所以曾经用来缓解Cursor Latch竞争的参数CURSOR_SPACE_FOR_TIME从Oracle 10.2.0.5和Oracle 11.1.0.7开始将不再被支持。

在Oracle 11.1.0.6中，以下是数据库中Library Cache相关的Latch与等待：

sys@CCDB> select * from v$version where rownum < 2;
BANNER
----------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
sys@CCDB> select name from v$latch where name like '%library%';
NAME
------------------------------
library cache load lock
sys@CCDB> select name from v$event_name where name like '%library%';
NAME
------------------------------
library cache pin
library cache lock
library cache load lock
library cache: mutex X
library cache: mutex S
OSD IPC library
library cache revalidation
library cache shutdown
8 rows selected.

在Oracle Database 11g中，和Mutex相关的数据库描述已经被引入，首先的变化是和Library Cache相关的Latch仅余library cache load lock：

sys@CCDB> select * from v$version where rownum < 2;
BANNER
----------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
sys@CCDB> select name from v$latch where name like '%library%';
NAME
------------------------------
library cache load lock

其次是等待事件引入了Library Cache:Mutex S/X等待，用以描述因为Mutex竞争而导致的Library Cache等待：

sys@CCDB> select name from v$event_name where name like '%library%';
NAME
------------------------------
library cache pin
library cache lock
library cache load lock
library cache: mutex X
library cache: mutex S
OSD IPC library
library cache revalidation
library cache shutdown
8 rows selected.

虽然在Oracle Database 11gR1中，这些变化已经可以清晰地看到，但是一些问题仍然存在，Oracle仍然在通过一系列不断努力和改进使得这些新的变化走向成熟。

当然Library Cache Latch在某些条件下仍然会被用到，Oracle数据库的很多内容还在不断变化中。关于Mutex的信息主要可以通过两个视图来查询：v$mutex_sleep和v$mutex_sleep_history。以下是一个Oracle 11g生产环境中的查询示范输出：

sys@CCDB> select SLEEP_TIMESTAMP,MUTEX_TYPE,GETS,SLEEPS,LOCATION,MUTEX_VALUE
  2  from v$mutex_sleep_history where rownum <10;
SLEEP_TIMESTAMP                MUTEX_TYPE            GETS     SLEEPS LOCATION             MUTEX_VALUE
------------------------------ --------------- ---------- ---------- -------------------- ----------------
11-MAY-10 08.46.15.176426 PM   Cursor Pin        20439381         80 kksfbc [KKSCHLPIN1]  00
13-MAY-10 04.01.19.066757 PM   Library Cache        39098     113171 kglhdgn1  62         0000021E00000000
13-MAY-10 04.50.40.279082 PM   Library Cache       172560    1384786 kgllkdl1  85         00
06-MAY-10 09.34.57.393852 PM   Library Cache        76718         43 kgllkdl1  85         000001CC00000000
06-MAY-10 10.24.47.734523 PM   Library Cache       103771     383024 kglhdgn1  62         0000031B00000000
13-MAY-10 04.50.40.328295 PM   Library Cache       150176      46662 kgllkdl1  85         000001C200000000
13-MAY-10 04.50.40.291834 PM   Library Cache       208155         45 kgllkdl1  85         00
09-MAY-10 01.00.03.163520 AM   Library Cache          155          1 kglhdgn1  62         00
07-MAY-10 03.33.35.071512 PM   Library Cache         2933          5 kgllkdl1  85         0000029700000000
9 rows selected.

- The End -

相关日志

• 2010/05/13 -- Latch Free（闩锁释放）
• 2010/05/13 -- Enqueue （队列等待）
• 2010/05/13 -- 日志文件相关等待
• 2010/04/12 -- direct path read/write （直接路径读／写）
• 2010/04/10 -- db file scattered read 等待事件

Latch是一种低级排队（串行）机制，用于保护SGA中共享内存结构。Latch就像是一种快速被获取和释放的内存锁，用于防止共享内存结构被多个用户同时访问。其实不必把Latch想得过于复杂，Latch通常就是操作系统利用内存中的某个区域，通过设置变量为0或非0，来表示Latch是否已经被取得，大多数操作系统，是使用TEST AND SET的方式来完成Latch检查或持有的。

为了快速地获得一个直观认识，以下示例展现的了Latch的获取与释放过程。Latch在内存中的位置及名称可以通过下面的语句查询获得：

sys@CCDB> select k.ksmfsadr,ksmfsnam,ksmfstyp,ksmfssiz,kslldnam,kslldlvl
  2  from x$ksmfsv k,x$kslld a
  3  where k.ksmfsnam = 'ksqeql_' and kslldnam = 'enqueues';
KSMFSADR         KSMFSNAM        KSMFSTYP          KSMFSSIZ KSLLDNAM          KSLLDLVL
---------------- --------------- --------------- ---------- --------------- ----------
000000006000CA68 ksqeql_         ksllt                  160 enqueues                 5

得到这些信息之后，可以通过Latch的地址信息手工对Latch进行模拟的持有或释放，注意获取Latch使用了kslgetl过程，释放Latch使用了kslfre，也就是Latch Free过程，如下所示：

sys@CCDB> select to_number('000000006000CA68','XXXXXXXXXXXXXXXX') from dual;
TO_NUMBER('000000006000CA68','XXXXXXXXXXXXXXXX')
------------------------------------------------
                                      1610664552                                     
sys@CCDB> oradebug setmypid
Statement processed.
sys@CCDB> oradebug call kslgetl 1610664552 1
Function returned 1
sys@CCDB> oradebug call kslfre 1610664552
Function returned 0

在这个Latch的短时持有前后，观察这个Latch的等待时间，可以发现大量的Latch等待已经发生，如下所示，这就是Latch、Latch Get和Latch Free的一个直观案例。

sys@CCDB> select name,wait_time from v$latch where name = 'enqueues';
NAME                                                          WAIT_TIME
------------------------------------------------------------ ----------
enqueues                                                              0
sys@CCDB> select name,wait_time from v$latch where name = 'enqueues';
NAME                                                          WAIT_TIME
------------------------------------------------------------ ----------
enqueues                                                              8

在数据库内部，Oracle通过v$latch视图记录不同类型Latch的统计数据，按获取和等待方式不同进行分类，Latch请求的类型可以分为willing-to-wait和immediate两类。
·willing-to-wait：是指如果所请求的Latch不能立即得到，请求进程将等待一段很短的时间后再次发出请求。进程一直重复此过程直到得到Latch。
·immediate：是指如果所请求的Latch不能立即得到，请求进程就不再等待，而是继续执行下去。

在v$latch中以下字段记录了willing-to-wait请求。
· GET：成功地以willing-to-wait请求类型请求一个Latch的次数。
· MISSES：初始以willing-to-wait请求类型请求一个Latch不成功，而进程进入等待的次数。
· SLEEPS：初始以willing-to-wait请求类型请求一个Latch不成功后，进程等待获取Latch时进入休眠的次数。

在v$latch中以下字段记录了immediate类请求。
· IMMEDIATE_GETS：以immediate请求类型成功地获得一个Latch的次数。
· IMMEDIATE_MISSES：以immediate请求类型请求一个Latch不成功的次数。

Oracle的Latch机制是竞争，其处理类似于网络里的CSMA/CD，所有用户进程争夺Latch，对于愿意等待类型（willing-to-wait）的Latch，如果一个进程在第一次尝试中没有获得Latch开始自旋（spin），如果经过_spin_count次争夺不能获得Latch，然后该进程转入睡眠状态，持续一段指定长度的时间，然后再次醒来，按顺序重复以前的步骤。这一过程可以下图来说明：

SPIN的次数受隐含参数_spin_count影响，该参数的缺省值为2000。以下数据取自Oracle 11gR1 + Linux环境：

sys@CCDB> select * from v$version where rownum < 2;
BANNER
----------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production

该系统存在4颗CPU：

sys@CCDB> show parameter cpu_count
NAME                                 TYPE            VALUE
------------------------------------ --------------- ---------
cpu_count                            integer         4

_spin_count的缺省值即为2000：

sys@CCDB> @GetHidPar.sql
Enter value for par: _spin_count
old   4: AND x.ksppinm LIKE '%&par%'
new   4: AND x.ksppinm LIKE '%_spin_count%'
NAME                           VALUE                DESCRIB
------------------------------ -------------------- ----------------------------------
_spin_count                    2000                 Amount to spin waiting for a latch
_kgx_spin_count                255                  third spare parameter - integer

从以上过程可以看到，在spin的过程中，进程会一直持有CPU，spin的机制是假设Latch可以被快速释放（正常情况下，Latch的持有时间是微秒级，相对spin机制如果直接采用Sleep方式引起的上下文切换会相当昂贵，所以Oracle针对Latch引入了spin算法），如果其他CPU上的其他进程释放了Latch，SPIN进程就可以立即获得这个Latch。如果系统只有单CPU，那就谈不上SPIN了。另一方面也可以看到，Latch竞争是非常昂贵的，可能导致严重的CPU耗用，所以Latch竞争在任何时候都应该引起充分的重视。经过spin后成功获得Latch的次数被记录在v$latch.spin_gets字段。通过下图来说明一下Latch竞争的情况。

继续来具体看一下willing-to-wait和immediate两类Latch的大致数量，以下查询来自Oracle 11gR1（同以上数据库）：

sys@CCDB> select count(*) from v$latch;
  COUNT(*)
----------
       496
sys@CCDB> select count(*) from v$latch where IMMEDIATE_GETS + IMMEDIATE_MISSES > 0;
  COUNT(*)
----------
        26
sys@CCDB> select count(*) from v$latch where IMMEDIATE_GETS + IMMEDIATE_MISSES = 0;
  COUNT(*)
----------
       470

可以看到willing-to-wait类型的等待事件占了绝大部分，immediate类型的仅为少数：

sys@CCDB> select name,immediate_gets,immediate_misses,spin_gets
  2  from v$latch
  3  where immediate_gets + immediate_misses > 0
  4  order by immediate_gets desc;
NAME                           IMMEDIATE_GETS IMMEDIATE_MISSES  SPIN_GETS
------------------------------ -------------- ---------------- ----------
cache buffers chains                    58212                1          9
hash table column usage latch           34803                0          0
cache buffers lru chain                 30936               92         17
redo copy                                9646               11          0
redo allocation                          9646                0          1
JOX SGA heap latch                       2257                0          0
space background task latch              2102                0          0
checkpoint queue latch                   1712                0          0
In memory undo latch                     1371                0          0
simulator lru latch                      1312                1         17
active service list                      1077                0          0
Memory Management Latch                  1055                0          0
SQL memory manager latch                 1045                0          0
KTF sga latch                             980                0          0
cache table scan latch                    394                1          0
process queue reference                   131                1          1
job workq parent latch                    114                0          0
process allocation                        109                0          0
MQL Tracking Latch                         63                0          0
post/wait queue                             8                0          0
SGA IO buffer pool latch                    4                0          0
query server process                        3                0          0
shared server configuration                 2                0          0
object queue header heap                    2                0          0
JOX JIT latch                               1                0          0
object stats modification                   1                0          0
26 rows selected.

需要注意的是，immediate类型的Latch通常是因为存在多个可用Latch，最常见的如redo copy latch，当process想要取得redo copy latch时，它首先要求其中一个Latch，如果可以取得就持有该Latch，如果不能获取，它会立刻转向要求另一个redo copy latch，只有所有redo copy latch都无法取得时，才会sleep与wait。

immediate的另外一种原因是每个Latch都有level的概念（level=1 - 14），当一个process需要取得一组Latches时，为避免死锁，取得Latches有一定的顺序，即process新请求的Latch的level，应该大于process目前所握有的Latch的level。所以如果process要求的新Latch的level小于目前所持有的Latch的level，正常情况下，Oracle要求process先释放目前所持有的所有Latch，再依次取得这些Latch。为节省时间，Oracle允许进程以no-wait方式要求较低level的Latch，如果成功取得，既可以避免deadlcok又可以节省时间。

在Oracle 10g之前，Latch Free同Enqueue一样，是一个汇总等待。从Oracle 10g开始，这个等待被分解，现在可以更直接地通过会话等待得知具体的Latch发生在哪些资源上：

sys@CCDB> select name,wait_class
  2  from v$event_name
  3  where name like '%latch%';
NAME                                               WAIT_CLASS
-------------------------------------------------- --------------------
latch: cache buffers chains                        Concurrency
latch: redo writing                                Configuration
latch: redo copy                                   Configuration
latch: Undo Hint Latch                             Concurrency
latch: In memory undo latch                        Concurrency
latch: MQL Tracking Latch                          Concurrency
latch: row cache objects                           Concurrency
latch: shared pool                                 Concurrency
latch free                                         Other
latch activity                                     Other
wait list latch activity                           Other
wait list latch free                               Other
latch: session allocation                          Other
latch: messages                                    Other
latch: enqueue hash chains                         Other
latch: ges resource hash list                      Other
ges2 proc latch in rm latch get 1                  Other
ges2 proc latch in rm latch get 2                  Other
gcs remastering wait for write latch               Other
gcs remastering wait for read latch                Other
latch: gcs resource hash                           Other
latch: cache buffers lru chain                     Other
latch: checkpoint queue latch                      Other
latch: cache buffer handles                        Other
buffer latch                                       Other
latch: object queue header operation               Other
latch: redo allocation                             Other
latch: gc element                                  Other
latch: undo global data                            Other
latch: Change Notification Hash table latch        Other
latch: change notification client cache latch      Other
latch: lob segment hash table latch                Other
latch: lob segment query latch                     Other
latch: lob segment dispenser latch                 Other
waiting to get CAS latch                           Other
waiting to get RM CAS latch                        Other
latch: virtual circuit queues                      Other
PX qref latch                                      Other
latch: parallel query alloc buffer                 Other
39 rows selected.

最常见的Latch集中于Buffer Cache的竞争和Shared Pool的竞争。和Buffer Cache相关的主要Latch竞争有cache buffers chains和cache buffers lru chain，和Shared Pool相关的主要Latch竞争有Shared Pool Latch和Library Cache Latch等。

Buffer Cache的Latch竞争经常是由于热点块竞争引起；Shared Pool的Latch竞争通常是由于SQL的量硬解析引起。

- The End -

相关日志

• 2010/05/13 -- Oracle 10g/11g Latch机制的变化
• 2010/05/13 -- Enqueue （队列等待）
• 2010/05/13 -- 日志文件相关等待
• 2010/04/12 -- direct path read/write （直接路径读／写）
• 2010/04/10 -- db file scattered read 等待事件

在Oracle 10g之前，Enqueue事件是一组锁定事件的集合，如果数据库中这个等待事件比较显著，我们还需要进一步来追踪是哪个类别的锁定引发了数据库等待。

从Oracle 10g开始，Oracle对于队列等待进行了细分，v$event_name视图中可以查询这些细分后的等待事件，简要摘录几个示例如下：

sys@CCDB> select name,wait_class
  2  from v$event_name     
  3  where name like '%enq%';
NAME                                  WAIT_CLASS
------------------------------------- ------------------------
enq: PW - flush prewarm buffers       Application
enq: RO - contention                  Application
enq: RO - fast object reuse           Application
enq: KO - fast object checkpoint      Application
enq: TM - contention                  Application
enq: ST - contention                  Configuration
enq: TX - row lock contention         Application
enq: TX - allocate ITL entry          Configuration
enq: TX - index contention            Concurrency
enq: TW - contention                  Administrative
enq: HW - contention                  Configuration
......

Oracle 的锁按照类型可以分为排他锁（Exclusive，缩写为X）与共享锁（Share，缩写为S），或者是两者的组合锁。排他锁（X）也被称为独占锁，在排他锁释放之前，一个对象上不能施加任何其他类型的锁定；而共享锁（S）在释放之前，对象上还可以继续加其他类型的共享锁，但是不能加排他锁。

如果按照事务的类型划分，又可以将锁定划分为DML锁，DDL锁以及内存锁（也即通常所说的Latch）。Oracle在数据库内部用Enqueue等待来记录锁定，通过Latch Free等待事件来记录闩。Enqueue等待常见的有ST、HW、TX、TM等，下面择要进行介绍。

1. 最重要的锁定：TM与TX锁
对于数据库来说，最常见的锁定类型是TM以及TX锁定。

TX锁通常被称为事务锁，当一个事务开始时，如执行INSERT/DELETE/UPDATE/MERGE等操作或者使用SELECT ... FOR UPDATE语句进行查询时，会首先获取事务锁，直到该事务结束。Oracle的TX锁定是在行级获得的，每个数据行上都存在一个锁定位（1b-Lock Byte），用于判断该记录是否被锁定，同时在每个数据块的头部（Header）存在一个ITL的数据结构，用于记录事务信息等，当需要修改数据时，首先需要获得回滚段空间用于存储前镜像信息，然后这个事务信息同样被记录在ITL上，通过ITL可以将回滚信息和数据块关联起来，所以说Oracle的行级锁定是在数据块上获得的，行级锁只有排他锁没有共享模式。

TM锁通常称为表级锁，可以通过手工发出lock命令获得，或者通过DML操作以及SELECT FOR UPDATE获得，表级锁可以防止其他进程对表加X排他锁，防止在对数据修改时，其他任务通过DDL来修改表结构或者truncate、drop表等操作。可以通过v$lock视图来观察锁定信息，其中TYPE字段表示锁定类型。对于TM锁LMODE字段又代表了不同级别的TM锁，这些级别包括2-row-S(SS)、3-row-X(SX)、4-share(S)、5-S/Row-X(SSX)和6-exclusive(X)。

当执行DML操作时，首先加TM锁，如果能获得锁定，则继续加TX事务锁。在一个会话中，一般只存在一个TX事务锁，在提交或回滚之前，该会话的所有DML操作都属于一个事务，使用一个回滚段，占用一个回滚段事务槽（Slot）。

以下通过SCOTT用户锁定一行记录，暂时不要提交：

scott@CCDB> update emp set sal = 4000 where empno = 7788;
1 row updated.

在另外session通过v$lock视图可以看到相关的锁定信息；

sys@CCDB> select sid,username from v$session where username = 'SCOTT';
       SID USERNAME
---------- ------------------------------
      1075 SCOTT
sys@CCDB> select * from v$lock where sid = 1075;
ADDR             KADDR                   SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
---------------- ---------------- ---------- -- ---------- ---------- ---------- ---------- ---------- ----------
000000008F836260 000000008F8362B8       1075 AE         99          0          4          0       1208          0
00002BA14E74A7F8 00002BA14E74A858       1075 TM      69539          0          3          0         16          0
000000008DF49A30 000000008DF49AA8       1075 TX      65551      30498          6          0         16          0

此时表上的行级排他锁会阻塞对于表的DDL语句：

sys@CCDB> truncate table scott.emp;
truncate table scott.emp
                     *
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired

此外，TM锁定的ID1代表的就是锁定的对象号：

sys@CCDB> select owner,object_name from dba_objects where object_id = 69539;
OWNER           OBJECT_NAME
--------------- ---------------
SCOTT           EMP

而TX锁的ID1代表的是事务的回滚段回滚段号、事务槽号，ID2代表的是顺序号：

sys@CCDB> select trunc(65551/power(2,16)),mod(65551,power(2,16)) from dual;
TRUNC(65551/POWER(2,16)) MOD(65551,POWER(2,16))
------------------------ ----------------------
                       1                     15

通过v$transaction视图也可以找到这个事务的信息（注意XIDSQN正是TX锁的ID2信息）：

sys@CCDB> select XIDUSN,XIDSLOT,XIDSQN from v$transaction;
    XIDUSN    XIDSLOT     XIDSQN
---------- ---------- ----------
         1         15      30498

如果转储回滚段信息进行分析，再结合ITL事务槽，可以清晰地看到锁定的含义以及整个事务的处理过程。

2. 最常见的锁定：MR与AE锁
可能很多朋友都注意过，在v$lock视图中，最常见的其实是MR锁，也就是介质恢复锁（Media Recovery）：

sys@CCDB> select * from v$lock where type = 'MR';
ADDR             KADDR                   SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
---------------- ---------------- ---------- -- ---------- ---------- ---------- ---------- ---------- ----------
00000000BC2EE378 00000000BC2EE3D0       1097 MR          1          0          4          0    6984045          0
00000000BC2EE448 00000000BC2EE4A0       1097 MR          2          0          4          0    6984045          0
00000000BC2EE518 00000000BC2EE570       1097 MR          3          0          4          0    6984045          0
00000000BC2EE5E8 00000000BC2EE640       1097 MR          4          0          4          0    6984045          0
00000000BC2EE6B8 00000000BC2EE710       1097 MR          5          0          4          0    6984045          0
00000000BC2EE788 00000000BC2EE7E0       1097 MR          6          0          4          0    6984045          0
00000000BC2EE858 00000000BC2EE8B0       1097 MR          7          0          4          0    6984045          0
00000000BC2EE940 00000000BC2EE998       1097 MR          8          0          4          0    6984045          0
00000000BC2EEA10 00000000BC2EEA68       1097 MR        201          0          4          0    6984045          0
00000000BC2F12F8 00000000BC2F1350       1097 MR          9          0          4          0    1132526          0
10 rows selected.

MR锁用于保护数据库文件，使得文件在数据库打开、表空间Online时不能执行恢复。当进程对数据文件执行恢复时，需要排他的获得MR锁。当数据库打开时，每个文件上都分配一个MR锁。注意在以上输出中ID1代表文件号，其中也包含了201号临时文件。

从Oracle Database 11g开始，除了每个文件要获得MR锁之外，每个登录数据库的会话现在都会缺省获得一个AE锁：

sys@CCDB> select * from v$lock where type = 'AE' and rownum <= 5;
ADDR             KADDR                   SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
---------------- ---------------- ---------- -- ---------- ---------- ---------- ---------- ---------- ----------
00000000BC2EDF68 00000000BC2EDFC0        822 AE         99          0          4          0    2761930          0
00000000BC2EE108 00000000BC2EE160        946 AE         99          0          4          0    3458645          0
00000000BC2EE1D8 00000000BC2EE230       1003 AE         99          0          4          0     207674          0
00000000BC2EE2A8 00000000BC2EE300       1092 AE         99          0          4          0    6984538          0
00000000BC2EEAE0 00000000BC2EEB38        991 AE         99          0          4          0    3458644          0

现在MR锁定和AE锁定是数据库中最为常见的锁定。

sys@CCDB> select name from v$event_name where name like '%AE%';
NAME
------------------------------------------------------------
enq: AE - lock

3. ST（空间事务锁）
ST锁主要用于空间管理和字典管理的表空间（DMT）的区间分配，在DMT中典型的是对于uet$和fet$数据字典表的争用。对于支持LMT的版本。应该尽量使用本地管理表空间，或者考虑手工预分配一定数量的区（Extent），减少动态扩展时发生的严重队列竞争。

以下案例说明了ST锁可能会导致的严重性能问题。

DB Name         DB Id    Instance     Inst Num Release     OPS Host
------------ ----------- ------------ -------- ----------- --- ------------------
DB           40757346    tqgzs               1 8.1.7.4.0   NO  server
                Snap Id     Snap Time      Sessions
                ------- ------------------ --------
Begin Snap:       2845 31-10月-03 02:10:16      46
  End Snap:       2848 31-10月-03 03:40:05      46
   Elapsed:                  89.82 (mins)

对于一个Statspack的report，采样时间是非常重要的维度，离开时间做参考，任何等待都不足以说明问题。

Top 5 Wait Events
~~~~~~~~~~~~~~~~~                                    Wait               % Total
Event                                                Waits  Time (cs)   Wt Time
-------------------------------------------- ------------ ------------ -------
enqueue                                            53,793   16,192,686   67.86
rdbms ipc message                                  19,999    5,927,350   24.84
pmon timer                                          1,754      538,797    2.26
smon timer                                             17      522,281    2.19
SQL*Net message from client                        94,525      520,104    2.18
          -------------------------------------------------------------

在Statspack分析中，Top 5等待事件是我们最为关注的部分。这个系统中，除了enqueue等待事件以外，其他4个都属于空闲等待事件，无须关注。来关注一下enqueue等待事件，在89.82 (mins)的采样间隔内，累计enqueue等待长达16,192,686(cs)，即45小时左右。这个等待已经太过显著，实际上这个系统也正因此遭遇了巨大的困难，观察到队列等待以后，这应该关注队列等待在等待什么资源。快速跳转的Statspack的其他部分，看到以下详细内容：

Enqueue activity for DB: DB  Instance: aaa  Snaps: 2845 -2848
-> ordered by waits desc, gets desc
Enqueue            Gets      Waits
---------- ------------ ----------
ST                1,554      1,554
          -------------------------------------------------------------

看到主要队列等待在等待ST锁定，对于DMT，我们说这个等待和FET$、UET$的争用紧密相关。再回过头来研究捕获SQL语句：

-> End Buffer Gets Threshold:   10000
-> Note that resources reported for PL/SQL includes the resources used by
   all SQL statements called within the PL/SQL code.  As individual SQL
   statements are also reported, it is possible and valid for the summed
   total % to exceed 100
  Buffer Gets    Executions  Gets per Exec  % Total  Hash Value
--------------- ------------ -------------- ------- ------------
      4,800,073       10,268          467.5    51.0   2913840444
select length from fet$ where file#=:1 and block#=:2 and ts#=:3
        803,187       10,223           78.6     8.5    528349613
delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 a
nd ext#=:4
        454,444       10,300           44.1     4.8   1839874543
select file#,block#,length from uet$ where ts#=:1 and segfile#=:
2 and segblock#=:3 and ext#=:4
         23,110       10,230            2.3     0.2   3230982141
insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)
         21,201          347           61.1     0.2   1705880752
select file# from file$ where ts#=:1
….
          9,505           12          792.1     0.1   1714733582
select f.file#, f.block#, f.ts#, f.length from fet$ f, ts$ t whe
re t.ts#=f.ts# and t.dflextpct!=0 and t.bitmapped=0
          6,426          235           27.3     0.1   1877781575
delete from fet$ where file#=:1 and block#=:2 and ts#=:3

可以看到数据库频繁操作UET$、FET$系统表已经成为了系统的主要瓶颈。

至此，已经可以准确地为该系统定位问题，相应的解决方案也很容易确定，在Oracle 8.1.7中使用LMT代替DMT，这是解决问题的根本办法，当然实施起来还要进行综合考虑，实际情况还要复杂得多。

- The End -

相关日志

• 2010/05/13 -- Oracle 10g/11g Latch机制的变化
• 2010/05/13 -- Latch Free（闩锁释放）
• 2010/05/13 -- 日志文件相关等待
• 2010/04/12 -- direct path read/write （直接路径读／写）
• 2010/04/10 -- db file scattered read 等待事件

sys@CCDB> select name from v$event_name where name like '%log%';
NAME
--------------------------------------------------
logout restrictor
LNS ASYNC archive log
LNS ASYNC end of log
log file sequential read
log file single write
log file parallel write
log buffer space
log file switch (checkpoint incomplete)
log file switch (private strand flush incomplete)
log file switch (archiving needed)
switch logfile command
log file switch completion
log file sync
simulated log write delay
Streams capture: waiting for archive log
ges RMS0 retry add redo log
gcs log flush sync
log switch/archive
ARCH wait for archivelog lock
MRP wait on archivelog delay
MRP wait on archivelog arrival
MRP wait on archivelog archival
log file switch (clearing log file)
enq: XR - database force logging
recovery area: computing applied logs
enq: FL - Flashback database log
flashback free VI log
flashback log switch
log write(odd)
log write(even)
30 rows selected.

下面摘录几个重要事件进行详细介绍。

1. log file switch（日志文件切换）：
log file switch当日志文件发生切换时出现，在数据库进行日志切换后，后台进程LGWR需要关闭当前日志组，切换并打开下一个日志组，在这个切换过程中，数据库的所有DML操作都处于停顿状态，直至这个切换完成。

log file switch主要包含两个事件，log file switch (checkpoint incomplete)和log file switch (archiving needed)。
⑴ log file switch (archiving needed)，即日志切换（需要归档），这个等待事件出现时通常是因为日志组循环写满以后，在需要覆盖先前日志时，发现日志归档尚未完成，出现该等待。由于redo能不写出，该等待出现时，数据库将陷于停顿状态。

出现该等待，可能表示I/O存在问题、归档进程写出缓慢，也有可能是日志组设置不合理等原因导致。针对不同原因，可以考虑采用解决办法有：
·可以考虑增大日志文件和增加日志组；
·移动归档文件到快速磁盘；
·调整log_archive_max_processes参数等。

⑵ log file switch (checkpoint incomplete)，即日志切换（检查点未完成）。当所有的日志组都写满之后，LGWR试图覆盖某个日志文件，如果这时数据库没有完成写出由这个日志文件所保护的脏数据时（检查点未完成），该等待事件出现。该等待出现时，数据库同样将陷于停顿状态。

同时警告日志文件中会记录如下信息：

Sat Feb 13 06:10:52 2010
Thread 1 advanced to log sequence 5115
  Current log# 3 seq# 5115 mem# 0: /home/oracle/app/oracle/oradata/ccdb/redo03.log
Thread 1 cannot allocate new log, sequence 5116
Checkpoint not complete
  Current log# 3 seq# 5115 mem# 0: /home/oracle/app/oracle/oradata/ccdb/redo03.log
Thread 1 advanced to log sequence 5116
  Current log# 1 seq# 5116 mem# 0: /home/oracle/app/oracle/oradata/ccdb/redo01.log

该等待事件通常表示DBWR写出速度太慢或者I/O存在问题。为解决该问题，用户可能需要考虑增加额外的DBWR或者增加日志组或日志文件大小。log file switch引起的等待都是非常重要的，如果出现就应该引起重视，并由DBA介入进行及时处理。

2. log file sync（日志文件同步）：
当一个用户提交或回滚数据时，LGWR将会话期的重做由日志缓冲器写入到重做日志中，LGWR完成任务以后会通知用户进程。日志文件同步过程（Log File Sync）必须等待这一过程成功完成。对于回滚操作，该事件记录从用户发出rollback命令到回滚完成的时间。

如果该等待过多，可能说明LGWR的写出效率低下，或者系统提交过于频繁。针对该问题，可以关注log file parallel write等待事件，或者通过user commits、user rollback等统计信息观察提交或回滚次数。

可能的解决方案主要有：
·提高LGWR性能，尽量使用快速磁盘，不要把redo log file存放在RAID5的磁盘上；
·使用批量提交；
·适当使用NOLOGGING/UNRECOVERABLE等选项。

可以通过如下公式计算平均redo写大小：

avg.redo writ size = (redo block written/redo writes)*512 bytes

如果系统产生redo很多，而每次写的较少，一般说明LGWR被过于频繁地激活了。可能导致过多的redo相关latch的竞争，而且Oracle可能无法有效地使用piggyback的功能。

从一个Statspack报告中提取一些数据来研究一下这个问题。
Report概要信息如下：

STATSPACK report for

Database    DB Id    Instance     Inst Num  Startup Time   Release     RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
          3317656585 ccdb                1 03-Feb-10 22:20 11.1.0.6.0  NO

Host Name             Platform                CPUs Cores Sockets   Memory (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
     MWSG1            Linux 64-bit for AMD       4     4       4          5.5

Snapshot       Snap Id     Snap Time      Sessions Curs/Sess Comment
~~~~~~~~    ---------- ------------------ -------- --------- -------------------
Begin Snap:         22 14-Apr-10 10:00:04      155       2.0
  End Snap:         23 14-Apr-10 11:00:05      233       2.1
   Elapsed:          60.02 (mins)
   DB time:         244.73 (mins)     DB CPU:        9.92 (mins)

Cache Sizes            Begin        End
~~~~~~~~~~~       ---------- ----------
    Buffer Cache:       912M              Std Block Size:         8K
     Shared Pool:       576M                  Log Buffer:     6,939K

Load Profile              Per Second    Per Transaction    Per Exec    Per Call
~~~~~~~~~~~~      ------------------  ----------------- ----------- -----------
      DB time(s):                4.1                8.0        0.01        0.00
       DB CPU(s):                0.2                0.3        0.00        0.00
       Redo size:            5,148.5           10,147.7

等待事件如下：

Top 5 Timed Events                                                    Avg %Total
~~~~~~~~~~~~~~~~~~                                                   wait   Call
Event                                            Waits    Time (s)   (ms)   Time
----------------------------------------- ------------ ----------- ------ ------
db file sequential read                        249,549      12,994     52   81.7
log file sync                                    9,125       1,092    120    6.9
log file parallel write                          8,932         864     97    5.4
control file parallel write                      1,189         425    357    2.7
CPU time                                                       324           2.0
          -------------------------------------------------------------
                                                             Avg          %Total
                                          %Tim Total Wait   wait    Waits   Call
Event                               Waits  out   Time (s)   (ms)     /txn   Time
---------------------------- ------------ ---- ---------- ------ -------- ------
db file sequential read           249,549    0     12,994     52    136.6   81.7
log file sync                       9,125    6      1,092    120      5.0    6.9
log file parallel write             8,932    0        864     97      4.9    5.4
control file parallel write         1,189    0        425    357      0.7    2.7

注意以上的输出信息，这里log file sync和log file parallel write还有control file parallel write等待事件同时出现，那么可能的一个原因是I/O竞争导致了性能问题，实际用户环境正是日志文件和数据文件和控制文件等同时存放在RAID5的磁盘上，存在性能问题需要调整。

统计信息如下：

Statistic                                      Total     per Second    per Trans
--------------------------------- ------------------ -------------- ------------
......
redo blocks checksummed by FG (ex             12,546            3.5          6.9
redo blocks written                           42,942           11.9         23.5
redo blocks written for direct wr             65,824           18.3         36.0
redo buffer allocation retries                     3            0.0          0.0
redo entries                                  43,842           12.2         24.0
redo log space requests                            3            0.0          0.0
redo log space wait time                          29            0.0          0.0
redo ordering marks                              788            0.2          0.4
redo size                                 18,539,824        5,148.5     10,147.7
redo subscn max counts                         1,830            0.5          1.0
redo synch time                              109,173           30.3         59.8
redo synch writes                              8,489            2.4          4.7
redo wastage                               2,431,180          675.1      1,330.7
redo write time                               86,227           24.0         47.2
redo writer latching time                          0            0.0          0.0
redo writes                                    8,936            2.5          4.9
......
sorts (disk)                                       0            0.0          0.0
sorts (memory)                               558,140          155.0        305.5
sorts (rows)                              18,638,004        5,175.8     10,201.4
......
transaction rollbacks                              1            0.0          0.0
transaction tables consistent rea                  0            0.0          0.0
transaction tables consistent rea                  0            0.0          0.0
undo change vector size                    6,314,760        1,753.6      3,456.4
user I/O wait time                         1,308,751          363.4        716.3
user calls                                 5,128,699        1,424.2      2,807.2
user commits                                   1,816            0.5          1.0
user rollbacks                                    11            0.0          0.0
workarea executions - onepass                      0            0.0          0.0
workarea executions - optimal                538,179          149.5        294.6
write clones created in backgroun                  0            0.0          0.0
write clones created in foregroun                 14            0.0          0.0
          -------------------------------------------------------------

根据统计信息可以计算平均日志写大小：

avg.redo write size = ( Redo block written/redo writes )*512 bytes
                    = ( 42,942/8,936 )*512
                    = 2.4KB
这个平均值过小了，说明系统提交过于频繁。

等待事件柱状图如下：

Wait Event Histogram  DB/Inst: CCDB/ccdb  Snaps: 22-23
-> Total Waits - units: K is 1000, M is 1000000, G is 1000000000
-> % of Waits - column heading: <=1s is truly <1024ms, >1s is truly >=1024ms
-> % of Waits - value: .0 indicates value was <.05%, null is truly 0
-> Ordered by Event (idle events last)

                           Total ----------------- % of Waits ------------------
Event                      Waits  <1ms  <2ms  <4ms  <8ms <16ms <32ms  <=1s   >1s
-------------------------- ----- ----- ----- ----- ----- ----- ----- ----- -----
......
control file parallel writ 1189                            2.0  53.1  37.0   7.9
control file sequential re 5059   99.8          .0    .1    .0    .1          .0
cursor: mutex X             292   96.6    .7    .3          .7    .3   1.4
cursor: pin S               476   70.2   2.9   7.4   7.6   5.7   5.5    .8
cursor: pin S wait on X      23    4.3               4.3  82.6   8.7
db file parallel read         2                           50.0        50.0
db file scattered read      116   18.1   7.8  15.5  32.8  14.7   9.5   1.7
db file sequential read     249K  23.0   3.1  11.4  28.1  15.3   7.6  10.9    .7
......
log file parallel write    8935           .1   2.7  14.6  26.9  20.7  33.3   1.6
log file sequential read     49   16.3              63.3   6.1  10.2   4.1
log file single write         2                     50.0  50.0
log file switch completion    2                                      100.0
log file sync              9128    1.9    .4   7.2   9.3  23.6  17.1  40.5

从等待事件柱状图，也可以明显地看到I/O竞争导致了性能问题。

3. log file single write
该事件仅与写日志文件头块相关，通常发生在增加新的组成员和增进序列号（log switch）时。头块写单个进行，因为头块的部分信息是文件号，每个文件不同。

更新日志文件头这个操作在后台完成，一般很少出现等待，无需太多关注。在log switch的过程中，LGWR需要改写日志文件头，有时可以观察到该等待事件的增加：

sys@CCDB> select event,time_waited from v$system_event where event = 'log file single write';
EVENT                                    TIME_WAITED
---------------------------------------- -----------
log file single write                           5541

sys@CCDB> alter system switch logfile;
System altered.

sys@CCDB> alter system switch logfile;
System altered.

sys@CCDB> select event,time_waited from v$system_event where event = 'log file single write';
EVENT                                    TIME_WAITED
---------------------------------------- -----------
log file single write                           5546

4. log file parallel write
从log buffer写redo记录到日志文件，主要指常规写操作（相对于log file sync）。如果每个日志组存在多个组成员，当flush log buffer时，写操作是并行的，这时此等待事件可能出现。

尽管这个写操作并行处理，直到所有I/O操作完成该写操作才会完成（如果磁盘支持异步IO或者使用IO SLAVE，那么即使只有一个redo log file member，也有可能出现此等待）。这个参数和log file sync时间相比较可以用来衡量log file的写入成本，通常称为同步成本率。

5. log Buffer Space - 日志缓冲空间
当数据库产生日志的速度比LGWR的写出速度快，或者是当日志切换（log switch）太慢时，就会发生这种等待。这个等待出现时，通常表明redo log buffer过小，为解决这个问题，可以考虑增大日志文件的大小，或者增加日志缓冲区的大小。

另外一个可能的原因是磁盘I/O存在瓶颈，可以考虑使用写入速度更快的磁盘。在允许的条件下，可以考虑使用裸设备来存放日志文件，提高写入效率。在一般的系统中，最低的标准是，不要把日志文件和数据文件存放在一起，因为通常日志文件只写不读，分离存放可以获得性能提升，尽量使用RAID10而不是RAID5磁盘来存储日志文件。

Log Buffer Space等待事件出现时，数据库将陷入停顿状态，所有和日志生成相关的操作全部不能进行，所以这个等待事件应该引起充分的重视。

- The End -

相关日志

• 2010/05/13 -- Oracle 10g/11g Latch机制的变化
• 2010/05/13 -- Latch Free（闩锁释放）
• 2010/05/13 -- Enqueue （队列等待）
• 2010/04/12 -- direct path read/write （直接路径读／写）
• 2010/04/10 -- db file scattered read 等待事件

直接路径读（direct path read）通常发生在Oracle直接读数据到进程PGA时，这个读取不需要经过SGA。直接路径读等待事件的3个参数分别是file number（指绝对文件号）、first dba、block cnt数量。在Oracle 10g/11g中，这个等待事件被归于User I/O一类。

db file sequential read、db file scattered read、direct path read是常见的集中数据读方式，下图简要描述了这3种方式的读取示意。

这类读取通常在以下情况被使用：
·磁盘排序IO操作；
·并行查询从属进程；
·预读操作。

最为常见的是第一种情况。在DSS系统中，存在大量的direct path read是很正常的，但是在OLTP系统中，通常显著的直接路径读（direct path read）都意味着系统应用存在问题，从而导致大量的磁盘排序读取操作。

直接路径写（direct paht write）通常发生在Oracle直接从PGA写数据到数据文件或临时文件，这个写操作可以绕过SGA。直接路径写等待事件的3个参数分别是：file number（指绝对文件号）、first dba和block cnt数量，在Oracle 10g/11g中，这个等待事件同direct path read一样被归于User I/O一类。

这类写入操作通常在以下情况被使用：
·直接路径加载；
·并行DML操作；
·磁盘排序；
·对未缓存的“LOB”段的写入，随后会记录为direct path write(lob)等待。

最为常见的直接路径写，多数因为磁盘排序导致。对于这一写入等待，我们应该找到I/O操作最为频繁的数据文件（如果有过多的排序操作，很有可能就是临时文件），分散负载，加快其写入操作。

1. 磁盘排序诊断：
如果系统存在过多的磁盘排序，会导致临时表空间操作频繁，对于这种情况，可以考虑为不同用户分配不同的临时表空间，使用多个临时文件，写入不同磁盘或者裸设备，从而降低竞争，提高性能；对于Oracle 8i的数据库，应该考虑使用本地管理（Local）的临时表空间，而不是字典（dictionary）管理。

对于这种情况，在Oracle 9i之前，可以适当增加sort_area_size的大小；从Oracle 9i开始，可以适当增大pga_aggregate_target，以缩减磁盘排序对于磁盘的写入，从而提高系统及应用响应。但是通常应该及时检查应用，确认是否因为应用问题导致了过度排序，从而根本上解决问题。

2. 并行查询导致性能问题：
有时候在应用系统中，不正确的使用并行查询也会导致应用问题。Statspack的Top 5时间事件输出显示direct path read消耗了较高的等待时，而内存排序率很高甚至是100%（In-memory Sort %:100.00）显然这里的Direct Path Read并不是由于排序引发的，注意到另外一个等待事件（KJC: Wait for msg sends to complete）和并行有关，所以初步判断这里的direct path read可能和并行有关。

    注：在Statspack的报告中，存在一个性能指标，称为内存排序率（In-memory Sort Ratio），用于衡量系统的排序操作，这个指标就是由两个统计信息sorts (disk)和sorts (memory)得出：
    In-memory Sort Ratio = sorts (memory) / [sorts (disk) + sorts (memory)]

进一步检查Statspack报告中的SQL部分，发现大量并行查询改写出来的SQL，这些SQL通过内部提示（Hints）固化其执行路径。

在很多情况下，并行也许并不是最好的选择，如果表并不大，并行反而会降低其执行速度。

通过查询dba_tables字典表可以获得degree并行度的记录，并行度大于1的数据表在查询时会启用并行，但是注意事实还会有所不同，degree字段的类型及长度是VARCHAR2(10)。所以注意，当使用类似查询时，可能无法获得返回值：

sys@CCDB> select table_name from dba_tables where degree = '1' or degree = 'DEFAULT';
no rows selected

我们看一下degree以及instances的记录方式：

sys@CCDB> select degree,length(degree) from dba_tables group by degree;
DEGREE          LENGTH(DEGREE)
--------------- --------------
         1                  10
sys@CCDB> select instances,length(instances) from dba_tables group by instances;
INSTANCES       LENGTH(INSTANCES)
--------------- -----------------
         1                     10
         0                     10

degreee和instances实际上记录了10个字符，左端用空格补齐。在dba_tables的创建语句中，可以找到根本原因，以下是这两个字段的定义来源：

    lpad(decode(t.degree, 32767, 'DEFAULT', nvl(t.degree,1)),10),
    lpad(decode(t.instances, 32767, 'DEFAULT', nvl(t.instances,1)),10),

而需要注意的是，如果degree设置为DEFAULT，则默认数据库会对该表启用并行。

最后找到相关的SQL，从AUTOTRACE可以看到这些SQL的执行计划，查看涉及数据表的并行度，注意是否有被设置为DEFAULT的表。

将表的并行度修改为1后，问题得以解决：

alter table <table_name> parallel 1;

这个问题给我们的启示是：并行并不总是能够到来性能提升。

3. 磁盘排序与临时文件：
在Oracle 10g/11g中，为了区分特定的对于临时文件的直接读写操作，Oracle对direct path read/write进行了分离，将这类操作分列出来：

sys@CCDB> select event#,name,wait_class
  2  from v$event_name
  3  where name like 'direct%';
    EVENT# NAME                      WAIT_CLASS
---------- ------------------------- ---------------
       177 direct path read          User I/O
       178 direct path read temp     User I/O
       179 direct path write         User I/O
       180 direct path write temp    User I/O

可以看到，现在的direct path read/write temp就是单指对于临时文件的直接读写操作。结合Oracle 10g的一些特性，来进一步研究一下直接路径读／写与临时文件。
首先在一个session中执行一个能够引发磁盘排序的查询：

tq@CCDB> select sid from v$mystat where rownum <2;
       SID
----------
      1066
tq@CCDB> select a.table_name,b.object_name,b.object_type
  2  from t1 a,t2 b
  3  where a.table_name = b.object_name
  4  order by b.object_name,b.object_type;

在另外sessoin查询相应等待事件：

tq@CCDB> select event,p1text,p1,p2text,p2,p3text,p3
  2  from v$session_wait_history
  3  where sid = 1066;
EVENT                    P1TEXT             P1 P2TEXT            P2 P3TEXT            P3
------------------------ ------------- ------- ------------ ------- ------------ -------
direct path read temp    file number       201 first dba     313512 block cnt         31
direct path read temp    file number       201 first dba     313481 block cnt         31
direct path read temp    file number       201 first dba     386887 block cnt         31
direct path read temp    file number       201 first dba     317736 block cnt         31
direct path read temp    file number       201 first dba     317193 block cnt         31
direct path read temp    file number       201 first dba     316646 block cnt         31
direct path read temp    file number       201 first dba     316134 block cnt         31
direct path read temp    file number       201 first dba     315622 block cnt         31
direct path read temp    file number       201 first dba     315079 block cnt         31
direct path read temp    file number       201 first dba     314567 block cnt         31
10 rows selected.

从以上输出可以看到最近10次等待，direct path read temp就是这个查询引起的磁盘排序。注意这里的file number为201。而实际上，通过v$tempfile来查询，临时文件的文件号仅为1：

tq@CCDB> select file#,name from v$tempfile;
     FILE# NAME
---------- -----------------------------------------
         1 /oracle/oradata/ccdb/ccdb/temp01.dbf

如果通过10046事件跟踪，也可以获得类似的结果：

WAIT #3: nam='direct path write temp' ela= 1 file number=201 first dba=437862 block cnt=31 obj#=112141 tim=1270780
330976998
WAIT #3: nam='direct path write temp' ela= 1 file number=201 first dba=437416 block cnt=31 obj#=112141 tim=1270780
330977070
WAIT #3: nam='direct path read temp' ela= 7 file number=201 first dba=438471 block cnt=31 obj#=112141 tim=12707803
30982214
WAIT #3: nam='direct path read temp' ela= 4 file number=201 first dba=438502 block cnt=31 obj#=112141 tim=12707803
30983765
WAIT #3: nam='direct path read temp' ela= 8 file number=201 first dba=387015 block cnt=31 obj#=112141 tim=12707803
30993872

在Oracle文档中，file#被定义为绝对文件号（The Absolute File Number）。这里的原因何在呢？研究这个问题要先研究一下v$tempseg_usage这个视图，可以从这个视图出发动手研究一下这个对象究竟来自何方。

查询dba_objects视图，发现v$tempseg_usage原来是一个同义词。

sys@CCDB> select object_type from dba_objects where object_name = 'V$TEMPSEG_USAGE';
OBJECT_TYPE
-------------------
SYNONYM

再追本溯源原来v$tempseg_usage是v_$sort_usage的同义词，也就是和v$sort_usage同源。从Oracle 9i开始，Oracle将v$sort_usage视图从文档中移除了，因为这个名称有所歧义，容易使人误解仅记录排序内容，所以v$tempseg_usage视图被引入，用于记录临时段的使用情况：

sys@CCDB> select * from dba_synonyms where synonym_name = 'V$TEMPSEG_USAGE';
OWNER      SYNONYM_NAME         TABLE_OWNER     TABLE_NAME      DB_LINK
---------- -------------------- --------------- --------------- ----------
PUBLIC     V$TEMPSEG_USAGE      SYS             V_$SORT_USAGE

如果再进一步，可以看到这个视图的构建语句：

sys@CCDB> select view_definition from v$fixed_view_definition
  2  where view_name = 'GV$SORT_USAGE';                 
VIEW_DEFINITION
--------------------------------------------------------------------------------
select x$ktsso.inst_id, username, username, ktssoses, ktssosno, prev_sql_addr, p
rev_hash_value, prev_sql_id, ktssotsn, decode(ktssocnt, 0, 'PERMANENT', 1, 'TEMP
ORARY'), decode(ktssosegt, 1, 'SORT', 2, 'HASH', 3, 'DATA', 4, 'INDEX', 5, 'LOB_
DATA', 6, 'LOB_INDEX' , 'UNDEFINED'), ktssofno, ktssobno, ktssoexts, ktssoblks,
ktssorfno from x$ktsso, v$session where ktssoses = v$session.saddr and ktssosno
= v$session.serial#

格式化一下，v$sort_usage的创建语句如下：

SELECT   x$ktsso.inst_id,username,username,ktssoses,ktssosno,
         prev_sql_addr,prev_hash_value,prev_sql_id,ktssotsn,
         DECODE (ktssocnt,
                 0,'PERMANENT',
                 1,'TEMPORARY'),
         DECODE (ktssosegt,
                 1, 'SORT',
                 2, 'HASH',
                 3, 'DATA',
                 4, 'INDEX',
                 5, 'LOB_DATA',
                 6, 'LOB_INDEX',
                 'UNDEFINED'),
         ktssofno,ktssobno,
         ktssoexts,ktssoblks,ktssorfno
  FROM   x$ktsso, v$session
WHERE   ktssoses = v$session.saddr AND ktssosno = v$session.serial#;

注意到在Oracle文档中对v$sort_usage字段SEGFILE#的定义为：

SEGFILE#    NUMBER        File number of initial extent

在视图中，这个字段来自x$ktsso.ktssofno，也就是说这个字段实际上代表的是绝对文件号。那么这个绝对文件号如何与临时文件关联呢？能否与v$tempfile中的file#字段关联呢？

再来看一下v$tempfile的来源，v$tempfile由如下语句创建：

sys@CCDB> select view_definition from v$fixed_view_definition
  2  where view_name = 'GV$TEMPFILE';
VIEW_DEFINITION
--------------------------------------------------------------------------------
select tf.inst_id, tf.tfnum, to_number(tf.tfcrc_scn), to_date(tf.tfcrc_tim,'MM/D
D/RR HH24:MI:SS','NLS_CALENDAR=Gregorian'), tf.tftsn, tf.tfrfn, decode(bitand(tf
.tfsta, 2),0,'OFFLINE',2,'ONLINE','UNKNOWN'), decode(bitand(tf.tfsta, 12), 0,'DI
SABLED',4, 'READ ONLY', 12, 'READ WRITE',
                           'UNKNOWN'), fh.fhtmpfsz*tf.tfbsz, fh.fhtmpfsz,  tf.tf
csz*tf.tfbsz,tf.tfbsz, fn.fnnam  from x$kcctf tf, x$kccfn fn, x$kcvfhtmp fh  whe
re fn.fnfno=tf.tfnum and fn.fnfno=fh.htmpxfil and tf.tffnh=fn.fnnum  and tf.tfdu
p!=0 and bitand(tf.tfsta, 32) <> 32  and fn.fntyp=7 and fn.fnnam is not null

格式化v$tempfile如下：

SELECT   tf.inst_id,tf.tfnum,TO_NUMBER (tf.tfcrc_scn),
         TO_DATE (tf.tfcrc_tim,'MM/DD/RR HH24:MI:SS','NLS_CALENDAR=Gregorian'),
         tf.tftsn,tf.tfrfn,
         DECODE (BITAND (tf.tfsta, 2), 0, 'OFFLINE', 2, 'ONLINE', 'UNKNOWN'),
         DECODE (BITAND (tf.tfsta, 12),
                 0, 'DISABLED',
                 4, 'READ ONLY',
                 12, 'READ WRITE',
                 'UNKNOWN'),
         fh.fhtmpfsz * tf.tfbsz,fh.fhtmpfsz,tf.tfcsz * tf.tfbsz,tf.tfbsz,fn.fnnam
  FROM   x$kcctf tf, x$kccfn fn, x$kcvfhtmp fh
WHERE       fn.fnfno = tf.tfnum
         AND fn.fnfno = fh.htmpxfil
         AND tf.tffnh = fn.fnnum
         AND tf.tfdup != 0
         AND BITAND (tf.tfsta, 32) <> 32
         AND fn.fntyp = 7
         AND fn.fnnam IS NOT NULL;

考察x$kcctf底层表，注意到TFAFN（Temp File Absolute File Number）在这里存在：

sys@CCDB> desc x$kcctf
Name             Null?    Type
---------------- -------- ----------------
ADDR                      RAW(8)
INDX                      NUMBER
INST_ID                   NUMBER
TFNUM                     NUMBER
TFAFN                     NUMBER
TFCSZ                     NUMBER
TFBSZ                     NUMBER
TFSTA                     NUMBER
TFCRC_SCN                 VARCHAR2(16)
TFCRC_TIM                 VARCHAR2(20)
TFFNH                     NUMBER
TFFNT                     NUMBER
TFDUP                     NUMBER
TFTSN                     NUMBER
TFTSI                     NUMBER
TFRFN                     NUMBER
TFPFT                     NUMBER
TFMSZ                     NUMBER
TFNSZ                     NUMBER

而这个字段在构建v$tempfile时并未出现，所以不能通过v$sort_usage和v$tempfile直接关联绝对文件号。可以简单构建一个排序段使用，然后来继续研究一下：

sys@CCDB> select username,segtype,segfile#,segblk#,extents,segrfno# from v$sort_usage;
USERNAME     SEGTYPE     SEGFILE#    SEGBLK#    EXTENTS   SEGRFNO#
------------ --------- ---------- ---------- ---------- ----------
SYS          LOB_DATA         201     340361          1          1

看到这里的SEGFILE#=201，而在v$tempfile是找不到这个信息的：

sys@CCDB> select file#,rfile#,ts#,status,blocks from v$tempfile;
     FILE#     RFILE#        TS# STATUS      BLOCKS
---------- ---------- ---------- ------- ----------
         1          1          3 ONLINE      443520

但是可以从x$kcctf中获得这些信息，v$tempfile.file#实际上来自x$kcctf.tfnum，是临时文件的文件号；而绝对文件号是x$kcctf.tfafn，这个字段才可以与v$sort_usage.segfile#关联：

sys@CCDB> select indx,tfnum,tfafn,tfcsz from x$kcctf;
      INDX      TFNUM      TFAFN      TFCSZ
---------- ---------- ---------- ----------
         0          1        201       2560

再进一步可以知道，实际上，为了分离临时文件号和数据文件号，Oracle对临时文件的编号以db_files为起点，所以临时文件的绝对文件号应该等于db_files+file#。

db_files参数的缺省值为200：

sys@CCDB> show parameter db_files
NAME          TYPE           VALUE
------------- -------------- -----------
db_files      integer        200
sys@CCDB> select file#,name from v$tempfile;
     FILE# NAME
---------- ---------------------------------------------
         1 /oracle/oradata/ccdb/ccdb/temp01.dbf

所以在Oracle文档中v$tempfile.file#被定义为The absolute file number是不确切的。

- The End -

相关日志

• 2010/04/10 -- db file scattered read 等待事件
• 2010/04/10 -- db file sequential read （数据文件顺序读取）
• 2010/05/13 -- Oracle 10g/11g Latch机制的变化
• 2010/05/13 -- Latch Free（闩锁释放）
• 2010/05/13 -- Enqueue （队列等待）

我们经常会见到db file scattered read等待事件，在生产环境中，这个等待事件可能更为常见。这个事件表明用户进程正在读数据到Buffer Cache中，等待直到I/O调用返回。db file scattered read发出离散读，将存储上连接的数据块离散的读入到多个不连续的内存位置。Scattered Read通常是多块读，在Full Table Scan或Fast Full Scan等访问方式下使用。

Scattered Read代表Full Scan，当执行Full Scan读取数据到Buffer Cache时，通常连续的数据在内存中的存储位置并不连续，所以这个等待被命名为Scattered Read（离散读）。每次多块读读取的数据块数量受初始化参数DB_FILE_MULTIBLOCK_READ_COUNT限制。下图简要说明了Scattered Read的数据读取方式。

从v$event_name视图可以看到，该等待有3个参数，分别代表文件号、起始数据块号、数据块的数量：

sys@CCDB> select event#,name,parameter1,parameter2,parameter3
  2  from v$event_name
  3  where name = 'db file scattered read';
    EVENT# NAME                           PARAMETER1   PARAMETER2   PARAMETER3
---------- ------------------------------ ------------ ------------ ------------
       132 db file scattered read         file#        block#       blocks

数据文件号、起始数据号加上数据块的数量，通过这些信息可以知道Oracle Session正在等待的对象文件等信息。该等待可能和全表扫描（Full Table Scan）或者快速全索引扫描（Index Fast Full Scan）的连续读取相关，根据经验，通常大量的db file scattered read等待可能意味着应用问题或者索引缺失。

在实际环境的诊断过程中，可以通过v$session_wait视图发现session的等待，再结合其他视图找到存在问题的SQL等根本原因，从而从根本上解决问题。

当这个等待事件比较显著时，用户也可以结合v$session_longops动态性能视图来进行诊断，该视图中记录了长时间（运行时间超过6秒的）运行的事务，可能很多是全表扫描操作（不管怎样，这部分信息都是值得我们注意的）。

从Oracle 9i开始，Oracle新增加了一个视图v$sql_plan用于记录当前系统Library Cache中SQL语句的执行计划，可以通过这个视图找到存在问题的SQL语句。

可以过程v$sql_plan和v$sqltext联合，获得这些查询的SQL语句，查找全表扫描的SQL语句可以参考如下语句：

select sql_text
from v$sqltext t,v$sql_plan p
where t.hash_value = p.hash_value
  and p.operation = 'TABLE ACCESS'
  and p.options = 'FULL'
order by p.hash_value,t.piece；

查找Fast Full Index扫描的SQL语句可以参考如下语句：

select sql_text
from v$sqltext t, v$sql_plan p
where t.hash_value = p.hash_value
  and p.operation = 'INDEX'
  and p.options = 'FULL SCAN'
order by p.hash_value, t.piece；

这些信息对于发现数据库问题，优化数据库性能具有极强的指导意义。

在Oracle 10g中，Oracle对等待事件进行了分类，db file scattered read事件被归入User I/O一类：

sys@CCDB> select name,parameter1 p1,parameter2 p2,parameter3 p3,
  2  wait_class_id,wait_class#,wait_class                 
  3  from v$event_name                                    
  4  where name = 'db file scattered read';
NAME                      P1         P2         P3         WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS
------------------------- ---------- ---------- ---------- ------------- ----------- ------------
db file scattered read    file#      block#     blocks        1740759767           8 User I/O

完成对等待事件的分类之后，Oracle 10g的ADDM可以很容易地通过故障分析定位到问题所在，帮助用户快速发现数据库的瓶颈及瓶颈的根源，这就是Oracle的ADDM专家系统的设计思想。

通过下图可以直观清晰地看到这个等待模型和ADDM结合实现的Oracle专家诊断系统。

- The End -

相关日志

• 2010/04/12 -- direct path read/write （直接路径读／写）
• 2010/04/10 -- db file sequential read （数据文件顺序读取）
• 2010/05/13 -- Oracle 10g/11g Latch机制的变化
• 2010/05/13 -- Latch Free（闩锁释放）
• 2010/05/13 -- Enqueue （队列等待）

db file sequential read是个非常常见的I/O相关的等待事件，通常显示与单个数据块相关的读取操作，在大多数的情况下，读取一个索引块或者通过索引读取一个数据块时，都会记录这个等待。

这个等待事件有3个参数P1，P2，P3，其中P1代表Oracle要读取的文件的绝对文件号，P2代表Oracle从这个文件中开始读取的起始数据块号，P3代表读取的BLOCK数量，通常这个值为1，表明是道单个BLOCK被读取。

sys@CCDB> select name,parameter1,parameter2,parameter3
  2  from v$event_name
  3  where name = 'db file sequential read';   
NAME                           PARAMETER1      PARAMETER2      PARAMETER3
------------------------------ --------------- --------------- ---------------
db file sequential read        file#           block#          blocks

在Oracle 10g/11g中，这个等待事件被归入User I/0一类：

sys@CCDB> select name,wait_class
  2  from v$event_name
  3  where name = 'db file sequential read';
NAME                           WAIT_CLASS       
------------------------------ ------------------
db file sequential read        User I/O

下图简要说明了单块读取的操作方式：

如果这个等待事件比较显著，可能表示在多表连接中，表的连接顺序存在问题，没有正确地使用驱动表；或者可能索引的使用存在问题，并非索引总是最好的选择。在大多数情况下，通过索引可以更为快速地获取记录，所以对于编码规范、调整良好的数据库，这个等待事件很大通常是正常的。有时候这个等待过高和存储分布不连续、连续数据块中部分被缓存有关，特别对于DML频繁的数据表，数据以及存储空间的不连续可能导致过量的单块读，定期的数据整理和空间回收有时候是必须的。

需要注意在很多情况下，使用索引并不是最佳的选择，比如读取较大表中大量的数据，全表扫描可能会明显快于索引扫描，所以在开发中就应该注意，对于这样的查询应该进行避免使用索引扫描。

从Oracle 9iR2开始，Oracle引入了段级统计信息收集的新特性，可以通过查询v$segment_statistics视图，找出物理读显著的索引段或者是表段，研究其数据结构，看能否通过重建或者重新划分分区、存储参数等手段降低I/O访问。

Oracle 9iR2中，收集的统计信息共有11类：

SQL> select * from v$segstat_name;
STATISTIC# NAME                                     SAMPLED
---------- ---------------------------------------- ---------
         0 logical reads                            YES
         1 buffer busy waits                        NO
         2 db block changes                         YES
         3 physical reads                           NO
         4 physical writes                          NO
         5 physical reads direct                    NO
         6 physical writes direct                   NO
         8 global cache cr blocks served            NO
         9 global cache current blocks served       NO
        10 ITL waits                                NO
        11 row lock waits                           NO
11 rows selected.

在Oracle 10gR2/11gR1中，这类统计信息增加为15个：

sys@CCDB> select * from v$segstat_name;
STATISTIC# NAME                                SAM
---------- ----------------------------------- ---
         0 logical reads                       YES
         1 buffer busy waits                   NO
         2 gc buffer busy                      NO
         3 db block changes                    YES
         4 physical reads                      NO
         5 physical writes                     NO
         6 physical reads direct               NO
         7 physical writes direct              NO
         9 gc cr blocks received               NO
        10 gc current blocks received          NO
        11 ITL waits                           NO
        12 row lock waits                      NO
        14 space used                          NO
        15 space allocated                     NO
        17 segment scans                       NO
15 rows selected.

对于CBO模式下的数据库，应当及时收集统计信息，使SQL可以选择正确的执行计划，避免因为统计信息的陈旧而导致执行错误等。

- The End -

相关日志

• 2010/04/12 -- direct path read/write （直接路径读／写）
• 2010/04/10 -- db file scattered read 等待事件
• 2010/05/13 -- Oracle 10g/11g Latch机制的变化
• 2010/05/13 -- Latch Free（闩锁释放）
• 2010/05/13 -- Enqueue （队列等待）

前文还提到另外一个重要视图v$system_event，该视图记录的是数据库自启动以来等待事件的汇总。通过查询该视图，就可以快速获得数据库等待事件的总体概况，了解数据库运行的基本状态：

sys@CCDB> select *
  2  from (select event,time_waited
  3        from v$system_event
  4        order by time_waited desc)
  5  where rownum < 11;
EVENT                                                            TIME_WAITED
---------------------------------------------------------------- -----------
rdbms ipc message                                                 6207605140
DIAG idle wait                                                    1033906433
virtual circuit status                                             517841938
dispatcher timer                                                   517838356
Streams AQ: qmn coordinator idle wait                              517837446
Streams AQ: qmn slave idle wait                                    517833505
fbar timer                                                         517818073
smon timer                                                         517784201
pmon timer                                                         517766357
Streams AQ: waiting for time management or cleanup tasks           517763231
10 rows selected.

以上是一个测试环境中的Top 10等待事件。

在Oracle的Statspack Report中，有一部分信息为Top 5 Wait Events（在Oracle 9i中更改为Top 5 Time Events），这部分信息是来自v$system_event视图的采样。

以下是一个Statspack的诊断报告：

Database    DB Id    Instance     Inst Num  Startup Time   Release     RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
          3313878466 ccdb                1 26-Jan-10 16:32 11.1.0.6.0  NO

Host                             Name             Platform                CPUs
Cores Sockets   Memory (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
     test7            Linux 64-bit for AMD       4     2       2          2.0

Snapshot       Snap Id     Snap Time      Sessions Curs/Sess Comment
~~~~~~~~    ---------- ------------------ -------- --------- -------------------
Begin Snap:          1 27-Mar-10 15:32:01       24       1.5
  End Snap:          2 27-Mar-10 15:32:19       25       1.4
   Elapsed:           0.30 (mins)
   DB time:           0.02 (mins)                               DB CPU:
      0.02 (mins)

Cache Sizes            Begin        End
~~~~~~~~~~~       ---------- ----------
    Buffer Cache:       224M              Std Block Size:         8K
     Shared Pool:       356M                  Log Buffer:     6,209K
... ...
Top 5 Timed Events                                                    Avg %Total
~~~~~~~~~~~~~~~~~~                                                   wait   Call
Event                                            Waits    Time (s)   (ms)   Time
----------------------------------------- ------------ ----------- ------ ------
CPU time                                                         1          53.0
control file parallel write                         20           0     14   19.3
log file switch completion                           2           0     97   13.1
log file parallel write                              8           0     18    9.6
os thread startup                                    1           0     26    1.7
          -------------------------------------------------------------

这里的Top 5 Timed Events是诊断的重要依据。

- The End -

相关日志

• 2010/05/13 -- Oracle 10g/11g Latch机制的变化
• 2010/05/13 -- Latch Free（闩锁释放）
• 2010/05/13 -- Enqueue （队列等待）
• 2010/05/13 -- 日志文件相关等待
• 2010/04/12 -- direct path read/write （直接路径读／写）