下载 Oracle 数据库

标签 database, enterprisemanagement, 全部

轻松预防生产灾难

使用 Oracle Enterprise Manager Grid Control 进行 Data Guard 的设置、管理（包括切换或故障切换）和监视可节省大量的时间和资源。

作者：Porus Homi Havewala

2010 年 1 月发表

意外停机带来的成本有可能高的惊人，尤其是在当今的经济形势下。员工生产时的意外停机每小时可能导致数千美元的产出损失，同时可能还伴随着业务的丢失，这将给竞争对手提供可乘之机。公司声望和相关股价也将受到威胁。

为防止服务器故障，长期以来的典型做法一直是提供高可用性 (HA)。多年以来，一直使用主动/被动集群来实现这一理念。通常使用可切换的 LUN（在存储术语中称作逻辑单元号）的概念从一台服务器故障切换到另一台服务器。被动服务器可以访问 LUN 上的数据库文件，Oracle 实例在被动服务器上重启和恢复。

这种过时的技术很快被主动/主动集群数据库的新概念所取代，多台服务器可通过 Oracle Real Application Clusters (RAC) 访问共享存储中的同一个数据库。该方法通过负载平衡和水平向外扩展功能，可避免所有服务器故障、提供高可用性并促进所有服务器的最佳利用。

但是对于站点故障（威胁整个计算机站点的自然或认为灾难），HA 尚不足以满足要求。因此，需要一个真正的灾难恢复 (DR) 解决方案，在该解决方案中，“备用”数据库位于一个距离主站点足够远的站点，能够隔离来自任何主站点的灾难。

在早期，为 Oracle 数据库建立 DR 需要建立手动备用数据库。这项技术是 Oracle Consulting 在 7.3 之前开发的，包括在备用服务器上安装 Oracle 软件，将主数据库的备份复制到备用服务器，启动备用服务器恢复，然后运行手动编写的 shell 脚本将新生成的存档日志从主服务器传输到备用服务器。其他脚本以持续的恢复模式将这些日志应用于备用数据库。日志的应用还受到脚本的监视。

有时，如果备用服务器落后（即日志文件没有传输过来或者被其他某个进程删除），就需要手动解决这些差异。甚至今天，在某些使用 Oracle Database 标准版的公司中还在使用类似的手动备用技术，而且是唯一的选择。

Oracle 从 7.3 开始正式支持备用数据库，并且每个数据库版本都有所改进。Oracle8i (8.1.7) 允许使用 Oracle SqlNet 8 传输日志，而不再使用脚本化的 OS 层文件传输。同时还引进了受控的数据库恢复，可以自动在备用数据库上应用存档日志。这就删除了流程中的许多脚本，提高了自动化程度。

随着 Oracle 8.1.7 中的 Oracle Data Guard 的发布，各种应用情况变得丰富多彩起来。Oracle Data Guard 可单独安装或解压缩在 Oracle 安装目录中，它包含若干用于部署 Data Guard 的 shell 脚本和一个 Data Guard 命令行控制界面，通过该界面在主备用服务器上均可启动 Data Guard 引擎。最后，可以从 Oracle Data Guard 方便地发布命令来执行切换或故障切换。

在 Oracle9i Database 中，Oracle Data Guard 通过成为内核的一部分得以增强，由服务器后台进程处理重做传输和应用。同时还引入了 Data Guard Broker 及其后台进程 (DMON)。

每个新版本都在不断增强功能。然而，有了所有这些新特性后，Data Guard 的设置也自然变得越来越复杂，相应地增加了人为错误的风险。幸好，Oracle 创建了一个强大的工具来帮助设置 Data Guard：Oracle Enterprise Manager。

尤其是通过 Oracle Enterprise Manager Grid Control 10g 的全新界面和体系结构，许多日常的 DBA 任务得以简化和自动化，这些任务包括性能管理（诊断和调优），创建和执行计划的数据库备份，在操作系统和数据库级执行计划的脚本，下载和应用数据库补丁，服务器、操作系统和数据库的受控配置管理，以及 Oracle Data Guard 备用数据库的设置、管理和日常监视，这些内容就是本文章的主题。

如今，Grid Control 使您可以设置、管理和监视从 Oracle9i 开始的所有数据库版本的 Oracle Data Guard，这就为那些常常使用多个数据库版本的公司站点提供了一个非常强大的工具。（很显然，需要正确构建 Grid Control 站点使其能够执行这些不同任务。有关推荐的 Grid Control 可伸缩体系结构的概述，请参见我发表在 Oracle 技术网上的文章“面向大型站点的 Oracle 企业管理器网格控制体系结构”。）

Grid Control 提供了一个简化、无错的分步式方法，在运行 Grid Control 引擎的任何服务器上设置 Oracle Data Guard。在一个已使用 Grid Control 进行标准化的大公司中，分布在公司各处不同站点的多个 DBA 团队使用这个工具针对不同项目管理和监视多个版本的 Oracle 数据库。使用 Grid Control 进行 Data Guard 的设置、管理（包括切换和故障切换）和监视可大大节省时间、消除定制脚本和减少人为错误。

从长远来看，任何公司站点都可遵循此示例，不仅能显著节省成本，还能使 DBA 生活变得轻松惬意。

第一步：创建备用 Oracle 主目录

考虑已经安装了第 5 版补丁的 Oracle Enterprise Manager Grid Control 10g (10.2.0.5.0)。控制台的 Home 页如图 1 所示。

图 1 Grid Control 的 Home 页

Grid Control 需要在您希望监视和管理的每个服务器目标上安装一个代理。您的实际情况中，已经安装了代理的服务器上有一个主数据库 FINPRD1，通过 Grid Control 管理该数据库。

现在，您考虑另一台用作备用数据库服务器的服务器。备用服务器与主服务器使用相同的操作系统，并且代理已经安装到备用服务器自己的代理主目录中。

因为不存在 Oracle 主目录，所以首先在备用服务器上安装 Oracle Database 软件并创建主目录。如图 2 所示，通过在 Grid Control 的 Deployments 选项卡的 Cloning 部分下选择 Clone Oracle Home 实用程序可以实现此目的。

图 2 Deployments 选项卡

Clone Oracle Home 实用程序的任何生产目的使用都需要 Oracle Enterprise Manager Provisioning Pack 许可。 这个通用的软件包还可实现多种其他自动化功能，如克隆 Oracle 数据库以及通过部署过程为数据库打补丁。

图 3 所显示的 Cloning 实用程序的首页使您可以选择希望克隆的 Oracle 主目录：Source Home。

图 3 Clone Oracle Home:Source Home

该页的“View Source Type”下拉框显示，可以从任何可见的安装 Oracle 主目录中选择 Source Home 作为 Oracle Grid Control 中的目标，也可以从 Oracle Grid Control 软件库中选择。

后一种选择使您可以在公司站点中存储标准 Oracle 主目录的“黄金副本”，在需要时使用克隆实用程序创建新的 Oracle 软件安装（这是 Provisioning Pack 的一大好处），同时还可以克隆标准 黄金 副本 Oracle 数据库。

选择主服务器上的主目录。单击 Next。您可以在下个页面（图 4）中指定复制期间的工作目录以及要排除的文件。

图 4 Clone Oracle Home:Source Settings

默认情况下，排除列表中的某些文件不会复制到克隆的主目录中。这一点很有意义，因为这些文件与源 Oracle 主目录关系密切，可能不适用于目标主目录：

*.log,*.dbf,*.aud,*.trc,EMStagedPatches,sqlnet.ora,tnsnames.ora,listener. ora,oratab

下个页面（图 5 ）允许您从目标主机列表中选择主机。本页将只显示与主服务器具有相同操作系统的主机。选择您要安装备用数据库的主机 — Oracle 主目录将复制到指定的主目录位置，即：

D:\app\porushh\product\11.1.0\db_1

将新 Oracle 主目录名称指定为“OraDb11g_home_stby”，并且为备用主机提供登录凭证。注意，可在该页添加多个目标，这意味着可以使用该“Clone Oracle Home”实用程序从一个源 Oracle 主目录（即黄金副本）在不同的目标上创建多个克隆的主目录。

图 5 Clone Oracle Home:Destinations

下一步使您可以指定克隆前脚本和克隆后脚本。这有助于定义克隆操作。可以选择主机命令或脚本。单击 Next。系统会要求您为目标主机指定主机名和 Oracle 基目录。指定 Oracle 基目录为 D:\app\porushh，代替原始的 C:\app\porushh。

在下个页面（图 6），系统要求您对克隆操作做出计划。为克隆创建一个作业，可立刻调度该作业，也可以后再调度。Enterprise Manager 的作业调度器会在选定的时间调度该作业。

图 6 Clone Oracle Home:Schedule

显示 Summary 页。确认克隆操作。单击 View Job 查看该作业的进度。如果计划设置为立刻运行，则将立刻执行该作业（图 7），开始克隆 Oracle 主目录的操作。

图 7 作业执行：克隆 Oracle 主目录

在页面上显示“Prepare Source Home”的步骤中（这是“Clone Oracle Home”作业的最初步骤），您可以看到在临时目录中创建了一个很大的 zip 文件，其中排除了列出的文件：

                                 
C:\OracleHomes\agent10g\bin\zip -r -S -9 
"C:\temp\oemchsED724047ACDB4DBCB7C2EE14AC386371\homeArchive" * -x "" "*.log" 
"*.log/*" "*.dbf" "*.dbf/*" "*.aud" "*.aud/*" "*.trc" "*.trc/*" 
"EMStagedPatches" "*/EMStagedPatches" "EMStagedPatches/*" "*/EMStagedPatches/*" 
"sqlnet.ora" "*/sqlnet.ora" "sqlnet.ora/*" "*/sqlnet.ora/*" "tnsnames.ora" 
"*/tnsnames.ora" "tnsnames.ora/*" "*/tnsnames.ora/*" "listener.ora" 
"*/listener.ora" "listener.ora/*" "*/listener.ora/*" "oratab" "*/oratab" 
"oratab/*" "*/oratab/*" 1> NUL

                              

之后，该 zip 文件将解压缩到目标目录中。创建主目录还包括其他一些后续步骤，如在 Oracle Enterprise Manager Grid Control 中自动查找该 zip 文件，以便后用。完成作业并创建完主目录后，您可以继续创建备用数据库的下个步骤。

使用 Grid Control 创建备用数据库

FINPRD1 数据库是主（生产）数据库。在 Oracle Enterprise Manager Grid Control 控制台中，选择 Targets..Databases 并单击该数据库显示其主页。单击 Availability 选项卡（图 8）。

图 8 Availability 选项卡

在该页的 Data Guard 部分下，选择 Add Standby Database。如果您尚未登录到 FINPRD1 数据库，现在系统要求您登录。以 SYSDBA 身份连接，然后继续。因为这是 Data Guard 首次用于该数据库，选择 Add Standby Database 来配置环境（图 9）。

图 9 Add Standby Database

选择您希望创建的备用数据库的类型（图 10）。主要选项包括新物理数据库或新逻辑数据库，您也可以添加现有的主用/备用数据库组合（可能已经手动建立），以便可由 Data Broker 管理，通过 Grid Control 进行控制。

图 10 选择备用数据库的类型

对 DR 来说，物理备用数据库通常是最好的选择，因为它是主数据库的一个精确副本，也是最快的备用类型。选择该选项后继续。

下一步是选择创建物理备用数据库将使用的方法（图 11）。

通常使用 Oracle Recovery Manager (RMAN) 执行主数据库的联机备份。这将在建立备用数据库时提供使用最新的主数据库副本，通过 RMAN 直接复制文件。

图 11 Add Standby Database:Backup Type

您决定是使用“Perform an online backup of the Primary database”还是使用“Use Recovery Manager (RMAN) to copy database files”。在本例中，不需要临时区域，因为将直接通过 RMAN 复制文件。

联机备份中的另一个选项是通过两个服务器上的临时区域复制数据库文件，请不要选择它。

显示“Add Standby Database:Backup Options”页面（图 12）。

图 12 Add Standby Database:Backup Options

在该页面中，指定将联机备份复制到备用数据库时使用的并发 RMAN 进程的数量。如果带宽充足，可以增加进程的数量，以便更快地创建备用数据库。在此还可以指定主服务器凭证。

在“Primary Database Standby Redo Log Files”部分下面，如果还没有备用重做日志文件，应将其添加到主数据库中。备用重做日志文件是 Oracle 针对备用数据库的最佳实践；这些文件使主数据库在转换为备用角色时能够接收重做日志数据。同步和异步重做传输模式也要求重做传输目标有备用重做日志。因此，这些日志十分重要。您可以决定将 Oracle 管理的文件 (OMF) 用于备用重做文件，尽可能简化设置。

