医院信息化建设项目数据中心基础架构解决方案.doc

《医院信息化建设项目数据中心基础架构解决方案.doc》由会员分享，可在线阅读，更多相关《医院信息化建设项目数据中心基础架构解决方案.doc（59页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、医院信息化建设项目数据中心基础架构解决方案我们本次为XX医院设计的数据中心硬件基础架构如下图所示：业务的连续性需要通过高可靠的信息系统基础架构来保障，在XX医院的整个基础架构中，我们主要通过以下技术手段来达到一个高可靠性。1是虚拟平台的集群，确保任何单服务器故障，集成在此虚拟平台上的系统都可以切换到其它服务器上；2 是高可靠的数据库系统，XX医院的数据库采用的是ORACLE数据库系统，所以我们选用ORACLERAC+DATAGUARD的模式来实现数据库的高可用；3 是通过存储的容灾功能，达到数据在不同存储之间的数据实时同步，确保数据的安全；4 构建统一的备份系统，确保数据的最后安全。1.1 虚

2、拟化平台解决方案1.1.1 VMware服务器整合随着XX医院规模的不断壮大，IT部门必须快速地提升运算能力以不同操作环境的新服务器形式而存在。因此而产生的服务器数量激增则需要大量的资金和人力去运作，管理和升级。IT部门需要： 提升系统维护的效率 快速部署新的系统来满足商业运行的需要 找到减少相关资产，人力和运作成本的方法VMWARE服务器整合为这些挑战提供了解决方案。虚拟构架提供前所未有的负载隔离，为所有系统运算和I/O设计的微型资源控制。虚拟构架完美地结合现有的管理软件并在共享存储（SAN）上改进投资回报率。通过把物理系统整合到有VMWARE虚拟构架的数据中心上去，企业体验到： 更少的硬件

3、和维护费用 空闲系统资源的整合 提升系统的运作效率 性价比高，持续的产品环境整合IT基础服务器运行IT基础应用的服务器大多数是Intel构架的服务器这一类的应用通常表现为文件和打印服务器，活动目录，网页服务器，防火墙，NAT/DHCP服务器等。虽然大多数服务器系统资源的利用率在1015，但是构架，安全和兼容性方面的问题导致必须指定不同的物理平台来运行它们。管理，安装补丁和添加安全策略将花去大量的时间。另外，服务器的衍生组件将导致设备，动力和散热方面的成本上升。因为低服务器的利用率，低CPU的合并和中等I/O的要求，IT基础服务器首选作为虚拟化和相关整合的候选者。虚拟化使得企业能实现： 达到甚至

4、超过每个CPU，4个负载的整合比率 更便宜的硬件和运作成本 在服务器管理方面的重大改进，包含添加，移动，变更，预制和重置 基础应用将变得更强壮和灾难抵御能力整合重要应用服务器根据5个不同的企业使用服务器软件来大幅降低成本的实例，VMWARE出具了一份研究报告。使用服务器TCO模型来分类和计算成本，我们分析显示VMWARE服务器软件帮助这些企业实现： 减少2853的硬件成本 减少7279的运作成本 减少2964的综合成本客户目标： 整合空闲服务器和存储资源，为新项目重新部署这些资源 提升运作效率 改进服务器的管理灵活性 通过零当机维护改善服务等级 标准化环境和改进安全 灾难状态下，减少恢复时间

5、更少冗余的情况下，确保高可用性 更有效的适应动态商业的需求 高级备份策略 在技术支持和培训方面降低成本1.1.2 VMware提高业务连续性水平 每年成百上千的全球数据中心遭遇重大的服务中断。这些商业运行将受到用户错误，病毒，硬件故障和自然灾害等问题的影响。当前商业连续性处于企业IT策略的最前沿，并且从管理层到CEO的所有人都非常重视它。医院和企业一样，在业务连续性方面的要求是一致的，来实现业务连续性的技术也是一致的。成功的商业连续性策略元素包含： 应用程序可用计划 包含监控和平台冗余的预防措施 数据保护 灾难恢复策略 有效的人员计划使用虚拟构架，IT管理员能改进商业连续性的所有方面，例如：

