Oracle 11g 物理Dataguard日常操作维护（二）

Oracle 11g 物理Dataguard日常操作维护（二）

2017年8月25日

14:34

3.3

3.3.1 查看备库进程状态

SYS(125_7)@fpyj123> select process,client_process,sequence#,status from v$managed_standby ;

PROCESS CLIENT_P SEQUENCE# STATUS

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

ARCH ARCH 0 CONNECTED

ARCH ARCH 93 CLOSING

ARCH ARCH 0 CONNECTED

ARCH ARCH 94 CLOSING

RFS N/A 0 IDLE

RFS UNKNOWN 0 IDLE

RFS LGWR 95 IDLE

RFS UNKNOWN 0 IDLE

MRP0 N/A 95 APPLYING_LOG

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

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

（3）SEQUENCE#：归档序号。

（4）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数据中。

通过上述查询可以得知Primary开了两个归档进程，使用ARCH同步传输方式与物理Standby通信，已经接收完序号为93、94的日志，正等待序号为95的日志

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

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

SYS(125_7)@fpyj123> 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 50

1 58

1 59

1 60

1 61

1 62

1 63

1 64

1 65

1 66

1 67

1 68

1 69

1 70

1 71

1 72

1 73

1 74

1 75

1 76

1 77

1 78

1 79

1 80

1 81

1 82

1 83

1 84

1 85

1 86

1 87

1 88

1 89

1 90

1 91

1 92

1 93

1 94

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

3.3.3查询standby 最后应用的归档文件

SYS(125_7)@fpyj123> SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG" FROM V$LOG_HISTORY GROUP BY THREAD#;

THREAD# LAST_APPLIED_LOG

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

1 94

3.3.4 或者查询归档日志应用情况

SYS(125_7)@fpyj123> SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG;

THREAD# SEQUENCE# APPLIED

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

1 50 YES

1 58 YES

1 51 YES

1 54 YES

1 53 YES

1 55 YES

1 57 YES

1 56 YES

1 52 YES

1 59 YES

1 60 YES

1 61 YES

1 62 YES

1 63 YES

1 64 YES

1 65 YES

1 66 YES

1 67 YES

1 68 YES

1 69 YES

1 70 YES

1 71 YES

1 72 YES

1 73 YES

1 74 YES

1 75 YES

1 76 YES

1 77 YES

1 78 YES

1 79 YES

1 80 YES

1 81 YES

1 82 YES

1 83 YES

1 84 YES

1 85 YES

1 86 YES

1 87 YES

1 88 YES

1 89 YES

1 90 YES

1 91 YES

1 92 YES

1 93 YES

1 94 IN-MEMORY

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

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

SYS(125_7)@fpyj123> col name for a60

SYS(125_7)@fpyj123> SELECT NAME,CREATOR,SEQUENCE#,APPLIED,COMPLETION_TIME FROM V$ARCHIVED_LOG ;

NAME CREATOR SEQUENCE# APPLIED COMPLETIO

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

/home/oracle/arch_dir/fpyj123/1_50_927291116.dbf SRMN 50 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_58_927291116.dbf ARCH 58 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_51_927291116.dbf ARCH 51 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_54_927291116.dbf ARCH 54 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_53_927291116.dbf ARCH 53 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_55_927291116.dbf ARCH 55 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_57_927291116.dbf ARCH 57 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_56_927291116.dbf ARCH 56 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_52_927291116.dbf ARCH 52 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_59_927291116.dbf ARCH 59 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_60_927291116.dbf ARCH 60 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_61_927291116.dbf ARCH 61 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_62_927291116.dbf ARCH 62 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_63_927291116.dbf ARCH 63 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_64_927291116.dbf ARCH 64 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_65_927291116.dbf ARCH 65 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_66_927291116.dbf ARCH 66 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_67_927291116.dbf ARCH 67 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_68_927291116.dbf ARCH 68 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_69_927291116.dbf ARCH 69 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_70_927291116.dbf ARCH 70 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_71_927291116.dbf ARCH 71 YES 24-AUG-17

/home/oracle/arch_dir/fpyj123/1_72_927291116.dbf ARCH 72 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_73_927291116.dbf ARCH 73 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_74_927291116.dbf ARCH 74 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_75_927291116.dbf ARCH 75 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_76_927291116.dbf ARCH 76 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_77_927291116.dbf ARCH 77 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_78_927291116.dbf ARCH 78 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_79_927291116.dbf ARCH 79 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_80_927291116.dbf ARCH 80 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_81_927291116.dbf ARCH 81 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_82_927291116.dbf ARCH 82 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_83_927291116.dbf ARCH 83 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_84_927291116.dbf ARCH 84 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_85_927291116.dbf ARCH 85 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_86_927291116.dbf ARCH 86 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_87_927291116.dbf ARCH 87 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_88_927291116.dbf ARCH 88 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_89_927291116.dbf ARCH 89 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_90_927291116.dbf ARCH 90 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_91_927291116.dbf ARCH 91 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_92_927291116.dbf ARCH 92 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_93_927291116.dbf ARCH 93 YES 25-AUG-17

