欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

关于Oracle Data Guard Failover 的实例说明

程序员文章站 2022-03-08 22:50:10
failover是失败切换。这种情况下切换对redo的处理,就显的很重要。如果处理好,就不会有数据丢失。否则就会有数据丢失。 在oracle 11g里,data guard切换多了一个新的功能:fl...

failover是失败切换。这种情况下切换对redo的处理,就显的很重要。如果处理好,就不会有数据丢失。否则就会有数据丢失。

oracle 11g里,data guard切换多了一个新的功能:flush redo。

flush能把没有发送的redo从主库传送到standby库。只要主库能启动到mount状态,那么flush就可以把没有发送的归档和current online redo发送到备库。

flush语法:

sql> alter system flush redo to target_db_name;

这里的target_db_name是我们在主库的db_unique_name名称。也就是在tnsnames.ora文件配置的。flush会将未发送的redo从主库传到备库,并且等待redo在standby库上apply之后返回成功。所以只要flush成功,那么failover就没有主句丢失。

如果说我们的primary已经不能启动到mount状态,那么就只能按照之前的方法来。oracle 10g下就是这么操作的。

一.正常的failover

1.1检查gap

sql> select thread#, low_sequence#, high_sequence# from v$archive_gap;

如果有,将对应的归档文件copy到备库,在注册它

sql>alter database register physical logfile 'filespec1';

注意:如果有gap存在,并且没有解决。那么是不能正常的进行一个failover。只能进行一个强制的failover。这种情况下会有数据丢失。

sql> alter database activate physical standby database;

1.2解决gap问题后,进行切换

1.2.1取消apply

sql> recover managed standby database cancel;

1.2.2结束apply

(1)在oracle 10gr2或之后的版本:如果在备用库上有备用库日志文件

sql> alter database recover managed standby database finish; -- [force|wait|nowait]

在执行这个命令的时候,如果主库和备库之间的网络中断了。那么备库的rfs进程就会等待网络的连接,直到tcp超时。因此在这种情况下,我们就需要加上foce关键字。

(2)在oracle 10gr2之前的版本:没有备库日志文件

sql> alter database recover managed standby database finish skip standby logfile;

注意:如果执行了这条命令,就不能在进行recover standby database;

1.2.3将备库切换成主库

sql> alter database commit to switchover to primary;

sql> shutdown immediate;

sql> startup

二.强行切换(激活)

2.1使用条件

当我们正常切换的时候,提示我们需要介质恢复的时候,就需要使用强行激活standby库。如:

sql> alter database commit to switchover to primary;

alter database commit to switchover to primary

*

error at line 1:

ora-16139: media recovery required

2.2强行激活下的redo问题

在这里需要说明一点,就是我们在主库commit之后,然后shutdown abort,这时候,主库的online redo会自动的写入备库的最后一个归档文件里(大小会发生变化)。我们在恢复的时候需要对备库的最后一个归档文件进行重新的注册。

sql>alter database register physical logfile 'filespec1';

如果说,主库os是整个宕机了。这个时候,online redo是不会发送到备库。所以我们需要手工的将主库的所有online redo copy到备库。然后进行recover。

步骤如下:

sql>alter database recover managed standby database cancel;

database altered.

sql>recover standby database until cancel;

ora-00279: change 509016 generated at 11/05/2010 11:40:27 needed for thread 1

ora-00289: suggestion : /u01/archive/1_17_734225750.dbf

ora-00280: change 509016 for thread 1 is in sequence #17

--默认情况下会提示需要归档17,实际上这个序列为17的归档还没有生成,我们忽略它,使用我们刚才copy过来的redo日志来恢复。

specify log: {=suggested | filename | auto | cancel}

/u01/app/oracle/oradata/orcl/redo01.log--注意,这个位置是我手动写的

log applied.

media recovery complete.

这里一次就搞定了。实际上有三个redo,如果不确定使用哪个redo的,只能一个一个试。

当我们使用了recover standby database until cancel之后,只能使用强制激活备库,如果使用正常模式,会提示我们需要:

ora-16139: media recovery required

2.3强制激活备库:

sql> alter database recover managed standby database cancel;
sql> recover standby database until cancel;