6、由于主备服务器之间的硬件独立性，使得灾难恢复更快而花费不多 排除计划内的硬件当机，并明显的减少计划内的软件当机 管理所有虚拟机和监控宿主机的单点控制技术 为了实现捕捉和恢复，完全的把主机压缩到文件里去 简化和可重复的自动程序基于虚拟机的集群冗余简化为了实现高可用性，我们使用中间软件例如微软和Veritas的集群软件，把两台服务器绑定在一个热备环境。即使运行在服务器上的应用程序有集群感知能力，万一主服务器遭遇硬件或软件错误，这样的安排仍然会导致非应用程序当机。冗余能消除单点失败。随着IT对医院运作而言变得更加重要，高水平的服务普遍成为医院的需求，越来越多的应用则被要求高度可用。然而，为了实现如上

7、所述的高可用性集群，就像很多服务器运行应用一样，都需要预备和管理两次。有了虚拟化，IT管理员能在运行重要应用的实体机和同等配置的虚拟机上创建集群。在待机状态下，虚拟机并不消耗计算机资源，并且能以非常高的比例整合到一个或几个实体平台上去。结果，用户无须在硬件数量或管理和安装补丁上投入双倍的人力和物力，从而实现高可用性。冗余的方式将由2N变为N+1。实体到虚拟的集群和实体到实体的集群一样都支持同样的集群软件。同时，节省的成本能为更多的负载实现高可用性并签署更多的高水平服务协议。无须原硬件的数据恢复大多数医院IT部门使用常用的备份软件，例如Tivoli Storage Manager, Legato

8、 Networker, 或者Veritas NetBackup来创建数据和应用程序备份。既然备份策略能抵御用户错误和某些情况下的软硬件故障，比较长的恢复时间和多恢复点是能被接受的。然而，为了获得备份所带来的好处，医院必须确保数据确实能被恢复。为了测试数据恢复，IT管理员需要为每个已备份的主机提供一台测试的失败转移服务器，安装操作系统，安装备份代理，尝试在测试失败转移服务器上调整Windows注册表和其他系统配置。如果系统调整成功，备份服务器和备份代理才能被用来测试数据恢复。预制新的服务器和调整Windows注册表是一个漫长的手工过程并且有时并不可能。这样，在不同的失败转移服务器实现数据恢复是存

9、在疑问的。这些问题将被虚拟失败转移硬件给解决了。此外，操作系统安装，备份代理的安装和Windows注册表的调整只需做一次。此后，一个完整的已配置的VM模板将被存储在VM模板库内。Vmware软件能确保医院： 为灾难后的测试和恢复，消除硬件资源方面的障碍 避免系统和备份代理的安装，用虚拟机模板来缩短恢复周期 用标准的虚拟化硬件，使得灾难恢复更加可靠和可重复失败转移服务器的整合和自动化对于关联在存储域网（SAN）上重要应用的部署，医院灾难恢复策略通常包含一个灾难恢复的热站，这个站点有在主备之间的完全同步的数据复制。这种策略提供很少的恢复点对象（PRO）。然而，出于恢复时间对象（RTO）的考虑，恢复

10、时间非常依赖于除了数据恢复之外的恢复实体服务器，操作系统，系统参数和应用程序的能力。为了维持较少的恢复时间对象（RTO），硬件和系统的同一配置需要被维护在失败转移站点上。这样的配置无论在初始资本投入阶段还是在项目运作，升级，维护和支持阶段费用都是很昂贵的。这种方案的两个明显缺点在于预制了太多的新服务器以及通常没有可能为数据恢复去调整Windows注册表和对不同的失败转移服务器的其他系统参数进行配置 部署在整个企业内的虚拟构架能确保企业： 避免在失败转移站点上停滞不前 在主备站点上，从服务器整合角度来减少投入成本 使恢复过程自动化，并实现存储管理软件的集成 改进恢复过程的可靠性1.1.3 虚拟平