/home/oracle/arch_dir/fpyj123/1_94_927291116.dbf ARCH 94 IN-MEMORY 25-AUG-17

3.3.6．Data Guard事件（V$DATAGUARD_STATUS）

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

SYS(125_7)@fpyj123> select to_char(timestamp,'yyyy-mm-dd hh24:mi:ss') t1,message from v$dataguard_status order by t1 asc;

MESSAGE

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ARC0: Archival started

ARC1: Archival started

ARC2: Archival started

ARC1: Becoming the 'no FAL' ARCH

ARC2: Becoming the heartbeat ARCH

RFS[1]: Assigned to RFS process 7749

RFS[1]: Identified database type as 'physical standby': Client is ARCH pid 3819

RFS[2]: Assigned to RFS process 7753

RFS[2]: Identified database type as 'physical standby': Client is ARCH pid 3823

ARC1: Beginning to archive thread 1 sequence 93 (1710001-1710049)

ARC1: Completed archiving thread 1 sequence 93 (0-0)

ARC3: Archival started

RFS[3]: Assigned to RFS process 7757

RFS[3]: Identified database type as 'physical standby': Client is LGWR SYNC pid 3720

Primary database is in MAXIMUM PERFORMANCE mode

RFS[4]: Assigned to RFS process 7761

RFS[4]: Identified database type as 'physical standby': Client is ARCH pid 3811

ARC3: Beginning to archive thread 1 sequence 94 (1710049-1710069)

ARC3: Completed archiving thread 1 sequence 94 (0-0)

Attempt to start background Managed Standby Recovery process

MRP0: Background Managed Standby Recovery process started

Managed Standby Recovery starting Real Time Apply

Media Recovery Log /home/oracle/arch_dir/fpyj123/1_91_927291116.dbf

Media Recovery Log /home/oracle/arch_dir/fpyj123/1_92_927291116.dbf

Media Recovery Log /home/oracle/arch_dir/fpyj123/1_93_927291116.dbf

Media Recovery Log /home/oracle/arch_dir/fpyj123/1_94_927291116.dbf

Media Recovery Waiting for thread 1 sequence 95 (in transit)

3.4 LGWR SYNC模式下日志同步测试

1.主库执行查询a表

SQL> select * from a;

----------

已选择7行。

2.此时备库以 read only 模式打开，现在对standby 进行查询

SQL> select * from a;

----------

已选择7行。

3.主库备库的数据是一样的，现在把standby备库继续进行日志恢复模式，来接收主库的redo信息

在备库上执行

SYS(125_7)@fpyjbak> alter database recover managed standby database disconnect from session;

数据库已更改。

4.查询备库的运行模式

SYS(125_7)@fpyj123> select protection_mode,protection_level from v$database;

PROTECTION_MODE PROTECTION_LEVEL

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

MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE

说明：备库是运行在最大可用模式，当dataguard 处于最大可用模式时，如果主库与备库之间没有通信（例如网络断开），主库与备库自动切换值最大性能模式，此时主库上的redolog无法正常传输到备库，当主库上redo在经过日志切换后会被写至主库的归档文件中，当主库与备库正常通信后，主库会强行进行current online redo归档转换，并且通过LNS传输redo信息，在备库oracle利用RFS接收主库redo信息来real time apply进行恢复，因此保持主库与备库的数据一致性

5.现在断开备库网络

[root@DB_standby ~]# service network stop

正在关闭接口 eth0： [确定]

关闭环回接口： [确定]

此时主库的redo信息无法正常传送到备库

6.在主库上执行delete 操作并提交

SQL> delete from a where rownum<7;

已删除6行。

SQL> select * from a;

----------

SQL> commit;

提交完成。

7.在主库上进行日志切换，将当前redolog归档

SQL> alter system switch logfile;

系统已更改。

SQL> alter system switch logfile;

系统已更改。

SQL> select protection_mode,protection_level from v$database;

PROTECTION_MODE PROTECTION_LEVEL

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

MAXIMUM AVAILABILITY RESYNCHRONIZATION

由于主库与备库无法正常通信，保护级别变成了待同步模式，此时查看主库归档日志，发现日志213至219无法传递至备库

Current log# 1 seq# 213 mem# 0: /u01/app/oracle/oradata/syw01/redo01.log

Mon Aug 29 21:41:09 2011

ORA-16198: LGWR received timedout error from KSR

LGWR: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (16198)

LGWR: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned

Mon Aug 29 21:41:09 2011

Errors in file /u01/app/oracle/admin/syw01/bdump/syw01_lgwr_4966.trc:

ORA-16198: 远程归档期间内部通道上超时

LGWR: Network asynch I/O wait error 16198 log 1 service 'syw'

Mon Aug 29 21:41:09 2011

Errors in file /u01/app/oracle/admin/syw01/bdump/syw01_lgwr_4966.trc:

ORA-16198: 远程归档期间内部通道上超时

LGWR: Error 16198 closing archivelog file 'syw'

LGWR: Error 16198 disconnecting from destination LOG_ARCHIVE_DEST_2 standbyhost 'syw'

Thread 1 advanced to log sequence 214

Current log# 2 seq# 214 mem# 0: /u01/app/oracle/oradata/syw01/redo02.log

Mon Aug 29 21:42:31 2011

Thread 1 advanced to log sequence 215

Current log# 3 seq# 215 mem# 0: /u01/app/oracle/oradata/syw01/redo03.log

Thread 1 cannot allocate new log, sequence 216

Checkpoint not complete

Current log# 3 seq# 215 mem# 0: /u01/app/oracle/oradata/syw01/redo03.log

Thread 1 advanced to log sequence 216

Current log# 1 seq# 216 mem# 0: /u01/app/oracle/oradata/syw01/redo01.log

Mon Aug 29 21:42:49 2011

Thread 1 cannot allocate new log, sequence 217

Checkpoint not complete

Current log# 1 seq# 216 mem# 0: /u01/app/oracle/oradata/syw01/redo01.log

Thread 1 advanced to log sequence 217

Current log# 2 seq# 217 mem# 0: /u01/app/oracle/oradata/syw01/redo02.log

Mon Aug 29 21:45:32 2011

Thread 1 advanced to log sequence 218

Current log# 3 seq# 218 mem# 0: /u01/app/oracle/oradata/syw01/redo03.log

Mon Aug 29 21:46:36 2011

ARCH: Possible network disconnect with primary database

LNSb started with pid=21, OS id=15612

Mon Aug 29 21:46:57 2011

LGWR: Standby redo logfile selected to archive thread 1 sequence 219

LGWR: Standby redo logfile selected for thread 1 sequence 219 for destination LOG_ARCHIVE_DEST_2

Thread 1 advanced to log sequence 219

Current log# 1 seq# 219 mem# 0: /u01/app/oracle/oradata/syw01/redo01.l

说明：由于我在主库上执行了删除操作，此时主库上a表只有1行数据，

现在验证：在主库与备库正常通信后，主库的归档日志可以自动传输到备库并且被备库应用

使得备库的a表中数据与主库一样

8.启动备库网络服务

[root@DB_standby ~]# service network start

弹出环回接口： [确定]

弹出界面 eth0： [确定]

查看备库警告日志

-- Connected User is Valid

RFS[16]: Assigned to RFS process 13763

RFS[16]: Identified database type as 'physical standby'

Mon Aug 29 21:46:58 2011

RFS[12]: Archived Log: '/sywdg/arch1/1_214_758642906.dbf'

Mon Aug 29 21:46:59 2011

RFS[16]: Successfully opened standby log 5: '/u01/app/oracle/oradata/stdby_redo05.log'

Mon Aug 29 21:47:00 2011

RFS[11]: Archived Log: '/sywdg/arch1/1_217_758642906.dbf'

Mon Aug 29 21:47:14 2011

RFS[14]: Archived Log: '/sywdg/arch1/1_213_758642906.dbf'

Mon Aug 29 21:47:16 2011

Media Recovery Log /sywdg/arch1/1_213_758642906.dbf

Mon Aug 29 21:47:26 2011

RFS[13]: Archived Log: '/sywdg/arch1/1_215_758642906.dbf'

Mon Aug 29 21:47:40 2011

Media Recovery Log /sywdg/arch1/1_214_758642906.dbf

Mon Aug 29 21:47:40 2011

Primary database is in MAXIMUM AVAILABILITY mode

Changing standby controlfile to MAXIMUM AVAILABILITY level

RFS[15]: Successfully opened standby log 5: '/u01/app/oracle/oradata/stdby_redo05.log'

Mon Aug 29 21:47:41 2011

Media Recovery Log /sywdg/arch1/1_215_758642906.dbf

Media Recovery Log /sywdg/arch1/1_216_758642906.dbf

Media Recovery Log /sywdg/arch1/1_217_758642906.dbf

Media Recovery Log /sywdg/arch1/1_218_758642906.dbf

Media Recovery Log /sywdg/arch1/1_219_758642906.dbf

主库上的归档日志自动传到备库，并且恢复成功，现在只要验证备库的a表是否与主库a表一致

9.以只读方式打开备库