可在下个页面（图 13）指定备用数据库的属性，如实例名称（该名称在备用主机上必须具有唯一性）。将备用数据库命名为 FINSTBY1。指定使用“File System”建立备用数据库。如果在备用服务器上已经安装了 Oracle 自动存储管理 (ASM) 实例，可将 ASM 指定为备用数据库存储。

图 13 Add Standby Database:Database Location

在同一页，您还可以选择备用主机和用来创建备用数据库的 Oracle 主目录。Oracle Enterprise Manager Grid Control 允许您从已经安装了 Grid Control 代理的主机目标列表中进行选择。

作为使用 Oracle Data Guard 的先决条件，主用主机与备用主机的操作系统应该相同，该列表反映了这一要求。注意，有些特殊情况下，由于字长（操作系统和/或数据库）、Linux 发布版本、操作系统或硬件体系结构的差异，Data Guard 配置中主备操作系统间的 Oracle 库可能存在差别。（支持 Data Guard 配置的最新信息，请参见 MetaLink 说明 413484.1。）Data Guard 备用数据库创建向导不允许在这些支持的混合平台上创建备用数据库，这些类型的备用数据库必须手动创建或导入 Grid Control 中。
备用主机上应存在 Oracle 主目录，与主 Oracle 主目录的版本也应匹配。因为你已经使用 Oracle Enterprise Manager Provisioning Pack 的“Clone Oracle Home”功能在备用主机上创建了新的 Oracle 主目录，因此可以继续进行其他步骤。

下个页面（图 14）使您可以指定备用数据库文件的位置。自定义备用数据库的文件位置，或者接受由 Oracle 建议的最佳弹性体系结构 (OFA)。

图 14 Add Standby Database:File Locations

只有在除主数据库之外的主机上创建了备用数据库，并且不使用 RMAN 复制 11g 数据库的数据库文件时，该页面才会单独显示“Backup File Access”部分。因为已经选择了 RMAN，因此图 14 中看不到这一部分。图 14 演示了 Grid Control 的直观特性，随着每个版本所提供的特性不同，不同数据库版本的该页面也有所不同。

在 Backup File Access 部分显示时，选择一种使主数据库备份文件能够用于备用主机的方法。一个选项是将文件从主用主机的工作目录传输到备用主机的工作目录 — 只需在备用主机上为从主用主机复制的备份文件指定临时位置。

文件传输机制使用 FTP 时，这是最快的方法。如果企业策略不支持或不允许 FTP，可以选择 Enterprise Manager HTTP Server 选项。将 Enterprise Manager 配置为使用 HTTPS，这样可以用安全的方式传输文件。

在实际情况中，另一个常用的访问备份文件的方法是通过 NFS — 主数据库规模很大、传输时间过长时，这是一个尤为有效的方法。如果能够通过共享的 NFS 或者其他网络方法从备用主机访问主用主机的工作目录，您可以选择“Directly Access the Primary host working directory location from the Standby host using a network pathname”。由于此方法既节省时间，又节省磁盘空间，并且还无需将备份文件传输到备用主机上，因此推荐使用。

在同一页面（图 14）中，使用“Network Configuration File Location”指定目标系统的 OracleNet 文件驻留的目录的位置，这样 Data Guard 能够将新备用数据库的配置信息添加到 listener.ora 和 tnsnames.ora 文件中。默认情况下，该目录设置为新的 ORACLE 主目录的 network/admin 子目录。

单击 Customize 按钮查看备用数据库的文件位置。您会看到 OFA 建议最好将备用数据库文件放在如下位置：

D:\app\porushh\product\11.1.0\db_1\oradata\FINSTBY1

您决定修改这些位置。可以一起设置所有数据文件的位置，还可以设置临时文件、日志文件、控制文件、目录对象和外部文件的位置。这些内容显示在页面的不同部分。选择“Set location for all files”，再针对每个文件类型单击“Go”按钮，将位置设置为以下目录：

C:\ORADATA\FINSTBY1

完成这些修改后，页面如图 15 所示。注意“Log Files”部分将四个重做日志显示为 Oracle 管理的文件。这些文件与刚添加到主数据库的备用重做日志是完全相同的。