11、台架构 XX医院应用系统较多，有LIS、PACS等系统的应用系统、病毒服务器、文件服务器、OA、各个医保的前置机等等，本次的虚拟平台架构将按照典型的SAN架构体系来搭建，后台共享EMC VNX5500存储系统。考虑到整体性能，我们基本按照以下方案来搭建。1、 创建高可用集群：使用3-4台服务器组成虚拟化集群，共享存储空间，部署20个左右的虚拟系统，确保这些系统的高可靠性。2、 在存储中划分高性能的磁盘空间用作虚拟平台的驻留空间，确保高性能。3、 重要系统的卷通过存储做数据同步，确保单存储故障不会导致整体平台的宕机，以确保整体架构的安全。4、 部署VMWARE DR系统，对整个虚拟环境进行备份，

12、备份介质可在存储上预留部分SATA磁盘空间，进行交叉备份，确保系统的安全。5、 重点业务系统在服务器本地做克隆和模板，确保业务系统的本地快速恢复。1.1.4 方案优势大大降低TCO 通过服务器整合，控制和减少物理服务器的数量，明显提高每个物理服务器及其CPU的资源利用率， 从而降低硬件成本。 降低运营和维护成本， 包括数据中心空间、机柜、网线，耗电量，冷气空调和人力成本等。提高运营效率 加快新服务器和应用的部署，大大降低服务器重建和应用加载时间。 主动地提前规划资源增长，这样对客户和应用的需求响应快速，不需要象以前那样，需要长时间的采购流程，然后进行尝试。 不需要象以前那样，硬件维护需要数天/

13、周的变更管理准备和1 - 3小时维护窗口，现在可以进行快速的硬件维护和升级。提高服务水平 帮助您建立业务和IT资源之间的关系，使IT和业务优先级对应。 将所有服务器作为大的资源统一进行管理，并按需进行资源调配。旧硬件和操作系统的投资保护 不再担心旧系统的兼容性，维护和升级等一系列问题。为将来的集中网络存储提供可能 对于由于成本或者其他原因没有接入到存储网络（SAN, iSCSi和NAS）的服务器，整合后物理服务器数量减少，可以考虑接入到存储网络, 这样充分利用网络存储的优势，将这些分散的数据集中管理备份，为这些服务器和应用的以后的容灾打下基础。同时，通过虚拟机的特有功能和网络存储的有效结合，

14、提高了这些应用的可用性，移动性和灵活性。1.2 HIS数据库高可用解决方案XX医院的数据库使用的是ORACLE数据库，所以确保HIS系统高可靠性的最佳方式是采用RAC和DATAGUARD，这一方式也是我们在诸多的医院信息系统的集成中所以采用的方式，已经被广泛认可。在本次XX医院的HIS系统建设中，我们本地会采用两台PC服务器搭建ORACLE RAC系统，以达到本地数据库系统的负载均衡和高可用，同时在其它机房部署第三个节点的DATAGUARD数据库节点，以建立起数据库的容灾节点，确保数据的安全。1.2.1 技术原理1.2.1.1 ORACLE RAC 技术原理在一个使用环境当中，所有的服务器使用

15、和治理同一个数据库，目的是为了疏散每一台服务器的工作量，硬件上至多需要两台以上的服务器，而且还需要一个共享存储装备。同时还需要两类软件，一个是集群软件，另外一个就是Oracle数据库中的RAC组件。同时所有服务器上的OS都应当是统一类OS,根据负载平衡的配置策略，当一个客户端发送请求到某一台服务的listener后，这台服务器根据咱们的负载平衡策略，会把请求发送给本机的RAC组件处置也能够会发送给另外一台服务器的RAC组件处置，处置完请求后，RAC会通过集群软件来走访咱们的共享存储装备。逻辑结构上看，每一个染指集群的节点有一个独立的instance，这些instance走访统一个数据库。节点之

