如果不能看到下面的照片，请移步到咱们伟大祖国管辖内的网站中观看，猛击Yupoo。

新娘的单人照，裙摆最漂亮的一张。

大东海的礁石上。

还是大东海，看上去沙滩挺大，其实就那么一小块。波澜壮阔的电影如果看到拍摄现场，也就那样。

十米长拖呢，二百五摄影师拍了个近景。

出乎意料的米奇玩偶，倒是有出乎意料的喜感，色彩也是最鲜艳的。

还是穿自己的休闲装舒服。气球的颜色和大海天空配合的也还不错。

由于新娘子劳累，提前结束了拍摄，原本计划的夕照并没有如愿，这张有PS过，太阳的高度在那个位置，实际并不会有如此浓烈的黄昏色彩。

在三亚住的地方远离市区，位于田独镇，四周是乡村，但是只要走出房门站在宽宽的走廊上看出去，就是湛蓝的天空和不远处的青山，每当午后，阳光充足，暖风习习。

从楼下门口的小路走出去，大概不要10分钟，就是田独镇的大街，往山的方向去是亚龙湾，那里水天一线。

大街的左侧是田独市场，到了晚上是熙熙攘攘的夜市，夜里11点钟，从家里走出来，牵着老婆的手晃晃悠悠，随便找一处大排档，吃上些烧烤，再来一个新鲜的金椰，插着吸管，你一口我一口，再惬意的生活也不过如此吧。

驱车20分钟到达亚龙湾，游人们都买票从大门进去，我们在三亚呆久了，觉得自己是半个本地人，就熟门熟路从旁边的小道进去，一家人都省了门票，占老大便宜了。:D

海边堆沙子，玩累了，就冒充旁边酒店的客人，躺在酒店专属的遮阳伞下的长椅上，感觉自己的皮肤一点一点被晒黑，海风吹过卷起地上的细沙扑打在脚面上，房山人从此改叫三亚人了。

借去年10月份在红螺寺的合影，祝大家新的一年福禄双至。

佟老师小朋友说，护照10年还能一换，这结婚证可是一辈子的证件呢，怎么就这么皱皱巴巴的？失落啊。

Anyway，让恭喜来的更猛烈些吧。:)

现在是2010年，我经常活动的地区周围房价大概是2.5万到3万一平米，那么会不会到了3年后，会再次说，想写给2010年的自己一定要多买套房子借钱也要多买套房子呢？

是以为记，2013年再来看。:)

这一年过的很闲散，最重要的是我有找到佟老师小朋友，更重要的是在新年来临之际我们终成眷属。

佟老师小朋友自己选的自己折的喜糖包就在上面了，在这个冬日的午后看着她盘腿坐在沙发上，一颗一颗往喜糖包里放巧克力，我知道对于我这就是幸福。

2009年的最后一天了，祝所有的朋友在新的一年，万事顺利。

EXECUTE dbms_system.set_sql_trace_in_session (sid,serial,TRUE);

这样的trace相当于event 10046 level 1。

停止：EXECUTE dbms_system.set_sql_trace_in_session (sid,serial,FALSE);

EXECUTE dbms_system.set_ev (sid,serial,10046,12,'');

这样直接设置某个会话的10046 event level 12，相当于level 4+level 8，也就是binds和waits都记录下来。

停止：EXECUTE dbms_system.set_ev (sid,serial,10046,0,”);

2. DBMS_SUPPORT包

EXECUTE dbms_support.start_trace_in_session (sid,serial,binds=>true,waits=>true);

这样的trace相当于event 10046 level 12。

停止：dbms_support.stop_trace_in_session(sid,serial);

备注：dbms_support包默认不存在，需要执行下述SQL来安装。
$ORACLE_HOME/rdbms/admin/dbmssupp.sql

3. 在Oracle10g以后可以使用DBMS_MONITOR包

EXECUTE DBMS_MONITOR.SESSION_TRACE_ENABLE(sid,serial, binds=>true,waits=>true);

这样的trace相当于event 10046 level 12。

停止：EXECUTE DBMS_MONITOR.SESSION_TRACE_DISABLE(sid,serial);

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

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也是可以完成的。

实际上，昨天刚有朋友问怎么找到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@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 ~]#

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

先看一篇简单的POWA插件使用指南。

在中文版的任何文章中，都没有提到如何设定复合条件，比如对于术士来说，如果想设定“敌方目标存在献祭效果，并且自己的焚烧可用”情况下，提示使用焚烧技能。这一需求是因为焚烧雕文的出现，焚烧并不会吞蚀献祭的效果，而献祭的时长又长于焚烧的CD时间，因此在长期的战斗过程中，往往一次献祭之后可以多次焚烧，那么必须要有一个醒目的提示来让玩家及时使用焚烧。

1. 首先设置献祭的提示，设置敌方目标身上存在献祭的情况下，触发该特效。然后将此特效置为禁用（Shift+鼠标左键点击图标）。在鼠标提示上可以看到[7]的字样，这是该特效的ID，记住。

2. 再设置焚烧的提示，设置自己焚烧技能CD的时候，触发该特效。然后，就是最重要的部分，在“精确匹配名称”后面的输入框内，输入献祭特效的ID，在本例中就是7。这部分表示只有在特效7和自身条件同时满足的情况下，特效才会触发。这里可以写多个特效ID，也就是允许无限多的复合条件。

3. 如果再设置一个献祭在敌方目标身上不存在则触发的特效，就可以在战斗中实现下面的效果。

当献祭在对方目标身上不存在的时候，特效提示补献祭。

当献祭在对方目标身上存在，并且自己焚烧CD的时候，特效提示补焚烧。

不需要再紧盯着面板和技能条，享受POWA带来的战斗新感觉吧。