ORACLE-Data guard在制造业ERP生产数据库中的应用演变

【 tulaoshi.com - 编程语言 】

　　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不可以把这些日志应用到备用数据库中。

　　Logical standby database

　　除了physical data guard,9i R2又推出logical data guard, 逻辑备用机在逻辑上和主库一样，也就是说，两台服务器的表、视图等对像需要保持一致，对物理结构上则不需要保持一致。逻辑备用机是靠把主机传过来的归档日志通过logminer解析成SQL语句，并应用到备用机上来进行更新的，与物理备用机不同的是它可以在更新的同时对数据库进行查询，这个可以进行近实时(差异一个current redo)数据库查询的功能对制造业生产系统的run report应用与其他应用分开以减轻主库的负担有很大帮助。就目前来看各企业数据库的性能瓶颈均在月结或实时的report查询未与生产应用分开导致阶段性的performance较差，logical standby的这种近实时的run report的功能对性能改善有很大的帮助。

　　但是很大程度上，而logical的方式则是需要把所有的归档转换成SQL语句再在logical standby database上执行它。这会占用一定的系统资源，如CPU，memory,I/O等，另外一点就是9i的logical standby相对来说bug限制等较多，还有就是不是很稳定，所以很少有企业在生产系统中使用，但是9i R2后几个patch针对logical DG修正了不少的bug,加上生产系统相对简单的,较少特殊运用的特性，故logical的近实时查询功还是有很好的可以用性，再加上专业的规划，制度化的管理相对来说这种技术还是值得推广使用的。

　　值得高兴的是在我们的精心准备及规划下苏州地区某大型制造业终于成为第一个吃螃蟹的，在正式的生产系统中运用了logical standby,正是这种近实时查询功能弥补了应用上的不足，解决了原系统I/O严重的问题，所有的report均至logical standby 端实时查询，在功能未受影响的同时，因为不同应用在2个DB内完成所以I/O大大降低，性能得到很大的改善。加上logical standby设计合理，管理上的规范目前该系统上线以来运行稳定。此项目的成功对苏州地区制造业对此项新技术的广泛运用有很大推动作用。

　　10g Data Guard

　　无论是8i的standby还是9i的Data Guard, Physical Standby Database只可以处于两种状态:mount和read-only,在处于mount状态时,可以手动或自动恢复archived logs,但是处于read-only模式时,不能恢复archived logs. logical standby database 也必须是从已收到的archived logs中解析出SQL语句恢复,也就是说,即使无数据丢失,在standby数据库上,用户获得的数据时落后实纪生产数据库的旧的资料.是近实时的数据(差一个current redo).10g的data guard, logical standby database也支持了standby redo logs的物理结构,允许一个实时恢复的进程与MPR或者LSP进程一起工作,,直接将standby redo logs中刚刚收到的primary数据库的redo日志内容恢复到物理或逻辑standby数据库上面,使得用户在standby数据库运行报告的信息是primary database的实时信息. 另外新增的实时恢复功能也可使数据库的switchover或者failover过程的时间大大缩短,系统的高可用性能大大的提高.Flashback Database standby数据库就可以恢复到一个指定的时间点,避免因为人为的错误带来的数据丢失,加上10G的Data Guard 图形管理功能进一步完善,管理起来会更容易,EM管理,可使Switchover/failover功能,单击鼠标就可以完成.

　　最后总结下data guard的优点

　　支持所有的DDL和DML语句

　　不管是什么数据类型、表的类型，任何DDL和DML语句都可以应用在物理备用数据库上。

　　可以减轻主数据库的备份压力

　　standby的中的数据文件可以用来快速恢复主数据库的数据文件

　　逻辑standby可以减轻主数据库的工作压力

　　物理standby也可以用只读来打开，可以分担一部分非实时的查询的工作

　　逻辑standby数据是近实时更新的，而且也可以让用户进行查询操作

　　逻辑standby可以在standby中建立索引和物化视图以方便用户的查询

　　人们的观念中,容灾所谓的火灾,地震之类的灾难是乎是很遥远的.但911后,人们开始对主要的系统制定紧急的计划.自动化的data guard开始被广泛的使用起来.加上data guard功能的不断改进使得这项实用的技术能个逐渐被接受且广泛的应用起来，从制造业集中的苏州各大企业的data guard的应用演变来说这种经济实用的技术正越来越得到制造业的青睐。