有谁知道SQL Server 2008中的表大小的任何上限。我有一个朋友谁想要在一个表中保存约9亿logging。 我对有关logging一无所知，或者它将被读取/更新的程度如何。
显然，他们需要考虑索引和磁盘IO，但是我想知道是否有人在SQL Server 2008中可以共享大表的经验。
我有一个数据库，它有一个单一的表格，其中有18亿条logging（是的，一个B不是M），现在。 在同一个数据库中还有另外一个表，大约有7.4亿条logging。
总数据库大小约为300GB。
服务器运行得很好。 这是一款四核Xeon，具有32GB内存和非常快速的磁盘arrays。
至于提示和技巧：
认真思考为什么你想要这么多的数据。 在任何一个时间处理都是很好的。 另外，一旦build立起来，忘记了改变索引，列或其他任何东西。 这些操作需要很长时间才能完成。
认真思考为什么你想要这么多的数据。 是的，我正在重复自己。 如果可能的话找另一种方法 恢复这个大小的数据库是一个完整的PITA，可能需要很长时间…像一天左右。
如果可能的话，以一些有意义的方式汇总数据。 如果使用数据进行趋势分析，请尝试尽快完成计算并丢弃基础数据。 当然，如果由于某种原因必须保留基础数据，请将其存储在平面文件或其他内容中。
不要使用这种数据库大小的任何forms的encryption。 如果你的数据要求，那么计划在硬件上花费很多钱（如在$ 1M +范围内）。
把你的时间和testing不同的恢复模式..正确的下到硬交易中的服务器启动。 走着瞧吧。 我发现“简单”最适合我。
我的数据大部分是事务性的，坦率地说，不是关键任务。 如果整个分贝突然落在它的脸上，好吧，几乎没有什么重大的眉毛可以提高。
数据库服务约150个请求/秒。 其中99.999％是写入。 每天晚上，我们将获得的信息汇总到汇总表中。 有一个小仪表盘网站，可能有5个人用来查看历史/每日摘要是什么。
你真的想找什么样的信息？
此MSDN文档说表大小是“受可用存储限制”。 我没有足够的SQL Server大表的经验给你任何性能指导，但不知道有关logging或读/写模式的任何事情，我不认为其他任何人都可以帮助。
按照任何标准，这是很多的logging。 有大量的数据处理技术，但…没有任何可能的方式，任何人都可以借出一个意见，没有更多的信息，你的朋友正在试图解决的问题。