Oracle Data Guard介绍管理手册

ora6000 贡献于2012-02-03

作者 ccno1  创建于2007-05-29 01:23:00   修改者ccno1  修改于2007-10-23 06:45:00字数183104

文档摘要:Oracle Data Guard 确保企业数据的高可用性、数据保护以及灾难恢复。Data Guard 提供了一套全面的服务来创建、维护、管理和监控一个或多个Standby 数据库(备用数据库)使得生产 Oracle 数据库从灾难和数据损坏中得以幸存。Data Guard 维护这些Standby 数据库(备用数据库)作为生产数据库的事务一致性拷贝。然后如果生产数据库因为计划的或计划外的中断而变得不可用。Data Guard 能切换任何备数据为生产角色从而最小化中断引起的宕机时间。Data Guard 能与传统的备份、恢复和 cluster 技术一起使用,以提供高级别的数据保护和数据可用性。
关键词:

目录 目录 1 1 Oracle Data Guard 介绍 4 1.1 Data Guard 配置 4 1.1.1 Primary Database 5 1.1.2 Standby 数据库(备用数据库) 5 1.2 Data Guard 服务 6 1.2.1 Redo Transport Services: 7 1.2.2 Log Apply Services: 7 1.2.3 Role Transitions: 角色转换 8 1.3 Data Guard Broker 9 1.3.1 使用 Oracle 企业管理器 9 1.3.2 使用 Data Guard 命令行界面 10 1.4 Data Guard 保护模式 10 1.4.1 Maximum protection(最大保护) 10 1.4.2 Maximum availability (最大可用性) 11 1.4.3 Maximum performance(最大性能) 11 1.5 Data Guard 和互补技术 11 1.6 Data Guard Benefits总结 13 2 Getting Started with Data Guard 15 2.1 Standby Database类型 15 2.1.1 Physical Standby Database 15 2.1.2 Logical Standby Database 17 2.2 管理 Data Guard 配置的用户界面 18 2.3 Data Guard 操作的先决条件 18 2.3.1 硬件和操作系统需求 18 2.3.2 Oracle 软件需求 19 2.4 Standby Database的不同结构 20 2.5 Online redo logs(联机redo log)、归档redo log和Standby redo log files 22 2.5.1 Online redo logs(联机redo log)和归档redo log 22 2.5.2 Standby redo log files 23 3 创建Primary Standby Database 24 3.1 为Standby Database创建准备Primary Database 24 3.1.1 允许强制记日志 24 3.1.2 创建口令文件 25 3.1.3 配置Standby redo log files 25 3.1.4 设置Primary Database初始化参数 27 3.1.5 打开归档 31 3.2 Step by step 创建Primary Standby Databas 32 3.2.1 创建Primary Database数据文件的备份拷贝 32 3.2.2 为Standby Database创建控制文件 32 3.2.3 为Standby Database准备初始化参数文件 33 3.2.4 从Primary system拷贝文件到Standby system 35 3.2.5 设置环境以支持Standby Database 35 3.2.6 启动Primary Standby Database 36 3.2.7 检验Primary Standby Database正确执行 37 3.3 建库完成后的后续步骤 39 4 创建Logical Standby Database 39 4.1 创建Logical Standby Database的先决条件 40 4.1.1 确定对于表的数据类型和存储属性的支持 40 4.1.2 确保在Primary Database中的表行能被唯一标识 40 4.2 创建Logical Standby Database的逐步指导 42 4.2.1 创建Primary Standby Database 43 4.2.2 在Primary Standby Database上停止Redo应用 43 4.2.3 准备Primary Database以支持Logical Standby Database 43 4.2.4 转换到Logical Standby Database 45 4.2.5 打开Logical Standby Database 47 4.2.6 检查Logical Standby Database正确执行 48 4.3 创建后的步骤 48 5 Redo transport services 48 5.1 Redo Transport Services介绍 49 5.2 发送redo data到哪里 50 5.2.1 Destination类型 50 5.2.2 使用 LOG_ARCHIVE_DEST_n 参数配置Destination 51 5.2.3 设置闪回恢复区--- Flash Recovery Areas 54 5.3 如何send redo data 56 5.3.1 使用归档进程(ARCn)来对redo data进行归档 57 5.3.2 使用日志写进程(LGWR)来归档redo data 59 5.3.3 提供安全的redo data传输 64 5.4 应该何时发送redo data 64 5.4.1 使用 VALID_FOR 属性指定基于角色的Destination 64 5.4.2 为Primary Database 和 Standby Database指定唯一名字 65 5.5 如何应对可能出现错误 67 5.5.1 重试归档操作 67 5.5.2 使用预Standby Destination 67 5.5.3 控制重试尝试的次数 68 5.6 设置数据保护模式 69 5.6.1 选择数据保护模式 69 5.6.2 Maximum Protection Mode 69 5.6.3 Maximum Availability Mode 69 5.6.4 Maximum Performance Mode 70 5.6.5 设置 Data Guard的数据保护模式 70 5.7 管理日志文件 72 5.7.1 为archived redo log files指定预备目录 73 5.7.2 Reuse online Redo log files 74 5.7.3 管理Standby redo log files 75 5.7.4 为控制文件的增长和重用而计划 76 5.7.5 在多个Standby Database之间共享日志文件Destination 77 5.8 管理归档GAP(差距) 78 5.8.1 何时发现归档中断? 79 5.8.2 如何解决中断? 79 5.8.3 使用取归档日志(FAL)来解决归档差距 79 5.9 核查 82 5.9.1 监控日志归档信息 82 5.9.2 监控Redo transport services的性能 84 6 Log apply servvices:日志应用服务 86 6.1 日志应用服务介绍 86 6.2 日志应用服务配置选项 87 6.2.1 使用实时应用来立即应用redo data 87 6.2.2 对archived redo log files的应用指定时间延迟 88 6.3 应用redo data到Primary Standby Database 89 6.3.1 开始Redo应用 89 6.3.2 停止Redo应用 90 6.3.3 在Primary Standby Database上监控Redo应用 90 6.4 应用redo data到Logical Standby Database 90 6.4.1 Starting SQL Apply 91 6.4.2 在Logical Standby Database上停止 SQL 应用 91 6.4.3 在Logical StandBy database上监控 SQL 应用 91 7 角色转换 91 7.1 角色转换介绍 92 7.1.1 为角色转换做准备(failover or switchover) 93 7.1.2 为角色转换选择目标Standby Database 94 7.1.3 Switchover 95 7.1.4 Failover 97 7.2 包含Primary Standby Database的角色转换 99 7.2.1 包含Primary Standby Database的切换 99 7.2.2 包含Primary Standby Database的failover 102 7.3 包含Logical Standby Database的角色转换 106 7.3.1 包含Logical Standby Database的切换 106 7.3.2 包含Logical Standby Database的failover 109 7.4 在角色转换后使用 Flashback 数据库 113 7.4.1 在切换后使用 Flashback 数据库 113 7.4.2 在故障转换后使用 Flashback 数据库 114 8 管理Physical Standby Database 114 8.1 启动和关闭Physical Standby Database 114 8.1.1 启动Physical Standby Database 114 8.1.2 关闭Primary Standby Database 115 8.2 打开Standby Database以用于只读或读/写访问 116 8.2.1 评估是否打开Standby Database 117 8.2.2 打开Primary Standby Database以用于只读访问 118 8.3 管理影响Standby Database的Primary Database事件 118 8.3.1 添加数据文件或创建表空间 120 8.3.2 删去表空间和删除数据文件 124 8.3.3 使用带Physical Standby Database的可传输表空间 126 8.3.4 在Primary Database中重命名数据文件 126 8.3.5 添加或删除联机redo log files 128 8.3.6 NOLOGGING 或不可恢复的操作 129 8.4 通过 OPEN RESETLOGS 语句恢复 129 8.5 监控Primary Database 和 Standby Database 130 8.5.1 警告日志 131 8.5.2 动态性能视图(固定视图) 132 8.5.3 监控恢复过程 132 1 Oracle Data Guard 介绍 Oracle Data Guard 确保企业数据的高可用性、数据保护以及灾难恢复。Data Guard 提供了一套全面的服务来创建、维护、管理和监控一个或多个Standby 数据库(备用数据库),使得生产 Oracle 数据库从灾难和数据损坏中得以幸存。Data Guard 维护这些Standby 数据库(备用数据库)作为生产数据库的事务一致性拷贝。然后,如果生产数据库因为计划的或计划外的中断而变得不可用。Data Guard 能切换任何备数据为生产角色,从而最小化中断引起的宕机时间。Data Guard 能与传统的备份、恢复和 cluster 技术一起使用,以提供高级别的数据保护和数据可用性。 使用 Data Guard,管理员能通过将资源密集的备份和报表操作转移到Standby system上,来提高生产数据库的性能。 本章包括下面描述 Oracle Data Guard 亮点的主题: u Data Guard 配置 u Data Guard 服务 u Data Guard Broker u Data Guard 保护模式 u Data Guard 和互补技术 u Data Guard Benefits 总结 1.1 Data Guard 配置 Data Guard 配置包含一个生产数据库和一个或更多Standby 数据库(备用数据库)。在 Data Guard 配置中的数据库可以通过 Oracle Net 连接并可以分布在不同地理位置。数据库所处位置是没有限制的,只要它们能互相通讯。例如,You can有一个Standby 数据库(备用数据库)与生产数据库处于同一系统上,并且有两个Standby 数据库(备用数据库)在异地的其它系统上。 你可以使用 SQL 命令行工具或 Data Guard broker 工具来管理主和Standby 数据库(备用数据库),包括命令行工具(DGMGRL)和在 Oracle 企业管理器中集成的图形化用户工具。 1.1.1 Primary Database Data Guard 配置包含一个生产数据库,也称为Primary Database,作为主角,这是大多数的应用访问的数据库。Primary Database可以是单instance Oracle 数据库或 Oracle Real Application Clusters 数据库。 1.1.2 Standby 数据库(备用数据库) Standby 数据库(备用数据库)是Primary Database的一个事务一致性拷贝。使用Primary Database的备份拷贝,可以创建最多九个Standby 数据库(备用数据库),并将其合并到一个 Data Guard 配置中。一旦创建,Data Guard 自动维护每个Standby 数据库(备用数据库),从Primary Database传送redo data然后应用Redo到Standby 数据库(备用数据库)。 类似于Primary Database,Standby 数据库(备用数据库)也可以是单instance Oracle 数据库或 Oracle Real Application Clusters 数据库。 Standby 数据库(备用数据库)可以是Primary Standby 数据库(备用数据库)或逻辑 Standby 数据库(备用数据库): l Physical Standby 数据库(备用数据库) 通过基于块对块的与Primary Database同样的磁盘数据库结构,提供Primary Database的完全一致的Primary 拷贝。数据库schema,包括索引,是完全相同的。Primary Standby 数据库(备用数据库)与Primary Database保持同步,通过Redo apply,恢复从Primary Database收到的redo data并将Redo应用到Primary Standby 数据库(备用数据库)。 除了灾难恢复,Primary Standby 数据库(备用数据库)只能在有限的范围内用于业务目的。 l 逻辑Standby 数据库(备用数据库) 包含与生产数据库同样的逻辑信息,尽管数据的Primary 组织和结构可以是不同的。 逻辑Standby 数据库(备用数据库)通过 SQL 应用与Primary Database保持同步,其将从Primary Database收到的Redo中的数据转换成 SQL 语句,然后在Standby 数据库(备用数据库)上执行 SQL 语句。 逻辑Standby 数据库(备用数据库)能用于灾难恢复需求以外的业务目的。这允许用户在任何时间访问逻辑Standby 数据库(备用数据库),进行查询和报表。同时,使用逻辑Standby 数据库(备用数据库),You can升级 Oracle 数据库软件和补丁集而几乎没有宕机时间。这样,逻辑Standby 数据库(备用数据库)能并发用于数据保护、报表和数据库升级。 配置举例: 图 1-1 显示典型的 Data Guard 配置,包含一个Primary Database,传送redo data到一个Standby 数据库(备用数据库)。Standby 数据库(备用数据库)异地于Primary Database以用于灾难恢复和备份操作。You can配置Standby 数据库(备用数据库)与Primary Database在同一位置。然而,为了灾难恢复的目的,Oracle 建议你配置Standby 数据库(备用数据库)在异地位置。 图 1-1 显示典型的 Data Guard 配置,在其中Redo被应用到Standby 数据库(备用数据库)的Standby redo log files中。 图 1-1 典型的 Data Guard 配置 1.2 Data Guard 服务 下面小节解释了 Data Guard 如何管理redo data的传送、redo data的应用、以及更改数据库角色: l Redo Transport Services: Redo transport services 控制从生产数据自动传输redo data到一个或更多归档的Destination。 l Log Apply Services: 日志应用服务 在Standby 数据库(备用数据库)上应用redo data,与Primary Database维持事务同步。redo data能从archived redo log files,或者,如果允许实时应用,当Standby redo log files写满时直接从其中应用,而不需要将redo data首先归档到Standby 数据库(备用数据库)。 l Role Transitions: 角色转换 使用切换或failover操作,从Standby 数据库(备用数据库)更改数据的角色到Primary Database,或者从Primary Database到Standby 数据库(备用数据库)。 1.2.1 Redo Transport Services: Redo Transport Services: 控制redo data从生产数据库自动传输到一个或更多归档的Destination。Redo transport services执行下述任务: l 从Primary Database传送redo data到配置中的Standby system l 管理解决archived redo log files由于网络故障中断的过程 l 强制数据库保护模式(在 1.4 节中描述) l 自动探测在Standby system上丢失或损坏的archived redo log files,并且自动从Primary Database或其它Standby 数据库(备用数据库)检索替代的archived redo log files 1.2.2 Log Apply Services: 从Primary Database传送的redo data写到Standby system上的Standby redo log files中,如果已经做配置,然后再归档到archived redo log files。日志应用服务自动应用Standby 数据库(备用数据库)上的redo data,以维持与Primary Database的一致性。其同时也允许对数据的只读访问。 Physical StandBy 与Logical Standby 数据库的主要区别是日志应用服务应用archived redo data的方式: 对于Physical Standby 数据库,Data Guard 使用Redo Apply(Redo应用)技术,使用 Oracle 数据库的标准恢复技术在Standby 数据库(备用数据库)上应用redo data,如图 1-2 所示。 图 1-2 Primary Standby 数据库(备用数据库)的自动更新 对于Logical Standby 数据库,Data Guard 使用 SQL 应用技术,首先将收到的redo data转换为 SQL 语句,然后在Logical Standby 数据库执行生成的 SQL 语句,如图 1-3 所示。 图 1-3 逻辑Standby 数据库(备用数据库)的自动更新 1.2.3 Role Transitions: 角色转换 Oracle 数据库的操作在两种角色之一:Primary or Standby。使用 Data Guard,可以使用 switchover(切换)或failover(failover)操作更改数据库的角色。 Switchover(切换)是在Primary Database与其Standby 数据库之一进行的角色反转,切换确保不丢失数据。这是对于Primary system计划维护的典型操作。在切换期间,Primary Database转换到Standby role(备用角色),Standby 数据库(备用数据库)转换到Primary role,转换发生不需要重建任何数据库。 Failover发生在Primary Database不可用时,它只有在Primary Database发生灾难故障的情况下执行,并且Failover导致Standby 数据库(备用数据库)转换到Primary role。数据库管理员能配置 Data Guard 以确保不丢失数据。 在本文档中描述的角色转换是使用 SQL 语句手工执行。你还可以使用 Oracle Data Guard broker 来简化角色转换,并使用 Oracle 企业管理器或 DGMGRL 命令行界面来自动化failover,如 1.3 节所述。 1.3 Data Guard Broker Data Guard Broker 是一个分布式的管理构架,用于自动化 Data Guard 配置的创建、维护和监控。你可以使用 Oracle Enterprise Manager 图形化用户界面(GUI)或 Data Guard命令行界面(DGMGRL)来: l Create and enable Data Guard 配置,包括设置redo transport services and log apply services(Redo transport services和日志应用服务)。 l 从configuration(配置)中的任何系统管理整个 Data Guard 配置。 l 管理和监控包含 Real Application Clusters Primary 或Standby 数据库(备用数据库)的 Data Guard 配置。 l 通过允许你使用 Oracle 企业管理器或在 DGMGRL 命令行界面中的单条命令简化切换和failover。 l 当Primary Database变得不可用时允许快速启动failover来自动转移故障。当允许快速启动failover时,由 Data Guard broker 决定是否需要failover,并自动启动failover到指定的目标Standby 数据库(备用数据库),不需要 DBA 的介入并且不丢失数据。 另外,Oracle 企业管理器自动化及简化了: l 从Primary Database的备份拷贝中创建Primary 或逻辑Standby 数据库(备用数据库) l 添加新的或现有的Standby 数据库(备用数据库)到现有的 Data Guard 配置 l 监控日志应用速度,捕获诊断信息,以及使用集中化的监控、测试和性能工具快速发现问题。 1.3.1 使用 Oracle 企业管理器 Oracle企业管理器,提供了一个基于 web 的界面,用于查看、监控和管理 Data Guard 配置中的Primary Database和Standby Database。企业管理器的易于使用的界面结合了 broker的集中管理和 Data Guard 配置的监控,增强了对于高可用性、节点保护和企业的数据保护的 Data Guard 解决方案。 从企业管理器中央控制台,所有的管理操作能在本地或异地执行。可以查看 Oracle 数据库的主页,包括Primary Database 和 Standby Database以及instance,创建或添加现有的Standby Database,启动和停止instance,监控instance运行性能,查看事件,调度作业,以及执行备份和恢复操作。 图 1-4 显示了在企业管理器中的 Data Guard 管理概要页面。 图 1-4 Oracle 企业管理器中的 Data Guard 概要页面 1.3.2 使用 Data Guard 命令行界面 Data Guard 命令行界面(DGMGRL)允许你从 DGMGRL 提示符或脚本中控制和监控Data Guard 配置。你可以使用 DGMGRL 执行大多数所需的行动来管理和监控配置中的数据库。请查看 Oracle Data Guard Broker 以获得完整的 DGMGRL 参考信息和举例。 1.4 Data Guard 保护模式 在一些情况下,业务不允许丢失数据。在另外一些情况下,数据库的可用性比丢失数据更为重要。一些应用需要最强的数据库性能并且能容忍丢失少量的数据。下面的描述概述了三种不同的数据保护模式。 1.4.1 Maximum protection(最大保护) 这种保护模式确保如果Primary Database的故障不会发生数据丢失。要提供这种级别的保护,恢复每个事务所需的redo data必须在事务提交之前同时写到local online redo log files和至少一个Standby Database上的Standby redo log files。如果故障导致了Primary Database无法写Redo stream到至少一个事务一致性Standby Database的Standby redo log files时,为了确保不发生数据丢失,Primary Database会关闭。 1.4.2 Maximum availability (最大可用性) 这种保护模式提供了可能的最高级别的数据保护,而不用与Primary Database的可用性相折衷。与最大保护模式相同,在恢复事务所需的redo写到本地Online redo logs(联机redo log)和至少一个事务一致性Standby Database上的Standby redo log files之前,事务将不会提交。与最大保护模式不同的是,如果故障导致Primary Database无法写Redo stream到异地Standby redo log files时,Primary Database不会关闭。在故障发生时,主数据库以最大性能模式运行直到故障消除,并且解决所有redo log files中的中断。当所有中断解决之后,Primary Database自动继续以最大可用性模式运行。 这种模式确保了如果Primary Database故障,但是只有当第二次故障没有阻止完整的redo data集从Primary Database发送到至少一个Standby Database时,不发生数据丢失。 1.4.3 Maximum performance(最大性能) 这种保护模式(默认)提供了可能的最高级别的数据保护,而不影响主数据库的性能。这是通过允许事务在恢复该事务所需redo data在写到本地Online redo logs(联机redo log)后立即提交而实现的。Primary Database的redo data stream也写到至少一个Standby Database,但是那个Redo流相对于创建redo data的事务是异步写的。 当所用的网络连接有足够的带宽,这种模式提供了近似于最大可用性模式的数据保护级别,并且对Primary Database性能的影响最小。 最大保护和最大可用性模式需要Standby redo log files配置在配置中的至少一个 Standby Database上。 所有三种保护模式都需要在 LOG_ARCHIVE_DEST_n 初始化参数上指定特定的日志传输属性以发送redo data到至少一个Standby Database。查看 5.6 节以获得数据保护模式的完整信息。 1.5 Data Guard 和互补技术 Oracle 数据库提供了几种独特的技术互补 Data Guard 确保业务关键系统以比使用其中任何单种技术更高级别的可用性和数据保护运行。下面的列表总结了一些 Oracle 高可用性技术: l Oracle Real Application Clusters(RAC) RAC 允许多个独立服务器通过内部连接共享访问一个 Oracle 数据库,提供了高可用性、可扩展性和发生故障时的冗余性。RAC 和 Data Guard 一起提供了系统级别、节点级别和数据级别的保护,导致了高级别的可用性和灾难恢复而不丢失数据。 e RAC 通过提供从故障的快速和自动恢复来处理系统故障,如节点故障和instance崩溃,也提供了对应用的增加的可扩展性。 e Data Guard 通过保持不共享磁盘的Primary Database 和 Standby Database的事务一致性来处理节点故障,允许从节点灾难和数据损坏中恢复。 可能有许多不同的使用 RAC 和 Data Guard 的架构,依赖于本地和异地节点的使用以及节点和逻辑与Primary Standby Database的结合的使用。查看附录 D,“Data Guard 和 Real Application Clusters”和 Oracle 数据库高可用性概述以获得 RAC 和 Data Guard 的整合。 l Flashback 数据库 Flashback 数据库特性提供了从逻辑数据损坏和用户错误中的快速恢复。通过允许闪回时间点,可能已经被错误更改或删除的前面版本的业务信息能被再次访问。这种特性: 消除了还原备份并前滚更改到错误或损坏出现的时间的需求。替代地,Flashback 数据库能回滚 Oracle 数据库到一个前面的时间点,而不用还原数据文件。 提供了延迟Redo的应用的选项,以保护用户错误或逻辑损坏。因此,Standby Database能近地与Primary Database同步,从而减少了failover和切换的时间。 避免在failover后完全重建原始Primary Database。故障的Primary Database能闪回到failover前的时间点,并转换成新的Primary Database的Standby Database。 请查看 Oracle 数据库备份和恢复高级用户指南以获得 Flashback 数据库的信息,以及 6.2.2 节以获得延迟redo data的应用的信息。 l 恢复管理器(RMAN) RMAN 是一种 Oracle 工具,简化了备份、还原和恢复数据库文件。与 Data Guard相同,RMAN 是一种 Oracle 数据库的特性,不需要额外的安装。Data Guard 能很好地与 RMAN 集成,允许: 使用恢复管理器 DUPILCATE 命令来从你的Primary Database的备份中创建Standby Database。 用Primary Standby Database取代生产数据库来进行备份,减少生产数据库的负载并允许有效地使用Standby node的系统资源。此外,备份能在Primary Standby Database在应用redo data时进行。通过自动删除用于在执行备份后输入的archived redo log files,帮助管理归档redo log文件。 1.6 Data Guard Benefits总结 Data Guard 提供了这些Benefits: l 灾难恢复,数据保护和高可用性 Data Guard 提供了一个有效的、广泛的灾难恢复及高可用性解决方案。易于管理的切换和failover能力允许角色在Primary Database 和 Standby Database之间转换,最小化了Primary Database在计划和非计划中断的宕机时间。 l 完全的数据保护 Data Guard能保证即使面对无法预料的灾难时也不出现数据丢失,Standby Database提供了对数据损坏和用户错误的保护。在Primary Database上的存储级别的Physical 损坏不会蔓延到Standby database。与这类似,导致Primary Database永久损害的逻辑损坏或用户错误能被解决。最后,redo data在应用到Standby Database时要验证。 l 系统资源的有效使用 由从Primary Database收到的redo data进行更新的Standby Database上的数据表,能用于其它任务如备份、报表、统计和查询,从而减少了Primary Database用于执行这些任务所需的工作负载,节省了宝贵的CPU 和 I/O 循环。在Logical Standby Database中,用户能在没有正在从Primary Database进行更新的schema下的表上执行正常的数据操作。Logical Standby Database能保证表正在从Primary Database更新时保持打开,并且表同时能被以只读方式进行访问。最后,在维护的表上能创建额外的索引和物化视图,以获得更好的查询性能并适合特定的业务需求。 l 灵活保护数据,平衡可用性与性能需求 Oracle Data Guard 提供了最大保护、最大可用性和最大性能模式,以帮助企业平衡数据可用性与系统性能需求。 l 自动发现和解决Primary Database和Standby database之间的差异 如果在Primary 和Standby Database之间的连接中断 (例如,由于网络问题),在Primary 数据库上生成的redo data就无法发送到那些Standby Database。一旦重新建立连接,Data Guard能自动发现丢失的archived redo log files(称之为中断),然后自动传输丢失的归档redo log到Standby Database。Standby Database与Primary Database同步,不需要 DBA 的手工介入,这个问题可以通过检查数据字典v$archived_log来确定。 l 集中和简单的管理 Data Guard broker 提供了一个图形化的用户界面和一个命令行界面来自动化管理和操作在 Data Guard 配置中的跨多个数据库的任务。Broker 也监控在单个 Data Guard配置中的所有系统。 l 与 Oracle 数据库集成 Data Guard 是 Oracle 数据库企业版中的一个特性,不需要单独地安装。 l 自动角色转换 当允许快速启动failover时,在主节点灾难的情况下,Data Guard broker 自动failover到一个同步的Standby node上,不需要 DBA 的介入。另外,role transitions(角色转换)会自动通知应用。 2 Getting Started with Data Guard Data Guard 配置包含一个Primary Database和最多九个相关的Standby Database。本章描述了 Data Guard入门知识所需要的下述需要了解的内容: u Standby Database类型 u 管理 Data Guard 配置的用户界面 u Data Guard 操作的先决条件 u Standby Database目录结构考虑 u Online redo logs(联机redo log)、归档redo log和Standby redo log files 2.1 Standby Database类型 Standby Database是一个 Oracle 生产数据库的事务一致性拷贝,起初从Primary Database的备份拷贝创建。一旦创建并配置好Standby Database后,Data Guard 通过传输Primary Database redo data到Standby system来自动维护Standby Database中的数据,在Standby database端,redo data被接受到Standby Database中。 Standby Database可以是两种类型之一:Physical Standby Database或Logical Standby Database。如果需要,任何一种类型的Standby数据库都能承担Primary Database的角色并接管生产过程。Data Guard 配置可以包括Physical Standby Database,Logical Standby Database,或两种类型的组合。 2.1.1 Physical Standby Database Physical standby database在物理结构上与Primary database完全相同,以基于块对块的原理保持与Primary database相同的磁盘数据库结构。在两边的数据库中schema(包括索引),在standby database中和Primary database中是完全相同的。 Physical standby 类型的Data guard 通过redo apply(redo应用),来维护physical standby database。当不是在performing recovery(执行恢复)的时段内,physical standby database只能以只读模式打开,根据oracle恢复机制的原理在进行redo apply这段时间内physical standby database是处于mount状态,此时对外提供的服务中止,或者如果允许 flashback 数据库则可以临时以读/写模式打开。 l Redo Apply:Redo应用 Physical Standby Database通过使用 Oracle 的恢复机制,从archived redo log files或直接从Standby system上的Standby redo log files接收redo data来维护数据。恢复操作使用数据块地址将Redo块中的更改应用到对应的数据块中,数据库在应用Redo apply时只能在mount状态下。 l Open read-only Physical Standby Database能以只读模式打开,可以执行查询。当以只读模式打开时,Standby Database能继续接收redo data,但是访问log files的redo data的应用会延迟,直到数据库继续Redo apply。 虽然Physical Standby Database不能在同一时间Redo Apple和以只读模式打开,但是可以在两者之间切换。例如,可以执行Redo Apply,然后以只读模式打开以运行报表应用,再将其改回去以执行Redo apply来接收任何未应用的archived redo log files。在必要时可以重复这个循环,在Redo Apply和read only之间切换。 Physical Standby Database可用于执行备份。此外,Primary Standby Database将继续接受redo data,即使archived redo log files或Standby redo log files没有在那个时刻被应用。 l 读/写打开 为了达到创建一个克隆数据库或读/写报表库的目的,Physical Standby Database也能为读/写访问打开。当以读/写模式打开时,Standby Database不会从Primary Database接受redo data并且无法提供灾难保护。 Physical Standby Database能临时地以读/写模式打开,以用于开发、报表、或测试目的,然后闪回到过去的点以 恢复到Primary Standby Database。当数据库闪回之后,Data Guard 自动进行Standby Database与Primary Database之间的同步,而不需要从Primary Database的备份拷贝重建Physical Standby Database。 l Physical Standby Database的Benefits n 灾难恢复和高可用性 Physical Standby Database提供了强壮的和有效的灾难恢复以及高可用性解决方案。易于管理的切换和failover能力允许在Primary和Physical Standby Database之间很容易地进行角色转换,最小化Primary数据库由于计划的或计划外的故障而导致的宕机时间。 n 数据保护 使用Physical Standby Database,Data Guard 能确保没有数据丢失,即使面对不可预见的灾难。 Physical Standby Database支持Primary Database能支持的所有数据类型和所有 DDL 和 DML 操作,其同时提供了对数据损坏和用户错误的保护。在Primary Database上的存储级别的Physical损坏不会蔓延到Standby Database。类似地,造成Primary Database永久损害的逻辑损坏或用户错误也能被解决。最后,redo data在应用到Standby Database时要验证。 n 减少Primary Database的工作负载 Oracle 恢复管理器(RMAN)可以使用Physical Standby Database进行非负载备份,从而节省了Primary Database的宝贵 CPU 和 I/O。Physical Standby Database也能以只读模式打开,用于报表和查询。 n 性能 Physical Standby Database使用的Redo Apply是使用低级别的恢复机制应用更改,绕过了所有SQL 级别代码层;因此,这是应用海量redo data最有效的机制。 2.1.2 Logical Standby Database Logical Standby Database最初创建为Primary Database的等同拷贝,但是以后能更改为不同的结构。Logical Standby Database通过执行 SQL 语句来更新。这允许用户在任何时间访问Standby Database进行查询和报表。那么Logical Standby Database能够并发地用于数据保护和报表操作。 Data Guard 通过转换日志文件中的数据到 SQL 语句,然后在Logical Standby Database上执行 SQL 语句,自动应用从archived redo log files或Standby redo log files中的信息到Logical Standby Database。因为Logical Standby Database是使用 SQL 语句更新的,其必须保持打开。虽然Logical Standby Database是以读/写模式打开的,但是用于重新生成 SQL 的目标表只能用于只读操作。当那些表被更新时,他们能同时用于其它任务如报表、统计和查询。此外,这些任务能通过在维护表上创建额外的索引和物化视图进行优化。 Logical Standby Database在数据类型、表的类型和 DDL 与 DML 操作类型上有一些限制。4.1.1节描述了不支持的数据类型和表的存储属性。 l Logical Standby Database的Benefits Logical Standby Database提供了与Physical standby database类似的灾难恢复,高可用性和数据保护Benefits。它同时还提供下述专门的Benefits: n Standby Database节点硬件资源的有效利用 Logical Standby Database能用于灾难恢复需求以外的其它业务用途。它能在 Data Guard 配置中保护的数据库方案之上主动创建额外的方案,并且用户能在任何时间对这些方案执行正常的 DDL 或 DML 操作。因为由 Data Guard 保护的逻辑备用表能存储在Primary Database以外的不同Primary 层次,所以能创建额外的索引和物化视图以提高查询性能并满足特定的业务需求。 n 减少Primary Database的工作负载 Logical Standby Database能在表被Primary Database更新的同时保持打开,并且这些表同时可用于读访问。这使得Logical Standby Database是进行查询、统计和报表活动的极好选择,从而减少了主数据库执行这些任务的负载并节省了宝贵的 CPU 和 I/O。 2.2 管理 Data Guard 配置的用户界面 可以使用下述界面来配置、实施和管理 Data Guard 配置: l Oracle 企业管理器 企业管理器提供了一个 Data Guard broker 的 GUI 界面,能自动化许多任务,包括创建、配置和监控 Data Guard 环境。查看 Oracle Data Guard Broker 和 Oracle 企业管理器联机帮助以获得 GUI 及其向导相关的信息。 l SQL*Plus 命令行 个别 SQL*Plus 语句使用 STANDBY 关键词来指定Standby Database上的操作。其它 SQL 语句不包含备-特定语法,但是它们对于在Standby Database上执行操作是有用的。请查看第 15 章以获得相关语句的列表。 l 初始化参数 个别初始化参数用于定义 Data Guard 环境。请查看第 13 章以获得相关初始化参数的列表。 l Data Guard broker 命令行界面(DGMGRL) DGMGRL 命令行界面是使用 Oracle 企业管理器的替代选项。如果你想从批处理程序或脚本使用 broker 来管理 Data Guard 配置,DGMGRL 命令行界面是很有用的。查看Oracle Data Guard Broker 以获得完整信息。 2.3 Data Guard 操作的先决条件 下面描述了使用 Data Guard 的操作需求: u 硬件和操作系统需求 u Oracle 软件需求 2.3.1 硬件和操作系统需求 下面列表描述了使用 Data Guard 的硬件和操作系统需求: Data Guard 配置中的所有成员必须运行在同一平台建立的 Oracle images上。例如,在 Intel 系统上的 32 位 Linux 上的Primary Database的 Data Guard 配置可以有配置在 Intel 系统上的 32 位 Linux 上的Standby Database。然而,在 64 位 HP-UX 系统上的主数据库也能配置在 32 位 HP-UX 系统上的Standby Database,只要两个服务器都运行 32 位的images。 Primary system和Standby system的硬件(例如,CPU 的数量、内存大小、存储配置)可以是不同的。如果Standby system比Primary system(主系统)要小,你可能必须限制在切换或failover后Standby system上的工作量。Standby system必须有足够的可用资源来接收和应用所有从Primary Database来的redo data。Logical Standby Database需要额外的资源以转换redo data为 SQL 语句并在Logical Standby Database上执行 SQL。 在主和备位置运行的操作系统必须是相同的,但是操作系统版本不需要一样。另外,Standby Database可以使用与Primary Database不同的目录结构。 2.3.2 Oracle 软件需求 下面列表描述了使用 Data Guard 的 Oracle 软件需求: Oracle Data Guard 只是作为 Oracle 数据库企业版的一个特性。在 Oracle 数据库标准版中没有这个特性。着意味着在 Data Guard 配置中必须在Primary Database和所有Standby Database上必须安装同样版本的 Oracle 数据库企业版。 使用 Data Guard SQL 应用,你将能够执行 Oracle 数据库软件的升级,从补丁集版本 n (最低地,这必须是版本 10.1.0.3)到下面的数据库 10.1.0.(n+1)补丁集版本。在升级期间,You can在升级的同时在主和Logical StandBy database上运行不同版本的Oracle 数据库,一次升级一个。要获得完整的信息,查看第 11 章,“使用 SQL 应用来升级 Oracle 数据库”和应用 Oracle 数据库 10g 补丁集版本的自述文件。 在 Data Guard 配置中所有数据库上的 COMPATIBLE 初始化参数必须设为同样的值。 如果你当前在 Oracle8i 数据库软件上运行 Oracle Data Guard,请查看 Oracle 数据库升级指南以获得升级 Oracle Data Guard 的完整信息。 Primary Database必须运行在 ARCHIVELOG 模式,请查看 Oracle 数据库管理员指南以获得更多信息。 Primary Database可以是单instance数据库或多instance的 Real Application Clusters 数据库。 Standby Database可以是单instance数据库或多instance Real Application Clusters(RAC)数据库,并且这些Standby Database可以是Primary 和逻辑类型的混合。请查看 Oracle 数据库高可用性概述以获得更多配置和使用 Oracle Data Guard 与 RAC 的信息。 每个Primary Database和Standby Database必须有自己的控制文件。 如果Standby Database与Primary Database位于同样的系统上,Standby Database的归档目录必须使用与主数据库不同的目录结构。否则,Standby Database可能覆盖Primary Database的文件。 为了解决在Primary Database上的unlogging的dirct writes无法传送到Standby Database的问题,在进行用于创建Standby Database的数据文件备份之前,在Primary Database上必须打开 FORCE LOGGING(alter datbase force logging;)。Standby Database也需要保持数据库在 FORCE LOGGING 模式。 用于管理Primary Database 和 Standby Databaseinstance的用户帐户必须有 SYSDBA 系统权限。 2.4 Standby Database的不同结构 不同Standby Database的目录结构是很重要的,因为它决定备用数据文件、archived redo log files和备用redo log files的路径名称。如果可能,Primary system和Standby system上的数据文件、日志文件和控制文件应该拥有同样的名字和路径名称,并且使用 Optimal Flexible Architecture(OFA)命名规定。在Standby Database上的归档目录在节点之间也应该是同样的,包括大小和结构。这种策略允许其它操作如备份、切换和failover执行同样的步骤,减少维护的复杂性。否则,你必须设置文件名转换参数(如表 2-1 中所示)或者重命名数据文件。不过,如果你需要使用不同目录结构的系统或将备和 Primary Database放在同一系统上,可以这么做以最小化额外的管理。 在图 2-1 中举例说明了三种基本的配置选项。这些包括: Standby Database与Primary Database处于同一系统上,并使用与Primary system(主系统)不同的目录结构,这在图 2-1 中举例为 Standby 1。如果你的Standby Database与Primary Database在相同的系统上,你必须使用不同的目录结构。否则,Standby Database会覆盖Primary Database的文件。 在不同系统上的Standby Database使用与Primary system(主系统)相同的目录结构,这在图 2-1 中举例为Standby 2,这是建议的模式。 在不同系统上的Standby Database使用与Primary system(主系统)不同的目录结构,这在图 2-1 中举例为Standby 3。 图 2-1 可以包括的Standby配置 表 2-1 Standby Database位置和目录选项 STANDBY SYSTEM 目录结构 结论 与Primary Database在同一主机 与Primary system必须区别 § 必须设置 DB_UNIQUE_NAME 初始化参数 § 手工重命名文件或在Standby Database上设置DB_FILE_NAME_CONVERT 和LOG_FILE_NAME_CONVERT 初始化参数,以自动更新 STANDBY DATABASE控制文件中的PRIMARY DATABASE数据文件与归档REDO LOG FILES和STANDBY REDO LOG FILES的路径名称 § STANDBY DATABASE不对PRIMARY DATABASE 和 STANDBY DATABASE所在系统的灾难进行保护,但是它提供了切换能力。通过将STANDBY DATABASE放在不同的PRIMARY 设备上,能保护主数据库上的数据不受PRIMARY SYSTEM(主系统)的灾难影响。 在不同的主机上 与Primary system相同 § 不需要重命名Standby Database控制文件中的Primary Database数据文件、archived redo log files和standby redo log files,如果你需要新的命名方式(例如,要将文件分布到不同磁盘上),你还是可以这么做。 在不同的主机上 § 可以手工重命名文件或在Standby Database上设置DB_FILE_NAME_CONVERT 和LOG_FILE_NAME_CONVERT 初始化参数来自动化重命名数据文件。 2.5 Online redo logs(联机redo log)、归档redo log和Standby redo log files Data Guard 恢复操作的最关键结构是Online redo logs(联机redo log)、归档redo log和Standby redo log files。从Primary Database传送的redo data由Standby system上的远程文件服务(RFS)进程接收,RFS 进程写Redo data(Redo数据)到归档日志文件或standby redo log files中。redo data可以在Redo写到archived redo log files或standbyredo log文件之后应用,如果允许实时应用的话,当standby redo log files写满后直接apply。 2.5.1 Online redo logs(联机redo log)和归档redo log Redo的传送是维护Primary Database 和 Standby Database的事务一致性所必须的,因此Online redo logs(联机redo log)和归档redo log在 Data Guard 环境中是必须的: l Online redo logs(联机redo log) Oracle Primary Database和Logical Standby Database的每个instance都有Online redo logs(联机redo log)以保护instance故障情况下的数据库。Primary Standby Database不使用Online redo logs(联机redo log),因为Primary Standby Database中的Standby Database以Read-Only模式打开,不允许单独更新并且不会生成新的redo data。 l 归档redo log files 归档redo log files是必须的,因为归档是用于使Standby Database与Primary Database保持事务一致性的方法。Primary Database、以及无论是Primary Standby Database和Logical Standby Database都使用归档redo log files。Oracle 数据库默认设置以 ARCHIVELOG 模式运行,所以归档(ARCn)进程自动拷贝每个写满的联机redo log文件到一个或更多 archived redo log files。不像Physical Standby Database,Logical Standby Database是打开的数据库,能生成日志数据并有多个日志文件,包括联机redo log files、archived redo log files和standby redo log files(如果配置)。 Online redo log files的大小和日志切换的频率都能影响主节点上archived redo log files的生成。Oracle 数据库高可用性概述提供了日志组大小的推荐值,日志的切换要控制在一个不是太频繁的范围之内,设置4组日志文件,每组两个成员,日志的切换不要小于20分钟。 Oracle 数据库在每次日志切换时都会发生check point(CKPT),通知dbwr进程写脏数据到数据文件中并且更新控制文件和数据文件头中的检查点信息。因此,如果联机redo log files的尺寸太小了,频繁的日志切换会导致频繁的检查点并且负面影响Standby Database的系统性能。 2.5.2 Standby redo log files Standby redo log files除了用于存储从其它数据库接收的Redo数据外,类似于Online redo logs(联机redo log)。 如果实施以下所列,则需要Standby redo log files: u 数据保护的最大保护和最大可用性级别(在 1.4 节中描述,在 5.6 节中详述) u 实时应用(在 6.2 节中描述) u 级联目的端(在附录 E 中描述) Standby redo log files提供了一些优势: l Standby redo log files能存放在裸设备上,这在Primary 与Standby Database都处于 Real Application Clusters 环境中时很重要。 l Standby redo log files可以使用多个成员进行多重镜像,提高archived redo log files的可靠性。 l During a failover, Data Guard can recover and apply more redo data from standby redo log files than from the archived log files alone。 l 在Primary Database上的归档(ARCn)进程或日志写(LGWR)进程能直接传送数据到远程Standby redo log files,潜在地消除了所需要注册部分archived redo log files的需求(例如,在Standby Database崩溃后的恢复)。请查看第 5 章以获得更多信息。 在3.1.3 节描述了如何配置Standby redo log files。 3 创建Physical Standby Database 本章将逐步指导你创建Physical Standby Database,它包括下述主要主题: u 为Standby Database创建准备Primary Database u 创建Physical Standby Database的逐步指导 u 创建后的步骤 在本章中描述的步骤以最高性能模式配置Standby Database,这是默认的数据保护模式。第 5章提供了配置不同数据保护模式的相关信息。在本章中的讨论假设你在服务器参数文件(SPFILE)中指定了初始化参数,替代了文本初始化参数文件(PFILE)。 3.1 为Standby Database创建准备Primary Database 在你创建Standby Database之前,你必须首先确保正确地配置好Primary Database。 表 3-1 提供了你在Primary Database上执行的为Physical Standby Database创建准备的任务的检查列表。每小节还有相关参考更详细地描述任务。 Reference Task Section 3.1.1 Enable Forced Logging允许强制记日志 Section 3.1.2 Create a Password File创建口令文件 Section 3.1.3 Configure a Standby Redo Log配置Standby redo log files Section 3.1.4 Set Primary Database Initialization Parameters设置Primary Database初始化参数 Section 3.1.5 Enable Archiving允许归档 Note:只要执行一次这些准备任务,在你完成这些步骤之后,数据库就准备好以Primary Database为一个或更多Standby Database服务了。 3.1.1 允许强制记日志 在数据库创建之后使用下面的 SQL 语句将Primary Database置于 FORCE LOGGING 模式: SQL> ALTER DATABASE FORCE LOGGING; 这条语句可能需要相当长的时间才能完成,因为它会等待所有未记日志的直接写 I/O 完成。 3.1.2 创建口令文件 如果没有已经存在的口令文件则创建一个。在 Data Guard 配置中的每个数据库必须使用口令文件,并且对于 SYS 用户的口令文件在每个系统上必须相同,以确保redo data传输成功。 3.1.3 配置Standby redo log files 最大保护和最大可用性模式都是需要Standby redo log files的,并且对于所有数据库推荐 LGWR ASYNC 传送模式。Data Guard 从Standby redo log files进行Redo apply比单独从archived redo log files进行Redo apply能恢复和应用更多的redo data。 你应该在创建Standby Database的时候,计划Standby redo log files配置并创建所有所需的日志组和组成员。为了提高可用性,考虑多重Standby redo log files,类似于多重联机redo log files的方式。执行下述步骤来配置Standby redo log files。 第 1 步:确保Primary Database 和 Standby Database上的日志文件尺寸是相同的。 当前Standby redo log files的尺寸必须与当前Primary Database联机redo log files的尺寸完全相同。例如,如果Primary Database使用两个Online redo logs(联机redo log)组,其日志文件是 200K,则Standby redo log files组也应该是 200K 大小的日志文件。 第 2 步:确定适当数量的Standby redo log files组。 最低限度下,配置应该比Primary Database上的联机redo log files组的数目多一个Standby redo log files组。然而, Standby redo log files组数目依赖于Primary Database上的线程数。使用下面的公式来确定Standby redo log files组的适当数目: (每个线程的日志文件的最大数目+1)×线程最大数目 使用这个公式减少了主instance的LGWR进程,因为在Standby Database上无法分配Standby redo log文件而被阻塞的可能性。例如,如果Primary Database每个线程有 2 个日志文件,并有 2 个线程,则在Standby Database上需要有 6 个Standby redo log files组。 Notes:Logical Standby Database根据工作负载可能需要更多的standby redo log files (或额外的 ARCn 进程)。这是因为Logical Standby Database也写联机redo log files,这优先于Standby redo log files。因此,Standby redo log文件可能没有联机redo log files归档速度快。 第 3 步:检验相关数据库参数和设置。 检查控制文件记录的MAXLOGFILES 和 MAXLOGMEMBERS两个参数,不然会限制Y对redo log files group和member的添加。修改 MAXLOGFILES和 MAXLOGMEMBERS 的参数只能是重建Primary Database的控制文件。 第 4 步:创建Standby redo log files组。 必须拥有 ALTER DATABASE 系统权限,才能创建新的Standby redo log files组。当Standby Database Primary Database上发生日志切换时,开始使用新创建的Standby redo data。 例 3-1 和例 3-2 显示了如何使用 ALTER DATABASE 语句和不同的 ADD STANDBY LOGFILE GROUP子句创建一个新的Standby redo log files组。 例 3-1: 添加一个Standby redo log files组到一个指定的线程 下面的语句添加一个新的Standby redo log files组到一个Standby Database,并指派到 THREAD 5: SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 5 ('/oracle/dbs/log1c.rdo','/oracle/dbs/log2c.rdo') SIZE 500M; THREAD 子句只有在你想添加一个或更多Standby redo log files组到指定的Primary Database线程时使用。如果你没有包括 THREAD 子句并且配置使用 Real Application Clusters(RAC),Data Guard 会在运行时,当不同 RAC instance需要时为Standby redo log files组自动分配线程。 例3-2:添加一个Standby redo log files组到一个指定的组号 你也可以使用 GROUP 子句指定标识组的号码: SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 10 ('/oracle/dbs/log1c.rdo','/oracle/dbs/log2c.rdo') SIZE 500M; 使用组号能使得管理 Standby redo log files组更容易,组号必须在 1 到 MAXLOGFILES子句的值之间,不能跳过日志文件组号。 注:虽然Standby redo log files只有在数据库运行在Standby角色时才使用,Oracle 建议你在Primary Database上创建一个Standby redo log files,使得Primary Database能快速切换到备用角色而不需要额外的 DBA 干涉。 第 5 步:检验Standby redo log files组已创建 要检验Standby redo log files组是否已经创建并正确地运行,需要在Primary Database上调用一个日志切换,然后查询Standby Database上的 V$STANDBY _LOG 视图或 V$LOGFILE 视图。例如: SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY _LOG; GROUP# THREAD# SEQUENCE# ARC STATUS --------- -------- ---------- --- ---------- 3 1 16 NO ACTIVE 4 0 0 YES UNASSIGNED 5 0 0 YES UNASSIGNED 3.1.4 设置Primary Database初始化参数 在Primary Database上,你定义当数据库处于Primary role时控制Redo transport services的初始化参数。当主数据库转换到备用角色时,你需要添加额外的参数来控制接收redo data和日志应用服务。 例子 3-3 显示了你在Primary Database上维护的Primary role初始化参数,这个例子表现了Primary Database位于 Chicago,一个Primary Standby Database位于 Boston 的 Data Guard 配置。在例子 3-3 中所示的参数对于 Chicago 数据库当它运行在主或Standby Database角色时都是有效的。配置举例使用下面表中所示的名字: Database DB_UNIQUE_NAME Oracle Net Service Name Primary chicago chicago Physical standby boston boston 例3-3:Primary Database:Primary role初始化参数 DB_NAME=chicago DB_UNIQUE_NAME=chicago LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)' CONTROL_FILES='/arch1/chicago/control1.ctl', '/arch2/chicago/control2.ctl' LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/chicago/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_2= 'SERVICE=boston LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY _ROLE) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE LOG_ARCHIVE_FORMAT=%t_%s_%r.arc LOG_ARCHIVE_MAX_PROCESSES=30 这些参数控制Redo transport services如何传送redo data到Standby system和本地文件系统上的redo data的归档。举例中指定了使用 LGWR 进程和异步(ASYNC)网络传输方式来传送redo data到LOG_ARCHIVE_DEST_2 初始化参数所定义的路径上。这些都是推荐的设置并且需要Standby redo log文件(查看 3.1.3 节,“配置Standby redo log files”)。 例子 3-4 显示了在Primary Database上额外的备用角色初始化参数,这些参数在Primary Database转换到备用角色时起效果。 例3-4:Primary Database上的Standby role(备用角色)初始化参数 FAL_SERVER=boston FAL_CLIENT=chicago DB_FILE_NAME_CONVERT='boston','chicago' LOG_FILE_NAME_CONVERT= '/arch1/boston/','/arch1/chicago/','/arch2/boston/','/arch2/chicago/' STANDBY _FILE_MANAGEMENT=AUTO Primary Database使用 3-4 中所指定的初始化参数来解决差异,从Primary Database转换新的数据文件和日志文件路径名,并在这个数据库处于备用角色时以归档方式接收redo data。使用上述Primary 和Standby角色集的初始化参数,在角色转换后不需要更改任何参数。 下面表提供了在例3-3 和例3-4 中所示的每个参数设置相关的简短解释。 Parameter Recommended Setting. DB_NAME Specify an 8-character name. Use the same name for all standby databases. 指定一个 8 字符名字。对于所有Standby Database要使用相同名字 DB_UNIQUE_NAME Specify a unique name for each database. This name stays with the database and does not change, even if the Primary and standby databases reverse roles. 为每个数据库指定一个唯一的名字。这个名字与数据库绑定不会更改,即使Primary Database 和 Standby Database交换角色。 LOG_ARCHIVE_CONFIG Specify the DG_CONFIG attribute on this parameter to list the DB_UNIQUE_NAME of the Primary and standby databases in the Data Guard configuration;this enables the dynamic addition of a standby database to a Data Guard configuration that has a Real Application Clusters Primary database running in either maximum protection or maximum availability mode. By default, the LOG_ARCHIVE_CONFIG parameter enables the Parameter Recommended Setting. database to send and receive redo; after a role transition, you may need to specify these settings again using the SEND, NOSEND, RECEIVE, or NORECEIVE keywords. CONTROL_FILES Specify the path name for the control files on the Primary database. Example 3–3 shows how to do this for two control files. It is recommended that a second copy of the control file is available so an instance can be easily restarted after copying the good control file to the location of the bad control file. 指定在Primary Database上的控制文件的路径名。例子 3-3 显示了如何为两个控制文件指定。推荐使用控制文件的第二个拷贝,使得instance能在拷贝好的控制文件到坏的控制文件位置之 后很容易地重启。 LOG_ARCHIVE_DEST_n Specify where the redo data is to be archived on the Primary and standby systems. In Example 3–3: ■ LOG_ARCHIVE_DEST_1 archives redo data generated by the Primary database from the local online redo log files to the local archived redo log files in /arch1/chicago/. ■ LOG_ARCHIVE_DEST_2 is valid only for the Primary role. This destination transmits redo data to the remote physical standby destination boston. Note: If a flash recovery area was configured (with the DB_RECOVERY_FILE_DEST initialization parameter) and you have not explicitly configured a local archiving destination with the LOCATION attribute, Data Guard automatically uses the LOG_ARCHIVE_DEST_10 initialization parameter as the default destination for local archiving. See Section 5.2.3 for more information. Also, see Chapter 14 for complete LOG_ARCHIVE_DEST_n information. LOG_ARCHIVE_DEST_1指定redo data在Primary 和Standby system上归档的位置。在例子 3-3 中: LOG_ARCHIVE_DEST_1 归档由Primary Database生成的redo data,从本地联机redo log files归档到在/arch1/chicago/目录的本地archived redo log files。 LOG_ARCHIVE_DEST_2只对于Primary role有效。这个参数指定从本地传送redo data到远程Primary Standby boston。 LOG_ARCHIVE_DEST_STATE_n Specify ENABLE to allow redo transport services to transmit redo data to the specified destination. 指定 ENABLE 以运行Redo transport services传送redo data到指定的Destination。 REMOTE_LOGIN_PASSWORDFILE Set the same password for SYS on both the Primary and standby databases. The recommended setting is either EXCLUSIVE or SHARED. 在Primary Database 和 Standby Database上为 SYS 都设置同样的口令。推荐的设置为EXCLUSIVE 或 SHARED。 Parameter Recommended Setting. LOG_ARCHIVE_FORMAT Specify the format for the archived redo log files using a thread (%t), sequence number (%s), and resetlogs ID (%r). See Section 5.7.1 for another example. 使用线程(%t),序列号(%s),和重置日志 ID(%r)指定archived redo log files的格式。 LOG_ARCHIVE_MAX_PROCESSES =integer Specify the maximum number (from 1 to 30) of archiver (ARCn) processes you want Oracle software to invoke initially. The default value is 4. See Section 5.3.1.2 for more information about ARCn processing. 指定你需要 Oracle 软件初始化调用归档(ARCn)进程的最大数目(从 1 到 30)。默认值是 4 FAL_SERVER Specify the Oracle Net service name of the FAL server (typically this is the database running in the Primary role). When the Chicago database is running in the standby role, it uses the Boston database as the FAL server from which to fetch (request) missing archived redo log files if Boston is unable to automatically send the missing log files. See Section 5.8. 指定 FAL 服务器(典型地这是运行在Primary role的数据库)的Oracle 网络服务名。当 chicago 数据库运行在备用角色,它使用 boston 数据库作为 FAL 服务器,如果 boston 无法自动发送丢失的日志文件,可以从那里取得(请求)丢失的归档redo log文件。查看 5.8 节。 指定 chicago 数据库的 Oracle 网络服务名。FAL 服务器(boston)拷贝丢失的archived redo log files到 chicago Standby Database。 FAL_CLIENT Specify the Oracle Net service name of the Chicago database. The FAL server (Boston) copies missing archived redo log files to the Chicago standby database. See Section 5.8. DB_FILE_NAME_CONVERT followed by the standby location. This parameter converts the path names of the Primary database datafiles to the standby datafile path names. If the standby database is on the same system as the Primary database or if the directory structure where the datafiles are located on the standby site is different from the Primary site, then this parameter is required. Note that this parameter is used only to convert path names for physical standby databases. Multiple pairs of paths may be specified by this parameter. 在Standby位置后面指定Primary Database文件的路径名和文件名位置。这个参数将Primary Database的数据文件路径名转换成Standby数据文件路径名。如果Standby Database与Primary Database处于同一系统上或如果数据文件在Standby node上的目录结构与主节点不同,则需要这个参数。注意这个参数只是用于转换Primary Standby Database的路径名。这个参数可以指定多对路径。 LOG_FILE_NAME_CONVERT Specify the location of the Primary database online redo log files followed by the standby location. This parameter converts the path names of the Primary database log files to the path names on the standby database. If the standby database is on the same system as the Parameter Recommended Setting. Primary database or if the directory structure where the log files are located on the standby system is different from the Primary system, then this parameter is required. Multiple pairs of paths may be specified by this parameter. 在Standby位置后面指定Primary Database联机redo log files的位置。这个参数将Primary Database日志文件的路径名转换成Standby Database上的路径名。如果Standby Database与Primary Database处于同一系统上或如果数据文件在Standby node上的目录结构与主节点不同,则需要这个参数。这个参数可以指定多对路径。 STANDBY_FILE_MANAGEMENT Set to AUTO so when datafiles are added to or dropped from the Primary database, corresponding changes are made automatically to the standby database. 设置为 AUTO 使得当在Primary Database上添加或删除数据文件时,相应的更改会自动应用到Standby Database。 3.1.5 打开归档 如果没有打开归档,执行下面的语句将Primary Database置于 ARCHIVELOG 模式并允许自动归档: SQL> shutdown immediate; SQL> startup mount; SQL> alter database archivelog; SQL> alter database open; SQL> archive log list; 3.2 Step by step 创建Primary Standby Databas 本节描述了你执行创建Primary Standby Database的任务。 表 3-2 提供了你执行创建Primary Standby Database的任务和你执行每个任务的数据库的检查列表。每个小节还有参考以更详细地描述任务。 3.2.1 创建Primary Database数据文件的备份拷贝 你可以使用Primary Database的任何备份拷贝来创建Primary Standby Database,只要你有必要的归档redo log文件来完全恢复数据库。Oracle 推荐你使用恢复管理工具(RMAN)。 3.2.2 为Standby Database创建控制文件 如果备份过程需要你关闭Primary Database,执行下面的 SQL*Plus 语句来启动Primary Database: SQL> STARTUP MOUNT; 然后,为Standby Database创建控制文件,并打开Primary Database允许用户访问,如下面举例所示: SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/boston.ctl'; SQL> ALTER DATABASE OPEN; 3.2.3 为Standby Database准备初始化参数文件 执行下面的步骤来创建备初始化参数文件。 第 1 步:拷贝Primary Database参数文件到Standby Database。 从Primary Database使用的服务器参数文件(SPFILE)创建一个文本初始化参数文件;文本初始化参数文件能拷贝到备位置并修改。例如: SQL> CREATE PFILE='/tmp/initboston.ora' FROM SPFILE; 后面,在 3.2.5 节,在修改这个文件以包含适用于Primary Standby Database的参数值之后,你将这个文件转换回服务器参数文件。 第 2 步:在Primary Standby Database上设置初始化参数 虽然在你从Primary system(主系统)拷贝来的文本初始化参数文件中的大多数初始化参数设置也适用于Primary Standby Database,但是需要进行一些修改。 例子 3-5 显示了备初始化参数文件中部分,对于Primary Standby Database进行的修改,与例子3-3 和例子 3-4 中不同的参数值以粗体所示。在例子 3-5 中所示的参数在 boston 数据库运行于Primary 或Standby Database角色时都是有效的。 例子 3-5:为Primary Standby Database修改初始化参数 DB_NAME=chicago --对于Primary database和standby database在不同主机上可以忽略下面这个参数 DB_UNIQUE_NAME=boston LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)' CONTROL_FILES='/arch1/boston/control1.ctl','/arch2/boston/control2.ctl' LOG_FILE_NAME_CONVERT='/arch1/chicago/','/arch1/boston/','/arch2/chicago/','/arch2/boston/' LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/boston/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2= 'SERVICE=chicago LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY _ROLE) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE STANDBY _FILE_MANAGEMENT=AUTO FAL_SERVER=chicago FAL_CLIENT=boston 注意该例子假设使用 LGWR 进程来传送redo data到本地和在 LOG_ARCHIVE_DEST_2初始化参数上的远程Destination。 另外,确保在Primary Database 和 Standby Database上设置 COMPATIBLE 初始化参数为相同值。如果该值不同,Redo transport services可能无法从Primary Database传送redo data到Standby Database。在 Data Guard 配置中,COMPATIBLE 必须设为最小值 9.2.0.1.0。然而,如果你想利用新的 Oracle 数据库 10g 的特性,设置 COMPATIBLE 参数为 10.2.0.0 或更高。使用SHOW PARAMETERS 命令来检查没有其它的参数需要更改总是一个很好的习惯。 下面的表提供了在例子 3-5 中所示的与Primary Database不同设置的参数设置的简要解释。 参数 DB_UNIQUE_NAME: 为这个数据库指定唯一的名字。这个名字与数据库绑定不会更改,即使Primary Database 和 Standby Database交换角色。 CONTROL_FILES: 指定在Primary Database上的控制文件的路径名。例子 3-3 显示了如何为两个控制文件指定。推荐使用控制文件的第二个拷贝,使得instance能在拷贝好的控制文件到坏的控制文件位置之后很容易地重启。 DB_FILE_NAME_CONVERT: 在Standby位置后面指定Primary Database文件的路径名和文件名位置。这个参数将Primary Database的数据文件路径名转换成备数据文件路径名。如果Standby Database与Primary Database处于同一系统上或如果数据文件在Standby node上的目录结构与主节点不同,则需要这个参数。 LOG_FILE_NAME_CONVERT: 在Standby位置后面指定Primary Database联机redo log files的位置。这个参数将Primary Database日志文件的路径名转换成Standby Database上的路径名。如果Standby Database与Primary Database处于同一系统上或如果数据文件在Standby node上的目录结构与主节点不同,则需要这个参数。 LOG_ARCHIVE_DEST_n: 指定redo data归档的位置。在例子 3-5 中:LOG_ARCHIVE_DEST_1 归档从Primary Database收到的Redo数据到/arch1/boston/目录中的archived redo log files。 LOG_ARCHIVE_DEST_2 当前被忽略,因为这个Destination只对Primary role有效。如果发生了切换并且这个instance成为主数据库,则会传送redo data到远程 chicago Destination。 注:如果配置了闪回恢复区域(使用 DB_RECOVERY_FILE_DEST初始化参数)并且你没有使用 LOCATION 属性显式配置本地归档Destination,Data Guard 自动使用 LOG_ARCHIVE_DEST_10 初始化参数作为本地归档的默认Destination。查看 5.2.3 节以获得更多信息。 FAL_SERVER: 指定 FAL 服务器(典型地这是运行在Primary role的数据库)的 Oracle网络服务名。当 boston 数据库运行在备用角色,它使用 chicago 数据库作为 FAL 服务器,如果 chicago 无法自动发送丢失的日志文件,可以从那里取得(请求)丢失的archived redo log files。指定 boston 数据库的 Oracle 网络服务名。FAL 服务器(chicago)拷贝丢失的archived redo log files 到 boston Standby Database。 FAL_CLIENT: 为可能需要更改的额外参数检查初始化参数文件。例如,如果在Standby Database上的目录位置与在Primary Database上指定的不同,你可能需要更改转储Destination参数(BACKGROUND_DUMP_DEST,CORE_DUMP_DEST,USER_DUMP_DEST)。另外,如果没有已经存在,你可能必须在Standby system上创建目录。 3.2.4 从Primary system拷贝文件到Standby system 使用操作系统拷贝工具将下面的二进制文件从Primary system(主系统)拷贝到Standby system: 在 3.2.1 节中创建的备份数据文件 在 3.2.2 节中创建的备控制文件(standby controlfile) 在 3.2.3 节中创建的初始化参数 3.2.5 设置环境以支持Standby Database 执行下面的步骤以创建一个基于 Windows 的服务,创建一个口令文件,设置 Oracle 网络环境,以及创建一个 SPFILE。 第 1 步:创建一个基于 Windows 的服务。 如果Standby system是运行在基于 Windows 的系统上,使用 ORADIM 工具来创建 Windows 服务和口令文件。例如: WINNT> oradim -NEW -SID boston -INTPWD password -STARTMODE manual 第 2 步:创建一个口令文件。 在 Windows 以外的平台上,创建一个口令文件,然后为 SYS 用户设置与在Primary Database上的 SYS 用户相同的口令。为了成功传输Redo,在 Data Guard 配置中的每个数据库上的 SYS 用户的口令都必须相同。查看 Oracle 数据库管理员指南。 第 3 步:为Primary Database 和 Standby Database配置监听。 在主和Standby node上,使用 Oracle 网络管理器为相关数据库配置监听。 要启动监听(获得新的定义),在主和Standby system上输入下面的 LSNRCTL 工具命令: % lsnrctl stop % lsnrctl start 查看 Oracle 数据库网络服务管理员指南。 第 4 步:创建 Oracle 网络服务名。 在主和Standby system上,使用 Oracle 网络管理器来为Primary Database 和 Standby Database创建网络服务名,为Redo传输服务所使用。 Oracle 网络服务名必须解析一个连接描述符,使用当你为Primary Database 和 Standby Database配置监听器时指 定的同样的协议、主机地址、端口和服务。连接描述符也必须指定使用专用服务器。 查看 Oracle 数据库网络服务管理员指南和 Oracle 数据库管理员指南。 第 5 步:为Standby Database创建一个服务器参数文件。 在一个空闲的Standby Database上,使用 SQL CREATE 语句来从步骤 2 中编辑的文本初始化参数文件,为Standby Database创建一个服务器参数文件。例如: SQL> CREATE SPFILE FROM PFILE='initboston.ora'; 3.2.6 启动Primary Standby Database 执行下面的步骤来启动Primary Standby Database和Redo应用。 第 1 步:启动Primary Standby Database。 在Standby Database上,执行下面的 SQL 语句来启动和安装数据库: SQL> STARTUP MOUNT; 第 2 步:启动Redo应用。 在Standby Database上,执行下面的命令来启动Redo应用: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; 该语句包含 DISCONNECT FROM SESSION 选项,使得Redo应用运行在后台会话中。 查看 6.3 节,“应用redo data到Primary Standby Database”以获得更多信息。 第 3 步:测试归档操作到Primary Standby Database。 在这个例子中,直到日志切换之后,redo data到远程备位置的传输才会发生。默认地,当联机redo log files满的时候,日志切换发生。要强制日志切换,使得redo data立即传送,在Primary Database上使用下面的 ALTER SYSTEM 语句。例如: SQL> ALTER SYSTEM SWITCH LOGFILE; 3.2.7 检验Primary Standby Database正确执行 一旦你创建Primary Standby Database并设立Redo transport services,你可能需要检查数据库更改成功地被从Primary Database传送到Standby Database。要在Standby Database上看到接收到redo data,你首先应该在Standby Database上确认现有的归档redo log 文件,在Primary Database上强制日志切换并归档一些联机redo log files,然后再次检查Standby Database。下面的步骤显示如何执行这些任务。 第 1 步:确认现有的archived redo log files。 在Standby Database上,查询 V$ARCHIVED_LOG 视图以确认归档redo log中现有的文件。例 如: SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME 2 FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#; SEQUENCE# FIRST_TIME NEXT_TIME ---------- ------------------ ------------------ 8 11-JUL-02 17:50:45 11-JUL-02 17:50:53 9 11-JUL-02 17:50:53 11-JUL-02 17:50:58 10 11-JUL-02 17:50:58 11-JUL-02 17:51:03 3 rows selected. 第 2 步:强制日志切换以归档当前的联机redo log files。 打开Primary Database,执行 ALTER SYSTEM SWITCH LOGFILE 语句以强制日志切换并归档 当前联机redo log files组: SQL> ALTER SYSTEM SWITCH LOGFILE; 第 3 步:在Standby Database上检查新的redo data已归档。 在Standby Database上,查询 V$ARCHIVED_LOG 视图来检查redo data已收到并归档到被数据库: SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME 2> FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#; SEQUENCE# FIRST_TIME NEXT_TIME ---------- ------------------ ------------------ 8 11-JUL-02 17:50:45 11-JUL-02 17:50:53 9 11-JUL-02 17:50:53 11-JUL-02 17:50:58 10 11-JUL-02 17:50:58 11-JUL-02 17:51:03 11 11-JUL-02 17:51:03 11-JUL-02 18:34:11 4 rows selected. 归档的redo log files现在可以应用到Primary 被数据库上了。 第 4 步:检查新归档的redo log files已应用。 在Standby Database上,查询 V$ARCHIVED_LOG 视图来检查archived redo log files已应用。 SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG 2 ORDER BY SEQUENCE#; SEQUENCE# APP --------- --- 8 YES 9 YES 10 YES 11 YES 4 rows selected. 查看 5.9.1 节,“监控日志文件归档信息”和 8.5.4 节,“监控在Primary Standby Database上的日志应用服务”来检查Redo transport services和日志应用服务正确工作。 3.3 建库完成后的后续步骤 在这个时候,Primary Standby Database已运行并能够提供最大性能级别的数据保护,下面的列表描述了可以在Primary Standby Database上进行的其它工作: 升级数据包含模式 Data Guard 配置初始化是设置为最大性能模式(默认)。查看 5.6 节以获得数据保护模式和如何升级或降级当前保护模式的相关信息。 l 允许 Flashback 数据库 Flashback 数据库消除了在failover之后重建Primary Database的需求。Flashback 数据库允许你将数据库返回到最近的过去时间的状态,比传统的基于时间点的恢复要快很多,因为它不需要从备份中恢复数据文件,也不需要大量地应用redo data。You can在主数据库上、Standby Database上、或两者都允许 Flashback 数据库。查看 12.4 节和 12.5 节以获得显示如何在 Data Guard 环境中使用 Flashback 数据库的场景。同时,查看 Oracle 数据库备份和恢复高级用户指南以获得 Flashback 数据库的更多相关信息。 4 创建Logical Standby Database u 本章逐步指导你创建Logical Standby Database。它包括下述主要主题: u 创建Logical Standby Database的先决条件 u 创建Logical Standby Database的逐步指导 u 建库的后续步骤 同时请参照以下文档: Oracle 数据库管理员指南以获得创建和使用服务器参数文件相关信息 Oracle Data Guard Broker 和 Oracle 企业管理器联机帮助系统以获得使用图形用户界面自动创建Logical Standby Database相关信息 4.1 创建Logical Standby Database的先决条件 在你创建Logical Standby Database之前,你必须首先确保正确地配置好Primary Database。表 4-1 提供了你在Primary Database上执行的为Logical Standby Database创建准备的任务的检查列表。每小节还有相关参考更详细地描述任务。 Table 4–1 为Logical Standby Database的创建准备Primary Database Reference Task Section 4.1.1 确定对于表的数据类型和存储属性的支持 Section 4.1.2 确保在Primary Database中的表行能被唯一标识 4.1.1 确定对于表的数据类型和存储属性的支持 在设置Logical Standby Database之前,要确保Logical Standby Database能维护你的Primary Database中的数据类型和表,查看附录 C 以获得数据类型和存储类型考虑的完整列表。可以通过查询视图DBA_LOGSTDBY_UNSUPPORTED来确定主数据库中是否含有不支持的对象: SQL> SELECT * FROM DBA_LOGSTDBY_UNSUPPORTED;   如果主数据库中含有不支持的对象,日志确认服务进程(Log Apply Service)在向 standby数据库应用redo log时会自动排除这些对象。 4.1.2 确保在Primary Database中的表行能被唯一标识 虽然Logical Standby Database是从Primary Database的备份拷贝中创建的,在Logical Standby Database中的物理结构(physical organization)也不同于Primary Database,。那么,Primary Database所生成的Redo记录(redo records)中包含的 ROWID 不能用于识别在Logical Standby Database中相应的行。 Oracle 使用主键或唯一约束/索引补充记录作为补就,来逻辑地标识在Logical Standby Database中被更改的行。当允许数据库范围的主键和唯一约束/索引补充记录时,每个 UPDATE 语句必须将需要的的列的值写到redo log中,以便在Logical Standby Database中唯一地标识被修改了的记录。 n 如果表定义了主键,则主键与被更改的列一起记录,作为 UPDATE 语句的一部分来标识更改的行。 n 如果没有主键,则最短的非空唯一约束/索引与更改的行一起记录,作为 UPDATE语句的一部分来标识更改的行。 n 如果即没有主键也没有非空唯一约束/索引,则所有有界限大小的列作为 UPDATE语句的一部分记录,以标识更改的行。换一句话说,记录所有列除了:LONG、LOB、LONG RAW、对象类型和集合。 Oracle 建议在Primary Database中添加一个主键或非空唯一索引,只要可能,确保 SQL 应用能有效地应用redo data库更新到Logical Standby Database。 请执行下面的步骤来确保 SQL 应用能唯一地标识在Logical Standby Database中被复制的每个表的记录。 第 1 步:在Primary Database中找到没有唯一逻辑标识符的表。 查询 DBA_LOGSTDBY_NOT_UNIQUE 视图来确定 SQL 应用可能无法唯一标识的表的列表。 SQL> SELECT OWNER, TABLE_NAME, BAD_COLUMN FROM DBA_LOGSTDBY_NOT_UNIQUE 2> WHERE (OWNER, TABLE_NAME) NOT IN 3> (SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED) 4> AND BAD_COLLUMN = 'Y' 以上查询会返回用户名、表名以及通过Y和N来标识的字段BAD_COLUMN: n 如果BAD_COLUMN的值为Y,表示这张表的字段使用一个大的数据类型,如LONG。如果有两条这样的记录存在表中(除LOB字段外),这张表就无法被正确维护。 n 值为N表示表含有足够的信息来维护standby数据库上的表(但是却没有主键或无空值约束)。然而,如果你增加了主键, Redo transport services进程(Log Transport Service)和SQL实施操作进程将会更高效。 第 2 步:添加一个非激活依赖主键的 RELY 约束 如果你的应用可以确保表中的记录是唯一的,那么你可以在表上创建一个disable主键的 RELY 约束,这能减少在Primary Database上维护主键的开销。 要在Primary Database表上创建一个disable的 RELY 约束,使用带 RELY DISABLE 子句的 ALTER TABLE 语句。下面的例子在名为 mytab 的表上创建了一个禁止的 RELY 约束,每一行都能使用 id 和 name 列唯一标识: SQL> ALTER TABLE mytab ADD PRIMARY KEY (id, name) RELY DISABLE; 关键字RELY是系统知道对id和name两个字段记录日志以定位这张表的记录。但是在选择非激活依赖的约束(这个约束会创建一个主键)的字段时要特别小心。如果选择的字段无法为这张表创建一个主键信息,SQL实施操作进程将无法在standby数据库上应用这些日志。  当你指定 RELY 约束时,系统将假设行是唯一的。因为你告诉系统依靠该信息,但是在每次更改表时不会去确认,所以对于将唯一标识表中的每一行的禁止的 RELY 约束,你必须小心查询列。如果这样的唯一性不存在,则 SQL 应用将无法正确地维护该表。 要提高 SQL 应用的性能,在Logical Standby Database上添加一个唯一约束/索引到列上以标识行。如果添加失败会导致 SQL 应用在表上进行的 UPDATE 或 DELETE 语句时进行全表扫描。 同时查看: 查看 Oracle 数据库参考以获得 DBA_LOGSTDBY_NOT_UNIQUE 视图的相关信息 Oracle 数据库 SQL 参考以获得 ALTER TABLE 语句语法和创建 RELY 约束相关信息 9.6.1 节,“创建主键 RELY 约束”以获得 RELY 约束和你增加Logical Standby Database性能所采取措施相关信息 4.2 创建Logical Standby Database的逐步指导 本小节描述了你创建Logical Standby Database所执行的任务。 表 4-2 提供了你创建Logical Standby Database和指定在哪个数据库上执行每个任务的任务列表。每小节还有相关参考更详细地描述任务。 表 4-2 创建Logical Standby Database Table 4–2 Creating a Logical Standby Database Reference Task Database Section 4.2.1 Create a Physical Standby Database Primary 创建Primary Standby Database Section 4.2.2 Stop Redo Apply on the Physical Standby Database 在Primary Standby Database上停止redo apply Standby Section 4.2.3 Prepare the Primary Database to Support a Logical Standby Database 准备Primary Database以支持Logical Standby Database数据库 Primary Section 4.2.4 Transition to a Logical Standby Database 转换到Logical Standby Database Standby Section 4.2.5 Open the Logical Standby Database Standby Section 4.2.6 Verify the Logical Standby Database Is Performing Properly Standby 检查Logical Standby Database正确执行 Standby 4.2.1 创建Primary Standby Database 创建Logical Standby Database之前,需要首先创建Primary Standby Database然后将其转换成Logical Standby Database。请参照第 3章,“创建Primary Standby Database”中的指导来创建Primary Standby Database。 4.2.2 在Primary Standby Database上停止Redo应用 可以在将新的Primary Standby Database转换成Logical Standby Database之前在上面运行任何长度时间的redo applyRedo应用。但是,在转换到Logical Standby Database之前,在Primary Standby Database上必须停止Redo应用。停止Redo应用是必要的,可以避免应用在包含 LogMiner 字典的Redo之后的更改(在 4.2.3.2 节,“在Redo数据中建立字典”中描述)。 要停止Redo应用,在Primary Standby Database上执行下面的语句。如果数据库是包含多个instance的RAC 数据库,则你在执行这个命令之前必须首先停止除一个instance以外的其它所有 RAC instance: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 4.2.3 准备Primary Database以支持Logical Standby Database 本小节包含下面主题: u 为角色转换准备Primary Database u 在redo data中建立字典 4.2.3.1 为角色转换准备Primary Database(Role Transitions) 在 3.1.4 节,“设置Primary Database初始化参数”中,已经设置多个standby role初始化参数以在Primary database转换到physical standby role时起作用。如果你计划转换Primary Database到logical standby role,则你还必须在主数据库上配置 LOG_ARCHIVE_DEST_3所指定的目标,如例子 4-1 中所示,使得在角色转换之后不需要更改参数。这个参数只有在Primary Database转变为备用角色时才起作用。 例子 4-1:Primary Database:逻辑备用角色初始化参数 LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/chicago/ VALID_FOR=(STANDBY _LOGFILES,STANDBY _ROLE) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_STATE_3=ENABLE 要动态设置 LOG_ARCHIVE_DEST_3 参数,使用 SQL ALTER SYSTEM SET 语句并包含 SCOPE=BOTH 子句,使得更改立即起作用并在数据库重启动后仍然有效。 下面的表描述了由例子 4-1 中所示初始化参数定义的归档进程。 When the Chicago Database Is Running in the Primary Role 当 chicago 数据库运行在Primary role When the Chicago Database Is Running in the Logical Standby Role 当 chicago 数据库运行在逻辑备用角色 LOG_ARCHIVE_DEST_3 Is ignored; LOG_ARCHIVE_DEST_3 is valid only when chicago is running in the standby role. LOG_ARCHIVE_DEST_3被忽略;LOG_ARCHIVE_DEST_3只有在 chicago 运行在被角色时才有效。 Archives redo data received from the Primary database to the local archived redo log files in /arch2/chicago/. 归档从Primary Database接收到的redo data到/arch2/chicago/上的本地归档Redo日志文件。 4.2.3.2 在redo data中建立字典 LogMiner数据字典 必须建立到redo data中,使得 SQL 应用的 LogMiner 组件能正确地解释它在Redo中看到的更改。作为建立 LogMiner Multiversioned Data Dictionary 的一部分,追加的记录自动设置以记录主键和唯一约束/索引列,追加的记录信息确保每次更新包含足够的信息以逻辑地标识由语句更改的每一 条记录。 要建立 LogMiner 字典,执行下面语句: SQL> EXECUTE DBMS_LOGSTDBY.BUILD; DBMS_LOGSTDBY.BUILD 过程需要等待所有现存的事务完成,在Primary Database上执行的长时间运行的事务将会影响这条命令的完成时间。 DBMS_LOGSTDBY.BUILD 过程使用 Flashback 查询来获得被记录到redo stream(Redo流)中的数据字典的一致性映像(snapshot)。Oracle 推荐在Primary 和Logical Standby Database上设置 UNDO_RETENTION初始化参数都为 3600。 请参照: 在 Oracle 数据库 PL/SQL 包和类型参考中的 DBMS_LOGSTDBY.BUILD PL/SQL 包和在Oracle 数据库参考中的 UNDO_RETENTION 初始化参数 4.2.4 转换到Logical Standby Database 本小节描述了如何准备Primary Standby Database来转换到Logical Standby Database,包含下面主题: u 转换到Logical Standby Database u 创建新的口令文件 u 为Logical Standby Database调整初始化参数 4.2.4.1 转换到Logical Standby Database redo log包含转换你的Primary Standby Database到Logical Standby Database必要的信息。要继续应用Redo数据到Primary Standby Database指导其准备好转换为Logical Standby Database,执行下面的 SQL 语句: SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name; db_name参数,指定一个数据库名字以标识新的Logical Standby Database。如果你在执行这条语句的时候使用服务器参数文件(spfile),则数据库会使用新的Logical Standby Database相关的适当信息更新该文件。如果你没有使用 spfile,则数据库会发出一条信息提示你在关闭数据库后设置DB_NAME 参数的名字。 该语句等待apply redo data,直到在日志文件中找到 LogMiner 字典。这可能会花费几分钟,依赖于在 4.2.3.2 节,“在redo data中建立字典”中生成的Redo多久才能传送到Standby Database,以及需要应用多少redo data库。如果LogMiner数据字典建立没能在Primary Database上成功执行,这条命令将永远不会完成,就需要通过在另外的 SQL 会话中执行 ALTER DATABASE RECOVER MANANGED STANDBY DATABASE CANCEL 语句来取消该 SQL 语句。 4.2.4.2 创建新的口令文件 因为转换过程对于Logical Standby Database更改了数据库名字(原先以 DB_NAME 初始化参数设置),所以你必须重建口令文件。 4.2.4.3 为Logical Standby Database调整初始化参数 在Logical Standby Database上,关闭instance并执行 STARTUP MOUNT 语句来启动数据库。不要打开数据库;它对于用户访问应该保持关闭,直到后面的创建过程完成。例如: SQL> SHUTDOWN; SQL> STARTUP MOUNT; 你还需要修改 LOG_ARCHIVE_DEST_n 参数,因为不像Primary Standby Database,Logical Standby Database是打开的数据库,生成redo data并有多个日志文件(联机redo log files,archived redo log files,和standby redo log files)。指定分开的本地Destination是一个很好的习惯: l 存储由Logical Standby Database生成的redo data的archived redo log files。在例子 4-2 中,这配置为 LOG_ARCHIVE_DEST_1=LOCATION=/arch1/boston Destination。 l 存储从Primary Database接收到的redo data的archived redo log files。在例子 4-2 中,这配置为 LOG_ARCHIVE_DEST_3=LOCATION=/arch2/boston Destination。 例子 4-2 显示了为Logical Standby Database修改的初始化参数,所示的参数对于 boston 逻辑Standby Database不管其是运行在主还是Standby Database角色者是有效的,。 例子 4-2:为Logical Standby Database修改初始化参数 LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/boston/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2= 'SERVICE=chicago LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY _ROLE) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/boston/ VALID_FOR=(STANDBY _LOGFILES,STANDBY _ROLE) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_3=ENABLE 下面的表描述了由例子 4-2 中所示的初始化参数定义的归档过程。 当 boston 数据库运行在Primary role时 当 boston 数据库运行在逻辑备用角色时 LOG_ARCHIVE_DEST_1 指示由Primary Database生成的redo data从本地联机redo log files到/arch1/boston/中的本地归档Redo日志文件的归档 指示由Logical Standby Database生成的redo data从本地联机redo log files到/arch1/boston/中的本地归档redo log文件的归档 LOG_ARCHIVE_DEST_2 指示redo data到远程Logical Standby Databasechicago 的传输 被忽略LOG_ARCHIVE_DEST_2 只有在 boston 运行在Primary role时才有效。 LOG_ARCHIVE_DEST_3 被忽略 LOG_ARCHIVE_DEST_3只有在 boston 运行在被角色时才有效 指示从Primary Database接收到的redo data到/arch2/boston/中的本地归档redo log文件的归档 注:一旦Primary Standby Database转换到Logical Standby Database,DB_FILE_NAME_CONVERT 初始化参数就无法兑现了。如果有必要,你应该注册一个skip handler,通过转换Primary Database数据文件的名字到Stanby数据库数据文件路径名,给 SQL 应用提供一个替代的 DDL 串来执行。 请参照 Oracle 数据库PL/SQL 包和类型参考中的 DBMS_LOGSTDBY 包以获得更多的 SKIP 过程相关信息。 4.2.5 打开Logical Standby Database 新的数据库与你的Primary Database在逻辑上是一样的,但是它在事务上与Primary Database不一致,因而对于恢复操作是不相容的。要打开新的Logical Standby Database,你必须通过执行下面的语句以 RESETLOGS 选项来打开: SQL> ALTER DATABASE OPEN RESETLOGS; 因为这是数据库第一次打开,所以数据的全局名自动调整以符合新的 DB_NAME 初始化参数。执行下面的语句来开始应用redo data库到Logical Standby Database。 例如: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 4.2.6 检查Logical Standby Database正确执行 为了验证Logical Standby Database是否正确执行,查看下面小节: u 5.9.1 节,“监控日志文件归档信息” u 6.4.3 节,“在Logical Standby Database上监控 SQL 应用” u 第 9 章,“管理Logical Standby Database” 4.3 创建后的步骤 在这个时候,Logical Standby Database已经运行并能提供最大性能级别的数据保护。下面的列表描述了You can在Logical Standby Database上进行的额外的准备: l 升级数据保护模式 Data Guard 配置初始设置为最大性能模式(默认)。查看 5.6 节,“设置数据保护模式”以获得数据保护模式和如何升级或降级当前保护模式相关的信息。 l 允许 Flashback 数据库 Flashback 数据库消除了在failover之后重建Primary Database的需求。Flashback 数据库允许你将数据库返回到最近的那个过去时间的状态,比传统的基于时间点的恢复要快很多, 因为它不需要从备份中恢复数据文件,也不需要大量地应用redo data。You can在主数据库上、Standby Database上、或两边都允许 Flashback 数据库。查看 12.4 节,“在failover后使用 Flashback 数据库”和 12.5 节,“在执行 open resetlogs 语句后使用 Flashback 数据库” 以获得显示如何在 Data Guard 环境中使用 Flashback 数据库的场景。同时,查看 Oracle数据库备份和恢复高级用户指南以获得 Flashback 数据库的更多相关信息。 5 Redo transport services 本章描述了如何配置从一个生产数据库传送Redo到一个或更多Standby Destination的Redo transport services,主要包含下面主题: u Redo transport services介绍 u 发送redo data到哪里 u 如何发送redo data u 应该何时发送redo data u 出现错误如何应对 u 设置数据保护模式 u 管理日志文件 u 管理归档中断 u 核查 5.1 Redo Transport Services介绍 Redo Transport Services控制从数据库Destination到一个或更多Destination的redo data的自动化转移。Redo transport services也管理解决由于网络故障导致archived redo log files中断的过程。 Redo Transport Services能传送redo data到本地和远程Destination。远程Destination能包括任何下面类型:Primary 和Logical Standby Database,归档redo log档案资料库,Oracle Change Data Capture 分段运输数据库,和 Oracle Streams 下游捕获数据库。 图 5-1 显示了一个简单的 Data Guard 配置,Redo Transport Services归档redo data到Primary Database端的本地路径,同时也传送到在远程Standby DatabaseDestination上的archived redo log files或Standby redo log files文件。 图 5-1 传送redo data 5.2 发送redo data到哪里 本节包含下述主题: u Destination类型 u 如何发送redo data u 设置闪回恢复区域 5.2.1 Destination类型 Redo Transport Services支持多种类型的Destination: l Oracle Data Guard Standby Database Standby DatabaseDestination既可以是Primary Standby Database也能是Logical Standby Database。1.1.2 节讨论了standby数据库。 l 归档redo log档案资料库 这种类型Destination允许脱离节点(off-site)归档redo data。归档日志档案资料库是使用Primary standby控制文件来启动instance、并mount数据库来创建的。这个数据库不包含数据文件并且不能用于切换或failover。这种替代方法作为短时间内,可能是一天,保留归档redo log的方法是很有用的,然后日志文件能够被删除,。这避免了另外全配置的Standby Database的绝大多数存储和处理过程代价。 Oracle 推荐使用归档redo log档案资料库作为archived redo log files的临时存储。这能通过在运行于最大性能模式的 Data Guard 配置中为基于归档的传输(使用LOG_ARCHIVE_DEST_n 参数上的 ARCH 属性)配置档案资料库Destination来完成。对于无数据丢失的环境,你应该使用全配置的Standby Database,在 Data Guard 配置中使用 LGWR、SYNC和 AFFIRM 传输设置以及运行在最大保护模式或最大可用性模式。 l Oracle Streams real-time downstream capture database 这种Destination类型允许 Oracle Streams 在远程下游数据库上配置一个捕获进程。Streams 下游捕获进程使用Redo transport services来传送redo data到下游数据库,在那里 Streams捕获进程捕获在远程Destination上的Standby redo log files和archived redo log files中的更改。查看Oracle Streams 概念和管理以获得更多信息。 l Oracle Change Data Capture staging database 这种Destination类型远程支持在分段运输数据库上的 Oracle Change Data Capture Asynchronous AutoLog 配置。使用Redo transport services将redo data从源数据库拷贝到分段运输数据库上。Change Data Capture 配置捕获从redo data中的更改。查看 Oracle 数据库数据仓库指南以获得更多信息。 为了讨论目的,本指南称生产数据库为Primary Database,归档Destination为Standby Database(如 1.1 节中定义)。如果你使用 Oracle Change Data Capture,分别将术语源和分段运输数据库替换为Primary 和Standby Database。如果你使用 Oracle Streams,分别将术语源和下游捕获数据库替换为Primary 和standby数据库。 5.2.2 使用 LOG_ARCHIVE_DEST_n 参数配置Destination LOG_ARCHIVE_DEST_n 初始化参数最多定义10(n=1,2,3,…10)个Destination,每个必须指定 LOCATION 或 SERVICE 属性来指定归档redo data到哪里。 LOCATION和 SERVICE 属性描述了本地磁盘位置或代表一个Redo transport services将会传送redo data的StandbyDestination的 Oracle 网络服务名。使用 SERVICE 属性指定远程Destination允许 Data Guard维护一个Primary Database的事务一致性远程拷贝,以用于灾难恢复。 对于你定义的每个 LOG_ARCHIVE_DEST_n 初始化参数,指定相应的LOG_ARCHIVE_DEST_STATE_n 参数。LOG_ARCHIVE_DEST_STATE_n(n 是从 1 到 10的整数)初始化参数指定相应的Destination当前是开(允许)还是关(禁止)。 表 5-1 描述了LOG_ARCHIVE_DEST_STATE_n 参数属性。 Attribute Description ENABLE Redo transport services can transmit redo data to this destination. This is the default. Redo transport services可以传送redo data到这个Destination。这是默认值。 DEFER Redo transport services will not transmit redo data to this destination. This is a valid but unused destination. Redo transport services不会传送redo data到这个Destination,这是有效但没有使用的Destination ALTERNATE This destination is not enabled, but it will become enabled if communication to its associated destination fails. 这个Destination没有被允许,但是如果到其相关的Destination的连接故障了则它将变成允许 RESET Functions the same as DEFER, but clears any error messages for the destination if it had previously failed. 与DEFER 的功能相同,但是如果以前发生故障则为Destination清理任何错误信息 Example 5–1 Specifying a Local Archiving Destination LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/' LOG_ARCHIVE_DEST_STATE_1=ENABLE 图 5-2 显示了这个简单的配置,包含单个本地Destination看起来是什么样的。LGWR写redo data到Online redo log files。当每个Online redo logs(联机redo log)写满时,发生日志切换并且 ARCn进程归档写满的online redo log files到archived redo log files。写满的online redo log files现在又可以重用了。 图 5-2 当没有Standby Database时的Primary Database归档 这里有一个重点是在图 5-2 中所示的配置没有包括Standby Database,因而不提供灾难恢复保护。要使得这个简单配置变为提供灾难恢复的 Data Guard 配置,通过指定 SERVICE 属性在远程Destination添加一个Standby Database。 例子 5-2 显示了允许Redo transport services在本地Destination chicago 归档Online redo logs并传送redo data到使用 Oracle 网络服务名 boston 远程Standby Database的初始化参数。该例子对于所有的其它 LOG_ARCHIVE_DEST_n 属性使用了默认值。 例子 5-2:指定远程归档Destination LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_2='SERVICE=boston' LOG_ARCHIVE_DEST_STATE_2=ENABLE 这些初始化参数设置了使用归档(ARCn)进程归档本地和远程Destination的 Data Guard 配置。这种配置提供了最大性能级别的数据保护。 虽可以仅仅通过在 LOG_ARCHIVE_DEST_n 参数上指定 LOCATION 或 SERVICE 属性创建 Data Guard 配置,但是也可以选择指定更多的属性来进一步定义每个Destination的行为。第 14 章提供了所有 LOG_ARCHIVE_DEST_n 参数属性的参考信息。 5.2.2.1 更改Destination属性 可以使用 ALTER SYSTEM SET 语句动态更新 LOG_ARCHIVE_DEST_n 和LOG_ARCHIVE_DEST_STATE_n 参数的大多数属性。 所有更改在Primary Database上的下一次日志切换生效。例如,要延迟Redo transport services传送redo data到名为 boston 的远程Standby Database,在Primary Database上执行下面的语句: SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=boston 2> VALID_FOR=(ONLINE_LOGFILES,PRIMARY _ROLE)'; SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER; 5.2.2.2 使用 V$ARCHIVE_DEST 查看属性 查询 V$ARCHIVE_DEST 视图以查看 LOG_ARCHIVE_DEST_n 初始化参数的当前设。 5.2.3 设置闪回恢复区--- Flash Recovery Areas Oracle 数据库允许你配置一块磁盘区域称为Flash Recovery Areas,它是一个目录或 Oracle 存储管理磁盘给,用于恢复相关文件的默认存储区域。 使用 DB_RECOVERY_FILE_DEST 初始化参数来配置Flash Recovery Areas,如果创建一个Flash Recovery Areas但没有设置任何其它的本地归档Destination,则 LOG_ARCHIVE_DEST_10 被隐式地设置为 USE_DB_RECOVERY_FILE_DEST(意味着archived redo log files将会被设置到Flash Recovery Areas)。(查看 Oracle 数据库备份和恢复基础来配置Flash Recovery Areas,以及 Oracle 数据库管理员指南以获得 Oracle 存储管理器和 Oracle 管理文件更多相关信息。) 注:存储在Flash Recovery Areas的archived redo log files的文件名是由 Oracle 管理文件(OMF)自动生成的;这些文件名不是基于由 LOG_ARCHIVE_FORMAT 初始化参数指定的格式。 本小节包含下述主题: u 使用 LOG_ARCHIVE_DEST_10 Destination u 使用其它 LOG_ARCHIVE_DEST_n Destination u 使用 STANDBY _ARCHIVE_DEST Destination u 在主和备数据之间共享Flash Recovery Areas 注:Primary Database不能写redo data到Logical Standby Database的Flash Recovery Areas。 请查看 Oracle 数据库备份和恢复基础来配置Flash Recovery Areas,以及 10.3.4 节以获得在闪回恢复区设置archived redo log files的删除策略。 5.2.3.1 使用 LOG_ARCHIVE_DEST_10 Destination 如果已经配置了Flash Recovery Areas并且没有定义本地Destination,Data Guard 隐式使用LOG_ARCHIVE_DEST_10 Destination作为Flash Recovery Areas。 当使用 LOG_ARCHIVE_DEST_10 参数时,Data Guard 自动使用所有LOG_ARCHIVE_DEST_10 属性的默认值。要覆盖默认值,通过显式指定LOG_ARCHIVE_DEST_10 参数动态设置。例如,下面的 ALTER SYSTEM SET语句在 LOG_ARCHIVE_DEST_10 初始化参数上指定了多个属性。 SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_10='LOCATION=USE_DB_RECOVERY_FILE_DEST LGWR MANDATORY REOPEN=5 VALID_FOR=(ONLINE_LOGFILES,PRIMARY _ROLE)' 当设置 LOG_ARCHIVE_DEST_n 属性时,LOG_ARCHIVE_DEST_n 参数的 TEMPLATE属性将会覆盖Flash Recovery Areas的所有其它配置,archived redo log files将会使用由 TEMPLATE 属性指定的目录和文件名。 5.2.3.2 使用其它 LOG_ARCHIVE_DEST_n设置Destination 可以显式设置一个或更多 LOG_ARCHIVE_DEST_n Destination来指向Flash Recovery Areas。在这种情况下,现有的 Data Guard 配置可能已经使用 LOG_ARCHIVE_DEST_10 Destination用作其它目的,或者可能想释放 LOG_ARCHIVE_DEST_10 Destination用作其它用途。 l 要配置其它归档Destination以指向Flash Recovery Areas而不是使用LOG_ARCHIVE_DEST_10,通过指定:LOCATION=USE_DB_RECOVERY_FILE_DEST 属性来定义新的Destination。例如: SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST ARCH MANDATORY REOPEN=5 VALID_FOR=(ONLINE_LOGFILES,PRIMARY _ROLE)' 这种情况下的隐式的配置(使用 LOG_ARCHIVE_DEST_10 参数指定Flash Recovery Areas)将会被清除。 l 配置 LOG_ARCHIVE_DEST_10 以外的Destination,用于角色转化之后 配置一个Destination,当数据库操作于Standby角色时对于Standby redo log files归档有效和配置一个Destination,当数据库操作于Primary role时对于Online redo logs(联机redo log)归档有效。因此配置 LOG_ARCHIVE_DEST_10 以外的 LOG_ARCHIVE_DEST_n Destination,必须显式指定两个Destination: LOG_ARCHIVE_DEST_9='LOCATION=USE_DB_RECOVERY_FILE_DEST ARCH MANDATORY REOPEN=5 VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)' LOG_ARCHIVE_DEST_10='LOCATION=USE_DB_RECOVERY_FILE_DEST ARCH MANDATORY REOPEN=5 VALID_FOR=(ONLINE_LOGFILES,PRIMARY _ROLE)' 5.2.3.3 使用 STANDBY _ARCHIVE_DEST Destination 在Primary Standby Database上,可以配置 STANDBY _ARCHIVE_DEST 参数来指定Flash Recovery Areas。 STANDBY _ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST' 注:由Logical Standby Database(SQL 应用)上的 STANDBY _ARCHIVE_DEST 参数所指定的闪回恢复区是被忽略的。 5.2.3.4 在Primary Database 和 Standby Database之间共享Flash Recovery Areas 在数据库之间可以共享Flash Recovery Areas,每个数据库共享的Flash Recovery Areas有唯一的数据库名,这由 DB_UNIQUE_NAME 初始化参数指定。 下面的例子是如何在Primary Database 和 Standby Database上指定初始化参数,将会在/arch/oradata 位置共享Flash Recovery Areas。虽然 DB_UNIQUE_NAME 参数没有在例子 5-3 中被指定,但是它默认为 PAYROLL,这是为 DB_NAME 初始化参数指定的名字。 例子 5-3:对于共享Flash 恢复区的Primary Database初始化参数 DB_NAME=PAYROLL LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST' DB_RECOVERY_FILE_DEST='/arch/oradata' DB_RECOVERY_FILE_DEST_SIZE=20G 例子 5-4:对于共享恢复区的Standby Database初始化参数 DB_NAME=PAYROLL DB_UNIQUE_NAME=boston LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST' STANDBY _ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST' DB_RECOVERY_FILE_DEST='/arch/oradata' DB_RECOVERY_FILE_DEST_SIZE=5G 5.3 如何send redo data 在Primary Database上,Oracle Data Guard可以使用归档进程(ARCn)或日志写进程(LGWR)来收集事务的redo data并传送到Standby Destination。虽然不能同时使用归档和日志写进程来发送Redo数据到同一Destination,但是可以选择在归档进程发送Redo数据到另外一些Destination的同时,为其它Destination使用日志写进程。 本节包含下述主题: u 使用归档进程(ARCn)来归档redo data u 使用日志写进程(LGWR)来归档redo data u 提供安全redo data传输 在网络中断之后,为了自动解决中断和重新同步,Data Guard 也使用取归档日志(FAL)客户端和服务器来发送archived redo log files到Standby Destination。FAL 进程和中断解决在 5.8 节中讨论。 5.3.1 使用归档进程(ARCn)来对redo data进行归档 在缺省情下,Redo transport services在Primary Database上使用 ARCn 进程来归档联机redo log files。在 DataGuard 配置中,ARCn 归档进程只支持最大性能级别的数据保护。必须使用 LGWR 进程来传送redo data到运行在其它保护模式中的Standby locations。(请查看 5.6 节以获得 Data Guard 数据保护模式的更多相关信息。) 下面的章节讨论了: u 控制 ARCn 归档行为的初始化参数 u ARCn 归档过程 5.3.1.1 控制 ARCn 归档行为的初始化参数 下面的描述讲述了如何使用 LOG_ARCHIVE_DEST_n 和LOG_ARCHIVE_MAX_PROCESSES 初始化参数。 允许 ARCn 进程归档到本地或远程Destination 通过初始化参数 LOG_ARCHIVE_DEST_n 上控制redo data从Primary Database自动传递到其它Destination。因为 ARCn 归档处理是默认的归档行为,所以在LOG_ARCHIVE_DEST_n 参数上指定 ARCH 属性是可选的。不要忘记,必须指定 LOCATION属性以归档到本地Destination或 SERVICE 属性以远程归档(如 5.2.2 节中描述)。 指定要调用的 ARCn 进程的数目 LOG_ARCHIVE_MAX_PROCESSES 初始化参数指定了 ARCn 进程的最大数目。Primary Database instance启动时默认启动 4 个归档进程,并且 Oracle 数据库动态调整进程的数目以平衡归档工作负载,归档进程的实际数目可能随时变化。 如果你预期到繁重的归档工作负载,可以通过设置初始化参数LOG_ARCHIVE_MAX_PROCESSES来增加归档进程的最大数目,最多 30。这个初始化参数是动态的,可以使用 ALTER SYSTEM 命令来更改,增加或减少归档进程的最大数目。 SQL> ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=20; 5.3.1.2 ARCn 归档过程 图 5-3 是在 Data Guard 配置中的归档出来的一个例子,Primary Database位于 Chicago,一个Primary Standby Database位于 Boston。 当在Primary Database上出现日志切换时发生归档时: l 在Primary Database上,在 ARC0 进程成功归档本地Online redo logs到本地Destination(LOG_ARCHIVE_DEST_1)后,ARC1 进程将本地archived redo log files(替代联机redo log files)传送Redo到远程Standby Destination(LOG_ARCHIVE_DEST_2)。 l 在远程Destination,远程文件服务进程(RFS)将从Standby redo log files依次写redo data到archived redo log files。日志应用服务(Log apply services)使用Redo接收[Redo Apply)](MRP 进程注 1)或SQL Apply [SQL 应用](LSP进程注 2)来应用Redo到Standby Database。 因为联机redo log files是首先在本地归档的,所以,LGWR 进程reuses Online redo log files比ARCn 并发归档到Standby数据库和本地Destination这种情况要早很多。 MPR进程:managed recovery process,在Physical database上应用已经归档的redo log files,并且自动地确定它启动时parallel recovery processes的数量,这个数量依赖于CPU的数量。 LSP进程:logical standby process,使用SQL引擎,并发地在Logical Standby Database端应用归档了的redo log files。 至少你需要2 个 ARCn 进程来分离本地归档与远程归档。设置 LOG_ARCHIVE_MAX_PROCESSES(默认设置是 4,但是最大值是 30)初始化参数。 图 5-3 在归档到远程Destination之前归档到本地Destination 因为默认的 ARCn 归档过程将本地归档与远程归档分离,所以节点可能有这样的策略,在归档Primary Database上的archived redo log files之后立即将其删除,则必须确保Standby Destination在Primary Database上删除archived redo log files之前接收到相应的redo data。通过查询 V$ARCHIVED_LOG 视图来检查Standby Destination是否接收到redo data。 5.3.2 使用日志写进程(LGWR)来归档redo data 可以选择允许Redo transport services使用 LGWR 进程来传送redo data到远程Destination。使用 LGWR 进程不同与 ARCn 过程(在 5.3 节中描述),因为需要等待Online redo logs在Primary Database上切换,然后写整个归档redo log到远程Destination,LGWR 进程在Standby node上选择一个Standby redo log files,来反映Primary Database的当前联机redo log files的日志序列号(和大小)。然后,只要Redo在Primary Database上生成,它也传送到远程Destination。到远程Destination的传输可以是同步的或异步的,基于在 LOG_ARCHIVE_DEST_n 参数上设置 SYNC 或 ASYNC 属性。对于 Data Guard 配置中的最大保护和最大可用性模式,同步 LGWR 过程是必需的。(查看 5.6 节以获得 Data Guard 数据保护模式的相关信息。) 本小节包含下述主题: u LGWR 归档过程相关的 LOG_ARCHIVE_DEST_n 属性 u LGWR SYNC 归档过程 u LGWR ASYNC 归档过程 5.3.2.1 LGWR 归档过程相关的 LOG_ARCHIVE_DEST_n 属性 下面小节描述了 LGWR、SYNC和 ASYNC 属性。 允许Redo transport services使用 LGWR 进程 你必须指定在 LOG_ARCHIVE_DEST_n 参数上的 LGWR 和 SERVICE 属性以允许Redo transport services使用 LGWR 进程来传送redo data到远程归档Destination。 指定异步或同步网络传输 LGWR 进程在传输redo data到远程Destination的同时同步写本地Online redo log files: l SYNC 属性同步执行所有的网络 I/O,与每次向联机redo log files写操作协作,并等待网络 I/O 完成。5.3.2.2 节显示了在 Data Guard 配置中的同步网络传输的例子。这是默认网络传输设置。 l ASYNC 属性异步执行所有网络 I/O,控制立即回到执行应用或用户,而不用等待网络 I/O 完成。5.3.2.3 节显示了在 Data Guard 配置中的异步网络传输的例子。 注:如果配置一个Destination来使用 LGWR 进程,但是由于某些原因 LGWR 进程变得无法归档到Destination了,则Redo传输将会恢复到使用 ARCn 进程来完成归档操作。 5.3.2.2 LGWR SYNC 归档过程 例子 5-5 显示了为同步网络传输配置 LGWR 进程的Primary role LOG_ARCHIVE_DEST_n参数。 例子 5-5 LGWR 同步归档相关的初始化参数 LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago' LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR SYNC NET_TIMEOUT=30' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE 在 LOG_ARCHIVE_DEST_n 参数上指定 SYNC 属性是可选的,因为这是 LGWR 归档过程的默认值。推荐使用 NET_TIMEOUT 属性,因为它控制 LGWR 进程在中断网络连接之前等待网络服务进程状态的时间长短。如果 NET_TIMEOUT 秒还没有响应,则 LGWR 进程就返回错误信息。 图5-4 显示了使用 LGWR 进程在写redo data到Primary Database上的Online redo log files的同时传送redo data到Standby system的 Data Guard 配置。 l 在Primary Database上,LGWR 进程提交redo data到一个或多个网络服务(LNSn)进程,该进程并行发起网络 I/O 到多个远程Destination直到恢复事务所需的redo data被所有 LGWR SYNC Destination接收到之后,。Primary Database上的事务才会提交。 l 在Standby system上,远程文件服务(RFS)通过网络从 LGWR 进程接收redo data,并写redo data到Standby redo log files。 当Primary Database上的日志切换触发了在Standby Database上的日志切换时,Standby Database上的 ARCn 进程归档redo log files到Standby Database上的archived redo log files。然后,Redo应用(MRP 进程)或 SQL 应用(LSP 进程)应用redo data到Standby Database。如果允许实时应用,Data Guard 在当前standby redo log files由 RFS 进程写满的同时直接从其恢复redo data。 图 5-4 LGWR SYNC 归档到使用Standby redo log files的远程Destination 5.3.2.3 LGWR ASYNC 归档过程 例子 5-6 显示了为异步网络传输配置 LGWR 进程的Primary role LOG_ARCHIVE_DEST_n参数。 例子 5-6 LGWR 异步归档相关的初始化参数 LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago' LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR ASYNC' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE 图 5-5 显示了 LNSn 进程从Online redo log files收集redo data并通过 Oracle 网络传送到Standby Database上的 RFS 进程。 当指定了 LGWR 和 ASYNC 属性,日志写进程写到本地联机redo log files,网络服务(LNSn)进程(每个Destination一个)异步传送Redo到远程Destination。LGWR 进程继续处理下一个请求而不用等待 LNS 网络 I/O 完成。 如果Redo transport services传送redo data到多个远程Destination,LNSn 进程(每个Destination一个)并行发起到所有Destination的网络 I/O。当一个Online redo log files写满了,就出现日志切换并且归档进程本地归档日志文件。 注:从 Oracle 数据库 10g 版本 10.2 开始,在同时配置 LGWR 和 ASYNC 属性的LOG_ARCHIVE_DEST_n Destination上,没有必要指定 NET_TIMEOUT 属性。这是因为在版本10.2 中日志写进程永远不会为任何原因等待 LNSn,就不需要指定 NET_TIMOUT 属性。 图 5-5 使用网络服务(LNSn)进程的 LGWR ASYNC 归档 注:不要使用 LOG_ARCHIVE_DEST 或 LOG_ARCHIVE_DUPLEX_DEST 初始化参数来指定Flash Recovery AreasDestination。 5.3.3 提供安全的redo data传输 Data Guard 提供了一个安全的环境并防止redo data在传递到Standby Database时被篡改,Redo transport services使用认证的网络会话来传递redo data,这些会话使用包含在口令文件中的 SYS 用户口令来认证。在 Data Guard 配置中的所有数据库都必须使用口令文件,并且包含在这个口令文件中的 SYS 口令在所有系统上都必须相同。这种认证即使在没有安装 Oracle Advanced Security的时候也能执行,以在运输Redo的时候提供一定级别的安全。 注:要进一步保护Redo(例如,要对跨网络的Redo 传输进行加密Redo或计算完整性校验和,不允许在网络上的Redo被篡改),Oracle 推荐你安装和使用 Oracle Advanced Security。查看 Oracle 数据库Advanced Security管理员指南。 在Primary Database和每个Standby Database上执行下面的步骤: 1. 在Primary 和所有Standby Database上创建口令文件(使用 orapwd 工具)。例如: ORAPWD FILE=orapw PASSWORD=mypassword ENTRIES=10 这个例子创建了可以输入 10 次的口令文件,在那里 SYS 的口令是 mypassword。为了成功传输redo data,对于每个Primary Database 和 Standby Database设置同样的 SYS 用户帐户口令。 2. 设置 REMOTE_LOGIN_PASSWORDFILE 初始化参数为 EXCLUSIVE 或 SHARED,以允许 Oracle 检查口令文件并指定多少数据库可以使用该口令文件。例如: REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE 5.4 应该何时发送redo data 本节包含下述主题: u 使用 VALID_FOR 属性指定基于角色的Destination u 为Primary Database 和 Standby Database指定唯一名字 5.4.1 使用 VALID_FOR 属性指定基于角色的Destination VALID_FOR 属性允许你在一个SPFILE中同时为Primary Database 和 Standby Database角色配置Destination属性,保证 Data Guard 配置在角色转换之后能正确操作。通过排除在角色转换之后允许和禁止角色相关参数文件的需求,简化了切换和failover。 指定了 LOG_ARCHIVE_DEST_n 参数的 VALID_FOR 属性,就确定了Redo transport services何时能传送redo data到基于下述要素的Destination: l 数据库当前是否运行在Primary 或standby角色 l 是否需要依赖于数据库当前角色的online redo log files,standby redo data文件,或者两者的归档, 为了为每个 LOG_ARCHIVE_DEST_n Destination配置这些要素,使用一对关键词指定这个属性:VALID_FOR=(redo_log_type, database_role)。redo_log_type 关键词标识了归档目的地对于下面的三个是有效的:ONLINE_LOGFILE、STANDBY _LOGFILE或 ALL_LOGFILES。database_role 关键词标识了当前数据库必须处于的角色,处于这些角色,Destination才是有效的:PRIMARY _ROLE、STANDBY _ROLE、或 ALL_ROLES。 如果你没有为Destination指定 VALID_FOR 属性,在默认状态下,不管数据库是什么角色,归档Online redo logs和Standby redo log files对于Destination是允许的。这种默认行为等同于在 VALID_FOR 属性上设置一对(ALL_LOGFILES, ALL_ROLES)关键字。 例如: LOG_ARCHIVE_DEST_1='LOCATION=/ARCH1/CHICAGO/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES)' 虽然(ALL_LOGFILES, ALL_ROLES)这对关键字是默认值,但是对于每个目的地并不推荐。例如,Logical Standby Database,它不同于Primary Standby Database是生成redo data并且有多种日志文件(Online redo log files、archived redo log files和Standby redo log files)的打开数据库。在大多数情况下,由Logical Standby Database生成的Online redo log files从Primary Database接收Redo的Standby redo log files是位于同一目录下的。 因此,推荐你为每个Destination定义 VALID_FOR 属性,使得你的 Data Guard 配置能在角色转换之后正确运行。请查看 12.1 节中的场景以获得对于不同 Data Guard 配置的VALID_FOR 属性的例子。 如果选择不使用 VALID_FOR 属性来配置Destination,必须对于每个数据库维护两个数据库服务器参数文件(SPFILEs):一个是对于数据库处于Primary role时,一个是对于standby role(备用角色) 。请第 12 章以获得更多配置例子。 5.4.2 为Primary Database 和 Standby Database指定唯一名字 DB_UNIQUE_NAME 属性允许你在配置Destination时指定唯一数据库名字。这使得动态添加Standby Database到包含 Real Applications Clusters Primary Database的 Data Guard 配置成为可能,当那个Primary Database操作于最大保护或最大可用性级别的保护时。如果已经定义了LOG_ARCHIVE_CONFIG 参数,则需要初始化参数 DB_UNIQUE_NAME。 注:如果在远程Destination的Standby Database没有使用 DB_UNIQUE_NAME 初始化参数确定,Standby Database必须在主instance启动之前可访问。 LOG_ARCHIVE_DEST_n 参数的 DB_UNIQUE_NAME 属性和LOG_ARCHIVE_CONFIG 参数的 DG_CONFIG 属性一起指定了 Data Guard 配置的每个数据库的唯一名字。提供的名字必须符合为使用 DB_UNIQUE_NAME 初始化参数的每个数据库的定义。 例如,下面的初始化参数显示了对在第 3 章中描述的 Data Guard 配置中的Primary Database(chicago)的 DB_UNIQUE_NAME 和 LOG_ARCHIVE_CONFIG 定义。 DB_NAME=chicago DB_UNIQUE_NAME=chicago LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago, boston)' LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES)' LOG_ARCHIVE_DEST_2= 'SERVICE=boston LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY _ROLE) DB_UNIQUE_NAME=boston' 对于使用 SERVICE 属性指定的远程Destination,需要 DB_UNIQUE_NAME 属性。在例子中,LOG_ARCHIVE_DEST_2 参数为远程Destination指定了 DB_UNIQUE_NAME=boston;Redo 传输服务在远程Destination检查这个信息。如果名字不符合,则到那个Destination的连接被拒绝。 LOG_ARCHIVE_CONFIG 参数也有 SEND、NOSEND、RECEIVE和 NORECEIVE 属性: l SEND 允许数据库发送redo data到远程Destination l RECEIVE 允许Standby Database从其它数据库接收Redo 要禁止这些设置,使用 NOSEND 和 NORECEIVE 关键词。 例如,要确保Primary Database永远不会收到任何归档redo data,在Primary Database上设置LOG_ARCHIVE_CONFIG 初始参数为 NORECEIVE,如下: LOG_ARCHIVE_CONFIG='NORECEIVE,DG_CONFIG=(chicago,boston)' 需要切记指定 NOSEND 或 NORECEIVE 属性会在角色转换之后限制数据库instance的能力。例如,如果使用 NOSEND 属性设置的Standby Database转换到Primary role,它将不能够传送Redo数据到其它Standby Database,直到你重置该参数值为 SEND。类似地,有 NORECEIVE 属性指定的数据库不能从Primary Database接收Redo。 在缺省情况下,LOG_ARCHIVE_CONFIG 参数允许Primary Database发送redo data到Standby Database并允许Standby Database从Primary Database接收Redo以用于归档。这等同于在 LOG_ARCHIVE_CONFIG 参数上同时设置 SEND 和 RECEIVE 属性。 注:LOG_ARCHIVE_CONFIG 初始化参数替代了 REMOTE_ARCHIVE_ENABLE 初始化参数,不赞成使用该参数。不要在一个 SPFILE 或文本初始化参数文件中同时指定两个参数。 5.5 如何应对可能出现错误 处理归档故障,可以使用 LOG_ARCHIVE_DEST_n 参数的 REOPEN,MAX_FAILURES和 ALTERNATE 属性来指定当向Destination的归档过程故障时应该采取什么措施。这些措施包括: l 在指定时间周期后重试向归档Destination的归档操作,直到限制数目的次数 l 使用一个预备的或替代的Destination l 控制视图重建连接的次数并重新开始发送redo data到故障的Destination 5.5.1 重试归档操作 使用 REOPEN 属性来决定是否并且何时 ARCn 进程或 LGWR 进程在错误过后试图再次传送redo data到故障的Destination。 使用 REOPEN=seconds 属性来指定在错误过后到归档进程再次尝试访问故障的Destination之前必须经过的最小秒数,默认值是 300 秒。对 REOPEN 属性设置的值应用到所有错误,而不仅仅是连接错误。通过指定 REOPEN=0 关闭该选项,这会防止Destination在故障发生后被重试。如果传送到预Standby Destination失败了并且 REOPEN 属性设置为零(0),Redo transport services将会尝试在下次redo data归档时发送redo data到预Standby Destination。 5.5.2 使用预Standby Destination ALTERNATE 属性定义一个预备的归档Destination,能够在原始归档Destination故障时被使用。如果没有指定预Standby Destination,Destination在故障时不会自动更改到其它Destination。 图 5-6 显示了redo data归档到本地磁盘设备的场景。如果原始Destination设备变满了或不可用了,归档操作会自动重指向预Standby Destination设备。 REOPEN 属性优先于 ALTERNATE 属性,预Standby Destination只有在如果下面条件之一为真时才使用: l REOPEN 属性指定为零(0)值。 l 非零 REOPEN 属性以及非零 MAX_FAILURE 计数被超过。 ALTERNATE 属性优先于 MANDATORY 属性,这意味者即使当前Destination是强制的,目的地也会failover到有效的预Standby Destination。 5.5.3 控制重试尝试的次数 使用 MAX_FAILURE 属性来指定Redo transport services尝试传送redo data到故障 Destination的连续次数的最大数目。要限制与故障Destination重新建立通讯的连续尝试的次数,要联合使用 REOPEN属性与 MAX_FAILURE 属性。一旦超过指定的连续尝试次数,Destination就被视为与 REOPEN属性设置为零。 当你使用 MAX_FAILURE 属性时需要 REOPEN 属性。例子 5-7 显示了如何设置重试时间 60 秒和重试限制 3 次。 例子 5-7:设置重试时间和限制 LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=60 MAX_FAILURE=3' 5.6 设置数据保护模式 Data Guard 提供三种数据保护模式:Maximum Protection Mode---最大保护、Maximum Availability Mode---最大可用性和Maximum Performance Mode---最大性能。 选择数据保护模式控制了,如果Primary Database丢失其到Standby Database的连接之后的行为。 本节包含下述主题: u 选择 Data Guard 保护模式 n Maximum Protection Mode n Maximum Availability Mode n Maximum Performance Mode u 如何设置 Data Guard 配置的数据保护模式 5.6.1 选择数据保护模式 首先复习一下ORACLE有关数据保护模式的说明。 5.6.2 Maximum Protection Mode 最大保护:确保如果Primary Database故障时不会发生数据丢失。要提供这种级别的保护,恢复每个会话所需的redo data必须在事务提交之前同时写到本地Online redo logs和至少一个Standby Database的Standby redo log files中。如果Primary Database无法向至少一个远程Standby redo log files写Redo stream,那么为了确保不发生数据丢失则Primary Database会关闭。对于多instance的 RAC 架构,如果无法写Redo到至少一个适当配置的数据库instance,则 Data Guard 关闭Primary Database。最大保护模式需要至少一个Standby instance有一个Standby redo log files并且在 LOG_ARCHIVE_DEST_n 参数上对于这个Destination使用 LGWR、SYNC和 AFFIRM 属性。 5.6.3 Maximum Availability Mode 最大可用性:提供了在保证Primary Database的可用下,可能的最高级别的数据保护。如同最大保护模式,事务要等到恢复该事务所需的Redo写到本地Online redo logs和至少一个远程Standby redo log files成功后才会提交。与最大保护模式的区别是,如果故障导致Primary Database无法写其Redo流到远程Standby redo log files,Primary Database不需要关闭,此时Primary Database运行于最大性能模式直到解除故障并且解决所有redo log files中的中断。当解决所有中断后,Primary Database自动继续运行于最大可用性模式。 这种模式确保即使Primary Database故障也不会发生数据丢失,但是它的前提条件是:只有在第二次故障没有阻止完整的redo data集从Primary Database发送到至少一个Standby Database的情况下。 如同最大保护模式,最大可用性模式需要: l 至少在一个Standby Database上配置Standby redo log files。 l 为至少 1 个Standby Database设置 LOG_ARCHIVE_DEST_n 参数的 LGWR、SYNC和AFFIRM 属性。 5.6.4 Maximum Performance Mode 最大性能:这是Data Guard中的默认模式,它在不影响Primary Database的性能的前提下提供了可能的最高级别的数据保护,这是通过允许事务在恢复该事务所需的redo data一写到本地Online redo logs就提交来实现的。Primary Database的redo data流也写到至少一个Standby Database,但是那个Redo流相对于创建redo data的事务的提交是异步的。当使用足够带宽的网络连接时,这种模式提供了接近最大可用性模式而对Primary Database性能影响最小的数据保护级别。 最大性能模式允许你在 LOG_ARCHIVE_DEST_n 参数上对于Standby DatabaseDestination设置LGWR 和 ASYNC 属性,或设置 ARCH 属性。如果Primary Database故障,通过设置 LGWR 和ASYNC 属性来减少Standby Destination上未接收到的数据量。 5.6.5 设置 Data Guard的数据保护模式 要设置Redo transport services和指定对于 Data Guard 配置的数据保护级别,参照以下步骤。 第 1 步:在Primary Database上配置 LOG_ARCHIVE_DEST_n 参数。 在Primary Database上配置 LOG_ARCHIVE_DEST_n 参数,每种 Data Guard 数据保护模式在配置中需要至少一个 Standby Database,以满足在表 5-2 中列出的最小需求。 Table 5–2 Minimum Requirements for Data Protection Modes: Maximum Protection Maximum Availability Maximum Performance Redo archival process Redo归档进程 LGWR LGWR LGWR or ARCH Network transmission mode 网络传输模式 SYNC SYNC SYNC or ASYNC when using LGWR process. 当使用 LGWR 进程时为 SYNC 或 ASYNC SYNC if using ARCH process 如果使用 ARCH 进程则 SYNC Disk write option 磁盘写选项 AFFIRM AFFIRM AFFIRM or NOAFFIRM Standby redo log required? 是否需要Standby redo log files Yes Yes No, but it is recommended Oracle 推荐运行在最大保护模式的 Data Guard 配置包含至少两个满足表 5-2 中所列需求的Standby Database,这样可以保证在Standby Database之一不能从Primary Database接收redo data时,Primary Database可以继续运行。 下面的例子显示了如何配置最大可用性模式: SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=chicago 2> OPTIONAL LGWR SYNC AFFIRM 3> VALID_FOR=(ONLINE_LOGFILES,PRIMARY _ROLE) 4> DB_UNIQUE_NAME=chicago'; 应当在SPFILE中指定DB_UNIQUE_NAME,以及在使用 DG_CONFIG 属性的 LOG_ARCHIVE_CONFIG 上列出所有数据库。 SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)' 将会允许动态添加一个Standby Database到一个运行在最大保护或最大可用性模式中的Real Application Cluster 主数据库的 Data Guard 配置中。 第 1 步:如果升级保护模式,执行这个步骤。 只有升级保护模式才执行这个步骤(例如,从最大性能切换到最大可用性模式),否则跳到步骤 3,假定这个例子是升级 Data Guard 配置从最大性能模式到最大可用性模式。 重启主数据库到mount模式: SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; 对于 Real Application Clusters 数据库,关闭所有的主instance但只启动并mout一个主instance。 第 2 步:设置数据保护模式。 要指定一种数据保护模式,在Primary Database上执行 SQL ALTER DATABAE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE}语句。例如,下面的语句指定了最大可用性模式: SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY; 第 3 步:打开Primary Database。 如果你执行步骤 1 来升级保护模式,打开数据库: SQL> ALTER DATABASE OPEN; 如果你是降级保护模式,则数据库已经打开。 第 4 步:在Standby Database上配置 LOG_ARCHIVE_DEST_n 参数。 在Standby Database上,配置 LOG_ARCHIVE_DEST_n 参数属性使得配置能在切换过后继续操作在新的保护模式。 例如: SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=boston 2> OPTIONAL LGWR SYNC AFFIRM 3> VALID_FOR=(ONLINE_LOGFILES,PRIMARY _ROLE) 4> DB_UNIQUE_NAME=boston'; 第 5 步:确认配置操作在新的保护模式。 查询 V$DATABASE 视图以确认 Data Guard 配置操作在新的保护模式。例如: SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE; PROTECTION_MODE PROTECTION_LEVEL --------------------- --------------------- MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY 5.7 管理日志文件 本节包含下述主题: u 为archived redo log files指定预备目录 u Reuse online redo log files u 管理Standby redo log files u Plan for控制文件的增长和reuse u 在多个Standby Database之间共享日志文件 5.7.1 为archived redo log files指定预备目录 在典型的情状态下,当从Primary Database接收到redo data,redo data是写到归档redo log中的,存储在由 LOG_ARCHIVE_DEST_n 参数的 LOCATION 属性所指定的目录。作为选择,在Standby Database上指定 STANDBY _ARCHIVE_DEST 初始化参数来指示一个预备的目录,归档Redo日志文件能在从Primary Database接收后存放在那里。 如果同时指定了两个参数,STANDBY _ARCHIVE_DEST 初始化参数覆盖了LOG_ARCHIVE_DEST_n 参数指定的目录位置。archived redo log files在Standby Database上存储的位置由下述规则列表决定。当数据库instance启动时,archived redo log files以列表中顺序评估: 1. 如果在Standby Database上指定了 STANDBY _ARCHIVE_DEST 初始化参数,则使用那个位置。 2. 如果 LOG_ARCHIVE_DEST_n 参数包含了 VALID_FOR=(STANDBY _LOGFILE, *)属性,则使用对这个Destination指定的位置。 3. 如果 COMPATIBLE 参数设为 10.0 或更高,并且没有一个 LOG_ARCHIVE_DEST_n参数包含 VALID_FOR=(STANDBY _LOGFILE, *)属性,则使用任意一个有效的LOG_ARCHIVE_DEST_n 参数。 4. 如果没有指定任何一个初始化参数,则archived redo log files存储在对于STANDBY _ARCHIVE_DEST 初始化参数的默认位置。要查看 STANDBY _ARCHIVE_DEST 初始化参数的隐式默认值,查询V$ARCHIVE_DEST 视图: SQL> SELECT DEST_NAME, DESTINATION FROM V$ARCHIVE_DEST 2> WHERE DEST_NAME='STANDBY _ARCHIVE_DEST'; DEST_NAME ----------------------------------------------------------------- DESTINATION ----------------------------------------------------------------- STANDBY _ARCHIVE_DEST /oracle/dbs/arch Redo transport services联合使用 STANDBY _ARCHIVE_DEST 初始化参数与LOG_ARCHIVE_FORMAT 参数指定的值来在Standby node生成archived redo log files的文件名。例如: STANDBY _ARCHIVE_DEST='/arc_dest/arls' LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc 在上面的例子中,%s 相应于序列号,%r 相应于重置日志 ID。这些一起确保跨多数据的 archived redo log files能有唯一名字。%t 是 Real Application Clusters 配置所需要的,相应于线程号。 对于Primary Standby Database,Redo transport services在Standby Database控制文件中存储全限定文件名,并且重做应用使用这个信息在Standby Database上执行恢复。 注: 如果你指定了 LOG_ARCHIVE_DEST_n 参数的 TEMPLATE 属性,它会覆盖由STANDBY _ARCHIVE_DEST 和 LOG_ARCHIVE_FORMAT 参数生成的文件名。查看第 14章以获得 TEMPLATE 属性相关信息。 要显示在Standby system上的archived redo log files的列表,在Standby Database上查询V$ARCHIVED_LOG 视图: SQL> SELECT NAME FROM V$ARCHIVED_LOG; NAME ----------------------------------------------------------------- /arc_dest/log_1_771.arc /arc_dest/log_1_772.arc /arc_dest/log_1_773.arc /arc_dest/log_1_774.arc /arc_dest/log_1_775.arc 5.7.2 Reuse online Redo log files 你可以使用设置 LOG_ARCHIVE_DEST_n 参数的 OPTIONAL 或 MANDATORY 属性来指定Reuse online redo log files的策略。远程Destination默认被设置为 OPTIONAL。可选Destination的归档操作可以失败,并且即使传送redo data和写日志内容没有成功,联机redo log files也能被重用。如果强制Destination的归档操作失败了,联机redo log files不能被覆盖,直到向强制Destination的失败归档完成。 默认地,即使你指定所有的Destination都为可选的,也有一个本地Destination是强制的。例子 5-8 显示了如何设置强制本地归档Destination,并允许那个Destination。当指定MANDATORY 属性时,也要考虑在 5.5 节中描述的 REOPEN 和 MAX_FAILURE 属性来处理故障情况。 例子 5-8:设置强制归档Destination LOG_ARCHIVE_DEST_3 = 'LOCATION=/arc_dest MANDATORY' 5.7.3 管理Standby redo log files 本小节包含下述主题: u 确定Standby redo log files组配置是否适当 u 添加Standby redo log files成员到现有的组 5.7.3.1 确定Standby redo log files组配置是否适当 检验Standby redo log files有合适数目的日志文件组,最简单的方法是检查 RFS 进程跟踪文件和数据库警告日志。如果两个日志都包含显示 RFS 进程频繁地因为归档没有完成而等待组, 则添加更多日志文件组到Standby redo log files。额外的Standby redo log files组给归档操作足够的时间在RFS 进程重用Standby redo log files之前完成。 注意: 不管何时你添加一个联机redo log files组到Primary Database,你必须添加一个相应的备Redo日志文件组到Standby Database。如果Standby redo log files组的数目不适当,Primary Database如果操作于最大保护模式将会关闭,如果操作于最大可用性模式将会切换到最大性能模式。 5.7.3.2 添加Standby redo log files成员到现有的组 在一些案例中,可能没有必要创建一个完整的Standby redo log files组。一个组可能已经存在,因为一个或更多成员被删除了(例如,因为磁盘故障),可能不完整。在这个案例中,可以添加新的成员到现有的组。 要添加新成员到一个Standby redo log files组,使用带 ADD STANDBY LOGFILE MEMBER子句的 ALTER DATABASE 语句。下面的语句添加一个新成员到 2 号Standby redo log files组: SQL> ALTER DATABASE ADD STANDBY LOGFILE MEMBER '/disk1/oracle/dbs/log2b.rdo' 2> TO GROUP 2; 使用新成员的全限定文件名来指出文件应该创建在何处。否则,文件将会被创建在数据库的默认或当前目录,依赖于你的操作系统。 5.7.4 为控制文件的增长和重用而计划 本小节描述: l 设置包含控制文件的磁盘容量的大小 l 指定控制文件中记录的重用 5.7.4.1 设置包含控制文件的磁盘卷的大小 随着生成的archived redo log files和进行的 RMAN 备份,Oracle 添加新的记录到控制文件的可重用部分。如果没有可用于重用的记录(因为所有的记录还处于由CONTROL_FILE_RECORD_KEEP_TIME 指定的天数之内),则控制文件会扩展,新的记录被添加到控制文件中。 最大的控制文件大小是 20000 个数据库块。如果 DB_BLOCK_SIZE 等于 8192,则最大的控制文件大小是 156MB。如果控制文件是存储在预先创建的卷中,则包含主与备控制文件的卷应该大小能容纳最大尺寸的控制文件。如果控制文件卷太小并且不能扩展,则在控制文件中的现有记录在它们的预期的重用之前将被覆盖。这种行为通过在警告日志中的下述信息来指出: 5.7.4.2 指定控制文件中记录的重用 CONTROL_FILE_RECORD_KEEP_TIME 初始化参数指定了控制文件中可重用的记录能被重用之前必须经过的最小天数。适当地设置这个参数预防Redo transport services覆盖控制文件中的可重用记录,并且确保Redo信息在Standby Database上保持可用。 设置 CONTROL_FILE_RECORD_KEEP_TIME 为一个值,允许所有在磁盘上的备份信息保留在控制文件中。CONTROL_FILE_RECORD_KEEP_TIME 指定记录在成为候选于重用之前在控制文件中保留的天数。 设置 CONTROL_FILE_RECORD_KEEP_TIME 为一个值,比你打算保留在磁盘上最早的备份文件稍微长一点,由备份区域的大小来确定。 例如,如果备份区域大小设置为维护每 7 天进行的两个全备份,每天的增量备份和archived redo log files也是这样,则设置 CONTROL_FILE_RECORD_KEEP_TIME 的值为 21 或 30。比这个更旧的记录将被重用。然而,备份元数据在 RMAN 恢复目录中将还是可用的。 如果对Standby Database设置了应用延迟(在 6.2.2 节中描述),确保你指定一个足够大的值。这个参数的值的范围从 0 到 365 天。默认值是 7 天。 查看 Oracle 数据参考以获得 CONTROL_FILE_RECORD_KEEP_TIME 初始化参数的更多相关细节,和 Oracle 数据库备份和恢复高级用户指南。 5.7.5 在多个Standby Database之间共享日志文件Destination 使用 LOG_ARCHIVE_DEST_n 初始化参数的 DEPENDENCY 属性来定义一个归档目的地代表多个Destination接收redo data,而不是传送redo data到每个单独的Destination。 图 5-7 显示了一个 Data Guard 配置,在这里面Primary Database传送redo data到一个归档目的地,同时共享其archived redo log files给一个Logical Standby Database和一个Primary Standby Database。这些Destination依赖于向父Destination的归档操作的成功。 指定Destination依赖性在下面的情况下可能是很有用的: 当你在同一系统配置一个Primary Standby Database和一个Logical Standby Database时。 当你在同一系统配置Standby Database和Primary Database时。因此,archived redo log files对于Standby数据库是隐式可访问的。 当使用集群文件系统来提供远程Standby Database对于Primary Database的archived redo log files的访问时。 当使用操作系统相关的网络文件系统时,提供远程Standby Database对于Primary Database归档重做日志文件的访问。 例如,假设有两个Standby Database stby1 和 stdby2 位于硬件的同一片上。不需要使用网络带宽和磁盘空间来发送同一redo data到两个Destination。如果你使用 DEPENDENCY 属性来指定其中一个Destination作为一个依赖Destination,数据库能共享同一archived redo log files。那就是说,主数据库发送要归档的Redo到没有定义为依赖Destination的Destination。如果redo data成功到达那个目的地,Primary Database认为其归档到了两个Destination。例如: LOG_ARCHIVE_DEST_1='LOCATION=DISK1 MANDATORY' LOG_ARCHIVE_DEST_2='SERVICE=stdby1 OPTIONAL' LOG_ARCHIVE_DEST_3='SERVICE=stdby2 OPTIONAL DEPENDENCY=LOG_ARCHIVE_DEST_2' 使用这些定义的参数,Primary Database传送redo data到 stdby1 而不到 stdby2。stdby2 数据库改为从传输到 stdby1 的archived redo log files来恢复Redo。 同时查看:DEPENDENCY 属性 5.8 管理归档GAP(差距) 如果Standby system没有接收到一个或多个Primary Database生成的archived redo log files,在Standby system上就会出现归档之间的差距。丢失的archived redo log files就是中断。如果有中断,则 Data Guard 自动探测到并通过拷贝丢失的日志文件序列到Standby Destination来解决。例如,当网络变得不可用时,从主数据库到Standby Database的自动归档临时停止,就会出现归档中断。当网络再次可用时,从主数据库到故障的Standby Database的redo data的自动传输继续。 Data Guard 不需要 DBA 的手工干预来探测和解决这样的中断。下面的小节描述了中断探测和解决。 5.8.1 何时发现归档中断? 无论何时Primary Database本地归档一个日志,但是Standby node没有接受到该日志就会发生归档中断。每分钟,Primary Database调查其Standby Database以查看是否在archived redo log files的序列中有中断。 5.8.2 如何解决中断? 中断恢复通过轮询机制解决。对于Primary 和Logical Standby Database、Oracle Change Data Capture 、和 Oracle Streams,Data Guard 通过自动从Primary Database检索丢失的archived redo log files来执行中断探测和解决。不需要额外的配置设置来调查Standby Database,来探测任何中断或解决中断。 这里很重要的考虑是自动中断恢复是依Primary Database的可用性而定的。如果Primary Database不可用了,并且你配置了多个Primary Standby Database,You can设置额外的初始化参数使得Redo应用能从其它Standby Database解决归档中断,如 5.8.3 节中描述。 查看 12.11 节以获得显示如何手工解决中断的场景。 注:在 Oracle 数据库 10g 版本 1 以前,FAL 客户端和服务器用于从Primary Database解决中断。 5.8.3 使用取归档日志(FAL)来解决归档差距 取归档日志(FAL)客户端和服务期解决在Primary Database生成的与Primary Standby Database接收到的归档redo log files的范围中探测到的差距。 FAL 客户单自动请求archived redo log files的传递。 FAL 服务期服务从 FAL 客户端来的 FAL 请求。 FAL 机制处理下述类型的归档中断和问题: 当创建一个Primary 或Logical Standby Database时,FAL 机制能自动检索在Primary Database的热备期间生成的任何archived redo log files。 当有在Standby Database上已经有接收到的archived redo log files的问题时,FAL 机制能自动检索archived redo log files来解决任何下述情况: 当archived redo log files在应用到standby 数据之前被从磁盘删除。 当archived redo log files因为磁盘损坏不能应用。 当archived redo log files在redo data应用到被数据库之前,意外被不是归档Redo日志文件的其它文件替换(例如,一个文本文件)。 当你有多个Primary Standby Database,FAL 机制能从其它Primary Standby Database自动检索丢失的归档redo log files。 FAL 客户端和服务期使用在Standby Database上设置的 FAL_CLIENT 和 FAL_SERVER 初始化参数来配置。在初始化参数文件中定义的 FAL_CLIENT 和 FAL_SERVER 初始化参数只针对于Primary Standby Database,如下表中所示: 在一些情况下,自动中断恢复可能不会发生,你将会需要手工执行中断恢复。例如, 如果你使用Logical Standby Database并且Primary Database不可用时,你将需要手工执行中断恢复。下面的小节描述了如何查询适当的视图以确定哪个日志文件丢失了并且执行手工恢复。 在Primary Standby Database: 要确定在你的Primary Standby Database上是否有归档中断,查询 V$ARCHIVE_GAP 视图,如下面例子所示: SQL> SELECT * FROM V$ARCHIVE_GAP; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ----------- ------------- -------------- 1 7 10 前面例子的输出指出你的Primary Standby Database当前丢失日志文件从线程 1 的序号 7 到序号 10。 在你确定Primary与Standby之间的归档差距后,在Primary Database上执行下面的 SQL 语句来在Primary Database上定位归档所对应的Redo日志文件。 (假设在Primary Database上的本地归档Destination是 LOG_ARCHIVE_DEST_1): SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 2> AND SEQUENCE# BETWEEN 7 AND 10; NAME ----------------------------------------------------------------- /Primary /thread1_dest/arcr_1_7.arc /Primary /thread1_dest/arcr_1_8.arc /Primary /thread1_dest/arcr_1_9.arc 拷贝这些日志文件到Primary Standby Database并在Primary Standby Database上使用 ALTER DATABASE REGISTER LOGFILE 语句来注册它们。例如: SQL> ALTER DATABASE REGISTER LOGFILE '/physical_Standby 1/thread1_dest/arcr_1_7.arc'; SQL> ALTER DATABASE REGISTER LOGFILE '/physical_Standby 1/thread1_dest/arcr_1_8.arc'; 在Primary Standby Database上注册这些日志文件之后,可以重启Redo应用。 注: Primary Standby Database上的 V$ARCHIVE_GAP 固定视图只返回当前妨碍Redo应用继续的下一个中断。在解决中断并重启Redo应用后,再次在Primary Standby Database上查询 V$ARCHIVE_GAP 固定视图来确定下一个中断序号,如果有的话。重复这个过程直到没有更多的中断。 在Logical Standby Database: 要确定是否有归档中断,在Logical Standby Database上查询 DBA_LOGSTDBY_LOG 视图。例如,下面的查询指出在archived redo log files的序号中有中断,因为它在Logical StandBy database上对于THREAD1 显示有两个文件。(如果没有中断的话,查询应该每个线程只显示一个文件。)输出显示最高的注册文件是序列号 10,但是在所示文件序列号 6 有中断: SQL> COLUMN FILE_NAME FORMAT a55 SQL> SELECT THREAD#, SEQUENCE#, FILE_NAME FROM DBA_LOGSTDBY_LOG L 2> WHERE NEXT_CHANGE# NOT IN 3> (SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#) 4> ORDER BY THREAD#,SEQUENCE#; THREAD# SEQUENCE# FILE_NAME --------- ---------- --------------------------------------------- 1 6 /disk1/oracle/dbs/log-1292880008_6.arc 1 10 /disk1/oracle/dbs/log-1292880008_10.arc 拷贝丢失的日志文件,序列号 7、8 和 9,到逻辑Standby system,并在你的Logical Standby Database上使用 ALTER DATABASE REGISTER LOGICAL LOGFILE 语句来注册它们。 例如: SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE '/disk1/oracle/dbs/log-1292880008_10.arc'; 在你在Logical Standby Database上注册这些日志文件之后,You can重启 SQL 应用。 注:在Logical Standby Database上的 DBA_LOGSTDBY_LOG 视图只返回当前妨碍 SQL 应用继续的下一个中断。在解决指定的中断并重启 SQL 应用之后,再次在Logical Standby Database上查询DBA_LOGSTDBY_LOG 视图以确定下一个中断序号,如果有的话。重复这个过程直到没有更多的中断。 5.9 核查 本节包含下述主题: u 监控日志文件归档信息 u 监控Redo transport services的性能 5.9.1 监控日志归档信息 本小节描述使用视图来对Primary Database监控redo log归档活动。查看 Oracle Data Guard Broker 和 Oracle 企业管理器联机帮助以获得图形用户界面的更多相关信息,用于自动化包含在监控 Data Guard 环境中的许多任务。 第 1 步 确定redo log files的状态。 在Primary Database上属性下面的查询以确定所有联机redo log files的状态: SQL> SELECT THREAD#, SEQUENCE#, ARCHIVED, STATUS FROM V$LOG; 第 2 步 确定最近的archived redo log files。 在Primary Database上输入下面的查询以确定最近的归档线程和序列号: SQL> SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG GROUP BY THREAD#; 第 3 步 确定在每个Destination的最近的archived redo log files。 在Primary Database上输入下面的查询以确定哪个archived redo log files是最近地传送到每个归档Destination: SQL> SELECT DESTINATION, STATUS, ARCHIVED_THREAD#, ARCHIVED_SEQ# 2> FROM V$ARCHIVE_DEST_STATUS 3> WHERE STATUS <> 'DEFERRED' AND STATUS <> 'INACTIVE'; DESTINATION STATUS ARCHIVED_THREAD# ARCHIVED_SEQ# ------------------ ------ ---------------- ------------- /private1/prmy/lad VALID 1 947 Standby 1 VALID 1 947 最近写的archived redo log files对于每个列出的归档Destination应该是相同的。如果不同,则VALID 以外的状态可能确定在向那个Destination的归档操作过程中遇到了错误。 第 4 步 找出archived redo log files是否已经被接收到。 可以在Primary Database上执行一个查询来找出archived redo log files是否在一个特定的节点没有被接收到。每个Destination有一个相关的 ID 号。You can在Primary Database上查询 V$ARCHIVE_DEST 固定视图的 DEST_ID 列来确定每个Destination的 ID 号。 假设当前本地Destination是 1,远程Standby Destination之一的 ID 是 2。要确定在Standby Destination上哪个日志文件丢失了,执行下面的查询: SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM 2> (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) 3> LOCAL WHERE 4> LOCAL.SEQUENCE# NOT IN 5> (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND 6> THREAD# = LOCAL.THREAD#); THREAD# SEQUENCE# --------- --------- 1 12 1 13 1 14 查看附录 A 以获得监控Primary Database的归档状态的细节。 第 5 步 在Standby node跟踪传送日志的过程。 要查看redo data传输到Standby Destination的过程,在主和备初始化参数文件中设置LOG_ARCHIVE_TRACE 参数。查看附录 G 以获得完整的细节和例子。 5.9.2 监控Redo transport services的性能 本小节描述了监控Redo transport services的性能的等待事件,这些服务由Primary Database上的LOG_ARCHIVE_DEST_n 初始化参数上的 ARCH、LGWR、SYNC和 ASYNC 属性指定。 下面的小节描述了等待事件和由 V$SYSTEM_EVENT 视图显示的相关时间信息。 u ARCn 进程等待事件 u LGWR SYNC 等待事件 u LGWR ASYNC 等待事件 5.9.2.1 ARCn 进程等待事件 对于 ARCn 归档过程,表 5-3 显示了多个等待事件,当为传输模式使用 ARCH 时,监控产生或删除 RFS 连接和发送redo data到Standby Database所花的时间。查看 5.3.1 节以获得 ARCn归档过程的相关信息。 表 5-3 对配置 ARCH 属性的Destination的等待事件 ARCH 等待 ATTACH:所有 ARCn 进程产生一个 RFS 连接。 ARCH 等待 SENDREQ:所有 ARCn 进程既打开和关闭远程archived redo log files,也写将所接收的redo data写到磁盘。 ARCH 等待 DETACH:所有 ARCn 进程删除一个 RFS 连接。 5.9.2.2 LGWR SYNC 等待事件 对于 LGWR SYNC 归档过程,表 5-4 显示了多个等待事件,监控 LGWR 进程在主数据库上花费时间: 在Primary Database上完成写online redo log files 传送redo data到远程Standby Destination 等待要写到Standby redo log files的redo data 从远程Standby Destination接收应答 查看 5.3.2 节以获得 LGWR SYNC 归档过程相关信息。 5.9.2.3 LGWR ASYNC 等待事件 对于 LGWR ASYNC 归档过程,表 5-5 显示了多个等待事件,监控在Primary Database上写重做数据到联机redo log files所花的事件。查看 5.3.2 节以获得 LGWR ASYNC 归档过程的相关信息。 6 Log apply servvices:日志应用服务 本章描述redo data如何应用到Standby Database。包含下述主题: u 日志应用服务介绍 u 日志应用服务配置选项 u 应用redo data到Primary Standby Database u 应用redo data到Logical Standby Database 6.1 日志应用服务介绍 日志应用服务自动应用接收到的Redo data到Standby Database,以维护与Primary Database的同步并允许对数据库的事务一致性访问。 在默认情况下,日志应用服务在应用archived redo log files到Standby Database之前等待完全的归档Redo日志文件到达Standby Database。5.3.1 节和 5.3.2 节描述了从Primary Database传送的redo data如何被Standby system上的远程文件服务进程(RFS)接收,在那里 RFS 进程写redo data到archived redo log files或standby redo log files。然而,如果你使用Standby redo log files,You can允许实时应用,这允许 Data Guard从正在被 RFS 进程写的当前Standby redo log files恢复redo data。实时应用在 6.2.1 节中更详细地描述。 日志应用服务使用下面的方法来维护Primary 和Logical Standby Database: u Redo应用(只有Primary Standby Database) Redo Apply的机制是使用Media recovery来保持Primary Database和Primary Standby Database之间的同步。 注意: 你也能以只读模式打开Primary Standby Database,允许用户查询Standby Database 用作报表用途。在Standby Database打开的时候,还是在接收redo data的;但是,Redo应用停止并且Primary Standby Database没有与Primary Database保持同步。如果在此时间发生故障,会延长failover操作完成所需的时间。请查看 8.2 节,“打开standby数据库以用于只读或读/写访问”以获得更多信息。 u SQL 应用(只在Logical Standby Database上使用) 从Primary Database接收的Redo重组 SQL 语句并在Logical Standby Database上执行 SQL 语句。 Logical Standby Database能以读/写模式打开,但是由Logical Standby Database维护的目标表只能以只读模式打开以用于报表用途(倘若数据库 guard 适当设置)。SQL 应用允许你使用逻辑Standby数据库用于报表活动,即使当 SQL 语句被应用时。 本章的小节更详细地描述了Redo应用、SQL 应用、实时应用和延迟应用。 6.2 日志应用服务配置选项 本节包含下述主题: n 使用实时应用来立即应用redo data n 对archived redo log files的应用指定时间延迟 6.2.1 使用实时应用来立即应用redo data 如果允许了实时应用(Real time apply)特性,日志应用服务能在接收redo data时立即应用,而不用等待当前Standby redo log files归档。这导致更快的切换和failover时间,因为Standby redo log files在failover或切换开始的时候已经应用到Standby Database。 使用 ALTER DATABASE 语句来允许实时应用特性: 对于Primary Standby Database,执行 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE 语句。 对于Logical Standby Database,执行 ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE 语句。 在设置使用实时应用redo data类型后,需要Standby redo log files。 图 6-1 显示了使用本地Destination和Standby Destination的 Data Guard 配置。当远程文件服务(RFS)进程在Standby Database上写redo data到Standby redo log files时,日志应用服务能从正在被写的Standby redo log files文件恢复Redo。 图 6-1 使用实时应用应用redo data到Standby Destination 6.2.2 对archived redo log files的应用指定时间延迟 在一些情况下,你可能想在redo data从主节点接收到它应用到Standby Database的时间之间创建一个时间延迟。可以指定时间间隔(分钟)来保护损坏或错误的数据的应用到Standby Database,当你设置 DELAY 间隔,它不是延迟redo data的传输到Standby Database。而是根据指定的时间将redo data完整地归档到Standby Destination设置一个时间延迟。 注:如果你定义对一个允许实时应用的Destination的延迟,则该延迟被忽略。 指定时间延迟: 你可以使用 LOG_ARCHIVE_DEST_n 初始化参数的 DELAY=minutes 属性,在Primary和Standby数据库上设置时间延迟来延迟应用archived redo log files到Standby Database。 默认情况下,是没有时间延迟的。如果你指定 DELAY 而没有指定一个值,则默认的延迟间隔是 30 分钟。 取消时间延迟: 对于Primary Standby Database,使用 RECOVER MANAGED STANDBY DATABASE 字句的NODELAY 关键词: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY; 对于Logical Standby Database,指定下面的 SQL 语句: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY; 这些命令导致日志应用在时间间隔过后,立即开始应用archived redo log files到Standby Database。 其它资料请,查看:12.8 节,“使用带时间延迟的Primary Standby Database” Oracle 数据库 SQL 参考,ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 语句的 DELAY 属性 6.2.2.1 使用 Flashback 数据库作为设置时间延迟的另一选择 作为设置应用延迟的另一选择,你可以使用 Flashback 数据库来从损坏或错误数据的应用中恢复到Standby Database。Flashback 数据库能快速、简单地闪回Standby Database到一个任意的时间点。 查看第 12 章以获得显示如何使用带 Flashback 数据库的 Data Guard,以及 Oracle 数据库备份和恢复基础以获得允许及使用 Flashback 数据库的更多相关信息。 6.3 应用redo data到Primary Standby Database 在默认情况下,redo data从archived redo log files被应用。当执行Redo apply时,Primary Standby Database能使用实时应用特性来从正在被 RFS 进程写的Standby redo log files直接应用Redo。注意当Primary Standby数据库以只读模式打开时日志应用服务不能应用redo data。 本节包含下述主题: n 开始Redo应用 n 停止Redo应用 n 在Primary Standby Database上监控Redo应用 6.3.1 开始Redo应用 要在Primary Standby Database上开始日志应用服务,要确保Primary Standby Database is started and mounted,然后使用 SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 语句来开始Redo应用。注意这个工作是在Standby Database上进行的,不要搞错了。 即可以指定Redo应用作为前台会话又可以指定它为后台进程运行,并允许它实时Apply。 要在前台开始Redo应用,执行下面的 SQL 语句: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE; 如果你开始一个前台会话,控制不会返回到命令提示符,直到恢复被其它会话取消了。 要在后台开始Redo应用,在 SQL 语句中包括 DISCONNECT 关键词。例如: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; 这条语句开始了一个分离的服务进程并立即返回控制到用户。当管理恢复进程在后台执行恢复的时候,执行 RECOVER 语句的前台进程仍能继续执行其它任务,这不会断开当前的 SQL 会话。 要开始实时应用,在 SQL 语句上要包含 USING CURRENT LOGFILE 字句。例如: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE; 6.3.2 停止Redo应用 要停止Redo应用,在其它窗口执行下面的 SQL 语句: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 6.3.3 在Primary Standby Database上监控Redo应用 要监控在Primary Standby Database上的日志应用服务,请查看 8.5.4 节。你也可以使用 Oracle 企业管理器监控Standby Database。同时,查看 Oracle 数据库参考以获得视图的完整参考信息。 6.4 应用redo data到Logical Standby Database SQL Apply从归档redo log或Standby redo log files转换数据到 SQL 语句,然后在Logical Standby Database上执行这些 SQL 语句。因为Logical Standby Database是始终保持打开,维护的表能同时用于其它任务,如报表、总结和查询。 本节包含下述主题: u Starting SQL Apply u 在Logical Standby Database上停止 SQL 应用 u 在Logical Standby Database上监控 SQL 应用 6.4.1 Starting SQL Apply 要开始 SQL Apply,启动Logical Standby Database后并执行下面语句: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY; 要在Logical Standby Database上开始实时应用,在Logical Standby Database上立即应用从Standby redo log files的redo data,如下面语句所示包含 IMMEDIATE 关键词: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 6.4.2 在Logical Standby Database上停止 SQL 应用 要停止 SQL Apply,在Logical Standby Database上执行下面语句: SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; 执行该语句后,SQL Apply将等待直到它提交了所有在应该过程中完成的事务。这样,该命令可能不能立即停止 SQL 应用进程。如果你想立即停止 SQL 应用,执行下面语句: SQL> ALTER DATABASE ABORT LOGICAL STANDBY APPLY; 6.4.3 在Logical StandBy database上监控 SQL 应用 要监控 SQL 应用,查看 9.2 节。也可以使用 Oracle 企业管理器监控Standby Database。查看附录 A,“解决 Data Guard 故障”和 Oracle Data Guard Broker。 同时,查看在 8.5.4.3 节中的 V$ARCHIVE_DEST_STATUS 固定视图的相关讨论和 Oracle 数据库参考以获得视图相关的完整参考信息。 7 角色转换 Data Guard 配置包含一个数据库作为Primary role以及一个或更多数据库作为Standby role(备用角色)。在典型的情况下,每个数据库的角色不会更改。然而,如果 Data Guard 是用于维护对Primary Database停机时提供响应的服务时,你就必须在配置中发起当前Primary Database和一个Standby Database之间的角色转换。要查看数据库的当前角色,查询 V$DATABASE 视图中的 DATABASE_ROLE 列。 在 Data Guard 配置中的Standby Database的数量、位置和类型(Physical 或 Logical),以及redo data以哪种方式从Primary Database传送到每个Standby Database,这些都决定了你用于响应Primary Database停机可用的角色管理选项。 本章描述了如何在 Data Guard 配置中管理角色转换。包含下述主题: u 角色转换介绍 u 包含Primary Standby Database的角色转换 u 包含Logical Standby Database的角色转换 u 在角色转换之后使用闪回数据库 在本章中描述的角色转换使用 SQL 语句手工调用。你也可以使用 Oracle Data Guard broker来简化角色转换和自动化failover。 同时请参照: Oracle Data Guard Broker 以获得使用 Oracle Data Guard broker 的相关信息: 通过允许你使用在 Oracle 企业管理器中单键点击或 DGMGRL 命令行界面中的单条命令简化切换和failover。 当Primary Database变得不可用时,允许快速启动failover来自动failover。当允许快速启动failover时,Data Guard broker 确定是否需要failover并自动发起failover到指定的目标Standby Database,而不需要 DBA 介入也没有数据丢失。 7.1 角色转换介绍 数据库工作于下面互斥的角色(mutually exclusive)之一:Primary或Standby。Data Guard 允许你通过执行本章中描述的SQL 语句或通过使用任何一个 Data Guard broker 界面,来动态更改这些角色。 Oracle Data Guard 支持下述角色转换: l Switchover(切换): 允许Primary Database切换角色到它的Standby Database之一,在切换期间不会出现数据丢失。在切换之后,每个数据库继续以其新的角色工作在 Data Guard 配置中。 l failover 更改Standby Database到Primary role,对Primary Database的故障来做出响应。如果Primary Database在故障之前没有操作在最大保护模式或最大可用性模式,可能发生数据丢失。如果在Primary Database 和 Standby Database上都允许 Flashback数据库,一旦故障的原因更正了,故障的数据库可用恢复作为新的Primary Database的备库。 7.1.1 节,“准备用角色转换(failover或切换)”帮助你选择最佳地减小宕机时间和数据丢失风险的角色转换。 在 7.1.3 节,switchover(切换)和failover,“切换”和 7.1.4 节,“failover”中相应地进行了更详细地描述。 7.1.1 为角色转换做准备(failover or switchover) 在开始任何角色转换之前,执行下述步骤进行准备工作: 对每个数据库检查初始化参数是否正确配置。查看第 3 章,“创建Primary Standby Database”和第 4 章,“创建Logical Standby Database”以获得在Primary Database 和 Standby Database上如何配置初始化参数,使得 Data Guard 配置在角色转换之后正确操作。 同时,还请查看 3.1.3 节,“配置Standby redo log files”以获得在创建Primary Standby Database时手工添加重做日志文件的相关信息。 注: 在DataGuard环境下的每个Standby Database上都必须要定义 LOG_ARCHIVE_DEST_n 和LOG_ARCHIVE_DEST_STATE_n 参数,使得当切换或故障发生时,所有Standby node继续从新的Primary Database接收redo data。查看 5.4.1 节,“使用 VALID_FOR 属性指定基于角色的Destination”和第 14 章,“LOG_ARCHIVE_DEST_n 参数属性”以获得使用 LOG_ARCHIVE_DEST_n ALID_FOR 属性来定义基于角色的Destination,以为将来的角色转换做准备。 检验将成为新的Primary Database的Standby Database是操作于 ARCHIVELOG 模式。确保存在于Standby Database的临时文件符合在Primary Database上的临时文件。 删除任何在应用Redo中的延迟,这可能会影响将会成为新的Primary Database的Standby Database。 检验在 Real Application Clusters 配置中的Standby Database上除了一个 RAC instance以外都关闭。 对于 Real Application Clusters 数据库,在角色转换过程中Standby Database上只有一个 RACinstance能联机。在开始角色转换之前关闭所有其它instance。然后,在角色转换完成后,将这些instance联机。 注: 即使在切换期间Standby Database上只有一个 RAC instance是打开的,所有其它Standby Databaseinstance在打开时,还将自动经历一个正确转换到它们的新角色的过程。 7.1.2 为角色转换选择目标Standby Database 对于使用多个Standby Database的 Data Guard 配置,当为角色转换选择目标Standby Database时需要考虑许多因素。包括如下: l Standby Database的本地性。 l Standby Database的能力(硬件规格——如 CPU 数目、可用 I/O 带宽、等等)。 执行角色转换所需的时间。这受Standby Databas数据与primary Database数据差别朋多大(用redo data的应用衡量),以及你有多大的灵活性(用应用可用性与数据丢失的折衷衡量)的影响。 Data Guard 提供了 V$DATAGUARD_STATS 视图,能用于估计每个Standby Database的生存能力,用Standby Database中数据的流通衡量,以及如果所有可用的redo data库应用到Standby Database,执行角色转换所需的时间。例如: SQL> COLUMN NAME FORMAT A18 SQL> COLUMN VALUE FORMAT A16 SQL> COLUMN TIME_COMPUTED FORMAT A24 SQL> SELECT * FROM V$DATAGUARD_STATS; NAME VALUE TIME_COMPUTED ------------------ ---------------- ------------------------ apply finish time +00 00:00:02.4 15-MAY-2005 10:32:49 second(1) interval apply lag +00 0:00:04 15-MAY-2005 10:32:49 second(0) interval transport lag +00 00:00:00 15-MAY-2005 10:32:49 second(0) interval 这表示对于这个Standby Database,没有传输延迟,日志应用服务没有应用在过去的 4 秒中生成的Redo(apply lag),日志应用服务将使用 2.4 秒来完成应用未应用的Redo(apply finish time)。在每个统计的时间在 TIME_COMPUTED 列中显示。如果配置包含Primary 和Logical Standby数据库,考虑选择Primary Standby Database作为目标Standby Database。向Primary Standby Database的切换或failover是更可取的,因为在角色转换完成后,配置中的所有数据库对于新的Primary Database作为Standby Database是可行的。然而切换或failover到Logical Standby Database将会使其它Primary Standby Database对于原Primary Database无效。然后在能够重允许Primary Standby Database之前,你将需要从新的Primary Database的备份重建Primary Standby Database。 7.1.3 Switchover 切换一般用于在计划的停机期间减少Primary Database宕机时间,如操作系统或硬件升级,或 Oracle 数据库软件和补丁集的滚动升级(在第 11 章,“使用 SQL 应用来升级 Oracle 数据 库”)。 切换以两个阶段发生。在第一个阶段,现有的Primary Database经历向备用角色的转换。在第二个阶段,Standby Database经历向Primary role的转换。 图 7-1 显示了在数据库角色切换前的两节点 Data Guard 配置。Primary Database位于 San Francisco,Standby Database位于 Boston。 图 7-2 显示了在原Primary Database切换到Standby Database后,但是在原Standby Database成为新的Primary Database 之前的 Data Guard 环境。在这个步骤,Data Guard 配置临时有两个Standby Database。 图 7-3 显示了在切换发生后的 Data Guard 环境。原Standby Database成为新的Primary Database。主数据库现在位于 Boston,Standby Database现在位于 San Francisco。 准备切换: 确保满足在 7.1.1 节中列出的先决条件,另外,下面的先决条件必须对切换满足: 对于包含Primary Standby Database的切换,检验Primary Databaseinstance是否打开和Standby Databaseinstance是否Mount。 你计划更改到Primary role的Standby Database在你开始切换之前必须是安装的。理想地,Primary Standby Database在数据库角色在切换时也将自动地应用Redo。如果Primary Standby Database打开用于只读访问时,切换还将发生,但是需要额外的时间。查看 6.3 节,“应用redo data到Primary Standby Database”以获得Redo应用的更多信息。 对于包含Logical Standby Database的切换,检验Primary Database 和 Standby Databaseinstance是否打开以及 SQL 应用是否活动。查看 6.4 节,“应用redo data到 Logical Standby Database”以获得 SQL 应用相关的更多信息。 对于包含在 Real Applications Cluster 中的Primary Database的切换,除了一个instance以外所有instance都必须关闭。一旦切换成功执行,才可以将所有其它instance联机。 当数据库从一个角色转换到另一个,DB_ROLE_CHANGE 系统事件会触发。可以通过写一个触发器关联这个系统事件,以在切换发生后管理任务。当数据库第一次在切换过后打开时该事件触发,不管其新的角色(就是说,不管切换导致其第一次作为Primary Database、作为Logical standby或作为只读模式中的Primary Standby而打开)。通过查询 V$DATABASE 视图的 DATABASE_ROLE列来确定数据库的当前角色。 7.1.4 Failover 只有当Primary Database变得不可用,并且在合理的时间期间内不可能复原以提供服务,才会使用failover。在failover期间执行的特定操作,基于failover中包括的是Logical还是Physical Standby Database,在failover的时候 Data Guard 配置的状态,由于开始failover使用的特定 SQL 语句而不同。 图 7-4 显示了从 San Francisco 的Primary Database failover到 Boston 的Primary Standby Database的failover的结果。 准备failover 在执行failover之前,你应该传递尽可能多的可用的和未应用的Primary Databaseredo data到Standby Database。 确保满足在 7.1.1 节,“准备用角色转换(failover或切换)”中列出的先决条件。另外,对于 failover,下面的先决条件必须满足: 如果failover中包括当前运行在最大保护模式的Standby Database,必须首先通过在Standby Database上执行下面语句将其置于最大性能模式: SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE; 然后,如果有合适的Standby Database可用,可以在failover完成之后在新的Primary Database上重新设置期望的保护模式。 这个必须要做,因为不能failover到一个处于最大保护模式中的Standby Database。另外,如果处于最大保护模式中的Primary Database还与Standby Database有活动联系,执行 ALTER DATABASE 语句来更改Standby Database从最大保护模式到最大性能模式会失败。因为failover将原Primary Database从 Data Guard 配置中删除了,所以这些特性服务于保护操作于最大保护模式中的Primary Database不受非故意的failover的影响。 注: 不要failover到Standby Database,以便于测试Standby Database是否被正确更新。 查看 3.2.7 节,“检验Primary Standby Database正确执行” 查看 4.2.6 节,“检验Logical Standby Database正确执行” 当数据库从一个角色转换到另一个,DB_ROLE_CHANGE 系统事件会触发。可以通过写一个触发器关联这个系统事件,以在failover发生后管理任务。当数据库第一次在failover过后打开时该事件触发,不管其新的角色(在failover到Primary Standby Database的情况下,系统事件在数据库第一次在failover操作后打开时触发)。通过查询 V$DATABASE 视图的DATABASE_ROLE 列来确定数据库的当前角色。查看在 Oracle 数据库应用开发指南-基础中的系统管理事件表,以获得更多细节。 要执行包含Primary Standby Database的failover,查看 7.2.2 节,“包含Primary Standby Database的failover”。 要执行包含Logical Standby Database的failover,查看 7.3.2 节,“包含Logical Standby Database的failover”。要 使用 Data Guard Broker 执行failover。查看在 Oracle Data Guard Broker 中的“切换和故障 转移操作”相关章节。 7.2 包含Primary Standby Database的角色转换 本节描述如何执行包含Primary Standby Database的switchover和failover。 7.2.1 包含Primary Standby Database的切换 本小节描述如何执行切换。切换必须在当前Primary Database上发起,并且在目标Standby Database上完成。下面的步骤描述如何执行切换。 第 1 步 检验是否可能执行切换。 在当前Primary Database上,在Primary Database上查询 V$DATABASE 固定视图的SWITCHOVER_STATUS 列,以检验是否可能执行切换。例如: SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO STANDBY 1 row selected 在 SWITCHOVER_STATUS 列中的 TO STANDBY 值指出可能切换Primary Database到备用角色。 如果 TO STANDBY 值没有显示,则检查 Data Guard 配置是否正确起作用(例如,检查所有的 LOG_ARCHIVE_DEST_n 参数值被正确指定)。 如果在 SWITCHOVER_STATUS 列中的值是 SESSIONS ACTIVE,执行在 A.4 节,“切换到Standby Database的问题”中描述的步骤,来确定并终止可能阻碍切换处理的活动用户或 SQL会话。如果,在执行这些步骤之后,SWITCHOVER_STATUS 列还是显示 SESSION ACTIVE,You can通过添加 WITH SESSION SHUTDOWN 子句到步骤 2 中描述的 ALTER DATABASECOMMIT TO SWITCHOVER TO PHYSICAL STANDBY 语句来成功执行切换。 查看 Oracle 数据库参考以获得 V$DATABASE 视图的 SWITCHOVER_STATUS 列的其它有效值的相关信息。 第 2 步 在Primary Database上发起切换。 要更改当前Primary Database到Primary Standby Database角色,在Primary Database上使用下面 SQL 语句: SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY ; 在这个语句完成后,Primary Database转换到Standby Database。当前控制文件在切换前备份到当前 SQL会话跟踪文件。这使得有可能重构当前控制文件,如果必要的话。 第 3 步 关闭并重启前主instance。 关闭前主instance,并重启和安装数据库: SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; 在切换过程的这个点,两个数据库都配置为Standby Database(查看图 7-2)。 第 4 步 检验 V$DATABASE 视图中的切换状态。 在你更改Primary Database到Primary 备用角色,以及配置中的Standby Database接收到切换通知之后,你应该检验目标Standby Database是否处理切换通知,通过查询目标Standby Database上的 V$DATABASE 固定视图的 SWITCHOVER_STATUS 列。 例如: SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO_PRIMARY 1 row selected 如果 SWITCHOVER_STATUS 列中的值是 SESSION ACTIVE,执行在 A.4 节,“切换到Standby Database的问题”中描述的步骤,来确定并终止可能阻碍切换处理的活动用户或 SQL 会话。如果,在执行这些步骤之后,SWITCHOVER_STATUS 列还是显示 SESSION ACTIVE,你能处理到步骤 5,并过添加 WITH SESSION SHUTDOWN 子句到切换语句。查看 Oracle 数据库参考以获得 V$DATABASE 视图的 SWITCHOVER_STATUS 列的其它有效值的相关信息。 第 5 步 切换目标Primary Standby Database角色到Primary role。 当Standby Databaseinstance安装在Redo应用模式或对只读访问打开时,You can将Primary Standby Database从备角色切换到Primary role。必须是这些模式之一,Primary Database的切换请求才能被调度。在Standby Database处于适当的模式,在你希望更改Primary role的Primary Standby Database上,执行下面的 SQL 语句: SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY ; 第 6 步 完成Standby Database到Primary role的转换。 你执行的任务依赖于Primary Standby Database是否曾经以只读模式打开过: 如果Primary Standby Database自从上次启动过后没有以只读模式打开过,执行 SQL> ALTER DATABASE OPEN 语句来打开新的Primary Database: SQL> ALTER DATABASE OPEN; 然后,跳到步骤 7。 如果Primary Standby Database自从上次启动过后曾经以只读模式打开,你必须关闭目标Standby数据库并重启: SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP; 目标Primary Standby Database现在经历到Primary Database角色的转换。查看 5.4.1 节,“指定有 VALID_FOR属性的基于角色的Destination”和第 14 章, “LOG_ARCHIVE_DEST_n 参数属性”以获得使用LOG_ARCHIVE_DEST_n VALID_FOR 属性来确保 Data Guard 配置在角色转换后正确操作的相关信息。 注: 不需要关闭并重启在切换的时候联机的其它Standby Database(不包括在切换中的)。这些备数 据库在切换完成后将继续正常起作用。 第 7 步 如果必要,在Standby Database上重启日志应用服务。 对于新的Primary Standby Database和 Data Guard 配置中的每个其它Primary 或Logical Standby Database,如果日志应用服务没有预先配置在切换过程中持续打开,使用合适的命令来重启日志应用服务。查看第 6 章,“日志应用服务”以获得如何配置及启动日志应用服务的相关信息。 第 8 步 开始发送redo data到Standby Database。 在新的Primary Database上执行下面语句: SQL> ALTER SYSTEM SWITCH LOGFILE; 7.2.2 包含Primary Standby Database的failover 本小节描述如何执行包含Primary Standby Database的failover。 在包含Primary Standby Database的failover过程中: 在所有情况中,在failover后,原Primary Database不能再参与在 Data Guard 配置中。 在大多数情况中,其它逻辑或Primary Standby Database不直接参与配置中剩余的failover,并 不必须关闭或重启。 在一些情况中,可能有必要在配置新的Primary Database之后重建所有Standby Database。 这些情况在下面的failover步骤中的适当位置描述。 在开始failover之前,执行在 7.1.4 节,“failover”中记录的尽可能多的步骤来为故障转移准备挑选的Standby Database,然后进行 7.2.2 节,“包含Primary Standby Database的failover”作为Failover步骤。 注: Oracle 建议你只使用在下面小节中描述的failover步骤和命令来执行failover。不要使用 ALTER DATABASE ACTIVATE STANDBY DATABASE 来执行failover,因为这条语句可能导致数据丢失。 failover步骤: 本小节描述了转换挑选的Primary Standby Database到Primary role必须执行的步骤。任何 也是配置中的一部分的其它Primary 或Logical Standby Database将保留在配置中,并将不需要关闭或重启。 如果目标Standby Database操作于使用日志写进程(LGWR)的最大保护模式或最大可用性模式,在archived redo log files中不应该存在中断,You can直接进行到步骤 4。否则,从步骤 1 开始以确定是否必须执行一些手工中断解决步骤。 第 1 步 确定并解决archived redo log files中的任何中断。 要在目标Standby Database上确定是否在archived redo log files中存在中断,查询V$ARCHIVE_GAP 视图。 V$ARCHIVE_GAP 视图包含对于每个线程已知丢失的archived redo log files的序列号。返回的数据只反映最高的中断。 例如: SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ---------- ------------- -------------- 1 90 92 在这个例子中,中断包括线程 1 的archived redo log files序号 90、91和 92。如果可能,从Primary Database拷贝所有确定的丢失的archived redo log files到目标Standby Database,并注册它们。这必须对于每个线程执行。 例如: SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1'; 第 2 步 重复步骤 1 直到解决所有中断。 在步骤 1 中执行的查询只显示最高的中断信息。在解决那个中断后,你必须重复步骤 1直到查询返回零行。 第 3 步 拷贝任何其它丢失的archived redo log files。 要确定是否还有其它丢失的archived redo log files,在目标Standby Database上查询V$ARCHIVED_LOG 视图以获得每个线程的最高序列号。 例如: SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) 2> OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG; THREAD LAST ---------- ---------- 1 100 从包含比目标Standby Database上可用的最高序列号更高序列号的Primary Database,拷 贝任何可用的archived redo log files到目标Standby Database并注册它们。这必须对每个线程执行。 例如: SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1'; 在所有可用的archived redo log files已经注册后,如步骤 1 中描述地查询V$ARCHIVE_GAP 视图,检验没有更多的中断在步骤 3 中引入。 注: 如果,当执行步骤 1 到 3 时,你不能解决在archived redo log files中的中断(例如,因为你 没有访问故障Primary Database所在的系统),在failover过程中会发生数据丢失。 第 4 步 在目标Primary Standby Database上发起failover。 执行下面语句以发起failover: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE; FORCE 关键词终止目标Primary Standby Database上活动的 RFS 进程,使得failover能不用等待网络连接超时而立即进行: 注: failover添加一个Redo结束的标识到最后一个归档的日志文件的头部,并发送Redo到所有允许的对于Primary Database有效的Destination(使用 VALID_FOR=(PRIMARY _ROLE, *_LOGFILES)或 VALID_FOR=(ALL_ROLE, *_LOGFILES)属性指定)。 在 SQL 语句中 FINISH 关键词必须跟在所有其它关键词后面,除了 FORCE、WAIT、或 NOWAIT。 第 5 步 转换Primary Standby Database到Primary role。 一旦 SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE …FINISH FORCE 语句成功完成,通过执行下面 SQL 语句更改Primary Standby Database到Primary Database: SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY ; 在执行这条 SQL 语句之后,目标Standby Database经历到Primary role的转换。结果是,不能再使用这个数据库作为Standby Database,并且任何后继的从原Primary Database接收的Redo不能被应用。再故障转移过程中,Standby redo log files在其它所有从原Primary Database导出的Standby Database上被自动归档并恢复。只有当Standby Destination在新的Primary Database上正确定义时这才会发生。没有必要关闭并重启任何其它在配置中没有参与failover的Standby Database。 第 6 步 完成Standby Database到Primary Database角色的转换。 你在本步骤执行的任务依赖于Primary Standby Database是否曾经以只读模式打开过: 如果Primary Standby Database自从上次启动过后没有以只读模式打开过,执行 SQL> ALTER DATABASE OPEN 语句来打开新的Primary Database: SQL> ALTER DATABASE OPEN; 然后,跳到步骤 7。 如果Primary Standby Database自从上次启动过后曾经以只读模式打开,你必须关闭目标Standby Database并重启: SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP; 目标Primary Standby Database现在经历到Primary Database角色的转换。 查看 5.4.1 节,“指定有 VALID_FOR 属性的基于角色的Destination”和第 14 章, “LOG_ARCHIVE_DEST_n 参数属性”以获得使用 LOG_ARCHIVE_DEST_n VALID_FOR 属性的相关信息,使得 Data Guard 配置在角色转换后正确操作。 第 7 步 备份新的Primary Database。 在执行 STARTUP 语句之前,备份新的Primary Database。立即执行备份是必要的安全措施,因为你无法在没有完整的数据库备份拷贝的情况下,恢复failover之后的更改。 作为failover的结果,原数据库不能再参与在 Data Guard 配置中,并且所有其它Standby数据库现在接收和应用从新的Primary Database的redo data。 第 8 步 可选地,还原故障的Primary Database。 在failover之后,原Primary Database不再参与在配置中。在执行failover后,你可能将故障的Primary Database还原作为新的Standby Database,使用下述方法之一: 使用闪回数据库来还原故障的Primary Database到failover发生前的时间点,然后遵循 12.4 节,“在failover后使用 Flashback 数据库”中的过程将其转换到Standby Database。 注: 在failover前,你必须已经在旧的Primary Database上允许 Flashback 数据库。查看 Oracle 数据库备份和恢复基础以获得更多信息。 重建故障的数据库并作为新的Standby Database将其添加到配置中。要在新的配置中重用旧的Primary Database,你必须使用新的Primary Database的备份拷贝将其重建为Standby Database。这个过程在 3.2 节,“创建Primary Standby Database的逐步指导”或 4.2 节,“创建Logical Standby Database的逐步指导”中描述。 使用 Oracle 企业管理器或 DGMGRL REINSTATE DATABASE 命令,当连接重新建立时重建故障的Primary Database为新配置中的Standby Database。恢复的逐步指导在 Oracle Data Guard Broker中描述。这个选项需要在failover前允许闪回数据库。 一旦故障的Primary Database被恢复并运行于备用角色,You can选择执行切换以执行数据 库的角色转换到它们的原(故障前)角色。查看 7.2.1 节,“包含Primary Standby Database的切换”以获得更多信息。 7.3 包含Logical Standby Database的角色转换 本节描述如何执行包含Logical Standby Database的切换和failover。 7.3.1 包含Logical Standby Database的切换 当你执行Switchover,在Primary Database和Logical Standby Database之间更改角色,总是在Primary Database上发起Switchover并在Logical Standby Database上完成。这些步骤必须以所描述的顺序执行,否则切换将不会成功。 注: 如果Primary Database是 RAC 数据库,确保除了一个以外关闭所有instance,并且在发起切换之前禁止相应的线程。类似地,如果Logical Standby Database是 RAC 数据库,确保除了一个以外的所有实例关闭 SQL 应用,并且在发起切换之前禁止相应的线程。一旦切换操作成功完成,可以重新允许这些线程并启动instance。虽然instance是关闭的,但是当它们重启时,角色更改将不会自动传递到这些instance。 第 1 步 在Primary Database上检验是否有可能执行切换 在当前的Primary Database上,查询在Primary Database上的 V$DATABASE 固定视图的SWITCHOVER_STATUS 列,以检验是否可能执行切换。 例如: SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO STANDBY 1 row selected 在 SWITCHOVER_STATUS 列中的 TO STANDBY 或 SESSIONS ACTIVE 的值指出可能切换Primary Database到Logical Standby角色。如果这些值之一没有显示,则检验 Data Guard 配置是否正确起作用(例如,检验所有 LOG_ARCHIVE_DEST_n 参数值是否正确指定)。查看 Oracle 数据库参考以获得 V$DATABASE 视图的 SWITCHOVER_STATUS 列的其它有效值的相关信息。 第 2 步 为切换准备当前Primary Database。 要为Logical Standby Database角色准备当前Primary Database,在Primary Database上 执行下面的 SQL 语句: SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY ; 这条语句通知当前Primary Database,它将马上切换到逻辑备用角色并开始从新的Primary Database接收redo data。你在Primary Database上执行这个步骤,为接收 LogMiner Multiversioned Data Dictionary记录在当前Logical Standby Database的Redo流中做准备,如步骤 3 中描述。 如果这个操作成功,则 V$DATABASE.SWITCHOVER_STATUS 列中显示 PREPARING SWITCHOVER 值。 第 3 步 为切换准备目标Logical Standby Database。 使用下面命令在作为切换目标的Logical Standby Database上建立 LogMiner Multiversioned Data Dictionary: SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY ; 这条语句也在Logical Standby Database上开始Redo transport services ,开始传送其redo data到当前主数据库和 Data Guard 配置中的其它Standby Database。从这个Logical Standby Database接收redo data的节点接收重做数据但不应用。 依赖于完成的工作量和数据库的大小,切换需要花费一些时间来完成。 当 LogMiner Multiversioned Data Dictionary 正在Redo流中记录时,在Logical Standby Database上的V$DATABASE.SWITCHOVER_STATUS 最初显示 PREPARING DICTIONARY。一旦这个成功完成,SWITCHOVER_STATUS 列显示 PREPARING SWITCHOVER。 第 4 步 确保当前Primary Database为将来的Primary Database的Redo流做好准备。 在You can完成Primary Database到逻辑备用角色的转换之前,通过查询Primary Database上的 V$DATABASE固定视图的 SWITCHOVER_STATUS 列,检验 LogMiner Multiversioned Data Dictionary 是否被Primary Database接收到。没有收到 LogMiner Multiversioned Data Dictionary,切换无法进行,因为当前的Primary Database将不能解释从未来的Primary Database发送的Redo记录。SWITCHOVER_STATUS列显示了切换的过程。 当查询返回 TO LOGICAL STANDBY 值,You can进行到步骤 5。例如: SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO LOGICAL STANDBY 1 row selected 注: 可以通过以下面的顺序执行下面的语句来取消切换操作: 1.在Primary Database上取消切换: SQL> ALTER DATABASE PREPARE TO SWITCHOVER CANCEL; 2.在Logical Standby Database上取消切换: SQL> ALTER DATABASE PREPARE TO SWITCHOVER CANCEL; 第 5 步 切换Primary Database到Logical Standby Database角色。 要完成Primary Database到Logical Standby Database的角色转换,执行下面 SQL 语句: SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY ; 这条语句等待Primary Database上的所有当前事务结束,并阻止任何新的用户开始新事务,并 在切换将要提交的地方建立一个时间点。 执行这条语句也将阻止用户对由Logical Standby Database维护的数据进行更改。要确保更快地执行,确保Primary Database在执行切换语句之前处于安静的状态,没有更新活动(例如,要求所有用户暂时从Primary Database退出登录)。You can查询 V$TRANSACTIONS 视图以获得任何当前正在处理的事务的状态,这些事务可能延迟这条语句的执行。 Primary Database现在可以经历角色转换以运行到Standby Database角色。 当Primary Database经历角色转换到Logical Standby Database角色时,你不需要关闭和重启数据库。 第 6 步 确保所有可用的Redo应用到将要成为新的Primary Database的目标Logical Standby Database上。 在你完成Primary Database到逻辑备用角色的角色转换,以及配置中的Standby Database接收到切换通知之后,你应该检验切换通知是否被目标Standby Database处理,通过查询目标Standby Database上的V$DATABASE 固定视图的 SWITCHOVER_STATUS 列。一旦所有可用的Redo记录应用到逻辑Standby Database,SQL 应用自动关闭以准备预料中的角色转换。 SWITCHOVER_STATUS 值更新以显示切换中的过程。当状态为 TO PRIMARY ,可以进行步骤 7。 例如: SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO PRIMARY 1 row selected 查看 Oracle 数据库参考以获得 V$DATABASE 视图的 SWITCHOVER_STATUS 列的其它有效值的相关信息。 第 7 步 切换目标Logical Standby Database到Primary Database角色。 在你希望切换到Primary role的Logical Standby Database上,使用下面的 SQL 语句来切换Logical Standby Database到Primary role: SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY ; 没有必要关闭并重启在 Data Guard 配置中的任何Logical Standby Database。其它现有的逻辑Standby Database将在切换完成后继续正常起作用。然而,所有现有的Primary Standby Database在切换后无法参与到Data Guard 配置中了。 第 8 步 在新的Logical Standby Database上开始 SQL 应用。 在新的Logical Standby Database,开始 SQL 应用: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY; 7.3.2 包含Logical Standby Database的failover 本小节描述如何执行包含Logical Standby Database的failover。包含Logical Standby Database的failover角色转换需要在故障的Primary Database和所有旁观Logical Standby Database上执行正确的操作。如果在故障的主数据库上没有允许 Flashback 数据库,你必须从当前Primary Database获得的备份重建数据库。另外,可以遵照 12.4 节中描述的过程转换故障的Primary Database为新的Primary Database的Logical Standby Database。 依赖于配置的保护模式以及你选择的Redo transport services,有可能自动恢复所有或部分主数 据库更改。 如果目标Standby Database操作于无数据丢失模式,在archived redo log files中将不存在中断,可以直接进行步骤 2。否则,从步骤 1 开始以确定是否必须执行手工中断解决步骤。 第 1 步 拷贝和注册任何丢失的redo log files到候选成为新Primary Database的目标Logical StandBy database库。 依赖于配置配置中的环境变量,通过访问Primary Database上的archived redo log files。如果可用,做如下操作: 1.确定在Logical Standby Database上是否丢失archived redo log files。 2.从Primary Database拷贝丢失的日志文件到Logical Standby Database。 3.注册拷贝的日志文件。 通过执行下面的语句来注册archived redo log files到Logical Standby Database。例如: SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE 2> '/disk1/oracle/dbs/log-%r_%s_%t.arc'; Database altered. 第 2 步 确保所有可用的archived redo log files已应用。 在你要转换到Primary role的Logical Standby Database上之前,要通过查询 V$LOGSTDBY_PROGRESS 视图检验所有可用的archived redo log files已应用。例如: SQL> SELECT APPLIED_SCN, LATEST_SCN FROM V$LOGSTDBY_PROGRESS; APPLIED_SCN LATEST_SCN ----------- ---------- 190725 190725 当 APPLIED_SCN 和 LASTEST_SCN 值相等时,所有可得到的数据已应用并且Logical Standby数据库现在包含与Primary Database可能一样多的数据库。 注: 如果在目标Logical StandBy database上 SQL 应用没有活动,在目标Standby Database上执行下面语句以开始SQL Apply: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY FINISH; Database altered. 查看第 9 章,“管理Logical Standby Database”和第 12 章,“Data Guard 场景”以获得V$LOGSTDBY_PROGRESS 视图相关信息。 第 3 步 允许远程Destination。 如果你前面没有配置基于角色的Destination,如 5.4.1 节,“使用 VALID_FOR 属性指定基于 角色的Destination”中所描述,对于新的Primary Database确定相应于远程逻辑Standby Destination的初始化参数,并手工允许对于每个这些Destination的redo data的归档。 例如,要允许对于由 LOG_ARCHIVE_DEST_2 参数定义的远程Destination的归档,执行下面语句: SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH; 要确保这个更改在如果新的Primary Database后来重启后还能保持,更新适当的文本初始化参数文件或服务器参数文件。总的来说,当数据库操作于Primary role,你必须允许归档到远程目的地,并且当数据库操作于备用角色,你必须禁止归档到远程Destination。 查看 5.4.1 节,“使用 VALID_FOR 属性指定基于角色的Destination”和第 14 章, “LOG_ARCHIVE_DEST_n 参数属性”以获得使用 LOG_ARCHIVE_DEST_n VALID_FOR属性来定义基于角色的Destination,以为将来的角色转换做准备。 第 4 步 激活新的Primary Database。 在目标Logical Standby Database(你转换到新的Primary role的)上执行下面的语句: SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY; 这条语句停止 RFS 进程,在Logical Standby Database成为Primary Database之前应用在Standby redo log files中的剩余redo data,停止 SQL 应用,并激活数据库为Primary Database角色。如果没有指定 FINISH APPLY 子句,则从当前Standby redo log files未应用的Redo在Standby Database成为Primary Database之前将不会应用。 第 5 步 准备恢复其它Standby Database。 依赖于能Apply多少redo data到新的Primary Database,你可能添加其它现有的Logical StandBy database库回到 Data Guard 配置以作为Standby Database为新的Primary Database服务。在每个Logical Standby Database上执行下述步骤以准备添加回到 Data Guard 配置: 1.在每个Logical Standby Database上创建数据库链接。 使用 ALTER SESSION DISABLE GUARD 语句来绕过数据库守卫并允许对逻辑备 数据库中的表的更改。例如,下面创建了到Primary Database chicago 的数据库链接: SQL> ALTER SESSION DISABLE GUARD; SQL> CREATE DATABASE LINK chicago 2> CONNECT TO username IDENTIFIED BY password USING 'chicago'; SQL> ALTER SESSION ENABLE GUARD; 在 CREATE DATABASE LINK 语句中指定的数据库用户帐户必须有在Primary Database上的 SELECT_CATALOG_ROLE 角色。 注: 在Primary Database打开过后但在任何 DDL 语句执行之前,你必须执行数据库字典建立操作。如果在字典建立操作执行之前有任何 DDL 语句执行,作为创建Logical StandBy database的源,备份将变得无效。 查看 Oracle 数据库管理员指南以获得创建数据库链接的更多相关信息。 2.检验数据库链接。 在Logical Standby Database,通过使用数据库链接执行下述查询来检验数据库链接是否正确 配置: SQL> SELECT * FROM DBA_LOGSTDBY_PARAMETERS@chicago; 如果查询成功,则确认在步骤 1 中创建的数据库链接能在角色转换期间使用。 第 6 步 开始 SQL Apply。 在每个Logical Standby Database上开始 SQL 应用。 例如,下面的语句在 chicago 数据库上开始 SQL 应用: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY chicago; 当这条语句完成,所有剩余的archived redo log files将已经被应用。依赖于要完成的工作, 这个操作可能需要一定时间来完成。 如果返回 ORA-16109 错误,你必须从新的Primary Database的备份拷贝重新创建Logical StandBy database库,然后将其添加到 Data Guard 配置。 下面的例子显示了在新配置中的Logical Standby Database上开始 SQL 应用的失败尝试,chicago 是指向新的Primary Database的服务名: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY chicago; ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY chicago * ERROR at line 1: ORA-16109: failed to apply log data from previous Primary 第 7 步 备份新的Primary Database。 在 Data Guard 数据库failover之后立即备份新的Primary Database。立即执行备份是必要的安全措施,因为你不能在没有完整数据库备份拷贝的情况下恢复在failover后进行的更改。 第 8 步 还原故障的Primary Database。 在执行failover之后,你可以选择使用下述方法之一还原故障的Primary Database作为新的Standby Database: 使用闪回数据库转换故障的Primary Database到failover发生前的时间点,然后遵循 12.4节,“在故障转换后使用闪回数据库”中的过程将其转换为Standby Database。 注: 在failover之前你必须已经在旧的Primary Database上允许 Flashback 数据库。查看 Oracle 数据库备份和恢复基础以获得更多信息。 使用 DBMS_LOGSTDBY.REBUILD PL/SQL 过程来重建Primary Database为新的Standby Database。运行该过程之前,必须检验: 查询 V$STANDBY _LOG 或 V$LOGFILE 视图以检验Standby redo log files已被归档 查询 DBA_LOGSTDBY_EVENTS 视图以检验 LogMiner 字典建立成功完成。 同时查看:在 Oracle 数据库 PL/SQL 包和类型参考中的 DBMS_LOGSTDBY 包以获得 REBUILD 子程序的相关信息 当连接重新建立时,使用 Oracle 企业管理器或 DGMGRL REINSTATE DATABASE命令来重建故障的Primary Database作为配置中的Standby Database。复原的逐步指导在 Oracle Data Guard Broker 中描述。 遵循 3.2 节,“创建Primary 备数库的逐步指导”或 4.2 节,“创建Logical Standby Database的逐步指导”中过程,重建故障的数据库并作为新的Standby Database将其添加到配置中。一旦故障的Primary Database被还原并运行于备用角色,You can选择执行切换以转换数据库到它们的原 (故障前)角色。查看 7.3.1 节,“包含Logical Standby Database的切换”以获得更多信息。 7.4 在角色转换后使用 Flashback 数据库 在角色转换后,You can选择使用 FLASHBACK DATABASE 命令来恢复数据库到角色转换发生前的时间点或系统更改号(SCN)。 在Primary Standby Database环境中,你可能需要闪回Primary Database和所有Standby Database以维护 Data Guard配置。如果你闪回Primary Database到一个特定的 SCN 或时间,你必须闪回所有备数据到同样(或更早)的 SCN 或时间。这样,在开始Redo应用后,Primary Standby Database将自动开始应用从主数据库接收到的redo data。当以这种方式闪回主或Standby Database,你不需要考虑过去的切换。如果SCN/时间是在过去切换之前,Oracle 能自动跨越过去的切换闪回。 注: 在角色转换发生之前必须在数据库上允许 Flashback 数据库。查看 Oracle 数据库备和恢复基础以获得更多信息。 7.4.1 在切换后使用 Flashback 数据库 在切换后,你可以使用 FLASHBACK DATABASE 命令返回数据库到一个切换发生前的时间或系统更改号(SCN)。 如果切换包含Primary Standby Database,Primary Database 和 Standby Database角色在闪回操作期间保持不变。就是说,当数据库闪回到你闪回数据库的目标 SCN 或时间时,数据运行的角色不能更改。在切换后但是在闪回前运行在Primary 备用角色的数据库,在 Flashback 数据库操作后将还是运行在Primary Standby角色。 如果切换包含Logical StandBy database,闪回更改Standby Database的角色到你闪回数据库到的目标 SCN 或时间时的状态。 7.4.2 在故障转换后使用 Flashback 数据库 你可以使用 Flashback 数据库来恢复Primary Database到故障转换发生前的时间点,然后将其转换为Standby Database。查看 12.4 节,“在故障转换后使用 Flashback 数据库”以获得完整的逐步过程。 8 管理Physical Standby Database 本章描述如何管理Physical Standby Database。本章包含下述主题: u 启动和关闭Physical Standby Database u 打开Standby Database以用于只读或读/写访问 u 管理影响Standby Database的Primary Database事件 u 通过 OPEN RESETLOGS 语句恢复 u 监控Primary Database 和 Standby Database u 为Physical Standby Database调优日志应用速度 在本章中的主题描述如何使用 SQL 语句、初始化参数和视图来管理Primary Standby Database。 8.1 启动和关闭Physical Standby Database 本节描述了用于启动和关闭Physical Standby Database的 SQL*Plus 语句。 8.1.1 启动Physical Standby Database 要启动Physical Standby Database,使用 SQL*Plus 以管理员权限连接到数据库,然后使用 SQL*Plus的 STARTUP 或 STARTUP MOUNT 语句。当在Physical Standby Database上使用时: STARTUP 语句启动数据库,作为Primary Standby Database Mount数据库,并打开数据库以用于只读访问。 STARTUP MOUNT 语句作为Primary Standby Database启动并Mount不打开数据库。一旦Mount,将Apply 从Primary Database接收的redo data。然后根据定义或者开始Redo应用或实时应用,或打开数据库以用于只读访问。 例如: 1. 启动并安装Primary Standby Database: SQL> STARTUP MOUNT; 2. 开始Redo应用或实时应用: 要开始Redo应用,执行下面语句: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> DISCONNECT FROM SESSION; 要开始实时应用,执行下面语句: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> USING CURRENT LOGFILE; 在Primary Database上,查询 V$ARCHIVED_DEST_STATUS 视图中的 RECOVERY_MODE 列,它显示Standby Database的操作,对于Redo应用是 MANAGED_RECOVERY,对于实时应用是MANAGED REAL TIME APPLY。 注: 当你首次在新创建的还没从Primary Database接受任何redo data的Primary Standby Database上开始Redo应用,可能会返回 ORA-01112 信息。这指出Redo应用不能确定媒质恢复的开始序列号。如果发生这种情况,你必须在Standby Database上手工检索并注册archived redo log files,或者等待自动归档在重启Redo应用前发生。 8.1.2 关闭Primary Standby Database 要关闭Primary Standby Database并停止Redo应用,使用 SQL*Plus SHUTDOMN 语句。控制没有返回到发起数据库关闭的会话,直到关闭完成。 如果Primary Database启动并运行,延迟Primary Database上的Destination并在关闭Standby Database之前执行日志切换。 要在关闭数据库之前停止Redo应用,使用下述步骤: 1.执行下面查询以发现Standby Database是执行Redo应用还是实时应用。如果 MRP0 或 MRP进程存在,则Standby Database正在Apply Redo。 SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY ; 2.如果Redo应用在运行,如下述例子中所示将其取消: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 3.关闭Standby Database: SQL> SHUTDOWN IMMEDIATE; 8.2 打开Standby Database以用于只读或读/写访问 当Standby Database打开以用于只读访问时,用户能以只读方查询Standby Database。因此,可以通过使用Standby Database用于报表用途来减少Primary Database上的负载。可以定期地打开Standby Database以用于只读访问,并执行特别的查询来检验Redo应用正确地更新Standby Database。(注意对于分布式查询,在只读数据库上执行查询之前,你必须首先执行 ALTER DATABASE SET TRANSACTION READ ONLY 语句。) 图 8-1 显示了Standby Database打开以用于只读访问。 同时查看: 评估是否打开Standby Database 打开Primary Standby Database以用于只读访问 Primary Standby Database能以读/写模式临时地打开以用于开发、报表、或测试用途,然后闪回到过去的点以恢复到Primary Standby Database。当数据库闪回时,Data Guard 自动与Primary Database同步Standby Database数据库,而不需要从Primary Database的备份拷贝重建Primary Standby Database。 同时查看: 12.6 节以获得描述激活Primary Standby Database作为读/写报表数据库的场景,然后重新与主数据库同步数据库 8.2.1 评估是否打开Standby Database 当你决定是否打开Primary Standby Database以用于只读或读/写访问,要考虑下面的问题: 只读打开Primary Standby Database可能延长从故障或断电恢复所需的时间,因为数据库必须在故障转换后重启。 只要Primary Standby Database自从上次启动后没有只读打开过,在故障转换后没有必要重启,因而增加系统可用性。 当Standby Database打开以用于只读或读/写访问,它不应用从Primary Database接受的redo data,因而它没有与Primary Database保持事务一致性。 当Primary Standby Database打开时,从Primary Database的redo data由Standby Database接收,但是日志文件不被应用。在一些点上,你需要在Standby Database上继续Redo应用,并应用归档redo log文件以重新与Primary Database同步Standby Database。因为应用任何累积的archived redo log files需要额外的时间,将Standby Database打开以用于只读访问能增加完成failover或切换所需的时间。 如果你在Standby system上配置超过一个Standby Database,你可以使用Primary Standby Database以用于报表用途或作为克隆数据库的同时也维持快速完成failover或切换的能力。 例如,基于你的业务需求,你可能: 配置两个Primary Standby Database,一个Standby Database总是执行Redo应用,与Primary Database尽可能保持一致,另一个Standby Database在业务时间以只读模式打开以用于报表用途。 配置一个Primary Standby Database来维护Primary Database的拷贝以用于灾难恢复用途,并同时配置一个Logical Standby Database来减负需要从Primary Database访问最近的数据的报表任务。 当在同一系统配置超过一个Standby Database,考虑使用 LOG_ARCHIVE_DEST_n 初始化参数的 DEPENDENCY 属性来定义一个归档Destination来代表所有Destination接收redo data,而不是传送redo data到每个单独Destination。查看 5.7.5 节以获得更多信息。 8.2.2 打开Primary Standby Database以用于只读访问 你可以使用下述过程在将Primary Standby Database打开以用于只读访问和执行Redo应用之间切换。 要Standby Database当前关闭时打开以用于只读访问: 使用下面语句启动、安装、并打开数据库以用于只读访问: SQL> STARTUP; 当Standby Database当前执行Redo应用时打开以用于只读访问: 1. 取消Redo应用: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 2.打开数据库以用于只读访问: SQL> ALTER DATABASE OPEN; 你不需要关闭instance来打开以用于只读访问。 注: 默认情况下,ALTER DATABASE OPEN 语句以只读模式打开Primary Standby Database。Oracle 数据库基于控制文件中的信息确定这是否是Primary Standby Database。 要从打开以用于只读访问更改Standby Database到执行Redo应用: 1.在Standby Database上终止所有活动的用户会话。 2.重启Redo应用。要开始Redo应用,执行下面语句: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> DISCONNECT FROM SESSION; 要允许实时应用,包括 USING CURRENT LOGFILE 子句: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> USING CURRENT LOGFILE; 你不需要关闭instance来开始任何这些应用模式之一。 8.3 管理影响Standby Database的Primary Database事件 要防止可能的问题,你必须注意在Primary Database上影响Standby Database的事件,并学习如何响应它们。本节描述这些事件和对于这些事件建议的响应。 在一些情况中,在Primary Database上发生的事件或更改自动通过redo data传播到Standby Database,因而在Standby Database上不需要额外的操作。在其它情况中,你可能需要在Standby Database上执行维护任务。 表 8-1 指出在Primary Database上进行的更改是否需要数据库管理员(DBA)额外的介入来传播到Standby Database。也能很简短地描述如何响应这些事件。响应的详细描述在提供的小节参考中描述。 表 8-1 在更改Primary Database后需要在Standby Database上的操作 下面的事件由Redo transport services和Redo应用自动管理,因此不需要数据库管理员的介入: 使用 ENABLE THREAD 或 DISABLE THREAD 子句执行的 SQL ALTERDATABASE 语句。 表空间的状态更改(更改到读/写或只读,置于联机或脱机)。 当 STANDBY _FILE_MANAGEMENT 初始化参数设为 AUTO 时,添加数据文件或创建表空间。 8.3.1 节 添加数据文件或创建表空间 如果你没有设置 STANDBY _FILE_MANAGEMENT 初始化参数为 AUTO,你必须拷贝新数据文件到Standby Database。 8.3.2 节 删去或删除表空间或数据文件 在包含 DROP 或 DELETE 命令的archived redo log files应用后从Primary Database 和 Standby Database删除数据文件。 8.3.3 节 使用可传输表空间 在Primary Database 和 Standby Database之间移动表空间。 8.3.4 节 重命名数据文件 在Standby Database上重命名数据文件。 8.3.5 节 添加或删除 redo log files 在Standby Database上同步更改。 8.3.6 节 使用 NOLOGGING 或UNRECOVERABLE 子句执行DML 或 DDL 操作 发送包含未记录更改的数据文件到Standby Database。 第 13 章 更改初始化参数 动态更改备参数或关闭Standby Database并更新初始化参数。 8.3.1 添加数据文件或创建表空间 初始化参数,STANDBY _FILE_MANAGEMENT,允许你控制是否向Primary Database的添加数 据文件自动传播到Standby Database,如下: 如果你在Standby Database服务器参数文件(SPFILE)中设置STANDBY _FILE_MANAGEMENT 初始化参数为 AUTO,则任何在Primary Database上创建的新数据文件一样自动创建在Standby Database上。 如果你没有指定 STANDBY _FILE_MANAGEMENT 初始化参数,或者你设置为MANUAL,则当你添加数据文件到Primary Database时你必须手工拷贝新数据文件到Standby Database。 注意如果你从其它数据库拷贝现有的数据文件到Primary Database,则你必须也拷贝新数据文件到Standby Database并重建备控制文件,不管 STANDBY _FILE_MANAGEMENT 初始化参数的设置。 下面小节提供了当 STANDBY _FILE_MANAGEMENT 初始化参数分别设置为 AUTO 和MAMUAL 时,添加数据文件到Primary Database的例子。 8.3.1.1 当 STANDBY _FILE_MANAGEMENT 设为 AUTO 时 下面的例子显示了当 STANDBY _FILE_MANAGEMENT 初始化参数设置为 AUTO 时添加新数据文件到Primary Database 和 Standby Database所需的步骤。 1.添加新表空间到Primary Database: SQL> CREATE TABLESPACE new_ts DATAFILE '/disk1/oracle/oradata/payroll/t_db2.dbf' 2> SIZE 1m AUTOEXTEND ON MAXSIZE UNLIMITED; 2.归档当前的联机redo log files,使得redo data将被传送到并在Standby Database上应用: SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; 3.检验新数据文件添加到Primary Database: SQL> SELECT NAME FROM V$DATAFILE; NAME -------------------------------------------------------------- /disk1/oracle/oradata/payroll/t_db1.dbf /disk1/oracle/oradata/payroll/t_db2.dbf 4.检验新数据文件添加到Standby Database: SQL> SELECT NAME FROM V$DATAFILE; NAME -------------------------------------------------------------- /disk1/oracle/oradata/payroll/s2t_db1.dbf /disk1/oracle/oradata/payroll/s2t_db2.dbf 8.3.1.2 当 STANDBY _FILE_MANAGEMENT 设为 MANUAL 时 本小节显示当 STANDBY _FILE_MANAGEMENT 初始化参数设为 MANUAL 时,如何添加新数据文件到Primary Database 和 Standby Database。当备数据文件位于裸设备上时,你必须设置STANDBY _FILE_MANAGEMENT 初始化参数为 MANUAL。本小节也描述如何在错误发生后从错误中恢复。 注: 不要在使用 Oracle Managed Files 的数据库上使用下面的过程。同样,如果在Primary和Standby服务器上的裸设备路径名不是相同,使用 DB_FILE_NAME_CONVERT 初始化参数来转换路径名。 8.3.1.2.1 使用带裸设备的 STANDBY _FILE_MANAGEMENT 参数 通过设置 STANDBY _FILE_MANAGEMENT 参数为 AUTO,不管新数据文件在主数据库上是添加还是删除,相应的更改在Standby Database上就进行,不需要手工介入。只要Standby Database使用文件系统这就是正确的。如果Standby Database使用裸设备作为数据文件,则 STANDBY _FILE_MANAGEMENT 初始化参数将继续工作,但是需要手工介入。这个手工介入包括确保,裸设备在Standby Database上的日志应用服务恢复将要创建新数据文件的redo data之前存在。在Primary Database上,创建新的表空间,其数据文件位于裸设备。在同一时间,在Standby Database上创建同样的裸设备。例如: SQL> CREATE TABLESPACE MTS2 DATAFILE '/dev/raw/raw100' size 1m; Tablespace created. SQL> ALTER SYSTEM SWITCH LOGFILE; System altered. Standby Database当作裸设备已经存在,自动添加数据文件。Standby上警告日志显示如下: Fri Apr 8 09:49:31 2005 Media Recovery Log /u01/MILLER/flash_recovery_area/MTS_STBY/archivelog/2005_04_08/o1 _mf_1_7_15ffgt0z_.arc Recovery created file /dev/raw/raw100 Successfully added datafile 6 to media recovery Datafile #6: '/dev/raw/raw100' Media Recovery Waiting for thread 1 sequence 8 (in transit) 然而,如果裸设备在Primary system(主系统)上但是没有在备上创建,则 MRP 进程将会由于文件创建错误关闭。例如,在Primary Database上执行下面语句: SQL> CREATE TABLESPACE MTS3 DATAFILE '/dev/raw/raw101' size 1m; Tablespace created. SQL> ALTER SYSTEM SWITCH LOGFILE; System altered. Standby system还没有创建/Dave/raw/raw101 裸设备。Standby警告日志在恢复归档时显示下述信息: Fri Apr 8 10:00:22 2005 Media Recovery Log /u01/MILLER/flash_recovery_area/MTS_STBY/archivelog/2005_04_08/o1 _mf_1_8_15ffjrov_.arc File #7 added to control file as 'UNNAMED00007'. Originally created as: '/dev/raw/raw101' Recovery was unable to create the file as: '/dev/raw/raw101' MRP0: Background Media Recovery terminated with error 1274 Fri Apr 8 10:00:22 2005 Errors in file /u01/MILLER/MTS/dump/mts_mrp0_21851.trc: ORA-01274: cannot add datafile '/dev/raw/raw101' - file could not be created ORA-01119: error in creating database file '/dev/raw/raw101' ORA-27041: unable to open file Linux Error: 13: Permission denied Additional information: 1 Some recovered datafiles maybe left media fuzzy Media recovery may continue but open resetlogs may fail Fri Apr 8 10:00:22 2005 Errors in file /u01/MILLER/MTS/dump/mts_mrp0_21851.trc: ORA-01274: cannot add datafile '/dev/raw/raw101' - file could not be created ORA-01119: error in creating database file '/dev/raw/raw101' ORA-27041: unable to open file Linux Error: 13: Permission denied Additional information: 1 Fri Apr 8 10:00:22 2005 MTS; MRP0: Background Media Recovery process shutdown ARCH: Connecting to console port... 8.3.1.2.2 从错误中恢复 要纠正 8.3.1.2.1 节中描述的问题,执行下面步骤: 1.在Standby Database上创建裸分区,并赋予权限给 Oracle 用户。 2.查询 V$DATAFILE 视图。例如: SQL> SELECT NAME FROM V$DATAFILE; NAME -------------------------------------------------------------- /u01/MILLER/MTS/system01.dbf /u01/MILLER/MTS/undotbs01.dbf /u01/MILLER/MTS/sysaux01.dbf /u01/MILLER/MTS/users01.dbf /u01/MILLER/MTS/mts.dbf /dev/raw/raw100 /u01/app/oracle/product/10.1.0/dbs/UNNAMED00007 SQL> ALTER SYSTEM SET STANDBY _FILE_MANAGEMENT=MANUAL; SQL> ALTER DATABASE CREATE DATAFILE 2 '/u01/app/oracle/product/10.1.0/dbs/UNNAMED00007' 3 AS 4 '/dev/raw/raw101'; 3.在备警告日志中你应该看到类似如下的信息: Fri Apr 8 10:09:30 2005 alter database create datafile '/dev/raw/raw101' as '/dev/raw/raw101' Fri Apr 8 10:09:30 2005 Completed: alter database create datafile '/dev/raw/raw101' a 4.在Standby Database上,设置 STANDBY _FILE_MANAGEMENT 为 AUTO 并重启Redo应用: SQL> ALTER SYSTEM SET STANDBY _FILE_MANAGEMENT=AUTO; SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT; 在这个点Redo应用使用新的裸设Standby Database并且恢复继续。 8.3.2 删去表空间和删除数据文件 当你在Primary Database删除一个或更多数据文件或者删去一个或更多表空间时,你也需要删除Standby Database中的相应数据文件。下面小节提供了当 STANDBY _FILE_MANAGEMENT 初始化参数设为 AUTO 或 MANUAL 时,删去表空间和删除数据文件的例子。 8.3.2.1 当 STANDBY _FILE_MANAGEMENT设为AUTO 或 MANUAL时 不管 STANDBY _FILE_MANAGEMENT 初始化参数设为 AUTO 还是 MANUAL 下面过程都起作用: 1.从Primary Database删除表空间 SQL> DROP TABLESPACE tbs_4; SQL> ALTER SYSTEM SWITCH LOGFILE; 2.确保Redo应用正在运行(使得更改应用到Standby Database)。如果下面查询返回 MRP 或MRP0 进程,Redo正在运行。 SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY ; 要检验删除的数据文件不再是数据库的一部分,查询 V$DATAFILE 视图。 3.在archived redo log files应用到Standby Database上后,在Standby system上删除相应的数据文件。例如: % rm /disk1/oracle/oradata/payroll/s2tbs_4.dbf 4.在Primary Database上,在确保Standby Database应用删除表空间的Redo信息的,You can删除表空间的数据文件。例如: % rm /disk1/oracle/oradata/payroll/tbs_4.dbf 8.3.2.2 使用 DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES 还可以在Primary Database上执行 SQL DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES 语句来在Primary Database 和 Standby Database上同时删除数据文件。要使用这个语句,STANDBY _FILE_MANAGEMENT 初始化参数必须设为 AUTO。例如,要在主节点删去表空间: SQL> DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES tbs_4; SQL> ALTER SYSTEM SWITCH LOGFILE; 8.3.3 使用带Physical Standby Database的可传输表空间 你可以使用 Oracle 可传输表空间特性来移动 Oracle 数据库的一个子集,并插入其它 Oracle 数据库,根本地在数据库之间移动表空间。 当使用Physical Standby时,要移动并拷贝一系列表空间到Primary Database,执行下述步骤: 1.生成一个包含要传输表空间集的数据文件的可传输表空间集,和包含该表空间集的结构信息的导出文件。 2.传输表空间集: a.拷贝数据文件和导出文件到Primary Database。 b.拷贝数据文件到Standby Database。 数据文件必须拷贝到由 DB_FILE_NAME_CONVERT 初始化参数定义的目录。如果没有定义 DB_FILE_NAME_CONVERT,则在包含可传输表空间的redo data应用并失败后,执行 ALTER DATABASE RENAME FILE 语句来更改Standby控制文件,STANDBY _FILE_MANAGEMENT 初始化参数必须设为 AUTO。 3.插入表空间。 调用 Data Pump 工具来插入表空间集到Primary Database。redo data将生成并应用到Standby站点以插入表空间到Standby Database。 对于可传输表空间相关的更多信息,查看 Oracle 数据库管理员指南。 8.3.4 在Primary Database中重命名数据文件 当你在Primary Database中重命名一个或更多数据文件时,更改没有传播到Standby Database。因此,如果你想在Standby Database上重命名同样的数据文件,你必须手工在Standby Database上进行等同的更改,因为该更改不会自动执行,即使 STANDBY _FILE_MANAGEMENT 初始化参数设为 AUTO。 下述步骤描述了如何在Primary Database中重命名数据文件和手工传播更改到Standby Database。 1.要在Primary Database中重命名数据文件,将表空间脱机: SQL> ALTER TABLESPACE tbs_4 OFFLINE; 2.从 SQL 提示符退出并执行操作系统命令,如下面的 UNIX mv 命令,来在Primary Database上重命名数据文件: % mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf 3.在Primary Database中重命名数据文件并将表空间联机: SQL> ALTER TABLESPACE tbs_4 RENAME DATAFILE 2> '/disk1/oracle/oradata/payroll/tbs_4.dbf' 3> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf'; SQL> ALTER TABLESPACE tbs_4 ONLINE; 4.连接到Standby Database,查询 V$ARCHIVED_LOG 视图来检验所有archived redo log files都被应用了,然后停止Redo应用: SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#; SEQUENCE# APP --------- --- 8 YES 9 YES 10 YES 11 YES 4 rows selected. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 5.关闭Standby Database: SQL> SHUTDOWN; 6.在Standby node使用操作系统命令重命名数据文件,如 UNIX mv 命令: % mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf 7.启动并安装Standby Database: SQL> STARTUP MOUNT; 8.重命名备控制文件中的数据文件。注意 STANDBY _FILE_MANAGEMENT 初始化 参数必须设置为 MANUAL。 SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/tbs_4.dbf' 2> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf'; 9.在Standby Database上,重启Redo应用: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> DISCONNECT FROM SESSION; 如果你没有在Standby system上重命名相应的数据文件,然后试图刷新Standby Database控制文件,Standby数据库将会企图使用重命名的数据文件,但是它将无法找到。因此,你将在警告日志中看到类似于如下的错误信息: ORA-00283: recovery session canceled due to errors ORA-01157: cannot identify/lock datafile 4 - see DBWR trace file ORA-01110: datafile 4: '/Disk1/oracle/oradata/payroll/tbs_x.dbf' 8.3.5 添加或删除联机redo log files 有时需要更改联机redo log files的大小和数目来调优数据库。可以Primary Database添加联机redo log files组或成员而不影响Standby Database。类似地,还可以rimary Database删去日志文件组或成员而不影响你的Standby Database。然而,这些更改在切换后影响Standby Database的性能。 注意: 无论何时你添加一个联机redo log files到Primary Database,你应该添加相应的联机和备Redo日志文件到Standby Database。 例如,如果Primary Database有 10 个联机redo log files,Standby Database有 2 个,然后你切换到Standby Database使得其作为新的Primary Database起作用,新的Primary Database被迫比原Primary Database更频繁地归档。 因此,当你在主节点添加或删除一个联机redo log files,通过下面这些步骤在Standby Database中同步更改是很重要的: 1.如果Redo应用正在运行,你必须在You can更改日志文件之前取消Redo应用。 2.如果 STANDBY _FILE_MANAGEMENT 初始化参数设为 AUTO,更改该值为MANUAL。 3.添加或删去一个联机redo log files: 要添加一个联机redo log files,使用如下的 SQL 语句: SQL> ALTER DATABASE ADD LOGFILE '/disk1/oracle/oradata/payroll/prmy3.log' SIZE 100M 要删去一个联机redo log files,使用如下的 SQL 语句: SQL> ALTER DATABASE DROP LOGFILE '/disk1/oracle/oradata/payroll/prmy3.log'; 4.在每个Standby Database上充分你在步骤 3 中使用的语句。 5.还原 STANDBY _FILE_MANAGEMENT 初始化参数和Redo应用选项到它们的原始状态。 8.3.6 NOLOGGING 或不可恢复的操作 当你使用 NOLOGGING 或 UNRECOVERABLE 子句执行 DML 或 DDL 操作,Standby Database变得无效并且可能需要很多地 DBA 管理活动来修复。主库上必须指定RCELOGGING 子句 的 SQL> LTER DATABASE 或 SQL ALTER TABLESPACE 语句来覆盖 NOLOGGING 设置。然而,该语句将不会修复已经无效的数据库。 查看 12.10 节以获得在使用 NOLOGGING 子句之后恢复相关的信息。 8.4 通过 OPEN RESETLOGS 语句恢复 Data Guard 允许在Primary Standby Database上的恢复在Primary Database以 RESETLOGS 选项打开后继续。 当在Primary Database上执行 ALTER DATABASE OPEN RESETLOGS 语句时,数据库就发生了改变,创建了新的Redo branch,Primary Standby Database接受到新的redo databranch,Redo应用自动取得新的redo data branch。对于Primary Standby Database,如果Standby Database没有应用新的重置日志 SCN 以前的redo data(新的Redo数据 branch起点以前),则不需要手工介入。下面的表描述如何与Primary Database分支重新同步Standby Database。 8.5 监控Primary Database 和 Standby Database 在本节中可以找到用于监控在 Data Guard 环境中的Primary Database 和 Standby Database的信息。 本节包含下述主题: n 警告日志 n 动态性能视图(固定视图) n 监控恢复过程 n 监控在Primary Standby Database上的日志应用服务 表 8-2 总结了通常在Primary Database上出现的事件,它们指向文件和视图,从那里You can监控这些在Primary和Standby node上的事件。 表 8-2 定位在Primary Database上哪里能监控普通活动 8.5.1 警告日志 数据库警告日志是信息和错误的按时间排序的记录。除了提供 Oracle 数据库相关信息以外, 它也包括 Data Guard 特定操作的相关信息,包括如下: 管理操作如下面 SQL 语句:ALTER DATABASE RECOVER MANAGED STANDBY ,STARTUP,SHUTDOWN,ARCHIVE LOG,和 RECOVER 的相关信息 由后台进程如 ARC0,MRP0,RFS,LGWR 报告的管理操作的相关错误d 管理操作的完整时间戳警告日志也提供指向由指定进程生成的跟踪或转储文件。 8.5.2 动态性能视图(固定视图) Oracle 数据库包含一系列基础视图。这些视图经常被称为动态性能视图,因为它们是在数据库打开和使用中是连续更新的,并且它们的内容主要与性能相关。这些视图也称为固定视图,因为它们不能被数据库管理员更改或删除。 这些视图名字以 V$或 GV$前缀,例如,V$ARCHIVE_DEST 或 GV$ARCHIVE_DEST。 标准动态性能视图(V$固定视图)存储本地instance相关信息。相对地,全局动态性能视图(GV$固定视图)存储在 Real Applications Cluster(RAC)中所有打开instance的相关信息。 每个 V$固定视图有一个相应的 GV$固定视图。在 GV$固定视图上的选择使用并行查询从进程来获得所有instance上的信息。查看第 16 章,“Oracle Data Guard 相关视图”和“Oracle 数据库参考”以获得额外信息。 8.5.3 监控恢复过程 本小节显示在 8.5.2 节中讨论的视图类型的一些例子,以用来监控 Data Guard 环境中的恢复过程。它包含下述例子: n 监控进程活动 n 确定Redo应用过程 n 确定archived redo log files的位置和创建者 n 查看 OPEN RESETLOGS 前后的数据库化身 n 查看归档redo log历史 n 确定哪些日志文件被应用到Standby Database n 确定哪些日志文件还没有被Standby node接收到 8.5.3.1 监控进程活动 在Standby Database上You can通过监控由下述进程执行的活动来获得Redo应用相关的信息: 在Standby Database节点上的 V$MANAGED_STANDBY 视图显示给你在 Data Guard 环境中Redo transport和Redo Apply services执行的活动。在下面查询结果中的 CLIENT_P 列确定了相应的主数据库进程。 SQL> SELECT PROCESS, CLIENT_PROCESS, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY ; PROCESS CLIENT_P SEQUENCE# STATUS ------- -------- ---------- ------------ ARCH ARCH 0 CONNECTED ARCH ARCH 0 CONNECTED MRP0 N/A 204 WAIT_FOR_LOG RFS LGWR 204 WRITING RFS N/A 0 RECEIVING 8.5.3.2 确定Redo应用的过程 在主或Standby Database节点上的 V$ARCHIVE_DEST_STATUS 视图提供给你信息,如已归档的联机redo log files,已应用的archived redo log files,和每个日志序列号。下述查询输出显示Standby Database应用从Primary Database接收的redo data已经落后了两个archived redo log files,就是有了两个归档日志文件的差异。 SQL> SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ# 2> FROM V$ARCHIVE_DEST_STATUS; ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# ---------------- ------------- --------------- ------------ 1 947 1 945 8.5.3.3 确定archived redo log files的位置和创建者 在Standby Database上查询 V$ARCHIVED_LOG 视图来找到归档redo log相关的额外信息。你能获得的一些信息包括归档redo log的位置,那个进程创建归档redo log,每个归档Redo日志文件的redo log序列号,每个日志文件何时归档,以及archived redo log files是否被应用。例如: SQL> SELECT NAME, CREATOR, SEQUENCE#, APPLIED, COMPLETION_TIME 2> FROM V$ARCHIVED_LOG; NAME CREATOR SEQUENCE# APP COMPLETIO ---------------------------------------------- ------- --------- --- --------- H:\ORACLE\ORADATA\PAYROLL\STANDBY \ARC00198.001 ARCH 198 YES 30-MAY-02 H:\ORACLE\ORADATA\PAYROLL\STANDBY \ARC00199.001 ARCH 199 YES 30-MAY-02 H:\ORACLE\ORADATA\PAYROLL\STANDBY \ARC00200.001 ARCH 200 YES 30-MAY-02 H:\ORACLE\ORADATA\PAYROLL\STANDBY \ARC00201.001 LGWR 201 YES 30-MAY-02 H:\ORACLE\ORADATA\PAYROLL\STANDBY \ARC00202.001 ARCH 202 YES 30-MAY-02 H:\ORACLE\ORADATA\PAYROLL\STANDBY \ARC00203.001 LGWR 203 YES 30-MAY-02 6 rows selected. 8.5.3.4 查看 OPEN RESETLOGS 前后的数据库化身 在Standby Database上查询 V$DATABASE_INCARNATION 视图来监控数据库化身和RESETLOGS_ID 列。在Primary Database上执行 OPEN RESETLOGS 语句之前在Standby Database上执行下述查询: SQL> SELECT INCARNATION#, RESETLOGS_ID, STATUS FROM V$DATABASE_INCARNATION ; INCARNATION# RESETLOGS_ID STATUS ------------ ------------ ------- 1 509191005 PARENT 2 509275501 CURRENT SQL> SELECT RESETLOGS_ID,THREAD#,SEQUENCE#,STATUS,ARCHIVED FROM V$ARCHIVED_LOG 2 ORDER BY RESETLOGS_ID,SEQUENCE# ; RESETLOGS_ID THREAD# SEQUENCE# S ARC ------------ ------- --------- - ---- 509275501 1 1 A YES 509275501 1 2 A YES 509275501 1 3 A YES 509275501 1 4 A YES 509275501 1 5 A YES 5 rows selected. 在Primary Database上执行 OPEN RESETLOGS 语句之后在Standby Database上执行下述查询,并且Standby Database开始在新的Redo branch接受redo data: SQL> SELECT INCARNATION#, RESETLOGS_ID, STATUS FROM V$DATABASE_INCARNATION ; INCARNATION# RESETLOGS_ID STATUS ------------ ------------ ------- 1 509191005 PARENT 2 509275501 PARENT 3 509278970 CURRENT SQL> SELECT RESETLOGS_ID,THREAD#,SEQUENCE#,STATUS,ARCHIVED FROM V$ARCHIVED_LOG 2 ORDER BY RESETLOGS_ID,SEQUENCE# ; RESETLOGS_ID THREAD# SEQUENCE# S ARC ------------ ------- --------- - --- 509275501 1 1 A YES 509275501 1 2 A YES 509275501 1 3 A YES 509275501 1 4 A YES 509275501 1 5 A YES 509278970 1 1 A YES 509278970 1 2 A YES 509278970 1 3 A YES 8 rows selected. 8.5.3.5 查看归档redo log历史 在Standby node上的 V$LOG_HISTORY 显示给你一个归档redo log的完整历史,包括如第一个条目的时间,日志中最低的 SCN,日志中最高的 SCN,和archived redo log files的序列号。 SQL> SELECT FIRST_TIME, FIRST_CHANGE#, NEXT_CHANGE#, SEQUENCE# FROM V$LOG_HISTORY; FIRST_TIM FIRST_CHANGE# NEXT_CHANGE# SEQUENCE# --------- ------------- ------------ ---------- 13-MAY-02 190578 214480 1 13-MAY-02 214480 234595 2 13-MAY-02 234595 254713 3 30-MAY-02 3418615 3418874 201 30-MAY-02 3418874 3419280 202 30-MAY-02 3419280 3421165 203 203 rows selected. 8.5.3.6 确定哪些日志文件被应用到Standby Database 在Standby Database上查询 V$LOG_HISTORY 视图,它记录已应用的最近的日志序列号。例如,执行下述查询: SQL> SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG" 2> FROM V$LOG_HISTORY 3> GROUP BY THREAD#; THREAD# LAST_APPLIED_LOG ------- ---------------- 1 967 在这个例子中,日志序列号 967 的archived redo log files是最近应用的日志文件。 你也能在Standby Database上使用 V$ARCHIVED_LOG 固定视图的 APPLIED 列来找出哪些日志文件被应用到Standby Database上。例如: SQL> SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG; THREAD# SEQUENCE# APP ---------- ---------- --- 1 2 YES 1 3 YES 1 4 YES 1 5 YES 1 6 YES 1 7 YES 1 8 YES 1 9 YES 1 10 YES 1 11 NO 10 rows selected. 管理Primary Standby Database 8-18 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 8.5.3.7 确定哪些日志文件还没有被Standby node接收到 每个归档Destination有一个分配给它的Destination ID。You can查询 V$ARCHIVE_DEST 固定视图 的 DEST_ID 列来找出你的Destination ID。然后You can在Primary Database上的查询中使用这个Destination ID 来找到还没有发送到特定Standby node的日志文件。 例如,假设在你的Primary Database上的当前本地归档Destination ID 是 1,你的远程Standby Database之一 的Destination ID 是 2。要找到哪些日志文件还没有被这个Standby Destination接收到,在Primary Database上执行 下述查询: SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM 2> (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) LOCAL 3> WHERE LOCAL.SEQUENCE# NOT IN 5> (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND 6> THREAD# = LOCAL.THREAD#); THREAD# SEQUENCE# ---------- ---------- 1 12 1 13 1 14 前面所述例子显示了还没有被Standby Destination 2 接受到的日志文件。 8.5.4 监控在Primary Standby Database上的日志应用服务 要监控在Primary 备数据上的日志应用服务的状态,查询在本小节中描述的固定视图。你 也可以使用 Oracle 企业管理器 GUI 来监控Standby Database。 本小节包含下述主题: d 访问 V$DATABASE 视图 d 访问 V$MANAGED_STANDBY 固定视图 d 访问 V$ARCHIVE_DEST_STATUS 固定视图 d 访问 V$ARCHIVED_LOG 固定视图 d 访问 V$LOG_HISTORY 固定视图 d 访问 V$DATAGUARD_STATUS 固定视图 同时,查看 Oracle 数据库参考以获得视图相关的完整参考信息。 8.5.4.1 访问 V$DATABASE 视图 执行下述查询来显示保护模式、保护级别、数据库的角色和切换状态相关的信息: SQL> SELECT DATABASE_ROLE, DB_UNIQUE_NAME INSTANCE, OPEN_MODE, PROTECTION_MODE, PROTECTION_LEVEL, SWITCHOVER_STATUS FROM V$DATABASE; 执行下述查询来显示快速启动failover相关的信息: 管理Primary Standby Database 8-19 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 SQL> SELECT FS_FAILOVER_STATUS FSFO_STATUS, FS_FAILOVER_CURRENT_TARGET TARGET_STANDBY , FS_FAILOVER_THRESHOLD THRESHOLD, FS_FAILOVER_OBSERVER_PRESENT OBS_PRES FROM V$DATABASE; 8.5.4.2 访问 V$MANAGED_STANDBY 固定视图 查询Primary Standby Database来在Standby node监控Redo应用和Redo transport services活动。 SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS 2> FROM V$MANAGED_STANDBY ; PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS ------- ----------- -------- ---------- -------- ---------- RFS ATTACHED 1 947 72 72 MRP0 APPLYING_LOG 1 946 10 72 前面的查询输出显示 RFS 进程完成归档序列号 947 的日志文件。输出也显示Redo应用 正活动应用一个序列号 946 的archived redo log files。恢复操作当前正在恢复 72 个块的归档重 做日志文件中的第 10 号块。 8.5.4.3 访问 V$ARCHIVE_DEST_STATUS 固定视图 要快速确定Standby Database的同步级别,在Primary Standby Database上执行下述查询: SQL> SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ# 2> FROM V$ARCHIVE_DEST_STATUS; ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# ---------------- ------------- --------------- ------------ 1 947 1 945 前面的查询输出显示Standby Database落后于Primary Database两个archived redo log files。 要确定是否允许实时应用,查询 V$ARCHIVE_DEST_STATUS 视图的 RECOVERY_MODE 列。当允许实时应用时它将包含值为 MANAGED REAL TIME APPLY, 如下面例子所示: SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2 ; RECOVERY_MODE ----------------------- MANAGED REAL TIME APPLY 8.5.4.4 访问 V$ARCHIVED_LOG 固定视图 Primary Standby Database上的 V$ARCHIVED_LOG 固定视图显示所有从Primary Database接收到的归档重 做日志文件。该视图只有在Standby node开始接收redo data才有用;在那个时间以前,该视图由从 管理Primary Standby Database 8-20 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 主控制文件生成的旧的归档redo log记录构成。 例如,You can执行下述 SQL*Plus 语句: SQL> SELECT REGISTRAR, CREATOR, THREAD#, SEQUENCE#, FIRST_CHANGE#, 2> NEXT_CHANGE# FROM V$ARCHIVED_LOG; REGISTRAR CREATOR THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# --------- ------- --------- ---------- ------------- ------------ RFS ARCH 1 945 74651 74739 RFS ARCH 1 946 74739 74772 RFS ARCH 1 947 74772 74774 前面的查询输出显示从Primary Database接收三个archived redo log files。 8.5.4.5 访问 V$LOG_HISTORY 固定视图 在Primary Standby Database上查询 V$LOG_HISTORY 固定视图来显示所有已应用的归档redo log 文件。 SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# 2> FROM V$LOG_HISTORY; THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# --------- ---------- ------------- ------------ 1 945 74651 74739 前面的查询输出显示最近应用的archived redo log files是序列号 945。 8.5.4.6 访问 V$DATAGUARD_STATUS 固定视图 V$DATAGUARD_STATUS 固定视图显示了典型地可能被任何消息触发到警告日志或 服务进程跟踪文件的事件。 下面的例子显示了在Primary Database上从 V$DATAGUARD_STATUS 视图的输出: SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS; MESSAGE ----------------------------------------------------------------- ARC0: Archival started ARC1: Archival started Archivelog destination LOG_ARCHIVE_DEST_2 validated for no-data-loss recovery Creating archive destination LOG_ARCHIVE_DEST_2: 'dest2' ARCH: Transmitting activation ID 0 LGWR: Completed archiving log 3 thread 1 sequence 11 Creating archive destination LOG_ARCHIVE_DEST_2: 'dest2' LGWR: Transmitting activation ID 6877c1fe LGWR: Beginning to archive log 4 thread 1 sequence 12 ARC0: Evaluating archive log 3 thread 1 sequence 11 管理Primary Standby Database 8-21 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 ARC0: Archive destination LOG_ARCHIVE_DEST_2: Previously completed ARC0: Beginning to archive log 3 thread 1 sequence 11 Creating archive destination LOG_ARCHIVE_DEST_1: '/oracle/arch/arch_1_11.arc' ARC0: Completed archiving log 3 thread 1 sequence 11 ARC1: Transmitting activation ID 6877c1fe 15 rows selected. 下面的例子显示了在Primary 被数据库上从 V$DATAGUARD_STATUS 视图的内容: SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS; MESSAGE ----------------------------------------------------------------- ARC0: Archival started ARC1: Archival started RFS: Successfully opened Standby logfile 6: '/oracle/dbs/sorl2.log' ARC1: Evaluating archive log 6 thread 1 sequence 11 ARC1: Beginning to archive log 6 thread 1 sequence 11 Creating archive destination LOG_ARCHIVE_DEST_1: '/oracle/arch/arch_1_11.arc' ARC1: Completed archiving log 6 thread 1 sequence 11 RFS: Successfully opened Standby logfile 5: '/oracle/dbs/sorl1.log' Attempt to start background Managed Standby Recovery process Media Recovery Log /oracle/arch/arch_1_9.arc 10 rows selected. 8.6 为Primary Standby Database调优日志应用速度 考虑使用下述方法来优化应用Redo到Primary Standby Database所需的时间。同时,查看 Oracle Media Recovery Best Practices 白皮书以获得更多信息: http://otn.oracle.com/deploy/availability/htdocs/maa.htm. 在一个备主机上设置并行恢复为 CPU 数目的两倍 在媒质恢复或Redo应用期间,redo log files被读取,需要Redo应用的数据块被分析出 来。使用并行媒质恢复,这些数据块连续平均分布到所有恢复进程来被读取到高速缓存。默 认是串行恢复或零并行度,这意味这同一恢复进程读取Redo,从磁盘读取数据块,并应用重 做更改。 要实施并行媒质恢复或Redo应用,添加可选的 PARALLEL 子句到恢复命令。进一步地, 设置数据库参数 PARALLEL_MAX_SERVERS 为最少的并行度。下面例子显示了如何设置 恢复并行度: RECOVER STANDBY DATABASE PARALLEL #CPUs * 2; 管理Primary Standby Database 8-22 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 你应该比较多个串行和并行恢复运行以确定最优的恢复性能。 为快速Redo应用率设置 DB_BLOCK_CHECKING=FALSE 在备或媒质恢复期间设置 DB_BLOCK_CHECKING=FALSE 参数能提供几乎两倍的应 用速度。在恢复过程中缺少块校验必须是可接收的风险。块校验应该在Primary Database上允许。 DB_BLOCK_CHECKSUM=TRUE(默认值)应该在生产和Standby Database上都允许。因为 DB_BLOCK_CHECKING 参数是动态的,它能在不关闭Standby Database的情况下转换。 设置 PARALLEL_EXECUTION_MESSAGE_SIZE=4096 当使用并行媒质恢复或并行备恢复,增加 PARALLEL_EXECUTION_MESSAGE_SIZE 数据库参数为 4K(4096)能增加并行恢复大概百分之二十的性能。在Primary Database 和 Standby Database上同时 设置这个参数是为了切换操作做准备。增加这个参数每个并行执行从进程需要更多共享池中 的内存。 并行查询操作也使用 PARALLEL_EXECUTION_MESSAGE_SIZE 参数,应该与一些并 行查询操作一起测试以确保在系统上有足够的内存。在 32 位安装上的大量并行查询从进程 可能会达到内存限制并禁止 PARALLEL_EXECUTION_MESSAGE_SIZE 从默认的 2K (2048)增加到 4K。 调优磁盘 I/O 在恢复期间遇到的最大瓶颈是读和写 I/O。要释放这个瓶颈,使用本地异步 I/O 并设置 数据库参数 DISK_ASYNCH_IO 为 TRUE(默认值)。DISK_ASYNCH_IO 参数控制到数据 文件的磁盘 I/O 是否是异步的。异步 I/O 应该能显著地降低数据库文件并行读,并且应该改 进整个恢复时间。 管理Primary Standby Database 8-23 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 9 管理Logical Standby Database 本章包含下述主题: d SQL 应用架构概述 d 管理和监控Logical Standby Database相关的视图 d 监控Logical Standby Database d 定制Logical Standby Database d 管理Logical Standby Database环境下的特定工作负载 d 调优Logical Standby Database 9.1 SQL 应用架构概述 SQL 应用使用一些并行执行服务器和后台进程的集合来应用从Primary Database的更改到逻辑 Standby Database。 图 9-1 显示了信息的流和每个进程执行的角色。 图 9-1 SQL 应用过程 包括的不同进程和它们在日志提取与应用过程期间的作用如下: 在日志提取期间: d READER 进程从archived redo log files或Standby redo log files读取Redo记录。 d PREPARER 进程转换在Redo记录中包含的块更改为逻辑更改记录(LCRs)。对于 给定的archived redo log files或Standby redo log files能有多个 PREPARER 进程激活。LCRs 驻留在系统全局区(SGA)的共享池中,称为 LCR 缓存。 d BUILDER 进程组织 LCRs 为事务,并执行其它任务,如 LCR 缓存中的内存管理, SQL 应用重启相关的检查点和过滤不感兴趣的更改。 在应用过程期间: d ANALYZER 进程检查包含一组 LCRs 的事务块,可能过滤出不感兴趣的事务,并 识别不同事务之间的依赖性。 d COORDINATOR 进程(LSP): 管理Logical Standby Database 9-1 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 e 分配事务 e 监控事务间的依赖性并协调调度 e 批准更改向Logical Standby Database的提交 d APPLIER 进程: e 应用 LCRs 到数据库 e 要求 COORDINATOR 进程批准有未解决依赖性的事务 e 提交事务 You can查询 V$LOGSTDBY_PROCESS 事务来检查 SQL 应用过程的活动。提供当前活动 信息的其它视图是 V$LOGSTDBY_STATS 视图,其显示Logical Standby Database在 SQL 应用活动期间 的状态信息。这些和其它相关视图在 9.2 节,“管理和监控Logical Standby Database”中更详细地讨论。 9.1.1 对于 SQL 应用的不同考虑 本小节包含下述主题: d 事务大小考虑 d 页面交换考虑 d 重启考虑 d DML 应用考虑 d DDL 应用考虑 9.1.1.1 事务大小考虑 SQL 应用划分事务为两类:小的和大的: d 小事务——SQL 应用一旦遇到redo log files中事务的提交记录就开始应用属于小 事务的 LCRs。 d 大事务——SQL 应用分开大事务为小的片称为事务块,并在redo log files中看到 的大事务的提交记录之前开始应用块。这是为了减少 LCR 缓存上的内存压力并减 少整个failover时间。 例如,不分开到小片的话,SQL*Loader 转载一千万行,每行大小 100 字节,可能 会在 LCR 缓存中使用超过 1GB 内存。如果分配给 LCR 缓存的内存小于 1GB,就会导 致 LCR 缓存的页面交换。 除了内存考虑以外,如果 SQL 应用不开始应用一千万行 SQL*Loader 装载相关的 更改,直到遇到事务的 COMMIT 记录,就可能会停止角色转换。在事务提交之后发起 的切换或failover无法完成,直到 SQL 应用在Logical Standby Database上应用了事务。 所有的事务一开始被分类为小事务。依赖与 LCR 缓存可用的内存数量和属于一个事务 的 LCR 使用的内存数量,SQL 应用确定何时重新分类一个事务为大事务。 9.1.1.2 页面交互考虑 页面交互出现在 SQL 应用的环境中,当 LCR 缓存中的内存用尽了并且需要释放空间给 SQL 应用向前处理。 例如,假设分配给 LCR 缓存的内存是 100MB,并且 SQL 应用遇到一个的 INSERT 事 务,有一个 300MB 大小的 LONG 列。在这个情况下,日志提取组件将会页面交换出 LONG 数据的第一部分来读取列更改的后面部分。在一个优化好的Logical Standby Database中,页面交换活动 只会偶尔出现并且应该不影响系统的整个吞吐量。 管理Logical Standby Database 9-2 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 同时查看: 查看 9.4 节,“定制Logical Standby Database”以获得如何确定造成问题的页面交换并执行正确的 操作的更多相关信息。 9.1.1.3 重启考虑 向Logical Standby Database的更改不会变得持久,直到事务的提交记录从redo log files中提取到 并应用到Logical Standby Database。因此,每次 SQL 应用停止时,不管是作为用户指令的结果还是因 为系统故障,SQL 应用必须返回并再次提取最早的未提交的事务。 在事务做很少工作但是保持长时间打开的情况下,重启 SQL 应用的代价十分惊人。这 是因为 SQL 应用可能必须再次提取大量archived redo log files,仅仅是为了读取少量未提交事 务的redo data。要减轻这个,SQL 应用定时地检查点旧的未提交的数据。在检查点进行的 SCN 反应在 V$LOGSTDBY_PROGRESS 视图的 RESTART_SCN 列中。随着重启,SQL 应 用开始提取比 RESTART_SCN 列中所示的值更高的 SCN 上生成的Redo记录。对于重启不需 要的archived redo log files被 SQL 应用自动删除。 通常的工作负载,如大的 DDL 事务,并行 DML 语句(PDML),以及直接路径装载, 将阻止 RESTART_SCN 在工作负载期间前进。 9.1.1.4 DML 应用考虑 SQL 应用当应用影响Logical StandBy database上的吞吐量和延迟的 DML 事务时有如下特性: d 在单语句导致多行更改的地方,在Primary Database上的批量更新或删除,在Logical StandBy database 库上作为单独行更改而应用。因此,对于每个维护的表必须有唯一或主键。查看 4.1.2 节,“确保在Primary Database上的表行能被唯一标识”以获得更多信息。 d 在Primary Database上直接路径插入在Logical Standby Database上使用常规 INSERT 语句。 d 并行 DML(PDML)事务在Logical Standby Database上不以并行执行。 9.1.1.5 DDL 应用考虑 SQL 应用当应用影响Logical StandBy database上的吞吐量和延迟的 DDL 事务时有如下特性: d 并行 DDL(PDDL)事务在Logical Standby Database上不以并行执行。 d DDL 事务在Logical Standby Database上串行应用。因此,在Primary Database上并行应用的 DDL 事务 在Logical Standby Database上一次应用一个。 d 如执行 CREATE TABLE AS SELECT(CTAS)那样的语句,DML 活动(CTAS 语句 的一部分)在Logical Standby Database上被抑制。插入到新建立的表中的行作为 CTAS 语句的 一部分被从redo log files中提取并使用 INSERT 语句应用到Logical Standby Database中。 9.2 管理和监控Logical Standby Database相关的视图 下面性能视图监控维护Logical Standby Database的 SQL 应用的行为。下述小节描述了能用于监控 Logical Standby Database的关键视图: d DBA_LOGSTDBY_EVENTS 视图 d DBA_LOGSTDBY_LOG 视图 d V$LOGSTDBY_STATS 视图 d V$LOGSTDBY_PROCESS 视图 d V$LOGSTDBY_PROGRESS 视图 管理Logical Standby Database 9-3 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 d V$LOGSTDBY_STATE 视图 d V$LOGSTDBY_STATS 视图 9.2.1 DBA_LOGSTDBY_EVENTS 视图 DBA_LOGSTDBY_EVENTS 视图记录在 SQL 应用操作期间发生的感兴趣的事件。默认 地,该视图记录最近的 100 个事件。然而,You can通过调用 DBMS_LOGSTDBY.APPLY_SET() PL/SQL 过程来更改记录事件的数目。如果 SQL 应用应该未预料地停止,问题的原因也记录 在该视图中。 注: 造成 SQL 应用停止的错误记录在这个事件表中。这些事件也记录到 ALERT.LOG 中, 以 LOGSTDBY 关键词包含在文本中。当查询视图时,以 EVENT_TIME_STAMP、 COMMIT_SCN、CURRENT_SCN 排序选择列。该顺序确保关闭故障出现在视图的最后面。 该视图也包含其它信息,如哪些 DDL 事务被应用以及哪些被跳过了。例如: SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS'; Session altered. SQL> COLUMN STATUS FORMAT A60 SQL> SELECT EVENT_TIME, STATUS, EVENT FROM DBA_LOGSTDBY_EVENTS 2 ORDER BY EVENT_TIMESTAMP, COMMIT_SCN; EVENT_TIME STATUS ----------------------------------------------------------------- EVENT ----------------------------------------------------------------- 23-JUL-02 18:20:12 ORA-16111: log mining and apply setting up 23-JUL-02 18:25:12 ORA-16128: User initiated shut down successfully completed 23-JUL-02 18:27:12 ORA-16112: log mining and apply stopping 23-JUL-02 18:55:12 ORA-16128: User initiated shut down successfully completed 23-JUL-02 18:57:09 ORA-16111: log mining and apply setting up 23-JUL-02 20:21:47 ORA-16204: DDL successfully applied create table hr.test_emp (empno number, ename varchar2(64)) 23-JUL-02 20:22:55 ORA-16205: DDL skipped due to skip setting create database link link_to_boston connect to system identified by change_on_inst 7 rows selected. 上面查询显示 SQL 应用多次开始和停止。它也显示哪些 DDL 被应用和跳过了。如果 SQL 应用停止了,查询中的最后记录将显示问题的原因。 同时查看: Oracle 数据库参考中的 DBA_LOGSTDBY_EVENTS 视图。 管理Logical Standby Database 9-4 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 9.2.2 DBA_LOGSTDBY_LOG 视图 DBA_LOGSTDBY_LOG 视图提供了被 SQL 应用处理的归档日志的动态相关信息。 例如: SQL> COLUMN DICT_BEGIN FORMAT A10; SQL> SET NUMF 9999999 SQL> SELECT FILE_NAME, SEQUENCE# AS SEQ#, FIRST_CHANGE# AS FCHANGE#, NEXT_CHANGE# AS NCHANGE#, TIMESTAMP, - DICT_BEGIN AS BEG, DICT_END AS END, - THREAD# AS THR# FROM DBA_LOGSTDBY_LOG - ORDER BY SEQUENCE#; FILE_NAME SEQ# F_SCN N_SCN TIMESTAM BEG END THR# APPLIED ------------------------- ---- ------- ------- -------- --- --- --- --------- /oracle/dbs/hq_nyc_2.log 2 101579 101588 11:02:58 NO NO 1 YES /oracle/dbs/hq_nyc_3.log 3 101588 142065 11:02:02 NO NO 1 YES /oracle/dbs/hq_nyc_4.log 4 142065 142307 11:02:10 NO NO 1 YES /oracle/dbs/hq_nyc_5.log 5 142307 142739 11:02:48 YES YES 1 YES /oracle/dbs/hq_nyc_6.log 6 142739 143973 12:02:10 NO NO 1 YES /oracle/dbs/hq_nyc_7.log 7 143973 144042 01:02:11 NO NO 1 YES /oracle/dbs/hq_nyc_8.log 8 144042 144051 01:02:01 NO NO 1 YES /oracle/dbs/hq_nyc_9.log 9 144051 144054 01:02:16 NO NO 1 YES /oracle/dbs/hq_nyc_10.log 10 144054 144057 01:02:21 NO NO 1 YES /oracle/dbs/hq_nyc_11.log 11 144057 144060 01:02:26 NO NO 1 CURRENT /oracle/dbs/hq_nyc_12.log 12 144060 144089 01:02:30 NO NO 1 CURRENT /oracle/dbs/hq_nyc_13.log 13 144089 144147 01:02:41 NO NO 1 NO 在 BEG 和 END 列中的 YES 条目指出 LogMiner dictionary build 在日志文件序列号 5 开 始。最近的archived redo log files是序列号 13,并且它是在 01:02:41 在Logical Standby Database上接收 到的。APPLIED 列指出 SQL 应用已经应用了在 SCN144057 以前的所有Redo。因为事务能 跨多个归档日志文件,所以可以有多个归档日志文件在 APPLIED 列中显示 CURRENT 值。 管理Logical Standby Database 9-5 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 同时查看: Oracle 数据库参考中的 DBA_LOGSTDBY_LOG 视图 9.2.3 V$LOGSTDBY_STATUS 视图 该视图提供了Logical Standby Database的failover特性的相关信息,包括: 到failover的时间(apply finish time) 在Logical Standby Database中已提交的数据有多新(lag time) 在灾难发生的情况下可能会丢失什么数据(potential data loss) 例如: SQL> SELECT NAME, VALUE, TIME_COMPUTED FROM V$LOGSTDBY_STATS; NAME VALUE TIME_COMPUTED ------------------ -------------- --------------------- apply finish time +00 00:00:00.1 07-APR-2005 08:29:23 lag time +00 00:00:00.1 07-APR-2005 08:29:23 potential data loss +00 00:00:00 07-APR-2005 08:29:23 每个显示的列的单位(量度)以天(2)到秒(1)为间隔。输出确认一个Logical StandBy database 库紧跟于Primary Database后在 0.1 秒之内,并且在Primary Database故障的情况下没有数据丢失会发生。 同时查看: Oracle 数据库参考中的 V$LOGSTDBY_STATS 视图 9.2.4 V$LOGSTDBY_PROCESS 视图 该视图提供涉及 SQL 应用的不同进程的当前状态的相关信息,包括: d 确认信息(sid | serial# | spid) d SQL 应用进程:COORDINATOR、READER、BUILDER、PREPARER、ANALYZER、 或 APPLIER(type) d 进程当前活动的状态(status_code | status) d 这个进程处理的最高Redo记录(high_scn) 例如: SQL> COLUMN LID FORMAT 9999 SQL> COLUMN SERIAL# FORMAT 9999 SQL> COLUMN SID FORMAT 9999 SQL> SELECT SID, SERIAL#, LOGSTDBY_ID AS LID, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_PROCESS; SID SERIAL# LID SPID TYPE HIGH_SCN ----- ------- ----- -------- --------------- ---------- 48 6 -1 11074 COORDINATOR 7178242899 56 56 0 10858 READER 7178243497 46 1 1 10860 BUILDER 7178242901 45 1 2 10862 PREPARER 7178243295 管理Logical Standby Database 9-6 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 37 1 3 10864 ANALYZER 7178241034 36 1 4 10866 APPLIER 7178239467 35 3 5 10868 APPLIER 7178239463 34 7 6 10870 APPLIER 7178239461 33 1 7 10872 APPLIER 7178239472 9 rows selected. HIGH_SCN 列显示读进程在所有其它进程之前,并且 PREPARER 和 BUILDER 进程在 剩余的前面。 SQL> COLUMN STATUS FORMAT A40 SQL> SELECT TYPE, STATUS_CODE, STATUS FROM V$LOGSTDBY_PROCESS; TYPE STATUS_CODE STATUS ------------- ----------- ----------------------------------------- COORDINATOR 16117 ORA-16117: processing READER 16127 ORA-16127: stalled waiting for additional transactions to be applied BUILDER 16116 ORA-16116: no work available PREPARER 16116 ORA-16117: processing ANALYZER 16120 ORA-16120: dependencies being computed for transaction at SCN 0x0001.abdb440a APPLIER 16124 ORA-16124: transaction 1 13 1427 is waiting on another transaction APPLIER 16121 ORA-16121: applying transaction with commit SCN 0x0001.abdb4390 APPLIER 16123 ORA-16123: transaction 1 23 1231 is waiting for commit approval APPLIER 16116 ORA-16116: no work available 输出显示 SQL 应用运行的快照。在提取一边,READER 进程在它能读取更多内存之前 等待额外的可用内存,PREPARER 进程处理Redo记录,并且 BUILDER 进程没有可用的工作。 在应用一边,COORDINATOR 分配更多的事务给 APPLIER 进程,ANALYZER 计算 SCN 7178241034 处的依存关系,一个 APPLIER 没有可用的工作,而其它两个有还未解决的还没 有满足的依存关系。 同时查看: Oracle 数据库参考中的 V$LOGSTDBY_PROCESS 以获得参考信息和 9.3.1 节,“监控 SQL 应用过程”以获得例子输出 9.2.5 V$LOGSTDBY_PROGRESS 视图 该视图提供了 SQL 应用进展的过程的相关详细信息,包括: d SCN 或时间,在那个点所有在Primary Database上已经提交的事务已经应用到Logical StandBy database 库上(applied_scn | applied_time) 管理Logical Standby Database 9-7 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 d SCN 或时间,在那个点 SQL 应用将开始在重启动上读取Redo记录(restart_scn | restart_time) d 最近的Redo记录在Logical Standby Database上接收到的 SCN 或时间(latest_scn | latest_time) d 由 BUILDER 进程处理的最近的记录的 SCN 或时间(mining_scn | mining_time) 例如: SQL> SELECT APPLIED_SCN, LATEST_SCN, MINING_SCN, RESTART_SCN FROM V$LOGSTDBY_PROGRESS; APPLIED_SCN LATEST_SCN MINING_SCN RESTART_SCN ----------- ----------- ---------- ----------- 7178240496 7178240507 7178240507 7178219805 依照输出: d SQL 应用已经应用了所有在 SCN 7178240496 上或之前已提交的事务 d 在Logical Standby Database接收到的最近的Redo记录是在 SCN 7178240507 生成的 d 提取组件已经处理了所有在 SCN 7178240507 上或之前生成的Redo记录 d 如果 SQL 应用由于任何原因停止并重启,它将开始提取在 SCN 7178219805 上或 之后生成的Redo记录 SQL> ALTER SESSION SET NLS_DATE_FORMAT='yy-mm-dd hh24:mi:ss'; Session altered SQL> SELECT APPLIED_TIME, LATEST_TIME, MINING_TIME, RESTART_TIME FROM V$LOGSTDBY_PROGRESS; APPLIED_TIME LATEST_TIME MINING_TIME RESTART_TIME ----------------- ----------------- ----------------- ----------------- 05-05-12 10:38:21 05-05-12 10:41:21 05-05-12 10:41:53 05-05-12 10:09:30 依照输出: d SQL 应用已经应用了所有在时间 05-05-12 10:38:21(APPLIED_TIME)上或之前已 提交的事务 d Primary Database上最近的Redo是在时间 05-05-12 10:41:53(LASTED_TIME)生成的 d 提取引擎已经处理了所有在 05-05-12 10:41:21 上或之前生成的Redo记录 (MINING_TIME) d 在重启的情况下,SQL 应用将开始提取在时间 05-05-12 10:09:30 以后生成的Redo 记录 同时查看: Oracle 数据库参考中的 V$DATAGUARD_PROGRESS 视图以获得参考信息和 9.3.1 节, “监控 SQL 应用过程”以获得例子输出 9.2.6 V$LOGSTDBY_STATE 视图 管理Logical Standby Database 9-8 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 该视图提供了 SQL 应用的当前状态的概要,包括: d Primary Database的 DBID(Primary _dbid) d 分配给 SQL 应用的 LogMiner 会话 ID(session_id) d SQL 应用是否以实时应用(realtime_apply) d 关于装载 LogMiner Multiversioned Data Dictionary(在 4.2.3.2 节,“在redo data中 建立字典”),从Primary Database接收Redo,以及应用redo data(STATE),SQL 应用当前 在哪里 例如: SQL> COLUMN REALTIME_APPLY FORMAT a15 SQL> COLUMN STATE FORMAT a16 SQL> SELECT * FROM V$LOGSTDBY_STATE; PRIMARY _DBID SESSION_ID REALTIME_APPLY STATE ------------ ---------- --------------- ---------------- 1562626987 1 Y APPLYING 输出显示 SQL 应用运行在实时应用模式并且当前应用从Primary Database接收到的redo data, Primary Database的 DBID 是 1562626987 并且 SQL 应用会话相关的 LogMiner 会话标识符是 1。 同时查看: Oracle 数据库参考中的 V$LOGSTDBY_STATE 视图以获得参考信息和 9.3.1 节,“监控 SQL 应用过程”以获得例子输出 9.2.7 V$LOGSTDBY_STATS 视图 该视图提供 SQL 应用统计信息: 例如: SQL> COLUMN NAME FORMAT a32 SQL> COLUMN VALUE FORMAT a32 SQL> SELECT * FROM V$LOGSTDBY_STATS; NAME VALUE -------------------------------- -------------------------------- number of preparers 1 number of appliers 4 maximum SGA for LCR cache 30 parallel servers in use 8 maximum events recorded 1000 preserve commit order TRUE record skip errors Y record skip DDL Y record applied DDL N record unsupported operations N coordinator state APPLYING transactions ready 132412 管理Logical Standby Database 9-9 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 transactions applied 132118 coordinator uptime 132102 realtime logmining Y apply delay 0 Log Miner session ID 1 bytes of redo processed 130142100140 txns delivered to client 131515 DML txns delivered 128 DDL txns delivered 23 CTAS txns delivered 0 Recursive txns delivered 874 Rolled back txns seen 40 LCRs delivered to client 2246414 bytes paged out 0 secs spent in pageout 0 bytes checkpointed 0 secs spent in checkpoint 0 bytes rolled back 0 secs spent in rollback 0 secs system is idle 2119 32 rows selected. 同时查看: Oracle 数据库参考中的 V$LOGSTDBY_STATS 视图 9.3 监控Logical Standby Database 本节包含下述主题: d 监控 SQL 应用过程 d 日志文件的自动删除 9.3.1 监控 SQL 应用过程 SQL 应用可以是六个进展状态中的任何一个:初始化 SQL 应用,等待字典日志,装载 LogMiner Multiversioned Data Dictionary,应用(redo data),等待归档中断被解决,和空闲。 图 9-2 显示了这些状态的流程。 图 9-2 在 SQL 应用处理期间的进展状态 管理Logical Standby Database 9-10 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 下面子小节更详细地描述了每个状态。 初始化状态 当你通过执行 ALTER DATABASE START LOGICAL STANDBY APPLY 语句开始 SQL 应用时,它处于初始化状态。 要确定 SQL 应用的当前状态,查询 V$LOGSTDBY_STATE 视图。例如: SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE; SESSION_ID STATE ---------- ------------- 1 INITIALIZING SESSION_ID 列标识了由 SQL 应用创建的持久 LogMiner 会话,用来提取由Primary Database生 成的archived redo log files。 等待字典日志 SQL 应用第一次开始时,它需要装载在redo log files中捕获的 LogMiner Multiversioned Data Dictionary。SQL 应用将逗留在 WAITING FOR DICTIONARY LOGS 状态,直到它接收 到所有装载 LogMiner Multiversioned Data Dictionary 所需的redo data。 装载字典状态 这个装载字典状态能保持一段时间。在大型数据上的装载 LogMiner Multiversioned Data Dictionary 可能花很长时间。当装载字典时查询 V$LOGSTDBY_STATE 视图返回下面输出: SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE; SESSION_ID STATE ---------- ------------------ 1 LOADING DICTIONARY 只有 COORDINATOR 进程和提取进程被产生,直到 LogMiner 字典被完全装载。因此, 如果你在这个点查询 V$LOGSTDBY_PROCESS,你将不会看到任何 APPLIER 进程。例如: SQL> SELECT SID, SERIAL#, SPID, TYPE FROM V$LOGSTDBY_PROCESS; SID SERIAL# SPID TYPE 管理Logical Standby Database 9-11 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 ------ --------- --------- --------------------- 47 3 11438 COORDINATOR 50 7 11334 READER 45 1 11336 BUILDER 44 2 11338 PREPARER 43 2 11340 PREPARER You can通过查询 V$LOGMNR_DICTIONARY_LOAD 视图来获得装载字典过程相关的更 详细的信息。字典装载分三个阶段: 1.相关的archived redo log files或Standby redo log files被提取以收集装载 LogMiner Multiversioned Data Dictionary 相关的Redo更改。 2.更改被处理并装载到数据库内部的分段运输表。 3.通过执行一系列 DDL 语句装载 LogMiner Multiversioned Data Dictionary 表。 例如: SQL> SELECT PERCENT_DONE, COMMAND FROM V$LOGMNR_DICTIONARY_LOAD WHERE SESSION_ID = (SELECT SESSION_ID FROM V$LOGSTDBY_STATE); PERCENT_DONE COMMAND ------------- ------------------------------- 40 alter table SYSTEM.LOGMNR_CCOL$ exchange partition P101 with table SYS.LOGMNRLT_101_CCOL$ excluding indexes without validation 如果 PERCENT_DONE 或 COMMAND 列长时间没有发生更改,查询 V$SESSION_LONGOPS 视图来监控问题 DDL 事务的进展。 应用状态 在这个状态,SQL 应用已经成功装载了 LogMiner Multiversioned Data Dictionary 的初始 快照,并当前正应用redo data到Logical Standby Database。 要获得 SQL 应用进展的详细信息,查询 V$LOGSTDBY_PROGRESS 视图: SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS'; SQL> SELECT APPLIED_TIME, APPLIED_SCN, MINING_TIME, MINING_SCN, FROM V$LOGSTDBY_PROGRESS; APPLIED_TIME APPLIED_SCN MINING_TIME MINING_SCN -------------------- ----------- -------------------- ----------- 10-JAN-2005 12:00:05 346791023 10-JAN-2005 12:10:05 3468810134 所有Primary Database上的在 APPLIED_SCN(或 APPLIED_TIME)或之前的已提交事务已经 应用到Logical Standby Database。提取引擎已经处理了在 MINING_SCN(和 MINING_TIME)或之前 生成的所有Redo记录。在平稳状态,值 MINING_SCN(和 MINING_TIME)将总是在 管理Logical Standby Database 9-12 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 APPLIED_SCN(和 APPLIED_TIME)之前。 等待中断状态 这个状态当 SQL 应用已经提取并应用所有可用的Redo记录时发生,并且是等待新的日 志文件(或丢失的日志文件)被 RFS 进程归档。 SQL> SELECT STATUS FROM V$LOGSTBDY_PROCESS WHERE TYPE = 'READER'; STATUS ----------------------------------------------------------------- ORA:01291 Waiting for logfile 空闲状态 一旦 SQL 应用已经应用了由Primary Database生成的所有Redo就进入这个状态。 9.3.2 日志文件的自动删除 当不再需要时,SQL 应用自动删除归档日志文件。 这种行为能通过执行下述 PL/SQL 过程来覆盖: SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', FALSE); 注: 默认地,SQL 应用将删除不再需要的archived redo log files。如果你闪回Logical Standby Database, 可能会将Logical Standby Database带会到一个状态,archived redo log files在 SQL 应用元数据中存在(在 DBA_LOGSTDBY_LOGS 视图中反映)但是不存在于文件系统。尝试在 Flashback 数据库后 重启 SQL 应用可能会失败,在警告日志中会有如下错误: Errors in file /home/oracle/DGR2/logical/stdl/bdump/stdl_lsp0_11310.trc: ORA-00308: cannot open archived log '/home/oracle/DGR2/logical/stdl/stlog/1_15_559399019.dbf' ORA-27037: unable to obtain file status 你需要拷贝已经被自动删除策略删除的archived redo log files到适当的目录并重启 SQL 应 用。 虽然 SQL 应用在Logical Standby Database上自动删除不再需要的archived redo log files,但是可能会 有你想手工删除它们的时候(例如,要清理磁盘空间)。 如果你覆盖默认的自动日志删除能力,执行下述步骤以确定并删除 SQL 应用不再需要 的archived redo log files: 1. 要清除不再需要的元数据的逻辑备会话,输入下述 PL/SQL 语句: SQL> EXECUTE DBMS_LOGSTDBY.PURGE_SESSION; 该语句也更新 DBA_LOGMNR_PURGED_LOG 视图,是显示不再需要的归档Redo 日志文件。 2.查询 DBA_LOGMNR_PURGED_LOG 视图来列出能被删除的archived redo log files: 管理Logical Standby Database 9-13 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 SQL> SELECT * FROM DBA_LOGMNR_PURGED_LOG; FILE_NAME ------------------------------------ /boston/arc_dest/arc_1_40_509538672.log /boston/arc_dest/arc_1_41_509538672.log /boston/arc_dest/arc_1_42_509538672.log /boston/arc_dest/arc_1_43_509538672.log /boston/arc_dest/arc_1_44_509538672.log /boston/arc_dest/arc_1_45_509538672.log /boston/arc_dest/arc_1_46_509538672.log /boston/arc_dest/arc_1_47_509538672.log 3.使用操作系统相关的命令来删除查询列出的archived redo log files。 9.4 定制Logical Standby Database 本节包含下述主题: d 在Logical Standby Database上使用实时应用 d 定制记录在 DBA_LOGSTDBY_EVENTS 视图中的事件 d 使用 DBMS_LOGSTDBY.SKIP 来阻止对特定方案对象的更改 d 对于 DDL 语句设置跳过处理 d 更改Logical Standby Database d 在Logical Standby Database上添加或重建表 同时查看: Oracle 数据库 PL/SQL 包和类型参考中的 DBMS_LOGSTDBY 包 9.4.1 在Logical Standby Database上使用实时应用 默认地,Data Guard 等待全部archived redo log files在应用到Standby Database之前到达Standby Database。 然而,如果你在Standby Database上已经配置了一个Standby redo log files,You can选择允许实时应用。当允许实 时应用,SQL 应用在日志文件被写入的同时从Standby redo log files应用redo data,相对于在日 志切换发生后从archived redo log files应用。以这种方式立即应用Standby redo log files保持逻辑备数 据库紧密跟随Primary Database,而不需要Standby redo log files在Standby node归档。这能导致快速切换和故障 转移。 要在Logical Standby Database上启动实时应用,执行下述语句: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Oracle 推荐你以实时应用模式运行 SQL 应用。同时查看 3.1.3 节,“配置Standby redo log files” 以获得配置Standby redo log files相关的更多信息。 9.4.2 定制记录 DBA_LOGSTDBY_EVENTS 视图中的事件 管理Logical Standby Database 9-14 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 DBA_LOGSTDBY_EVENTS 视图可用被视为包含发生在 SQL 应用环境中的最近感兴 趣的事件的循环日志。默认地最近的 100 个事件被记录在事件视图。You can通过调用 DBMS_LOGSTDBY.APPLI_SET 过程来更改记录事件的数量。例如,要确保记录最近的 10000 个事件,You can执行下述语句: SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET ('MAX_EVENTS_RECORDED', '10000'); 注: 在 Oracle 数据库 10g 版本 1(10.1)中,DBMS_LOGSTDBY.MAX_EVENTS 常量被称 为 DBMS_LOGSTDBY_PUBLIC.MAX_EVENTS。这两个常量的效果是一样的,但是在版本 2(10.2)中 DBMS_LOGSTDBY_PUBLIC 包已经被除去了,而该常量的定义就移到 DBMS_LOGSTDBY 包中。 另外,You can指定在视图中记录哪种类型的事件。例如,要记录应用的 DDL 事务到 DBA_LOGSTDBY_EVENTS 视图中,执行下述语句: SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET ('RECORD_APPLIED_DDL', 'TRUE'); 造成 SQL 应用停止的错误总是记录在事件视图中(除非在系统表空间中没有足够的空 间)。这些事件总是也记入 ALERT.LOG 文件中,在文本中包括 LOGSTDBY 关键词。当查 询该视图时,以 EVENT_TIME、COMMIT_SCN和 CURRENT_SCN 排序选择列。这个顺 序确保关闭故障出现在视图的最后面。 9.4.3 使用 DBMS_LOGSTDBY.SKIP 来阻止对特定方案对象的更改 默认地,在Primary Database中所有支持的表被复制到Logical Standby Database中。You can通过指定规则来 跳过对特定表的应用更改,从而更改默认行为。例如,要忽略对 HR.EMPLOYEES 表的更改, You can指定规则来阻止对特定表的 DML 和 DDL 更改的应用。例如: 1.停止 SQL 应用: SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; 2.注册 SKIP 规则: SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'DML', schema_name => 'HR', object_name => 'EMPLOYEES', proc_name => null); SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'SCHEMA_DDL', schema_name => 'HR', object_name => 'EMPLOYEES', proc_name => null); 3.开始 SQL 应用: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 9.4.4 对 DDL 语句设置跳过处理 You can创建一个过程来截取某个 DDL 语句并使用其它语句替代原始 DDL 语句。例如, 管理Logical Standby Database 9-15 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 如果在Logical Standby Database中的文件系统组织不同于Primary Database中的,You can写一个 DBMS_LOGSTDBY.SKIP 过程来透明地处理与文件相关的 DDL 事务。 下面过程能处理Primary Database和Standby Database之间不同的文件系统组织,只要你对于你的文件 相关串使用特定的名字转换。 1.创建跳过过程来处理表空间 DDL 事务: CREATE OR REPLACE PROCEDURE SYS.HANDLE_TBS_DDL ( OLD_STMT IN VARCHAR2, STMT_TYP IN VARCHAR2, SCHEMA IN VARCHAR2, NAME IN VARCHAR2, XIDUSN IN NUMBER, XIDSLT IN NUMBER, XIDSQN IN NUMBER, ACTION OUT NUMBER, NEW_STMT OUT VARCHAR2 ) AS BEGIN -- All Primary file specification that contains a directory -- /usr/orcl/Primary /dbs -- should go to /usr/orcl/stdby directory specification NEW_STMT = REPLACE(OLD_STMT, '/usr/orcl/Primary /dbs', '/usr/orcl/stdby'); ACTION := DBMS_LOGSTDBY.SKIP_ACTION_REPLACE; EXCEPTION WHEN OTHERS THEN ACTION := DBMS_LOGSTDBY.SKIP_ACTION_ERROR; NEW_STMT := NULL; END HANDLE_TBS_DDL; 2.停止 SQL 应用: SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; 3.向 SQL 应用注册跳过过程: SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'TABLESPACE', - proc_name => 'sys.handle_tbs_ddl'); 4.开始 SQL 应用: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 管理Logical Standby Database 9-16 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 9.4.5 更改Logical Standby Database Logical Standby Database能用于报表活动,即使当 SQL 语句在被应用时。数据库 guard 控制用户 到Logical Standby Database中表的访问,使用 ALTER SESSION DATABASE DISABLE GUARD 语句可 以绕过数据库 guard 并允许更改Logical Standby Database中表。 默认地,Logical Standby Database是操作在数据库 guard 设置为 ALL,这是最严格的设置,不允许 在数据库上执行任何用户操作。You can通过执行 ALTER SESSION DISABLE GUARD 语句来 覆盖数据库 guard 以允许对Logical Standby Database进行更改。特权用户能执行这句语句来将数据库 guard 对当前会话关闭。 下面小节提供了一些例子。在这些小节中的讨论假设数据库 guard 是设为 ALL 或 STANDBY 。 9.4.5.1 在Logical Standby Database上执行 DDL 本小节描述如何添加一个约束到通过 SQL 应用维护的表。 默认地,当数据库 guard 设置为 ALL 或 STANDBY 时,只有拥有 SYS 权限的帐户才能 更改数据库。如果你以 SYSTEM 或其它特权帐户登录,要没有首先对会话绕过数据库 guard, 你将不能在Logical Standby Database上执行 DDL 语句。 下面例子显示了如何停止 SQL 应用,绕过数据库 guard,在Logical Standby Database上执行 SQL 语句,然后重新允许 guard: SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered. SQL> ALTER SESSION DISABLE GUARD; PL/SQL procedure successfully completed. SQL> ALTER TABLE SCOTT.EMP ADD CONSTRAINT EMPID UNIQUE (EMPNO); Table altered. SQL> ALTER SESSION ENABLE GUARD; PL/SQL procedure successfully completed. SQL> ALTER DATABASE START LOGICAL STANDBY APPLY; Database altered. Oracle 建议在允许绕过数据库 guard 时,你不要在由 SQL 应用维护的表上执行 DML 操 作。这将在Primary Database 和 Standby Database之间引入背离,那将使得维护Logical Standby Database变得不可能。 9.4.5.2 更改不是由 SQL 应用维护的表 有些时候,报表应用必须收集总结结果并临时存储它们或跟踪报表运行的次数。虽然应 用的主要目的是执行报表活动,但是应用可能需要在Logical Standby Database上执行 DML(插入,更 新,和删除)操作。甚至可能需要创建或删去表。 You can设置数据库 guard 以允许报表操作更改数据,只要数据不是通过 SQL 应用维护的。 要这么做,你必须: 管理Logical Standby Database 9-17 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 d 在Logical Standby Database上指定表集合,应用能通过执行 DBMS_LOGSTDBY.SKIP 过程向 其上面写数据。跳过的表是不通过 SQL 应用维护的。 d 设置数据库 guard 只保护备表。 在下面例子中,假设报表要写的表也在Primary Database上。 例子停止 SQL 应用,跳过表,然后重启 SQL 应用,使得更改能被应用到Logical Standby Database 上。报表应用将能够写到 MYSCHEMA 中的 MYTABLES%。它们将不再通过 SQL 应用维 护。 SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered. SQL> EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'SCHEMA_DDL',- schema_name => 'HR', - object_name => 'TESTEMP%'); PL/SQL procedure successfully completed. SQL> EXECUTE DBMS_LOGSTDBY.SKIP('DML','HR','TESTEMP%'); PL/SQL procedure successfully completed. SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered. 一旦 SQL 应用开始,它需要为新指定添加到跳过规则的表更新Standby Database上的元数据。 直到 SQL 应用已经有机会更新元数据,试图更改新跳过的表将会失败。You can通过执行下面 查询来找出 SQL 应用是否已经成功考虑你刚添加的 SKIP 规则: SQL> SELECT VALUE FROM DBA_LOGSDTBY_PARAMETERS WHERE NAME = 'GUARD_STANDBY '; VALUE --------------- Ready 一旦 VALUE 列显示“Ready”,SQL 应用已经成功更新了对于跳过表的所有相关元数据, 并且此时更改表是安全的。 同时查看: C.6 节,“Logical Standby Database支持的 DDL 语句”和 Oracle 数据库 PL/SQL 包和类型参考中的 DBMS_LOGSTDBY 包 9.4.6 在Logical Standby Database上添加或重建表 典型地,在无法恢复的操作之后你使用表instance化来重建表。你也可以使用这个过程来在 以前跳过的表上允许 SQL 应用。 在You can创建表之前,它必须满足在 4.1.2 节,“确保Primary Database中的表行能被唯一标识” 中描述的需求。然后,你可以使用下述步骤来重建名为 HR.EMPLOYEES 的表并重新开始 SQL 应用。说明假设已经定义了数据库连接 BOSTON 来访问Primary Database。 管理Logical Standby Database 9-18 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 下面列表显示了如果重建表并重启那个表上的 SQL 应用: 1.停止 SQL 应用: SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; 2.通过查询 DBA_LOGSTDBY_SKIP 视图来确保怀疑的表上没有操作被跳过: SQL> SELECT * FROM DBA_LOGSTDBY_SKIP; ERROR STATEMENT_OPT OWNER NAME PROC ----- --------------- ------------- ---------------- ----- N SCHEMA_DDL HR EMPLOYEES N DML HR EMPLOYEES N SCHEMA_DDL OE TEST_ORDER N DML OE TEST_ORDER 因为你已经有相关的跳过规则与你想在Logical Standby Database上重建的表相关联,你必须 首先删除那些规则。You can通过调用 DBMS_LOGSTDBY.UNSKIP 过程来完成。例如: SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'DML', - schema_name => 'HR', - object_name => 'EMPLOYEES');SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'SCHEMA_DDL', - schema_name => 'HR', - object_name => 'EMPLOYEES'); 3.通过使用 DBMS_LOGSTDBY.INSTANTIATE_TABLE 过程在Logical Standby Database中重建表 HR.EMPLOYEES 与其所有数据。例如: SQL> EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE(shema_name => 'HR', object-+_name => 'EMPLOYEES', - dblink => 'BOSTON'); 4.开始 SQL 应用: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 同时查看: Oracle 数据库 PL/SQL 包和类型参考以获得 DBMS_LOGSTDBY.UNSKIP 和 DBMS_LOGSTDBY.INSTANTIATE_TABLE 过程的相关信息 要确保一个跨新instance化的表和数据库的剩余部分的一致性视图,在查询这个表之前等 待 SQL 应用追赶上Primary Database。You can通过执行下述步骤来做到这点: 1.在Primary Database上,通过查询 V$DATABASE 视图确定当前 SCN: SQL> SELECT CURRENT_SCN FROM V$DATABASE@BOSTON; CURRENT_SCN --------------------- 345162788 2.确保 SQL 应用已经应用了所有在前面查询中返回的 CURRENT_SCN 之前提交的事 务: SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS; 管理Logical Standby Database 9-19 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 APPLIED_SCN -------------------------- 345161345 当在这个查询中返回的 APPLIED_SCN 比第一个查询返回的 CURRENT_SCN 大 时,查询新重建的表是安全的。 9.5 管理Logical Standby Database环境下的特定工作负载 本节包含下述主题: d 导入一个可传输表空间到Primary Database d 使用物化视图 d 触发器和约束是如何在Logical Standby Database上处理的 d 通过 OPEN RESETLOG 语句恢复 9.5.1 导入一个可传输表空间到Primary Database 执行下述步骤来导入一个表空间到Primary Database。 1.禁止 guard 设置使得You can更改Logical Standby Database: SQL> ALTER SESSION DISABLE GUARD; 2.在Logical StandBy database导入表空间。 3.允许数据库 guard 设置(或从会话断开): SQL> ALTER SESSION ENABLE GUARD; 4.在Primary Database导入表空间。 9.5.2 使用物化视图 SQL 应用不支持这些物化视图相关的 DDL 语句: d CREATE、ALTER、或 DROP MATERIALIZED VIEW d CREATE、ALTER、或 DROP MATERIALIZED VIEW LOG 因此,在Logical Standby Database已经创建后,在Primary Database上创建的、更改的、或删去的新物化 视图不会在Logical Standby Database上反映。然而,在Logical Standby Database已经创建之前,在Primary Database上创建 的物化视图也表现在Logical Standby Database上。 d 对于同时存在于主和Logical Standby Database上的物化视图,当事务提交发生时 ON-COMMIT 物化视图在Logical Standby Database上刷新。 ON-COMMIT 物化视图不是由 SQL 应用自动刷新的。你必须执行 DBMS_MVIEW.REFRESH 过程来刷新它。例如,要在Logical Standby Database上使用快速刷新方 式刷新名为 HR.DEPARTMENTS_MV 的 ON-DEMAND 物化视图,执行下面命令: SQL> EXECUTE DBMS_MVIEW.REFRESH (- LIST => 'HR.DEPARTMENTS_MV', - 管理Logical Standby Database 9-20 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 METHOD => 'F'); d 在Logical Standby Database上创建的额外 ON-COMMIT 物化视图是自动维护的。 d 在Logical Standby Database上创建的额外 ON-DEMAND 物化视图不是由 SQL 应用维护,你 必须使用 DBMS_MVIEW.REFRESH 过程刷新它们。 9.5.3 触发器和约束是如何在Logical Standby Database上处理的 默认地,触发器和约束在Logical Standby Database上是自动允许和处理的。 对于由 SQL 应用维护的表上的触发器和约束: d 约束——检查约束在Primary Database上被评估并不需要在Logical Standby Database上重新评估 d 触发器——在Primary Database上执行的触发器的效果记录并应用到Standby Database上 对于不是由 SQL 应用维护的表上的触发器和约束: d 约束被评估 d 触发器被触发 9.5.4 通过 OPEN RESETLOGS 语句恢复 当Logical Standby Database接收到新的redo data分支,SQL 应用自动获得新的redo data分支。对 于Logical Standby Database,如果Standby Database没有应用新重置日志 SCN 以前的(在新的redo data分支开 始以前的)redo data,则不需要手工介入。下面的表描述了如果与Primary Database分支重新同步备 数据库。 如果Standby Database… 还没有应用新重置日志 SCN 以前 的(在新的redo data分支开始以前 的)redo data 已经应用新重置日志 SCN 以前的 (在新的redo data分支开始以前 的)redo data,并且在Standby Database上 允许 Flashback 数据库 已经应用新重置日志 SCN 以前的 (在新的redo data分支开始以前 的)redo data,并且在Standby Database上 没有允许 Flashback 数据库 丢失介于新的redo data分支其间 则… SQL 应用自动获取新的 redo data分支。 Standby Database恢复到新的重 做数据分支之后。 Primary Database在指定的主数 据库分支从备分叉。 SQL 应用无法继续直到 执行这些步骤… 没有必要手工介入。SQL 应用自动 与新的redo data分支重新同步。 1.遵循 12.5.2 节,“在闪回主之后 闪回Logical Standby Database”中的步骤来闪 回Logical Standby Database。 2.重启 SQL 应用以继续应用Redo 到新的重置日志分支。 SQL 应用自动与新的分支重新同步 Standby Database。 遵循第 4 章,“创建Logical Standby Database” 中的步骤重建Logical Standby Database。 从每个分支定位并注册丢失的归档 的archived redo log files 检索到丢失的日志文件。 redo log files。 丢失从前面redo data分支结尾的 SQL 应用无法继续直到 从前面分支定位并注册丢失的归档 archived redo log files 检索到丢失的日志文件。 redo log files。 查看 Oracle 数据库备份和恢复高级用户指南以获得数据库化身,通过 OPEN RESETLOGS 操作恢复,和 Flashback 数据库的更多相关信息。 管理Logical Standby Database 9-21 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 9.6 调优Logical Standby Database 本节包含下述主题: d 创建主键 RELY 约束 d 为基于代价的优化器收集统计信息 d 调整进程的数量 d 调整 LCR 缓存使用的内存 d 调整如何在Logical Standby Database上应用事务 9.6.1 创建主键 RELY 约束 在Primary Database上,如果表没有主键或唯一索引,并且你确认行是唯一的,则创建一个主 键 RELY 约束。在Logical Standby Database上,在组成主键的列上创建一个索引。下面查询生成一个表 的列表,这些表没有索引信息能被Logical Standby Database使用来应用唯一地标识行。通过在下述表上 创建索引,性能能显著提高。 SQL> SELECT OWNER, TABLE_NAME FROM DBA_TABLES 2> WHERE OWNER NOT IN('SYS','SYSTEM','OUTLN','DBSNMP') 3> MINUS 3> SELECT DISTINCT TABLE_OWNER, TABLE_NAME FROM DBA_INDEXES 4> WHERE INDEX_TYPE NOT LIKE ('FUNCTION-BASED%') 5> MINUS 6> SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED; You can向Primary Database上的表添加一个 rely 主键约束,如下: 1.在Primary Database上添加主键 rely 约束 SQL> ALTER TABLE HR.TEST_EMPLOYEES ADD PRIMARY KEY (EMPNO) RELY DISABLE; SQL> ALTER SESSION DISABLE GUARD; 这将确保 EMPNO 列,能被用于唯一标识 HR.TEST_EMPLOYEES 表中的行,将 作为表上任何更新的一部分被补充记录。 注意到 HR.TEST_EMPLOYEES 表还没有任何唯一索引在Logical Standby Database上指定。 这可能造成 UPDATE 语句在Logical Standby Database上做全表扫描。You can通过在Logical Standby Database上 在 EMPNO 列添加一个唯一索引来改正这个问题。查看 4.1.2 节,“确保在Primary Database中 的行能被唯一标识”和 Oracle 数据库 SQL 参考以获得 RELY 约束相关的更多信息。 2.停止 SQL 应用: SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; 3.禁止 guard 使得你在Logical StandBy database上更改Logical StandBy database上的被维护的表: SQL> ALTER SESSION DISABLE GUARD; 4.在 EMPNO 列上添加一个唯一索引: 管理Logical Standby Database 9-22 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 SQL> CREATE UNIQUE INDEX UI_TEST_EMP ON HR.TEST_EMPLOYEES (EMPNO); 5.允许 guard: SQL> ALTER SESSION ENABLE GUARD; 6.开始 SQL 应用: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 9.6.2 为基于代价的优化器收集统计信息 在Logical Standby Database上应该收集统计信息,因为基于代价的优化器(CBO)使用它们来确 定最优的查询执行路径。在方案对象的数据或结构发生改变使得以前的统计信息不准确时, 应该收集新的统计信息。例如,在对表插入或删除大量行后,收集相应数量行的新统计信息。 应该在Standby Database上收集统计信息,因为在主数据上的 DML 和 DDL 操作是作为工作复 杂的功能执行的。当Standby Database逻辑等同于Primary Database时,SQL 应用可能以不同的方式执行工 作负载。这就是为什么使用Logical Standby Database上的 STATS 包和 V$SYSTAT 视图能用于确定哪些 表消耗了最多的资源和表扫描。 同时查看: 4.1.2 节,“确保Primary Database中的表行能被唯一标识”和 Oracle 数据库 SQL 参考以获得 RELY 约束相关的更多信息 9.6.3 调整进程的数量 下面小节描述了: 调整 APPLIER 进程的数量 调整 PREPARER 进程的数量 9.6.3.1 调整 APPLIER 进程的数量 执行下述步骤来找出调整 APPLIER 进程的数量是否能帮助你获得更高的吞吐量: 1.通过执行下面查询确定 APPLIER 进程是否繁忙: SQL> SELECT COUNT(*) AS IDLE_APPLIER FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER' and status_code = 16166; IDLE_APPLIER ------------------------- 0 2.一旦你确定有非空闲的 APPLIER 进程,如果你选择调整 APPLIER 的数量,执行下 面查询来确保对于额外的 APPLIER 进程有足够的工作可做: SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE 'TRANSACTIONS%'; NAME VALUE 管理Logical Standby Database 9-23 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 --------------------- ------- transactions ready 27896 transactions applied 25671 有两种统计信息保留事务的累计总数,一种是 APPLIER 进程准备应用的事务数, 另一种是已经被应用的事务数量。 如果数量(transactions ready – transactions applied)比两倍可用的 APPLIER 进程数 量还要高,则如果你增加 APPLIER 进程的数量对吞吐量的提高是可能的。 注: 数量是准备好的工作的大概测量。工作负载可能由于准备好的事务之间的相关性阻止额 外可用的 APPLIER 进程应用它们。例如,如果大多数准备好应用的事务是 DDL 事务,则 添加更多的 APPLIER 进程将不会导致更高的吞吐量。 要从默认值 5 调整 APPLIER 进程的数量到 20,执行下述步骤: a.停止 SQL 应用: SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered b.设置 APPLY_SERVERS 的数量为 20: SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS', 20); PL/SQL procedure successfully completed c.开始 SQL 应用 SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered 9.6.3.2 调整 PREPARER 进程的数量 只有在很罕见的情况下你需要调整 PREPARER 进程的数量。在你决定增加 PREPARER 进程的数量之前,确保下面条件为真: d 所有 PREPARER 进程是繁忙的 d 准备好要应用的事务数量少于可用的 APPLIER 进程数量 d 有空闲的 APPLIER 进程 下面步骤显示如何确定这些条件为真: 1.确保所有 PREPARER 进程是繁忙的: SQL> SELECT COUNT(*) AS IDLE_PREPARER FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'PREPARER' and status_code = 16166; IDLE_PREPARER ------------- 0 2.确保准备好要应用的事务数量少于可用的 APPLIER 进程数量: SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE 'transactions%'; 管理Logical Standby Database 9-24 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 NAME VALUE --------------------- ------- transactions ready 27896 transactions applied 27892 SQL> SELECT COUNT(*) AS APPLIER_COUNT FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER'; APPLIER_COUNT ------------- 20 注:多次执行这个查询以确保这不是一个短暂的事件。 3.确保有空闲的 APPLIER 进程: SQL> SELECT COUNT(*) AS IDLE_APPLIER FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER' and status_code = 16166; IDLE_APPLIER ------------------------- 19 在这个例子中,所有条件已经被满足。因此,你现在可以增加 PREPARER 进程到 4(从 默认值 1),通过执行下述步骤: 1.停止 SQL 应用: SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered 2.设置 PREPARE_SERVERS 的数量为 4: SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PREPARE_SERVERS', 4); PL/SQL procedure successfully completed 3.开始 SQL 应用: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered 9.6.4 调整 LCR 缓存使用的内存 对于一些工作负载,SQL 应用可可以使用大量的换页操作,从而减轻系统的整个吞吐量。 要找到增加分配给 LCR 缓存的内存是否有益,执行下述步骤: 1.执行下面查询以获得换页活动的快照: SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE '%PAGE%' OR NAME LIKE '%UPTIME%' OR NAME LIKE '%idle%'; NAME VALUE -------------------------- --------------- 管理Logical Standby Database 9-25 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 coordinator uptime in secs 894856 bytes paged out 20000 seconds spent in pageout 2 system idle time in secs 1000 2.在 5 分钟内再次执行查询: SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE '%PAGE%' OR NAME LIKE '%UPTIME%' OR NAME LIKE '%idle%'; NAME VALUE -------------------------- --------------- coordinator uptime in secs 895156 bytes paged out 1020000 seconds spent in pageout 100 system idle time in secs 1000 3.计算规格化的换页活动。例如: Change in coordinator uptime (C)= (895156 – 894856) = 300 secs Amount of additional idle time (I)= (1000 – 1000) = 0 Change in time spent in pageout (P) = (100 – 2) = 98 secs Pageout time in comparison to uptime = P/(C-I) = 98/300 ~ 32.67% 理想地,换页活动不应该消耗超过百分之 5 的整个运行时间。如果你继续在延长的间 隔获取快照,你会发现换页活动继续消耗了应用时间的显著部分,增加内存大小能提供一些 Benefits。You can通过执行下述步骤增加分配给 SQL 应用的内存: 1.停止 SQL 应用: SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered 2.设置分配给 LCR 缓存的内存(对于这个例子,SGA 设为 1GB): SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SGA', 1024); PL/SQL procedure successfully completed 因为 MAX_SGA 是以兆字节(MB)指定的,增加内存到 1GB 在例子中以 1024MB 指定。 3.开始 SQL 应用: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered 9.6.5 调整如何在Logical Standby Database上应用事务 默认地,在Logical Standby Database上应用的事务与它们在Primary Database上提交的次序完全相同。提 交事务的默认顺序允许任何报表应用在Logical Standby Database上透明地运行。然而,当你想逻辑备数 据库追赶上Primary Database时是要时间的(如在由于硬件故障或升级Logical Standby Database长时间地中断之 管理Logical Standby Database 9-26 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 后),并且能容忍不运行报表应用一段时间。在这种情况下,You can通过执行下述步骤更改默 认应用模式: 1.停止 SQL 应用: SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered 2.执行下面以允许事务不按它们在Primary Database上提交的顺序应用: SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PRESERVE_COMMIT_ORDER', 'FALSE'); PL/SQL procedure successfully completed 3.开始 SQL 应用: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered 一旦你已经追赶上Primary Database(通过查询 V$LOGSTDBY_STATS 视图来检验),并且你准 备打开Logical Standby Database以用于报表应用,You can如下更改应用模式: 1.停止 SQL 应用: SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered 2.还原 PRESERVE_COMMIT_ORDER 参数的默认值: SQL> EXECUTE DBMS_LOGSTDBY.APPLY_UNSET('PRESERVE_COMMIT_ORDER'); PL/SQL procedure successfully completed 3.开始 SQL 应用: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered 对于典型的联机事务处理(OLTP)工作负载,非默认模式能比默认的应用模式提 供百分之 50 或更好的吞吐量提高。 管理Logical Standby Database 9-27 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 10 使用 RMAN 来备份和恢复文件 本章描述与 Data Guard 和Standby Database使用 Oracle 恢复管理器工具(RMAN)的备份策略。 RMAN 能以对Primary Database最小影响来执行备份并且从丢失单个数据文件或整个数据库中快速 恢复。RMAN 和 Data Guard 能一起使用来简化 Data Guard 配置的关联。 本章包含下述主题: d 备份过程 d 切换、failover和控制文件重建在备份上的影响 d 额外的备份情况 注: 因为Logical Standby Database不是Primary Database的块对块拷贝,你不可以使用Logical Standby Database来备份主数据 库。 10.1 备份过程 在备环境中,在主或Standby system上进行的备份数据文件和archived redo log files在其它系统是 可以用于恢复的。虽然一些文件如控制文件和 SPFILE 必须在Primary Database上备份,但是备份数 据文件和archived redo log files的步骤能卸载到Standby system,以最小化生产系统上的备份影响。 只有那些由备instance创建的archived redo log files才能在Standby node上备份。如果有在Standby Database 启动之前生成的archived redo log files,它们必须在Primary Database上备份。例如,如果从Primary Database发 送到备的第一个日志是日志序列 100 线程 1,则日志序列小于 100 的archived redo log files的备 份必须在Primary Database上完成。 如果配置了Flash Recovery Areas,Oracle 软件基于需求从Flash Recovery Areas删除文件。Flash Recovery Areas对于 磁带备份作为磁盘缓存。 10.1.1 对磁带备份使用磁盘作为缓存 下面指导假设已配置了Flash Recovery Areas(如 5.2.3 节中描述)和设置了其它 RMAN 持久平 配置。执行下述步骤: 1.在Primary Database上,执行下面 RMAN 命令来进行控制文件和 SPFILE 的当前备份,并备 份由主instance创建的Flash Recovery Areas中的文件到磁带: BACKUP DEVICE TYPE DISK CURRENT CONTROLFILE; BACKUP RECOVERY AREA; 每天或一周一次执行这些命令(或在脚本中使用它们),取决于在丢失所有当前控 制文件的情况下能容忍丢失多少redo data的应用(查看 10.2.4 节)。 2.在Standby Database上,每天执行下面 RMAN 命令来前滚 0 级别数据库拷贝: RECOVER COPY OF DATABASE WITH TAG 'OSS'; BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'OSS' DATABASE; BACKUP DEVICE TYPE DISK ARCHIVELOG ALL NOT BACKED UP 2 TIMES; 使用 RMAN 来备份和还原文件 10-1 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 BACKUP RECOVERY AREA; 这些命令应用一天以前进行的级别 1 增量备份,创建一个新的级别 1 增量备份, 备份archived redo log files到Flash Recovery Areas,并从Flash Recovery Areas备份由备instance创建的文件到磁 带。 10.1.2 直接执行备份到磁带 如果所有备份直接写到磁带,使用 RMAN CONFIGURE DEFAULT DEVICE TYPE TO SBT 命令来配置默认的设备类型为 SBT。 在Primary Database上,使用下面 RMAN 命令来备份当前控制文件并拷贝由主instance创建的自动 备份到磁带上: BACKUP AS BACKUPSET CURRENT CONTROLFILE; BACKUP RECOVERY AREA; 每天或一周一次执行这些命令,取决于在丢失所有当前控制文件的情况下能容忍丢失 多少redo data的应用(查看 10.2.4 节)。 假设每周日进行全数据库备份,能在Standby Database上执行下面命令来进行级别 0 数据库备 份: BACKUP AS BACKUPSET INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG NOT BACKED UP 2 TIMES; 在备份周期的其它日期,运行下面命令来创建数据库的级别 1 增量备份和所有还没有 备份两次的archived redo log files: BACKUP AS BACKUPSET INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG NOT BACKED UP 2 TIMES; 10.2 切换、failover和控制文件重建在备份上的影响 所有在备份完成所在系统上的上次备份以后生成的archived redo log files,在下述事件之 后,必须使用 RMAN CATALOG ARCHIVELOG ‘archivelog_name_complete_path’命令手工编 录: d 主或备控制文件重建。 d 在切换后Primary Database角色转换到备。 d 在切换或failover后Standby Database角色转换到主。 如果新的archived redo log files没有编录,RMAN 将不会备份它们。 在下面小节中的例子假设你从磁带还原文件到备份创建的同一系统上。如果你需要还 原文件到不同系统,你可能需要更改媒质配置或在还原期间在 RMAN 通道上指定不同的参 数,或两者都。查看媒质管理文档以获得如何从不同系统访问 RMAN 备份的更多相关信息。 10.2.1 从Primary Database上数据文件的丢失恢复 指定下面 RMAN 命令来还原并恢复数据文件。你必须同时连接到主和恢复目录数据库。 使用 RMAN 来备份和还原文件 10-2 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 RESTORE DATAFILE n,m...; RECOVER DATAFILE n,m...; 执行下面 RMAN 命令来还原并恢复表空间。你必须同时连接到主和恢复目录数据库。 RESTORE TABLESPACE tbs_name1, tbs_name2, ... RECOVER TABLESPACE tbs_name1, tbs_name2, ... 10.2.2 从Standby Database上数据文件的丢失恢复 要在丢失一个或更多数据文件恢复Standby Database,你必须使用 RMAN RESTORE DATAFILE 命令从备份中还原丢失的文件到Standby Database。如果恢复损坏文件所需的所有archived redo log files 在磁盘上可以由Standby Database访问,则重启Redo应用。 如果恢复所需的archived redo log files在磁盘上不可访问,使用 RMAN 还原恢复的数据文 件到 SCN/日志序号高于最近应用到Standby Database的,然后重启Redo应用继续应用redo data,如 下: 1.停止Redo应用。 2.确定 UNTIL_SCN 列的值,通过执行下面查询: SQL> SELECT MAX(NEXT_CHANGE#)+1 UNTIL_SCN FROM V$LOG_HISTORY LH, V$DATABASE DB WHERE LH.RESETLOGS_CHANGE#=DB.RESETLOGS_CHANGE# AND LH.RESETLOGS_TIME = DB.RESETLOGS_TIME; UNTIL_SCN ------- ---------------- 967786 3.执行下面 RMAN 命令来还原并恢复Standby Database上的数据文件。你必须同时连接到备 和恢复目录数据库(使用 TARGET 关键词来连接到备instance): RESTORE DATAFILE ; RECOVER DATABASE UNTIL SCN 967786; 要还原一个表空间,使用 RMAN ‘RESTORE TABLESPACE tbs_name1, tbs_name2, …’命令。 4.重启Redo应用。 10.2.3 从备控制文件的丢失恢复 Oracle 软件允许多重备控制文件。要确保备控制文件被多重,检查 CONTROL_FILES 初始化参数,如下: SQL> SHOW PARAMETER CONTROL_FILES NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ control_files string , 使用 RMAN 来备份和还原文件 10-3 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 如果其中一个多重备控制文件丢失或不可访问,Oracle 软件停止instance并写下面信息到警 告日志: ORA-00210: cannot open the specified controlfile ORA-00202: controlfile: '/ade/banand_hosted6/oracle/dbs/scf3_2.f' ORA-27041: unable to open file You can拷贝一个控制文件的完整拷贝覆盖到丢失的拷贝,然后使用下面 SQL 语句重启备 instance: SQL> STARTUP MOUNT; SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; 如果所有备控制文件丢失了,则你必须从Primary Database创建一个新的控制文件,拷贝它到 Standby Database上所有多重位置,并重启备instance和Redo应用。创建的控制文件丢失所有在其创建之 前生成的archived redo log files的相关信息。因为 RMAN 到控制文件中查找要备份的归档Redo 日志文件的列表,所有在最近备份以后生成的archived redo log files必须手工编录。 10.2.4 从主控制文件的丢失恢复 Oracle 软件允许在Primary Database上多重控制文件。如果其中一个控制文件无法在Primary Database上 更新,则Primary Databaseinstance自动关闭。如 10.2.3 节中描述,You can拷贝一个控制文件的完整拷贝并 重启instance而不用执行还原或恢复操作。 如果你丢失你的所有控制文件,You can选择下述步骤之一,取决于可接受的宕机事件。 创建一个新的控制文件 如果所有控制文件的拷贝丢失了,你可以使用 NORESETLOGS 选项来创建一个新的控制文件并在完成媒质恢复之后打开数据库。现有的Standby Databaseinstance能通 过使用下面语句生成脚本来创建一个新的控制文件: SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS; 注意到数据库文件名在Primary Database 和 Standby Database中是不同的,然后你必须编辑生成的脚本来更改 文件名。 这个语句能定期地使用以生成控制文件创建脚本。如果你要将控制文件创建作为你的 恢复计划的一部分,则你应该在任何Primary 架构更改后使用这个语句,如添加或删去数据文件、 表空间、或redo log成员。 创建的控制文件丢失所有在控制文件创建时间之前生成的archived redo log files的相关信 息。如果archived redo log files备份正在Primary Database上执行,自从最近archived redo log files备份以后 生成的所有archived redo log files必须手工编录。 使用备份控制文件恢复 如果你不可以使用前面的步骤创建控制文件,则你可以使用一个备 份控制文件,执行完全恢复,并以 RESETLOGS 选项打开数据库。 要还原控制文件并恢复数据库,在连接到主instance(在 NOMOUNT 状态)之后执行下面 RMAN 命令并编录数据库: RESTORE CONTROLFILE; ALTER DATABASE MOUNT; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS; 使用 RMAN 来备份和还原文件 10-4 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 从 Oracle 版本 10.1.0 开始,所有在 RESETLOGS 选项之前进行的备份能用于恢复。因 此,没有必要在可用于生产之前备份数据库。 10.2.5 从联机redo log files的丢失恢复 Oracle 建议多重联机redo log files。丢失一个Online redo logs(联机redo log)组的所有成员导致 Oracle 软件终止instance。如果只有一个日志文件组的一些成员无法写入,则它们将不被使用直到它们 变得可访问。视图 V$LOGFILE 和 V$LOG 包含Primary Databaseinstance中日志文件成员的当前状态的 更多相关信息。 当 Oracle 软件不能写联机redo log files成员之一时,会返回下面警告信息: ORA-00313: open failed for members of log group 1 of thread 1 ORA-00312: online log 1 thread 1: '/ade/banand_hosted6/oracle/dbs/t1_log1.f' ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory Additional information: 3 如果访问问题是暂时由于硬件问题,更正问题处理将自动继续。如果丢失是永久的, 可以添加一个新的成员并从组中删去旧的组。 要添加一个新的成员到redo log组,执行下面语句: SQL> ALTER DATABASE ADD LOGFILE MEMBER 'log_file_name' REUSE TO GROUP n 即使数据库打开时你也能执行这个语句,而不影响数据库可用性。 如果一个已经归档的非活动组的所有成员丢失了,该组能删除并重建。 在所有其它情况(丢失当前 ACTIVE 组,或还没有备归档的非活动组的所有联机日志 成员),你必须failover到Standby Database。参考第 7 章以获得failover步骤。 10.2.6 数据库的不完全恢复 Primary Database的不完全恢复通常在如下情况下完成,如当数据库逻辑损坏(被一些用户或 应用)或当表空间或数据文件意外从数据库删去。 取决于Standby Databaseinstance上的当前数据库检查点 SCN,你可以使用下面步骤之一来执行数据 库的不完全恢复。所有过程按优先排序,以花费最少时间的开始。 使用 Flashback 数据库 当在Primary Database上允许 Flashback 数据库特性时,使用 Flashback 数据库是推荐的步骤,不丢失一个数据库文件,并且基于时间点的恢复比最旧的闪回 SCN 或最旧的闪回时间还大。查看 12.5 节以获得使用 Flashback 数据库来做基于时间点的恢复的 步骤。 使用Standby Databaseinstance 当Standby Database处于期望的不完全恢复时间之后时,并且在主或备数据 库上没有允许 Flashback 数据库,推荐使用这个步骤, 1.恢复Standby Database到期望的时间点: RECOVER DATABASE UNTIL TIME 'time'; 可选的,不完全恢复时间可以使用 SCN 或日志序列号指定: 使用 RMAN 来备份和还原文件 10-5 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 RECOVER DATABASE UNTIL SCN incomplete recovery SCN' RECOVER DATABASE UNTIL LOGSEQ incomplete recovery log sequence number THREAD thread number 2.以只读模式打开Standby Database以检验数据库的状态。 如果状态不是期望的,使用 LogMiner 工具来查找archived redo log files以找到不完全 恢复正确的目标时间或 SCN。可选地,You can开始恢复Standby Database到你已知的在目标时间 前的点,然后以只读模式打开数据库来检查数据的状态。重复这个过程直到数据库的 状态检查为正确。注意如果你恢复数据库太远,(就是说,经过错误发生的 SCN)你不 能返回到更早的 SCN。 3.使用 SQL ALTER DATABASE ACTIVATE STANDBY DATABASE 语句激活备数据 库。这转换Standby Database到Primary Database,创建一个新的重置日志分支,并打开数据库。查看 8.4 节以认识到Standby Database如何反应到新的重置日志分支。 使用Primary Databaseinstance 如果所有的Standby Databaseinstance已经恢复到期望的时间点以后,并且在主 或Standby Database上允许 Flashback 数据库,则这是你的唯一选择。 使用下面步骤在Primary Database上执行不完全恢复: 1.使用 LogMiner 或其它方法来确定在那个时间或 SCN,数据库中的所有数据是好的。 2.使用时间或 SCN,执行下面 RMAN 命令来做不完全数据库恢复并使用 RESETLOGS 选项打开数据库(在连接到目录数据库和处于 MOUNT 状态的主instance之后): RUN { SET UNTIL TIME 'time'; RESTORE DATABASE; RECOVER DATABASE; } ALTER DATABASE OPEN RESETLOGS; 在这个过程之后,所有Standby Databaseinstance必须在 Data Guard 配置中重新建立。 10.3 额外的备份情况 下面小节描述了如何对于其它配置更改备份步骤,如当备和Primary Database无法共享备份文 件时;备instance只用于远程archived redo log files时;或Standby Database文件名不同于Primary Database时。 10.3.1 Standby Database地理距离太远无法共享备份 在这种情况中,在Standby system上进行的备份不容易被Primary system(主系统)或其它Standby system访问到。在所有 系统上执行数据库的完全备份以执行恢复操作。Flash Recovery Areas能位于主和Standby system的本地(例如, Flash Recovery Areas对于Primary Database 和 Standby Database不是同一个)。 在这个场景中,你还是可以使用 10.2 节中描述的普通策略,但有如下例外: d 由 RMAN 创建的备份文件必须标记本地系统名字,在 RESTORE 操作时必须使用 标记以限制 RMAN 选择在同一主机上进行的备份。换句话说,BACKUP 命令在创 建备份时必须使用 TAG node name 选项;RESTORE 命令必须使用 FROM TAG node 使用 RMAN 来备份和还原文件 10-6 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 name 选项;并且 RECOVER 命令必须使用 FROM TAG node name ARCHIVELOG TAG node name 选项。 d Standby node的灾难恢复: 1.使用备instance以前操作使用的同样参数文件以 NOMOUNT 状态启动备instance。 2.使用 SQL ALTER DATABASE CREATE STANDBY CONTROLFILE AS filename 语句在主instance上创建一个备控制文件,并使用创建的控制文件来安装备instance。 3.执行下面 RMAN 命令来还原和恢复数据库文件: RESTORE DATABASE FROM TAG 'node name' RECOVER DATABASE FROM TAG 'node name' ARCHIVELOG TAG 'node name' 4.重启Redo应用。 备instance将取得 5.8 节中描述的剩余archived redo log files。 10.3.2 Standby Database不包含数据文件,用于 FAL 服务器 使用在 10.1 节中描述的同样步骤,除了备份数据文件的 RMAN 命令不能对 FAL 服务 器运行。对于所有archived redo log files FAL 服务器能用于备份源,从而减负向 FAL 服务器的 archived redo log files的备份。 10.3.3 Standby Database文件名不同于Primary Database 如果数据库文件名在Primary Database 和 Standby Database上是不同的,你使用的 RESTORE 和 RECOVER 命 令将会稍微不同。要获得Standby Database上实际的数据文件名字,查询 V$DATAFILE 视图并对于 数据库中的所有数据文件指定 SET NEWNAME 选项: RUN { SET NEWNAME FOR DATAFILE 1 TO 'existing file location for file#1 from V$DATAFILE'; SET NEWNAME FOR DATAFILE 2 TO 'existing file location for file#2 from V$DATAFILE'; … … SET NEWNAME FOR DATAFILE n TO 'existing file location for file#n from V$DATAFILE'; RESTORE {DATAFILE | TABLESPACE tbs_name_1, 2, …| DATABASE; SWITCH DATAFILE ALL; RECOVER DATABASE {NOREDO}; } 类似地,在Standby Database恢复期间,RMAN DUPLICATE 命令也应该使用 SET NEWNAME 选项来指定新的文件名。 10.3.4 对于Flash Recovery Areas中的archived redo log files的删除策略 使用 RMAN 来备份和还原文件 10-7 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 默认地,在Flash Recovery Areas中已备份到第三方设备或变得废弃(如 RMAN 保留策略定义) 的archived redo log files是适宜删除的。如果Flash Recovery Areas中的磁盘空间变满了,已备份或废弃的 archived redo log files最终能被自动删除以腾出空间。然而,你可以使用下面 RMAN 命令来更改 这种默认删除策略: CONFIGURE ARCHIVELOG DELETION POLICY TO [CLEAR | NONE | APPLIED ON STANDBY ]; 本小节描述命令限定词并提供设置删除策略的例子。查看 Oracle 数据库备份和恢复高 级用户指南以获得 Oracle 软件如何管理Flash Recovery Areas中的磁盘空间的更多相关信息。 使用 APPLIED ON STANDBY 子句 使用 APPLIED ON STANDBY 子句使得已经被应用到所有强制Standby Destination的归档Redo日 志文件将被删除。当你指定这个子句时进行的处理在下面表中描述: 当 APPLIED ON STANDBY 子句配置在… 然后,这些文件适宜于删除… Primary Database 在Flash Recovery Areas中已经应用在所有强制备数据 库上的archived redo log files 有一个或更多强制级联Standby Database的Standby Database 在Flash Recovery Areas中已经应用在所有强制级联备 数据库上的archived redo log files 没有级联备数控的Standby Database 在Flash Recovery Areas中已经应用在Standby Database上的归 档redo log files 查看附录 E 以获得级联Destination的更多相关信息。 使用 CLEAR 子句 使用 CLEAR 子句来禁止以前使用 RMAN CONFIGURE ARCHIVELOG DELETION POLICY 命令设置的删除策略。Oracle 数据库将继续默认的删除策略行为,就是如果闪回恢 复区中的磁盘空间变满就删除已备份或废弃的归档redo log。 使用 NONE 子句 使用 NONE 子句使得在Flash Recovery Areas中已备份或作为 RMAN 保留策略废弃的归档Redo日 志适宜于删除。这是默认的配置。如果Flash Recovery Areas中的磁盘空间变满了,已备份或废弃的归 档redo log files被删除以腾出空间。 CONFIGURE ARCHIVELOG DELETION POLICY 命令的例子 当在Standby Database上进行archived redo log files的备份时: 1.在Primary Database上执行下面命令: CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY ; 2.在Standby Database上执行下面命令: CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; 当在Primary Database上进行archived redo log files的备份时: 1.在Standby Database上执行下面命令: CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY ; 使用 RMAN 来备份和还原文件 10-8 B14239 Oracle Data Guard 概念和管理 10g 版本 2 fable_cao 翻译 2.在Primary Database上执行下面命令: CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; 10.3.4.1 在角色转换之后重新配置删除策略 在切换或failover之后,你可能需要在每个数据库上重新执行 RMAN CONFIGURE ARCHIVELOG DELETION POLICY 命令。如果对于archived redo log files的备份节点保持相 同,则不需要操作。否则,你必须通过在不进行备份的数据库上执行 CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY 语句来切换归档日志删除 策略,并在进行备份的数据库上执行 CONFIGURE ARCHIVELOG DELETION POLICY TO NONE 语句。 10.3.4.2 查看当前删除策略 要查看数据库的当前设置(APPLIED ON STANDBY 、CLEAR、NONE),执行下面查 询: SELECT NAME, VALUE FROM V$RMAN_CONFIGURATION WHERE NAME LIKE '%ARCHIVELOG DELETION POLICY%'; NAME VALUE ----------------------------- -------------- ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY 你也可以使用 RMAN SHOW ARCHIVELOG DELETION POLICY 命令来找出现有的配 置: RMAN> SHOW ARCHIVELOG DELETION POLICY RMAN configuration parameters are: CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY ;

下载文档到电脑,查找使用更方便

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 15 金币 [ 分享文档获得金币 ] 0 人已下载

下载文档