紧急数据库恢复带来的数据库备份策略是怎样的
紧急数据库恢复带来的数据库备份策略是怎样的，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
某日，接到一个CASE，说数据库两台服务器电源同时损坏，已经不能使用，要求在第二天上班前恢复所有的数据库，赶到现场已经晚上12点了，首先了解了一下该学校的数据库情况：
数据库的操作系统为Solaris的操作系统。
数据库的备份只有Rman的备份，并且放在存储上。
万幸的是现场有一台可供恢复的小型机并且有识别该小型机的光纤卡。
首先在可供恢复的小型机上接上光纤存储卡并且可以认到存储上数据库rman备份，然后安装好数据库软件后，将数据库的数据恢复，在将数据库打开。整个过程大概用时5小时以上。
根据上述的案例，下面我就来跟大家讨论一下备份方案的制定：
1、最早希望恢复到什么时间点
对于用户，用户只关注数据库当前状态是否正常，至于数据曾经做过什么操作，什么时间做的并不重要;也有些业务类型可能会由于特殊的需求，希望看到之前曾经做过的操作，甚至要将数据库恢复到之前的某个时间点。这两种需求主要与备份的保留策略有关。对于前者，一般建议选择基于冗余数量的备份保留策略，如果只希望保证数据库稳定运行，那么可视数据规模的大小，适当保存几份最近的备份即可。
为什么要保存最近的几份，一份不就行了吗?
备份本身就是在做冗余，那么从可靠的角度考虑，对于备份当然也要有冗余，至少要保证有两份备份嘛，这样即使由于某些原因损坏了一份，还能有个替补的。像上述案例中一样，只有一份的备份其实是很危险的，如果出现异常情况，万一数据不能恢复，那造成的损失就无法估量了。当然，份数的多少决定需要的磁盘空间会成倍增加，需要根据磁盘的容量大小来决定所需要保留的备份份数。
如果不仅要看到，还要能将数据恢复到之前的某个时间点，那么就必须要保证存在目标时间点(或之前)创建的备份，以及相关的归档文件。基于这类需求建议选择基于冗余时间的备份保留策略，备份的保留时间设置为最早恢复到的时间即可。
2、系统什么时间比较空闲
由于系统需要涉及大量数据的读写，这期间必然会占用较多的系统资源，如果在数据库繁忙时段执行备份任务，那么不仅仅备份需要花费较长时间，还有可能对正常运行的业务系统造成影响。
我们目前通常的做法都是将备份的任务放到凌晨两点执行，对于大多数业务，这个时间系统的访问量最少，当然个别学校如果对于自己的数据库使用情况了解的话，可以提出要求在某一时刻进行备份。
3、数据库的数据规模有多大
虽然前面说不考虑硬件因素，不过备份操作本身，考虑到执行效率的因素，想完全忽略硬件是不可能的，备份所需的时间还是建立在用户使用独立存储的性能基础上的。按照磁盘读写大概每秒百M的速率计算，200GB左右数据执行备份操作需要半个小时左右(对应的恢复操作也差不多是这个时间，一般会更长，因为恢复时还需要应用重做日志)，就备份操作来说，每天在系统不繁忙的时间分配几个小时专门执行，这个时间对于大多数应用都还可以接受。所以我们给一般学校制定的备份策略为每周六进行一次全备份，每天对归档日志进行备份，当每周六进行全备后，删除以前备份的归档日志。
4、预估可能给予的恢复操作时间
一般情况下正常的系统不会执行恢复操作，当需要对数据库系统做恢复操作时就代表着系统中出现了问题，虽然说出现的问题可能是偶发性的，但处理问题所需要的时间有可能是确定的，比如数据量确定的情况下，恢复数据文件和应用日志的时间是可以估算出来的。
对于某些核心的业务系统，任何无公告通知的短暂停止服务甚至都是灾难，那么这种情况下，一旦出现重大问题，仅依靠RMAN想做到快速恢复是不可能的。所以需要数据库管理员通过其他途径确保系统的高可用性(例如在存储层做镜像或者做数据库灾备等)，而不能仅仅是依靠备份。
而有些非核心的业务系统，可能每周甚至每个月只有某个时段需要用到(如选课系统)，对于这类数据库系统，由于其执行恢复的时间非常富裕，相对来说制订备份策略时也就可以更宽松。比如并不需要每天都创建备份，而仅在有数据修改发生时执行备份任务。
备份和恢复之间绝对不是各自孤立存在，恢复依赖于备份，备份策略基本上也就决定了恢复方式、能恢复的数据及恢复的效率等。因此备份策略的制订要视你的恢复需求，以及恢复策略而定。
5、总结：
对于如何制定数据库的备份，我的建议是如果条件允许的情况下，可以在数据库服务器本地与存储上做一个Rman备份，如果是小型机系统，建议除了做Rman备份(rman只能适用于同平台之间的恢复)外，还需要做一个逻辑方面的备份并且将这个备份放置在远程端。备份完成后，需要每隔一段时间(一般三个月)就要做一次全库的恢复性测试以保证数据库备份文件的可用。
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注行业资讯频道，感谢您对的支持。
