11G - RAC - DG环境配置以及维护文档(6)

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

1. SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY; 2. Database altered.

该语句还提供了一个WITH SESSION SHUTDOWN的子句，专门用来处理前步操作中仍有用户在连接的情况，如果附加了该子句，Primary数据库执行switchover，就会自动断开仍在连接该实例的无关会话。

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

1. SQL> SHUTDOWN IMMEDIATE

2. ORA-01507: database not mounted 3. ORACLE instance shut down. 4. SQL> STARTUP MOUNT 5. ORACLE instance started.

6. Total System Global Area 314572800 bytes 7. Fixed Size 1248720 bytes 8. Variable Size 71303728 bytes 9. Database Buffers 234881024 bytes 10. Redo Buffers 7139328 bytes 11. Database mounted.

此时原Primary数据库就是以Standby身份在运行了。

2.2转换standby库为primary，

检查是否能够执行switchover操作（待转换Standby数据库操作）。 待原Primary切换为Standby角色之后，检查待转换的Standby数据库SWITCHOVER_STATUS列，看看是否支持角色转换，建议本地连接：

1. SQL> CONN SYS/VERYSAFE AS SYSDBA 2. Connected.

3. SQL> set sqlprompt \

4. JSSPDG> SELECT SWITCHOVER_STATUS FROM V$DATABASE; 5. SWITCHOVER_STATUS 6. -------------------- 7. TO PRIMARY

此时待转换的Standby数据库SWITCHOVER_STATUS列值应该是TO PRIMARY，除此之外，如果当前级有用户连接到Standby数据库，也有可能显示成SESSIONS ACTIVE，建议首先断开这些连接后再进行后续操作。Oracle提供了一个WITH SESSION SHUTDOWN的子句，专门用来处理前步操作中仍有用户在连接的情况

另外还有可能显示为SWITCHOVER PENDING，这说明当前Standby数据库没有启动REDO应用，重新执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION命令即可。

如果是由于检查其初始化参数配置导致Standby数据库转换状态不对，建议对比原Primary数据库的初始化参数进行修改。

转换角色到Primary（待转换Standby数据库操作）。通过下列语句转换Standby数据库为Primary角色：

1. JSSPDG> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; 2. Database altered.

待转换的物理Standby可以处于MOUNT模式或OPEN READ ONLY模式，但不能处于OPEN READ WRITE模式。

完成转换，打开新的Primary数据库：

1. JSSPDG> ALTER DATABASE OPEN;

数据库已更改。

注：如果数据库处于OPEN READ ONLY模式的话，需要先SHUTDOWN然后直接STARTUP即可。

3.物理Standby的failover

注意以下几点：

failover之后，原Primary数据库默认不再是该Data Guard配置的一部分。 在多数情况下，其他逻辑/物理Standby数据库不直接参与failover的过程，因此这些数据库并不需要做任何操作。

在某些情况下，新的Primary数据库配置之后，需要重新创建同一Data Guard配置中其他所有的Standby数据库。

在执行failover之前，尽可能将原Primary数据库的可用REDO文件（含联机重做日志文件和归档日志文件）都复制到Standby数据库。

如果待转换角色的Standby处于MAXIMUM PROTECTION模式，需要你首先将其切换为Maximum Performance模式（什么什么，你不知道怎么转换模式？O，对对，我们还没有操作过，这块并不复杂，接下来会专门介绍），这里先提前透露一下，转换Standby数据库到Maximize Performance模式执行下列SQL即可：

1. SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

等Standby数据库转换为新的Primary之后，你可以再随意更改数据库的保护模式。 你是不是有疑问，为什么待切换角色的Standby数据库不能处于Maximum Protection模式呢？这个其实很好理解，我们在10.1节学习三种保护模式的时候就介绍过其各自的特点，脑袋瓜好使的同学应该还有印象，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步开始执行。

另外：本环境延续前面小节中执行过的操作，此时JSSPRE已经是Standby服务器了，我们正是要通过下列操作，再将其转换成Primary数据库，千万不要理解错了哟。

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

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

1. JSSPRE> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM 2. V$ARCHIVE_GAP; 3. no rows selected

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

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

1. JSSPRE> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

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

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

1. JSSPRE> SELECT DISTINCT THREAD#,MAX(SEQUENCE#) 2. OVER(PARTITION BY THREAD#) A FROM V$ARCHIVED_LOG;

用该语句取得当前数据库各线程已归档文件最大序号，如果Primary与Standby最大序号不相同，必须将多出的序号对应的归档文件复制到待转换的Standby服务器。不过既然是failover，有可能Primary数据库此时已经无法打开，甚至无法访问，那你只好听天由命喽，三思在这里替你默念：苍天啊，大地啊，哪路的神仙大姐能来保佑俺们不丢数据呀！

3．启动failover 执行下列语句：

1. JSSPRE> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;

2. Database altered.

FORCE关键字将会停止当前活动的RFS进程，以便立刻执行failover。 剩下的步骤就与前面switchover很相似了。 4．切换物理Standby角色为Primary 执行下列语句：

1. JSSPRE> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; 2. Database altered.

5．启动新的Primary数据库

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

1. JSSPRE> ALTER DATABASE OPEN; 2. Database altered.

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

四．Oracle dataguard 物理备库日常维护

以下操作在物理备机实现

1.日志应用管理

1.启用日志应用

SQL> alter database recover managed standby database disconnect from session; Database altered.

2.启用实时的日志应用 real time apply，开启日志的实时应用需要备库有备重做日志文件的存在。

SQL> alter database recover managed standby database using current logfile disconnect from session; Database altered. 3.停止日志应用服务

SQL> alter database recover managed standby database cancel; Database altered. 检查是否存在GAP

SQL> select thread#,low_sequence#,high_sequence# from v$archive_gap; 判断当前备库是否启用了日志实时应用，使用如下语句： SQL> select RECOVERY_MODE from v$archive_dest_status; RECOVERY_MODE -----------------------

MANAGED REAL TIME APPLY MANAGED REAL TIME APPLY

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库11G - RAC - DG环境配置以及维护文档(6)在线全文阅读。