sql>alter database activate standby database;
sql>shutdown immediate;

sql>startup

三.switchover

3.1主库操作:

(1)查看状态:

sql>select switchover_status from v$database;

(2)切换

sql> alter database commit to switchover to physical standby with session shutdown;

sql> shutdown immediate;

sql> startup;

sql> alter database mount standby database;

sql> recover managed standby database disconnect;

3.2备库操作:

sql> alter database commit to switchover to primary with session shutdown;

sql> shutdown immediate

sql> startup

四.对failover过程的研究

4.1 failover日志

thu mar 17 15:01:47 2011

alter database activate standby database

thu mar 17 15:01:47 2011

alter database activate [physical] standby database (dave)

--我们切换的时候,命令写全命令,db自动补全了

resetlogs after complete recovery through change 1255060

resetting resetlogs activation id 808909668 (0x3036fb64)

-- resetlogs了.这就以为着产生一个新的incarnation。online redo会被清空

online log /u01/app/oracle/oradata/dave/redo01.log: thread 1 group 1 was previously cleared

online log /u01/app/oracle/oradata/dave/redo02.log: thread 1 group 2 was previously cleared

online log /u01/app/oracle/oradata/dave/redo03.log: thread 1 group 3 was previously cleared

standby became primary scn: 1255058

thu mar 17 15:01:48 2011

setting recovery target incarnation to 3

--修改incarnation版本

thu mar 17 15:01:48 2011

converting standby mount to primary mount.

--将standby转成primary

thu mar 17 15:01:48 2011

activate standby: complete - database mounted as primary (dave)

completed: alter database activate standby database

--完成active

thu mar 17 15:01:59 2011

shutting down instance: further logons disabled

--关闭实例

thu mar 17 15:01:59 2011

stopping background process cjq0

thu mar 17 15:01:59 2011

stopping background process mmnl

thu mar 17 15:01:59 2011

stopping background process mmon

thu mar 17 15:01:59 2011

shutting down instance (immediate)

license high water mark = 7

thu mar 17 15:01:59 2011

stopping job queue slave processes, flags = 7

thu mar 17 15:01:59 2011

job queue slave processes stopped

all dispatchers and shared servers shutdown

thu mar 17 15:02:35 2011

arc1: archival disabled due to shutdown: 1089

shutting down archive processes

archiving is disabled

thu mar 17 15:02:45 2011

arch shutting down

arc0: archival stopped

thu mar 17 15:02:50 2011

arch shutting down

arc1: archival stopped

thu mar 17 15:07:04 2011

shutdown: active processes prevent shutdown operation

thu mar 17 15:07:50 2011

alter database close normal

thu mar 17 15:07:50 2011

ora-1109 signalled during: alter database close normal...

thu mar 17 15:07:50 2011

alter database dismount

completed: alter database dismount

arch: archival disabled due to shutdown: 1089

shutting down archive processes

archiving is disabled

archive process shutdown avoided: 0 active

arch: archival disabled due to shutdown: 1089

shutting down archive processes

archiving is disabled

archive process shutdown avoided: 0 active

thu mar 17 15:08:13 2011

starting oracle instance (normal)

--开始重新启动实例

license_max_session = 0

license_sessions_warning = 0

picked latch-free scn scheme 2

autotune of undo retention is turned on.

imode=br

ilat =18

license_max_users = 0

sys auditing is disabled

ksdpec: called for event 13740 prior to event group initialization

starting up oracle rdbms version: 10.2.0.4.0.

system parameters with non-default values:

processes= 150

__shared_pool_size= 113246208

__large_pool_size= 4194304

__java_pool_size= 25165824

__streams_pool_size= 0

nls_territory= america

sga_target= 247463936

control_files= /u01/app/oracle/oradata/dave/control01.ctl, /u01/app/oracle/oradata/dave/control02.ctl, /u01/app/oracle/oradata/dave/control03.ctl

db_block_size= 8192

__db_cache_size= 100663296

compatible= 10.2.0.1.0

log_archive_config= dg_config=(dave_pd,dave_st)

log_archive_dest_1= location=/u01/archivelog valid_for=(all_logfiles,all_roles) db_unique_name=dave_st

