Question

我们有一个包含blob列和其他简单字段的表。行数约为6K，所有行的blob列的长度总和约为30MB。但是，当我们运行查询以查找实际占用的表空间时，它大约为10GB（数据库大小本身为11GB）。我们想知道是否，

中止事务是否仍会阻止为blob分配的空间，就好像它已经提交一样？
虽然记录数量没有显着增加，但数据库的大小在几天内从2GB跃升至约10GB。运行查询以查找真实的表空间显示，具有blob的单个表具有大约8GB的数据（仅有6K记录，并且blob的数据长度总和仅提供30MB）。

我们可以做些什么来解决空间问题并解决为什么数据库的大小必须增加这么多？

Answer 1

完全恢复模式，没有备份？
在备份时打开tran阻止日志清除（运行DBCC OPENTRAN）
许多删除/插入+没有索引维护？（和口味）

这对所有物体说了什么？（我使用的脚本的复制/粘贴）

SELECT
    ds.[name] AS LogicalFileName,
    OBJECT_NAME(p.object_id) AS Thing,
    SUM(au.total_pages) / 128.0 AS UsedMB,
    df.size / 128 AS FileSizeMB,
    100.0 * SUM(au.total_pages) / df.size AS PercentUsed
FROM
    sys.database_files df
    JOIN
    sys.data_spaces ds ON df.data_space_id = ds.data_space_id 
    JOIN
    sys.allocation_units au ON ds.data_space_id = au.data_space_id 
    JOIN 
    sys.partitions p ON au.container_id = p.hobt_id
WHERE
    OBJECTPROPERTYEX(p.object_id, 'IsMSShipped') = 0
GROUP BY
    ds.[name], OBJECT_NAME(p.object_id), df.size
ORDER BY
    ds.[name]

Answer 2

中止交易仍会阻止为blob分配的空间就好像它承诺了？

索引物理更改发生在与逻辑更改不同的事务中。当INSERT需要为表分配新页面以便对新行进行编码时，页面分配将在立即提交的另一个事务上进行。如果INSERT回滚，则页面分配不受影响。想想如果页面分配将被回滚并且另一个插入已经在其中分配了不同的行槽并且提交了该插入，会发生什么。

事情有点复杂，特别是对于BLOB存储滚动，但是想法是BLOB列中的高速率修改可能导致未使用页面的高比率。高回滚率可能会加剧问题。如果对于类型2和3的分配单元，total_pages远高于used_pages，sys.allocation_units将很容易揭示这一点。

你可以尝试（在线）索引重建macking确保LOB_COMPACTION为ON。

SQL Server数据库大小以非常高的速率增加

2 个答案: