===========================================================
rman的问题，头疼呢！
===========================================================
最近一直在内蒙做备份项目。头疼的很，没有想到简单的rman会碰到这么多的问题。
开始是备份速度太慢。只有500
多k。实在是不知道哪里的问题，后来查metalink猜知道原来是oracle 9205
在aix jfs文件系统上的bug。我用9201启动这个数据库备份就没有问题了。50g的备份 2
个多小时就可以完成。
但是由于客户这边全三9205，所以不能用9201，后来用裸设备来备份就没有这个问题了。
作完成了备份之后，要测试备份，于是我用rman来克隆数据库。
结果碰到的问题更多了。
无法recover数据库，他从早期的日志开始去恢复。
做了几次这样的测试，还是一样。我都绝望了。
查metalink，上itpub，找问题。
昨天看到可以通过克隆创建target数据库的一个子集。结果成功了。
然后又做一遍，今天早上来，发现还是从以前的log找，开始恢复。而这个log早就删除了。
今天仔细的分析以下备份，target数据库＆auxiliary数据库的scs，终于发现了有个数据文件的scn不一样。
我想它可能在备份的时候是offline的原因。
现在备份时候的target数据库状态已经无法确定，因为已经重启了，而且我也把这个表空间online了。
然后我在auxiliary数据库把这个数据文件offline，然后开始执行
recover database using backup controlfile until cancel;
太神奇了，他从昨天前天也就是备份的那个时候开始找log，开始恢复了。
现在正在进行恢复呢。。。。。。。。
alter database open resetlogs,我想应该可以打开数据库了！
开始是备份速度太慢。只有500
多k。实在是不知道哪里的问题，后来查metalink猜知道原来是oracle 9205
在aix jfs文件系统上的bug。我用9201启动这个数据库备份就没有问题了。50g的备份 2
个多小时就可以完成。
但是由于客户这边全三9205，所以不能用9201，后来用裸设备来备份就没有这个问题了。
作完成了备份之后，要测试备份，于是我用rman来克隆数据库。
结果碰到的问题更多了。
无法recover数据库，他从早期的日志开始去恢复。
做了几次这样的测试，还是一样。我都绝望了。
查metalink，上itpub，找问题。
昨天看到可以通过克隆创建target数据库的一个子集。结果成功了。
然后又做一遍，今天早上来，发现还是从以前的log找，开始恢复。而这个log早就删除了。
今天仔细的分析以下备份，target数据库＆auxiliary数据库的scs，终于发现了有个数据文件的scn不一样。
我想它可能在备份的时候是offline的原因。
现在备份时候的target数据库状态已经无法确定，因为已经重启了，而且我也把这个表空间online了。
然后我在auxiliary数据库把这个数据文件offline，然后开始执行
recover database using backup controlfile until cancel;
太神奇了，他从昨天前天也就是备份的那个时候开始找log，开始恢复了。
现在正在进行恢复呢。。。。。。。。
alter database open resetlogs,我想应该可以打开数据库了！
