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小时左右。这个等待已经太过显著，实际上这个系统也正因此遭遇了巨大的困难，观察到队列等待以后，这应