Photo Booth是配合Macbook Pro内置的摄像头的一个软件，拍摄出来的图片可以直接作Mac开机的个人logo，同时跟iPhoto，iChat等软件也有紧密的连接。
最有趣的是Photo Booth提供了很多相片的特效，其中一些超级滑稽，整个一哈哈镜。

选两张Cool一点儿的特效吧，那些惨不忍睹的小丑照就留着自己欣赏了。

彩色铅笔

X射线

Mac Photo Booth

刚才通过SMB协议从Windows的机器上copy文件到Mac上来，或许是Copy的东西比较大，有9G多，或许是用的802.11g无线网络有些不稳定，总之是忽然Mac上报告了跟Windows的连接丢失，然后那个显示Copy进程的进度框就傻在那里了，同时打开的Finder界面也无法进行任何点击。

用Cmd+Option+Esc强行关闭Finder窗口倒是可以关掉，但是重新启动的Finder仍然无法点击，而且无法正常的Logout用户，甚至连重新启动和关机都无法进行，只能是长按电源钮强制关机然后重启系统了。

要说Mac的多任务系统倒是挺好，即使在刚才那种情况下，Safari啊，Word啊，还都可以正常运行，所以严格意义上来说，人家也没算死机。不过…… Finder不能用了，就象Windows里面的资源管理器不能用了一样，很多事情都没法儿作了。

是Finder本身有些脆弱还是SMB协议导致的问题？

Finder Mac

QIM的试用就快到期了，一个好的软件在能够支持的情况下是应该支持的，就像以前的金山词霸。

可惜，Paypal的页面在付款结束以后，并没有给出注册码。只好给卿锋又发了一封邮件，希望明天注册码能够发到。眼看着着10000个字就要打到了。

QIM

好久好久没有写过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