touch_123 发表于 2013-1-14 08:52:53

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: Assigned to RFS process 1292 ­
RFS: Database mount ID mismatch ­
RFS: Client instance is standby database i ­
RFS: 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
页: [1]
查看完整版本: Oracle 10G windows 平台 DataGuard 实例(三)