现在，因为我没有在管理数据库方面拥有非常丰富的经验，我正在寻找归档旧数据的最佳方法。
信息
有关于数据库中总共有310'000'000条记录。
数据库在硬盘上需要250 GB。
服务器版本是SQL Server 2008，兼容级别为SQL Server 2005（90），但是我们重新计划很快升级到SQL Server 2012
我考虑了两种可能性：
新数据库
创建类似的数据库到生产服务器上的一个服务器，然后将所有旧数据插入新数据库。
缺点：由于我们的环境中不允许链接服务器，因此很难加入旧服务器必要时提供数据
历史架构
创建新架构fe [hist]具有与生产数据库中相同的表。将所有旧数据插入新方案中的这些新表中。
优点：如果将来将来需要旧数据，则可以轻松连接
您是否更喜欢其中一种解决方案？
为什么？
还有更好的可能性吗？
是否有现有的工具可以轻松完成此任务？
/>还有其他想法吗？
预先感谢
编辑
其他问题：
新创建的档案库是否会表还需要主键/外键？
还是应该只包含列但没有键/约束？
#1 楼
我认为您对许多问题的答案取决于情况。您遇到什么性能问题？数据库从容量增长到250GB似乎会出现性能问题。也许您的查询正在对整个事实表执行表扫描，即使只有很小一部分（例如，去年） ）需要日期范围？如果存在最需要优化的特定查询，请考虑在另一个问题中发布架构，查询和实际执行计划，以查看是否可以优化。
您更喜欢其中一种解决方案吗？
我通常更喜欢历史数据库，而且我认为Guy在回应中对此做了充分说明。
我看到的历史数据库（与模式相对）的主要缺点是您不能再对归档表使用外键。这对您可能很好，但是需要注意。
为该方法列出的缺点并不准确；您将能够轻松地在同一服务器上的跨数据库查询，并且查询优化器通常可以很好地处理跨数据库查询。
还有更好的可能性吗？
如果需要定期查询档案数据，我可能会考虑按日期对表进行分区。但是，这是一个很大的变化，可能带来很多性能影响，包括积极的影响（例如，消除分区，更有效的数据加载）和消极的影响（例如，更慢的单例查找，并行查询中线程偏斜的可能性更大）。因此，如果数据库使用率很高，我不会轻易做出这个决定。
新创建的存档表是否还需要主键/外键？
还是他们应该只包含列但没有键/约束吗？
我建议至少拥有主键和唯一索引，以便您可以获得它们提供的数据完整性好处。例如，这将防止您不小心两次将一年的数据插入历史记录表。另外，如果您确实需要查询历史记录表，它可能会提高性能。
还有其他想法吗？
由于您正在使用企业版并计划升级到SQL 2008+，因此您可以考虑对该表进行数据压缩。压缩当然会减少磁盘空间，但是取决于服务器的磁盘和CPU资源，它还可以通过减少磁盘I / O和提高内存利用率（一次有更多数据放入高速缓存）来提高读取的查询性能。
#2 楼
我宁愿每天都在链接服务器上拥有一个历史架构或另一个历史数据库。它节省了许可证成本，更易于管理和查询。然后，您还可以使用更简单的架构并删除一些索引，从而使数据库更小。但是，由于您拥有企业版，因此第三个选择是对表进行分区，当放置到位时，存档数据和查询旧数据对您的用户来说是透明的，并且您无需进行应用程序更改。
评论
将第二个架构放入其自己的文件组中，还可以使OP将存档数据放置在速度较慢，价格较低的磁盘上。由于OP使用的是Enterprise Edition，因此在灾难恢复时进行零碎恢复也可以使他们受益。
– Max Vernon♦
2015年10月6日在21:35
#3 楼
以我的经验，出于两个原因，第二个数据库将是首选。您可以从历史备份中还原数据，然后删除不需要的表和索引。
您可以将其移至其他服务器以进行报告，这样做的好处是不使用主服务器的资源
您仍然需要从主数据库中删除所有历史数据，但是这可以安排在。
#4 楼
现在，请不要理会许可证，因为那不是我的时间。恕我直言，存档数据库最容易实现和维护。它们是不同的，松散耦合的实体。数据移动和加载/资源控制具有明确的界限。可以轻松移动到其他实例或服务器以进行更好的性能管理，而成本并不是主要问题。请注意，最简单的！=最省力或省力。它实际上还有很多任务，但是它们都是简单的任务，有两个重要的例外：
约束执行-SQL Server中没有跨数据库约束之类的东西因此，您需要确定这是否是一笔交易
。
跨数据库查询使用分布式查询，该查询仍然取决于不推荐使用的OLEDB。这意味着您可能
遇到新数据类型的问题，并且如果遇到性能问题，则不太可能解决它们
归档模式或只是归档表有点问题实施起来更复杂，但更容易使用。同一数据库中的所有对象意味着您不必复制和维护访问控制。无需跨数据库查询即可简化性能调整，监视，故障排除等操作。
表分区是一个很好的解决方案，它提供了归档表/架构的许多优点，但对用户/查询。也就是说，这是实施起来最复杂的过程，需要对初学者来说不容易的持续护理。
一些重要的注意事项：
查询是否定期返回历史/冷数据或不经常访问冷数据？
历史数据是不可变的还是会定期更新/删除？
310m行是否为“中等”（假设全部集中在1个表中），具体取决于行大小。您有行大小数据吗？那310m行有多少GB？
那张桌子的增长率是多少？
您能够修改应用程序代码及其SQL查询吗？
这些是重要的考虑因素，因为它们可能会对您选择的解决方案产生重大影响，甚至可能不允许某些解决方案。例如，如果您的历史数据得到定期（每周一次以上）的修改/更新，则使用单独的数据库意味着您必须使用DTC进行这些查询或手动管理交易安全性（不琐碎以确保始终正确）。成本比不变的历史数据高得多。
此外，如果您要升级，请考虑使用2016年和新的Stretch Database功能：https://msdn.microsoft.com/zh-cn /library/dn935011.aspx
#5 楼
由于以下原因，我希望将数据库拆分为单独的逻辑数据库：1。资源需求
通过将其拆分成单独的数据库，可以将其存储在其他驱动器上，并以与主要生产数据不同的速率对其进行监视。
2。性能
通过将数据拆分到一个单独的数据库中，可以减小主生产数据库的大小，从而提高整体性能。
3。更简单的备份
与主SQL数据库中的“活动/当前”记录相比，备份存档的数据可能并不重要。这可能意味着可以减少备份备份数据的频率。同样，由于记录存档数据的方式的顺序性质，可能一次备份存档数据库的各个部分，然后再也不备份。例如。一旦将存档数据写入2014年的更改存档数据库，该数据将再也没有任何变化。
注意：我想您对许多问题的答案都取决于您的情况，性质数据和您遇到的性能问题。
评论
可能值得一提的是您使用的是哪个版本，以及std / ent等。感谢您提供此提示，我已在其他信息中添加了版本。 std / ent是什么意思？ :-)
抱歉，标准版或企业版。
嗯，好的：-)这是企业版