首页 > 代码库 > Oracle 10g 物理Dataguard日常操作维护（二）
Oracle 10g 物理Dataguard日常操作维护（二）
3.3进程日志的监控操作
3.3.1 查看备库进程状态
SQL>select process,client_process,sequence#,status from v$managed_standby
PROCESS CLIENT_P SEQUENCE# STATUS
--------- -------- ---------- - -----------
ARCH ARCH 153 CLOSING
ARCH ARCH 154 CLOSING
ARCH ARCH 155 CLOSING
ARCH ARCH 156 CLOSING
ARCH ARCH 157 CLOSING
MRP0 N/A 158 WAIT_FOR_LOG
RFS UNKNOWN 0 IDLE
RFS UNKNOWN 0 IDLE
RFS LGWR 158 IDLE
RFS ARCH 0 IDLE
（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通信，已经接收完序号为157的日志，正等待序号为158的日志
3.3.2 查看物理Standby数据库未接收的日志文件
这种查询从Primary端获取。日志文件的发送是通过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 53
1 54
1 55
1 56
1 57
1 58
1 59
1 60
1 61
1 62
DEST_ID=N，N其实就是LOG_ARCHIVE_DEST_N参数中的那个N。
3.3.3查询standby 最后应用的归档文件
SQL> SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG" FROM V$LOG_HISTORY GROUP BY THREAD#;
THREAD# LAST_APPLIED_LOG
---------- ----------------
1 157
3.3.4 或者查询归档日志应用情况
SQL> SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG;
THREAD# SEQUENCE# APP
---------- ---------- ---
1 67 YES
1 85 YES
1 70 YES
1 69 YES
3.3.5检查归档文件路径和创建信息
物理Standby数据库端可以通过查询V$ARCHIVED_LOG视图，获取归档文件的一些附加信息，如文件创建时间、创建进程、归档序号、是否被应用等，例如：
SQL>SELECT NAME,CREATOR,SEQUENCE#,APPLIED,COMPLETION_TIME FROM V$ARCHIVED_LOG
NAME CREATOR SEQUENCE# APP COMPLETION_TIM
---------------------------------------- ------- ---------- --- --------------
/sywdg/arch1/1_144_758642906.dbf ARCH 144 YES 28-8月 -11
/sywdg/arch1/1_143_758642906.dbf ARCH 143 YES 28-8月 -11
/sywdg/arch1/1_147_758642906.dbf ARCH 147 YES 28-8月 -11
/sywdg/arch1/1_148_758642906.dbf ARCH 148 YES 28-8月 -11
/sywdg/arch1/1_150_758642906.dbf ARCH 150 YES 28-8月 -11
/sywdg/arch1/1_149_758642906.dbf ARCH 149 YES 28-8月 -11
/sywdg/arch1/1_151_758642906.dbf ARCH 151 YES 28-8月 -11
/sywdg/arch1/1_152_758642906.dbf ARCH 152 YES 28-8月 -11
/sywdg/arch1/1_153_758642906.dbf ARCH 153 YES 28-8月 -11
/sywdg/arch1/1_154_758642906.dbf ARCH 154 YES 28-8月 -11
/sywdg/arch1/1_155_758642906.dbf ARCH 155 YES 28-8月 -11
3.3.6．Data Guard事件（V$DATAGUARD_STATUS）
该视图显示那些被自动触发写入Alert.log或服务器Trace文件的事件。不查服务器查询Alert.log时，可以临时访问本视图查看一些与Data Guard相关的信息，例如：
SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;
MESSAGE
----------------------------------------------------------------------------------------------------
Media Recovery Waiting for thread 1 sequence 148
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 1617
RFS[1]: Identified database type as ‘physical standby‘
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 1619
RFS[2]: Identified database type as ‘physical standby‘
Media Recovery Log /sywdg/arch1/1_148_758642906.dbf
Media Recovery Waiting for thread 1 sequence 149
3.4 LGWR SYNC模式下日志同步测试
1.主库执行 查询a表
SQL> select * from a;
I
----------
1
1
1
1
1
1
1
已选择7行。
2.此时备库以 read only 模式打开，现在对standby 进行查询
SQL> select * from a;
I
----------
1
1
1
1
1
1
1
已选择7行。
3.主库备库的数据是一样的，现在把standby备库继续进行日志恢复模式，来接收主库的redo信息
在备库上执行
SQL> alter database recover managed standby database disconnect from session;
数据库已更改。
4.查询备库的运行模式
SQL> select protection_mode,protection_level from v$database;
PROTECTION_MODE PROTECTION_LEVEL
-------------------- --------------------
MAXIMUM AVAILABILITY MAXIMUM AVAILABILIT
说明：备库是运行在最大可用模式，当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;
I
----------
1
SQL> commit;
提交完成。
7.在主库上进行日志切换，将当前redolog归档
SQL> alter system switch logfile;
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;
I
----------
1
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;
I
----------
1
同时在主库上执行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;
I
----------
1
在主库上可以做正常查询和和其他操作，此时不会对备库有任何影响，主库的警告日志会提示设置正确的备库归档目的地
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;
I
----------
1
在备库上执行
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE cancel;
数据库已更改。
SQL> alter database open;
数据库已更改。
SQL> select * from test_primary;
I
----------
1
主库与备库此时数据已经一致 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
Copyright (c) 1982, 2005, Oracle. All rights reserved.
已连接到目标数据库: 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>
数据库已更改。
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服务器。具体操作方式可以分为二类：①重建；②备份恢复本文出自 “O Record” 博客，请务必保留此出处http://evils798.blog.51cto.com/8983296/1420881
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。