图 15 Customize Destination Options

单击 OK。Grid Control 显示一个警告，提示指定的目录不存在，但会自动创建。单击 Continue。

下个页面（图 16）是备用数据库配置页面。这是一个重要页面，在此设置备用数据库参数。

图 16 Add Standby Database:Configuration

第一个参数是备用数据库在企业中的唯一名称：DB_UNIQUE_NAME 参数。因为您已经确认 FINSTBY1 在您公司中是唯一的，因此将 DB_UNIQUE_NAME 设置为 FINSTBY1。

Target Name 是 Enterprise Manager 用于显示的名称。建议与唯一名称相同，因此将 Target Name 也设置为 FINSTBY1。

Standby Archive Location 是放置从主数据库收到的存档重做日志的位置。建议将其设置为：

D:\app\porushh\product\11.1.0\db_1\oradata\FINSTBY1\arc

因为您还希望将该位置用作快速恢复区，因此更改为：

D:\flash_recovery_area\FINSTBY1

快速恢复区 (FRA) 的大小取决于您打算在其中保留的信息；闪回数据库日志、存档日志、数据库的完整副本等等。该参数可以根据您的需求和每家公司的策略进行修改。这里，我们将使用 4000MB。

在同一页面中，指定 Data Guard 使用的 Enterprise Manager 监视凭证。如果公司策略允许，这些可以是非 SYSDBA，如“dbsnmp”用户。这样设置的不足在于：Enterprise Manager 无法监视挂载的物理备用数据库，因为只有以 SYSDBA 身份登录才能连接到挂载的数据库。指定 SYSDBA 监视凭证可以避免出现这种情况。

在 Data Broker 部分，选择使用 Data Guard Broker 管理 Data Guard 配置（推荐）。在该页面底部（图 16 没能完全显示出来），还可以选择使用 Enterprise Manager 连接描述符作为主用和备用数据库的 Data Guard 连接标识符。您还可以选择提供自己的 TNS 标识符以使用现有的服务名称。

显示 Review 页面（图 17）。展开 Standby Database Storage 部分，确保所有细节都是正确的，然后单击 Finish。

图 17 Add Standby Database:Review

完成最初的几个步骤（如创建 Data Guard 配置和准备作业）后，就可以提交创建备用数据库的 Enterprise Manager 作业。

图 18 显示了这几个初始步骤。其中我们注意到：在提交备用数据库创建作业之前，允许 Cancel。

图 18 Processing:Add Standby Database（允许取消）

图 19 显示了初始步骤的最后阶段，此时，因为备用数据库创建作业已经提交，因此不能再取消该进程。

图 19 Processing:Add Standby Database（不能取消）

现在，已经提交了备用数据库创建作业，开始根据 RMAN 或使用前几页选择的其他方法构建备用数据库。该作业提交后，您将返回 Data Guard 主页。

完成创建作业后，在 Enterprise Manager Grid Control 的“Targets..Databases”列表中即可看到主用/备用数据库组合（图 20），显示为 Database Instance:Primary 和 Database Instance:Physical Standby。

两个数据库均显示为 Status – Up。

图 20 目标数据库

选择主数据库 FINPRD1，进入它的数据库主页，转到 Availability 选项卡。在“Data Guard”部分，可以看到几个新选项（图 21），因为该主数据库对应的备用数据库现在可用了。

除了以前的“Setup and Manage”选项外，这几个新选项分别是“Performance”、“Verify Configuration”和“Add Standby Database”。

图 21 显示新的 Data Guard 选项

选择 Setup and Manage；这是您的主用/备用 Data Guard 配置的主 Data Guard 管理页面（图 22）。

您可以一目了然地观察到 Data Guard Status (normal)、所用的 Protection Mode（默认为 Maximum Performance），以及是否启用了 Fast-Start Failover（默认为 Disabled）。快速启动故障切换 (Fast-Start Failover) 是 Data Guard 10g 的一个新特性，如果启用该特性，在主数据库故障时，无需人工干预，备用数据库即可承担主数据库的角色。

图 22 Data Guard 管理页面

该页面突出显示了 “Standby Progress Summary” ，分别为以图形方式显示的 Transport lag 指示器和 Apply lag 指示器。这可以使您根据日志的传输与应用情况，了解备用数据库落后于主数据库的情况。

