22,209
社区成员
发帖
与我相关
我的任务
分享想请教邹大侠
我在一个应用中，使用的SQL Server 2008。其中一个文档的数据已经超过1TB，每次全备的时间都很长，再加上异地备份，时间就更长了。客户对此意见很大。
请教邹大侠有没有好的备份方案或者简单的数据库拆分方案。
现在的环境是：SQL Server 2008 企业版双机，EMC存储设备，每周周日一个全备，工作日中午差异备份。
请教邹大侠有没有好的备份方案或者简单的数据库拆分方案。
现在的环境是：SQL Server 2008 企业版双机，EMC存储设备，每周周日一个全备，工作日中午差异备份。
...全文
请发表友善的回复…
发表回复
ZSUWinFast 2010-04-29
- 打赏
- 举报
[Quote=引用 20 楼 leedsema 的回复:]
分割物理文件，自己不会分，那就看看书先。
另外，不知道你的数据库为何搞这么大？脑壳进了水？建议搞个服务器阵列，群集一下。
[/Quote]
你还真是天真，年龄和你的天真度不匹配，看清楚了具体配置再说。
分割物理文件，自己不会分，那就看看书先。
另外，不知道你的数据库为何搞这么大？脑壳进了水？建议搞个服务器阵列，群集一下。
[/Quote]
你还真是天真，年龄和你的天真度不匹配，看清楚了具体配置再说。
「已注销」 2010-04-26
- 打赏
- 举报
分割物理文件，自己不会分，那就看看书先。
另外，不知道你的数据库为何搞这么大？脑壳进了水？建议搞个服务器阵列，群集一下。
另外，不知道你的数据库为何搞这么大？脑壳进了水？建议搞个服务器阵列，群集一下。
yk32167 2010-04-26
- 打赏
- 举报
...友情帮顶...
zhangsong841 2010-04-26
- 打赏
- 举报
[Quote=引用 18 楼 yk32167 的回复:]
...友情帮顶...
[/Quote]
等邹老大吧，估计是个没有结果的题
...友情帮顶...
[/Quote]
等邹老大吧，估计是个没有结果的题
dichun 2010-04-26
- 打赏
- 举报
这么大的数据，采用拷贝的方法不可取
建议如下：
1。与客户确认目前存在系统中数据是否可以归档；
2。你分析一下数据库中那些表的记录数最大、占用空间最大，然后需要DBA把大表的数据分切到不同的文件组中；尤其存放附件的表单独出来；
3。如果数据量这么大，那么全备份肯定是需要很长时间的；从建构上考虑，可以考虑把某些表保存在不同数据库中，就可以同时执行两个或者多个库的备份，这样时间应该会少；
建议如下：
1。与客户确认目前存在系统中数据是否可以归档；
2。你分析一下数据库中那些表的记录数最大、占用空间最大，然后需要DBA把大表的数据分切到不同的文件组中；尤其存放附件的表单独出来；
3。如果数据量这么大，那么全备份肯定是需要很长时间的；从建构上考虑，可以考虑把某些表保存在不同数据库中，就可以同时执行两个或者多个库的备份，这样时间应该会少；
dawugui 2010-04-25
- 打赏
- 举报
[Quote=引用 15 楼 htl258 的回复:]
引用 14 楼 dawugui 的回复:
引用 13 楼 htl258 的回复:
建议：停止服务，直接复制.mdf和.ldf两个文件,这会估计会比较快。
1TB?拷贝到猴年马月?
1TB相当于1024G，当然了，花些时间是要的。我是觉得备份如果太慢，可以换种方式试下，但是快是慢，我也没试过。
[/Quote]
此方案不可取.
引用 14 楼 dawugui 的回复:
引用 13 楼 htl258 的回复:
建议：停止服务，直接复制.mdf和.ldf两个文件,这会估计会比较快。
1TB?拷贝到猴年马月?
1TB相当于1024G，当然了，花些时间是要的。我是觉得备份如果太慢，可以换种方式试下，但是快是慢，我也没试过。
[/Quote]
此方案不可取.
htl258_Tony 2010-04-25
- 打赏
- 举报
[Quote=引用 14 楼 dawugui 的回复:]
引用 13 楼 htl258 的回复:
建议：停止服务，直接复制.mdf和.ldf两个文件,这会估计会比较快。
1TB?拷贝到猴年马月?
[/Quote]
1TB相当于1024G，当然了，花些时间是要的。我是觉得备份如果太慢，可以换种方式试下，但是快是慢，我也没试过。
引用 13 楼 htl258 的回复:
建议：停止服务，直接复制.mdf和.ldf两个文件,这会估计会比较快。
1TB?拷贝到猴年马月?
[/Quote]
1TB相当于1024G，当然了，花些时间是要的。我是觉得备份如果太慢，可以换种方式试下，但是快是慢，我也没试过。
dawugui 2010-04-25
- 打赏
- 举报
[Quote=引用 13 楼 htl258 的回复:]
建议：停止服务，直接复制.mdf和.ldf两个文件,这会估计会比较快。
[/Quote]
1TB?拷贝到猴年马月?
建议：停止服务，直接复制.mdf和.ldf两个文件,这会估计会比较快。
[/Quote]
1TB?拷贝到猴年马月?
htl258_Tony 2010-04-25
- 打赏
- 举报
建议：停止服务，直接复制.mdf和.ldf两个文件,这会估计会比较快。
dawugui 2010-04-25
- 打赏
- 举报
1TB?
太恐怖了.
建议把数据库完全备份了,然后把日志清除了.
太恐怖了.
建议把数据库完全备份了,然后把日志清除了.
ZSUWinFast 2010-04-25
- 打赏
- 举报
前者，或者移走历史数据进专门的只读表，无须每次备份，或者按时间分区表，以前时间的表也就不用每次备份了
什么是历史数据？你怎么知道应用程序不去更新和删除原来的记录。你的要求，文件组就足够解决了，不用时间表之类的。
再者，把数据库备份的工作交给数据库引擎是最好的，应用只做应用的工作，各司其职。
什么是历史数据？你怎么知道应用程序不去更新和删除原来的记录。你的要求，文件组就足够解决了，不用时间表之类的。
再者，把数据库备份的工作交给数据库引擎是最好的，应用只做应用的工作，各司其职。
bancxc 2010-04-25
- 打赏
- 举报
搬个板凳等老大
nalnait 2010-04-25
- 打赏
- 举报
搬个板凳等老大
haitao 2010-04-25
- 打赏
- 举报
【其中一个文档的数据已经超过1TB】
这个文档是什么意思？表？数据库文件？
前者，或者移走历史数据进专门的只读表，无须每次备份，或者按时间分区表，以前时间的表也就不用每次备份了
这个文档是什么意思？表？数据库文件？
前者，或者移走历史数据进专门的只读表，无须每次备份，或者按时间分区表，以前时间的表也就不用每次备份了
--小F-- 2010-04-25
- 打赏
- 举报
[Quote=引用 2 楼 tjianliang 的回复:]
1、拆分数据，历史数据归档
2、基于硬件的备份方案
[/Quote]
同意将历史数据存档 历史数据专门用一张表来保存
其实备份的也就是新增的数据
1、拆分数据，历史数据归档
2、基于硬件的备份方案
[/Quote]
同意将历史数据存档 历史数据专门用一张表来保存
其实备份的也就是新增的数据
ZSUWinFast 2010-04-25
- 打赏
- 举报
另外，水平拆分和垂直拆分的可能性比较小，因为操作为很复杂。
这只是其中一个数据，加上其他数据，每次全备大概要花掉2~3TB的空间。但是就单个数据库来说，最大的这个备份是关键。
我尝试过文件组来解决问题，遗憾的是，表的存储空间都在Primary组上，无法移动。
这只是其中一个数据，加上其他数据，每次全备大概要花掉2~3TB的空间。但是就单个数据库来说，最大的这个备份是关键。
我尝试过文件组来解决问题，遗憾的是，表的存储空间都在Primary组上，无法移动。
feixianxxx 2010-04-25
- 打赏
- 举报
[Quote=引用 4 楼 huminghua 的回复:]
引用 1 楼 ws_hgo 的回复:
友情帮顶.......
[/Quote]
...
引用 1 楼 ws_hgo 的回复:
友情帮顶.......
[/Quote]
...
huminghua 2010-04-25
- 打赏
- 举报
[Quote=引用 1 楼 ws_hgo 的回复:]
友情帮顶.......
[/Quote]
友情帮顶.......
[/Quote]
我是小数位 2010-04-25
- 打赏
- 举报
人呢？怎么还没来，被人点名的都 是神！
亮剑_ 2010-04-25
- 打赏
- 举报
1、拆分数据，历史数据归档
2、基于硬件的备份方案
2、基于硬件的备份方案
加载更多回复（1）
