使用 Oracle Enterprise Manager Cloud Control 12c 安装和管理
使用 Oracle Enterprise Manager Cloud Control 12c 安装和管理 Oracle Data Guard作者：Porus Homi Havewala 使用 Oracle Oracle Enterprise Manager Cloud Control 12c 的 Oracle Data Guard 安装和管理功能控制停机时间和简化灾难恢复。 2013 年 8 月 下载 数据库和服务器的停机时间可以精心规划，也可以毫无计划！就业务成本而言，任何类型的停机都是昂贵的。但是，可以通过数据库技术特性（如滚动升级或异地修补）控制和减少计划停机时间。对企业而言，意外停机代价更高，因为在这段时间内，员工处于空闲状态，企业网站无法访问，从而造成收入损失和信誉损失。 高可用性 (HA) 是各大公司用来防御服务器故障的主要策略。多年来，这一技术通常都是以主动-被动式集群的形式实现。在主动-被动式集群中，被称为 LUN（逻辑单元编号）的存储单元在两台服务器之间共享，但每次只能由一台主服务器访问。数据库文件位于该 LUN 上，Oracle 实例在主服务器的内存中启动。 当主服务器出现故障时，LUN 切换到辅助服务器，并在该服务器的内存中重新启动实例。多年来，这种主动-被动技术曾一直是企业计算机中心的 HA 标准。唯一的缺点是，集群可能会因一些微不足道的原因，意外地自动切换到被动服务器上，例如，当主动服务器的网络访问速度变慢，或数据库因本地 DBA 维护而被关闭时。对于后面这种情况，必须先禁用集群监视软件，才能对数据库展开维护工作。 Oracle 是主动-主动式集群的先行者。在这种情况下，一个数据库在多台服务器上运行实例，所有这些实例访问同一个数据库存储。第一个版本称作 Oracle Parallel Server (OPS)，但当时集群技术刚刚起步，使用共享存储本身作为节点间传输数据块的方法。这种技术有性能局限性，并且安装非常复杂，因此实施 OPS 的企业非常少，懂得 OPS 的 DBA 薪水都很高。 当 Oracle 开发出新版本的主动-主动式集群（从 Oracle 9i 开始命名为 Oracle Real Application Clusters (RAC)）后，情况有了很大改观。它采用了最新的 Oracle 缓存融合技术，该技术的突破在于，数据库第一次使用节点的内存（缓存）跨互连传输请求的数据块。 从某种意义上说，多个集群节点上的实例缓存融合在了一起。该技术显著提升了跨实例数据块访问的性能，使 Oracle Database 9i Real Application Clusters (RAC) 成为了主动-被动技术极具实用价值的可扩展替代方案。 Oracle RAC 显然能够防御服务器故障，如果其中一个节点发生故障，数据库不会受到影响，因为其他节点还在继续工作。因此，这是一个非常有效的高可用性解决方案。 此外，它还有一个巨大的优势，那就是通过智能负载平衡，集群中的所有服务器可实现最佳利用。由于负载在所有节点间共享，因此 RAC 集群可以横向扩展，这是主动-被动式集群无法做到的，除非将应用程序和数据库分解成碎片。 但将应用程序和数据库分解成碎片能持续多久呢？对于大多数应用程序，RAC 配置不需要这样做。起初，您可以只部署少量的 RAC 节点，不需要一开始就部署大型服务器来适应未来增长。 2009 年年底，Oracle 在 Oracle 11g 第 2 版中引入了新的 HA 技术 — Oracle RAC One Node。实际上就是在集群中某个节点上运行的 RAC，与主动-被动方案一样，具备故障切换保护功能。不同的是，RAC One Node 可以轻松地在线升级为全主动-主动式 RAC 集群。这是其他第三方主动-被动式集群无法做到的。 昔日的 Oracle 灾难恢复想像一下整个计算机站点停机的情景，无论是自然的还是人为的，实际灾难就是这种情况。在这种情况下，HA 技术将无能为力。无论是主动-被动还是主动-主动 RAC 服务器，只要所属的站点受到灾难，都将全军覆没！我们需要一套真正的灾难恢复 (DR) 解决方案，能够在完全不同的站点接管服务器，并且站点之间的距离足够遥远，这样才不会受到主站点灾难的影响。 在响应客户请求时，Oracle 顾问咨询团队首次将灾难恢复的概念应用到 Oracle 数据库中。手动备用数据库是主要工具 — 这是在 Oracle 7.3 诞生之前的情况。虽然该技术非常原始，但为 Oracle 不断发展的备用数据库概念奠定了基础。所执行的步骤大体如下：
但是，这个过程中有一些问题。有时日志应用过程会被中断，原因是网络故障导致存档日志无法传输到备用服务器。或者，即使传输了，但未经授权的删除或硬盘损坏等原因导致它们无法应用到备用数据库时，也会出现这个问题。这些原因导致的中断必须手动解决。 奇怪的是，即使是今天，也还有一些公司使用这种手动编写脚本的方法部署备用数据库。这是因为他们使用的是 Oracle Database Server 标准版（SE) 数据库软件 — 只有 Oracle Database Server 企业版 (EE） 才允许使用 Oracle 最新的高级备用技术。这是 EE 相比 SE 的众多优点之一。 在 7.3 版的数据库软件中，Oracle 正式开始支持备用数据库机制。随着版本的更迭，这项支持得到了长足的发展。Oracle 8.1.7 开始通过 Oracle SqlNet 8 机制（取代 ftp/scp 操作系统实用程序）在主数据库与备用数据库之间传输日志。当时推出的另一个新特性是托管数据库恢复，可将所传输的存档日志自动应用到备用数据库。 有了这些新特性，以前在备用数据库安装过程中所使用的手动脚本现已不再需要。这成功迈出了自动化的第一步。 但 8.1.7 版的最大亮点是 Oracle 新推的“Data Guard”技术 — 历史的结晶。您必须单独从 Oracle 技术网 (OTN) 下载 Oracle Data Guard，然后将其解压到 Oracle 主目录下的子目录中。 当时的 Oracle Data Guard 是一个 Unix shell 脚本集，例如 dgdeploy.sh，用于部署主数据库和备用数据库的 Data Guard 配置。它还有一个命令行界面 Data Guard Control (dgdctl)，使您能够相当轻松地切换或故障切换到备用数据库。 在 Oracle 9i 中，Data Guard 升级为 Oracle 内核的一部分，在性能和内存管理方面都有所提升。除了其他后台进程外，Data Guard 代理现在有了一个新的专用 Oracle 后台进程 DMON。 Oracle 10g 和 11g 继续对 Data Guard 技术进行了增强。但 Data Guard 安装、配置和维护的复杂性也相应增加，而且整个过程中发生人为错误的机率更大，尤其当您有多对主数据库和对应的备用数据库时更是如此。 随着 Oracle Database 从 9i 起日趋复杂，需要一个强大的工具来驱动 Data Guard 的安装和配置。Oracle Enterprise Manager 9i 就是这样一个工具，它提供了一个向导，允许您直接从 Enterprise Manager 控制台安装 Data Guard 备用数据库。您还可以从 Enterprise Manager 9i 本身切换或故障切换到备用数据库，不需要使用 Data Guard 命令行界面手动执行。 处理备用数据库的下一版 Enterprise Manager 是 Grid Control 10g。这进一步增强了 Data Guard 配置的安装过程，并且还包括了对整个配置过程的监视界面。Grid Control 11g 和最新的 Cloud Control 12c 出色地兼顾了备用数据库的创建和监视，同时还增加了快照备用数据库等新特性。 总的来说，Enterprise Manager 凭借其新的架构和接口，已被证明是 DBA 的得力助手。除了提供和应用数据库补丁以及配置管理和监视应用程序、数据库、操作系统和服务器，Cloud Control 12c 还擅长简化和自动化 DBA 的许多日常任务，如性能诊断、调优、调度数据库和操作系统脚本、配置和调度数据库 RMAN 备份。当然，作为打造企业灾难恢复能力的理想工具，使用 Cloud Control 12c，您还可以轻松安装 Data Guard 配置、管理配置、切换或故障切换数据库，以及监视主数据库和备用数据库。 更不可思议的是，Oracle 9i、10g、11g 以及最新发布的 Oracle Database 12c 全部包括在 Enterprise Manager Cloud Control 12c 的 Data Guard 安装和管理功能之中。通常，大公司都有这些数据库的现有版本。用于创建备用数据库的向导是一个分步式的、指导性的、无错误的 Oracle Data Guard 安装过程。通过此过程，您可以在公司范围内的任何服务器上安装备用数据库，但前提是，在实际设置之前，该服务器上已安装并运行了 Cloud Control 12c。 如果大公司规范了 Enterprise Manager Cloud Control 12c 的使用，那么在整个公司中，为 Oracle 数据库配置灾难恢复将是一个非常轻松的过程。可以节省很多时间，无需自定义脚本，并且大大减少了人为错误。 请注意，Enterprise Manager Cloud Control 12c 的基本安装包括购买任何 Oracle 软件许可证或支持合同时赠送的几个免费特性。所幸的是，使用 Enterprise Manager 配置和查看备用数据库的功能涵盖在基本数据库管理功能中，如 Oracle Enterprise Manager 许可信息指南所述。 初始步骤在想要通过 Enterprise Manager Cloud Control 12c 监视和管理的每个主机上，都必须安装和运行 12c 代理。这是前提条件，因为该代理用于在主机上的目标和 Oracle Management Service (OMS) 之间进行通信。 假定主数据库已由 Cloud Control 12c 管理，您现在要切换到将被用作备用服务器的服务器。根据 Oracle Data Guard 的要求，主服务器和备用服务器必须是相同的操作系统，但操作系统的补丁集版本可以不同。 Oracle 软件的要求更为严格。Oracle 软件必须是相同的版本 — 包括 Oracle 补丁集版本。 在该备用服务器上做的第一件事就是，使用位于目标服务器上单独的代理主目录安装 Enterprise Manager Cloud Control12C 代理。一旦 EM 代理开始与中央 OMS 通信，中央 Enterprise Manager 站点将提供有关备用服务器的所有信息。 该代理安装完成后，备用服务器将有一个代理主目录，但没有 Oracle 主目录，因为此服务器上尚未安装 Oracle 数据库软件。 您可以手动从 CD 安装 Oracle 企业版 (EE) 软件，也可以使用从 Oracle 技术网 (OTN) 下载的安装文件。请确保您安装的不是标准版 (SE)，因为标准版不允许使用 Data Guard。 另一种更快、更好的方法是使用 Enterprise Manager Cloud Control 12c 的供应功能。可通过 Enterprise Manager Console 菜单中的 Enterprise..Provisioning 和 Patching..Database Provisioning 访问。然后，选择“Provision Oracle Database”部署过程。这使您可以从 Enterprise Manager 本身部署 Oracle 软件，即通过软件库中称为配置文件的预存储黄金副本来部署。此功能需要 Enterprise Manager Database Lifecycle Management Pack (DBLM) 的许可。 部署过程完成后，备用服务器上将生成一个新的 Oracle 主目录。现在可以继续创建备用数据库了。 添加备用数据库转到 Enterprise Manager Cloud Control 12c 控制台中的 Targets..Databases，然后在出现的数据库列表中选择 PROD 生产数据库。 这将是 Data Guard 配置中的主数据库。 PROD 数据库 Home 页面出现时，从数据库目标菜单中选择 Availability..Add Standby Database，如下图所示。
如果您之前没有登录到 PROD 数据库，那么您需要在出现登录屏幕时登录。 以 SYSDBA 权限连接。这是为 11g 及早期版本的所有数据库配置和监视 Oracle Data Guard 的必要条件。在新的 Oracle Database 12c 中，现在有一个不同的权限 SYSDG。此权限允许用户执行 Data Guard 操作。这一广受欢迎的增强终于在 Oracle Database 12c 中实现了，这意味着没有 sysdba 权限也能实现 Data Guard 的管理。 向导现在会显示下一个页面，您可以选择要创建的备用数据库的类型。
主要选项是新的物理备用或新的逻辑备用。 但是，如果您已经手动配置了一个备用数据库，也可以在此阶段将其添加到 Data Guard 配置。您可以通过选择 Manage an existing standby database with Data Guard broker 完成该操作。 对于 Oracle Database 12c，添加备用数据库时，只有当生产容器数据库 (CDB) 中的所有可拔插数据库 (PDB) 都已打开，向导才会继续。如下面的屏幕截图所示。向导现在是 CDB 和 PDB 感知型，可以从容器数据库创建备用数据库。请注意，所创建的备用数据库适用于整个 CDB 及其中包含的所有 PDB。
在物理备用数据库与逻辑备用数据库之间进行选择时，大多数情况下，物理备用数据库更合适，因为它比逻辑备用的性能更好。逻辑备用在允许的数据类型方面也有一些限制。 因此，我们选择 Create a new physical standby database 以使用物理备用。单击 Continue。向导随即启动，并显示第一步，如下图所示。
现在，我们选择将用于创建物理备用的备份方法。 联机备份主数据库最简单的方法是通过 Oracle Recovery Manager (RMAN)。备份文件将由 RMAN 复制到备用服务器。 它会提供最新的主数据库副本 — 作为主数据库精确副本的物理备用。 也可以使用之前创建的 RMAN 数据库备份（如夜间备份）。如果数据库很大，而此时您又不想再次进行联机备份，可以这样做。 选择 Online Backup 和 Use Recovery Manager (RMAN) to copy database files。在这种情况下，文件将由 RMAN 复制到备用服务器上，所以不需要临时区域。 但是，如果您愿意，也可以选择使用临时区域，但这时主服务器和备用服务器上都必须使用临时区域。 单击 Next 继续。
随即出现 Add Standby Database:Backup Options 页面。 在此页面中，您可以输入并发文件复制进程的数量。它们是 RMAN 用来将数据库文件复制到备用的并行通道。 只要有足够的带宽，您就可以增加进程数（默认情况下是 2）。进程越多，备用的创建速度越快。 只有当您在单独的主机（不是主用主机）上创建备用，并且不使用 RMAN 复制数据库文件（对于 11g 数据库），而是在图 4 所示的 Online Backup 选项中选择了“Copy database files via staging areas”时，此页面上才会出现新的部分“Staging Area”。 在本例中，我们使用 RMAN，所以上面的屏幕不会显示该部分 — 显示屏幕的动态特征。 对于不同的数据库版本，该向导还会显示不同的选项，具体取决于该版本的技术进展。 还可以在此页面指定主用主机登录凭据。您可以使用现有的首选或命名的凭据，也可以创建一个新凭据。 Primary Database Standby Redo Log Files 部分表示向导会自动将备用重做日志文件添加到主数据库。 备用重做日志对 Data Guard 的运行非常重要。其主要目的是，几乎在主数据库生成重做日志的同时便将其填充到备用日志，从而将重做数据实时地应用到备用。所以您不必等待存档日志被传输至备用。 这意味着，如果有故障切换，在实时应用的情况下，数据损失会最小，因为没有丢失重做数据。 因此，无论使用同步还是异步重做传输模式，传输目标都必须有备用重做日志。 还会在主数据库中创建备用重做日志，因为它们使主数据库在获得备用数据库角色后接收重做日志数据。 为了简化安装，您可以将 Oracle 托管文件 (OMF) 用作备用重做文件。Oracle 将自动命名这些文件，并将它们放在目录结构中。如果您不使用 OMF 文件，您必须指定自己的文件名称和目录位置。 单击 Next 继续。
您可以在以下页面指定备用数据库的属性。 备用主机上的实例名称必须是唯一的。在本例中，您可以将备用数据库命名为“stby”。选择“File System”作为备用数据库的数据库存储类型。 另一个选择是 Oracle Automatic Storage Management (ASM)。只有当备用服务器上运行了 ASM 实例时，才可将其指定为备用数据库存储。 在 Standby Database Location 下，输入主机名和所创建备用数据库的 Oracle 主目录位置。您可以从 Cloud Control 12c 系统中的主机目标列表中选择。该列表仅显示操作系统与主用主机相同的主机，因为这是 Oracle Data Guard 的要求，Enterprise ManagerCloud Control 12c 了解这一点。在 Oracle 主目录的版本方面，主备也必须相同。有关受支持 Data Guard 配置的列表，请参见 My Oracle Support (MOS) 说明 413484.1。 Oracle 主目录二进制文件可能因数据库或操作系统级别的字大小或者不同硬件、不同操作系统，甚至不同的 Linux 发行版本，而有所不同。 在此类情况下，虽然不能使用 Data Guard 备用创建向导在此类不同的主备平台上创建备用数据库，但您可以手动创建，然后使用 Data Guard 代理进行管理（管理现有备用数据库的这一选项如图 2 所示）。 请记住，备用主机上已经创建了新的 Oracle 主目录。 单击 Next 继续。
现在，您可以指定备用数据库文件的位置。 一种选择是接受建议的最佳灵活架构 (OFA) 位置，或者您也可以通过单击 Customize 按钮手动更改文件位置。
现在，您可以看到备用数据库的建议文件位置。基于 OFA，数据文件和临时文件的位置如下所示： /app/oracle/product/oradata/stby/*.dbf 如果要更改这些位置，可以批量进行 — 例如，针对所有数据文件、临时文件、日志文件、控制文件、目录对象和页面上各部分的外部文件。向下滚动到 Log Files 和 Control Files 部分。
您可以一次性将所有同类文件的位置设置成一个适合的目录。 在 Log Files 部分可以看到，最近添加到主数据库的备用重做日志是 Oracle 托管文件。 向下滚动到 Directory Objects 和 External Files 部分，如图 10 所示。
当您通过选择 OK 接受更改时，会出现一个警告。这表示将自动创建您指定的目录，因为它们目前不存在于服务器上。这没有关系，您可以继续。 您将回到 File Locations 屏幕。单击 Next 继续。
随即出现备用数据库配置页面。 可以在这里设置备用数据库控制参数。首先，您可以通过 DB_UNIQUE_NAME 参数设置备用数据库的唯一名称。 本例设置为 stby。公司其他地方不能有同名的数据库，该名称必须是唯一的。 接下来，设置备用数据库的目标名称。它用作目标在 Enterprise Manager Cloud Control 12c 屏幕上的显示名称。使其与该唯一名称相同，所以这里还是 stby。 如果您愿意，您可以更改 Standby Archive Location，并将其配置为快速恢复区 (FRA)。Data Guard 将从主数据库收到的已存档重做日志放置到此处。 通常，根据经验，快速恢复区的大小应该是数据库大小的两倍。但具体值因不同的公司而异。在本例中，我们使用 7500 MB。 Data Guard 的 Enterprise Manager 监视凭据也在这些页面上指定。如果您打算监视挂载的备用数据库，则应使用 SYSDBA 登录（只有 SYSDBA 可以连接到挂载的数据库），否则使用普通凭据即可，例如，“dbsnmp”用户即可满足贵公司的安全要求。 向下滚动到此页面的 Data Broker 部分。
在 Data Broker 部分，建议使用 Data Guard Broker 管理 Data Guard 配置。 您可以使用 Enterprise Manager 连接描述符作为主备数据库的 Data Guard 连接标识符，也可以使用已经存在的网络服务名称。 单击 Next 继续。
您现在看到的是 Review 页面。 在此页面中，如果您想确认是否正确指定了所有位置，可以展开 Standby Database Storage 部分。 然后选择 Finish。
Enterprise Manager 作业系统现在可以提交备用数据库创建作业。这将使用向导页面中选择的方法（RMAN 备份和复制或其他方法）开始创建备用数据库。 随即显示此数据库的 Data Guard Home 页面，稍后您将用它监视 Data Guard 的运行。物理备用目前显示为 Down，因为它还在创建中。如果要监视作业的进度，请单击 View job。
备用创建作业最终所需时间取决于主数据库的大小和选择用于创建备用数据库的方法。 这个时候，Enterprise Manager Cloud Control 12c 的 Targets..Databases 列表将显示主数据库和备用数据库，如下图所示。
我们可以看到 Database Instance:Primary 和 Database Instance:Physical Standby。这两个数据库的状态都显示为 Up。 Data Guard 的菜单选项在 Enterprise Manager Cloud Control 12c 中，转至主数据库的 Home 页面。从菜单中选择 Availability。 现在，我们可以看到菜单中与 Data Guard 有关的几个新选项。
由于 Enterprise Manager 检测到该主数据库有活动的 Data Guard 配置，所以出现了这些选项。 这些选项是 Data Guard Administration、Data Guard Performance 和 Verify Data Guard Configuration。这些选项是原有 Add Standby Database 的补充。 选择 Verify Data Guard Configuration 通过脚本自动检查 Data Guard 配置，以确保日志能够正常传输和应用，而不用实际执行故障切换或切换。 建议初次安装时执行，此后定期执行。从图 18 中可以看出，该步骤会验证不同的主备数据库设置。
这个过程会切换主数据库的当前日志，随后验证快速启动故障切换服务和保护模式。 然后检查备用重做日志文件。日志切换已成功验证。
然后，验证配置过程会就 Data Guard 配置的运行状况生成一份详细报告，这有助于让 DBA 注意到任何紧急问题。 选择 Availability..Data Guard Performance。随即出现以下屏幕。
在 Data Guard Performance 页面中，您可以监视主数据库中的 Redo Generation Rate 和备用数据库中的 Apply Rate 和 Lag Times。有一个 Switch Log 按钮，用于存档主数据库上的当前日志文件组。 另一个有用的选项是“Test Application”功能。通过 Start/Stop/Pause 按钮，您可以在主数据库上生成一个负载，并查看 Data Guard 配置如何应对增加的负载。 Data Guard 管理单击“Data Guard Administration”。这将打开 Data Guard Administration 页面，如下图所示。
此页面用于管理这个主数据库以及与之关联的备用数据库的整个 Data Guard 配置。 Data Guard Administration 页面显示了 Data Guard Status，值是“Normal”。它还显示了所使用的 Protection Mode — 默认值是 Maximum Performance。 我们还可以看到 Fast-Start Failover 是否已启用。默认情况下，此特性被禁用。快速启动故障切换是 Oracle Data Guard 10g 中引入的新特性。如果启用此特性，备用数据库能够获得主数据库的状态 — 即无论任何原因，一旦主数据库发生故障，便会执行故障切换，无需人工干预。 查看 Standby Database Progress Summary 部分。它以条形图的形式显示了传输延迟和应用延迟。传输延迟指主数据库上次更新与备用数据库上次收到重做之间的时间差。应用延迟指主数据库上次更新与备用数据库上次应用重做之间的时间差。 通过与日志的传输和应用有关的这两项计算，DBA 一看就知道备用数据库滞后于主数据库的时间。 我们也可以看到这两个数据库的状态 — 它们处于 Normal 状态。Administration 页面还显示了主数据库的当前日志，以及备用数据库上次收到的日志和上次应用的日志。预计故障切换时间小于 1 秒。 Data Guard Administration 页面还允许您编辑主备 Data Guard 属性。您甚至可以向此 Data Guard 配置添加其他备用数据库 — 对于 Oracle Data Guard 11.2，总共最多可添加 30 个备用数据库。 DBA 还可以直接从 Administration 页面“切换”或“故障切换”到所选的备用数据库。如果灾难导致意外停机，将需要进行故障切换，而切换可以用于计划停机，例如安装操作系统补丁或机器升级。 编辑备用数据库属性在 Data Guard Administration 页面，您可以编辑主备数据库的 Data Guard 属性。 通过单选按钮选择备用数据库，然后单击 Edit 按钮。随即出现 Edit Standby Database Properties 页面。
备用数据库的属性屏幕中有三个选项卡 — General、Standby Role Properties 和 Common Properties。 在 General 选项卡的 Redo Apply Services 下，您可以打开或关闭重做日志应用，以便所有重做日志重新开始或停止应用到备用数据库。 如果您愿意，您可以（但不建议）禁用数据库的 Data Guard Broker 管理。 还有一个 Diagnostics 部分，您可以在此处查看主备数据库的警报日志，如果您愿意，也可以向任一服务器发起 telnet 会话。 还可以启用备用数据库的实时查询，即以只读模式打开数据库时应用重做日志。这就是 Active Data Guard 选项，需要额外的许可。 在此页面上启用实时查询，然后转至 Standby Role Properties 选项卡。
下一个选项卡是 Standby Role Properties。您可以在这里将 Redo Transport Mode 修改为 SYNC — 与默认的 ASYNC 相反。 您还可以更改 Net Timeout 属性以应对网络较慢的情况，以及更改 Apply Delay 为主备数据库之间的日志应用指定具体延迟分钟数。 如果用户在主数据库上发生人为错误，并且 DBA 及时得知，则时间延迟有助于从备用数据库恢复数据，或故障切换到备用数据库。 毫无疑问，这些都是重要的 Data Guard 属性，因此必须仔细理解和实施。Enterprise Manager Cloud Control 12c 一目了然地显示了所有属性，有助于理解可能性。 假设将 Apply Delay 指定为 15 分钟。这意味着传输到备用服务器的日志将必须在 15 分钟后才会应用到备用数据库。如果用户现在删除了一个表并立即通知 DBA，DBA 可以停止备用数据库日志的应用，然后从备用数据库恢复所删除的表，如果需要，可以故障切换到备用数据库。 您可以在此页面上启用 Redo Compression，这样就能以压缩形式传输重做数据。 转至 Common Properties 选项卡。
第三个选项卡是 Common Properties。此选项卡显示 Data Guard 所使用的连接标识符和日志存档进程数。 它还显示 Log Archive Trace 级别。调试 Data Guard 配置时，后者可以设置为较高的值。 单击 Apply。属性将被保存。 编辑主数据库属性在 Data Guard Administration 页面，可以通过单击 Edit 链接编辑主数据库的属性（见图 25）。
随即打开 Edit Primary Database Properties 页面。此页面有三个选项卡，类似于 Standby Database Properties 页面。
在 General 选项卡的 Redo Transport Services 下，您可以打开或关闭重做日志传输，以便重做日志重新开始或停止传输到备用数据库。 当发生网络中断或类似事件，即您知道日志不能发送到备用数据库，并且主数据库一直尝试发送日志毫无意义时，可以使用这项操作。 如果主数据库正处于维护停机状态，关闭重做传输是最好的选择。 Primary Database Properties 中的另外两个选项卡 Standby Role Properties 和 Common Properties 与 Standby Database Properties 完全一样。 转换为快照备用回到 Data Guard Administration 页面。请注意 Standby Databases 部分的 Convert 按钮。它用于将备用数据库转换为快照备用数据库。 Oracle Data Guard 11g 中引入了这种数据库。转换为快照备用数据库后，数据库变成可读写状态。它可用于测试，一旦完成，便可回到其以前的状态（使用 Oracle 闪回技术），并且可以应用所有重做日志，以便像普通备用数据库一样重新与生产数据库同步。
选择所需的备用数据库，然后单击 Convert 按钮。出现以下警告。
如果单击 Yes 按钮，备用数据库将转换成快照备用数据库，并且此信息将出现在 Data Guard Administration 页面（见图 29）。
测试完成后，可以通过单击 Convert 按钮将其转换回物理备用数据库。 切换和故障切换现在我们来讨论切换和/故障切换到备用数据库的过程。它们是 Oracle Data Guard 的重要特性，也是 Oracle Data Guard 的用途所在，用于计划停机（切换）或意外停机（故障切换），后者是灾难场景。 在 Oracle Database 12c 中，正如前文所述，备用发生在 CDB 级别。不能切换或故障切换到 CDB 中的各个 PDB。 现在，Data Guard Administration 页面将数据库再次显示为物理备用（见图 30）。
使用 Enterprise Manager，可以轻松切换到备用数据库。单击 Switchover 按钮。将显示以下消息。
切换允许主数据库与备用数据库交换角色。由于主数据库会话将被关闭，因此您可以使用页面上的链接浏览它们。 此外，您还可以选择交换监视设置，包括度量阈值。 切换过程启动并显示进度（见图 32）。
切换完成后，选择 Return to Data Guard Overview 时，作业和监视设置会继续在后台传输。
在 Data Guard Administration 页面，很明显角色已发生互换，stby 数据库现在是主数据库，而 prod 数据库现在是备用数据库。 这也可以在 dgmgrl 的 Data Guard 命令行界面中进行验证。
dgmgrl 的命令行界面反映了 Enterprise Manager 信息，还显示了这两个数据库互换后的角色。这通过 show configuration verbose 命令实现。 现在可以在 Enterprise Manager 中再次执行切换，将角色返回到之前的状态。 现在，我们将执行故障切换。在现实的灾难情形中，即主数据库发生故障（因任何原因）并且无法再使用时，使用故障切换。在这种情况下，备用数据库必须作为主数据库打开。此过程称为故障切换。 在 dgmgrl 中，执行故障切换的方法如下：
由于主数据库停机，dgmgrl 显示无法访问此数据库。执行 failover to stby 命令。操作成功。
再次执行 show configuration verbose 命令，stby 数据库变成了主数据库。 prod 数据库现在是物理备用数据库，但显示了一条消息，指示必须恢复 prod 数据库。 可以从 Enterprise Manager 执行 prod 数据库的恢复，如图 37 所示。只需单击 Database must be reinstated 链接即可。
但这将产生错误，因为未启用闪回数据库。恢复使用了闪回数据库技术。
该错误导致 dgmgrl 中的配置状态更改为 the standby database needs to be re-created（见图 39）。
现在，使用本文之前章节介绍的 Enterprise Manager 向导，您可以轻松地将备用数据库重新创建为 prod。 Oracle Database 12c 中的远程同步 Oracle Database 12c 有一种新的备用，称为“远程同步”。Oracle Data Guard 远程同步实例实际上是从主数据库接收重做的远程 Oracle Data Guard 目标。然后，重做会传输到 Oracle Data Guard 配置的其他成员。 远程同步实例有一个控制文件，将收到的重做转发给备用重做日志，并将这些日志存档在本地已存档日志中。但远程同步实例没有用户数据文件。因此该实例不能打开进行访问、不能运行重做应用、不能成为主数据库，甚至不能成为任何类型的备用数据库。 远程同步实例是 Oracle Active Data Guard 远程同步特性的一部分，需要 Oracle Active Data Guard 许可。 Enterprise Manager 12c Cloud Control 目前不支持创建远程同步实例。但是，外部创建的远程同步实例将显示在 Data Guard Administration 页面。 总结如这篇技术文章所述，使用 Oracle Enterprise Manager Cloud Control 12c 可以轻松配置、管理和监视任何主数据库的备用数据库。由 Oracle 提供的用于创建和管理 Data Guard 配置的 Web 界面在各方面都非常先进，并且极其易用。 DBA 可以利用 Enterprise Manager 进行 Data Guard 配置的日常监视和管理。在计划停机或意外停机的情况下，他们还可以轻松切换或故障切换到备用，从 Enterprise Manager Cloud Control 12c 控制台或 dgmgrl 界面即可完成这一切。 Enterprise Manager Cloud Control 12c 提供了一个通用的标准界面来配置和管理适用于 9i、10g、11g 以及最新 Oracle Database 12c 的 Oracle Data Guard。针对不同的数据库版本，Oracle Data Guard 自动为 DBA 提供不同的高级特性，降低了学习难度。因此，Enterprise Manager Cloud Control 12c 有助于针对大公司的各种 Oracle Database 版本实施 Oracle Data Guard。 关于作者Porus Homi Havewala 是 Oracle 新加坡企业技术项目办公室的高级经理，同时也是 Oracle Enterprise Manager 技术的东盟区域中小企业和业务发展带头人。作为 Oracle 10g 和 Oracle 11g 的 Oracle 双认证大师 (OCM)，Porus 拥有超过 25 年的 IT 从业经验，包括超过 18 年的 Oracle 技术使用经验。他写过两本著作，分别是《Oracle Enterprise Manager Cloud Control 12c:Managing Data Center Chaos》（2012 年，Packt Publishing 出版）和《Oracle Enterprise Manager Grid Control:Advanced OEM Techniques for the Real World》（2010 年，Rampant TechPress 出版），他还是博文 Oracle Enterprise Manager Cloud Control 12c 的作者。 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |