上个星期刚和客户做完一次Oracle 10G DATAGUARD 的实施，  在方案的整理，实施过程中遇到了大大小小的问题，现在做下记录总结：

1.此次standby 库是直接通过 客户生产环境的数据库集中备份方式恢复，备份是rman备份，所以我们的思路便是：
（1）集中备份前天晚上进行日常备份，此时备份的控制文件什么的都是current control file ；
（2） 通过集中备份rman 恢复前一天晚上数据；
（3）生产primary库 生成pfile ,standby control file 拷贝到standby库；
（4）追平归档。

2.      严格按照步骤，实施文档要多次审核。
此次有两个低级错误浪费了较长时间：
（1）在创建密码文件的步骤，认为之前主机工程师应该是生产全软件目录已经恢复过去，于是无需再次创建，于是当时跳过该步骤，导致后来 日志一直无法同步，查看alert日志才知 一直报了 ORA-16191错误 。最后  从primary库     将密码文件拷贝standby库即可。
（2）看错目录，这是非常低级都不好意思说的，在写文档时将startup nomount pfile=‘xxx'的目录写错了，于是在standby   库启动数据库时一直报pfile有问题，         ORA-01078: failure in processing system parameters,一直以为是修改pfile文件时搞坏了。后来才发现目录写错了。。太粗心了，DBA大忌。                  
           
3.    standby库恢复完成之后还是要手工创建一次standby;

4.      恢复完成后在执行recover standby database until cancel 追归档时报一下错误。                                                                  

ORA-00283: recovery session canceled due to errors
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: '/oracle/oradata/xxxxx '                          

MOS上说：
The Standby Database has been activated, then flashback to be Physical Standby again. 
Cause
This is caused by Bug 6035495 ORA-19909 during MRP / RMAN-600 on resync
Fixed-Releases: 10.2.0.4, 11.1.0.0
Details:
ORA-19909 during MRP or RMAN-600 (8201) during RMAN resync can occur.
MRP encounter same error and standby has resetlogs done

实际上这一步 归档没做完全，继而导致后面standby库接收日志后一直是 没有apply，最终导致 切换时standby一直提示要 recover needed。
当时，并没有那么多时间，考虑到数据库并不大，于是 重新直接在主库生重新生成standby control file后 重新恢复，然后才成功。

5.oracle 10 g dataguard 生产使用broker的案例比较少，还是建议少用 。

6.数据库在做dataguard 切换时，切记保证无连接存在，此时最好停止业务应用。

7.listener问题，其实在创建监听的时可以将的监听与生产使用监听分别独立开来，就是重开一个监听端口供dataguard使用，客户有出现过dataguard出现bug致使 监听无法启动从而影响了生产业务的案例。

大概就这么多了。引以为戒吧！