在我目前工作的地方,主要业务数据库位于虚拟服务器(SQL Server 2005 标准)上。临时数据库和日志在一个磁盘上,数据库本身在另一个磁盘上。SAN 的配置方式使得它们只能提供 512GB 磁盘(有人告诉我 4K 块,但我对 SAN 一无所知)。保存数据库的磁盘上大约有 4% 的可用空间。
我的任务是研究一种方法来归档旧数据并将其从数据库中清除为一年的块以便归档到磁带(我是一名承包商,实际上我是一名开发人员,尽管我过去曾涉足过 DBA 世界并且有 15 年左右的 SQL Server 开发经验,而不是 DBA,我一进门就把它交给了我。我们确实有 DBA,所以我不知道我为什么要这样做但是没关系)。那是大约 6 个月前的事,从那时起,我断断续续地构建了一些可以做到这一点的东西。但我越来越担心我们无法对生成的数据库进行足够的测试以验证我们确实没有破坏某些东西,并且我一直在考虑寻找替代解决方案。
我首先考虑分区,但那是因为我们有 SE,没有机会升级到 EE,因为在 6 个月左右的时间里,整个 shebang 将转移到一个专用的数据中心,拥有更大、更现代的基础设施,整个系统将被新的取代未来2-4年的发展。但后来我想到,我们当然可以将数据库拆分为一个文件组中的多个文件,并将它们分布在多个磁盘上(我们可以毫无问题地配置更多 512GB 磁盘)。这使整个数据库完好无损,甚至可能有轻微的性能优势,尽管这不是这里的主要目标。
我很确定这在 SE 中是可以的(同样,我不是 DBA),而且我认为这风险要小得多,而且实施起来可能更快。所以我的问题:
- 是否可以在 2005 SE 中将数据库拆分为多个文件?
是否可以将当前位于单个磁盘上的一个文件中的现有数据库拆分为跨多个磁盘的多个文件?
我什至需要提供比这些信息更多的信息来说服任何理智的人,冒着破坏数百万英镑业务的风险从生产数据库中清除数据是愚蠢的吗?
1) 是
2)是的,
创建新文件后,您需要删除并重新创建目标表的聚簇索引,将它们移动到新文件组以移动数据:
3) 如果你能让 DBA 支持你使用这个解决方案,我想你会没事的。根据您的限制,这似乎是一个非常合理的举动 - 但请记住在尝试移动数据之前进行备份!