SQL> alter database recover managed standby database cancel;

数据库已更改。

SQL> alter database open;

数据库已更改。

SQL> select * from a;

----------

10.经查询备库与主库的a表一致，在主库进行删除a表数据后，备库通过主库之后传来的归档日志以oracle内部机制，应用当前归档日志保持与主库数据同步

3.5 以read write方式打开物理standby

使用DG中还原点和数据库闪回的组合功能，物理备库可以临时为开发，报表或测试目的以读/写模式打开，然后闪回在过去的一个点恢复物理备用数据库。闪回数据库时，Data Guard备库与主数据库将自动同步，而不需要从主数据库的备份副本重新创建物理备库。

通过下面演示操作将在real-time apply状态的物理备库以读写模式打开

3.5.1 在备库上设置闪回区大小及其路径

SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=2G;

系统已更改。

SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/arch/oradata';

如果不指定闪回路径则oracle将用默认的FRA

3.5.2 在备库上停止standbyd备库的实时应用并创建还原点

SQL> alter database recover managed standby database cancel;

数据库已更改。

SQL> CREATE RESTORE POINT before_app GUARANTEE FLASHBACK DATABASE;

还原点已创建。

3.5.3.在主库上归档主库的当前日志，并将备库的归档目的地设置为defer

SQL> alter system archive log current;

系统已更改。

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;

系统已更改。

3.5.4 激活物理备库，在备库上执行

SQL> alter database activate standby database;

数据库已更改。

SQL> startup mount force;

ORACLE 例程已经启动。

Total System Global Area 285212672 bytes

Fixed Size 2020224 bytes

Variable Size 96472192 bytes

Database Buffers 184549376 bytes

Redo Buffers 2170880 bytes

数据库装载完毕。

3.5.5将备库设置为最大性能模式并以读写模式打开备库.

SQL> alter database set standby database to maximize performance;

数据库已更改。

SQL> alter database open ;

数据库已更改。

此时在备库警告日志会显示当前闪回区大小及使用率和数据库实例状态，日志传送信息，可以发现主库归档日不会传至备库

LOGSTDBY: Validation complete

Wed Aug 31 11:06:59 2011

db_recovery_file_dest_size of 2048 MB is 5.03% used. This is a

user-specified limit on the amount of space that will be used by this

database for recovery-related files, and does not reflect the amount of

space available in the underlying filesystem or ASM diskgroup.

Wed Aug 31 11:07:09 2011

Completed: alter database open

Errors in file /u01/app/oracle/admin/syw/bdump/syw_arc2_29307.trc:

ORA-16009: 远程归档日志目标必须为备用数据库

Wed Aug 31 11:12:23 2011

PING[ARC2]: Heartbeat failed to connect to standby 'syw01'. Error is 16009.

Wed Aug 31 11:13:24 2011

Shutting down archive processes

Wed Aug 31 11:13:29 2011

ARCH shutting down

ARC5: Archival stopped

3.5.6.备库读写测试

查看备库读写模式，此时备库是以读写模式打开

SQL> select open_mode from v$database;

OPEN_MODE

----------

READ WRITE

在备库上执行DML， DDL操作来验证备库

SQL> create table flash_test (i int);

表已创建。

SQL> insert into flash_test values(1);

已创建 1 行。

SQL> commit;

提交完成。

SQL> alter system switch logfile;

系统已更改

经过commit,和日志切换之后，在备库上进行查询，此时备库已有数据可以查询，证明切换备库读写模式成功

SQL> select * from flash_test;

----------

同时在主库上执行DML,DDL操作，将为之后的同步验证做准备

SQL> create table test_primary (i int);

表已创建。

SQL> insert into test_primary values(1);

已创建 1 行。

SQL> commit;

提交完成。

SQL> alter system switch logfile;

系统已更改。

SQL> select * from test_primary;

----------

在主库上可以做正常查询和和其他操作，此时不会对备库有任何影响，主库的警告日志会提示设置正确的备库归档目的地

RFS[43]: Assigned to RFS process 5598

RFS[43]: Database mount ID mismatch [0x152e1eba:0x152b137a]

RFS[43]: Not using real application clusters

Wed Aug 31 13:27:59 2011

Errors in file /u01/app/oracle/admin/syw01/udump/syw01_rfs_5598.trc:

ORA-16009: 远程归档日志目标必须为备用数据库

Redo Shipping Client Connected as PUBLIC

-- Connected User is Valid

RFS[44]: Assigned to RFS process 5775

RFS[44]: Database mount ID mismatch [0x152e1eba:0x152b137a]

RFS[44]: Not using real application clusters

Wed Aug 31 13:32:59 2011

Errors in file /u01/app/oracle/admin/syw01/udump/syw01_rfs_5775.trc:

