近期对本地网某系统做了一次恢复测试，将整个恢复过程简单记录一下：

Reset database重新注册新的Incarnation之后，默认恢复时，即使我们指定了tag，也不会去使用之前incarnation的备份集。备份集总是对应一个特定的incarnation，无法在一个incarnation下恢复另一个incarnation下的备份集，但我们可以使用reset database to incarnation Inc，指定了incarnation后，就可以恢复那个incarnation下的备份集了。例如我们不完全恢复后，仍想使用老的备份集再进行恢复，就需要指定incarnation了。

数据不完全恢复后，如果不是在RMAN中以RESETLOGS打开数据库的话，常会遇见这样的报错：

RMAN-06004: ORACLE error from recovery catalog database: 
RMAN-20003: target database incarnation not found in recovery catalog

在HP-UX 11.23上升级9207时，修改升级包解压出来的目录的权限时，居然报错：

$ chmod -R 755 *
chmod: can't traverse install
chmod: can't traverse response
chmod: can't traverse stage

在DROP TEMP表空间时，会话长时间不能结束，查看等待事件为：

数据库日志中发现以下错误信息：

最近在HP平台上遇到两次跟dba MLOCK权限相关的错误：

索引跳跃式扫描（INDEX SKIP SCAN），需要在CBO模式下才能起作用，当查询谓词中不带有前导列，且前导列唯一值较少时，才有可能用上该索引扫描方式。下面来看看INDEX SKIP SCAN 是如何扫描的：

昨天写了个索引与NULL值，回头查看了资料，发现理解得太单一了，没把组合索引考虑上，而且组合索引中，NULL不是不记录，应该理解为不完全记录：

常见的B-Tree单列索引中，并不会记录null值的索引条目，因而is null等条件的查询走不了索引，走的是全表扫，而Bitmap索引则不同，它会记录NULL值的索引条目：

一、前一篇文章的案例中提到,索引损坏了，重建索引时，直接rebuild报错，而rebuild online则可以，这主要是两者重建索引时的扫描方式不同，rebuild用的是“INDEX FAST FULL SCAN”，rebuild online用的是“TABLE ACCESS FULL”：

上周公司组织了一次拓展，大老远地从杭州跑到金华去，说是那风景好，汗。第一次参加拓展活动，感觉还不错。过缅甸桥、爬天梯、攀岩、哑人搭塔、沙漠掘金，都挺有意思的。印象比较深刻的还有早上起来活动的“早上操”，本想找几张图出来给大家看看的，可惜没搜到。还有练反应的“一只枪打四只鸟”，刚开始一点反应不过来，练了练，现在就玩得挺溜的了。