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

全部博文(350)

文章存档

2013年(350)

分类: Oracle

2013-04-10 13:29:58

涂抹ORACLE试阅章节:第8章-Rman说,我能

===========================================================================

8.8 制订备份策略

  作为一名严谨的DBA,必须在正式上线之前就考虑到,数据由于各种原因导致出错的可能。出现错误本身并不可怕,但如果没有对应的机制进行处理,那就有可能演变成灾难了,对于Oracle数据库来说,是否存在适当的备份,是能否最终修复数据的关键因素之一,因此,如何制订数据库的备份策略,就成了很多初学者最常提及的问题。

  有很多技术书籍在谈到策略之类话题时,往往是以非常全面、严肃的方式,详尽阐述涉及这一话题的方方面面,恨不得把前盖儿螺丝是否上紧都要扯进来漫谈一通。当然不能说人家介绍的方式不对,但是我想,对于真正的应用者来说,并不是所有的知识点都具有很大的意义,而且由于文字枯燥,看得云山雾罩,特别是初学者,可能看了几页也不知道究竟应该做什么以及怎么做。

  针对这一问题,在此我想换一种表达的方式。你想知道究竟需要什么样的备份策略,以及当前制订的备份策略是否合理?很简单,只需要回答几个问题就行了。

    提示:

    本小节阐述的内容仅从业务特点和Oracle自身应用的角度出发,不涉及硬件环境,如用户使用的存储设备、磁盘阵列类型、服务器配置及网络条件等方面话题。下列描述是建立在用户系统资源充配,存储空间充足的基础之上的。

1.备份的数据库有可能进行恢复吗

  如果答案为否,请响应国家号召,自觉进行至少7天以上隔离。开玩笑,数据库既然都不准备进行恢复操作,那还谈什么备份策略,甚至都不需要创建备份。

  如答案为是,那么请继续回答下一个问题。

提示:

  本题是让大家认识到,备份的目的就是为了恢复,所有为创建备份而进行的准备、设计的方案、创建的策略等都是为了满足恢复的需要。如果看到这里,你终于恍然大悟、豁然开朗,恭喜,你已经开窍了,后面的问题不过是提醒你认识到这一点,既然你已大 - 彻 - 大 - 悟,修 - 得 - 圆 - 满(注,一定要一个字一个字的读),为师已经没什么可以再教你的了,你就下山去吧。O,错了错了,俺是说本小节三思该说的都说了,你就看下一章去吧。

2.最早希望恢复到什么时间点

  对于某些业务类型,用户只关注数据库当前状态是否正常,至于数据曾经做过什么操作,什么时间做的并不重要;也有些业务类型可能会由于特殊的需求,希望看到之前曾经做过的操作,甚至要将数据库恢复到之前的某个时间点。这两种需求主要与备份的保留策略有关。对于前者,一般建议选择基于冗余数量的备份保留策略,如果只希望保证数据库稳定运行,那么可视数据规模的大小,适当保存几份最近的备份即可。例如,配置当前备份集的保留策略为保留最近的3份,执行语句如下:

    RMAN>  CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

    new RMAN configuration parameters:

    CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

    new RMAN configuration parameters are successfully stored

    提示:

    为什么要保存最近的几份,一份不就行了吗?

    俗话说得好,鸡蛋不要放到一个篮子里,备份本身就是在做冗余,那么从可靠的角度考虑,对于备份当然也要有冗余,至少要保证有两份备份嘛,这样即使由于某些原因损坏了一份,还能有个替补的。

  对于后者,如果希望能够看到之前曾经做过的操作,那么至少归档文件的保存时间需要适当的延长,因为在对用户所做的操作进行分析时,LogMiner是最为常用的工具,而LogMiner分析的正是目标数据库生成的归档文件。

  如果不仅要看到,还要能将数据恢复到之前的某个时间点,那么就必须要保证存在目标时间点(或之前)创建的备份,以及相关的归档文件。基于这类需求建议选择基于冗余时间的备份保留策略,备份的保留时间设置为最早恢复到的时间即可。例如,设置备份集至少保留7天,执行语句如下:

    RMAN>  CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

    old RMAN configuration parameters:

    CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

    new RMAN configuration parameters:

    CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

    new RMAN configuration parameters are successfully stored

  由于备份集也是要占用存储空间(往往还不小),因此基于时间的备份保留策略,必须要考虑到存储设备空闲空间的问题。

3.系统什么时间比较空闲

  由于系统需要涉及大量数据的读写,这期间必然会占用较多的系统资源,如果在数据库繁忙时段执行备份任务,那么不仅仅备份需要花费较长时间,还有可能对正常运行的业务系统造成影响。

  目前通常的做法都是将备份的任务放到凌晨时段执行,对于大多数业务,这个时间系统的访问量最少,当然DBA在设计备份任务执行时间时,还是要根据自身实际情况而定。

4.数据库的数据规模有多大

  三选一:超大(>1TB)、一般(<1TB and >200GB)、小(<200GB)。

  虽然前面说不考虑硬件因素,不过备份操作本身,考虑到执行效率的因素,想完全跳过硬件是不可能的,上述选项是建立在用户使用独立存储(或磁盘阵列的读写性能不低于100M/s)的基础上的。按照磁盘读写大概每秒百M的速率计算,200GB左右数据执行备份仅仅写操作需要半个小时左右(对应的恢复操作也差不多是这个时间,一般会更长,因此恢复时还需要应用重做日志),就备份操作来说,每天在系统不繁忙的时间分配几个小时专门执行,这个时间对于大多数应用都还可以接受。如果当前使用存储的性能很好,如读写效率超过百兆/秒,甚至能达到千兆/秒,或者可以接受更长的备份/恢复时间,那么数据规模稍大也可以,本例中列举的选项仅供参考。

  三个选项中,后两个选项可以每次都进行全备份,请接着看第6条,而对于第一个选项,也许增量备份更适合,请继续看第5个问题。

5.数据是否被频繁修改

  还是三选一:

  (1)是:每天数据量中都有超过10%以上的数据修改。

  (2)否:每天数据基本没变化,只偶尔有极少量修改。

  (3)一般:每天数据都在变,但量并不大。

  对于选项(1),基本上不建议使用增量备份,除非的数据库规模非常非常大。

  对于选项(2),强烈建议使用增量备份,除非管理的数据库规模非常非常小。

  对于选项(3) ,都行啊,建议根据数据库的规模,再结合问题3来定是否启用增量吧。

    提示1:选择增量备份的话,记得要启用块修改跟踪特性哟。

    提示2:增量备份也有两种不同类型,在处理增量数据时逻辑并不相同,详细请参考8.7.4小节。

    提示3:如果数据库中每天变化的数据量虽然很大,但基本上都只是系统中某个或某几个表空间的数据在变化,那么可以在制定备份策略时,只定期备份该表空间中的数据,其他的表空间以不那么频繁的周期创建备份。

6.能否预估可能给予的恢复操作时间

  一般情况下正常的系统不会执行恢复操作,当需要对数据库系统做恢复操作时就代表着系统中出现了问题,虽然说出现的问题可能是偶发性的,但处理问题所需要的时间有可能是确定的,比如数据量确定的情况下,恢复数据文件和应用日志的时间是可以估算出来的。

  对于某些核心的业务系统,任何无公告通知的短暂停止服务甚至都是灾难,那么这种情况下,一旦出现重大问题,仅依靠RMAN想做到快速恢复是不可能的(前面讨论过磁盘读写速率与数据库规模的关系),DBA需要通过其他途径确保系统的高可用性,而不能仅仅是依靠备份。

  而有些非核心的业务系统,可能每周甚至每个月只有某个时段需要用到(如员工薪资系统),对于这类数据库系统,由于其执行恢复的时间非常富裕,相对来说制订备份策略时也就可以更宽松。比如并不需要每天都创建备份,而仅在有数据修改发生时执行备份任务。

7 .是什么原因导致的错误

  所谓的恢复其实就是根据可能出现的问题制订的一个计划,出现什么样的问题采用什么样的方式处理,这中间还要兼顾恢复技术的可靠性及恢复的成本。

  • 用户误操作导致的错误。用户被动造成的也好,应用程序不严谨导致的也好,总之就是前面的操作导致数据不正确(或者误删了数据,或者更新了错误的数据),为了应付这种问题,Oracle自身提供了多种修复方式,包括:
    • 使用Flashback进行快速恢复。
    • 通过之前创建的备份,恢复到错误产生之前的时间点。
    • 逻辑导入正确的数据。
  • 介质操作导致的错误。如果是磁盘损坏(代表硬件),或是误删文件(代表人为)。如果是前者,能否联系厂商进行快速维修,对于大型数据库来说,有可能厂商修复硬件的时间会比执行恢复要快得多;如果是后者,首先检查是否有操作系统级的文件冗余(如联机重做日志文件、控制文件这类文件,Oracle自身都提供了冗余),如果有,则首推使用冗余的文件恢复,如果没有,再考虑使用备份的方式进行恢复。
  • 数据块损坏导致的错误。在这种情况下可以使用RMAN的备份进行块级的修复,效率高并且速度快。

  备份和恢复之间绝对不是各自孤立存在,恢复依赖于备份,备份策略基本上也就决定了恢复方式、能恢复的数据及恢复的效率等。因此备份策略的制订要视你的恢复需求,以及恢复策略而定(当然同时还受限于软硬件的实际情况)。

  在制订恢复策略时,根据假定可能遇到的那些问题,罗列出的能够帮助我们修复错误的解决方案(通常都不会只有一种选择),以及实际情况(在建立备份策略的时候需要具体问题具体分析,如操作系统的资源配置,数据库系统的运行要求等都会对备份策略产生重要影响),来实施具体的恢复方案了。

  最后一个问题,当备份策略设计完成,并且也按照该备份策略创建了备份,但如何确保该备份策略可靠、有效呢?方式只有一个,实践,因此当备份创建完成之后工作并不算完,最后也是最重要的环节,就是测试创建的备份是否能够真正满足需求。

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