Oracle 10G windows 平台 DataGuard 实例(三)

7. 启动备用数据库 ­

C:>set ORACLE_SID=orcl ­

SQL>sqlplus "/as sysdba" ­

SQL>startup nomount pfile='D:/oracle/product/10.2.0/db_1/database/initorcl.ora'; ­

SQL>create spfile from pfile='D:/oracle/product/10.2.0/db_1/database/initorcl.ora'; ­

 

若采用Rman备份的, 则在此standby 端进行 Rman还原数据库：­

$rman target sys/admin@primary auxiliary /­

RMAN> duplicate target database for standby dorecover nofilenamecheck;

 

 

SQL>alter database mount standby database ; ­

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

 

--------------------------------------------------------------------------- ­

测试 ­

 

注意Data Guard 启动顺序：

启动顺序：先standby ,后primary;
       关闭顺序：先primary 后standby;

 

 

在备库将实例启动到mount 状态：

SQL> startup nomount;

SQL>alter database mount standby database ; 

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 

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

 

在备库启动监听：

$lsnrctl start

 

在主库启动实例：

SQL> startup;

 

在主库启动监听：

$lsnrctl start

 

在主库验证归档目录是否有效：

SQL> SELECT STATUS,DESTINATION, ERROR FROM V$ARCHIVE_DEST;

如果有错误，要排查原因。

 

SQL> alter system switch logfile;

 