ORA-16009: 远程归档日志目标必须为备用数据库

接下来将standby 切回至实时应用模式，在备库执行

SQL> STARTUP MOUNT FORCE;

ORACLE 例程已经启动。

Total System Global Area 285212672 bytes

Fixed Size 2020224 bytes

Variable Size 100666496 bytes

Database Buffers 180355072 bytes

Redo Buffers 2170880 bytes

数据库装载完毕。

在备库开始执行闪回

SQL> flashback database to restore point before_app;

闪回完成。

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

数据库已更改

备库警告日志出现如下提示，备库转化完成

Wed Aug 31 14:17:05 2011

flashback database to restore point before_app

Wed Aug 31 14:17:06 2011

Flashback Restore Start

Wed Aug 31 14:17:41 2011

Flashback Restore Complete

Completed: flashback database to restore point before_app

ALTER DATABASE CONVERT TO PHYSICAL STANDBY

Wed Aug 31 14:20:42 2011

ALTER DATABASE CONVERT TO PHYSICAL STANDBY (syw)

Wed Aug 31 14:20:42 2011

The primary database controlfile was created using the

'MAXLOGFILES 16' clause.

There is space for up to 13 standby redo logfiles

Use the following SQL commands on the standby database to create

standby redo logfiles that match the primary database:

ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;

ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;

ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;

ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;

Setting recovery target incarnation to 2

Completed: ALTER DATABASE CONVERT TO PHYSICAL STANDBY

在备库上再次执行STARTUP MOUNT FORCE;

SQL> STARTUP MOUNT FORCE;

ORACLE 例程已经启动。

Total System Global Area 285212672 bytes

Fixed Size 2020224 bytes

Variable Size 100666496 bytes

Database Buffers 180355072 bytes

Redo Buffers 2170880 bytes

数据库装载完毕。

现在开始与主库进行同步操作，在备库上执行

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

数据库已更改。

在主库上执行如下命令来开启standby的日志传输目的地，以保证日志能给正常传到备库

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

系统已更改。

观察备库的alert警告日志

-- Connected User is Valid

RFS[1]: Assigned to RFS process 3828

RFS[1]: Identified database type as 'physical standby'

RFS LogMiner: Client disabled from further notification

Clearing online redo logfile 3 complete

Media Recovery Log /sywdg/arch1/1_240_758642906.dbf

Wed Aug 31 14:28:02 2011

db_recovery_file_dest_size of 2048 MB is 5.96% used. This is a

user-specified limit on the amount of space that will be used by this

database for recovery-related files, and does not reflect the amount of

space available in the underlying filesystem or ASM diskgroup.

Wed Aug 31 14:28:15 2011

Media Recovery Log /sywdg/arch1/1_241_758642906.dbf

Media Recovery Waiting for thread 1 sequence 242

Fetching gap sequence in thread 1, gap sequence 242-242

Wed Aug 31 14:28:28 2011

Redo Shipping Client Connected as PUBLIC

3.5.7 验证standby备库同步

说明：在standby切换至读写模式时，主库与备库之间redo信息无法传输，此时主库上有DDL，DML操作，其中创建了表test_primary，并对其进行insert操作，因此备库无法通过主库redo信息来进行实时应用与主库进行数据同步，当把standby备库由读写模式切换至时时应用模式时，备库应该通过stanby redo log 实时应用来保持与主库数据一致

在主库上执行查询操作

SQL> select * from test_primary;

----------

在备库上执行

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE cancel;

数据库已更改。

SQL> alter database open;

数据库已更改。

SQL> select * from test_primary;

----------

主库与备库此时数据已经一致

3.6 DATAGUARD 备份恢复

3.6.1 DATAGUARD的备份

通常可以为了减轻主库的负担，可以用rman备份备库，登录备库

[oracle@DB_standby arch1]$ rman nocatalog target sys/oracle@syw01

恢复管理器: Release 10.2.0.1.0 - Production on 星期日 8月 23 15:25:12 2011

已连接到目标数据库: SYW (DBID=353353625, 未打开)

使用目标数据库控制文件替代恢复目录，对备库执行备份，运行如下备份脚本

RMAN>run {

allocate channel d1 device type disk;

backup as compressed backupset

incremental level=0

format='/sywdg/dgbak/inc0_stb_%d_%U'

tag='inc0_stb'

channel=d1

database;

backup as compressed backupset

format='/sywdg/dgbak/arch_stb_%d_%U'

tag='arch_stb'

channel=d1

archivelog all delete input;

}

分配的通道: d1

通道 d1: sid=148 devtype=DISK

启动 backup 于 23-8月 -11

通道 d1: 启动压缩的增量级别 0 数据文件备份集

通道 d1: 正在指定备份集中的数据文件

输入数据文件 fno=00007 name=/u01/app/oracle/oradata/syw01/tbs_syw01.ora

