2013年（350）
分类： Oracle
2013-04-10 13:29:58
===========================================================================
作为一名严谨的DBA，必须在正式上线之前就考虑到，数据由于各种原因导致出错的可能。出现错误本身并不可怕，但如果没有对应的机制进行处理，那就有可能演变成灾难了，对于Oracle数据库来说，是否存在适当的备份，是能否最终修复数据的关键因素之一，因此，如何制订数据库的备份策略，就成了很多初学者最常提及的问题。
有很多技术书籍在谈到策略之类话题时，往往是以非常全面、严肃的方式，详尽阐述涉及这一话题的方方面面，恨不得把前盖儿螺丝是否上紧都要扯进来漫谈一通。当然不能说人家介绍的方式不对，但是我想，对于真正的应用者来说，并不是所有的知识点都具有很大的意义，而且由于文字枯燥，看得云山雾罩，特别是初学者，可能看了几页也不知道究竟应该做什么以及怎么做。
针对这一问题，在此我想换一种表达的方式。你想知道究竟需要什么样的备份策略，以及当前制订的备份策略是否合理？很简单，只需要回答几个问题就行了。
提示：
本小节阐述的内容仅从业务特点和Oracle自身应用的角度出发，不涉及硬件环境，如用户使用的存储设备、磁盘阵列类型、服务器配置及网络条件等方面话题。下列描述是建立在用户系统资源充配，存储空间充足的基础之上的。如果答案为否，请响应国家号召，自觉进行至少7天以上隔离。开玩笑，数据库既然都不准备进行恢复操作，那还谈什么备份策略，甚至都不需要创建备份。
如答案为是，那么请继续回答下一个问题。
提示：
本题是让大家认识到，备份的目的就是为了恢复，所有为创建备份而进行的准备、设计的方案、创建的策略等都是为了满足恢复的需要。如果看到这里，你终于恍然大悟、豁然开朗，恭喜，你已经开窍了，后面的问题不过是提醒你认识到这一点，既然你已大 － 彻 － 大 － 悟，修 － 得 － 圆 － 满（注，一定要一个字一个字的读），为师已经没什么可以再教你的了，你就下山去吧。O，错了错了，俺是说本小节三思该说的都说了，你就看下一章去吧。
对于某些业务类型，用户只关注数据库当前状态是否正常，至于数据曾经做过什么操作，什么时间做的并不重要；也有些业务类型可能会由于特殊的需求，希望看到之前曾经做过的操作，甚至要将数据库恢复到之前的某个时间点。这两种需求主要与备份的保留策略有关。对于前者，一般建议选择基于冗余数量的备份保留策略，如果只希望保证数据库稳定运行，那么可视数据规模的大小，适当保存几份最近的备份即可。例如，配置当前备份集的保留策略为保留最近的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由于备份集也是要占用存储空间（往往还不小），因此基于时间的备份保留策略，必须要考虑到存储设备空闲空间的问题。
由于系统需要涉及大量数据的读写，这期间必然会占用较多的系统资源，如果在数据库繁忙时段执行备份任务，那么不仅仅备份需要花费较长时间，还有可能对正常运行的业务系统造成影响。
目前通常的做法都是将备份的任务放到凌晨时段执行，对于大多数业务，这个时间系统的访问量最少，当然DBA在设计备份任务执行时间时，还是要根据自身实际情况而定。
三选一：超大（>1TB）、一般（<1TB and >200GB）、小（<200GB）。
虽然前面说不考虑硬件因素，不过备份操作本身，考虑到执行效率的因素，想完全跳过硬件是不可能的，上述选项是建立在用户使用独立存储（或磁盘阵列的读写性能不低于100M/s）的基础上的。按照磁盘读写大概每秒百M的速率计算，200GB左右数据执行备份仅仅写操作需要半个小时左右（对应的恢复操作也差不多是这个时间，一般会更长，因此恢复时还需要应用重做日志），就备份操作来说，每天在系统不繁忙的时间分配几个小时专门执行，这个时间对于大多数应用都还可以接受。如果当前使用存储的性能很好，如读写效率超过百兆/秒，甚至能达到千兆/秒，或者可以接受更长的备份/恢复时间，那么数据规模稍大也可以，本例中列举的选项仅供参考。
三个选项中，后两个选项可以每次都进行全备份，请接着看第6条，而对于第一个选项，也许增量备份更适合，请继续看第5个问题。
还是三选一：
（1）是：每天数据量中都有超过10%以上的数据修改。
（2）否：每天数据基本没变化，只偶尔有极少量修改。
（3）一般：每天数据都在变，但量并不大。
对于选项（1），基本上不建议使用增量备份，除非的数据库规模非常非常大。
对于选项（2），强烈建议使用增量备份，除非管理的数据库规模非常非常小。
对于选项（3） ，都行啊，建议根据数据库的规模，再结合问题3来定是否启用增量吧。
提示1：选择增量备份的话，记得要启用块修改跟踪特性哟。
提示2：增量备份也有两种不同类型，在处理增量数据时逻辑并不相同，详细请参考8.7.4小节。
提示3：如果数据库中每天变化的数据量虽然很大，但基本上都只是系统中某个或某几个表空间的数据在变化，那么可以在制定备份策略时，只定期备份该表空间中的数据，其他的表空间以不那么频繁的周期创建备份。一般情况下正常的系统不会执行恢复操作，当需要对数据库系统做恢复操作时就代表着系统中出现了问题，虽然说出现的问题可能是偶发性的，但处理问题所需要的时间有可能是确定的，比如数据量确定的情况下，恢复数据文件和应用日志的时间是可以估算出来的。
对于某些核心的业务系统，任何无公告通知的短暂停止服务甚至都是灾难，那么这种情况下，一旦出现重大问题，仅依靠RMAN想做到快速恢复是不可能的（前面讨论过磁盘读写速率与数据库规模的关系），DBA需要通过其他途径确保系统的高可用性，而不能仅仅是依靠备份。
而有些非核心的业务系统，可能每周甚至每个月只有某个时段需要用到（如员工薪资系统），对于这类数据库系统，由于其执行恢复的时间非常富裕，相对来说制订备份策略时也就可以更宽松。比如并不需要每天都创建备份，而仅在有数据修改发生时执行备份任务。
所谓的恢复其实就是根据可能出现的问题制订的一个计划，出现什么样的问题采用什么样的方式处理，这中间还要兼顾恢复技术的可靠性及恢复的成本。
备份和恢复之间绝对不是各自孤立存在，恢复依赖于备份，备份策略基本上也就决定了恢复方式、能恢复的数据及恢复的效率等。因此备份策略的制订要视你的恢复需求，以及恢复策略而定（当然同时还受限于软硬件的实际情况）。
在制订恢复策略时，根据假定可能遇到的那些问题，罗列出的能够帮助我们修复错误的解决方案（通常都不会只有一种选择），以及实际情况（在建立备份策略的时候需要具体问题具体分析，如操作系统的资源配置，数据库系统的运行要求等都会对备份策略产生重要影响），来实施具体的恢复方案了。
最后一个问题，当备份策略设计完成，并且也按照该备份策略创建了备份，但如何确保该备份策略可靠、有效呢？方式只有一个，实践，因此当备份创建完成之后工作并不算完，最后也是最重要的环节，就是测试创建的备份是否能够真正满足需求。
