Chinaunix首页 | 论坛 | 博客
  • 博客访问: 213143
  • 博文数量: 70
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 735
  • 用 户 组: 普通用户
  • 注册时间: 2014-10-25 13:37
个人简介

对我认真的人,我会加倍珍惜

文章分类

全部博文(70)

文章存档

2016年(1)

2015年(15)

2014年(54)

分类: Oracle

2014-12-05 10:51:54

首先要明确一点,通过RMAN 创建备份集时,必须保证连接到的实例能够访问所有节
点所生成的归档日志,否则会导致备份失败(除非不备份归档文件)。对于单实例当然不存在
这样的问题,因为单实例数据库的归档通常是放在本地,必然能够访问(废话,不能访问的
话怎么写进去的),不过对于多实例的RAC 数据库这就可能会成为一个问题,如何保证
RMAN 能够访问到所有节点生成的归档文件呢?两种方案:
???? 各节点生成的归档放到共享存储上,这样自然可以确保每个节点都能够访问
到,比如将归档存放到ORACLE 的ASM,或者是第三方提供的集群文件系统中;
???? 各节点除在本地生成归档文件外,另外向其它节点或者说执行备份的节点发送
归档日志,以确保执行备份的那台节点能够访问到所有的归档文件。
从RMAN 易用的角度来说,将归档放置于共享存储上无疑是最方便的,不过第三方集
群件的配置又会带来一些其它额外的管理成本;ASM 倒是简单,但是三思的个人看法是这
样,ASM 确实好用效率也不错,不过由于ASM 对DBA 来说就像个黑匣子(起码10g 版本是
这样,当然也有可能是俺研究的还不够深入),使用上了之后就得求天保佑千万不要出现问
题,一旦出现问题很有可能都不知该从何处着手处理。因此,这里三思决定采用另外的方案。
ORACLE 的重做日志发送机制非常灵活,在10g 版本中可以同时向10 个目标地写入归
档(11g 增加到了30 个),这里三思准备利用这种特性,将各节点生成的归档发送到执行备份
的节点中,来实现该节点能够访问所需的归档文件。
操作非常简单,其实上就是给LOG_ARCHIVE_DEST_n 初始化参数设置适当的值,例
如当下的测试环境中,三思经过慎重考虑,决定将备份操作放在节点2 端执行,因此,只需
要在节点1 中,设置发送节点1 生成的归档文件到节点2 即可,操作如下:
JSSDBN1> alter system set log_archive_dest_2='service=jssdbn2' sid='jssdbn1';
System altered.
命令中设置的jssdbn2 是指tnsnames.ora 文件中配置的连接节点2 的网络服务名(好绕
口),除此之外呢,还有一个初始化参数LOG_ARCHIVE_LOCAL_FIRST,用来设置是否首
先归档文件到本地,默认为true,将其改为false,同样只修改节点1 的设置即可,操作如下:
JSSDBN1> alter system set log_archive_local_first=false sid='jssdbn1';
System altered.
测试一下效果,尝试手动触发归档操作,然后查看是否成功归档至各节点的适当位置:
JSSDBN1> alter system switch logfile;
System altered.
JSSDBN1> select inst_id,recid,dest_id,name from gv$archived_log where sequence#=219;
INST_ID RECID DEST_ID NAME
---------- ----- ------- ------------------------------------------------------------
1 8 2 /data/oradata/jssdbn2/archivelog/1_219_703671669.dbf
1 9 1 /data/oradata/jssdbn1/archivelog/1_219_703671669.dbf
2 8 2 /data/oradata/jssdbn2/archivelog/1_219_703671669.dbf
2 9 1 /data/oradata/jssdbn1/archivelog/1_219_703671669.dbf
归档文件成功生成并发送到节点2 端!
提示:
RAC 数据库各实例拥有各自的REDO 线程,因此还需要考虑各节点生成的归档文件名
称规则的问题,不要因为文件名生成规则不合适造成文件名重复,导致归档失败。归档文件
名的生成规则由LOG_ARCHIVE_FORMAT 初始化参数控制, 还好默认情况下是
%t_%s_%r.dbf(具体%符所代表意义就不说了,可以参考之前三思笔记系列文章),不会导致
重复的发生。
下面我们来考虑一个问题~~~
问:丢失了几个归档怎么办?
答:简单,凉拌,噢对不起说错了,是冷复制。
比如说由于山崩地裂洪水海啸等等这些最近几年我们耳熟能详的事件原因导致节点1
的某几个归档没能成功发送至节点2,结果节点2 执行备份时报错(一般是提示找不到归档
文件),那么手工复制缺少的几个归档到节点2 的适当路径下就好了,用什么复制呢?方式
很多,如果文件数目不多的话,直接用scp 命令吧,比如说这里我们复制seq 为218 的归档
文件到节点2,操作如下。
首先是找到要复制的文件详细路径,最简单的方式就是从v$archived_log 视图中查找:
JSSDBN1> select name from v$archived_log where sequence#=218;
NAME
------------------------------------------------------------
/data/oradata/jssdbn1/archivelog/1_218_703671669.dbf
接下来通过scp 命令来复制文件,scp 可以在任意节点上操作,语法也比较简单,就是
指明源路径和目标路径就好,例如:
[oracle@jssdbn1 ~]$ scp /data/oradata/jssdbn1/archivelog/1_218_703671669.dbf
jssdbn2:/data/oradata/jssdbn2/archivelog/1_218_703671669.dbf
1_218_703671669.dbf
100% 34MB 17.1MB/s 00:02
然后在节点2 注册该归档文件,操作如下:
JSSDBN2> alter database register physical logfile
'/data/oradata/jssdbn2/archivelog/1_218_703671669.dbf';
Database altered.
再次查询gv$archived_log,确定归档文件已被注册:
JSSDBN2> select inst_id,recid,dest_id,name from gv$archived_log where sequence#=218;
INST_ID RECID DEST_ID NAME
---------- ----- ------- ------------------------------------------------------------
2 7 1 /data/oradata/jssdbn1/archivelog/1_218_703671669.dbf
2 10 1 /data/oradata/jssdbn2/archivelog/1_218_703671669.dbf
1 7 1 /data/oradata/jssdbn1/archivelog/1_218_703671669.dbf
1 10 1 /data/oradata/jssdbn2/archivelog/1_218_703671669.dbf

阅读(1242) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~