SQL SERVER 库越来越大如何管理？

Question

当SQL SERVER 库超过1T 的时候，如何管理？表也越来越大，如何处理？如何迁移？如何恢复？

Answer 1

您好，

請參考以下的資訊，希望對您有幫助，謝謝!

http://blogs.msdn.com/b/sqlserverstorageengine/archive/2007/04/30/very-quick-list-of-vldb-maintenance-best-practices.aspx

---

亂馬客blog: http://www.dotblogs.com.tw/rainmaker/

Answer 2

库的大小，管理的方式和机制基本一样，不管是SQL Server还是ORACLE、DB2

要方便归档，基本就是分区，不过这会涉及改动数据库结构甚至磁盘设计，也需要SQL 2005以上企业版才支持

---

Try SQL Server 2008 QQ:315054403 [e-mail]

Answer 3

目前我给我的主管的建议就是对项目了解，针对功能开始拆分，大功能变成若干个小功能拆分。大表利用分区的方式管理，或拆成多个扩展表方式。需用到及时复制，尽量能选择复制，筛选出不需要的数据。按照目前SQLSERVER复制方式，容易造成分发好多日志鸡肋，目前没有好的工具。可以自行选择复制。ORACLE DG可以，不过价格不便宜。

Answer 4

Not sure if replication can help here. Yes, partitioning does lot for us on 20+ tb dbs.

Answer 5

表通常是要分区的。

迁移？为啥要迁移？

备份/恢复可以做文件组/文件备份。

---

想不想时已是想，不如不想都不想。

Answer 6

同意rmiao，复制不是解决数据量大的问题的。

楼主就没搞明白复制怎么用。复制可以加条件筛选的。

另外，现在1TB真不算大。国内少说也有几十个TB级的SQL数据库。

拆分是个好方法，当然，要求从架构设计开始，等都做完了再拆就麻烦了。

---

想不想时已是想，不如不想都不想。

Answer 7

策略的话要看你数据库里的数据了

到底你需要这么多吗？还是说有很多无用的数据，多了就purge掉，又或者有历史数据并不厂用，而且front tier也不用，偶尔历史查询，考虑archive出来

如果以上两者都没有再考虑partition咯

---

If you think my suggestion is useful, please rate it as helpful.
If it has helped you to resolve the problem, please Mark it as Answer.
http://twitter.com/7Kn1ghts