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的重建工作顺利完成。