代码之家  ›  专栏  ›  技术社区  ›  anon

数据库太大了

  •  3
  • anon  · 技术社区  · 15 年前

    我有以下问题。 我们有一个在数据库中存储二进制文件的数据库。 我们知道数据库的大小可能很大,所以我们从数据库中删除了所有二进制文件,并在其上使用了任务“收缩”。 这样我们希望数据库会小得多。 结果如下:

    移除前大小为:20G字节 删除后大小为:25GB(包括日志文件) 收缩后的大小为:13千兆字节

    现在我不知道13个gig是从哪里来的,数据库中最大的一个表是一个logtable,它是1.3 gig,其余的加起来不需要200 MB…

    收缩任务无法删除的日志文件中是否仍有一些数据? 这个问题有解决办法吗?

    4 回复  |  直到 11 年前
        1
  •  3
  •   Robin Day    15 年前

    如果您的恢复模型是“满的”,并且您没有备份,然后收缩您的事务日志,那么它仍然可能是大的。

    根据您的情况,收缩事务日志的最简单方法之一是将恢复模型设置为Simple,然后收缩事务日志文件,然后将恢复模型设置为Full。但是,如果这是一个生产系统,您可能需要一个时间点恢复,那么您应该改为执行事务日志的备份。

        2
  •  3
  •   Santiago Cepas    15 年前

    要获取有关空间使用的详细信息,可以尝试:

    EXEC sp_spaceused;
    
        3
  •  0
  •   HLGEM    15 年前

    请记住,在听取Robin Day的建议并缩小日志后,设置事务日志备份(不仅仅是数据库备份,因为它们不会使日志保持如您所发现的那样小),否则日志将再次变大。我们的事务日志每15分钟备份一次。您的日程安排可能需要或多或少地频繁,这取决于如果出现故障,您可以损失多少数据。至少我会每天做一次日志备份,以保持日志的大小合理。

        4
  •  0
  •   onupdatecascade    15 年前

    一种可能是删除数据的表是一个堆(意味着没有聚集索引),当从堆中删除数据时,为表分配的空间不一定被释放。从MS查看本文: http://support.microsoft.com/kb/913399