dataguard的其他一些操作

用READ ONLY模式打开物理Standby

物理Standby可以有效分担Primary数据库压力，提升资源利用，实际上说的就是将物理Standby置于OPEN状态。

当以READ ONLY模式打开物理Standby，可以将一些不涉及数据库写操作的任务如查询、备份转移到Standby数据库端进行，通过这种方式来分担Primary数据库的压力。下面我们通过实际操作，详细了解Standby数据库在关闭状态、打开状态以及REDO应用状态中的转换。

1．物理Standby数据库从SHUTDOWN状态启动到READ ONLY状态

SQL>STARTUP  

ORACLE instance started.  

SQL> SELECT OPEN_MODE FROM V$DATABASE;

OPEN_MODE

----------

MOUNTED

不过启动成功之后，并不是像普通Oracle数据库那样置于READ WRITE模式，而是进入到READ ONLY模式。

2．物理Standby数据库从REDO应用状态启动到READ ONLY状态

1）首先需要取消REDO应用，执行下列语句：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Database altered.

注意：虽然当前是在MOUNT状态，但并不能直接ALTER DATABASE OPEN打开数据库，否则会报ORA-01154错误。

SQL> ALTER DATABASE OPEN;

ALTER DATABASE OPEN

*

ERROR at line 1:

ORA-01154: database busy. Open, close, mount, and dismount not allowed now

2）取消REDO应用后，再打开数据库：

SQL> ALTER DATABASE OPEN;

Database altered.

SQL> SELECT OPEN_MODE FROM V$DATABASE;

OPEN_MODE

----------

MOUNTED

注意：OPEN的时候不需要附加READ ONLY子句，Oracle会根据控制文件判断是否是物理Standby，从而自动启动到READ ONLY模式。

3．物理Standby数据库从READ ONLY状态切换回REDO应用状态

要从OPEN状态切换回REDO应用状态，并不需要SHUTDOWN数据库再启动，直接执行启用REDO应用的语句即可，例如：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Database altered.

SQL> SELECT OPEN_MODE FROM V$DATABASE;

OPEN_MODE

----------

MOUNTED

由于只读打开时不能应用，查询的结果可能与Primary数据库并不同步的，这一点小小的缺憾降低了物理Standby提供报表服务，分担Primary数据库压力的实用性，对于这点呢，我们有两个解决方案：

改用逻辑Standby，由于逻辑Standby是打开状态下的实时应用，因此数据同步应该是没啥问题了（只要Primary数据库的数据类型都能被逻辑Standby支持）。

Oracle 11g全面改良了物理Standby，最突出的特点就是在READ ONLY打开模式下，可以边接收边应用了，所以可以考虑升级数据库到最新版本，当然新版本也有新版本的问题，如各种尚未暴露出来的Bug。

 管理影响物理Standby的Primary数据库事件

多数情况下，Primary数据库的修改会随着REDO数据传播到物理Standby数据库端并被应用，不需要在物理Standby端做额外的操作，不过根据实际配置的不同，也会有例外，有些操作不是没有被传播到Standby端，而是传播过去了，但不能正确执行，其中最常见的就是对表空间和日志文件的管理操作，下面通过实例逐一进行说明。

9.1  创建表空间或数据文件

初始化参数STANDBY_FILE_MANAGEMENT用来控制是否自动将Primary数据库增加表空间或数据文件的改动，传播到物理Standby数据库。该参数有两个值：

AUTO：如果该参数值设置为AUTO，则Primary数据库执行的表空间创建操作也会被传播到物理Standby数据库上执行。

MANUAL：如果设置为MANUAL或未设置任何值（默认值是MANUAL），需要手工复制新创建的数据文件到物理Standby服务器。

注 意：STANDBY_FILE_MANAGEMENT参数特指Primary数据库端的表空间或数据文件创建，如果数据文件是从其他数据库复制而来（比如通过TTS传输表空间），则不管STANDBY_FILE_MANAGEMENT参数值如何设置，都必须同时手工复制到Standby数据库，并重建物理Standby数据库的控制文件。

9.2  删除表空间