16、间通过集群软件的通信层（communication layer）来进行通信。同时为了缩小IO的耗费，具备了一个全局缓存服务，因此每一个数据库的instance，都保存了一份相同的数据库cache。RAC中的个性是：每一个节点的instance都有本人的SGA每一个节点的instance都有本人的background process每一个节点的instance都有本人的redo logs每一个节点的instance都有本人的undo表空间所有节点都共享一份datafiles和controlfilesOracle还提出了一个缓存融合的技术(Cache fusion)目的有两个1.保证缓存的分歧性I

17、XPUB技术博客2.缩小共享磁盘IO的耗费IXPUB技术博客因此在RAC环境中多个节点保存了统一份的DB CACHE缓存融合（Cache fusion）工作原理：1.其中一个节点会从共享数据库中读取一个block到db cache中2.这个节点会在所有的节点进行穿插db block copy3.当任何一个节点缓存被修改的时分，就会在节点之间进行缓存修改4.为了到达存储的分歧最终修改的后果也会写到磁盘上ClusterWare组件有四种ServiceCrsd - 集群资源服务Cssd - 集群同步服务Evmd - 事件治理服务oprocd - 节点检测监控有三类ResourceVIP - 虚拟IP

18、地址(Virtual IP)OCR - Oracle Cluster Registry(集群注册文件),记载每个节点的相干信息Voting Disk - Establishes quorum (表决磁盘),仲裁机制用于仲裁多个节点向共享节点同时写的行动，这样做是为了防止发生发火抵触。RAC的组件提供过了额定的历程，用来掩护数据库LMS - Gobal Cache Service Process 全局缓存服务历程LMD - Global Enqueue Service Daemon 全局查询服务守护历程LMON - Global Enqueue Service Monitor全局查询服务监视历程

19、LCK0 - Instance Enqueue Process 实例查询历程1.2.1.2 ORACLE DATA GUARD技术原理Data Guard体系结构 一个Data Guard环境可配置一个生产数据库和最多至9个备份数据库系统，生产和备份数据库之间通过Oracle Net技术互联，并且没有任何距离上的限制(Data Guard体系结构如图2所示)。Oracle Data Guard配置包括一个松散连接的系统集合，由一个生产数据库和若干备用数据库组成，形成一个独立、易于管理的数据保护方案。现有医院的核心业务系统的数据库在物理位置上往往位于医院信息中心的机房内，如果在同一位置有其它机房

20、或利用其它楼层机房部署同步备份的数据库，通过Oracle网络服务连接到一起，就可以构成一个很好的容灾解决方案。在修改主数据库时，对主数据库更改而生成的更新数据即发送到备用数据库，这些更改在备用数据库被重新应用。当生产数据库出现故障时，备用数据库可以继续提供服务。图2提供了一个例子。图2简单的双工作区配置物理备份数据库 物理上提供了与生产数据库在数据块级的一致性镜像。物理备份数据库是通过Redo Apply技术来保障数据镜像能力。逻辑备份数据库 通过SQL Apply（即Log Miner）技术，将接收到的日志文件还原成SQL语句，并在逻辑备份数据库上执行，从而达到数据一致性的目的。物理备用数据

21、库在应用日志文件时，是基于数据块级别来进行。因此，要求备用数据库和主数据库具有相同的物理结构，而且备用数据库只能处在恢复状态和只读打开两种状态中的一种。而逻辑备用数据库在应用日志文件时，首先将其转化为SQL语句，然后再进行同步应用。因此，逻辑备用数据库一直处于打开状态，在应用日志文件的同时，可以同时读取数据（见图3）。逻辑备用数据库与主数据库只要求逻辑结构相同，因此，还可以建立自己的数据库对象，进行读写操作。这样备用数据库就可以分担一部分主数据库的负载，如生成报表、备份等，在一定程度上提高了用户的投资回报。 Oracle Data Guard中主数据库和备用数据库的角色切换有两种方式：Swit

