当oracle的数据量达到几百TB的时候，rman怎么处理？

vongates

大库真正完全用RMAN比较不实在。

brotherxiao

其实主要不在于备份，而在于这么大的备份在你恢复的时候，你能忍受多长的恢复时间？如果忍受不了，备份也就没有意义。再考虑现在的备份介质的读写速度，也就明白了。
T级别的数据备份用rman还是比较多的，毕竟存储级成本太高，不是每个单位都能用的起的。
对于一个要求高可用的系统，实际上真正会用到全备的情况也非常少，通常是通过各种冗余或HA策略来保障业务的连续性。

sgsoft

TB级别的数据库都得用盘阵吧，备份用RMAN的估计仍然有一些的，应用应该支持逻辑上的增量备份。

foxmile

这种级别的大库如果出了异常。怎么处理呢？

randylin2006

百T级别的库基本上都是用存储级别的备份，RMAN已经满足不了需求了！

foxmile

那象这样级别的数据量，有没有类似的方案可以学习呢。

happybirty

关注中

feng_xin

看你的需求了

如果你对备份恢复的时间没有要求，多大的数据库都能使用rman

如果rman备份恢复的时间超过你的要求，可以考虑硬件存储级别的备份

foxmile

有道理。oracle的备份还是有局限。不知道淘宝的数据量有多少。大概的备份方式是什么

binhu

我也觉的那么大的资料量，全库用rman备份并不实用，因为还原的时间一定超久的
可考虑架dataguard，而其中一台standby的机器跟primary机器同步的时间可设间隔一定的时间再同步一次，然而平常时primary的archive log file再指定同时备份到别台机器上面
当primary挂点时，拿其中一台standby机器转换成primary再配合archive log file，就可达到损失最少的数据跟downtime的时间最少了。
而我为何要规划其中一台standby机器要晚一些时间呢，因为我要把这台机器放在别的机房内。跟primary同机房内别的standby机器当然可立即同步archive的方式。
不然就要找协力厂商软体处理了，有一些备份软体是可on line备份数据库的，这也是另一个想法
使用的数据量能上T的公司，不太可能会省这点小钱的。整个重点应该要放在还原的时间上面，备份的时间反而不是优先考虑。

[ 本帖最后由 binhu 于 2008-1-10 22:12 编辑 ]