在Primary数据库端删除表空间时，会影响到物理Standby端数据库的数据文件和表空间，初始化参数STANDBY_FILE_MANAGEMENT的属性值设置决定了该事件是否需要DBA介入。

当STANDBY_FILE_MANAGEMENT设置为AUTO。

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;  

System altered. 

在Primary数据库端执行删除表空间的操作：

SQL> DROP TABLESPACE TEST INCLUDING CONTENTS AND DATAFILES;  

Tablespace dropped. 

注：INCLUDING DATAFILES子句，在删除表空间时Oracle也将自动删除对应的物理文件。

将初始化参数STANDBY_FILE_MANAGMENT设置为AUTO，对于表空间和数据文件的操作也无须DBA手工干预，物理Standby能很好地进行处理。

当STANDBY_FILE_MANAGEMENT参数设置为MANUAL时，即使DBA在Primary数据库端执行删除操作时加上了INCLUDING DATAFILES子句，Standby数据库仍然只会将表空间和数据文件从数据字典中删除，表空间涉及的物理文件仍需要手工删除。

对于文件系统，我们可以将初始化参数STANDBY_FILE_MANAGMENT设置为AUTO，但是对于裸设备，只能将该参数设置为MANUAL。

9.3  重命名数据文件

如果Primary数据库重命名了一个或多个数据文件，该项修改并不会自动传播到Standby数据库。 就算设置了初始化参数STANDBY_FILE_MANAGEMENT等于AUTO也不行，要让Standby的数据文件与Primary保持一致，只能手工操作。

下面通过示例演示，操作步骤如下：

首先OFFLINE要更名的数据文件所在的表空间：

SQL> ALTER TABLESPACE SCOTT_TBS OFFLINE;  

Tablespace altered. 

然后手工修改数据文件名。方法很多，这里直接使用操作系统自带的RENAME命令（在Linux平台下可用mv命令）：

SQL> HOST RENAME F:/oracle/oradata/test/scott_tbs01.dbf scott01.dbf 

通过命令修改数据字典中的数据文件路径，然后ONLINE表空间：

SQL> ALTER TABLESPACE SCOTT_TBS RENAME DATAFILE  

  2  'F:/oracle/oradata/test/scott_tbs01.dbf' to 

  3  'F:/oracle/oradata/test/scott01.dbf';  

Tablespace altered.  

SQL> ALTER TABLESPACE SCOTT_TBS ONLINE;  

Tablespace altered.  

SQL> SELECT NAME FROM V$DATAFILE;  

NAME 

-------------------------------------------------- 

F:/ORACLE/ORADATA/TEST/SCOTT01.DBF  

切换日志：  

SQL> ALTER SYSTEM SWITCH LOGFILE;  

System altered.  

在物理Standby端查看当前数据文件路径：  

SQL> SELECT NAME FROM V$DATAFILE;  

NAME 

-------------------------------------------------- 

L:/ORADATA/JSSPDG/SCOTT_TBS01.DBF 

Standby数据库端的数据文件仍为原路径，并未被修改，因此只能DBA介入手动修改。步骤如下：

首先暂停REDO应用：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;  

Database altered. 

手工将数据文件改名：

SQL> HOST REN l:/oradata/test/scott_tbs01.dbf scott01.dbf 

然后修改数据字典中数据文件的路径：

SQL> ALTER DATABASE RENAME FILE  

  2  'L:/ORADATA/TEST/SCOTT_TBS01.DBF' to 

  3  'L:/ORADATA/TEST/SCOTT01.DBF';  

Database altered. 

最后重新启动Standby数据库的REDO应用即可：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;  

Database altered. 

9.4 添加或删除Redologs文件

 数据库调优时极有可能会涉及重置日志文件大小或增加删除日志组等操作，如果STANDBY_FILE_MANAGEMENT参数值设置为AUTO的话，这种操作也会被传播到物理Standby数据库。不过在一般情况下，你可以不管STANDBY_FILE_MANAGEMENT参数的设置，因为无论Primary端对日志组或日志文件的操作是否传播到物理Standby数据库，也不会影响到物理Standby数据库的运行，不过如果你不注意其中的关系，造成的影响可能会很深远。