输入数据文件 fno=00001 name=/u01/app/oracle/oradata/syw01/system01.dbf

输入数据文件 fno=00004 name=/u01/app/oracle/oradata/syw01/users01.dbf

输入数据文件 fno=00006 name=/u01/app/oracle/oradata/syw01/tbs_cms.ora

输入数据文件 fno=00003 name=/u01/app/oracle/oradata/syw01/sysaux01.dbf

输入数据文件 fno=00005 name=/u01/app/oracle/oradata/syw01/TBS_IDX_SYW.ora

输入数据文件 fno=00002 name=/u01/app/oracle/oradata/syw01/undotbs01.dbf

输入数据文件 fno=00008 name=/u01/t.dbf

通道 d1: 正在启动段 1 于 23-8月 -11

通道 d1: 已完成段 1 于 23-8月 -11

段句柄=/sywdg/dgbak/inc0_stb_SYW_1hml4v4e_1_1 标记=INC0_STB 注释=NONE

通道 d1: 备份集已完成, 经过时间:00:02:36

通道 d1: 启动压缩的增量级别 0 数据文件备份集

通道 d1: 正在指定备份集中的数据文件

备份集中包括当前控制文件

在备份集中包含当前的 SPFILE

段句柄=/sywdg/dgbak/inc0_stb_SYW_1iml4v9b_1_1 标记=INC0_STB 注释=NONE

通道 d1: 备份集已完成, 经过时间:00:00:02

完成 backup 于 23-8月 -11

启动 backup 于 23-8月 -11

通道 d1: 启动压缩的归档日志备份集

通道 d1: 正在指定备份集中的存档日志

输入存档日志线程 =1 序列 =158 记录 ID=103 时间戳=760378683

输入存档日志线程 =1 序列 =159 记录 ID=102 时间戳=760378653

输入存档日志线程 =1 序列 =160 记录 ID=104 时间戳=760378687

输入存档日志线程 =1 序列 =161 记录 ID=105 时间戳=760380176

输入存档日志线程 =1 序列 =162 记录 ID=106 时间戳=760380266

输入存档日志线程 =1 序列 =163 记录 ID=107 时间戳=760380288

输入存档日志线程 =1 序列 =164 记录 ID=108 时间戳=760380707

输入存档日志线程 =1 序列 =165 记录 ID=109 时间戳=760380713

通道 d1: 正在启动段 1 于 28-8月 -11

通道 d1: 已完成段 1 于 28-8月 -11

段句柄=/sywdg/dgbak/arch_stb_SYW_1jml4v9h_1_1 标记=ARCH_STB 注释=NONE

通道 d1: 备份集已完成, 经过时间:00:00:02

通道 d1: 正在删除存档日志

存档日志文件名 =/sywdg/arch1/1_158_758642906.dbf 记录 ID=103 时间戳 =760378683

存档日志文件名 =/sywdg/arch1/1_159_758642906.dbf 记录 ID=102 时间戳 =760378653

存档日志文件名 =/sywdg/arch1/1_160_758642906.dbf 记录 ID=104 时间戳 =760378687

存档日志文件名 =/sywdg/arch1/1_161_758642906.dbf 记录 ID=105 时间戳 =760380176

存档日志文件名 =/sywdg/arch1/1_162_758642906.dbf 记录 ID=106 时间戳 =760380266

存档日志文件名 =/sywdg/arch1/1_163_758642906.dbf 记录 ID=107 时间戳 =760380288

存档日志文件名 =/sywdg/arch1/1_164_758642906.dbf 记录 ID=108 时间戳 =760380707

存档日志文件名 =/sywdg/arch1/1_165_758642906.dbf 记录 ID=109 时间戳 =760380713

完成 backup 于 28-8月 -11

释放的通道: d1

3.6.2 Standby RMAN备份排错

Rman对standby 进行备份时，长出现如下报错信息

通道 d1: 备份集已完成, 经过时间:00:00:03

完成 backup 于 23-8月 -11

RMAN-08132: 警告: 无法更新恢复区可回收文件列表

释放的通道: d1

MAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03009: REFAF 命令 (default 通道上, 在 08/23/2011 16:44:53 上) 失败

ORA-00604: 递归 SQL 级别 1 出现错误

ORA-01219: 数据库未打开: 仅允许在固定表/视图中查询

这是一个oracle的一个bug,需要对standby进行如下丢该

SQL> alter system set optimizer_secure_view_merging=FALSE;

系统已更改。

SQL> shutdown immediate

startup mount

SQL> ORACLE 例程已经启动。

Total System Global Area 285212672 bytes

Fixed Size 2020224 bytes

Variable Size 100666496 bytes

Database Buffers 180355072 bytes

Redo Buffers 2170880 bytes

