原文链接自：Miladin Modrakovic’s Blog – Oraclue

实际上，昨天刚有朋友问怎么找到TX enqueu的锁对象以及语句。在Oracle11gR2中我们可以使用oradebug unit_test per_session_find_one_waiter语句来进行简单的blocker定位。

oradebug unit_test per_session_find_one_waiter的用法如下：

usage: 
  oradebug unit_test per_session_find_one_waiter
    find_waiters_for=<current_sess or all_local_sess>
    wait_event="<wait_event_name_to_search_for>"
    waiter_min_secs_blkd=<secs>
    min_results=<num>
    [ timeout_mins=<mins - default is 10 mins> ]

实际测试如下，还是测试简单的enq: TX – row lock contention等待事件。

在第1个session中：

SQL> create table t (n int primary key);

Table created.

SQL> insert into t values(1); 

1 row created.

SQL> commit;

Commit complete.

SQL> update t set n=2 where n=1;

1 row updated.

在第2个session中：

SQL> update t set n=3 where n=1;

在第3个session中：

SQL> update t set n=4 where n=1;

在另外一个session中用sysdba登陆，然后执行oradebug。

SQL> oradebug unit_test per_session_find_one_waiter find_waiters_for=all_local_sess wait_event="enq: TX - row lock contention" waiter_min_secs_blkd=1 min_results=1
WAITERS_FOUND_BEGIN
(inst=1, sid=16, osid=30658) is blocking (inst=1, sid=17) for at least 501 secs
(inst=1, sid=17, osid=30668) is blocking (inst=1, sid=25) for at least 486 secs
WAITERS_FOUND_END

从以上的输出中可以得知：
1. sid=16的会话锁住了sid=17的会话，已经有至少501秒
2. sid=17的会话锁住了sid=25的会话，已经有至少486秒

此时如果commit会话1，那么会话2和会话3的”enq: TX – row lock contention” 锁都会消失，但是两个会话都不会更新到任何记录，因为n=1的记录已经被会话1更新为n=2。

在目前的测试中，如果在oradebug中指定的wait_event在当前数据库中并不存在，那么oradebug命令将长时间没有反应，并最终报出ORA-00600的错误，这应该是bug，有望在今后的版本中得到修改。

SQL> oradebug unit_test per_session_find_one_waiter find_waiters_for=current_sess wait_event="enq: TX - row lock contention" waiter_min_secs_blkd=1 min_results=1

ORA-00600: internal error code, arguments: [ksdhng:waiting_sessions_not_found], [enq: TX - row lock contention], [10], [10], [], [], [], [], [], [], [], []

今天启动Oracle Enterprise Linux 5虚拟机中的Oracle11gR2数据库，但是报错。

[oracle@dbserver ~]$ sqlplus / AS sysdba
 
SQL*Plus: Release 11.2.0.1.0 Production ON Wed Dec 16 13:28:44 2009
 
Copyright (c) 1982, 2009, Oracle.  ALL rights reserved.
 
Connected TO an idle instance.
 
SQL> startup
ORA-27154: post/wait CREATE failed
ORA-27300: OS system dependent operation:semget failed WITH STATUS: 28
ORA-27301: OS failure message: No space LEFT ON device
ORA-27302: failure occurred at: sskgpsemsper

sskgpsemsper函数可以很简单的猜测是跟semaphore有关，而ORA-27301则是No space left on device，那么很容易判断应该是操作系统内核参数中semaphore设置的问题。

[root@dbserver ~]# /sbin/sysctl -a | grep sem
kernel.sem = 250        100     32      128

而实际上，安装Oracle11gR2的semaphore需求是：
semmsl：250
semmns：32000
semopm：100
semmni：128

很明显semmns和semopm都不足。

[root@dbserver ~]# /sbin/sysctl -w kernel.sem="250 32000 100 128"
kernel.sem = 250 32000 100 128
[root@dbserver ~]# /sbin/sysctl -a | grep sem
kernel.sem = 250        32000   100     128
[root@dbserver ~]# echo "kernel.sem = 250 32000 100 128"  >> /etc/sysctl.conf
[root@dbserver ~]#

重新启动数据库实例正常。

很早之前就有传闻Oracle12g（也许不是g）版本将不再支持裸设备。而这份声明在最新发布的Oracle11gR2中就已经有所体现。以下完全通过阅读文档而得，并非实践经验，各位自行取舍。

Block and Raw Devices Not Supported with OUI
With this release, OUI no longer supports installation of Oracle Clusterware files on
block or raw devices. Install Oracle Clusterware files either on Automatic Storage
Management diskgroups, or in a supported shared file system.

不再支持将文件存储在裸设备上，但是仅仅局限于使用OUI图形界面创建数据库，那么命令行方式应该还是可以的。

For new installations, OCR and voting disk files can be placed either on ASM, or on a
cluster file system or NFS system. Installing Oracle Clusterware files on raw or block
devices is no longer supported, unless an existing system is being upgraded.

Oracle Clusterwae需要的OCR和Voting disk可以存储在ASM或者集群文件系统或者NFS中，对于全新安装，裸设备不再被支持，但是如果是升级而来的话（比如从10g升级到11g），仍然支持。

Voting Disk Backup Procedure Change
In prior releases, backing up the voting disks using a dd command was a required
postinstallation task. With Oracle Clusterware release 11.2 and later, backing up and
restoring a voting disk using the dd command is not supported.
Backing up voting disks manually is no longer required, as voting disks are backed up
automatically in the OCR as part of any configuration change and voting disk data is
automatically restored to any added voting disks.

之前Voting disk因为是存储在裸设备中的，因此备份需要使用dd命令来手动执行，在11gR2中，通过dd备份Voting disk不再被支持，同时，也无需通过任何方法手动备份Voting disk了，备份将自动进行。