通常建议当你在Primary数据库增加或删除Online Redologs时，一定记得手工同步相关物理Standby数据库中相关的设置，同时也要考虑好Standby Redologs与Online Redologs之间的关系，即保证Standby Redologs比Online Redologs要至少多一组。

注意的就是在Standby数据库端操作前务必将STANDBY_FILE_MANAGEMENT设置为MANUAL，如果物理Standby数据库的日志文件与Primary数据库路径不同的话，应该通过初始化参数LOG_FILE_NAME_CONVERT的设置，让其自动进行转换。

9.5  跨OPEN RESETLOGS的应用

在某些情况下，Primary数据库以RESETLOGS方式打开之后，也不会影响Data Guard的配置，Standby数据库无须人工参与，自动应用OPEN RESETLOGS的操作，继续接收并应用Primary数据库OPEN RESETLOGS之后产生的日志。

当然这是有条件的，并不是所有情况下都能这么智能。我们知道执行ALTER DATABASE OPEN RESETLOGS语句之后，数据库的INCARNATION被重置，也就是此时其Standby数据库的SEQUENCE序号也会从头开始设置。当然物理Standby数据库并不关注这一点，它只是忠实地紧跟Primary数据库的脚步，一步一步地执行Primary数据库曾经执行过的操作，因此当其接收到新的REDO数据时，就会自动应用这部分REDO数据。

正常情况下这个逻辑没有问题，不过遇到Primary执行过OPEN RESETLOGS之后，又通过备份恢复到OPEN RESETLOGS之前的状态，视物理Standby的具体配置（配置方式决定了物理Standby是否有可能回到OPEN RESETLOGS之前的状态）的不同，情况可能会复杂很多。

图中显示了Primary数据库RESETLOGS操作对Standby的影响

十 监控Primary和物理Standby数据库

10.1  监控途径：概括起来主要通过两个方面来进行：

10.2  监控恢复进度

10.2.1 查看进程的活动状态

V$MANAGED_STANDBY视图专用于显示物理Standby数据库相关进程的当前状态，该视图中的列也很有特点，查看进程状态时，通常我们会关注PROCESS、CLIENT_PROCESS、SEQUENC#和STATUS几列，例如：

SQL> SELECT PROCESS,CLIENT_PROCESS,SEQUENCE#, STATUS FROM V$MANAGED_STANDBY;

PROCESS   CLIENT_P  SEQUENCE# STATUS

--------- -------- ---------- ------------

ARCH      ARCH        78  CLOSING

ARCH      ARCH        79  CLOSING

MRP0      N/A          80  WAIT_FOR_LOG

RFS       LGWR        80  IDLE

RFS       ARCH         0  IDLE

RFS       N/A            0  IDLE

相关说明：

PROCESS：进程名称，如ARCH、RFS、MRP0等。

CLIENT_P：对应的Primary数据库中的进程，如ARCH、LGWR等。

SEQUENCE#：归档序号。

STATUS：进程的当前状态，值较多，常见的有：

1）ALLOCATED：正准备连接Primary数据库。

2）ATTACHED：正在连接Primary数据库。

3）CONNECTED：已连接至Primary数据库。

4）IDLE：空闲中。

5）RECEIVING：归档文件接收中。

6）OPENING：归档文件处理中。

7）CLOSING：归档文件处理完，收尾中。

8）WRITING：REDO数据库写向归档文件中。

9）WAIT_FOR_LOG：等待新的REDO数据中。

10）WAIT_FOR_GAP：归档有中断，正等待中断的那部分REDO数据。

11）APPLYING_LOG：应用REDO数据中。

10.2.2  检查REDO应用进度

V$ARCHIVE_DEST_STATUS视图显示归档文件路径配置信息及REDO的应用情况等，例如：

SQL> SELECT DEST_NAME,ARCHIVED_THREAD#,ARCHIVED_SEQ#,APPLIED_THREAD#,APPLIED_SEQ#, 

DB_UNIQUE_NAME FROM V$ARCHIVE_DEST_STATUS WHERE STATUS='VALID';