22、ch Over和Fail Over。Switch Over使用于计划内宕机的情况，如主数据库进行硬件和操作系统的升级，Switch Over可以在不产生数据丢失的情况下，可逆地切换主数据库和备用数据库的角色。切换后，备用数据库成为主数据库，主数据库自动成为备用数据库。在需要时，还可切换回来。如果发生计划之外的故障，就需通过Fail Over进行角色切换，使备用数据库担当起主数据库的责任。这时主数据库不会自动成为备用数据库，并且需要一些手工操作来进行恢复。每笔医院日常业务以及计费对生产数据库中的数据做出修改时，Oracle数据库将在一个联机重做日志文件中记录此次更改。在Data Gurard中可

23、配置写日志的这个过程，在大的方面可分为同步方式和异步方式。所谓同步方式就是在提交对生产数据库所做的修改时，要求此次修改已在备用数据库被应用，在生产数据库的操作才能成功。异步方式是通过维护一个本地缓存，当积累到一定程度时才将日志传送到备用数据库，在提交事务时不受备用数据库的影响。可以看出同步方式可更有效地保护数据不丢失，但会对生产数据库的性能有一定影响。异步方式则对生产数据库的性能影响很小，但会存在一定数据丢失的可能。 DataGuard是Oracle数据库自带的数据同步功能，基本原理是将日志文件从原数据库传输到目标数据库，然后在目标数据库上应用（Apply）这些日志文件，从而使目标数据库与源数

24、据库保持同步。DataGuard提供了三种日志传输（Redo Transport）方式，分别是ARCH传输、LGWR同步传输和LGWR异步传输。在上述三种日志传输方式的基础上，提供了三种数据保护模式，即最大性能（Maximum Performance Mode）、最大保护（Maximum Protection Mode）和最大可用（Maximum Availability Mode），其中最大保护模式和最大可用模式要求日志传输必须用LGWR同步传输方式，最大性能模式下可用任何一种日志传输方式。 最大性能模式：这种模式是默认的数据保护模式，在不影响源数据库性能的条件下提供尽可能高的数据保护等级。

25、在该种模式下，一旦日志数据写到源数据库的联机日志文件，事务即可提交，不必等待日志写到目标数据库，如果网络带宽充足，该种模式可提供类似于最大可用模式的数据保护等级。 最大保护模式：在这种模式下，日志数据必须同时写到源数据库的联机日志文件和至少一个目标库的备用日志文件（standby redo log），事务才能提交。这种模式可确保数据零丢失，但代价是源数据库的可用性，一旦日志数据不能写到至少一个目标库的备用日志文件（standby redo log），源数据库将会被关闭。这也是目前市场上唯一的一种可确保数据零丢失的数据同步解决方案。 最大可用模式：这种模式在不牺牲源数据库可用性的条件下提供了尽可

26、能高的数据保护等级。与最大保护模式一样，日志数据需同时写到源数据库的联机日志文件和至少一个目标库的备用日志文件（standby redo log），事务才能提交，与最大保护模式不同的是，如果日志数据不能写到至少一个目标库的备用日志文件（standby redo log），源数据库不会被关闭，而是运行在最大性能模式下，待故障解决并将延迟的日志成功应用在目标库上以后，源数据库将会自动回到最大可用模式下。 根据在目标库上日志应用（Log Apply）方式的不同，DataGuard可分为Physical Standby（Redo Apply）和Logical Standby（SQL Apply）两种。

27、 Physical Standby数据库，在这种方式下，目标库通过介质恢复的方式保持与源数据库同步，这种方式支持任何类型的数据对象和数据类型，一些对数据库物理结构的操作如数据文件的添加，删除等也可支持。如果需要，Physical Standby数据库可以只读方式打开，用于报表查询、数据校验等操作，待这些操作完成后再将数据库置于日志应用模式下。 Logical Standby数据库，在这种方式下，目标库处于打开状态，通过LogMiner挖掘从源数据库传输过来的日志，构造成SQL语句，然后在目标库上执行这些SQL，使之与源数据库保持同步。由于数据库处于打开状态，因此可以在SQL Apply更新数据

