菜单

RAC RMAN备份

2019年11月26日 - 计算机数据

最近在因归档日志暴增,使用delete archivelog
all貌似无法清除所有的归档日志,到底是什么原因呢? 1、演示环境 复制代码 代码如下: SQL> select * from
v$version where rownum<2; BANNER
—————————————————————- Oracle
Database 10g Release 10.2.0.3.0 – 64bit Production SQL> select
inst_id,instance_name from gv$instance; –>两节点RAC INST_ID
INSTANCE_NAME ———- —————- 1 GOBO4A 2 GOBO4B SQL>
show parameter db_recovery –>+REV,使用了ASM 存储方式 NAME TYPE
VALUE ———————————— ———– ————-
db_recovery_file_dest string +REV db_recovery_file_dest_size big
integer 1G SQL> select flashback_on from v$database;
–>数据库未开启闪回特性,也就是说尽管指定了闪回区,未启用闪回特性
–>相应的,归档日志充满整个闪回区时,闪回区空间并不会被重用
FLASHBACK_ON —————— NO 2、查看及清除现有的归档日志文件
复制代码 代码如下: oracle@bo2dbp:~>
export ORACLE_SID=+ASM1 oracle@bo2dbp:~> asmcmd ASMCMD> cd
+REV/GOBO4/ARCHIVELOG ASMCMD> ls 2012_10_08/ ….
arch_795194241_1_10.arc arch_795194241_1_100.arc ….
oracle@bo2dbp:~> export ORACLE_SID=GOBO4A oracle@bo2dbp:~> rman
target / Recovery Manager: Release 10.2.0.3.0 – Production on Thu Nov 29
16:23:15 2012 Copyright 1982, 2005, Oracle. All rights reserved.
connected to target database: GOBO4 #下面通过使用rman backup
archivelog方式来删除所有的归档日志文件 RMAN> backup format
‘/install_source/rman_bak/arch_%d_%U’ 2> archivelog all delete
input; Starting backup at 29-NOV-12 current log archived using target
database control file instead of recovery catalog allocated channel:
ORA_DISK_1 channel ORA_DISK_1: sid=1058 instance=GOBO4A devtype=DISK
channel ORA_DISK_1: starting archive log backupset channel
ORA_DISK_1: specifying archive log in backup set input archive log
thread=1 sequence=139 recid=214 stamp=797450261 input archive log
thread=1 sequence=140 recid=215 stamp=797450292 input archive log
thread=1 sequence=141 recid=216 stamp=797450308 input archive log
thread=1 sequence=142 recid=218 stamp=797450347 input archive log
thread=1 sequence=143 recid=219 stamp=797450372 input archive log
thread=1 sequence=144 recid=220 stamp=797450409 channel ORA_DISK_1:
starting piece 1 at 29-NOV-12 channel ORA_DISK_1: finished piece 1 at
29-NOV-12 piece
handle=/install_source/rman_bak/arch_GOBO4_1dnrhkn4_1_1
tag=TAG20121129T162806 comment=NONE channel ORA_DISK_1: backup set
complete, elapsed time: 00:02:15 channel ORA_DISK_1: deleting archive
log archive log
filename=+REV/gobo4/archivelog/arch_795194241_1_139.arc recid=214
stamp=797450261 archive log
filename=+REV/gobo4/archivelog/arch_795194241_1_140.arc recid=215
stamp=797450292 archive log
filename=+REV/gobo4/archivelog/arch_795194241_1_141.arc recid=216
stamp=797450308 …….. piece
handle=/install_source/rman_bak/arch_GOBO4_1hnrhli2_1_1
tag=TAG20121129T162806 comment=NONE channel ORA_DISK_1: backup set
complete, elapsed time: 00:00:09 channel ORA_DISK_1: deleting archive
log archive log
filename=+REV/gobo4/archivelog/arch_795194241_2_141.arc recid=427
stamp=800547491 archive log
filename=+REV/gobo4/archivelog/arch_795194241_2_142.arc recid=429
stamp=800549193 archive log
filename=+REV/gobo4/archivelog/arch_795194241_2_143.arc recid=433
stamp=800578944 archive log
filename=+REV/gobo4/archivelog/arch_795194241_2_144.arc recid=437
stamp=800641679 Finished backup at 29-NOV-12
#再次查看依然有很多归档日志文件存在,而且都是10月23日之前的 ASMCMD>
pwd +REV/GOBO4/ARCHIVELOG ASMCMD> ls 2012_09_30/ 2012_10_09/
2012_10_10/ 2012_10_11/ 2012_10_12/ 2012_10_13/ 2012_10_14/
2012_10_15/ 2012_10_16/ 2012_10_17/ 2012_10_18/ 2012_10_22/
2012_10_23/ arch_795194241_1_100.arc arch_795194241_1_101.arc
arch_795194241_1_102.arc …………
#再次删除日志文件,来个更狠的命令,直接delete所有的archivelog,最近新增的一个archivelog被删除
RMAN> delete noprompt archivelog all; released channel: ORA_DISK_1
allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=1081
instance=GOBO4A devtype=DISK List of Archived Log Copies Key Thrd Seq S
Low Time Name ——- —- ——- – ——— —- 453 1 294 A
29-NOV-12 +REV/gobo4/archivelog/arch_795194241_1_294.arc deleted
archive log archive log
filename=+REV/gobo4/archivelog/arch_795194241_1_294.arc recid=453
stamp=800662185 Deleted 1 objects #
上面输出的结果只有一个归档日志被删除,何以故? #
这个我们的分析一下delete noprompt archivelog all以及备份归档日志时使用的
delete input # 回顾一下Oracle控制文件以及Oracle
RMAN的的备份恢复的原理。 # 我们知道,Oracle
控制文件里边记录了数据库的名字,id,创建的时间戳….一大堆的信息,当然也有不可少的归档信息以及备份信息。
# 如果不知道控制文件有什么? 那就参考:Oracle
控制文件,文章尾部有给出链接。 # 其次,Oracle
RMAN的备份恢复的所有信息都依赖于两个东东,要么是控制文件,要么是恢复目录。
# 因为所有的备份与恢复信息都会依据备份是的方式存储到这两个位置。 #
理所当然的是,对这两个东东里的备份集,镜像副本,归档日志,等等所有能备份的对象的任意操作,首先会参考这些对象的记录的信息。
# 其次是当被记录的对象发生变化时做相应的更新。
3、深度分析无法清除的原因 复制代码
代码如下: #先来看看gv$archived_log,如果是单实例使用v$archived_log
#从下面的查询可知,又有两个新的归档日志产生,一个从第一个instance产生,一个从第二个instance产生。
SQL> select name,status,count from gv$archived_log group by
name,status; NAME S COUNT
————————————————– – ———- D 444
+REV/gobo4/archivelog/arch_795194241_1_295.arc A 2
+REV/gobo4/archivelog/arch_795194241_2_150.arc A 2 #
从上面的查询可知,当前的两个节点其归档日志只有2个,其余的444个其名字都是NULL值。
# 看看关于视图v$archived_log中NAME列的解释 # Archived log file name.
If set to NULL, either the log file was cleared before it was archived
or an RMAN backup command # with the “delete input” option was executed
to back up archivelog all (RMAN> backup archivelog all delete
input;). #
上面的这段话表明当前的这些日志文件要么被手动清除,要么被rman的delete
input选项清除。 #
其次status列的D字段也表明了这些个名字为空的归档日志已经被Deleted.也就是说有444个归档日志已经被删除了。
# 再次尝试删除归档日志,尾数为295和150的归档日志也被删除 RMAN>
delete noprompt archivelog all; released channel: ORA_DISK_1 allocated
channel: ORA_DISK_1 channel ORA_DISK_1: sid=1081 instance=GOBO4A
devtype=DISK List of Archived Log Copies Key Thrd Seq S Low Time Name
——- —- ——- – ——— —- 454 1 295 A 29-NOV-12
+REV/gobo4/archivelog/arch_795194241_1_295.arc 455 2 150 A 29-NOV-12
+REV/gobo4/archivelog/arch_795194241_2_150.arc deleted archive log
archive log filename=+REV/gobo4/archivelog/arch_795194241_1_295.arc
recid=454 stamp=800712037 deleted archive log archive log
filename=+REV/gobo4/archivelog/arch_795194241_2_150.arc recid=455
stamp=800712038 Deleted 2 objects #
查询gv$archived_log视图,表明所有现有的archivelog都已经被删除 SQL>
select name,status,count from gv$archived_log group by name,status;
NAME S COUNT ————————————————– –
———- D 448 # 在asmcmd命令下也无法找到我们刚刚删除的归档日志文件
ASMCMD> pwd +REV/GOBO4/ARCHIVELOG ASMCMD> ls -l
arch_795194241_1_295.arc asmcmd: entry ‘arch_795194241_1_295.arc’
does not exist in directory ‘+REV/GOBO4/ARCHIVELOG/’ ASMCMD> ls -l
arch_795194241_2_150.arc asmcmd: entry ‘arch_795194241_2_150.arc’
does not exist in directory ‘+REV/GOBO4/ARCHIVELOG/’ #
在A节点上再次切换一次 SQL> alter system switch logfile; System
altered. SQL> select inst_id,name,count from gv$archived_log group
by inst_id,name; INST_ID NAME COUNT ———-
————————————————– ———- 2 223 1
+REV/gobo4/archivelog/arch_795194241_1_296.arc 1 2
+REV/gobo4/archivelog/arch_795194241_1_296.arc 1 1 223
–上面的查询可以看到当前的一个归档日志arch_795194241_1_296.arc基于Inst_id为1的有1个,而基于Inst_id为2的也有一个
–而直接查询v$archived_log时只有1个当前的归档日志,实际上arch_795194241_1_296.arc文件是由第一个instance产生的。
–数字296之前的1即可以表明为第一个instance产生的。 SQL> select name
from v$archived_log where

这篇主要介绍的是RAC 环境下的RMAN 备份。 关于Oracle
备份与恢复的一些理论知识参考我的Blog:

name=’+REV/gobo4/archivelog/arch_795194241_1_296.arc’; NAME

+REV/gobo4/archivelog/arch_795194241_1_296.arc #
关于这个地方个人认为这个应该是用于做恢复时用的。 #
RAC数据库在恢复时,无论多个少节点,只有所有的归档日志的集合才能完成地表述数据库的变迁。
#
此时,无论从哪个节点上看,或者说做无论从哪个节点恢复,都可以看到该归档日志。
# 而具体是哪个instance产生则由’%t’重做线程编号来判断。
#下面再来看看控制文件 SQL> select * from
gv$controlfile_record_section where type=’ARCHIVED LOG’; INST_ID TYPE
RECORD_SIZE RECORDS_TOTAL RECORDS_USED FIRST_INDEX LAST_INDEX
LAST_RECID ———- —————————- ———–
————- ———— ———– ———- ———- 1 ARCHIVED
LOG 584 224 224 149 148 456 2 ARCHIVED LOG 584 224 224 149 148 456 #
RECORDS_TOTAL:Number of records allocated for the section #
列RECORDS_TOTAL表明为当前TYPE分配的可存储的总数,在两个instance上都为224条
#
从最近一次切换日志的查询结果可知,被删除的有223条,新增的一条为arch_795194241_1_296.arc,总条数为224条。
#
如果下次日志切换再增加一条往哪里放呢?那些已经超出缺省保留期的归档日志被覆盖,即被重用。
# 用户在控制文件中保存ARCHIVED
LOG部分的保留时间由谁来决定呢,参数control_file_record_keep_time,缺省为7天
# 这意味着7天前的归档日志和备份信息可能在控制文件中已经不存在了 SQL>
show parameter control_file_record_keep_time NAME TYPE VALUE


—————————— control_file_record_keep_time integer
7 SQL> select count from v$archived_log; COUNT ———- 224 #
Author : Robinson # Blog : SQL>
alter session set nls_date_format=’yyyymmdd hh24:mi:ss’; Session
altered. #
下面的查询正好表明为什么2012_10_23和之前的日志为什么没有被删除 #
因为20121023 18:04:53之后的归档日志已经被覆盖了,所以使用delete
archivelog all时是根本无法清除之前的日志的,无能为力阿。 #
对于rman下的delete archivelog
all方式不会删除控制文件中对应的归档日志信息,但在控制文件中设置delete状态,
# 即v$archived_log视图的status列为deleted SQL> select min , min ,
max , max from 2 v$archived_log; MIN MIN(COMPLETION_TI MAX
MAX(COMPLETION_TI —————– —————– —————–
—————– 20121023 18:03:12 20121023 18:04:53 20121130 12:00:26
20121130 12:14:51 SQL> select min , min , max , max from 2
gv$archived_log; MIN MIN(COMPLETION_TI MAX MAX(COMPLETION_TI


20121023 18:03:12 20121023 18:04:53 20121130 12:00:26 20121130 12:14:51
# 既然这般,如何是好啊? # 那就直接在asmcmd命令行下删除吧。一顿狂删 rm
-rf 2012_09_30/ #
莫急,莫急,一不小心删完了,我晕,ORA-00254/ORA-15173 Archive_log
Directory On Asm Being Deleted 在等候阿。 小结 a、delete archivelog
all将会毫无保留的删除所有的归档日志
b、归档日志的信息被记录在控制文件之中,其生存期和可保留的总数也受到控制文件创建初以及参数control_file_record_keep_time限制
c、对于那些已经在控制文件中被覆盖的归档日志,该方式不起作用,使用backup
archivelog all delete input同样不起作用 d、注意backup archivelog
all时delete input与delete all
input有些差异,前者删除仅仅被备份过的归档日志,而后者则对于多个归档位置下的所有归档日志全部删除。
e、视图v$archived_log或gv$archived_log提供了归档日志的相关详细信息
f、建议备份归档日志后再删除。注,RAC+ASM下切不可使得archivedlog文件夹为空,否则,整个文件夹连同上级空目录会被删除

 

      Oracle 备份 与 恢复 概述

      

 

 

一.     RAC 归档的设置

 

1.1  相关理论知识

RAC
在运行的时候,每个实例都会产生归档日志,所有实例的归档日志集中在一起,才能完整地代表数据库的操作历史,此外,只有进行介质恢复(Media
Recovery)时,才会用到归档日志。
进行介质恢复时,才要求在执行恢复操作的那个节点访问所有实例的归档日志。

 

正是因为归档日志有这些特点,所以归档位置的设计也有两种方案:

(1)各节点生成的归档放到共享存储上,这样自然可以确保每个节点都能够访问到,比如将归档存放到ORACLE的ASM,或者是第三方提供的集群文件系统中。
对于这种方法,一些集群的配置比较麻烦,而且也增加了ASM的维护,出现问题也不好处理。

(2)各节点除在本地生成归档文件外,另外向其它节点或者说执行备份的节点发送归档日志,以确保执行备份的那台节点能够访问到所有的归档文件。在这种方法中,因为ORACLE
的重做日志发送机制非常灵活,在10g版本中可以同时向10个目标地写入归档(11g增加到了30个),所以利用这种特性,将各节点生成的归档发送到执行备份的节点中,来实现该节点能够访问所需的归档文件。

 

在第二种方案中,我们可以在每个节点建2个归档目录,分别存放本地和其他节点节点的归档日志,这里假设是2个节点的RAC.

 

归档位置

实例1

实例2

本地磁盘

Mkdir /rac1_arch

Mkdir /rac2_arch

Mkdir /rac1_arch

Mkdir /rac2_arch

Log_archive_dest_1

Location=’/rac1_arch’

Location=’/rac2_arch’

Log_archive_dest_2

Service=’rac2’

Service=’rac1’

Standby_archive_dest

‘/rac2_arch’

‘/rac1_arch’

 

 

在每个节点上建2个目录: /u02/rac1_arch, /u02/rac2_arch,
并赋予读写的权限:

 

[root@rac2 /]# mkdir /u02/rac1_arch

[root@rac2 /]# mkdir /u02/rac2_arch

[root@rac2 /]# chown oracle:oinstall /u02/*

[root@rac2 /]# chmod 777 /u02/*

 

      

1.2  RAC 设置成归档模式

       RAC的归档设置和单实例归档设置差不多。
先将所有实例设置为非OPEN状态,然后在任意一个处于MOUNT状态的实例执行ALTER
DATABASE命令,操作成功后,再正常启动其它实例即可。

 

之前整理的一篇RAC
归档切换的文档,不过和今天这个实验不太匹配,就重新在整理下。

Oracle RAC 归档 与 非归档 切换

 

 

 

1.2.1 设置归档参数

 

1.2.1.1 设置实例orcl1的参数:

 

SQL> alter system set log_archive_dest_1 =
‘LOCATION=/u02/rac1_arch’ scope=both sid=’orcl1′;

System altered.

 

SQL> alter system set log_archive_dest_2 = ‘service=orcl2′
scope=both sid=’orcl1’;

System altered.

 

SQL> alter system set standby_archive_dest = ‘/u02/rac2_arch’
scope=both sid=’orcl1′;

System altered.

 

1.2.1.2 设置实例orcl2的参数:

 

SQL> alter system set log_archive_dest_1 =
‘LOCATION=/u02/rac2_arch’ scope=both sid=’orcl2′;

System altered.

 

SQL> alter system set log_archive_dest_2= ‘SERVICE=orcl1′
scope=both sid=’orcl2’;

System altered.

 

SQL> alter system set standby_archive_dest = ‘/u02/rac1_arch’
scope=both sid=’orcl2′;

System altered.

 

 

 

1.2.1.3 在2个节点上分别验证参数的状态:

 

SQL> set wrap off

SQL> col dest_name format a20

SQL> select dest_name,status,error from v$archive_dest;

 

DEST_NAME            STATUS    ERROR



LOG_ARCHIVE_DEST_1   VALID

LOG_ARCHIVE_DEST_2   VALID

LOG_ARCHIVE_DEST_3   INACTIVE

LOG_ARCHIVE_DEST_4   INACTIVE

LOG_ARCHIVE_DEST_5   INACTIVE

LOG_ARCHIVE_DEST_6   INACTIVE

LOG_ARCHIVE_DEST_7   INACTIVE

LOG_ARCHIVE_DEST_8   INACTIVE

LOG_ARCHIVE_DEST_9   INACTIVE

LOG_ARCHIVE_DEST_10  INACTIVE

 

10 rows selected.

 

1.2.2 将RAC 切换成归档模式

 

1.2.2.1 修改数据库的归档模式

       SQL> alter system set cluster_database=false scope=spfile
sid=’*’;

System altered.

 

1.2.2.2 关闭所有实例

       SQL> shutdown immediate

 

 

1.2.2.3 在任意一个实例上将数据库启动到mount状态,修改数据库归档模式

SQL> startup mount

ORACLE instance started.

Total System Global Area  167772160 bytes

Fixed Size                  1266392 bytes

Variable Size             117443880 bytes

Database Buffers           46137344 bytes

Redo Buffers                2924544 bytes

Database mounted.

 

SQL> alter database archivelog;

Database altered.

 

SQL> alter system set cluster_database=true scope=spfile sid=’*’;

System altered.

 

         SQL> shutdown immediate

 

1.2.2.4 重启数据库,确定归档生效

 

SQL> archive log list;

Database log mode              Archive Mode

Automatic archival             Enabled

Archive destination            /u02/rac1_arch

Oldest online log sequence     54

Next log sequence to archive   55

Current log sequence           55

 

SQL> archive log list;

Database log mode              Archive Mode

Automatic archival             Enabled

Archive destination            /u02/rac2_arch

Oldest online log sequence     26

Next log sequence to archive   27

Current log sequence           27

 

 

1.2.2.5 在两个节点分别切换归档日志,并检查对应的目录是否产生归档日志

       SQL> alter system switch logfile;

System altered.

 

SQL> select inst_id,recid,dest_id,name from gv$archived_log ;

  INST_ID      RECID    DEST_ID NAME



         2         12          1 /u02/rac1_arch/1_5_730181171.dbf

         2         13          2 /u01/rac1_arch1_5_730181171.dbf

         2         14          2 /u02/rac2_arch/2_3_730181171.dbf

         2         15          1 /u02/rac1_arch/1_6_730181171.dbf

         2         16          2 /u02/rac1_arch/1_6_730181171.dbf

         2         17          1 /u02/rac1_arch/1_7_730181171.dbf

              ……

         1         12          1 /u02/rac1_arch/1_5_730181171.dbf

         1         13          2 /u01/rac1_arch1_5_730181171.dbf

         1         14          2 /u02/rac2_arch/2_3_730181171.dbf

         1         15          1 /u02/rac1_arch/1_6_730181171.dbf

         1         16          2 /u02/rac1_arch/1_6_730181171.dbf

 

 

提示:RAC
数据库各实例拥有各自的REDO线程,归档文件名的生成规则由LOG_ARCHIVE_FORMAT初始化参数控制,默认情况下是
%t_%s_%r.dbf ,所以不会导致重复的发生。

 

 

注意一个参数:LOG_ARCHIVE_LOCAL_FIRST,用来设置是否首先归档文件到本地,默认为true.

 

LOG_ARCHIVE_LOCAL_FIRST 这个参数是Oracle 10g
新增的,它主要针对Standby环境退出,在Oracle 10g
以前的Standby中,本地和远程的归档都完成后,联机日志文件才可以被重用,在网络速度慢的环境中,远程归档的配置会很大程度的影响节点的处理能力。而设置LOG_ARCHIVE_LOCAL_FIRST=true,Oracle
会先进行本地归档,本地归档结束后在进行远程传递,同时使联机日志可以重用,从而减少了网络环境对本地的影响。
如果把这个参数设置为FALSE, 则相当于Oracle 10g
之前的方式,这个参数默认是True,如果在应用中遇到找不到归档日志的问题,就可以把这个参数改成FALSE.

 

 

 

二、RAC数据库的RMAN备份

RAC 和 单实例数据库备份机制是一样的,有两点需要注意:

(1)       RMAN 要连接到集群中的某个实例,而不是连接到整个集群

(2)      
备份归档日志时,必须保证在备份实例上能够访问所有实例的归档日志,否则就会报错。

 

 

2.1 先看一个归档日志不一致的问题

       在这种情况下备份是会报错的。
之前启动归档之后,2个节点的归档目录文件是相同的,现在我们模拟归档日志不一致的情况。

 

先关闭两个节点的归档位置2。 此时归档日志都不能传递到对方的归档的目录下。

 

SQL> alter system set log_archive_dest_state_2 =defer scope=both 
sid=’*’;

System altered.

 

在手动档产生归档日志:

SQL> alter system switch logfile;

System altered.

 

此时两个节点归档目录下文件不一致。我们连接到rac1节点,然后用rman
备份一下,看报什么错

 

RMAN> backup database plus archivelog;

 

Starting backup at 20-SEP-10

current log archived

using channel ORA_DISK_1

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of backup plus archivelog command at 09/20/2010
14:13:32

RMAN-06059: expected archived log not found, lost of archived log
compromises recoverability

ORA-19625: error identifying file /u02/rac2_arch/2_11_730181171.dbf

ORA-27037: unable to obtain file status

Linux Error: 2: No such file or directory

Additional information: 3

 

这里报错了。 现在我们手动把缺失的日志从rac2节点copy到节点1.
然后启用归档位置2.

 

SQL> alter system set log_archive_dest_state_2 =enable
scope=both  sid=’*’;

System altered.

 

然后在备份一下看看。

 

 

RMAN> backup database plus archivelog;

 

Starting backup at 20-SEP-10

current log archived

using channel ORA_DISK_1

channel ORA_DISK_1: starting archive log backupset

channel ORA_DISK_1: specifying archive log(s) in backup set

input archive log thread=1 sequence=11 recid=29 stamp=730213616

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图