DEST_NAME ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# DB_UNIQUE_NAME

-------------------- ---------------- ------------- --------------- ------------ ------------------------------

LOG_ARCHIVE_DEST_1         1          79              0            0      NONE

STANDBY_ARCHIVE_DEST      1          78              1           78     NONE

10.2.3 检查归档文件路径和创建信息

物理Standby数据库端可以通过查询V$ARCHIVED_LOG视图，获取归档文件的一些附加信息，如文件创建时间、创建进程、归档序号、是否被应用等，例如：

SQL>  SELECT NAME,CREATOR,SEQUENCE#,APPLIED,COMPLETION_TIME FROM V$ARCHIVED_LOG;

NAME                                               CREATOR  SEQUENCE# APP COMPLETIO

-------------------------------------------------- ------- ---------- --- ---------

/u01/archive/1_1_717413573.dbf                     ARCH             1 YES 30-APR-10

/u01/archive/1_3_717413573.dbf                     ARCH             3 YES 30-APR-10

... ... 

/u01/archive/1_78_717413573.dbf                    ARCH            78 YES 01-MAY-10

/u01/archive/1_79_717413573.dbf                    ARCH            79 YES 02-MAY-10

10.2.4 查询归档历史

物理Standby数据库端通过V$LOG_HISTORY视图，可以查询所有已被应用的归档文件信息（无论该归档文件是否还存在），例如：

SQL> SELECT FIRST_TIME,FIRST_CHANGE#,NEXT_CHANGE#, SEQUENCE# FROM V$LOG_HISTORY;

FIRST_TIM FIRST_CHANGE# NEXT_CHANGE#  SEQUENCE#

--------- ------------- ------------ ----------

27-APR-10        446075       475833          1

27-APR-10        475833       489482          2

... ...

30-APR-10        544929       590113         78

01-MAY-10        590113       652357         79

仍然通过该视图，稍稍修改下SQL语句，就可以查询到最后应用的归档文件，例如：

SQL> SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG" FROM V$LOG_HISTORY GROUP BY THREAD#;

   THREAD# LAST_APPLIED_LOG

---------- ----------------

         1               79

当然也可以通过查询V$ARCHIVED_LOG视图中的APP列获得相同的功能，例如：  

SQL> SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG;

   THREAD#  SEQUENCE# APP

---------- ---------- ---

         1          1 YES

         1          2 YES

         1          3 YES

10.2.5 查看物理Standby数据库未接收的日志文件

日志文件的发送是通过LOG_ARHIVE_DEST_N参数来控制，因此我们只需要对比本地生成的归档和远端生成的归档间差异即可。例如：

SQL> 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#);

   THREAD#  SEQUENCE#

---------- ----------

         1         76

         1         77

         1         78

         1         79

说明:  DEST_ID=N，N其实就是LOG_ARCHIVE_DEST_N参数中的那个N。

10.2.6  监控日志应用服务

1） 查询当前数据的基本信息（v$database信息）：如，查询数据库角色、保护模式、保护级别等：

SQL> SELECT DATABASE_ROLE,DB_UNIQUE_NAME,OPEN_MODE,

PROTECTION_MODE,PROTECTION_LEVEL, SWITCHOVER_STATUS  FROM V$DATABASE; 

DATABASE_ROLE    DB_UNIQUE_NAME                 OPEN_MODE  PROTECTION_MODE      PROTECTION_LEVEL     SWITCHOVER_STATUS

---------------- ------------------------------ ---------- -------------------- -------------------- --------------------

PRIMARY          orcl_pd                        READ WRITE MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY SESSIONS ACTIVE

再比如，查询failover后快速启动的信息：

SQL> SELECT FS_FAILOVER_STATUS,FS_FAILOVER_CURRENT_TARGET,  FS_FAILOVER_THRESHOLD,  FS_FAILOVER_OBSERVER_PRESENT FROM V$DATABASE;

FS_FAILOVER_STATUS    FS_FAILOVER_CURRENT_TARGET     FS_FAILOVER_THRESHOLD FS_FAIL

