现在可以从OTN上下载OTN’s “Greatest Hits” CD。

这张cd大概120M，包括了过去12个月来OTN上最热门的技术文章，示例代码，被人查的最多的Oracle文档，另外还有一些podcast音频，比如我们可以听听Tom Kyte对Oracle Database 10g Express Edition的看法，Tom长得秀气，声音居然也很秀气，甚至可以说有些羞赧呢。

当然，仍然有些跟不上的变化的地方，比如推荐的OTN Blog中在ORACLE EMPLOYEE BLOGS分类中有Stefan Roesch这位RAC专家的blog，但是其实Stefan Roesch已经不再是Oracle的雇员了，在Oracle工作了7年以后他现在跳槽到了微软。

Oracle otn

作为新员工，根据Role的不同会被自动加入一些公司内部的邮件组中，这在Oracle称为helpinglist。
比如helpperf就是关于Oracle数据库性能问题的邮件组，平时没有自己工作的时候看看这些往来的技术邮件也是挺有意思的。

helpperf今天上午就有一个关于select count(*) from a如何提高性能的讨论，a表中有44 million的数据。
有人提出的建议就很有实验意义，可惜今天没有可以用于实验的数据库环境，否则就测试一下了。

So in order to speed it up you need to read less blocks and do it in parallel … you need to find the smallest column that has a not null constraint … create a global partition index by hash …

也就是对于一个有索引的大数据量表进行select count(*)，能够提高性能的就是读最少的index block并且并行，那么我们可以在一个最小的非空列上创建一个hash类型的全局分区索引。这样index fast full scan就有可能提高速度了。

Oracle内部的高手一定很多，但是在外声名显赫的无非就是Tom那几个人，也许这个helpinglist也是原因之一吧，既然公司内部就有广泛交流的渠道，当然就少了很多动力去外面抛头露面了。

Oracle performance

还真得拳不离手,曲不离口.

今天用于clone数据库的备份出现了问题,一个冷备份,但是缺少了2个备份之前新创建的数据文件,这两个数据文件属于undo表空间.

其实,应该立刻就可以想到既然是冷备,那么undo表空间中的数据自然在open的时候是不用去读的,那么只需要把数据库open开,然后创建新的undo表空间,把初始化参数指定的默认回滚表空间改到这个undo上,再删除原来缺少了数据文件的undo表空间就可以了.

但是,当时却一心想着如何才能重新构建这两个缺少的数据文件. 幸好后来给eygle打了个电话, 他说冷备嘛, 肯定可以打开数据库的,这才觉得自己咋这么傻呢……基本概念都反应不过来了, 看来要经常弄坏点儿数据库,经常作作恢复,要不真是会关键时刻掉链子呢.

BTW: 如果要删除原来的undo表空间,需要在mount状态下先将原来表空间中的所有数据文件(包括没有备份的那些)都offline drop掉,然后打开库,再作drop tablespace的操作.

Oracle Recover

好久好久没有写过Oracle相关的文章了好像。作为一个DBA着实有些惭愧，人eygle都出书了。

上个周六晚上借着首届杰出数据库工程师评选活动之机，吃了eygle一顿，然后去了eygle新家，说是小坐一会儿，却被大雨挡在了屋子里面，结果后来开始看Mr. Bean，一帮人前仰后合，饶有兴味。准备回家的时候，当晚最大的暴雨出现了，幸好桔子开着一辆…开着一辆…开着一辆啥来着？反正4个轮子的车，先送大师和汪海回酒店，有幸见到了第一次那么清晰的一个区域瓢泼大雨，过了一座立交桥，地面就干的没事儿人一样，诡异。

好吧，我承认又多扯了一堆家常，言归正传。

周日上午酣睡中被电话吵醒，说，客户查不到数据了，一个客户化功能的重新移植将原来已经有很多数据的表drop掉然后重新创建了。

这个drop的操作发生在上周五，也就是接到电话的一天多前，一天多的新业务一定是不能丢掉的，所以不允许直接把数据库恢复到上周五。接到电话以后大略想了一下操作的步骤，后来去公司又做了一些调整，最后的恢复过程大体如下。

1。停产品数据库 （因为允许当库，所以down下来比较保险），将原有数据文件所在的文件系统umount，新做一个文件系统，挂载到原来数据文件所在的目录下。现在就有了一个没有数据文件的Oracle环境。

2。先恢复控制文件，DP的GUI界面连接不上（VNC那边有防火墙），以下均是在RMAN中执行的。
set dbid 1296121177; –dbid在下面的控制文件备份名称中就可以看到
run {
allocate channel ‘dev_0′ type ’sbt_tape’
parms ‘ENV=(some ob2 parameters)’;
restore controlfile from ‘c-1296121177-20060806-00′; –因为最新的备份是在删除了表以后，所以要指定控制文件名以恢复倒数第二次的有效备份，否则直接from autobackup就可以
}

3。再恢复数据文件
alter database mount;
run {
allocate channel ‘dev_0′ type ’sbt_tape’
parms ‘ENV=(some ob2 parameters)’;
restore database;
}

4。recover数据库到DROP表之前的时间点（因为客户化移植的具体时间系统中有记录，所以这个时间点很好确定）
run{
sql “alter session set nls_date_format=”yyyy-mm-dd hh24:mi:ss””;
set until time ‘2006-08-11 16:40:00′;
allocate channel ‘dev_0′ type ’sbt_tape’
parms ‘ENV=(some ob2 parameters)’;
recover database;
}

5。将被DROP掉的那些表中数据EXP出来，记录下当时相关的最大Sequence序列

6。停掉这个恢复的库，再把刚才产品库的文件系统重新mount回来，打开正式库，启动应用

7。将exp出来的数据重新imp进入产品库（当然其中还有牵涉到Sequnce被重置以后，表中的ID也相当于重新开始了，直接imp必然发生数据冲突的问题，但是这些都是后续修改数据的操作，不多说了）

总结：本方法说大些，就是所谓的point-in-time recovery (PITR)，通过将数据恢复到另外一个数据库来达到不完全恢复但是不丢失产品库新数据的目的。

Oracle Recover