请教各位高手两个比较大的数据库oracle 每个两个多T,求备份方案

cs119

具体配置和要求如下:
数据库版本 ： ORACLLE 8.17.4   （每天的REDO LOG 在100G左右）
盘柜为     ：HP XP512
带库可在8小时内备份4T数据（在理论值的基础上砍掉50％后计算得来）于盘柜在同一SAN内。

我得系统为7×24的工作模式，白天为大量的前台连接，晚上有1－2两小时的集中批量处理。现采用每天EXPORT出一些核心的数据，但无法保证数据的一致性，因此备出的数据根本没有用，现想得到一种有明确时间点的备份方法，允许最大的数据损失在为一天的数据，当然若可以更短或没有损失更好，数据有损失后可在8小时内恢复正常。
  在此先谢谢各位高手。

davy-chen

联系一下：davy_wang@21cn.com我可以与您方案！

dansz

数据库一定要使用archivelog的方式，不然到时候你哭都哭不出来

cs119

我的数据库在忙时不到一分钟REDOLOG就要切换一次（每个256M），这样的话使用archivelog的方式会不会导致性能急剧下降，现在资源本身不是很富裕，在加上应用厂家写的比较烂，里面有N多的全表扫描。再者若采用archivelog的方式多久做一次全备好呢，时间长了若出问题恢复起来需要好多天可不行。我们领导能接受的也就是一个晚上的时间。因此请dansz 兄针对我的情况分析一下archivelog的方式的可行性。

dansz

采用archivelog的方式肯定会造成性能下降，如果你本身资源不是很富饶，要小心使用archivelog方式，建议你咨询一下ORACLE的工程师。

就你说的情况：如果采用archivelog方式一定要足够的硬盘空间来存放archivelog日志文件。如果archivelog所在文件系统满了，将会导致ORACLE数据库挂起。

由于你的的应用提交的事物太多，至于备份我认为是每天晚上某一时间对数据库做全备份，然后每天不定时的备份archivelog。对于archivelog的备份一定要保证完整性。如果在灾难发生的时候丢失数据最小，就ORACLE公司的说法，如果你的备份做的足够好，可以达到零数据的丢失。

至于出问题恢复的时间是没有办法控制的，这和你的数据量和你所做的备份有很大的关系，如你要求有最少的恢复时间，肯定就要求有最多的全备份，这样对你磁带的消耗也是一个很大的问题。

因此你要综合考虑一下。

老邱

补充一点dansz兄关于archivelog的说明：如果你不用archivelog模式，就没有办法在线进行数据库物理备份，也就是说要物理备份时必需先shutdown数据库！

另外，有一些磁盘备份的方式，可以快速备份。好像XP512有BusinessCopy功能，可以快速镜像和拆分数据库所在的磁盘。另外Veritas Volume Manager也有snapshot的功能，也可以实现镜像拆分，而且可以使用一些低成本的磁盘柜。拆完了你就慢慢备去吧，因为备份时不对你的生产数据库造成影响，你也就不必在乎备份时间了。

不过有一点，利用这种镜像拆分的功能，你的oracle一定也要在archivelog模式下，不然拆开的一瞬间是无法保证oracle的一致性的。

cs119

hp 的bc 说得挺好，但实施的时候，感觉其太粗糙，跟其MC 差不多，真拿他备份不知会不会有问题。另外那位老兄熟悉Veritas Volume Manager也有snapshot的功能,能不能讲一下其实现的大致机制，在那个层面实现。

老邱

bc是基于LUN的，而Volume Manager的snapshot是基于volume。LUN与volume关系是：一个或多个LUN组成一个dg（disk group，hp 的LVM叫vg，volume group，一个意思），一个dg上可以建许多volume。

做snapshot其实很简单，以下每一条都是一句语句：
1. snapstart     # 系统为你在dg申请一块空间对要snapshot的volume开始做镜像，只需要在建立snapshot时做一次
2. 当需要拆分时：snapshot     
3. 需使用snap_volume时（例如做备份）：mount
4. 用完后：snapback或删除snap_volume

另外，也可以将snap_volume由另一台服务器操作，不过需要将snap_volume从一个dg中拆开，合并到另一个dg，才能由另一台机器操作（常规情况下，一个dg不能被两个host同时操作）。步骤如下：
1. snapstart     # 系统为你在dg申请一块空间对要snapshot的volume开始做镜像，只需要在建立snapshot时做一次
2. 当需要拆分时：snapshot     
3. split snap_volume from old_dg to new_dg
4. deport new_dg on host1    # 在生产机上把包含snap_volume的dg卸下来
5. import new_dg on host2    #在备机上把该dg挂上
6. 需使用snap_volume时（例如做备份）：在host2上mount
7. 用完后删除：destroy new_dg
8. 或snapback
   1) deport from host2
   2) import to host1
   3) join new_dg to old_dg
   4) snapback

Hom

那到底LUN和VOLUME之间是什么关系呢？
还是没看明白，

原帖由 "老邱" 发表：
LUN与volume关系是：一个或多个LUN组成一个dg group ，一个dg上可以建许多volume。

wdbj

一般来说，ARCHIVE LOG是很必要的，虽然它的确影响性能，但你可以衡量一下是性能更重要还是数据的完整性。
性能下降可以靠升级设备来搞定，既然是很重要的应用，没理由不做预算在上面。
有为老兄提出的利用XP512的business copy方法我觉得是个好方法