--------------------- ------------------------------ --------------------- -------

DISABLED                                                                 0

2） 查看当前REDO应用和REDO传输服务的活动状态

查询物理Standby数据库当前REDO应用和REDO传输服务的状态非V$MANAGED_STANDBY视图莫属，例如：

SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;

PROCESS   STATUS          THREAD#  SEQUENCE#     BLOCK#     BLOCKS

--------- ------------ ---------- ---------- ---------- ----------

ARCH      CLOSING               1         78      98305       1752

ARCH      CLOSING               1         79      98305       1752

MRP0      WAIT_FOR_LOG          1         80          0          0

RFS       IDLE                  1         80      75297          3

RFS       IDLE                  0          0          0          0

RFS       IDLE                  0          0          0          0

3） 检查应用模式（是否启用了实时应用）

物理Standby数据库查询V$ARCHIVE_DEST_STATUS视图，如果打开了实时应用，则RECOVERY_MODE列会显示为：MANAGED REAL TIME APPLY，例如：

SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2;

RECOVERY_MODE

-----------------------

MANAGED

4） Data Guard事件（V$DATAGUARD_STATUS）

该视图显示那些被自动触发写入Alert.log或服务器Trace文件的事件。通常是在你不便访问到服务器查询Alert.log时，可以临时访问本视图查看一些与Data Guard相关的信息，例如：

SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;

MESSAGE

---------------------------------------------------------------------------------------------------

ARC0: Archival started

ARC1: Archival started

ARC0: Becoming the 'no FAL' ARCH

ARC0: Becoming the 'no SRL' ARCH

ARC1: Becoming the heartbeat ARCH

Attempt to start background Managed Standby Recovery process

MRP0: Background Managed Standby Recovery process started

Managed Standby Recovery not using Real Time Apply

Clearing online redo logfile 1 /u01/app/oracle/oradata/orcl/redo01.log

Clearing online redo logfile 1 complete

Media Recovery Waiting for thread 1 sequence 74

10.2.7  调整物理Standby端REDO数据应用频率

调整应用频率，说白了就是调整I/O读取能力，所以通常我们从以下几个方面着手：

1）设置RECOVER并行度

在介质恢复或REDO应用期间，都需要读取重做日志文件，默认都是串行恢复，我们可以在执行RECOVER的时候加上PARALLEL子句来指定并行度，提高读取和应用的性能，例如：

SQL> RECOVER STANDBY DATABASE PARALLEL 2 ; 

提 示: 建议PARALLEL的值为#CPUs×2。

注意: 该设置仅对当前环境有效，Oracle数据库重启之后，默认情况下并行度会恢复至初始值，如果DBA觉着每次执行很麻烦，要通过初始化参数PARALLEL_MAX_SERVERS来设置默认的并行度。

2) 加快REDO应用频繁

设置初始化参数DB_BLOCK_CHECKING=FALSE能够提高2倍左右的应用效率，该参数设置是否验证数据块的有效性，对于物理Standby数据库，禁止验证基本上还是可以接受的（Primary数据库强烈建议将该参数值设置为TRUE，当然默认就是TRUE），该参数是一个动态参数，修改后直接生效，不需要重启数据库。

3) 设置PARALLEL_EXECUTION_MESSAGE_SIZE参数值

如果打开了并行恢复，适当提高初始化参数PARALLEL_EXECUTION_MESSAGE_ SIZE的参数值，比如4096也能提高大概20%左右的性能，不过需要注意，增大这个参数的参数值可能会占用更多内存。

4) 优化磁盘I/O

在恢复期间最大的瓶颈就是I/O读写，要缓解这个瓶颈，使用本地异步I/O并设置初始化参数DISK_ASYNCH_IO=TRUE会有所帮助。DISK_ASYNCH_IO参数控制到数据文件的磁盘I/O是否异步。某些情况下异步I/O 能降低数据库文件并行读取，提高整个恢复时间。

最后

以上就是个性早晨为你收集整理的dataguard的其他一些操作的全部内容，希望文章能够帮你解决dataguard的其他一些操作所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。