log_archive_dest_2= service=dave_pd reopen=120 lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=dave_pd

log_archive_dest_state_1 = enable

log_archive_dest_state_2 = enable

standby_archive_dest= /u01/archivelog

fal_client= dave_st

fal_server= dave_pd

db_file_multiblock_read_count= 16

standby_file_management= auto

undo_management= auto

undo_tablespace= undotbs1

remote_login_passwordfile= exclusive

db_domain=

dispatchers= (protocol=tcp) (service=davexdb)

job_queue_processes= 10

background_dump_dest= /u01/app/oracle/admin/dave/bdump

user_dump_dest= /u01/app/oracle/admin/dave/udump

core_dump_dest= /u01/app/oracle/admin/dave/cdump

audit_file_dest= /u01/app/oracle/admin/dave/adump

db_name= dave

db_unique_name= dave_st

open_cursors= 300

pga_aggregate_target= 81788928

pmon started with pid=2, os id=5909

psp0 started with pid=3, os id=5911

mman started with pid=4, os id=5913

dbw0 started with pid=5, os id=5915

lgwr started with pid=6, os id=5917

ckpt started with pid=7, os id=5919

smon started with pid=8, os id=5921

reco started with pid=9, os id=5923

cjq0 started with pid=10, os id=5925

mmon started with pid=11, os id=5927

thu mar 17 15:08:14 2011

starting up 1 dispatcher(s) for network address '(address=(partial=yes)(protocol=tcp))'...

mmnl started with pid=12, os id=5929

thu mar 17 15:08:14 2011

starting up 1 shared server(s) ...

thu mar 17 15:08:15 2011

alter databasemount

thu mar 17 15:08:19 2011

setting recovery target incarnation to 3

thu mar 17 15:08:19 2011

successful mount of redo thread 1, with mount id 808884895

thu mar 17 15:08:19 2011

database mounted in exclusive mode

completed: alter databasemount

thu mar 17 15:08:19 2011

alter database open

thu mar 17 15:08:19 2011

assigning activation id 808884895 (0x30369a9f)

lgwr: starting arch processes

arc0 started with pid=16, os id=5937

thu mar 17 15:08:19 2011

arc0: archival started

arc1: archival started

lgwr: starting arch processes complete

arc1 started with pid=17, os id=5939

lns1 started with pid=18, os id=5941

thu mar 17 15:08:22 2011

thread 1 advanced to log sequence 2 (thread open)

thu mar 17 15:08:23 2011

arc0: starting arch processes

thu mar 17 15:08:23 2011

arc1: becoming the 'no fal' arch

arc1: becoming the 'no srl' arch

thu mar 17 15:08:23 2011

thread 1 opened at log sequence 2

current log# 2 seq# 2 mem# 0: /u01/app/oracle/oradata/dave/redo02.log

successful open of redo thread 1

thu mar 17 15:08:23 2011

******************************************************************

lgwr: setting 'active' archival for destination log_archive_dest_2

******************************************************************

thu mar 17 15:08:23 2011

arc1: lgwr is actively archiving destination log_archive_dest_2

thu mar 17 15:08:23 2011

arc2: archival started

arc0: starting arch processes complete

arc0: becoming the heartbeat arch

arc2 started with pid=19, os id=5943

thu mar 17 15:08:23 2011

mttr advisory is disabled because fast_start_mttr_target is not set

thu mar 17 15:08:23 2011

smon: enabling cache recovery

thu mar 17 15:08:24 2011

successfully onlined undo tablespace 1.

dictionary check beginning

dictionary check complete

thu mar 17 15:08:24 2011

smon: enabling tx recovery

thu mar 17 15:08:24 2011

database characterset is zhs16gbk

opening with internal resource manager plan

where numa pg = 1, cpus = 1

replication_dependency_tracking turned off (no async multimaster replication found)

starting background process qmnc

qmnc started with pid=20, os id=5945

thu mar 17 15:08:26 2011

logstdby: validating controlfile with logical metadata

thu mar 17 15:08:26 2011

logstdby: validation complete

completed: alter database open

4.2对failover的补充说明

