ORACLE 11G DataGuard Failover后如何修复standby库



failover后的问题场景:

由于做failover测试,一个standby已经被我变成了primary库,如何将这个新的primary库(原来的standby)变回来重新成为standby
两个都是primary,p1,p2,如何将一个primary库1设置成p1,而另外一个primary库p2设置成p1的standby库呢?


1,问题描述
原来的primary库:
SQL> select open_mode,database_role from v$database;


OPEN_MODE     DATABASE_ROLE
-------------------- ----------------
READ WRITE     PRIMARY


SQL> 


新的做了failover变成了primary(原来是standby库)p2,
SQL>  select open_mode,database_role from v$database;


OPEN_MODE     DATABASE_ROLE
-------------------- ----------------
READ WRITE     PRIMARY


SQL>
除了重新clone做standby外,还有别的办法将p2重新变成p1的standby呢?


比较简单的方法是,备库打开flashback database
然后在failover以后,通过flashback回退到切换前的时间点
如果没有打开的话,大概只能重新克隆做备库了


2,解决方案
去standby上查看下数据库是否开启了,
SQL> SELECT FLASHBACK_ON FROM v$database;


FLASHBACK_ON
------------------
NO


SQL> 
闪回没有开启,物理dg一般不开闪回,而且一般oracle数据库默认闪回都不开启,需要手动开启。
物理dg方便重建,但是redo应用不能及时更新。

只能重新进行clone重建。


3,选择clone重新搭建standby
3.1,先确认primary库处于归档模式
SQL> archive log list;
Database log mode       Archive Mode
Automatic archival       Enabled
Archive destination       USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     362
Next log sequence to archive   364
Current log sequence       364
SQL> 


3.2,添加standby文件
因为以前已经是dg模式,所以standby文件一直处于工作状态
select * from v$logfile order by 1;


3.3 生成参数文件
 生成pfile
create pfile from spfile;
shutdown immediate;
检查参数文件,因为是在曾经的dg环境重建,所以参数文件不需要做太大的修改,例行检查一下OK。
vim $ORACLE_HOME/dbs/initpowerdes.ora
*.db_unique_name=pdunq
*.diagnostic_dest=‘/oracle/app/oracle‘
*.dispatchers=‘(PROTOCOL=TCP) (SERVICE=powerdesXDB)‘
*.fal_client=‘pdunq‘
*.fal_server=‘pdunq_dg‘
*.standby_file_management=‘AUTO‘
*.db_file_name_convert=‘/home/oradata/powerdes‘,‘/home/oradata/pwerdes‘
*.log_file_name_convert=‘/home/oradata/powerdes‘,‘/home/oradata/powerdes‘
*.log_archive_config=‘DG_CONFIG=(pdunq,pdunq_dg)‘
*.log_archive_dest_2=‘SERVICE=pdunq_dg  lgwr sync affirm VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=pdunq_dg‘
*.log_archive_dest_state_2=‘ENABLE‘


惯例生成新的spfile
shutdown 
create pfile from spfile;
startup 


3.4,重新注册监听模式
按照惯例的修改primary上的listener.ora以及tnsnames.ora都不需要修改了,因为原来的dg环境都已经配置好了。
配置最大可用模式:
配置最大可用模式:
SQL>startup
SQL>alter database set standby database to maximize availability;
  
3.5,在新的primary上备份数据库
RMAN> backup database plus archivelog;
RMAN> backup current controlfile for standby;
RMAN> exit


3.6,备份集合、参数文件、控制文件同步
包括dump文件目录,数据文件目录,通过show parameter dest;,由于standby原来就有,所以各种目录都不用重新建立,这一步骤省略