28、库的同时将原来在源数据库上执行的一些查询、报表等操作放到目标库上来执行，以减轻源数据库的压力，提高其性能。DataGuard数据同步技术有以下优势：1）Oracle数据库自身内置的功能，与每个Oracle新版本的新特性（如ASM）都完全兼容，且不需要另外付费；2）配置管理较简单，不需要熟悉其他第三方的软件产品；3）Physical Standby数据库支持任何类型的数据对象和数据类型；4）Logical Standby数据库处于打开状态，可以在保持数据同步的同时执行查询等操作；5）在最大保护模式下，可确保数据的零丢失；DataGuard数据同步技术的劣势体现在以下几个方面：1）由于传输整个日志

29、文件，因此需要较高的网络传输带宽；2）Physical Standby数据库虽然可以只读方式打开，然后做些查询、报表等操作，但需要停止应用日志，这将使目标库与源数据不能保持同步，如果在此期间源数据库发生故障，将延长切换的时间；3）Logical Standby数据库不能支持某些特定的数据对象和数据类型；4）不支持一对多复制，不支持双向复制，因此无法应用于信息集成的场合；5）只能复制整个数据库，不能选择某个schema或表空间进行单独复制；6）不支持异构的系统环境，需要相同的操作系统版本和数据库版本；DataGuard技术是Oracle推荐的用于高可用灾难恢复环境的数据同步技术。1.2.2 关键

30、技术介绍一、Data Guard配置(Data Guard Configurations)Data Guard是一个集合，由一个primary数据库(生产数据库)及一个或多个standby数据库(最多9个)组成。组成Data Guard的数据库通过Oracle Net连接，并且有可能分布于不同地域。只要各库之间可以相互通信，它们的物理位置并没有什么限制，至于操作系统就更无所谓了(某些情况下)，只要支持oracle就行了。你即可以通过命令行方式管理primary数据库或standby数据库，也可以通过Data Guard broker提供的专用命令行界面(DGMGRL)，或者通过OEM图形化界面

31、管理。1.Primary 数据库前面提到，Data Guard包含一个primary数据库即被大部分应用访问的生产数据库，该库即可以是单实例数据库，也可以是RAC。2.Standby 数据库Standby数据库是primary数据库的复制(事务上一致)。在同一个Data Guard中你可以最多创建9个standby数据库。一旦创建完成，Data Guard通过应用primary数据库的redo自动维护每一个standby数据库。Standby数据库同样即可以是单实例数据库，也可以是RAC结构。关于standby数据库，通常分两类：逻辑standby和物理standby。二、Data Guard

32、服务(Data Guard Services)1）REDO传输服务(Redo Transport Services)控制redo数据的传输到一个或多个归档目的地。2）Log应用服务(Log Apply Services)应用redo数据到standby数据库，以保持与primary数据库的事务一致。redo数据即可以从standby数据库的归档文件读取，也可直接应用standby redo log文件(如果实时应用打开了的话)。3）角色转换服务(Role Transitions)Dg中只有两种角色：primary和standby。所谓角色转换就是让数据库在这两个角色中切换，切换也分两种：swi

33、tchover和failoverswitchover：转换primary数据库与standby数据库。switchover可以确保不会丢失数据。failover：当primary数据库出现故障并且不能被及时恢复时，会调用failover将一个standby数据库转换为新的primary数据库。在最大保护模式或最高可用性模式下，failover可以保证不会丢失数据。三、Data Guard保护模式(Data Guard Protection Modes) Data Guard提供了三种数据保护的模式：最大保护(Maximum protection)：这种模式能够确保绝无数据丢失。要实现这一步当然

34、是有代价的，它要求所有的事务在提交前其redo不仅被写入到本地的online redo log，还要同时提交到standby数据库的standby redo log，并确认redo数据至少在一个standby数据库可用(如果有多个的话)，然后才会在primary数据库上提交。如果出现了什么故障导致standby数据库不可用的话，primary数据库会被shutdown。最高性能(Maximum performance)：这种模式提供在不影响primary数据库性能前提下最高级别的数据保护策略。事务可以随时提交，当前primary数据库的redo数据也需要至少写入一个standby数据库，不过这

35、种写入可以是不同步的。如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护而仅对primary数据库有轻微的性能影响。最高可用性(Maximum availability)：这种模式提供在不影响primary数据库可用前提下最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求所有事务在提交前必须保障redo数据至少在一个standby数据库可用，不过与之不同的是，如果出现故障导入无法同时写入standby数据库redo log，primary数据库并不会shutdown，而是自动转为最高性能模式，等standby数据库恢复正常之后，它又会再自动转换成最高可用性模式。最大保护

36、及最高可用性需要至少一个standby数据库redo数据被同步写入。三种模式都需要指定LOG_ARCHIVE_DEST_n初始化参数。LOG_ARCHIVE_DEST_n很重要，你看着很眼熟是吧，我保证，如果你完完整整学完dataguard，你会对它更熟。四、Standby数据库类型 物理standby我们知道物理standby与primary数据库完全一模一样(默认情况下，当然也可以不一样，事无绝对嘛)，Dg通过redo应用维护物理standby数据库。通常在不应用恢复的时候，可以以read-only模式打开，如果数据库指定了快速恢复区的话，也可以被临时性的置为read-write模式。Re

37、do应用物理standby通过应用归档文件或直接从standby系统中通过oracle恢复机制应用redo文件。恢复操作属于块对块的应用(不理解？那就理解成块复制，将redo中发生了变化的块复制到standby)。如果正在应用redo，数据库不能被open。Redo应用是物理standby的核心，务必要搞清楚其概念和原理，后续将有专门章节介绍。 Read-only模式以read-only模式打开后，你可以在standby数据库执行查询，或者备份等操作(变相减轻primary数据库压力)。此时standby数据库仍然可以继续接收redo数据，不过并不会触发操作，直到数据库恢复redo应用。也就是

38、说read-only模式时不能执行redo应用，redo应用时数据库肯定处于未打开状态。如果需要的话，你可以在两种状态间转换，比如先应用redo,然后read-only，然后切换数据库状态再应用redo，呵呵，人生就是循环，数据库也是一样。Read-write模式如果以read-write模式打开，则standby数据库将暂停从primary数据库接收redo数据，并且暂时失去灾难保护的功能。当然，以read-write模式打开也并非一无是处，比如你可能需要临时调试一些数据，但是又不方便在正式库操作，那就可以临时将standby数据库置为read-write模式，操作完之后将数据库闪回到操作前

39、的状态(闪回之后，Data Guard会自动同步，不需要重建standby)。物理standby特点1、灾难恢复及高可用性物理standby提供了一个健全而且极高效的灾难恢复及高可用性的解决方案。更加易于管理的switchover/failover角色转换及最更短的计划内或计划外停机时间。2、数据保护应用物理standby数据库，Dg能够确保即使面对无法预料的灾害也能够不丢失数据。前面也提到物理standby是基于块对块的复制，因此对象、语句统统无关，primary数据库上有什么，物理standby也会有什么。3、分担primary数据库压力通过将一些备份任务、仅查询的需求转移到物理stand

40、by，可以有效节省primary数据库的cpu以及i/o资源。4、提升性能物理standby所使用的redo应用技术使用最底层的恢复机制，这种机制能够绕过sql级代码层，因此效率最高。逻辑standby逻辑standby是逻辑上与primary数据库相同，结构可以不一致。逻辑standby通过sql应用与primary数据库保持一致，也正因如此，逻辑standby可以以read-write模式打开，你可以在任何时候访问逻辑standby数据库。同样有利也有弊，逻辑standby对于某些数据类型以及一些ddl,dml会有操作上的限制。逻辑standby的特点：除了上述物理standby中提到的类

41、似灾难恢复，高可用性及数据保护等之外，还有下列一些特点：1） 有效的利用standby的硬件资源除灾难恢复外，逻辑standby数据库还可用于其它业务需求。比如通过在standby数据库创建额外的索引、物化视图等提高查询性能并满足特定业务需要。又比如创建新的schema(primary数据库并不存在)然后在这些schema中执行ddl或者dml操作等。2） 分担primary数据库压力逻辑standby数据库可以在更新表的时候仍然保持打开状态，此时这些表可同时用于只读访问。这使得逻辑standby数据库能够同时用于数据保护和报表操作，从而将主数据库从那些报表和查询任务中解脱出来，节约宝贵的 C

