在7*24的环境下是否适合做全备？

oracle-plus

ahlu有點像我得性格。喜歡未雨綢繆，集思廣益，還有不停的提出問題和研究問題
我說說我們公司的情況。
由於，我們公司並不需要7x24,所以，每天晚上都會做一次Rman 全備份，
然後每2天還做Exp全備份。
所以，一般出現什麼情況的話，都可以很快的對數據庫進行恢復。

當然，還有些是因為硬盤不夠，但每天卻產生很多得archivelog，所以，
後來就放棄了Archivelog模式，而是采用每半天都數據庫進行Exp.

rollingpig

晕

怕archive log 多 可以用

rman 的 backup archive log delete input 啊。

oracle-plus

最初由 rollingpig 发布
[B]晕

怕archive log 多 可以用

rman 的 backup archive log delete input 啊。 [/B]

哦？我想聽聽你的意見。
rman 的 backup archive log delete input 主要有什麼用的？
我的archivelog很多很多啊！硬盤不夠用，所以不能用archvielog了。

piner

最初由 oracle-plus 发布
[B]

哦？我想聽聽你的意見。
rman 的 backup archive log delete input 主要有什麼用的？
我的archivelog很多很多啊！硬盤不夠用，所以不能用archvielog了。 [/B]

既然是生产库，就不该不归档

macrossplus

rac4+netbackup

ahlu

RE：BTW : 明白备份与恢复的原理，就不怕环境的变化，反而没必要非去罗列所有例子，我觉得，要完成一套方案，我需要知道就是：

1：数据库存储 和带库的速度
2：数据库容量、归档日志的生成量
3：恢复所要求的时间

   说的没错，明白备份与恢复的原理，就不怕环境的变化。但是就像自然灾害，我想每个水利专家都知道发生灾害的原因，但实际问题法发生时，压力和时间会影响你的决策，这时借签别人同样事件的解决方案，每次灾害发生都有一套事先的计划安排，只有所有方案都失效了，你展现个人魅力的时候就到了 。就像编程，大家都有体会的，你冥思苦想一整夜才想出来，其实只要一个遇到这问题的人用一分钟就可以让你解决，我们为什么不问问那个有经验的人呢？

ahlu

RE：BTW : 明白备份与恢复的原理，就不怕环境的变化，反而没必要非去罗列所有例子，我觉得，要完成一套方案，我需要知道就是：

1：数据库存储 和带库的速度
2：数据库容量、归档日志的生成量
3：恢复所要求的时间

   说的没错，明白备份与恢复的原理，就不怕环境的变化。但是就像自然灾害，我想每个水利专家都知道发生灾害的原因，但实际问题法发生时，压力和时间会影响你的决策，这时借签别人同样事件的解决方案，每次灾害发生都有一套事先的计划安排，只有所有方案都失效了，你展现个人魅力的时候就到了 。就像编程，大家都有体会的，你冥思苦想一整夜才想出来，其实只要一个遇到这问题的人用一分钟就可以让你解决，我们为什么不问问那个有经验的人呢？

ahlu

请问你的数据库多大，server的配置，用什么介质做备份，每天估计archive log 有多少，生产系统不用归档模式是不是存在问题，但这好像很普遍，很多企业考虑到成本问题。

biti_rainy

最初由 ahlu 发布
[B]RE：BTW : 明白备份与恢复的原理，就不怕环境的变化，反而没必要非去罗列所有例子，我觉得，要完成一套方案，我需要知道就是：

1：数据库存储 和带库的速度
2：数据库容量、归档日志的生成量
3：恢复所要求的时间

   说的没错，明白备份与恢复的原理，就不怕环境的变化。但是就像自然灾害，我想每个水利专家都知道发生灾害的原因，但实际问题法发生时，压力和时间会影响你的决策，这时借签别人同样事件的解决方案，每次灾害发生都有一套事先的计划安排，只有所有方案都失效了，你展现个人魅力的时候就到了 。就像编程，大家都有体会的，你冥思苦想一整夜才想出来，其实只要一个遇到这问题的人用一分钟就可以让你解决，我们为什么不问问那个有经验的人呢？ [/B]

一个良好的备份方案自然估计了发生任何  损坏 时候的恢复方案（只要备份本身是好的），说白了，恢复不过是  尽量少地恢复达到快速恢复完毕的目的。 如果一套方案要等到 灾难来临时候展现个人魅力，或者说灾难来临时候的处理办法要借鉴他人经验，只能说备份时候就不曾仔细考虑过灾难恢复。

做备份恢复的时候，你只要问问自己： 如果一个文件损坏我怎么恢复，如果全部文件损坏我怎么恢复，如果日志文件损坏呢？控制文件损坏呢？如果恢复过程中发现还丢了一个归档怎么办？我是否要定期做恢复测试 或者备份文件有效性检查？

你把这些疑问都回答了，恢复的时候也就很自然了。




做备份的基本原理无非是：
备份速度
恢复速度
恢复的可能性

由此决定恢复时间、空间需求，根据应用需求，来决定详细的方案。 无非就是有全备、增量、归档 这种类型，或者逻辑的备份，根据应用恢复时间需求决定全备的频率，甚至决定是否做 standby。 由于具体应用千奇百怪，罗列10种也未必覆盖的了你的要求。 所以你完全可以说出你的具体应用需求，甚至你可以虚拟一个 需求，并描述出恢复的要求时间、数据量、介质速度，我们就可以评估出备份与恢复方案。

biti_rainy

BTW:  我只是说没有必要穷尽所有现象，只要了解 通常大家的几种习惯做法就可以了。

因为单就这个帖子的标题来看，我个人以为你除了了解大家的几种习惯做法外，更重要的是去  理解备份与恢复的原理。

因为 24*7 往往意味着 系统重要，数据也比较重要。不备份是非常危险的，而备份，则必然会有全备，所以这个我认为这个题目和内容折射出来的意思，应该是由于不了解通常习惯做法、也不知道自己该如何做，总是害怕自己出错。但只要理解原理以及回答了我上面提出的几个问题，就不会有什么担心的。


如果一个数据文件损坏我怎么恢复?
如果全部文件损坏我怎么恢复?
如果日志文件损坏呢？
控制文件损坏呢？
如果恢复过程中发现还丢了一个归档怎么办？
我是否要定期做恢复测试 或者备份文件有效性检查？


我个人看见题目时候的一点感觉，妄加揣测，希望不要见怪。