SQL> select max(sequence#) from v$archived_log;

 

MAX(SEQUENCE#)

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

            70

 

主备查询结果一致，Data Guard 搭建结束。

 

 

 

1. 测试主库产生的归档日志是否能正常传送到归档日志 ­

主库进行日志切换: ­

SQL>Alter system switch logfile; ­

  然后分别查看主库和备库的D:/arch目录下是否产生了同样的归档日志 ­

文件。 ­

select max(sequence#) from v$archived_log; ­

select max(sequence#) from v$log_history; ­

select group#,sequence#,archived,status from v$log; ­

select name,sequence#,applied from v$archived_log; ­

select sequence#,applied from v$archived_log; ­

 

若不同步， ­

1. 看log日志， archive是否有丢失 ­

2. 可以在备库坐如下操作： ­

alter database recover managed standby database cancel; ­

alter database recover managed standby database disconnect from session; ­

 

----------------------------------------------------------------------- ­

主备库切换 ­

 

1. switchover ­

 

一般SWITCHOVER切换都是计划中的切换，特点是在切换后，不会丢失任何的数据，而且这个过程是可逆的，整个DATA GUARD环境不会被破坏，原来DATA GUARD环境中的所有物理和逻辑STANDBY都可以继续工作。 在进行DATA GUARD的物理STANDBY切换前需要注意： ­

确认主库和从库间网络连接通畅； ­

确认没有活动的会话连接在数据库中； ­

PRIMARY数据库处于打开的状态，STANDBY数据库处于MOUNT状态； ­

确保STANDBY数据库处于ARCHIVELOG模式； ­

如果设置了REDO应用的延迟，那么将这个设置去掉； ­

确保配置了主库和从库的初始化参数，使得切换完成后，DATA GUARD机制可以顺利的运行。 ­

 

主库： ­

1. 查看switchover 状态 ­

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; ­

      to standby ­

附： A:switchover_status出现session active/not allowed ­

        当出现session active的时候表示还有活动的session,则运行 ­

         Alter database commit to switchover to physical standby with session shutdown; ­

      当出现not allowed时，在官方文档说转换会不成功，但是我测试的时候成功了，如果大家在测试不成功的时候再和我说，让我看看在什么情况下会不成功。 ­

   ­

     B.ora- 01153: an incompatible media recovery is active ­

        运行下面代码 ­

        Alter database recover managed standby database finish; ­

        或者Alter database recover managed standby database finish force; ­

        Alter database recover managed standby database disconnect from session; ­

2 切换成备库 ­

SQL>Alter database commit to switchover to physical standby with session shutdown; ­

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY; ­

     Database altered. ­

 

3 启动到mount和应用日志状态 ­

SQL> SHUTDOWN IMMEDIATE ­

SQL> startup nomount; ­

SQL> alter database mount standby database; ­

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

 

4. 查看数据库模式 ­

SQL>select dest_name,status,database_mode,recovery_mode,protection_mode from v$archive_dest_status; ­

SQL>select status,database_mode from v$archive_dest_status; ­

 

备库： ­

 

1.查看switchover状态 ­

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; ­

    TO PRIMARY ­

附：若不是用此语句切换：ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY with session shutdown ­

2. 切换成主库 ­

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; ­

Database altered. ­

SQL> shutdown immediate; ­

SQL> startup; ­

SQL> alter system switch logfile; ­

3. 查看数据库模式 ­

SQL>select dest_name,status,database_mode,recovery_mode,protection_mode from v$archive_dest_status; ­

SQL>select status,database_mode from v$archive_dest_status; ­

 

注意地方: ­

如果做了switchover,主库参数设置成以下方式，会触发ora-16009错误 ­

Alert system set log_archive_dest_2=’service=primary ­

DB_UNIQUE_NAME=orcl’ scope=spfile; ­

然后再alert_orcl.log 日志中会出现以下错误内容 ­

Thu Nov 27 10:19:12 2008 ­

Redo Shipping Client Connect ­

-- Connected User is Valid ­

RFS[2]: Assigned to RFS process 1292 ­

RFS[2]: Database mount ID mismatch [0x4781d95f:0x47823be1] ­

RFS[2]: Client instance is standby database i ­

RFS[2]: Not using real app ­

Thu Nov 27 10:19Errors in file ­

d:/oracle/product/10.2.0/admin/orcl/udump/orc ­

ORA-16009: 远程归档日 ­

从metalink上查到: ­

* fact: Oracle Server - Enterprise Edition 9 ­

* symptom: Errors appears in alert.log on primary database ­

* symptom: RFS: client instance is standby database instead ­

* symptom: RFS: Not using real application clusters ­

* symptom: Errors appear in alert.log on standby database ­

* symptom: ­

database ­

standby database ­

primary database ­

* symptom: Standby redo log files are defined on the standby database ­

* cause: The standby redo log files are synchronously filled with redo ­

from the primary database. When a logswitch occur on the primary database, ­

those files are archived on the standby database before being applyed on ­

it. The archiving process on the standby database should only archive to ­

the local disks on tprimarfix: ­

Disable the remote archiving on the standby databasExample: alter system set log_archive_dest_2 = '' ­

是因为没有把standby 上的log_archive_dest_2 清空导致的。 ­

另外也有可 ­

bug 4676659 ­

Standby may not be recognised (ORA-16009) ­

When the log transport is LGWR ASYNC and logical standby has ­

LOG_ARCHIVE_DEST setting VALID_FOR=(ONLINE_LOGFILE, PRIMARY_ROLE) ­

ORA-16009 is reportedregular interWorkaround: ­

There is no workaround to prevent ORA-16009 from appearing in alert logs. ­

 

2. Failovers： ­

FAILOVER切换一般是PRIMARY数据库发生故障后的切换，这种情况是STANDBY数据库发挥其作用的情况。这种切换发生后，可能会造成数据的丢失。而且这个过程不是可逆的，DATA GUARD环境会被破坏。 ­

由于PRIMARY数据库已经无法启动，所以FAILOVER切换所需的条件并不多，只要检查STANDBY是否运行在最大保护模式下，如果是的话，需要将其置为最大性能模式，否则切换到PRIMARY角色也无法启动。 ­

 

 

1.查看是否有日志GAP,没有应用的日志： ­

    SQL> SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG; ­

　　SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; ­

　　如果有，则拷贝过来并且注册 ­

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE '路径'; ­

重复查看直到没有应用的日志： ­

2. 然后停止应用归档： ­

　　SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; ­

　　Database altered. ­

3. 下面将STANDBY数据库切换为PRIMARY数据库： ­

　　SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH; ­

或 SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE; ­

　　Database altered. ­

　　SQL> SELECT DATABASE_ROLE FROM V$DATABASE; ­

　　DATABASE_ROLE ­

　　---------------- ­

　　PHYSICAL STANDBY ­

　　SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; ­

　　Database altered. ­

    SQL> ALTER DATABASE OPEN; 或者 shutdown immediate+startup ­

　　Database altered. ­

 

　　检查数据库是否已经切换成功： ­

　　SQL> SELECT DATABASE_ROLE FROM V$DATABASE; ­

　　DATABASE_ROLE ­

　　---------------- ­

　　PRIMARY ­

　　至此，FAILOVER切换完成。这个时候应该马上对新的PRIMARY数据库进行备份。­

更多信息请查看 java进阶网 http://www.javady.com