42、PU和I/O资源。3）平滑升级比如跨版本升级，打小补丁啦等等，应该说应用的空间很大，而带来的风险却很小。五、Data Guard操作界面(方式)做为oracle环境中一项非常重要的特性，oracle提供了多种方式搭建、操作、管理、维护Data Guard配置，比如：OEM(Oracle Enterprise Manager)Orcale EM提供了一个窗口化的管理方式，基本上你只需要点点鼠标就能完全dg的配置管理维护等操作，其实质是调用oracle为dg专门提供的一个管理器：Data Guard Broker来实施管理操作。Sqlplus命令行方式命令行方式的管理，本系列文章中主要采用的方式。

43、不要一听到命令行就被吓倒，data guard的管理命令并不多，你只需要在脑袋瓜里稍微挪出那么一小点地方用来记忆就可以了。DGMGRL(Data Guard broker命令行方式)就是Data Guard Broker，不过是命令行方式的操作。六、Data Guard的软硬件需求 1）硬件及操作系统需求同一个Data Gurid配置中的所有oracle数据库必须运行于相同的平台。比如inter架构下的32位linux系统可以与inter架构下的32位linux系统组成一组Data Guard。另外，如果服务器都运行于32位的话，64位HP-UX也可以与32位HP-UX组成一组Data Gua

44、rd。不同服务器的硬件配置可以不同，比如cpu啦，内存啦，存储设备啦，但是必须确保standby数据库服务器有足够的磁盘空间用来接收及应用redo数据。 primary数据库和standby数据库的操作系统必须一致，不过操作系统版本可以略有差异，比如(linux as4&linux as5)，primary数据库和standby数据库的目录路径也可以不同。2）软件需求Data Guard是Oracle企业版的一个特性，明白了吧，标准版是不支持地。通过Data Guard的SQL应用，可以实现滚动升级服务器数据库版本(要求升级前数据库版本不低于10.1.0.3)。同一个Data Guard配置中

45、所有数据库初始化参数：COMPATIBLE的值必须相同。Primary数据库必须运行于归档模式，并且务必确保在primary数据库上打开FORCE LOGGING，以避免用户通过nologging等方式避免写redo造成对应的操作无法传输到standby数据库。Primary和standby数据库均可应用于单实例或RAC架构下，并且同一个data guard配置可以混合使用逻辑standby和物理standby。Primary和standby数据库可以在同一台服务器，但需要注意各自的数据文件存放目录，避免重写或覆盖。七、Data Guard优点总结* 灾难恢复及高可用性* 全面的数据保护* 有

46、效利用系统资源* 在高可用及高性能之间更加灵活的平衡机制* 故障自动检查及解决方案* 集中的易用的管理模式* 自动化的角色转换1.2.3 数据库高可用实施方案在生产数据库的事务一致性时，使用生产库的物理全备份(或物理COPY)创建备库，备库会通过生产库传输过来的归档日志(或重做条目)自动维护备用数据库。将重做数据应用到备用库。一:Oracle DataGuard环境设定1.软件环境操作系统HP UNIX 11IV3数据库版本Oracle 10g release 22.primary databaeIP:192.168.18.1ORACLE_SID=db1db_unique_name=db13.

47、standby databaseIP:192.168.18.2ORACLE_SID=standbydb_unique_name=standby二,主数据库(db1)做准备1.设置主数据库为Force loggingSQL alter database force logging;2.创建密码文件cd $ORACLE_HOME/dbs/orapwdfile=orapwdb1 password=123456 force=y3.修改主库的初始化参数alter system set log_archive_config=dg_config=(db1,standby) scope=both;alter system set log_archive_dest_1=location=/u01/db1/arch scope=both;alter system set db_unique_name=db1 scope=both;4.生成数据库备份RMAN conne