数据库装载完毕。

数据库已更改。

SQL> alter database recover managed standby database disconnect from session;

在进行备份就不会报错

3.7 dataguard switchover切换

从原Primary数据库端的操作开始，到新Primary数据库端的操作结束，一定要注意操作步骤的先后，检查初始化参数，Primary端和要切换的Standby端都需要进行。检查是否支持switchover操作。执行本步操作时登录到Primary数据库，然后在查询V$DATABASE视图的SWITCHOVER_STATUS列，例如：

主库执行

SQL> select protection_mode,protection_level from v$database;

PROTECTION_MODE PROTECTION_LEVEL

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

MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS

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

SESSIONS ACTIVE

如果该列值为TO STANDBY则表示Primary数据库支持转换为Standby角色，否则你就需要重新检查一下Data Guard配置，如看看LOG_ARCHIVE_DEST_n之类参数值是否正确有效等。

还有一种情况是SWITCHOVER_STATUS列显示为SESSIONS ACTIVE，说明当前有人仍在连接Primary数据库（比如你以as SYSDBA方式通过网络服务名连接的话，就会可能导致该列状态为SESSIONS ACTIVE），出现这种情况不代表不能进行转换，建议首先查询V$SESSION视图，查看当前的连接用户，并根据实际情况决定是否能够中止这些会话连接。

此时，在备库上查看switchover_status参数

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS

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

NOT ALLOWED

A 如果switchover_status为TO_PRIMARY 说明标记恢复可以直接转换为primary库

SQL>alter database commit to switchover to primary

B 如果switchover_status为SESSION ACTIVE 就应该断开活动会话

SQL>alter database commit to switchover to primary with session shutdown;

C 如果switchover_status为NOT ALLOWED 说明切换标记还没收到，此时不能

执行转换

启动switchover首先将Primary数据库转换为Standby角色，可用下列语句：

SQL> alter database commit to switchover to PHYSICAL STANDBY WITH SESSION SHUTDOWN;

WITH SESSION SHUTDOWN的子句，专门用来处理前步操作中仍有用户在连接的情况，如果附加了该子句，Primary数据库执行switchover，就会自动断开仍在连接该实例的无关会话。语句执行完毕后，Primary数据库将会转换为Standby数据库，也就是说这会儿整个Data Guard配置中群备无主了。另外在执行上述SQL语句时会自动备份当前的控制文件到trace文件。

警告日志出现如下信息

Successful close of redo thread 1

Sat Aug 27 14:44:38 2011

ARCH: Noswitch archival of thread 1, sequence 123

ARCH: End-Of-Redo Branch archival of thread 1 sequence 123

ARCH: Archiving is disabled due to current logfile archival

Clearing standby activation ID 353325209 (0x150f5099)

The primary database controlfile was created using the

'MAXLOGFILES 16' clause.

There is space for up to 13 standby redo logfiles

Use the following SQL commands on the standby database to create

standby redo logfiles that match the primary database:

ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;

ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;

ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;

ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;

Archivelog for thread 1 sequence 123 required for standby recovery

MRP0 started with pid=13, OS id=14412

Sat Aug 27 14:44:39 2011

Sat Aug 27 14:44:51 2011

Media Recovery Log /sywdg/arch1/1_123_758642906.dbf

Identified End-Of-Redo for thread 1 sequence 123

overy process shutdown (syw)

Sat Aug 27 14:44:52 2011

idle dispatcher 'D000' terminated, pid = (14, 2)

Sat Aug 27 14:44:53 2011

Switchover: Complete - Database shutdown required (syw)

Sat Aug 27 14:44:53 2011

Completed: alter database commit to switchover to PHYSICAL STANDBY WITH SESSION SHUTDOWN

重新启动到MOUNT状态（原Primary数据库操作）。首先SHUTDOWN原Primary数据库，然后启动到MOUNT状态：

SQL> shutdown immediate

ORA-01507: 未装载数据库

ORACLE 例程已经关闭。

SQL> startup nomount

ORACLE 例程已经启动。

Total System Global Area 285212672 bytes

Fixed Size 2020224 bytes

Variable Size 104860800 bytes

Database Buffers 176160768 bytes

Redo Buffers 2170880 bytes

SQL> alter database mount;

数据库已更改。

SQL> select status from v$instance;

STATUS

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

MOUNTED

此时原Primary数据库就是以Standby身份在运行了。待原Primary切换为Standby角色之后，检查原Standby数据库SWITCHOVER_STATUS列

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS

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

TO PRIMARY

此时原Standby数据库SWITCHOVER_STATUS列值应该是TO PRIMARY，除此之外，如果当前级有用户连接到Standby数据库，也有可能显示成SESSIONS ACTIVE，建议首先断开这些连接后再进行后续操作。另外还有可能显示为SWITCHOVER PENDING，这说明当前Standby数据库没有启动REDO应用，重新执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION命令即可。

