几乎没有剩下的地方,所以我决定删除所有数据,比如说,2008年.执行删除查询(清理了大约10 000 000行)和清理事务日志后我发现我的操作对数据库大小没有影响.还有什么我必须做的吗？
解决方法
在理想的世界中 – 您将创建具有足够自由空间的数据库.我称之为“正确调整大小”您的数据库.你可以让这个免费空间在那里而不是努力让它回来,并保持你的总尺寸在你的二手尺寸.为什么？因为你的数据库最终会再次增长..然后你会再次萎缩..而你将陷入这种无用的缩减模式,随后是增长 – 而且整个时间,正如一些人已经指出的那样,你将成为增加你的索引碎片.
我在博客上写过这里,我告诫人们要“Don’t touch that shrink button!”,但有时……有时你需要.如果你有一个大型数据库,只需释放大量空间,并且不要期望重新进入它 – 那么可以考虑缩小为一次性操作,只要你可以通过重建来处理你的索引碎片他们.缩小操作可能非常耗时,因此您需要将其计划在可以支付缩减运行价格的时间.创建一个空数据库并将数据复制到其中的方法很有效 – 但是对于大型数据库和大量数据而言,这可能变得非常困难.
如果您打算通过正常使用和增长模式将该空间添加回数据库,那么您可能只想将空间留在那里.
也
你说你“清除”了你的交易日志.我很想知道你是如何做到这一点但是当你阅读我分享的帖子和系列中的其他人时,你会看到一些关于事务日志管理的提示.但简而言之 – 如果您处于完全恢复模式,则应该进行常规日志备份以保持日志重用.否则 – 在完全模式下没有日志备份 – 日志文件不断增长,不断增长和增长,并始终保存您已完成的工作,因为您告诉sql您不仅要维护该日志以进行崩溃恢复,而且希望保留手动备份它以重放事务/撤消事务以恢复到特定时间点以进行恢复…如果您处于简单状态并且看到日志过度增长,这可能是(通常)您正在做的很多信号在一个事务中工作(无论你是否说BEGIN TRAN …做工作…. COMMIT TRAN或者你是否只发出了一个大的DELETE语句并在一个隐式事务中删除了一大堆数据.)
我也假设您正在寻找文件系统上的这个可用空间.如果您正在sql中查找它并且在您拥有的那个大文件中 – 如果您在操作后立即查看,那么您可能正在等待ghost清理完成. Paul Randal blogs about Ghost Cleanup.