主用/备用数据库均处于“Normal”状态。显示了主数据库的当前日志、备用数据库上最新接收和应用的日志，以及估算的故障切换时间（小于 1 秒）。在该页面中，您可以编辑主数据库或备用数据库的 Data Guard 属性，甚至可以添加额外的备用数据库（最多可以向 Data Guard 配置添加九个备用数据库）。

最重要的是，在该页面中可以执行到选定备用数据库的“切换”或“故障切换”。通常，切换用于计划停机，而存在真实灾难（意外停机）时使用故障切换。

建议您单击“Additional Administration”部分下面的 Verify Configuration，对您的主用/备用数据库组合执行一组自动检查。Grid Control 会验证备用数据库的各种设置（图 23）。

主数据库上的当前日志被切换，保护模式得以验证，备用重做日志文件已经检查，日志切换得到验证。生成了一份有关您的 Data Guard 设置情况的详细报告。这将主动帮助您测试您的设置并发现任何问题。

图 23 Processing:Verify Configuration

通过 Data Guard 的主管理页面，可以方便地编辑主数据库或备用数据库的 Data Guard 属性，参见图 22。

单击 Primary Database 部分 Properties 项的 Edit，或者先选择您要编辑的备用数据库，然后单击 Standby Databases 部分下面的 Edit 按钮。

将弹出一组属性选项卡。在主数据库的情况下，第一个是 General 属性选项卡（图 24），在此，您可以打开或关闭重做传输，这将启动或停止向所有备用数据库运送数据。

如果您因为某些计划的工作需要使主数据库停机，这个特性非常有用。备用数据库继续运行。

图 24 Edit Primary Database Properties:General 选项卡

第二个选项卡是“Standby Role Properties”（图 25）。

使用该选项卡，您可以修改重要的 Data Guard 属性，如“Redo Transport Mode”（默认为 ASYNC）、“Net timeout”或“Apply Delay”，使用“Apply Delay”，您可以特意在备用和主用间留出一段时间，以防止主数据库用户的人为错误。

图 25 Edit Primary Database Properties:Standby Role Properties

例如，如果将“Apply Delay”指定为 30 分钟，则 30 分钟后后日志才应用到备用数据库。这样，DBA 有机会阻止任何用户错误进入备用数据库。

第三个选项卡（“Common Properties”）显示了使用的 Data Guard 连接标识符、日志存档进程的个数，以及日志存档跟踪级别 — 为了有助于调试，可以将日志存档跟踪级别设置为较大的值。参见图 26。

图 26 Edit Primary Database Properties:Common Properties

总结及有关 Grid Control 的其他信息

使用 Oracle Enterprise Manager Grid Control，您已经可以轻松地对生产进行“灾难预防”，它明确地为设置 Data Guard 备用配置提供了一个非常成熟的方法。

Grid Control 非常有助于 Data Guard 的日常监视和管理，计划停机的切换和意外停机的故障切换也包括在管理之中。Oracle9i、10g 和 11g 中都提供了常用的 Data Guard 界面，在 Data Guard 设置期间可自动提供每个数据库版本中的新特性，这就使得 Grid Control 成为在整个公司站点实施 Data Guard 时一个非常通用的管理系统。

另外，还可以使用 Grid Control 建立和计划公司数据库的 Oracle RMAN 备份。这点在我的文章“Oracle RMAN 备份：提供简单方式”中有所介绍，本文演示了一家大型公司如何改用 Oracle Enterprise Manager Grid Control 管理公司的 Oracle 数据库备份。

如果您还想了解如何对您环境中的 Oracle RAC 或 非 RAC 数据库、ASM 实例和集群件自动打补丁，请阅读我最近发表的另一篇文章“使用 Oracle Enterprise Manager Grid Control 修补数千个数据库”。享用 Grid Control 的强大功能。

Porus Homi Havewala（Oracle ACE 总监）是 S & I Systems Pte Ltd（Oracle 的白金合作伙伴）的首席顾问。他在 Oracle 技术方面经验丰富，自 1994 年以来担任过生产 DBA、高级顾问、电子商务技术 DBA 和系统管理员、开发 DBA 以及数据库设计人员/建模人员（当然使用 Oracle Designer）。