Oracle Data Guard Administration
Oracle Data Guard Administration
Introduction
我们创建好数据库，将数据存储到数据库，修改数据库中的数据，查询数据库中的数据。但这就够了吗？在实际工作中，往往还存在以下需求：
- 灾难恢复，数据库出现问题后能够快速恢复数据和业务。
- 数据保护，数据库提供只读数据给特定用户。
- 报表分析，对于IO密集的报表分析数据库应该与正常业务数据库分离。
- 每日恢复，测试开发需要与生产数据库尽可能一致的测试数据库，用于预发布和问题排查。
Oracle 数据库提供了 Data Guard 组件来实现上述需求。
Data Guard Configurations
Data Guard 配置由一个生产数据库和一个或多个备用数据库组成。Data Guard 配置中的数据库通过 Oracle Net 连接。
典型的 Data Guard 配置：
Primary Database
Data Guard 配置包含一个生产数据库（也称为主库 primary database），以主库角色运行。生产应用程序访问此数据库。
主库可以是单实例 Oracle 数据库，也可以是 Oracle Real Application Clusters （Oracle RAC） 数据库。
Standby Databases
备用数据库库（也成为备库 standby database）是主库的事务一致性副本。最多可以创建 30 个备库。创建后，Data Guard 将重做日志从主库传输到备库，然后应用重做日志到备库。
备库也可以是单实例 Oracle 数据库或 Oracle RAC 数据库。
备库的类型有：
物理备库（Physical standby database），提供与主库物理上相同的副本。物理备库通过应用重做日志（Redo Apply）与主库保持同步。可用于灾难恢复、数据保护以及报表分析。
逻辑备库（Logical standby database），包含与主库相同的逻辑信息。逻辑备库通过 SQL Apply 与主库保持同步，将从主库接收的重做日志中的数据转换为 SQL 语句，然后在备库上执行 SQL 语句。可用于灾难恢复、报表分析以及滚动升级。
快照备库（Snapshot Standby Database），将只读的物理备库临时切换为可读可写，此时备库仍从主库接收重做日志，但不会应用，而对备库进行的 DML 操作将会被写入到闪回日志中。后续切换为只读的物理备库时，会将闪回日志中的 DML 操作回滚，并应用之前接收到的重做日志，以保持与主库一致。可用于预发布以及问题排查。
Data Guard Operational Prerequisites
Hardware and Operating System Requirements
在Oracle 11g，主库和备库可以是：
- 不同的 CPU 架构
- 不同的操作系统
- 不同的操作系统位数（32位/64位）
- 不同的 Oracle 软件位数（32位/64位）
主库和备库的数据库版本需要一致，在使用逻辑备库进行滚动升级的时候可以不一致。
对于物理备库的跨平台支持和限制参考文档 413484.1，具体如下：
| PLATFORM_ID | PLATFORM_NAME Release name | PLATFORM_IDs supported within the same Data Guard configuration when using Data Guard Redo Apply (Physical Standby) |
|---|---|---|
| 2 | Solaris[tm] OE (64-bit) Solaris Operating System (SPARC) (64-bit) | 2 6 - See Support Note: 1982638.1 and Note: 414043.1 |
| 3 | HP-UX (64-bit) HP-UX PA-RISC | 3 4 - Oracle 10g onward, see Support Note: 395982.1 and Note:414043.1 |
| 4 | HP-UX IA (64-bit) HP-UX Itanium | 4 3 - Oracle 10g onward, see Support Notes Note: 395982.1 and [Note:414043.1](https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=413484.1&id=414043.1 |
| 5 | HP Tru64 UNIX HP Tru64 UNIX | 5 |
| 6 | IBM AIX on POWER Systems (64-bit) | 2 - See Support Note: 1982638.1 and Note: 414043.1 6 |
| 7 | Microsoft Windows (32-bit) Microsoft Windows (x86) | 7 8, 12 - Oracle 10g onward, see Support Note: 414043.1 10 - Oracle 11g onward, requires Patch 13104881 --> Fix for 13104881 Included in 12.1 11, 13 - Oracle 11g onward, see Support Note: 414043.1, also requires Patch 13104881 |
| 8 | Microsoft Windows IA (64-bit) Microsoft Windows (64-bit Itanium) | 7 - Oracle 10g onward, see Support Note: 414043.1 8 12 - Oracle 10g onward 11, 13 - Oracle 11g onward, requires Patch 13104881 |
| 9 | IBM zSeries Based Linux z/Linux | 9 18 (64-bit zSeries only) |
| 10 | Linux (32-bit) Linux x86 | 7 - Oracle 11g onward, requires Patch 13104881 10 11, 13 - Oracle 10g onward, see Support Note: 414043.1 |
| 11 | Linux IA (64-bit) Linux Itanium | 10 - Oracle 10g onward, see Support Note: 414043.1 11 13 - Oracle 10g onward 7 - Oracle 11g onward, see Support Note: 414043.1, also requires Patch 13104881 8, 12 - Oracle 11g onward, requires Patch 13104881 |
| 12 | Microsoft Windows 64-bit for AMD Microsoft Windows (x86-64) | 7 - Oracle 10g onward, see Support Note Note: 414043.1 8 - Oracle 10g onward 12 11, 13 - Oracle 11g onward, requires Patch 13104881 |
| 13 | Linux 64-bit for AMD Linux x86-64 | 7 - Oracle 11g onward, see Support Note: 414043.1, also requires Patch 13104881 10 - Oracle 10g onward, see Support Note Note: 414043.1 11 - Oracle 10g onward 8, 12 - Oracle 11g onward, requires Patch 13104881 13 20 - Oracle 11g onward |
| 15 | HP Open VMS HP OpenVMS Alpha HP IA OpenVMS OpenVMS Itanium | 15 |
| 16 | Apple Mac OS Mac OS X Server | 16 |
| 17 | Solaris Operating System (x86) Solaris Operating System (x86) | 17 20 - Oracle 10g onward, see Support Note: 414043.1 |
| 18 | IBM Power Based Linux Linux on Power | 9 (64-bit zSeries only) 18 |
| 20 | Solaris Operating System (AMD64) Solaris Operating System (x86-64) | 13 - Oracle 11g onward 17 - Oracle 10g onward, see Support Note: 414043.1 20 |
对于逻辑备库的跨平台支持和限制参考文档 1085687.1，具体如下：
| PLATFORM_ID | PLATFORM_NAME Release name | PLATFORM_IDs supported within the same Data Guard configuration when using Data Guard SQL Apply (Logical Standby) |
|---|---|---|
| 2 | Solaris[tm] OE (64-bit) Solaris Operating System (SPARC) (64-bit) | 2 |
| 3 | HP-UX (64-bit) HP-UX PA-RISC | 3, 4 |
| 4 | HP-UX IA (64-bit) HP-UX Itanium | 3, 4 |
| 5 | HP Tru64 UNIX HP Tru64 UNIX | 5 |
| 6 | AIX-Based Systems (64-bit) AIX5L | 6 |
| 7 | Microsoft Windows (32-bit) Microsoft Windows (x86) | 7 10 requires patch for Bug 13104881 8, 12 - Replication can only occur from a 32-bit primary to a 64-bit standby, once a role transition has promoted the 64-bit system to the primary role, the original 32-bit primary is not supported as a standby database. |
| 8 | Microsoft Windows IA (64-bit) Microsoft Windows (64-bit Itanium) | 7 - Replication can only occur from a 32-bit primary to a 64-bit standby, once a role transition has promoted the 64-bit system to the primary role, the original 32-bit primary is not supported as a standby database. 8, 12 11, 13, both require patch for Bug 13104881 |
| 9 | IBM zSeries Based Linux z/Linux | 9 |
| 10 | Linux (32-bit) Linux x86 | 7, requires patch for Bug 13104881 10 11, 13 - Replication can only occur from a 32-bit primary to a 64-bit standby, once a role transition has promoted the 64-bit system to the primary role, the original 32-bit primary is not supported as a standby database. |
| 11 | Linux IA (64-bit) Linux Itanium | 10 - Replication can only occur from a 32-bit primary to a 64-bit standby, once a role transition has promoted the 64-bit system to the primary role, the original 32-bit primary is not supported as a standby database. 8, requires patch for Bug 13104881 11, 13 |
| 12 | Microsoft Windows 64-bit for AMD Microsoft Windows (x86-64) | 7 - from Oracle 11g onward. Replication can only occur from a 32-bit primary to a 64-bit standby, once a role transition has promoted the 64-bit system to the primary role, the original 32-bit primary is not supported as a standby database. 8, 12 |
| 13 | Linux 64-bit for AMD Linux x86-64 | 10 - Replication can only occur from a 32-bit primary to a 64-bit standby, once a role transition has promoted the 64-bit system to the primary role, the original 32-bit primary is not supported as a standby database. 8, requires patch for Bug 13104881 11, 13 |
| 15 | HP Open VMS HP OpenVMS Alpha HP IA OpenVMS OpenVMS Itanium | 15 |
| 16 | Apple Mac OS Mac OS X Server | 16 |
| 17 | Solaris Operating System (x86) Solaris Operating System (x86) | 17 |
| 18 | IBM Power Based Linux Linux on Power | 18 |
| 20 | Solaris Operating System (AMD64) Solaris Operating System (x86-64) | 20 |
Oracle Software Requirements
- Oracle 数据库企业版才包含 Data Guard 组件。
- 需要将 Data Guard 配置中所有数据库的 COMPATIBLE 参数设置为一致，但是逻辑备库的 COMPATIBLE 可以比主库大。
- 主库必须运行在归档模式。
- 不建议主库和备库位于同一主机上，如果不能避免，则主库和备库的归档目录必须不同。
- 建议主库启用 FORCE LOGGING。
- 建议 Data Guard 配置中所有数据库都使用 OMF 管理文件。
- 建议 Data Guard 配置中所有数据库都设置相同时区。
Redo Transport Services
重做日志传输服务（Redo transport services）在 Oracle 数据库之间执行重做日志的自动传输。
支持以下传输目标：
- Data Guard 备库
- 归档日志仓库
- 流复制中间库
- CDC中间库
Oracle 数据库可以将重做日志发送到多达 30 个传输目标。可以为每个传输目标单独配置以下两种传输模式之一：
同步模式，事务必须等待其产生的重做日志都成功发送到使用同步模式的传输目标后，才能提交。
异步模式，事务可以提交，无需等待其产生的重做日志是否成功发送到使用异步模式的传输目标。
Configuring Redo Transport Services
Redo Transport Authentication Using a Password File
在 Data Guard 配置中，所有备库都必须使用主库的密码文件副本，并且每当授予或回收 SYSOPER 或 SYSDBA 权限时，以及在更改具有这些权限的用户的密码后，都必须刷新该副本。
当密码文件用于重做日志传输身份验证时，将在主库和目标库之间比较用于重做日志传输的用户帐户密码。两个数据库中的密码必须相同才能创建重做日志传输会话。
默认情况下，使用密码文件时，SYS 用户的密码用于对重做日志传输会话进行身份验证。 REDO_TRANSPORT_USER 初始化参数可用于指定其他用户密码进行重做日志传输身份验证，方法是将此参数设置为已授予 SYSOPER 权限的用户名。为了便于管理，Oracle 建议在主库和每个备库上将 REDO_TRANSPORT_USER 参数设置为相同的值。
Configuring an Oracle Database to Send Redo Data
LOG_ARCHIVE_DEST_n 初始化参数（其中 n 是 1 到 31 之间的整数）用于指定重做日志的本地归档位置或指定重做日志的远程传输目标。
LOG_ARCHIVE_DEST_STATE_n 初始化参数（其中 n 是 1 到 31 之间的整数），对应于每个 LOG_ARCHIVE_DEST_n 参数。用于启用或禁用相应的重做日志传输目标。此参数的有效值如下：
| Value | Description |
|---|---|
ENABLE | Redo transport services can transmit redo data to this destination. This is the default. |
DEFER | Redo transport services will not transmit redo data to this destination. |
ALTERNATE | This destination will become enabled if communication to its associated destination fails. |
通过将 LOG_ARCHIVE_DEST_n 参数设置为包含一个或多个属性的字符串来配置重做日志传输目标。
语法：
LOG_ARCHIVE_DEST_[1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31] =
{ null_string |
{ LOCATION=path_name | SERVICE=service_name }
[ MANDATORY ]
[ REOPEN[=seconds] ]
[ DELAY[=minutes] ]
[ NOREGISTER ]
[ TEMPLATE=template ]
[ ALTERNATE=destination ]
[ MAX_FAILURE=count ]
[ SYNC | ASYNC ]
[ AFFIRM | NOAFFIRM ]
[ NET_TIMEOUT=seconds ]
[ VALID_FOR=(redo_log_type,database_role) ]
[ DB_UNIQUE_NAME ]
[ MAX_CONNECTIONS=count ]
[ COMPRESSION={ENABLE|DISABLE} ]
}
LOCATION 属性用于指定日志传输目标为本地目录。
SERVICE 属性是重做日志传输目标的必需属性，必须是属性列表中指定的第一个属性。用于指定用于连接到重做日志传输目标的 Oracle Net 连接描述符。连接描述符配置在 ORACLE_HOME/network/admin/tnsnames.ora 文件中。
LOG_ARCHIVE_DEST_1到 LOG_ARCHIVE_DEST_10 可以设置为 LOCATION 或 SERVICE。
LOG_ARCHIVE_DEST_11到 LOG_ARCHIVE_DEST_31 只能设置为 SERVICE。
| Category | LOCATION=local_disk_directory or USE_DB_RECOVERY_FILE_DEST | SERVICE=net_service_name |
|---|---|---|
| Data type | String value | String value |
| Valid values | Not applicable | Not applicable |
| Default Value | None | None |
| Requires attributes | Not applicable | Not applicable |
| Conflicts with attributes | SERVICE, DELAY, NOREGISTER, SYNC, ASYNC, NET_TIMEOUT, AFFIRM,NOAFFIRM, COMPRESSION, MAX_CONNECTIONS | LOCATION |
| Corresponds to | DESTINATION and TARGET columns of the V$ARCHIVE_DEST view | DESTINATION and TARGET columns of the V$ARCHIVE_DEST view |
SYNC 属性用于指定使用同步模式传输重做日志。
ASYNC 属性用于指定使用异步模式传输重做日志。
如果未指定 SYNC 和 ASYNC 属性，则将使用异步模式。
| Category | SYNC | ASYNC |
|---|---|---|
| Data type | Keyword | Keyword |
| Valid values | Not applicable | Not applicable |
| Default value | Not applicable | None |
| Requires attributes | None | None |
| Conflicts with attributes | ASYNC, LOCATION | SYNC, LOCATION |
| Corresponds to | TRANSMIT_MODE column of the V$ARCHIVE_DEST view | TRANSMIT_MODE and column of the V$ARCHIVE_DEST view |
NET_TIMEOUT 属性用于指定在同步模式下 LGWR 进程的超时等待时间。如果在 NET_TIMEOUT 秒内未收到确认，则会终止重做日志传输连接并记录错误。Oracle 建议在使用同步模式时指定 NET_TIMEOUT 属性。
| Category | NET_TIMEOUT=seconds |
|---|---|
| Data type | Numeric |
| Valid values | 1 to 1200 |
| Default value | 30 seconds |
| Requires attributes | SYNC |
| Conflicts with attributes | ASYNC (If you specify the ASYNC attribute, redo transport services ignores it; no error is returned.) |
| Corresponds to | NET_TIMEOUT column of the V$ARCHIVE_DEST view of the primary database |
AFFIRM 属性指定备库在将收到的重做数据写入备库重做日志之后确认该数据。
NOAFFIRM 属性指定备库在将收到的重做数据写入备库重做日志之前确认该数据。
| Category | AFFIRM | NOAFFIRM |
|---|---|---|
| Data type | Keyword | Keyword |
| Valid values | Not applicable | Not applicable |
| Default Value | Not applicable | Not applicable |
| Requires attributes | SERVICE | SERVICE |
| Conflicts with attributes | NOAFFIRM | AFFIRM |
| Corresponds to | AFFIRM column of the V$ARCHIVE_DEST view | AFFIRM column of the V$ARCHIVE_DEST view |
DB_UNIQUE_NAME 属性用于指定备库的 DB_UNIQUE_NAME。如果已定义 LOG_ARCHIVE_CONFIG 初始化参数并且其值包含 DG_CONFIG 列表，则必须指定 DB_UNIQUE_NAME 属性。
如果指定了 DB_UNIQUE_NAME 属性，则其值必须与 DG_CONFIG 列表中的 DB_UNIQUE_NAME 值之一匹配。还必须与备库的 DB_UNIQUE_NAME 参数匹配。
| Category | DB_UNIQUE_NAME=name |
|---|---|
| Data Type | String |
| Valid values | The name must match the value that was defined for this database with the DB_UNIQUE_NAME parameter. |
| Default value | None |
| Requires attributes | None |
| Conflicts with attributes | None |
| Corresponds to | DB_UNIQUE_NAME column of the V$ARCHIVE_DEST view |
VALID_FOR 属性用于指定重做日志传输服务何时将重做数据传输到备库。Oracle 建议为 Data Guard 配置中的所有数据库（包括主库和备库）指定 VALID_FOR 属性，以便重做日志传输服务在角色转换后继续向所有备库发送重做数据。
| Category | VALID_FOR=(redo_log_type, database_role) |
|---|---|
| Data Type | String value |
| Valid values | Not applicable |
| Default Value | VALID_FOR=(ALL_LOGFILES, ALL_ROLES) |
| Requires attributes | None |
| Conflicts with attributes | None |
| Corresponds to | VALID_NOW, VALID_TYPE, and VALID_ROLE columns in the V$ARCHIVE_DEST view |
| VALID_FOR Definition | Primary Role | Physical Standby Role | Logical Standby Role |
|---|---|---|---|
ONLINE_LOGFILE, PRIMARY_ROLE | Active | Inactive | Invalid |
ONLINE_LOGFILE, STANDBY_ROLE | Inactive | Invalid | Active |
ONLINE_LOGFILE, ALL_ROLES | Active | Invalid | Active |
STANDBY_LOGFILE, PRIMARY_ROLE | Error | Error | Error |
STANDBY_LOGFILE, STANDBY_ROLE | Invalid | Active | Active |
STANDBY_LOGFILE ALL_ROLES | Invalid | Active | Active |
ALL_LOGFILES, PRIMARY_ROLE | Active | Inactive | Invalid |
ALL_LOGFILES, STANDBY_ROLE | Invalid | Active | Active |
ALL_LOGFILES, ALL_ROLES | Active | Active | Active |
REOPEN 属性用于指定重做日志传输失败后重新尝试前等待的最小秒数。
| Category | REOPEN [=seconds] |
|---|---|
| Data Type | Numeric |
| Valid values | >=0 seconds |
| Default Value | 300 seconds |
| Requires attributes | None |
| Conflicts with attributes | Not applicable |
| Corresponds to | REOPEN_SECS and MAX_FAILURE columns of the V$ARCHIVE_DEST view |
COMPRESSION 属性用于指定在传输前是否压缩重做数据。压缩可以显著提高低带宽和高延迟网络链路上的传输性能。
| Category | COMPRESSION=ENABLE or DISABLE |
|---|---|
| Data Type | Boolean |
| Valid values | ENABLE or DISABLE |
| Default value | DISABLE |
| Requires attributes | None |
| Conflicts with attributes | None |
| Corresponds to | COMPRESSION column of the V$ARCHIVE_DEST view |
示例：
DB_UNIQUE_NAME=BOSTON
LOG_ARCHIVE_CONFIG='DG_CONFIG=(BOSTON,CHICAGO,HARTFORD)'
LOG_ARCHIVE_DEST_2='SERVICE=CHICAGO ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILE,
PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE DB_UNIQUE_NAME=CHICAGO'
LOG_ARCHIVE_DEST_STATE_2='ENABLE'
LOG_ARCHIVE_DEST_3='SERVICE=HARTFORD SYNC AFFIRM NET_TIMEOUT=30
VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE
DB_UNIQUE_NAME=HARTFORD'
LOG_ARCHIVE_DEST_STATE_3='ENABLE'
Configuring an Oracle Database to Receive Redo Data
Creating and Managing a Standby Redo Log
备库使用备库重做日志（Standby Redo Log）存储从其他库收到的重做日志。备库重做日志在结构上与重做日志相同，并且使用用于创建和管理重做日志的相同 SQL 语句进行创建和管理。
使用 RFS 前台进程将接收到的重做数据写入备库重做日志组。当源库上发生日志切换时，传入的重做将写入下一个备库重做日志组，之前使用过的备库重做日志组由 ARCn 前台进程进行归档。
每个备库重做日志文件的大小必须至少与源库的重做日志中最大的重做日志文件一样大。为了便于管理，Oracle 建议源库重做日志文件和备库重做日志文件大小相同。
对于源库中的每个重做线程，备库必须至少比源库多一个重做日志组。在源库中，查询 V$LOG 视图确定重做日志组数量，查询 V$THREAD 视图确定重做线程数量。
在主库查询每个日志文件的大小以及日志组数量：
SQL> SELECT GROUP#, BYTES FROM V$LOG;
在备库查询每个日志文件的大小以及日志组数量：
SQL> SELECT GROUP#, BYTES FROM V$STANDBY_LOG;
Oracle 建议在 Data Guard 配置中的主库上创建备库重做日志，以便在切换到备库角色后可立即接收重做数据。
使用 ALTER DATABASE ADD STANDBY LOGFILE SQL 语句创建备库重做日志。
例如，假定源库有两个重做日志组，每个重做日志组包含一个 500 MB 重做日志文件。在这种情况下，备库应至少有 3 个备库重做日志组。
SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog1.rdo') SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog2.rdo') SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog3.rdo') SIZE 500M;
如果源库是 Oracle RAC，查询 V$LOG 视图确定重做线程数量，并在备库添加备库重做日志组时指定相应的线程号。
例如，以下 SQL 语句可用于在数据库上创建备库重做日志，该数据库从具有两个重做线程的源库接收重做数据：
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 500M;
注意：每当主库添加重做日志组时，每个备库也必须添加对应的备库重做日志组。
Configuring Standby Redo Log Archival
（1）启用归档
如果没有启用归档，则需要将数据库修改为归档模式。
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
（2）将备库重做日志归档到快速恢复区
步骤：
- 设置 LOG_ARCHIVE_DEST_n 参数的 LOCATION 属性为 USE_DB_RECOVERY_FILE_DEST。
- 设置 LOG_ARCHIVE_DEST_n 参数的 VALID_FOR 属性允许备库重做日志归档。
LOG_ARCHIVE_DEST_2 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE)'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
Oracle 推荐使用快速恢复区来简化文件管理。
（3）将备库重做日志归档到本地文件系统
步骤：
- 设置 LOG_ARCHIVE_DEST_n 参数的 LOCATION 属性为一个有效的路径。
- 设置 LOG_ARCHIVE_DEST_n 参数的 VALID_FOR 属性允许备库重做日志归档。
LOG_ARCHIVE_DEST_2 = 'LOCATION = /disk2/archive
VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE)'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
Cascaded Redo Transport Destinations
虽然主库最多可以配置 30 个备库，但是备库越多，必然对主库的性能影响越大。为降低日志传输对主库的影响，可以使用级联备库，先将重做日志传输到一个物理备库（称之为级联备库），再将重做日志从此备库传输到其他备库（称之为被级联备库）。
注意：级联备库只有在将备库重做日志本地归档后，才会将归档的日志传输到被级联备库。因此，被级联备库与主库之间有可能存在较大的数据差异。
注意：从 12c 开始，支持 Real-time 级联备库。
Configuring a Cascaded Destination
步骤：
选择一个物理备库作为级联备库。
配置级联备库的 FAL_SERVER 参数为主库的网络连接描述符以获取主库的重做日志。
配置级联备库的 LOG_ARCHIVE_DEST_n 参数以便传输重做日志到被级联备库。
配置被级联备库的 FAL_SERVER 参数为级联备库的网络连接描述符以获取级联备库的重做日志。
例子：Some of the Initialization Parameters Used When Cascading Redo
主库：
DB_UNIQUE_NAME=boston
FAL_SERVER=boston2
LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,boston2,denver)'
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2='SERVICE=boston2 SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston2'
级联备库：
DB_UNIQUE_NAME=boston2
FAL_SERVER=boston
LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(boston,boston2,denver)'
LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston2'
LOG_ARCHIVE_DEST_2= 'SERVICE=denver
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver'
被级联备库：
DB_UNIQUE_NAME=denver
FAL_SERVER=boston2
LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,boston2,denver)'
LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=denver'
Monitoring Redo Transport Services
Monitoring Redo Transport Status
监控重做日志传输状态步骤：
- 在主库查看每个线程最近归档的日志序号
SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG
WHERE RESETLOGS_CHANGE# = (SELECT MAX(RESETLOGS_CHANGE#) FROM V$ARCHIVED_LOG)
GROUP BY THREAD#;
- 在主库查看每个传输目标上最近归档的日志文件
SELECT DESTINATION, STATUS, ARCHIVED_THREAD#, ARCHIVED_SEQ#
FROM V$ARCHIVE_DEST_STATUS
WHERE STATUS <> 'DEFERRED' AND STATUS <> 'INACTIVE';
- 在主库查看某个传输目标是否缺少日志文件
SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM
(SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) LOCAL
WHERE LOCAL.SEQUENCE# NOT IN
(SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND THREAD# = LOCAL.THREAD#);
Monitoring Synchronous Redo Transport Response Time
V$REDO_DEST_RESP_HISTOGRAM 视图包含每个传输目标的响应时间数据，用于同步模式。
响应时间小于 300 秒将四舍五入到最接近的整秒，大于 300 秒将向上舍入为 600、1200、2400、4800 或 9600 秒。
每行包含四列：FREQUENCY, DURATION, DEST_ID 和 TIME。
| Column | Datatype | Description |
|---|---|---|
DEST_ID | NUMBER | A non-negative integer value from 1 - 10 for each possible LGWR SYNC standby destination |
TIME | VARCHAR2(20) | A text string that shows the last wall-clock time that a bucket was hit |
DURATION | NUMBER | A positive integer value that represents a bucket of seconds, 1, 2, 3, up to 300 seconds, followed by 5 additional buckets that represent 600, 1200, 2400, 4800, and 9600 ( >= 4801) seconds |
FREQUENCY | NUMBER | A non-negative integer that shows the number of times a particular bucket was hit by the SYNC LNS process |
例子：在主库查看指定传输目标的响应时间直方图
SELECT FREQUENCY, DURATION FROM
V$REDO_DEST_RESP_HISTOGRAM WHERE DEST_ID=2 AND FREQUENCY>1;
例子：在主库查看指定传输目标的最大响应时间
SELECT max(DURATION) FROM V$REDO_DEST_RESP_HISTOGRAM
WHERE DEST_ID=2 AND FREQUENCY>1;
例子：在主库查看指定传输目标的最小响应时间
SELECT min( DURATION) FROM V$REDO_DEST_RESP_HISTOGRAM
WHERE DEST_ID=2 AND FREQUENCY>1;
注意：最大响应时间不能超过为该目标指定的 NET_TIMEOUT，因为如果传输目标在 NET_TIMEOUT 秒内未响应传输消息，则同步模式会话将终止。
Redo Gap Detection and Resolution
当重做日志传输中断时，会出现重做间隙（Redo Gap）。当传输恢复时，重做日志传输服务会自动检测重做间隙，并通过将缺少的重做发送到目标来解决。
解决重做间隙所需的时间取决于重做间隙的大小以及网络的带宽和延迟。重做日志传输服务有两个选项，可以在使用低性能网络链接时减少重做间隙解决时间：
压缩，LOG_ARCHIVE_DEST_n 参数的 COMPRESSION 属性用于指定在传输到目标之前压缩重做数据。
并行会话，LOG_ARCHIVE_DEST_n 参数的 MAX_CONNECTIONS 属性可用于指定使用多个网络会话来发送解决重做间隙所需的归档日志。
Manual Gap Resolution
在某些情况下，间隙无法自动解决，需要人工介入。例如，如果主数据库不可用，则必须在逻辑备库上手动解决重做间隙。
在物理备库查询是否存在重做间隙：
SQL> SELECT * FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
----------- ------------- --------------
1 7 10
输出表示物理备库当前缺少线程 1 的序列 7 到序列 10 的日志文件。
在主库查询已归档的重做日志文件（假设主库上的本地归档目标是 LOG_ARCHIVE_DEST_1）：
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND
DEST_ID=1 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
将这些日志文件复制到物理备库，并使用 ALTER DATABASE REGISTER LOGFILE 进行注册：
SQL> ALTER DATABASE REGISTER LOGFILE '/physical_standby1/thread1_dest/arcr_1_7.arc';
SQL> ALTER DATABASE REGISTER LOGFILE '/physical_standby1/thread1_dest/arcr_1_8.arc';
SQL> ALTER DATABASE REGISTER LOGFILE '/physical_standby1/thread1_dest/arcr_1_9.arc';
注意：物理备库上的 V$ARCHIVE_GAP 视图仅返回当前阻止 Redo Apply 继续的间隙。解决该间隙后，再次查询 V$ARCHIVE_GAP 视图，以确定是否存在其他间隙。
查询逻辑备库上的 DBA_LOGSTDBY_LOG 视图确定是否存在重做间隙。
以下查询如果每个线程只返回一行，则表示没有重做间隙。
SQL> COLUMN FILE_NAME FORMAT a55
SQL> SELECT THREAD#, SEQUENCE#, FILE_NAME FROM DBA_LOGSTDBY_LOG L
WHERE NEXT_CHANGE# NOT IN
(SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#)
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）复制到逻辑备库，并使用 ALTER DATABASE REGISTER LOGICAL LOGFILE 进行注册：
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE '/disk1/oracle/dbs/log-1292880008_7.arc';
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE '/disk1/oracle/dbs/log-1292880008_8.arc';
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE '/disk1/oracle/dbs/log-1292880008_9.arc';
注意：逻辑备库上的 DBA_LOGSTDBY_LOG 视图仅返回当前阻止 SQL Apply 继续的间隙。解决该间隙后，再次查询 DBA_LOGSTDBY_LOG 视图，以确定是否存在其他间隙。
Apply Services
Introduction to Apply Services
重做日志应用服务（Apply Services）自动将重做日志应用于备库，以保持与主库同步。
默认情况下，重做日志应用服务会等待备库重做日志文件被归档后再应用。也可以启用实时应用，即在写入日志到备库重做日志文件的同时进行应用。
应用服务有：
- Redo Apply 只用于物理备库，使用介质恢复。
- SQL Apply 只用于逻辑备库，从日志解析出 SQL 语句并执行。
Apply Services Configuration Options
Using Real-Time Apply to Apply Redo Data Immediately
如果启用了实时应用（real-time apply）功能，则应用服务（apply services）可以在收到重做数据时进行应用，而无需等待备库重做日志文件归档，这样可以缩短主备切换和故障转移时间。
使用 ALTER DATABASE 语句启用实时应用：
对于物理备库，使用 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE 语句。
对于逻辑备库，使用 ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE 语句。
实时应用需要备库配置备库重做日志且处于归档模式。
启用实时应用的Data Guard配置如下图：
上图中远程文件服务器 （remote file serve RFS） 进程将重做数据写入备库重做日志文件时，应用服务就从备库重做日志中进行恢复。
Specifying a Time Delay for the Application of Archived Redo Log Files
在某些情况下，需要在接收重做日志与应用重做日志之间设置一个时间间隔，用于阻止主库的逻辑错误在该时间间隔内不会应用到备库，这样就可以在备库查看到逻辑错误之前的数据。
注意：如果备库启用了实时应用，将会忽略时间延迟设置。
（1）指定时间延迟
使用 LOG_ARCHIVE_DEST_n 初始化参数的 DELAY=minutes 属性在主库和备库上设置时间延迟，以延迟将归档的重做日志文件应用到备库。默认情况下，没有时间延迟。如果指定 DELAY 属性而不指定值，则默认延迟间隔为 30 分钟。
常用的方式是直接在备库启动日志应用时指定 DELAY 关键字：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DELAY 360 DISCONNECT FROM SESSION;
SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=1;
RECOVERY_MODE
-----------------------
MANAGED
注意：使用 DELAY 关键字就不能使用 USING CURRENT LOGFILE。
（2）取消时间延迟
- 对于物理备库，使用如下语句：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
- 对于逻辑备库，使用如下语句：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;
Applying Redo Data to Physical Standby Databases
Starting Redo Apply
要在物理备库上启动日志应用服务，至少需要启动到 MOUNT 状态，然后使用 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 语句。
启动 Redo Apply 为前台进程：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
启动 Redo Apply 为后台进程：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
启动 Redo Apply 为后台进程，并启用实时应用（最常用）：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
Stopping Redo Apply
停止 Redo Apply：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Applying Redo Data to Logical Standby Databases
Starting SQL Apply
启动 SQL Apply：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
启动实时 SQL Apply：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Stopping SQL Apply on a Logical Standby Database
停止 SQL Apply：
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
此语句需要等待正在处理的 SQL Apply 事务完成后才会返回。
Creating a Physical Standby Database
Planing
（1）主机规划
| 序号 | 操作系统 | 主机名 | IP | OS 版本 | DB 版本 | 用途 |
|---|---|---|---|---|---|---|
| 1 | RHEL | stone | 192.168.247.135 | 6.7-x86_64 | 11.2.0.4 | primary |
| 2 | RHEL | stonedg1 | 192.168.247.136 | 6.7-x86_64 | 11.2.0.4 | standby |
（2）名称规划
| 序号 | 节点 | DB Name | Instance Name | DB Unique Name |
|---|---|---|---|---|
| 1 | primary | stone | stone | stone |
| 2 | standby | stone | stonedg1 | stonedg1 |
Preparation
（2）主库：启动监听。
[oracle@stone ~]$ lsnrctl start
（3）主库：确认是否处于归档模式，如果不是归档模式，需要在 MOUNT 下使用 ALTER DATABASE ARCHIVELOG 调整为归档模式。
SQL> ARCHIVE LOG LIST;
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 173
Current log sequence 175
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;
SQL> ARCHIVE LOG LIST;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 173
Next log sequence to archive 175
Current log sequence 175
（4）主库：确认是否启用 FORCE LOGGING，如果没有，则使用 ALTER DATABASE FORCE LOGGING 语句启用，需要在 MOUNT 或者 OPEN 下执行。
SQL> SELECT NAME,OPEN_MODE,LOG_MODE,FORCE_LOGGING FROM V$DATABASE;
NAME OPEN_MODE LOG_MODE FOR
--------- -------------------- ------------ ---
STONE READ WRITE ARCHIVELOG NO
SQL> ALTER DATABASE FORCE LOGGING;
Database altered.
SQL> SELECT NAME,OPEN_MODE,LOG_MODE,FORCE_LOGGING FROM V$DATABASE;
NAME OPEN_MODE LOG_MODE FOR
--------- -------------------- ------------ ---
STONE READ WRITE ARCHIVELOG YES
（5）备库：安装数据库。
（6）备库：创建监听并启动。
[oracle@stonedg1 ~]$ vim /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = stonedg1)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1)
(SID_NAME = stonedg1)
)
)
LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.247.136)(PORT = 1521))
)
ADR_BASE_LISTENER = /u01/app/oracle
[oracle@stonedg1 ~]$ lsnrctl start
（7）备库：配置到主库的网络连接描述符并测试。
[oracle@stonedg1 ~]$ vim /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/tnsnames.ora
STONE =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.247.135)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = stone)
)
)
[oracle@stonedg1 ~]$ tnsping STONE
（8）主库：配置到备库的网络连接描述符并测试
[oracle@stone ~]$ vim /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/tnsnames.ora
STONEDG1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.247.136)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = stonedg1)
)
)
[oracle@stone ~]$ tnsping STONEDG1
（9）主库：调整参数并生成文本参数文件。
SQL> alter system set LOG_ARCHIVE_CONFIG='DG_CONFIG=(stone,stonedg1)';
SQL> alter system set LOG_ARCHIVE_DEST_2='SERVICE=STONEDG1 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stonedg1';
SQL> alter system set LOG_ARCHIVE_DEST_STATE_2=ENABLE;
SQL> create pfile='/home/oracle/pfile.ora' from spfile;
（10）备库：拷贝主库生成的文本参数文件并修改。
[oracle@stonedg1 ~]$ vim pfile.ora
*.audit_file_dest='/u01/app/oracle/admin/stonedg1/adump'
*.audit_trail='NONE'
*.compatible='11.2.0.4.0'
*.control_files='/u01/app/oracle/oradata/STONEDG1/controlfile/control1.ctl','/u01/app/oracle/fast_recovery_area/STONEDG1/controlfile/control2.ctl'
*.db_block_size=8192
*.db_create_file_dest='/u01/app/oracle/oradata'
*.db_create_online_log_dest_1='/u01/app/oracle/oradata'
*.db_domain=''
*.db_files=1000
*.db_name='stone'
*.db_unique_name='stonedg1'
*.db_recovery_file_dest='/u01/app/oracle/fast_recovery_area'
*.db_recovery_file_dest_size=100G
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=stonedg1XDB)'
*.log_archive_config='DG_CONFIG=(stone,stonedg1)'
*.log_archive_dest_1='location=/u01/app/oracle/oradata/STONEDG1/archivelog/'
*.log_archive_format='%t_%s_%r.dbf'
*.memory_target=820M
*.open_cursors=300
*.processes=150
*.remote_login_passwordfile='exclusive'
*.undo_tablespace='UNDOTBS1‘
*.undo_retention=3600
*.standby_file_management='auto'
*.fal_server='STONE'
（11）备库：创建备库 SPFILE。
SQL> create spfile from pfile='/home/oracle/pfile.ora';
（12）备库：创建对应目录。
[oracle@stonedg1 ~]$ mkdir -p /u01/app/oracle/admin/stonedg1/{adump,bdump,cdump,udump}
[oracle@stonedg1 ~]$ mkdir -p /u01/app/oracle/oradata/STONEDG1/{controlfile,datafile,onlinelog,archivelog}
[oracle@stonedg1 ~]$ mkdir -p /u01/app/oracle/fast_recovery_area/STONEDG1/{controlfile,onlinelog,archivelog}
（13）备库：拷贝主库的密码文件。
[oracle@stonedg1 ~]$ scp oracle@192.168.247.135:/u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwstone /u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwstonedg1
Creation
（1）备库：启动到 NOMOUNT。
SQL> startup nomount
（2）主库：使用 RMAN 创建备库。
[oracle@stone ~]$ rman target / auxiliary sys/123456@stonedg1
RMAN> duplicate target database for standby from active database;
（3）备库：创建完成后查看状态。
SQL> SELECT DATABASE_ROLE,OPEN_MODE FROM V$DATABASE;
DATABASE_ROLE OPEN_MODE
-------------------- ----------
PHYSICAL STANDBY MOUNTED
SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=1;
RECOVERY_MODE
-----------------------
IDLE
（4）备库：创建 Standby Redo Log，如果主库是三组，则备库应该创建四组。
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 11 SIZE 2G;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 12 SIZE 2G;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 13 SIZE 2G;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 14 SIZE 2G;
SQL> SELECT GROUP#,THREAD#,SEQUENCE#,BYTES/1024/1024 MB FROM V$STANDBY_LOG;
GROUP# THREAD# SEQUENCE# MB
---------- ---------- ---------- ----------
11 1 0 2048
12 1 0 2048
13 1 0 2048
14 1 0 2048
（5）备库：启用 Real-Time Apply 并查看 Standby Redo Log 状态。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=1;
RECOVERY_MODE
-----------------------
MANAGED REAL TIME APPLY
SQL> SELECT GROUP#, SEQUENCE#, DBID,STATUS FROM V$STANDBY_LOG;
GROUP# SEQUENCE# DBID STATUS
---------- ---------- ---------------------------------------- ----------
11 0 UNASSIGNED UNASSIGNED
12 0 UNASSIGNED UNASSIGNED
13 0 UNASSIGNED UNASSIGNED
14 0 UNASSIGNED UNASSIGNED
（6）主库：切换日志。
SQL> ALTER SYSTEM SWITCH LOGFILE;
（7）备库：再次查看 Standby Redo Log 状态。
SQL> SELECT GROUP#, SEQUENCE#, DBID,STATUS FROM V$STANDBY_LOG;
GROUP# SEQUENCE# DBID STATUS
---------- ---------- ---------------------------------------- ----------
11 0 UNASSIGNED UNASSIGNED
12 5 1183427473 ACTIVE
13 0 UNASSIGNED UNASSIGNED
14 0 UNASSIGNED UNASSIGNED
（8）备库：启用 Real-time query。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE OPEN;
SQL> SELECT OPEN_MODE FROM V$DATABASE;
OPEN_MODE
--------------------
READ ONLY
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
SQL> SELECT OPEN_MODE FROM V$DATABASE;
OPEN_MODE
--------------------
READ ONLY WITH APPLY
（9）主库：查看状态。
SQL> SELECT INST_ID,DEST_ID,DEST_NAME,STATUS,TYPE,DATABASE_MODE,RECOVERY_MODE,PROTECTION_MODE,DESTINATION,ERROR,GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2;
（10）备库：查看状态。
SQL> SELECT INST_ID,DEST_ID,DEST_NAME,STATUS,TYPE,DATABASE_MODE,RECOVERY_MODE,PROTECTION_MODE,ERROR,GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=1;
SQL> SELECT PROCESS,PID,STATUS,GROUP#,THREAD#,SEQUENCE#,BLOCK# FROM V$MANAGED_STANDBY;
SQL> SELECT NAME,VALUE,DATUM_TIME, TIME_COMPUTED FROM V$DATAGUARD_STATS;
SQL> SELECT * FROM V$STANDBY_EVENT_HISTOGRAM;
Verification
（1）备库：查询 V$ARCHIVED_LOG 视图查看已归档日志文件。
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
SEQUENCE# FIRST_TIME NEXT_TIME
---------- ------------------ ------------------
8 11-JUL-07 17:50:45 11-JUL-07 17:50:53
9 11-JUL-07 17:50:53 11-JUL-07 17:50:58
10 11-JUL-07 17:50:58 11-JUL-07 17:51:03
3 rows selected.
（2）主库：切换日志并归档联机重做日志文件。
SQL> ALTER SYSTEM SWITCH LOGFILE;
（3）备库：再次查询 V$ARCHIVED_LOG 视图查看已归档日志文件是否增加。
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
SEQUENCE# FIRST_TIME NEXT_TIME
---------- ------------------ ------------------
8 11-JUL-07 17:50:45 11-JUL-07 17:50:53
9 11-JUL-07 17:50:53 11-JUL-07 17:50:58
10 11-JUL-07 17:50:58 11-JUL-07 17:51:03
11 11-JUL-07 17:51:03 11-JUL-07 18:34:11
4 rows selected.
（4）备库：查看重做日志是否已经被应用。
SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
SEQUENCE# APP
--------- ---
8 YES
9 YES
10 YES
11 IN-MEMORY
APPLIED 字段为 YES 或 IN-MEMORY 表示重做日志已经被应用。
Creating a Cascaded Physical Standby Database
可以使用前面创建的物理备库作为级联备库来创建被级联备库。
Planing
（1）主机规划
| 序号 | 操作系统 | 主机名 | IP | OS 版本 | DB 版本 | 用途 |
|---|---|---|---|---|---|---|
| 1 | RHEL | stone | 192.168.247.135 | 6.7-x86_64 | 11.2.0.4 | primary |
| 2 | RHEL | stonedg1 | 192.168.247.136 | 6.7-x86_64 | 11.2.0.4 | standby |
| 3 | RHEL | stonedg2 | 192.168.247.137 | 6.7-x86_64 | 11.2.0.4 | cascaded standby |
（2）名称规划
| 序号 | 节点 | DB Name | Instance Name | DB Unique Name |
|---|---|---|---|---|
| 1 | primary | stone | stone | stone |
| 2 | standby | stone | stonedg1 | stonedg1 |
| 3 | cascaded standby | stone | stonedg2 | stonedg2 |
Preparing
（1）Cascaded Standby：安装数据库。
（2）Cascaded Standby：创建监听并启动。
[oracle@stonedg2 ~]$ vim /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = stonedg2)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1)
(SID_NAME = stonedg2)
)
)
LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.247.137)(PORT = 1521))
)
ADR_BASE_LISTENER = /u01/app/oracle
[oracle@stonedg2 ~]$ lsnrctl start
（3）Cascaded Standby：配置到备库的网络连接描述符并测试。
[oracle@stonedg2 ~]$ vim /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/tnsnames.ora
STONEDG1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.247.136)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = stonedg1)
)
)
[oracle@stonedg2 ~]$ tnsping STONEDG1
（4）备库：配置到 Cascaded Standby 的网络连接描述符并测试。
[oracle@stonedg1 ~]$ vim /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/tnsnames.ora
STONE =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.247.135)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = stone)
)
)
STONEDG2 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.247.137)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = stonedg2)
)
)
[oracle@stonedg1 ~]$ tnsping STONEDG2
（5）备库：创建备份。
[oracle@stonedg1 ~]$ mkdir /home/oracle/backup
[oracle@stonedg1 ~]$ rman target /
RMAN> RUN {
allocate channel d1 type disk;
allocate channel d2 type disk;
BACKUP
SKIP INACCESSIBLE
FILESPERSET 5
FORMAT '/home/oracle/backup/bk_%s_%p_%t'
DATABASE;
BACKUP
filesperset 20
FORMAT '/home/oracle/backup/al_%s_%p_%t'
ARCHIVELOG ALL;
BACKUP
spfile
FORMAT '/home/oracle/backup/spfile_cntrl_%s_%p_%t'
include CURRENT CONTROLFILE;
release channel d1;
release channel d2;
}
注意：以上备份是在备库上创建的，如果要使用主库创建的备份，则需要单独创建备库控制文件。
RMAN> COPY CURRENT CONTROLFILE FOR STANDBY TO '/home/oracle/backup/stonedg2.ctl';
（6）Cascaded Standby：拷贝备库的文本参数文件并修改。
[oracle@stonedg2 ~]$ vim pfile.ora
*.audit_file_dest='/u01/app/oracle/admin/stonedg2/adump'
*.audit_trail='NONE'
*.compatible='11.2.0.4.0'
*.control_files='/u01/app/oracle/oradata/STONEDG2/controlfile/stonedg2.ctl','/u01/app/oracle/fast_recovery_area/STONEDG2/controlfile/stonedg2.ctl'
*.db_block_size=8192
*.db_create_file_dest='/u01/app/oracle/oradata'
*.db_create_online_log_dest_1='/u01/app/oracle/oradata'
*.db_domain=''
*.db_files=1000
*.db_name='stone'
*.db_unique_name='stonedg2'
*.db_recovery_file_dest='/u01/app/oracle/fast_recovery_area'
*.db_recovery_file_dest_size=100G
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=stonedg2XDB)'
*.log_archive_config='DG_CONFIG=(stone,stonedg2)'
*.log_archive_dest_1='location=/u01/app/oracle/oradata/STONEDG2/archivelog/'
*.log_archive_format='%t_%s_%r.dbf'
*.memory_target=820M
*.open_cursors=300
*.processes=150
*.remote_login_passwordfile='exclusive'
*.undo_tablespace='UNDOTBS1‘
*.undo_retention=3600
*.standby_file_management='auto'
*.fal_server='STONEDG1'
（7）Cascaded Standby：创建 SPFILE。
SQL> create spfile from pfile='/home/oracle/pfile.ora';
（8）Cascaded Standby：创建对应目录。
[oracle@stonedg2 ~]$ mkdir -p /u01/app/oracle/admin/stonedg2/{adump,bdump,cdump,udump}
[oracle@stonedg2 ~]$ mkdir -p /u01/app/oracle/oradata/STONEDG2/{controlfile,datafile,onlinelog,archivelog}
[oracle@stonedg2 ~]$ mkdir -p /u01/app/oracle/fast_recovery_area/STONEDG2/{controlfile,onlinelog,archivelog}
[oracle@stonedg2 ~]$ mkdir /home/oracle/backup
（9）Cascaded Standby：拷贝主库的密码文件。
[oracle@stonedg2 ~]$ scp oracle@192.168.247.135:/u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwstone /u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwstonedg2
（10）Cascaded Standby：拷贝备库的备份文件。
[oracle@stonedg2 ~]$ rsync -P --rsh=ssh oracle@192.168.247.136:/home/oracle/backup/* /home/oracle/backup/
Creating
（1）Cascaded Standby：启动到 NOMOUNT。
SQL> startup nomount
（2）Cascaded Standby：使用 RMAN 恢复控制文件并还原数据库。
[oracle@stonedg2 ~]$ rman target /
RMAN> restore controlfile from '/home/oracle/backup/spfile_cntrl_36_1_990283881';
RMAN> alter database mount;
RMAN> restore database;
注意：
如果使用主库创建的备库控制文件，需要将其拷贝到备库参数文件指定的控制文件位置，再 MOUNT。
[oracle@stonedg2 ~]$ cp /home/oracle/backup/stonedg2.ctl /u01/app/oracle/oradata/STONEDG2/controlfile/stonedg2.ctl [oracle@stonedg2 ~]$ cp /home/oracle/backup/stonedg2.ctl /u01/app/oracle/fast_recovery_area/STONEDG2/controlfile/stonedg2.ctl如果备库存放备份文件的目录与主库不一致，则需要手动将备份注册到控制文件，然后再进行 RESTORE。
RMAN> catalog start with '/home/oracle/backup/';
（3）主库：调整参数。
SQL> alter system set LOG_ARCHIVE_CONFIG='DG_CONFIG=(stone,stonedg1,stonedg2)';
（4）备库：调整参数。
SQL> alter system set LOG_ARCHIVE_CONFIG='DG_CONFIG=(stone,stonedg1,stonedg2)';
SQL> alter system set log_archive_dest_3='SERVICE=STONEDG2 VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=stonedg2';
SQL> alter system set LOG_ARCHIVE_DEST_STATE_3=ENABLE;
（5）Cascaded Standby：调整参数。
SQL> alter system set LOG_ARCHIVE_CONFIG='DG_CONFIG=(stone,stonedg1,stonedg2)';
（6）Cascaded Standby：清理 Standby Redo Logs。
SQL> SELECT GROUP#,STATUS,MEMBER FROM V$LOGFILE ORDER BY 1;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 2;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 3;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 11;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 12;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 13;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 14;
SQL> SELECT GROUP#,STATUS,MEMBER FROM V$LOGFILE ORDER BY 1;
（7）Cascaded Standby：启用 Real-time query。
SQL> ALTER DATABASE OPEN;
SQL> SELECT OPEN_MODE FROM V$DATABASE;
OPEN_MODE
--------------------
READ ONLY
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
SQL> SELECT OPEN_MODE FROM V$DATABASE;
OPEN_MODE
--------------------
READ ONLY WITH APPLY
（8）备库：查看状态。
SQL> SELECT INST_ID,DEST_ID,DEST_NAME,STATUS,TYPE,DATABASE_MODE,RECOVERY_MODE,PROTECTION_MODE,DESTINATION,ERROR,GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=3;
（9）Cascaded Standby：查看状态。
SQL> SELECT INST_ID,DEST_ID,DEST_NAME,STATUS,TYPE,DATABASE_MODE,RECOVERY_MODE,PROTECTION_MODE,ERROR,GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=1;
SQL> SELECT PROCESS,PID,STATUS,GROUP#,THREAD#,SEQUENCE#,BLOCK# FROM V$MANAGED_STANDBY;
SQL> SELECT NAME,VALUE,DATUM_TIME, TIME_COMPUTED FROM V$DATAGUARD_STATS;
SQL> SELECT * FROM V$STANDBY_EVENT_HISTOGRAM;
Managing a Snapshot Standby Database
Converting a Physical Standby Database into a Snapshot Standby Database
物理备库转换为快照备库的步骤如下：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;
SQL> ALTER DATABASE OPEN;
Converting a Snapshot Standby Database into a Physical Standby Database
快照备库转换为物理备库的步骤如下：
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
Managing Physical Standby Databases
Monitoring Apply Lag in a Real-time Query Environment
如果启用了 Real-time Query，可以使用 V$DATAGUARD_STATS 视图查询主库和备库之间的应用延迟（apply lag）时间。
SQL> SELECT name, value, datum_time, time_computed FROM V$DATAGUARD_STATS WHERE name like 'apply lag';
NAME VALUE DATUM_TIME TIME_COMPUTED
--------- ------------- ------------------- -------------------
apply lag +00 00:00:00 05/27/2009 08:54:16 05/27/2009 08:54:17
使用 V$STANDBY_EVENT_HISTOGRAM 视图应用延迟的历史数据。
SQL> SELECT * FROM V$STANDBY_EVENT_HISTOGRAM WHERE NAME = 'apply lag' AND COUNT > 0;
NAME TIME UNIT COUNT LAST_TIME_UPDATED
--------- --------- -------- ----------- ------------------------
apply lag 0 seconds 79681 06/18/2009 10:05:00
apply lag 1 seconds 1006 06/18/2009 10:03:56
apply lag 2 seconds 96 06/18/2009 09:51:06
apply lag 3 seconds 4 06/18/2009 04:12:32
apply lag 4 seconds 1 06/17/2009 11:43:51
apply lag 5 seconds 1 06/17/2009 11:43:52
6 rows selected
Adding Temp Files to a Physical Standby Database
如果使用物理备库作为报表分析或者执行大量的排序操作，有可能需要更多的临时表空间。可以手动为物理备库添加临时表空间。
SQL> SELECT TABLESPACE_NAME FROM DBA_TABLESPACES WHERE CONTENTS = 'TEMPORARY';
TABLESPACE_NAME
--------------------------------
TEMP1
TEMP2
SQL> ALTER TABLESPACE TEMP1 ADD TEMPFILE '/u01/app/oracle/oradata/STONEDG1/datfile/temp03.dbf' SIZE 1G AUTOEXTEND ON NEXT 100M MAXSIZE 20G;
Renaming a Datafile in the Primary Database
如果主库数据文件所在的磁盘分区空间不足，有可能需要将某些数据文件移动到其他磁盘分区，此时就需要修改数据文件的路径，这种操作是不会被自动同步到备库的，故也需要在备库手动执行相同的操作。
步骤如下：
（1）主库：OFFLINE 表空间。
SQL> ALTER TABLESPACE tbs_4 OFFLINE;
（2）主库：调整数据文件位置。
% mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk2/oracle/oradata/payroll/tbs_4.dbf
（3）主库：RENAME 数据文件并 ONLINE 表空间。
SQL> ALTER TABLESPACE tbs_4 RENAME DATAFILE '/disk1/oracle/oradata/payroll/tbs_4.dbf' TO '/disk2/oracle/oradata/payroll/tbs_4.dbf';
SQL> ALTER TABLESPACE tbs_4 ONLINE;
（4）备库：停止 Redo Apply 并关闭数据库。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> SHUTDOWN;
（5）备库：调整数据文件位置。
% mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk2/oracle/oradata/payroll/tbs_4.dbf
（6）备库：启动到 MOUNT，调整 STANDBY_FILE_MANAGEMENT 参数并 RENAME 数据文件。
SQL> STARTUP MOUNT;
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;
SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/tbs_4.dbf' TO '/disk2/oracle/oradata/payroll/tbs_4.dbf';
（7）备库：调整 STANDBY_FILE_MANAGEMENT 参数并重新启动 Redo Apply。
SQL> ALTER DATABASE OPEN;
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
如果是备库的磁盘空间不足，也可以单独调整备库的数据文件位置，此时只需要执行（4）~ （7）步骤即可。
Add or Drop a Redo Log File Group
在创建数据库的时候，联机重做日志文件默认大小为 50M，在实际工作中，建议设置为 2G，如果在创建数据库的时候忘记修改了，可以在创建数据库完成后进行调整。
步骤如下：
（1）主库：增加联机重做日志文件，大小为 2G。
SQL> SELECT L.GROUP#,L.THREAD#,L.BYTES/1024/1024/1024 GB,L.ARCHIVED,L.STATUS,F.MEMBER FROM V$LOG L JOIN V$LOGFILE F ON L.GROUP#=F.GROUP# ORDER BY 1;
SQL> ALTER DATABASE ADD LOGFILE GROUP 4 SIZE 2G;
SQL> ALTER DATABASE ADD LOGFILE GROUP 5 SIZE 2G;
SQL> ALTER DATABASE ADD LOGFILE GROUP 6 SIZE 2G;
SQL> SELECT L.GROUP#,L.THREAD#,L.BYTES/1024/1024/1024 GB,L.ARCHIVED,L.STATUS,F.MEMBER FROM V$LOG L JOIN V$LOGFILE F ON L.GROUP#=F.GROUP# ORDER BY 1;
（2）主库：切换到增加的日志组，使以前的日志组处于 INACTIVE 状态。
SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> ALTER SYSTEM CHECKPOINT;
（3）主库：删除默认的重做日志文件。
SQL> SELECT L.GROUP#,L.THREAD#,L.BYTES/1024/1024/1024 GB,L.ARCHIVED,L.STATUS,F.MEMBER FROM V$LOG L JOIN V$LOGFILE F ON L.GROUP#=F.GROUP# ORDER BY 1;
SQL> ALTER DATABASE DROP LOGFILE GROUP 1;
SQL> ALTER DATABASE DROP LOGFILE GROUP 2;
SQL> ALTER DATABASE DROP LOGFILE GROUP 3;
SQL> SELECT L.GROUP#,L.THREAD#,L.BYTES/1024/1024/1024 GB,L.ARCHIVED,L.STATUS,F.MEMBER FROM V$LOG L JOIN V$LOGFILE F ON L.GROUP#=F.GROUP# ORDER BY 1;
如果在创建备库后，主库才调整联机重做日志文件大小，则备库也需要进行同步调整。
步骤如下：
（1）备库：停止 Redo Apply 并调整 STANDBY_FILE_MANAGEMENT 参数。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;
（2）备库：将所有的 Standby Redo Logs 删除，然后再重建。
SQL> SELECT GROUP#,THREAD#,BYTES/1024/1024/1024 FROM V$STANDBY_LOG;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 11;
SQL> ALTER DATABASE DROP LOGFILE GROUP 11;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 12;
SQL> ALTER DATABASE DROP LOGFILE GROUP 12;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 13;
SQL> ALTER DATABASE DROP LOGFILE GROUP 13;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 14;
SQL> ALTER DATABASE DROP LOGFILE GROUP 14;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 11 SIZE 2G;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 12 SIZE 2G;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 13 SIZE 2G;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 14 SIZE 2G;
SQL> SELECT GROUP#,THREAD#,BYTES/1024/1024/1024 FROM V$STANDBY_LOG;
（3）备库：调整 STANDBY_FILE_MANAGEMENT 参数并重新启动 Redo Apply。
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
Monitoring Primary, Physical Standby, and Snapshot Standby Databases
主库和备库相关信息位置：
| Primary Database Action | Primary Site Information | Standby Site Information |
|---|---|---|
| Enable or disable a redo thread | Alert logV$THREAD | Alert log |
| Display database role, protection mode, protection level, switchover status, fast-start failover information, and so forth | V$DATABASE | V$DATABASE |
| Add or drop a redo log file group | Alert logV$LOGSTATUS column of V$LOGFILE | Alert log |
CREATE CONTROLFILE | Alert log | Alert log |
| Monitor Redo Apply | Alert logV$ARCHIVE_DEST_STATUS | Alert logV$ARCHIVED_LOGV$LOG_HISTORYV$MANAGED_STANDBY |
| Change tablespace status | V$RECOVER_FILEDBA_TABLESPACESAlert log | V$RECOVER_FILEDBA_TABLESPACES |
| Add or drop a datafile or tablespace | DBA_DATA_FILESAlert log | V$DATAFILEAlert log |
| Rename a datafile | V$DATAFILEAlert log | V$DATAFILEAlert log |
| Unlogged or unrecoverable operations | V$DATAFILEV$DATABASE | Alert log |
| Monitor redo transport | V$ARCHIVE_DEST_STATUSV$ARCHIVED_LOGV$ARCHIVE_DESTAlert log | V$ARCHIVED_LOGAlert log |
Issue OPEN RESETLOGS or CLEAR UNARCHIVED LOGFILES statements | Alert log | Alert log |
| Change initialization parameter | Alert log | Alert log |
Using Views to Monitor Primary, Physical, and Snapshot Standby Databases
（1）V$DATABASE
在主库和备库上查看数据库的保护模式，保护级别，角色以及切换状态。
SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL,DATABASE_ROLE ROLE, SWITCHOVER_STATUS
FROM V$DATABASE;
查看 fast-start failover（FSFO）状态。
SQL> SELECT FS_FAILOVER_STATUS "FSFO STATUS",FS_FAILOVER_CURRENT_TARGET TARGET,
FS_FAILOVER_THRESHOLD THRESHOLD,FS_FAILOVER_OBSERVER_PRESENT "OBSERVER PRESENT"
FROM V$DATABASE;
（2）V$MANAGED_STANDBY
在备库查看 Redo Apply 和日志传输状态。
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;
PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
------- ------------ ---------- ---------- ---------- ----------
RFS ATTACHED 1 947 72 72
MRP0 APPLYING_LOG 1 946 10 72
（3）V$ARCHIVED_LOG
在备库查看归档的日志文件。
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# FROM V$ARCHIVED_LOG;
THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1 945 74651 74739
1 946 74739 74772
1 947 74772 74795
（4）V$LOG_HISTORY
查看归档日志历史信息。
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# FROM V$LOG_HISTORY;
（5）V$DATAGUARD_STATUS
查看 Data Guard 事件信息。
SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;
（6）V$ARCHIVE_DEST
查看日志传输目标的状态。
SQL> SELECT DEST_ID, APPLIED_SCN FROM V$ARCHIVE_DEST WHERE TARGET='STANDBY';
DEST_ID STATUS APPLIED_SCN
---------- --------- -----------
2 VALID 439054
3 VALID 439054
Creating a Logical Standby Database
Planing
（1）主机规划
| 序号 | 操作系统 | 主机名 | IP | OS 版本 | DB 版本 | 用途 |
|---|---|---|---|---|---|---|
| 1 | RHEL | stone | 192.168.247.135 | 6.7-x86_64 | 11.2.0.4 | primary |
| 2 | RHEL | stonedg3 | 192.168.247.138 | 6.7-x86_64 | 11.2.0.4 | logical standby |
（2）名称规划
| 序号 | 节点 | DB Name | Instance Name | DB Unique Name |
|---|---|---|---|---|
| 1 | primary | stone | stone | stone |
| 2 | logical standby | stonedg3 | stonedg3 | stonedg3 |
Preparing
（1）主库：查看会被 SQL Apply 忽略的表
在创建逻辑备库前，需要明确主库上被 SQL Apply 忽略的表。
如果用户表创建在 Oracle 数据库内部模式（例如：SYSTEM），则该表会被 SQL Apply 忽略。
执行以下语句查询 Oracle 所有的内部模式：
SQL> SELECT OWNER FROM DBA_LOGSTDBY_SKIP WHERE STATEMENT_OPT = 'INTERNAL SCHEMA';
执行以下语句查询不属于 Oracle 内部模式，因为有不支持的数据类型，会被 SQL Apply 忽略的表：
SQL> SELECT DISTINCT OWNER,TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED ORDER BY OWNER,TABLE_NAME;
如果表包含以下任一数据类型的字段，则该表会被 SQL Apply 自动忽略：
- BFILE
- Collections (including VARRAYS and nested tables)
- Multimedia data types (including Spatial, Image, and Oracle Text)
- ROWID, UROWID
- User-defined types
如果表只有以下数据类型，则该表也会被 SQL Apply 自动忽略：
- LOB (CLOB, NCLOB, BLOB)
- LONG
- LONG RAW
- OBJECT TYPE
- COLLECTIONS
- XML
以下 SQL 语句也会被 SQL Apply 自动忽略：
- ALTER DATABASE
- ALTER MATERIALIZED VIEW
- ALTER MATERIALIZED VIEW LOG
- ALTER SESSION
- ALTER SYSTEM
- CREATE CONTROL FILE
- CREATE DATABASE
- CREATE DATABASE LINK
- CREATE PFILE FROM SPFILE
- CREATE MATERIALIZED VIEW
- CREATE MATERIALIZED VIEW LOG
- CREATE SCHEMA AUTHORIZATION
- CREATE SPFILE FROM PFILE
- DROP DATABASE LINK
- DROP MATERIALIZED VIEW
- DROP MATERIALIZED VIEW LOG
- EXPLAIN
- LOCK TABLE
- SET CONSTRAINTS
- SET ROLE
- SET TRANSACTION
（2）主库：查看没有唯一逻辑标识符的表并添加 RELY 约束
Oracle 使用主键或唯一键补充日志来标识逻辑备库中修改的行。因此最好为主库中的表创建主键或唯一键，以便 SQL Apply 可以高效应用日志。否则会导致在 SQL Apply 执行 UPDATE 或 DELETE 语句时进行全表扫描。
如果不能为表创建主键或唯一键，则执行以下步骤以确保 SQL Apply 可以唯一标识表行。
步骤 1：查询没有唯一逻辑标识符的表
SQL> SELECT OWNER, TABLE_NAME 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_COLUMN = 'Y';
步骤 2：创建禁用的主键 RELY 约束
如果应用可以确保表行唯一，则可以在表上创建禁用的主键 RELY 约束，以避免主库上维护主键的开销。
SQL> ALTER TABLE mytab ADD PRIMARY KEY (id, name) RELY DISABLE;
（3）Logical Standby：根据规划创建物理备库。
（4）Logical Standby：停止 Redo Apply。（如果 Physical Standby 是 RAC，则需要停止其他实例而只保留一个实例来执行下面语句）
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
（5）主库：创建 LogMiner 字典。
SQL> EXECUTE DBMS_LOGSTDBY.BUILD;
Creating
（1）Logical Standby：将物理备库转换为逻辑备库。
如果 Physical Standby 是单实例，执行如下语句：
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY stonedg3;
SQL> SHOW PARAMETER NAME
如果 Physical Standby 是 RAC，则需要停止其他实例而只保留一个实例来执行下面语句：
SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=SPFILE;
SQL> SHUTDOWN ABORT;
SQL> STARTUP MOUNT EXCLUSIVE;
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY stonedg3;
SQL> SHOW PARAMETER NAME
SQL> ALTER SYSTEM SET CLUSTER_DATABASE=TRUE SCOPE=SPFILE;
注意：如果使用逻辑备库进行滚动升级，则需要执行以下语句来保持 DB_NAME 和 DBID 与主库一致：
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY;
注意：如果由于主库 LogMiner 字典信息创建有问题导致转换语句卡住，则可以在其他会话执行以下语句取消转换：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
（2）Logical Standby：调整参数。
关闭逻辑备库然后启动到 MOUNT 状态（确保配置了 DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE 参数，如果没有配置，则需要分别为联机重做日志和备库重做日志指定归档位置 ）。
SQL> SHUTDOWN;
SQL> STARTUP MOUNT;
SQL> SHOW PARAMETER NAME
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST DB_UNIQUE_NAME=stonedg3';
（3）Logical Standby：打开数据库。（如果 Physical Standby 是 RAC， 打开后就可以启动其他实例了）
SQL> ALTER DATABASE OPEN RESETLOGS;
开始应用重做数据：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
注意：此时就不能再使用主库的备份还原逻辑备库了，需要为逻辑备库创建备份。
Managing a Logical Standby Database
Overview of the SQL Apply Architecture
SQL Apply 的信息流以及进程角色：
日志挖掘（Log Mining）阶段：
- READER 进程从归档重做日志文件和备库重做日志文件读取日志。
- PREPARER 进程将重做记录中的块改变转换为逻辑更改记录（LCR）。LCRs 暂存在 SGA 中，称为 LCR Cache。
- BUILDER 进程将 LCRs 分组到事务中。
日志应用（Apply Rpocessing）阶段：
- ANALYZER 进程识别不同事务之间的依赖关系。
- COORDINATOR 进程（LSP）将事务分配给不同的应用者，并在它们之间进行协调，以确保遵守事务之间的依赖关系。
- APPLIER 进程在 COORDINATOR 进程的监督下将事务应用于逻辑备库。
Controlling User Access to Tables in a Logical Standby Database
使用SQL语句 ALTER DATABASE GUARD 控制用户对逻辑库中表的访问。
有以下选项：
- ALL：默认选项，除 SYS 用户外，其他所有用户都不能对逻辑备库中的任何数据进行更改。
- STANDBY：除 SYS 用户外，其他所有用户都不能对逻辑备库中通过 SQL Apply 维护的表和序列进行 DDL 和 DML 操作。如果逻辑备库用于报表分析且创建了额外的业务表，则建议配置为此选项。
- NONE：允许对逻辑备库对数据进行更改。
例子：允许用户修改不被 SQL Apply 维护的表
SQL> ALTER DATABASE GUARD STANDBY;
注意：用户可以分别使用 ALTER SESSION DISABLE GUARD 和 ALTER SESSION ENABLE GUARD 语句暂时关闭和打开当前会话的数据库防护。
Views Related to Managing and Monitoring a Logical Standby Database
（1）DBA_LOGSTDBY_EVENTS
记录在 SQL Apply 操作期间发生的相关事件。默认记录最近的 10000 个事件，可以通过调用 DBMS_LOGSTDBY.APPLY_SET() 来进行更改。如果 SQL Apply 意外停止，则问题的原因也会记录在此视图中。
注意：导致 SQL Apply 停止的错误信息也会被记录到 ALERT.LOG 文件中，包含 LOGSTDBY 关键字。
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS';
SQL> COLUMN STATUS FORMAT A60
SQL> SELECT EVENT_TIME, STATUS, EVENT FROM DBA_LOGSTDBY_EVENTS ORDER BY EVENT_TIMESTAMP, COMMIT_SCN, CURRENT_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.
（2）DBA_LOGSTDBY_LOG
提供有关 SQL Apply 正在处理的归档日志的动态信息。
SQL> COLUMN DICT_BEGIN FORMAT A10;
SQL> SET NUMF 99999999;
SQL> SELECT FILE_NAME, SEQUENCE# AS SEQ#, FIRST_CHANGE# AS F_SCN#,
NEXT_CHANGE# AS N_SCN#, TIMESTAMP,
DICT_BEGIN AS BEG, DICT_END AS END,
THREAD# AS THR#, APPLIED 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 字典构建从日志文件序号 5 开始。最新的归档重做日志文件的序号为 13，逻辑备库在 01:02:41 收到该文件。APPLIED 列表示 SQL Apply 程序已应用了 SCN 144057 之前的所有重做数据。由于事务可以跨越多个归档日志文件，因此多个归档日志文件可能会在 APPLIED 列中显示值 CURRENT。
（3）V$DATAGUARD_STATS
提供与逻辑备库的故障切换特征相关的信息，包括：
- 故障转移时间（apply finish time）
- 应用延迟时间（apply lag）
- 传输延迟时间（transport lag ）
SQL> COL NAME FORMAT A20
SQL> COL VALUE FORMAT A12
SQL> COL UNIT FORMAT A30
SQL> SELECT NAME, VALUE, UNIT FROM V$DATAGUARD_STATS;
NAME VALUE UNIT
-------------------- ------------ ------------------------------
apply finish time +00 00:00:00 day(2) to second(1) interval
apply lag +00 00:00:00 day(2) to second(0) interval
transport lag +00 00:00:00 day(2) to second(0) interval
（4）V$LOGSTDBY_PROCESS
提供 SQL Apply 相关进程的状态信息。
SQL> COLUMN SERIAL# FORMAT 9999
SQL> COLUMN SID FORMAT 9999
SQL> SELECT SID, SERIAL#, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_PROCESS;
SID SERIAL# SPID TYPE HIGH_SCN
----- ------- ----------- ---------------- ----------
48 6 11074 COORDINATOR 7178242899
56 56 10858 READER 7178243497
46 1 10860 BUILDER 7178242901
45 1 10862 PREPARER 7178243295
37 1 10864 ANALYZER 7178242900
36 1 10866 APPLIER 7178239467
35 3 10868 APPLIER 7178239463
34 7 10870 APPLIER 7178239461
33 1 10872 APPLIER 7178239472
9 rows selected.
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
（5）V$LOGSTDBY_PROGRESS
提供 SQL Apply 处理过程详细信息。
包括：
- 已经应用到的记录的 SCN 和时间（applied_scn，applied_time），之前的重做记录都已经应用。
- 最新接收到的记录的 SCN 和时间（latest_scn, latest_time）。
- 由 BUILDER 进程处理的最新记录的 SCN 和时间（mining_scn, mining_time），之前的重做记录都已经处理。
- 重启后需要读取的记录的 SCN 和时间（restart_scn, restart_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
SQL> ALTER SESSION SET NLS_DATE_FORMAT='yy-mm-dd hh24:mi:ss';
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:53 05-05-12 10:41:21 05-05-12 10:09:30
（6）V$LOGSTDBY_STATE
提供 SQL Apply 当前状态的概要。
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 Apply 在实时应用模式下运行，并且当前正在应用从主库接收的重做数据，主库的 DBID 为 1562626987，与 SQL Apply 会话关联的 LogMiner 会话标识符为 1。
（7） V$LOGSTDBY_STATS
显示与 SQL Apply 相关的统计信息、当前状态和状态信息。当 SQL Apply 未运行时，不会返回任何行。
SQL> ALTER SESSION SET NLS_DATE_FORMAT='dd-mm-yyyy hh24:mi:ss';
SQL> SELECT SUBSTR(name, 1, 40) AS NAME, SUBSTR(value,1,32) AS VALUE FROM V$LOGSTDBY_STATS;
NAME VALUE
---------------------------------------- --------------------------------
logminer session id 1
number of preparers 1
number of appliers 5
server processes in use 9
maximum SGA for LCR cache (MB) 30
maximum events recorded 10000
preserve commit order TRUE
transaction consistency FULL
record skipped errors Y
record skipped DDLs Y
record applied DDLs N
record unsupported operations N
realtime apply Y
apply delay (minutes) 0
coordinator state APPLYING
coordinator startup time 19-06-2007 09:55:47
coordinator uptime (seconds) 3593
txns received from logminer 56
txns assigned to apply 23
txns applied 22
txns discarded during restart 33
large txns waiting to be assigned 2
rolled back txns mined 4
DDL txns mined 40
CTAS txns mined 0
bytes of redo mined 60164040
bytes paged out 0
pageout time (seconds) 0
bytes checkpointed 4845
checkpoint time (seconds) 0
system idle time (seconds) 2921
standby redo logs mined 0
archived logs mined 5
gap fetched logs mined 0
standby redo log reuse detected 1
logfile open failures 0
current logfile wait (seconds) 0
total logfile wait (seconds) 2910
thread enable mined 0
thread disable mined 0
.
40 rows selected.
Monitoring a Logical Standby Database
Monitoring SQL Apply Progress
SQL Apply 可以处于以下六种状态中的任何一种：
（1）Initializing State
当使用 ALTER DATABASE START LOGICAL STANDBY APPLY 语句启动 SQL Apply 时，进入 Initializing State。
查询 V$LOGSTDBY_STATE 视图查看 SQL Apply 的当前状态。
SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;
SESSION_ID STATE
---------- -------------
1 INITIALIZING
SESSION_ID 列表示由 SQL Apply 创建的 LogMiner 会话，用于挖掘主库生成的归档日志文件。
（2）Waiting for Dictionary Logs
首次启动 SQL Apply 时，会加载重做日志文件中捕获的 LogMiner 字典。SQL Apply 在收到加载 LogMiner 字典所需的所有重做数据之前，会保持在该状态。
（3）Loading Dictionary State
在大型数据库上加载 LogMiner 字典可能需要很长时间。加载字典时，查询 V$LOGSTDBY_STATE 视图将返回以下输出：
SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;
SESSION_ID STATE
---------- ------------------
1 LOADING DICTIONARY
在 LogMiner 字典完全加载之前，只会启动 COORDINATOR 进程和日志挖掘相关进程。因此，如果此时查询 V$LOGSTDBY_PROCESS，将看不到任何 APPLIER 进程。例如：
SQL> SELECT SID, SERIAL#, SPID, TYPE FROM V$LOGSTDBY_PROCESS;
SID SERIAL# SPID TYPE
------ --------- --------- ---------------------
47 3 11438 COORDINATOR
50 7 11334 READER
45 1 11336 BUILDER
44 2 11338 PREPARER
43 2 11340 PREPARER
可以通过查询 V$LOGMNR_DICTIONARY_LOAD 视图来获取有关加载字典进度的详细信息。字典加载分三个阶段进行：
挖掘相关的归档重做日志文件或备库重做日志文件，以收集与加载 LogMiner 字典相关的重做数据。
在数据库内的临时表中处理和加载重做数据。
通过 DDL 语句加载 LogMiner 字典表。
例如：
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 事务的进度。
（4）Applying State
在此状态下，SQL Apply 已成功加载 LogMiner 字典的初始快照，并且当前正在将重做数据应用于逻辑备库。
有关 SQL Apply 进度的详细信息，查询 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
（5）Waiting On Gap State
当 SQL Apply 挖掘并应用了所有可用的重做记录，并且正在等待 RFS 进程归档新的日志文件（或丢失的日志文件）时，会发生此状态。
SQL> SELECT STATUS FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'READER';
STATUS
------------------------------------------------------------------------
ORA-16240: waiting for log file (thread# 1, sequence# 99)
（6）Idle State
SQL Apply 在应用主库生成的所有重做数据后进入此状态。
Automatic Deletion of Log Files
从主库传输过来的外部重做日志有两种存储方式：
存储在快速恢复区
存储在快速恢复区之外的目录中
存储在快速恢复区中的外部归档日志由 SQL Apply 自动管理。在逻辑备库应用了日志中包含的所有重做记录后，这些记录将保留 DB_FLASHBACK_RETENTION_TARGET 参数指定的时间（默认为 1440 分钟）。无法禁用存储在快速恢复区中的外部归档日志的自动管理。
未存储在快速恢复区中的外部归档日志默认由 SQL Apply 管理。在自动管理下，一旦日志中包含的所有重做记录都应用于逻辑备库，未存储在快速恢复区中的外部归档日志将保留 LOG_AUTO_DEL_RETENTION_TARGET 参数指定的时间。可以通过执行以下 PL/SQL 过程来禁用未存储在快速恢复区中的外部归档日志的自动管理：
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'FALSE');
注意：
使用 DBMS_LOGTSDBY.APPLY_SET 设置 LOG_AUTO_DEL_RETENTION_TARGET 参数。如果未显式指定LOG_AUTO_DEL_RETENTION_TARGET，那么默认设置为 DB_FLASHBACK_RETENTION_TARGET。
如果要手动删除日志，需定期执行以下步骤来识别和删除 SQL Apply 不再需要的归档重做日志文件：
- 清除不再需要的元数据的逻辑备库会话：
SQL> EXECUTE DBMS_LOGSTDBY.PURGE_SESSION;
此语句还会更新 DBA_LOGMNR_PURGED_LOG 视图，此视图显示不再需要的归档重做日志文件。
- 查询 DBA_LOGMNR_PURGED_LOG 视图，列出可以删除的归档重做日志文件：
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
- 使用操作系统命令删除查询列出的归档重做日志文件。
Customizing a Logical Standby Database
Customizing Logging of Events in the DBA_LOGSTDBY_EVENTS View
可以将 DBA_LOGSTDBY_EVENTS 视图视为一个循环日志，包含 SQL Apply 操作期间发生的相关事件。默认记录最近的 10000 个事件，可以通过调用 DBMS_LOGSTDBY.APPLY_SET() 来进行更改。例如：
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET ('MAX_EVENTS_RECORDED', '100000');
例子：将 DDL 事务记录到 DBA_LOGSTDBY_EVENTS 视图
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET ('RECORD_APPLIED_DDL', 'TRUE');
例子：捕获逻辑备库不支持的事务的信息
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> EXEC DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE');
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Using DBMS_LOGSTDBY.SKIP to Prevent Changes to Specific Schema Objects
缺省情况下，主库中所有受支持的表都将被复制到逻辑备库中。可以通过指定规则来跳过对特定表的应用。
例子：指定规则以防止将 DML 和 DDL 更改应用于 EMPLOYEE 表
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'DML', schema_name => 'HR', object_name => 'EMPLOYEES');
SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'SCHEMA_DDL', schema_name => 'HR', object_name => 'EMPLOYEES');
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Modifying a Logical Standby Database
Performing DDL on a Logical Standby Database
默认情况下，只有具有 SYS 权限的帐户才能在数据库防护设置为 ALL 或 STANDBY 时修改数据库。如果以 SYSTEM 或其他特权帐户身份登录，不首先绕过会话的数据库防护，将无法在逻辑备库上发出 DDL 语句。
以下示例说明如何停止 SQL Apply，绕过数据库防护，在逻辑备库上执行 SQL 语句，然后重新启用防护。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Database altered.
SQL> ALTER SESSION DISABLE GUARD;
PL/SQL procedure successfully completed.
SQL> CREATE INDEX EMP_SOUNDEX ON SCOTT.EMP(SOUNDEX(ENAME));
Table altered.
SQL> ALTER SESSION ENABLE GUARD;
PL/SQL procedure successfully completed.
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.
SQL> SELECT ENAME,MGR FROM SCOTT.EMP WHERE SOUNDEX(ENAME) = SOUNDEX('CLARKE');
ENAME MGR
---------- ----------
CLARK 7839
Oracle 建议在绕过数据库防护时不要对 SQL Apply 维护的表执行 DML 操作，这将导致主库和备库不一致。
Modifying Tables That Are Not Maintained by SQL Apply
以下示例说明如何停止 SQL Apply，跳过表，然后重新启动 SQL Apply。
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 Apply 启动后，需要为跳过规则中新添加的表更新备库上的元数据。在 SQL Apply 更新元数据之前，尝试修改新跳过的表将失败。可以使用以下查询来了解 SQL Apply 是否使用刚刚添加的 SKIP 规则：
SQL> SELECT VALUE FROM SYSTEM.LOGSTDBY$PARAMETERS WHERE NAME = 'GUARD_STANDBY';
VALUE
---------------
Ready
当 VALUE 列显示 Ready 时，SQL Apply 已成功更新跳过的表的所有相关元数据，并且可以安全地修改该表。
Adding or Re-Creating Tables On a Logical Standby Database
通常，使用 DBMS_LOGSTDBY.INSTANTIATE_TABLE 重建表。还可以使用此存储过程对以前跳过的表启用 SQL Apply。
例子：重建 HR.EMPLOYEES 表
步骤：
（1）停止 SQL Apply。
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
因为已经有重建表相关联的跳过规则，必须先删除这些规则。
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 重建表及其数据，其中 BOSTON 时到主库的 DBLINK。
SQL> EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE(schema_name => 'HR', table_name => 'EMPLOYEES', dblink => 'BOSTON');
（4）启动 SQL Apply。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
若要确保重建的表和数据库的其余部分之间的视图一致，需要等待 SQL Apply 追上主库，然后再查询重建的表。步骤：
（1）查询主库的 CURRENT_SCN。
SQL> SELECT CURRENT_SCN FROM V$DATABASE@BOSTON;
CURRENT_SCN
---------------------
345162788
（2）查看备库的 APPLIED_SCN。
SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS;
APPLIED_SCN
--------------------------
345161345
如果 APPLIED_SCN 比 CURRENT_SCN 大，则可以安全查询重建的表。
Tuning a Logical Standby Database
Create a Primary Key RELY Constraint
在创建物理备库的准备阶段，需要为没有唯一逻辑标识符的表创建禁用的主键 RELY 约束。在创建完逻辑备库后，需要在逻辑备库中为这些表创建主键或者唯一键，以便提高性能。
步骤：
（1）查询需要主键或者唯一键的表。
SQL> SELECT OWNER, TABLE_NAME FROM DBA_TABLES
WHERE OWNER NOT IN (SELECT OWNER FROM DBA_LOGSTDBY_SKIP
WHERE STATEMENT_OPT = 'INTERNAL SCHEMA')
MINUS
SELECT DISTINCT TABLE_OWNER, TABLE_NAME FROM DBA_INDEXES
WHERE INDEX_TYPE NOT LIKE ('FUNCTION-BASED%')
MINUS
SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED;
（2）停止 SQL Apply。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
（3）关闭当前会话的数据库防护。
SQL> ALTER SESSION DISABLE GUARD;
（4）增加唯一索引。
SQL> CREATE UNIQUE INDEX UI_TEST_EMP ON HR.TEST_EMPLOYEES (EMPNO);
（5）启用当前会话的数据库防护。
SQL> ALTER SESSION ENABLE GUARD;
（6）启动 SQL Apply。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Adjust the Number of Processes
可以修改三个参数来控制分配给 SQL Apply 的进程数：
- MAX_SERVERS
- APPLY_SERVERS
- PREPARE_SERVERS
三个参数的关系如下：
APPLY_SERVERS + PREPARE_SERVERS = MAX_SERVERS - 3
其中 3 表示 SQL Apply 始终为 READER，BUILDER 和 ANALYZER 分配一个进程。
- 默认情况下，MAX_SERVERS 为 9，PREPARE_SERVERS 为 1，APPLY_SERVERS 为 5。
- Oracle 建议仅通过 DBMS_LOGSTDBY.APPLY_SET 更改 MAX_SERVERS 参数，准备进程和应用进程由 SQL Apply 分配。
SQL Apply 分配进程的算法为每 20 个 SQL Apply 进程（MAX_SERVERS）分配 1 个PREPARE_SERVER，例如：
- MAX_SERVER 为 1 ~ 20，则 PREPARE_SERVER 为 1。
- MAX_SERVER 为 20 ~ 40，则 PREPARE_SERVER 为 2。
可以通过直接设置 APPLY_SERVERS 和 PREPARE_SERVERS 来覆盖此分配算法。
Adjusting the Number of APPLIER Processes
先查看是否需要调整 APPLIER 进程数量来提高性能，步骤如下：
（1）查看 APPLIER 进程是否繁忙。
SQL> SELECT COUNT(*) AS IDLE_APPLIER
FROM V$LOGSTDBY_PROCESS
WHERE TYPE = 'APPLIER' and status_code = 16116;
IDLE_APPLIER
-------------------------
0
（2）上面查询返回 0，表示 APPLIER 没有空闲进程，然后查询事务信息。
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME = 'txns applied' OR NAME = 'distinct txns in queue';
如果 distinct txns in queue - txns applied 时 APPLIER 进程的 2 倍，则增加 APPLIER 进程数量可以提高性能。
如果需要设置 APPLIER 进程数量为 20，REPARER 进程数量为 1，则需要先设置 MAX_SERVERS 为 24，再设置 APPLY_SERVERS 为20。
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SERVERS', 24);
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS', 20);
Adjusting the Number of PREPARER Processes
只有在极少数情况下，才需要调整 PREPARER 进程数量。在决定增加 PREPARER 进程数量之前，需确保满足以下条件：
- 所有 PREPARER 进程都忙。
- 准备应用的事务数量小于 APPLIER 进程数量。
- 存在空闲的 APPLIER 进程。
步骤：
（1）确认所有 PREPARER 进程都忙。
SQL> SELECT COUNT(*) AS IDLE_PREPARER
FROM V$LOGSTDBY_PROCESS
WHERE TYPE = 'PREPARER' and status_code = 16116;
IDLE_PREPARER
-------------
0
（2）确认准备应用的事务数量小于 APPLIER 进程数量（需要多次执行）。
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME = 'txns applied' OR NAME = 'distinct txns in queue';
NAME VALUE
--------------------- -------
txns applied 27892
distinct txns in queue 12896
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 = 16116;
IDLE_APPLIER
-------------------------
19
如果 3 个条件都满足，假设需要调整 PREPARER 进程数量为 3，APPLIER 进程数量保持不变为 20，则需要先设置 MAX_SERVERS 为 26，再增加 PREPARER 进程。
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SERVERS', 26);
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PREPARE_SERVERS', 3);
Adjust the Memory Used for LCR Cache
查看是否需要通过增加 LCR Cache 来提高性能的步骤：
（1）查询当前状态。
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE '%page%'
OR NAME LIKE '%uptime%' OR NAME LIKE '%idle%';
NAME VALUE
---------------------------- --------------
coordinator uptime (seconds) 894856
bytes paged out 20000
pageout time (seconds) 2
system idle time (seconds) 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 (seconds) 895156
bytes paged out 1020000
pageout time (seconds) 100
system idle time (seconds) 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%。如果发现其占用大部分时间，则可以增加内存以提高性能：
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SGA', 1024);
Protection Modes
Data Guard Protection Modes
Data Guard 有三种保护模式：
最大可用性（Maximum Availability）
- 此保护模式可在不影响主库可用性的情况下提供最高级别的数据保护。在将事务相关重做数据写入主库联机重做日志和至少一个同步备库的备库重做日志之后，事务才会提交。如果主库无法将其重做数据写入至少一个同步备库，则将以最大性能模式保持主库可用性，直到再次恢复同步写入备库。
- 此保护模式可确保在主库发生故障时不会丢失数据。
最大性能（Maximum Performance）
此保护模式可在不影响主库性能的情况下提供最高级别的数据保护。在将事务相关重做数据写入主库联机重做日志后立即提交，重做数据异步写入一个或多个备库，主库性能不受将重做数据写入备库的延迟的影响。
此保护模式提供的数据保护略低于最大可用性模式，但对主库性能的影响最小。
这是默认保护模式。
最大保护（Maximum Protection）
此保护模式可确保在主库发生故障时不会丢失数据。要提供此级别的保护，在事务提交之前，必须将相关重做数据同时写入主库联机重做日志和至少一个同步备库的备库重做日志。为了确保不会丢失数据，如果主库无法将其重做数据写入至少一个同步备库，那么将关闭主库。
由于此保护模式将数据保护优先于主库可用性，因此 Oracle 建议至少使用两个备库，以防止单个备库故障导致主库关闭。
Setting the Data Protection Mode of a Primary Database
数据保护模式所需的重做传输属性：
| Maximum Availability | Maximum Performance | Maximum Protection |
|---|---|---|
AFFIRM | NOAFFIRM | AFFIRM |
SYNC | ASYNC | SYNC |
DB_UNIQUE_NAME | DB_UNIQUE_NAME | DB_UNIQUE_NAME |
主库设置数据保护模式的语法：
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {AVAILABILITY | PERFORMANCE | PROTECTION};
主库查询数据保护模式：
SQL> SELECT PROTECTION_MODE FROM V$DATABASE;
Role Transitions
Introduction to Role Transitions
数据库角色有：
- 主库
- 备库
可以使用 SQL 语句更改角色。Oracle Data Guard 支持以下角色转换类型：
- Switchover
允许主库与其一个备库转换角色。切转换间不会丢失数据。转换后每个数据库将继续以其新角色参与 Data Guard 配置。
- Failover
在主库发生故障后，将备库转换为新主库。如果主库在发生故障前未在最大保护模式或最大可用性模式下运行，则可能会丢失一些数据。如果主库启用了闪回数据库，那么在故障处理后，可以将其恢复为新主库的备库。
Preparing for a Role Transition
进行角色转换前的准备工作：
- 查看初始化参数配置是否正确，包括 LOG_ARCHIVE_DEST_n，LOG_ARCHIVE_DEST_STATE_n，FAL_SERVER等。
- 在主库查询 V$ARCHIVE_DEST_STATUS 查看传输目标是否有传输错误或者日志间隙。
SQL> SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;
STATUS GAP_STATUS
--------- ------------------------
VALID NO GAP
- 确保主库和备库的临时文件一致。
- 移除延迟应用配置。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
- 在将 RAC 主库 SWITCHOVER 到物理备库前，需要关闭 RAC 其他实例只保留一个实例，SWITCHOVER 后再进行启动。
- 在对启用了实时查询的物理备库进行 Switchover 前，建议将其启动到 MOUNT 状态。
- 在对主库转换前，配置 Standby Redo Log。
Choosing a Target Standby Database for a Role Transition
对于具有多个备库的 Data Guard 配置，在为角色转换选择目标备库时需要考虑：
备库的位置。
备库的硬件配置。
执行角色转换所需的时间。
备库类型。
如果新主库转换前是物理备库，则配置中的其余备库将成为新主库的备库。
如果新主库转换前是逻辑备库，则配置中的其余逻辑备库将成为新主库的备库，配置中的物理备库仍是旧主库的备库。
在有物理备库和逻辑备库的 Data Guard 配置中，通常选择物理备库进行转换。
使用 V$DATAGUARD_STATS 视图查看角色转换所需时间：
SQL> COLUMN NAME FORMAT A24
SQL> COLUMN VALUE FORMAT A16
SQL> COLUMN DATUM_TIME FORMAT A24
SQL> SELECT NAME, VALUE, DATUM_TIME FROM V$DATAGUARD_STATS;
NAME VALUE DATUM_TIME
------------------------ ---------------- ------------------------
transport lag +00 00:00:00 06/18/2009 12:22:06
apply lag +00 00:00:00 06/18/2009 12:22:06
apply finish time +00 00:00:00.000
estimated startup time 9
输出表示备库已接收并应用主库生成的所有重做数据。
Switchovers
Switchover 通常用于操作系统或者硬件升级，Oracle 软件升级或者安装补丁，减少主库的停机时间。
Switchover 分两个阶段进行：
- 在第一阶段，原主库转换为新备库。
- 在第二阶段，原备库转换为新主库。
转换前配置：
原主库转换为新备库：
原备库转换为新主库：
转换前需要确认：
- 对于物理备库，主库处于 OPEN 状态，备库的 Redo Apply 处于活动状态。
- 对于逻辑备库，主库和备库都处于 OPEN 状态，备库的 SQL Apply 处于活动状态。
Failovers
Failover 通常仅在主库不可用，并且无法在合理的时间内恢复时使用。
转换前需要确认：
- 如果备库运行在最大保护模式，需要修改为最大性能模式：
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
Role Transitions Involving Physical Standby Databases
Performing a Switchover to a Physical Standby Database
步骤：
（1）主库：查看状态。
查询 V$DATABASE 视图的 SWITCHOVER_STATUS 字段：
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO STANDBY
如果结果为 TO STANDBY 或者 SESSIONS ACTIVE 表示主库可以转换为备库。
（2）主库：转换为新物理备库。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
转换前会将控制文件备份到当前会话的跟踪文件。
（3）主库：启动到 MOUNT。
SQL> STARTUP MOUNT;
（4）备库：查看状态。
查询 V$DATABASE 视图的 SWITCHOVER_STATUS 字段：
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO_PRIMARY
如果结果为 TO PRIMARY 或者 SESSIONS ACTIVE 表示备库可以转换为主库。
（5）备库：转换为新主库。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
（6）备库：打开新主库。
SQL> ALTER DATABASE OPEN;
（7）主库：启动 Redo Apply。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
Performing a Failover to a Physical Standby Database
步骤：
（1）主库：发送重做数据到备库。
如果主库可以 MOUNT，但是不能 OPEN。执行以下语句：
SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;
其中 target_db_name 为备库的 DB_UNIQUE_NAME。这条语句将主库上未发送的重做数据发送到备库。
如果执行成功，则跳到第 4 步。
如果执行失败，则进行第 2 步。
主库不能 MOUNT，则进行第 2 步。
（2）备库：获取主库未发送的日志。
查询 V$ARCHIVED_LOG 视图获取各线程的最大日志序号。
SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#)
OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;
THREAD LAST
---------- ----------
1 100
如果可以，拷贝主库上比备库多的日志文件到备库，然后注册到备库。
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
（3）备库：解决日志间隙。
查询 V$ARCHIVE_GAP 视图查看是否有日志间隙。
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
1 90 92
以上结果表示线程为 1 ，序号为 90，91，92 的日志丢失。
如果可以，从主库拷贝丢失的日志文件到备库，然后注册到备库。
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
重复以上步骤，直到解决所有日志间隙。
（4）备库：停止 Redo Apply。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
（5）备库：完成应用所有重做数据。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
如果执行成功，则进行第 6 步。
如果执行失败，且不能解决（会丢失数据），则执行以下语句：
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
然后进行第 8 步。
（6）备库：查看状态。
查询 V$DATABASE 视图的 SWITCHOVER_STATUS 字段：
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO PRIMARY
如果结果为 TO PRIMARY 或者 SESSIONS ACTIVE 表示备库可以转换为主库。
（7）备库：转换为主库。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
（8）备库：打开数据库。
SQL> ALTER DATABASE OPEN;
Role Transitions Involving Logical Standby Databases
Performing a Switchover to a Logical Standby Database
步骤：
（1）主库：查看状态。
查询 V$DATABASE 视图的 SWITCHOVER_STATUS 字段：
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO STANDBY
如果结果为 TO STANDBY 或者 SESSIONS ACTIVE 表示主库可以转换为逻辑备库。
（2）主库：准备切换。
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY;
如果执行成功，V$DATABASE 视图的 SWITCHOVER_STATUS 字段为 PREPARING SWITCHOVER。
（3）备库：准备切换。
使用以下语句创建 LogMiner 字典。
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;
执行过程中，V$DATABASE 视图的 SWITCHOVER_STATUS 字段为 PREPARING DICTIONARY。执行完成后为 PREPARING SWITCHOVER。
（4）主库：确认 LogMiner 字典创建完成。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO LOGICAL STANDBY
如果结果为 O LOGICAL STANDBY 则进行第 5 步。
注意：
可以取消 Switchover 操作：
主库取消：
SQL> ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;备库取消：
SQL> ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;
（5）主库：转换为逻辑备库。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
此语句等待主库上的所有当前事务结束，并阻止任何新用户启动新事务。可以查询 V$TRANSACTION 视图，以获取延迟此语句执行的事务信息。
（6）备库：查看状态。
查询 V$DATABASE 视图的 SWITCHOVER_STATUS 字段：
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO PRIMARY
如果结果为 TO PRIMARY 则进行第 7 步。
（7）备库：转换为新主库。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
（8）主库：启动 SQL Apply。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Performing a Failover to a Logical Standby Database
步骤：
（1）主库：发送重做数据到备库。
如果主库可以 MOUNT，但是不能 OPEN。执行以下语句：
SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;
其中 target_db_name 为备库的 DB_UNIQUE_NAME。这条语句将主库上未发送的重做数据发送到备库。
（2）备库：获取主库未发送的日志。
拷贝主库上比备库多的日志文件到备库，然后注册到备库。
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE 'filespec1';
（3）备库：转换为主库。
SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY;
Troubleshooting
What to Do If SQL Apply Stops
如果遇到不受支持的 DML 语句，DDL 语句以及程序包，SQL Apply 将会停止。具体问题和解决方法如下：
| If... | Then... |
|---|---|
| You suspect an unsupported statement or Oracle supplied package was encountered | Find the last statement in the DBA_LOGSTDBY_EVENTS view. This will indicate the statement and error that caused SQL Apply to fail. If an incorrect SQL statement caused SQL Apply to fail, transaction information, as well as the statement and error information, can be viewed. The transaction information can be used with LogMiner tools to understand the cause of the problem. |
| An error requiring database management occurred, such as running out of space in a particular tablespace | Fix the problem and resume SQL Apply using the ALTER DATABASE START LOGICAL STANDBY APPLY statement. |
| An error occurred because a SQL statement was entered incorrectly, such as an incorrect standby database filename being entered in a tablespace statement | Enter the correct SQL statement and use the DBMS_LOGSTDBY.SKIP_TRANSACTION procedure to ensure the incorrect statement is ignored the next time SQL Apply is run. Then, restart SQL Apply using the ALTER DATABASE START LOGICAL STANDBY APPLY statement. |
An error occurred because skip parameters were incorrectly set up, such as specifying that all DML for a given table be skipped but CREATE, ALTER, and DROP TABLE statements were not specified to be skipped | Issue the DBMS_LOGSTDBY.SKIP('TABLE','schema_name','table_name',null) procedure, then restart SQL Apply. |
Network Tuning for Redo Data Transmission
为了获得最佳性能，可以将在重做传输服务中使用的 Oracle Net 连接描述符中的 Oracle Net SDU 参数设置为 32 KB。
例子：为 tnsnames.ora 文件中的连接描述符增加 SDU 参数
netserv=(DESCRIPTION=(SDU=32768)(ADDRESS=(PROTOCOL=tcp)(HOST=host) (PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=srvc)))
例子：为 listener.ora 文件中的监听增加 SDU 参数
LISTENER=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)
(HOST=host)(PORT=1521))))
SID_LIST_LISTENER=(SID_LIST=(SID_DESC=(SDU=32768)(SID_NAME=sid)
(GLOBALDBNAME=srvc)(ORACLE_HOME=/oracle)))
如果使用高延迟或高带宽网络链接归档到远程站点，则可以使用 SQLNET.SEND_BUF_SIZE 和 SQLNET.RECV_BUF_SIZE 参数提高网络性能。
Troubleshooting a Logical Standby Database
DDL Transactions Containing File Specifications
如果由于主备库环境不同而导致备库 DDL 错误，修改步骤如下：
（1）关闭当前会话的数据库防护。
SQL> ALTER SESSION DISABLE GUARD;
（2）根据备库环境修正 DDL 语句并执行，然后开启当前会话的数据库防护。
SQL> ALTER TABLESPACE t_table ADD DATAFILE '/dbs/t_db.f' SIZE 100M REUSE;
SQL> ALTER SESSION ENABLE GUARD;
（3）启动 SQL Apply ，并跳过失败的事务。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE SKIP FAILED TRANSACTION;
在某些情况下，可以修复导致事务失败的问题，并重新启动 SQL Apply，而无需跳过事务。例如，当可用空间耗尽时：
SQL> SET LONG 1000
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS';
Session altered.
SQL> SELECT EVENT_TIME, COMMIT_SCN, EVENT, STATUS FROM DBA_LOGSTDBY_EVENTS;
EVENT_TIME COMMIT_SCN
------------------ ---------------
EVENT
-------------------------------------------------------------------------------
STATUS
-------------------------------------------------------------------------------
22-OCT-03 15:47:58
ORA-16111: log mining and apply setting up
22-OCT-03 15:48:04 209627
insert into "SCOTT"."EMP"
values
"EMPNO" = 7900,
"ENAME" = 'ADAMS',
"JOB" = 'CLERK',
"MGR" IS NULL,
"HIREDATE" = TO_DATE('22-OCT-03', 'DD-MON-RR'),
"SAL" = 950,
"COMM" IS NULL,
"DEPTNO" IS NULL
ORA-01653: unable to extend table SCOTT.EMP by %200 bytes in tablespace T_TABLE
SQL> ALTER TABLESPACE t_table ADD DATAFILE '/dbs/t_db.f' SIZE 60M;
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
当 SQL Apply 重新启动时，失败的事务将重新执行失败的事务。
Long-Running Transactions
如果 SQL Apply 长时间执行单个 SQL 语句，则告警日志中会报告类似警告消息：
Mon Feb 17 14:40:15 2003
WARNING: the following transaction makes no progress
WARNING: in the last 30 seconds for the given message!
WARNING: xid =
0x0016.007.000017b6 cscn = 1550349, message# = 28, slavid = 1
knacrb: no offending session found (not ITL pressure)
以上信息表示：
- 单个 SQL 语句执行时间超过 30 秒。
- 以
knacrb开头的最后一行表明可能出现了全表扫描，且不是 ITL 问题。
使用以下 SQL 语句查看 SQL Apply 处理的数据库对象：
SQL> SELECT SAS.SERVER_ID, SS.OWNER, SS.OBJECT_NAME, SS.STATISTIC_NAME, SS.VALUE
FROM V$SEGMENT_STATISTICS SS, V$LOCK L, V$STREAMS_APPLY_SERVER SAS
WHERE SAS.SERVER_ID = &SLAVEID
AND L.SID = SAS.SID
AND L.TYPE = 'TM'
AND SS.OBJ# = L.ID1;
上面 SQL 语句中的 &SLAVEID 为告警日志中的 slavid。
使用以下 SQL 语句查看有大量磁盘读取的 SQL 语句：
SQL> SELECT SUBSTR(SQL_TEXT,1,40), DISK_READS, EXECUTIONS, DISK_READS/EXECUTIONS, HASH_VALUE, ADDRESS
FROM V$SQLAREA
WHERE DISK_READS/GREATEST(EXECUTIONS,1) > 1
AND ROWNUM < 10
ORDER BY DISK_READS/GREATEST(EXECUTIONS,1) DESC;
Oracle 建议为所有表定义主键约束。对于没有主键约束的表，如果可能，可以指定 SQL Apply 跳过该表。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML' , schema_name => 'SCOTT' , object_name => 'FTS');
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Troubleshooting ITL Pressure
ITL 问题会出现在告警日志中：
Tue Apr 22 15:50:42 2003
WARNING: the following transaction makes no progress
WARNING: in the last 30 seconds for the given message!
WARNING: xid =
0x0006.005.000029fa cscn = 2152982, message# = 2, slavid = 17
查看以上告警信息对应的 SQL 语句：
SQL> SELECT SA.SQL_TEXT
FROM V$SQLAREA SA, V$SESSION S, V$STREAMS_APPLY_SERVER SAS
WHERE SAS.SERVER_ID = &SLAVEID
AND S.SID = SAS.SID
AND SA.ADDRESS = S.SQL_ADDRESS
SQL_TEXT
------------------------------------------------------------
insert into "APP"."LOAD_TAB_1" p("PK","TEXT")values(:1,:2)
上面 SQL 语句中的 &SLAVEID 为告警日志中的 slavid。
查看有 ITL 问题的段：
SQL> SELECT OWNER, OBJECT_NAME, OBJECT_TYPE
FROM V$SEGMENT_STATISTICS
WHERE STATISTIC_NAME = 'ITL waits'
AND VALUE > 0
ORDER BY VALUE;
通过为对象增大 INITRANS 来解决 ITL 问题：
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> ALTER SESSION DISABLE GUARD;
SQL> ALTER TABLE APP.LOAD_TAB_1 INITRANS 30;
SQL> ALTER SESSION ENABLE GUARD;
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;