对于数据库的稳定性，高可用，跨平台以及海量数据库的处理，Oracle 数据库通常是大型数据库和大企业的首选。尽管如此，仍然不乏很多中小企业想要品尝一下Oracle腥味，因此在Oracle环境中也有不少中小型数据库。出于成本的考虑，通常有可能就搞个标准版了，跑在Linux上。谁叫Oracle太贵呢？对于中小企业而言，选择合理的才是最好的。对我们这些个搞DB的，贵的一定有贵的道理，我们也可以都进多几斗米。哈哈......典型的打工者的心态哟。言归正传，中小企业的成本限制了我们搞高可用，RAC和DG也就比较少了。最近就碰到这样的情形，就是能否模拟DataGuard来保护数据库。我们知道DataGuard可以实时将数据库从主库切换到备库，或者从备库再切换回主库，实现无缝对接，从而避免由于硬件故障所带来的数据损失。下文即是基于上面的情形来使用rman catalog方式从某种程度上模拟DataGuard来更大程度地保护数据。
1、模拟DataGuard可行性分析
a、能否将生产数据库整个结构以相同的结构存在于备份服务器? 可以，热备，冷备，RMAN备份，方式多样化。首次选用冷备初始化数据库。
b、抛开DG的什么逻辑物理Standy来考虑，即不考虑实现自动或手动failover。只考虑的Prod机器硬件故障，DB在备份服务器可用。可行。
c、能否将数据库损失减小到最少？DG可以定时传送archivelog，自动apply，那我们也可以定时传送archivelog，不过自动apply有难度。
d、对于定时传送的archivelog，能否最终应用的备份服务器？可以，不论是添加/减少表空间/数据文件，数据变化更是没有问题的了。
e、数据丢失的程度取决于最后剩余未及时传送的archivelog以及Prod的redo log，这个会损失，没有办法，毕竟不是DG。
2、备份恢复方案规划
下面是数据库备份的方案规划
系统环境： Linux，Oracle 10g Standard
数据库环境： 主数据库位于Prod服务器，备份数据库位于Bak服务器，数据库容量<=200GB
备份频度： 每天做一个level 0级备份，也可以根据需要每2天实现0级备份。当然，如果中型或大型，建议使用0，1，2级增量备份
备份位置：Prod服务器放置备份文件，同时将当次的备份文件ftp到Bak服务器
归档日志：定时将归档日志ftp到Bak服务器上与原数据库相同的归档位置
还原频度：每天定时使用新的备份文件在Bak服务器上进行还原
恢复频度：不作任何恢复操作，因为恢复操作为不完全恢复，且需要使用resetlogs打开数据库，会生成新的incarnation
故障处理：如果Prod服务器主库损坏，则将剩余的archivelog及redo复制到Bak(如果可能的话)，接下来在Bak服务器手动恢复数据库并open
恢复目录数据库：建议对恢复目录数据库备份，方案多样不表
3、创建恢复目录数据库及其脚本
由于Prod服务器数据库较多，因此创建恢复目录数据库。如果你的环境库较少，可以直接使用控制文件替代恢复目录。
其次创建基于恢复目录数据库的备份与恢复的全局脚本供所有数据库调度。
关于如何创建恢复目录数据库及恢复目录脚本，此处省略，请参考:
4、创建RMAN备份shell脚本
5、自动FTP archivelog脚本
6、部署备份脚本到crontab
如果你的数据库比较少，则直接将上面的备份脚本与自动FTP archivelog脚本部署到crontab。
如果你的数据库比较多，建议将上面的脚本封装到另外的一个文件，然后部署到crontab。
如下面的full_bak_by_rman.sh实际上是包含了多个db_bak_rman_catalog.sh <$ORACLE_SID> ，后面的多个full开头的使用类是的原理。
#Rman backup and restore database
0 1 * * 1-6 /u02/database/common/rman_scripts/full_bak_by_rman.sh
0 3 * * 1-6 /u02/database/common/rman_scripts/full_resotre_by_rman.sh #这个是用来还原的脚本
#Auto ftp archive log from prod to bak server
*/16 7-20 * * 1-6 /u02/database/common/rman_scripts/full_autoftp_arch.sh
相关参考
![【MySQL数据库】数据库索引事务1.索引2.事务[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)