在4.1中看了failover的整个过程,db会进行一次resetlogs。这个是个很有意思的过程。

(1)resetlogs会产生一个新的incarnation。这个会影响我们的rman恢复。我们查看一下:

rman> list incarnation;

list of database incarnations

db keyinc key db namedb idstatusreset scnreset time

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

11dave808637274parent130-jun-05

22dave808637274parent44607514-mar-11

33dave808637274current 125506117-mar-11

这个时候,我们只能恢复incarnation为3之内的信息,如果要恢复到其他版本的信息,要保证对应备份集存在的同时,在使用reset database incarnation to 3或者其他的版本。之后在恢复。

(2)看下归档日志

先看备库:

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

max(sequence#)

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

6

sql> select sequence#,applied from v$archived_log;

sequence# app

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

3 yes

2 yes

5 yes

4 yes

6 yes

这个是重新开始的,没有什么问题。

我们看下主库:

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

max(sequence#)

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

88

sql> select sequence#,applied from v$archived_log;

sequence# app

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

4 yes

3 yes

5 yes

6 yes

7 yes

8 yes

......

82 yes

83 yes

84 yes

85 yes

86 yes

87 yes

88 yes

2 no

2 yes--注意这部分,有重新开始了。

3 no

3 yes

4 no

5 no

5 yes

4 yes

6 no

6 yes

因为resetlogs会重置sequence#。将其设置为1.所以这里又重新开始了。但是scn不会重置。我们查看一下:

sql> select sequence#,first_change#,next_change# from v$log_history;

sequence# first_change# next_change#

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

1446075451208

2451208483347

3483347485272

4485272485277

5485277486119

.....

8312276671229252

8412292521252272

8512522721252277

8612522771252293

8712522931252294

8812522941253301

112550611255062

--sequence#重新开始了,但是scn还是继续增加的。

212550621257639

312576391257644

412576441265602

512656021265607

612656071265913

94 rows selected.

sql>

所以,这种情况下,查看同步情况还是有点不直观。但是v$log_history和v$archived_log显示的log历史信息是从控制文件中取得的,所以说,如果要删除以前的记录,只有重建控制文件了。

(3)重建控制文件

sql> shutdown immediate

sql> startup nomount;

sql>create controlfile reuse database davenoresetlogsarchivelog

logfile

group 1 '/u01/app/oracle/oradata/dave/redo01.log',

group 2 '/u01/app/oracle/oradata/dave/redo02.log',

group 3 '/u01/app/oracle/oradata/dave/redo03.log'

datafile

'/u01/app/oracle/oradata/dave/sysaux01.dbf',

'/u01/app/oracle/oradata/dave/system01.dbf',

'/u01/app/oracle/oradata/dave/undotbs01.dbf',

'/u01/app/oracle/oradata/dave/users01.dbf'

character set zhs16gbk;

--注意,使用的是noresetlogs,如果使用resetlogs,dg就需要重新搭建了。

sql> alter tablespace temp add tempfile '/u01/app/oracle/oradata/dave/temp01.dbf' size 100m;

tablespace altered.

--添加临时表空间,在重建控制文件的时候,不能添加temp表空间,只能在控制文件重建好之后,在添加temp表空间。

更多信息参考:

oracle控制文件

https://www.cndba.cn/dave/article/1216

(4)在次验证归档信息

主库:

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

max(sequence#)

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

9

sql> alter system switch logfile;

system altered.

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

max(sequence#)

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

10

sql> select sequence#,applied from v$archived_log;

sequence# app

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

8 no

7 no

9 no

9 yes

10 yes

10 no

6 rows selected.

sql> select sequence#,first_change#,next_change# from v$log_history;

sequence# first_change# next_change#

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

912678281268212

1012682121274690

从这个结果来看,重建控制文件之后,之前的所有的有关归档的信息都会被删除。

备库:

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

max(sequence#)

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

10

sql> select sequence#,applied from v$archived_log;

sequence# app

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

3 yes

2 yes

5 yes

4 yes

6 yes

7 yes

8 yes

9 yes

10 yes

9 rows selected.

说明:

我这里是测试环境,所以重建控制文件测试一下,如果是生产环境,小心操作。