求:数据库备份(5T数据量)的方案

marydan 2017-11-15 10:25:52
各位大侠:


目前应用的是Orcle数据库,切数据量庞大(5T左右)根据客户需要要对数据库进行备份然后在另外设备上进行数据恢复;不知道 大侠们有没有好的策略,或者是在实际工作中有过类似的需求;求一个好的解决办法。

另:
(1) 数据库备份方式是手动的,并且备份出来后直接就拷贝到另外设备进行恢复;
(2) 因为数据量特别大,客户要求数据库备份所需时间不能超过一周;


以上。
...全文
949 16 点赞 打赏 收藏 举报
写回复
16 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
azhou46 2017-11-23
我做过8t的迁移,当时是在10g迁到11g情况和你的有点似,用rman,一天就能弄好
  • 打赏
  • 举报
回复
分不同的schema导出嘛,看着也感觉快点。。
  • 打赏
  • 举报
回复
minsic78 2017-11-20
引用 10 楼 liangjian010 的回复:
用DG呀,在存储级别对备库的DG卷做快照,然后把快照卷挂到目标机器,强行切换为主库可读写,整个过程三十分钟内解决。
切换时间呐需要三十分钟,顺利的话三分钟可能都够了,楼主问的是备份时间~
  • 打赏
  • 举报
回复
minsic78 2017-11-20
引用 9 楼 ckc 的回复:
这么大数据没玩过。 印象中100g的数据备份恢复需要1小时,按这个比例5t差不多就是2天 数据量大了似乎并不是简单的比例关系,所以2天应该不止
现在的存储,逻辑备份都不需要那么长时间吧,除非是串行的导出,导出大量数据必然会并行,就算是用exp之类的,也可以自己做拆分,以充分调动存储的性能~
  • 打赏
  • 举报
回复
minsic78 2017-11-20
引用 12 楼 liangjian010 的回复:
[quote=引用 11 楼 minsic78 的回复:] [quote=引用 10 楼 liangjian010 的回复:] 用DG呀,在存储级别对备库的DG卷做快照,然后把快照卷挂到目标机器,强行切换为主库可读写,整个过程三十分钟内解决。
切换时间呐需要三十分钟,顺利的话三分钟可能都够了,楼主问的是备份时间~[/quote] 切换是不用三十分钟,三十分钟指的是指备份到恢复最后到提供服务的整个过程过程,用RMAN不止三十分钟。[/quote] 用存储复制还需要三十分钟停机时间还是太久了,不知道有什么特别的操作?rman的话只要准备的好,别说三十分钟,半分钟搞定都有可能,关键可以多次recover,尽量同步主备库之间的差距,只要能做好这点,除非切换卡壳,怎会需要半个小时那么长时间? 另外,其实注意到了楼主发的前一个帖子,他的环境恐怕比较复杂,别说存储级的复制,怕是连rman都对付不了,源库与目标库之间网络都不通或者网络很差,估计只有用逻辑备份搞搞了。
  • 打赏
  • 举报
回复
「已注销」 2017-11-20
引用 11 楼 minsic78 的回复:
[quote=引用 10 楼 liangjian010 的回复:] 用DG呀,在存储级别对备库的DG卷做快照,然后把快照卷挂到目标机器,强行切换为主库可读写,整个过程三十分钟内解决。
切换时间呐需要三十分钟,顺利的话三分钟可能都够了,楼主问的是备份时间~[/quote] 切换是不用三十分钟,三十分钟指的是指备份到恢复最后到提供服务的整个过程过程,用RMAN不止三十分钟。
  • 打赏
  • 举报
回复
「已注销」 2017-11-19
用DG呀,在存储级别对备库的DG卷做快照,然后把快照卷挂到目标机器,强行切换为主库可读写,整个过程三十分钟内解决。
  • 打赏
  • 举报
回复
ckc 2017-11-17
这么大数据没玩过。 印象中100g的数据备份恢复需要1小时,按这个比例5t差不多就是2天 数据量大了似乎并不是简单的比例关系,所以2天应该不止
  • 打赏
  • 举报
回复
zbdzjx 2017-11-16
也要看数据库的版本和可停机时间了。
  • 打赏
  • 举报
回复
惜分飞 2017-11-16
5T的数据,备份不是个问题,稍微好点的io,rman就可以了
  • 打赏
  • 举报
回复
minsic78 2017-11-15
引用 2 楼 qq646748739 的回复:
买好机柜,固态硬盘,存储设备(我公司用的是富士通存储)
你不是HUAWEI的吗?不用自家的存储?
  • 打赏
  • 举报
回复
minsic78 2017-11-15
引用 4 楼 minsic78 的回复:
如果,如果说你逼不得已用逻辑备份做迁移: 1、如果网络通畅,那么可以考虑用impdp+dblink,省掉拷贝备份文件的时间;网络若是不通畅,那就没办法了,只有把dmp文件扛过去了~ 2、如果使用逻辑备份,可以考虑打开并行,不仅仅是工具本身的并行,可能的话,可以将需要备份的数据库对象拆分,当前需要注意一些依赖关系,这个拆分可能会比较花时间,或者简单粗暴点的,你可以按照用户拆分,争取在有限可用的时间窗口内,将主机的资源尽量榨取出来; 3、如果这一周还算上了导入的时间,那么导入可能也需要并行,而且导入最可能发生阻塞的是目标库的redo日志切换不及,可能需要按需调整redo大小及组数,以让导入
最后漏了几个字 以让导入顺利进行~
  • 打赏
  • 举报
回复
minsic78 2017-11-15
如果,如果说你逼不得已用逻辑备份做迁移: 1、如果网络通畅,那么可以考虑用impdp+dblink,省掉拷贝备份文件的时间;网络若是不通畅,那就没办法了,只有把dmp文件扛过去了~ 2、如果使用逻辑备份,可以考虑打开并行,不仅仅是工具本身的并行,可能的话,可以将需要备份的数据库对象拆分,当前需要注意一些依赖关系,这个拆分可能会比较花时间,或者简单粗暴点的,你可以按照用户拆分,争取在有限可用的时间窗口内,将主机的资源尽量榨取出来; 3、如果这一周还算上了导入的时间,那么导入可能也需要并行,而且导入最可能发生阻塞的是目标库的redo日志切换不及,可能需要按需调整redo大小及组数,以让导入
  • 打赏
  • 举报
回复
碧水幽幽泉 2017-11-15
5T的数据不用一个上午就备份好了。
  • 打赏
  • 举报
回复
碧水幽幽泉 2017-11-15
买好机柜,固态硬盘,存储设备(我公司用的是富士通存储)
  • 打赏
  • 举报
回复
minsic78 2017-11-15
如果存储设备够劲,几个小时就完成备份了,恢复时间会长点,算个备份时间的两倍好了,一星期足够了,顺利的话一天都搞定了 …… BTW:那么大库的迁移,肯定用rman了,如果你要导出导入那就是另外一回事情了。
  • 打赏
  • 举报
回复
相关推荐
发帖
Oracle 高级技术
加入

3439

社区成员

Oracle 高级技术相关讨论专区
申请成为版主
帖子事件
创建了帖子
2017-11-15 10:25
社区公告
暂无公告