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，其它参数可以不变化，保持原状，如下所示：
[[email protected] 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
[[email protected] admin]$ rman target sys/[email protected]_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;
[[email protected] dbs]$ cp $ORACLE_HOME/dbs/initpowerdes.ora $ORACLE_HOME/dbs/initpowerdes.ora.bak
[[email protected] 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)
----------------------------------------------------------------------------------------------------------------

时间： 2024-10-19 21:58:57

ORACLE 11G DataGuard Failover后如何修复standby库的相关文章

Oracle 11G DataGuard ORA-16086问题修复详细过程

1,问题描述,standby从库没有应用redo日志Tue Jul 22 09:05:07 2014RFS[8852]: Assigned to RFS process 12956RFS[8852]: Identified database type as 'physical standby': Client is ARCH pid 16028Tue Jul 22 09:05:09 2014RFS[8853]: Assigned to RFS process 12958RFS[8853]: Id

Linux Oracle 11g dataguard物理standby 配置过程

这两天研究了下oracle 11g dataguard 物理standby 功能,总体来说这个功能满足公司需求,好了,不多说了,以下是详细的配置过程. 数据库的安装可以参考之前写的六步搞定Linux Oracle 11gR2 配置安装 注意:分别在主库和备库都安装上oracle软件,不装数据库. 主库: IP:192.168.77.5 主机名:nod1 ORACLE_SID=test ORACLE_BASE=/oracle/app/oracle ORACLE_HOME=/oracle/app/o

Oracle Study之案例--Oracle 11g DataGuard Snapshot Standby

Oracle Study之案例--Oracle 11g  DataGuard Snapshot Standby Oracle 11g的Data Guard不仅仅带给我们的是Active Data Guard实时查询特性,同时还带来了另外一个新特性,这便是Snapshot Standby数据库功能,此项功能可将备库置身于"可读写状态"用于不方便在生产环境主库中测试的内容,比如模拟上线测试等任务.当备库读写状态下任务完成后,可以非常轻松的完成Snapshot Standby数据库角色切换回

ORACLE 11G DataGuard的一些高级管理案例研究

搭建完了ORACLE 11G dataguard后,也做了角色切换的实验,有switchover已经failover,感觉受益颇多,而后继续研究了下dataguard的一些高级管理功能,所谓冰山一角,ORACLE果然博大精深,总结记录如下:1,ORACLE 11G dataguard的高级管理1.1.READ ONLY/WRITE模式打开物理STANDBY一般standby都是可以设置为mount状态的,于物理standby 可以有效分担primary 数据库压力,提升资源利用,实际上说的就是这

【转】Oracle 11g Dataguard 参数详解

转自:https://www.jb51.net/article/52269.htm 这篇文章主要介绍了Oracle 11g Dataguard参数详解,包含了独立参数.主库参数.备库参数的详细说明,需要的朋友可以参考下. 注:本文译自<Oracle Data Guard 11g Handbook> Page 78 – Page 88 就Data Guard(后面都写成DG)来说,我们只关注如下三种参数: 1.独立于数据库角色的参数2.数据库角色为primary时的参数3.数据库角色为stand

Oracle 11g dataguard三种模式以及实时查询（Real-time query）功能设置

之前我们讨论过<Linux Oracle 11g dataguard物理standby 配置过程>, 但是在实际过程中会遇到不同的问题,首先我们讨论下ORACLE DATAGUARD的三种模式, 保护最大化:这种模式的配置可以保证主库和备库的同步,任何情况下主库的损毁都不会导致已提交数据的丢失.如果主库和备库之间的网络出现问题,或者备库本身出现问题,都会导致主库停止数据处理. 可用最大化:这种模式和上面一种类似,也是会保证主库和备库的同步,区别在于,当网络或备库不可用时,主库仍然可以继续处理.

Oracle 11G DataGuard生产环境重新启动详细过程

场景,重启数据库,不重启linux系统,所以不用考虑监听程序,#linux输入lsnrctl start1 数据库关闭1.1 关闭主库SHUTDOWN IMMEDIATE; SQL> SHUTDOWN IMMEDIATE;                                                                                                                                          

Oracle 11g Dataguard 暂停物理备库的日志传输

Oracle 11g Dataguard 暂停物理备库的日志传输分类: Oracle2017-07-18 10:03:17这两天生产端的日志产生过多导致灾备端的归档日志目录满的现象,在清除灾备端的日志后发现log_archive_dest_2处于error状态,需要将其enable.在实际生产系统中,通常有这样的场景,例如在系统维护日,对主库进行大量的业务更新,会有大量的DML操作:为了避免主库中的业务更新对备库造成影响,可以暂停主库对备库的日志传输,这样的话,如果主库的更新出现问题,备库还保留

Oracle 11g安装GI后，运行roothas.pl脚本报错libcap.so.1找不到

环境:RHEL6.4 + Oracle 11.2.0.3问题:需求是文件系统迁移到ASM,在安装GI后,运行roothas.pl脚本报错 1.运行root.sh后,按提示运行roothas.pl报错: [[email protected] mnt]# /u01/app/11.2.0/grid/crs/install/roothas.pl Using configuration parameter file: /u01/app/11.2.0/grid/crs/install/crsconfig_p