Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1103361
  • 博文数量: 350
  • 博客积分: 10
  • 博客等级: 民兵
  • 技术积分: 5668
  • 用 户 组: 普通用户
  • 注册时间: 2011-03-23 17:53
文章分类

全部博文(350)

文章存档

2013年(350)

分类: Oracle

2013-04-27 17:05:51

2、配置节点归档间归档文件的自动发送

  首先要明确一点,通过RMAN创建集时,必须保证连接到的实例能够访问所有节点所生成的归档日志,否则会导致备份失败(除非不备份归档文件)。 对于单实例当然不存在这样的问题,因为单实例的归档通常是放在本地,必然能够访问(废话,不能访问的话怎么写进去的),不过对于多实例的RAC数据库这就可能会成为一个问题, 如何保证RMAN能够访问到所有节点生成的归档文件呢 ?两种方案:

  • 各节点生成的归档放到共享存储上,这样自然可以确保每个节点都能够访问到,比如将归档存放到的ASM,或者是第三方提供的集群文件系统中;
  • 各节点除在本地生成归档文件外,另外向其它节点或者说执行备份的节点发送归档日志,以确保执行备份的那台节点能够访问到所有的归档文件。

  从RMAN易用的角度来说,将归档放置于共享存储上无疑是最方便的,不过第三方集群件的配置又会带来一些其它额外的成本;ASM倒是简单,但是三思的个人看法是这样,ASM确实好用效率也不错,不过由于ASM对DBA来说就像个黑匣子(起码版本是这样,当然也有可能是俺研究的还不够深入),使用上了之后就得求天保佑千万不要出现问题,一旦出现问题很有可能都不知该从何处着手处理。因此,这里三思决定采用另外的方案。

  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_ l og 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

  那么再接下来呢...........................

 

 

 

 

 

 

 

  下面没有了~~

  今天先到这儿,明天同一时间同一地点,请大家继续关注!


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