转换角色到Primary（原Standby数据库操作）。通过下列语句转换Standby数据库为Primary角色：原物理Standby可以处于MOUNT模式或OPEN READ ONLY模式，但不能处于OPEN READ WRITE模式。执行上述语句时同样支持WITH SESSION SHUTDOWN子句，以自动断开当前非必须的会话连接。

SQL> alter database commit to switchover to primary;

SQL> alter database open;

SQL> select open_mode from v$database;

OPEN_MODE

----------

READ WRITE

3.8 灾难切换物理Standby的failover

failover之后，原Primary数据库默认不再是该Data Guard配置的一部分。

在多数情况下，其他逻辑/物理Standby数据库不直接参与failover的过程，因此这些数据库并不需要做任何操作。在某些情况下，新的Primary数据库配置之后，需要重新创建同一Data Guard配置中其他所有的Standby数据库。在执行failover之前，尽可能将原Primary数据库的可用REDO文件（含联机重做日志文件和归档日志文件）都复制到Standby数据库。如果待转换角色的Standby处于MAXIMUM PROTECTION模式，需要你首先将其切换为Maximum Performance模式，转换Standby数据库到Maximize Performance模式执行下列SQL即可：

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

等待Standby数据库转换为新的Primary之后，可以再随意更改数据库的保护模式。

Maximum Protection模式需要确保绝无数据丢失，因此其对于提交事务对应的REDO数据一致性要求非常高，另外，如果处于Maximum Protection模式的Primary数据库仍然与Standby数据库有数据传输，此时用ALTER DATABASE语句更改Standby数据库保护模式会失败，这也是由Maximum Protection模式特性决定的。

一般情况下failover都是表示Primary数据库瘫痪，因此这种类型的切换基本上不需要Primary数据库做什么操作。所以下列步骤中如果有提到Primary数据库执行的，只是建议如果Primary还可以用，那就执行一下，即使它能用你不执行，也没关系，不影响Standby数据库的角色切换，只是会丢些数据。

如果待转换角色的Standby处于Maximum Protection或Maximum Availability模式的话，归档日志应该是连续存在的，这种情况下你可以直接从第3步执行，否则建议你按照操作步骤从第1步开始执行。

此时待转换的Standby服务器，要通过下列操作，再将其转换成Primary数据库，

1． 检查归档文件是否连续

查询待转换Standby数据库的V$ARCHIVE_GAP视图，确认归档文件是否连接：

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM

V$ARCHIVE_GAP;

no rows selected

如果有返回的记录，按照列出的记录号复制对应的归档文件到待转换的Standby服务器。这一步非常重要，必须确保所有已生成的归档文件均已存在于Standby服务器，不然可能会因数据不一致造成转换时报错。

文件复制过来后，在standby上通过下列命令将其加入数据字典：

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

2．检查归档文件是否完整

分别在Primary和Standby数据库执行下列语句：

SQL> SELECT DISTINCT THREAD#,MAX(SEQUENCE#)

OVER(PARTITION BY THREAD#) A FROM V$ARCHIVED_LOG;

用该语句取得当前数据库各线程已归档文件最大序号，如果Primary与Standby最大序号不相同，必须将多出的序号对应的归档文件复制到待转换的Standby服务器。

3．启动failover

在standby备库执行下列语句：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;

Database altered.

FORCE关键字将会停止当前活动的RFS进程，以便立刻执行failover。

剩下的步骤就与前面switchover很相似了。

4．切换物理Standby角色为Primary

执行下列语句：

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

Database altered.

5．启动新的Primary数据库

如果当前数据库已MOUNT，直接OPEN即可，如果处于READ ONLY模式，需要首先SHUTDOWN IMMEDIATE，然后再执行STARTUP。这里直接用ALTER DATABASE OPEN命令打开数据库：

SQL> ALTER DATABASE OPEN;

Database altered.

角色转换工作完成。剩下的是补救措施（针对原Primary数据库），由于此时Primary数据库已经不再是Data Guard配置的一部分，我们需要做的就是尝试看看能否恢复原Primary数据库，将其改造为Standby服务器。具体操作方式可以分为二类：①重建；②备份恢复

源文档 <http://blog.csdn.net/evils798/article/details/8470072>

posted @ 2017-08-29 16:44 Oracle-fans 阅读(613) 评论(0) 编辑收藏举报

刷新页面返回顶部

ORACLE-fans（本人博客园的文章不再更新，所有博客已迁移到 iyoume2008.cn）

ORACLE-fans（本人博客园的文章不再更新，所有博客已迁移到 iyoume2008.cn）

Oracle 11g 物理Dataguard日常操作维护（二）

公告