Data guard是ORACLE 推出的一种高可用性(HIGH AVAILABLE)的数据库方案,在8i之前称之为standby database，从9i开始，正式更名为Data guard，它是在主节点与备用节点间通过日志同步来保证数据的同步，可以实现快速切换与灾难性恢复。Data guard只是在软件上对数据库进行设置，并不需要额外购买任何组件能在对主数据库影响很小的情况下，实现主备数据库的同步，而主备机的数据差异只在在线日志部分，所以被不少企业作为了数据容灾方案。

　　ORACLE 从7.3推出standby database，7.3.x-8.0.x 需要手工拷贝所有归档日志并手工同步，从ORACLE815 开始，开始支持多节点复制，并实现了自动同步，但是这种同步是数据异步模式的，可能引起数据丢失。从ORACLE9i开始，备用服务器已经换了一种新的称呼，叫数据保护(DATA GUARD)，在这种模式中，开始支持三种不同的数据保护模式，并开始采用LGWR 对数据的传送而不是以往的ARCH，而且增加了一个新的后台进程叫DMON 监控数据的同步，支持多达9个节点的同时复制。从920开始，还开始支持逻辑备用服务器。

　　本文通过笔者对公司苏州地区制造业客户Data Guard的使用发展情况来阐述oracle这一新技术在制造业数据库应用中的推广普及以及从单纯的max performance的physical data guard的数据库容灾保护到逻辑 Data Guard等新特性的增值使用。

　　说到这边我们不得不简单的描述下制造业系统数据库的使用特性，制造业生产用数据库前端应用一般以各类ERP,MES及shop floor系统为多，目前我们维护客户中以MES，shop floor为多，这类生产类的系统一般是24x7不间断运行，应用以OLTP为主且会定期月结时或实时的run大量的report,在高可用性方面会要求低downtime最好不能超过半小时，资料丢失一般最多容忍也就15分钟。

　　纵观前几年苏州地区制造业的Oracle数据库系统几乎都是单机运行的数据库，最多加上Cluster的双机热备，但是双机热备其实不能真正意思上保障到数据库系统的安全，该HA只是保障了server故障及维护时的数据库的高可用性，对oracle database来说没有任何保障。

　　这就是利用os cluster或某些第三方的软件也实现了集群功能，如ClusterWizard双机集群容错软件、AFS/2000高可用备援系统等。这些系统一般通过RS232联机或内部网络联机做心跳线，检测主机状态，一旦发现主机宕机，则接管主机的IP，并且重新启动应用程序，达到减少宕机时间的目的。

　　后来随着oracle HA技术的发展，standby技术的完善以及oracle database委外服务的盛行，专业顾问服务公司专业技术及理念的注入，让制造业在database容灾方面有了很大的改善，硬件成本的降低各家公司开始在HA 的机制上局部加入physical data guard的容灾功能，此阶段的制造业生产系统的数据库均为cluster + physical Data guard架构这样既保障了主机维护高可用性又保障了DB损毁对生产造成的影响。另standby db还可以代替主库备份以分担备份所消耗的性能。

　　Data Guard运行要求:

　　主机必需运行在归档模式下。

　　主备数据库的版本必须一样，操作系统必须一样，版本可不同,主备机可使用不同的目录结构。

　　主备机必须都要运行在32位或64位下。

　　主库避免nologing的方式，这样会导致备机无法与主机同步。

　　Physical standby database

　　物理备用机在物理上和主据库的结构完全一样。也就是说，物理备机除了control 文件和主机不一样以及在线日志是可选的以外，其他都和主数据库一样。物理备机是靠应用主机所产生的归档文件来实现主备的一致。归档日志从主数据库通过网络传到备库上，并在备机上应用传过来的归档文件，以实现两台机的同步。 物理备用机有两种模式：Managed recovery mode归档文件从主数据传到备用数据库，log apply services把这些日志应用到备用数据库中。Read only mode这种模式可供用户只读的操作数据库，归档日志仍然会从主数据库传到备用数据库，但Log apply services不可以把这些日志应用到备用数据库中。