本文起源自dbsnake的《昨天我被问到的问题》。

如果这几个问题是问到我，那么我怎么回答呢？

1. dedicated模式、非RAC、无连接池、要求支持2000个连接，在这样的条件下如何设置PGA？
根据应用程序特性的不同，SQL语句优化的程度，PGA的设置会相差很远。即使是知道专属连接方式，有2000个连接，恐怕我也无法再没有测试前就知道该设置多大的PGA。有一点默认的考虑，一个应用程序如果要支持2000个连接，那么通常不会是数据仓库系统，那么是OLTP系统的话，单个会话使用的PGA理应不需要很大。按照一般的经验值，给每个连接3M-5M，那么PGA的初始设置应该在6G-10G，然后跑测试，根据statspack或者awr report，再去判断是需要增加还是减少PGA。

2. 如何解决ORA-04031问题？
ORA-04031:unable to allocate string bytes of shared memory (“string”,”string”,”string”,”string”)
通常表示Shared Pool不足，一种情况是确实设置过小，另外一种情况是共享池碎片太多，没有足够的连续空间来放置一个稍大的空间请求，前一种情况就是增大共享池，大概到2G如果还报4031错误，那么应该是后一种情况了，而后一种情况则很可能是由于绑定变量不足导致过多的SQL Cursor存在，优化应用程序吧。再有那就可能是Oracle Database的bug了，那就五花八门不一而足了。

3. Current online redo log被删掉或者损坏后如何恢复？
当前联机日志损坏或者被删除，那么通常意味着必然会有数据损失，如果有备份，那么做full database restore，然后做不完全恢复，open resetlogs启动数据库。如果没有备份，那么利用_allow_resetlogs_corruption的隐含参数强制open数据库，做全库export，然后重建新库，做import。

4. oracle里的补丁具体分为哪几种类型？
我所知道的包括：大的Patchset，比如10.2.0.4的Patchset；Oneoff patch，修补某个bug或者某些bug的小Patch；Bundle Patch，一个时间段之后，发布的对于某一产品的集合Patch，修补一堆问题；CPU，也就是安全性Patch。dbsnake列出的其它那些，都不知道了。
其实，我的意思是这个问题有意义吗？

dbsnake – cuihua是这几年里我见到的对于Oracle数据库Internal研究最富有热情的朋友，在他的blog中有大量对于Oracle数据库内部机制的研究，比如类似于上面的第三个问题，哪怕是最棘手的数据库恢复，我相信dbsnake也是可以完成的。

原文链接自：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 ~]#

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