从从primary上copy数据文件到standby上
在primary库上执行:
ps:在primary上执行
copy闪回区内容
copy闪回文件
cd /oracle/app/oracle/flash_recovery_area/
scp -r ./* 192.168.121.218:/oracle/app/oracle/flash_recovery_area/


copy参数文件
cd /oracle/app/oracle/product/11.2.0/dbhome_1/dbs
scp -r ./* 192.168.121.218:/oracle/app/oracle/product/11.2.0/dbhome_1/dbs


copy监听文件,由于原来的dg环境已经有了,所以不必copy过去,下面的步骤可以省略。
cd /oracle/app/oracle/product/11.2.0/dbhome_1/network/admin/
scp -r ./* 192.168.121.218:/oracle/app/oracle/product/11.2.0/dbhome_1/network/admin/


PS:至此以下操作基本在standby上操作,如有额外会有提示


4,在standby上修改配置文件
在standby库 修改配置文件 在standby上修改,主要修改db_unique_name以及log_archive_dest_2,其它参数可以不变化,保持原状,如下所示:
[oracle@powerlong5 admin]$ vim listener.ora 
*.db_unique_name=‘pdunq_dg‘  #这里填写的是standby的db_unique_name名字
*.log_archive_dest_2=‘SERVICE=pdunq_dg  lgwr sync affirm VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=pdunq‘ # 这里填写的是primary的db_unique_name,主要是为了switchover的时候用。
PS:将*.log_archive_dest_2=后面的DB_UNIQUE_NAME改成primary的DB_UNIQUE_NAME值改为pdunq,这样在做switchover的时候,新的primary能通过这个将redo日志传到新的standby上面去。
log_archive_dest_N 目的是告诉数据库,把归档放到那里去可选项,首先是本地,然后考虑远程的从库,所以,假设A是主库,B是从库,切换之后B是主库,A是从库,所以,log_archive_dest_N需要设置为对方


4.1,重启监听 standby上
lsnrctl stop;
lsnrctl start;


4.2,恢复数据库
在standby上面操作
先关闭oracle,生成参数文件,然后将oracle启动到nomount状态,然后rman操作恢复
 SQL> shutdown immediate;
 SQL> create pfile from spfile;
 SQL> startup nomount
[oracle@powerlong5 admin]$ rman target sys/syspl1758@pdunq_dg auxiliary / 
RMAN> run {
allocate auxiliary channel c1 device type disk;
allocate auxiliary channel c2 device type disk;
duplicate target database for standby nofilenamecheck dorecover;
release channel c1;
release channel c2;
}


4.3,关闭oracle
shutdown immediate
启动数据库
startup nomount;
alter database mount standby database;
alter database add standby logfile;
alter database add standby logfile;
alter database add standby logfile;
alter database recover managed standby database using current logfile disconnect from session;


4.4,primary、standby上验证redo日志应用状态
archive log list;
standby库上异常如下所示:
SQL> archive log list;
Database log mode       Archive Mode
Automatic archival       Enabled
Archive destination       USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     0
Next log sequence to archive   0
Current log sequence       0
SQL>
redo日志没有被传输过来


4.5,查看归档参数,重新设置下:
alter system set log_archive_dest_2=‘SERVICE=pdunq_dg  lgwr sync affirm VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=pdunq_dg‘;
select open_mode , database_role from v$database;


然后再去看primary上的alert日志,有如下信息:
***********************************************************************


Fatal NI connect error 12514, connecting to:
 (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.121.218)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=pdunq_dg)(CID=(PROGRAM=oracle)(HOST=powerlong4)(USER=oracle))))


  VERSION INFORMATION:
TNS for Linux: Version 11.2.0.1.0 - Production
TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.1.0 - Production
  Time: 10-FEB-2015 16:11:34
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12564
    
TNS-12564: TNS:connection refused
    ns secondary err code: 0
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0
Error 12514 received logging on to the standby
Errors in file /oracle/app/oracle/diag/rdbms/pdunq/powerdes/trace/powerdes_arc3_6627.trc:
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
PING[ARC3]: Heartbeat failed to connect to standby ‘pdunq_dg‘. Error is 12514.


4.6,去check standby库 ,查看name状况,发现db_unique_name没有设置对,如下所示
SQL> show parameter name;


NAME     TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert     string /home/oradata/powerdes, /home/
oradata/powerdes
db_name     string powerdes
db_unique_name     string pdunq
global_names     boolean FALSE
instance_name     string powerdes
lock_name_space     string
log_file_name_convert     string /home/oradata/powerdes, /home/
oradata/powerdes
service_names     string pdtest
SQL> 
standby库的db_unique_name不对,需要修改。


4.7,去standby库上修改spfile参数
SQL> create pfile from spfile;
SQL> shutdown immediate;
[oracle@powerlong5 dbs]$ cp $ORACLE_HOME/dbs/initpowerdes.ora $ORACLE_HOME/dbs/initpowerdes.ora.bak
[oracle@powerlong5 dbs]$ vim $ORACLE_HOME/dbs/initpowerdes.ora
*.db_unique_name=‘pdunq_dg‘
SQL> create spfile from pfile;
SQL> startup mount;


4.8,再check standby归档情况,正常,如下所示:
SQL> archive log list;
Database log mode       Archive Mode
Automatic archival       Enabled
Archive destination       USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     31
Next log sequence to archive   0
Current log sequence       32
SQL> 
check下primary归档情况,如下所示:
SQL> archive log list;
Database log mode       Archive Mode
Automatic archival       Enabled
Archive destination       USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     30
Next log sequence to archive   32
Current log sequence       32
SQL> 


OK,现在可以将standby库open起来


5,打开数据库,启动redo应用
alter database open;
启动redo 应用
alter database recover managed standby database using current logfile disconnect ; 


primary库做alter system switch logfile;操作,检查standby是否有新的日志。
primary库:
SQL> alter system switch logfile;


System altered.


SQL> archive log list;
Database log mode       Archive Mode
Automatic archival       Enabled
Archive destination       USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     31
Next log sequence to archive   33
Current log sequence       33
SQL> 

standby库:
SQL> archive log list;
Database log mode       Archive Mode
Automatic archival       Enabled
Archive destination       USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     32
Next log sequence to archive   0
Current log sequence       33
SQL> 


ok,归档日志及时传递到standby库,failover后新的standby的重建工作顺利完成。
 ----------------------------------------------------------------------------------------------------------------
<版权所有,允许转载,但必须以链接方式注明源地址,否则追究法律责任!>
原博客地址:        http://blog.itpub.net/26230597/viewspace-1433720/
原作者:黄杉 (mchdba)
----------------------------------------------------------------------------------------------------------------

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。