从包含 LOB 的表中删除数据不会减少表或数据库内部报告的数据量

Question

运行 SQL Server 2012 标准，同时使用复制数据和日志传送。每隔几分钟创建一次事务日志备份。

这个问题与文件系统报告的空间量无关。

我们有一个包含四个 VARCHAR(max) 列的日志表。该表目前包含大约 180 GB 的数据。该表以每月大约 10 GB 的速度增长。

为了为未来的增长腾出空间，我最近删除了（在 36 小时内以块为单位）接近 30% 的数据。

根据表的大小和删除的行数，我预计表的大小将减少大约 55-60 GB。我通过抽取样本并计算平均行大小，然后将其乘以要删除的行数来验证这一点。但是，删除完成后，表大小并没有改变。

虽然我不希望缩小 .mdf 文件的大小，但我确实检查了数据库是否有任何可以缩小的可用空间，但可用空间为 0%。

所以 - 我很困惑。我已经验证我从表中删除的数据不再存在。我什至将它与备份进行了比较，以获得前后对比。数据库中的行数发生了变化，但表的数据空间并没有减少。

我的问题是：
1）为什么从表中删除数据没有减少表的大小？
2）我能做些什么来实际减少表格的大小？

编辑：

• 我通过调用 sp_spaceused 'tablename' 来确定表使用的空间。
• 我在调用 sp_spaceused 之前使用了 dbcc updateusage (0, tablename)。
• 我不想释放磁盘空间 - 尽管分析表明有 0% 的空间可供回收。
• 我已经使用（ LOB_COMPACTION = ON ）运行了一个索引重组。碎片率低于 1%。
• 表不是堆。表定义如下。

 CREATE TABLE [dbo].[LARGE_LOG_TABLE](
  [ID] [varchar](36) NOT NULL,
  [DOC_ID] [varchar](36) NOT NULL,
  [REQUEST_DATA] [varchar](max) NULL,
  [REQUEST_DATA_XSLT] [varchar](max) NULL,
  [RESPONSE_DATA] [varchar](max) NULL,
  [RESPONSE_DATA_XSLT] [varchar](max) NULL,
  [ACTIVE_FLAG] [varchar](1) NULL,
  [CREATED_BY] [varchar](100) NULL,
  [DATE_CREATED] [datetime] NULL CONSTRAINT [DF_LARGE_LOG_TABLE_CREATE_DT]  DEFAULT (getdate()),
  [USER_LAST_UPDATED] [varchar](100) NULL,
  [DATE_LAST_UPDATED] [datetime] NULL CONSTRAINT [DF_LARGE_LOG_TABLE_LAST_DT]  DEFAULT (getdate()),
 CONSTRAINT [PK_LARGE_LOG_TABLE] PRIMARY KEY CLUSTERED 
 ( [ID] ASC ) ON [PRIMARY] ) 
 ON [PRIMARY] 
 TEXTIMAGE_ON [PRIMARY]

编辑2：

SELECT * FROM sys.dm_db_index_physical_stats (db_id(), OBJECT_ID('database..LARGE_LOG_TABLE'), default, default, default)

编辑 3：

在删除查询中提供的问题的答案似乎没有在 SQL Server 上打开空间是指释放磁盘空间/缩小数据库的物理大小。此问题是指删除包含 LOB 数据的行，但数据库（内部）显示 LOB 数据尚未删除。我们删除了 600000 行数据，但表级（不是文件系统级）使用的空间仅减少了几个字节 - 而不是预期的 60 GB。这个问题是关于删除 LOB 数据的。

Answer 1

@edze 问了一个很好的问题。我知道 LOB 与表数据分开存储（用指针引用存储位置），但我不知道它们具体存储在哪里。

在搜索有关 LOB 数据存储位置的更多信息时，我发现了以下链接：

http://itknowledgeexchange.techtarget.com/sql-server/deleting-lob-data-and-shrinking-the-database/

这里的关键要点（重点是数据库收缩）如下：

Do the database deletion as normal. 
Then backup and restore the database. 
Then do the shrink, followed by rebuilding the clustered indexes in order to fix the fragmentation issue which the shrink will introduce.

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/f80ad8c7-e6c9-4538-a89b-8d6727050b9c/release-space-used-after-sql-server-delete-in-rows-with- blob-varbinarymax-using-textimage-on?forum=sqldatabaseengine

这里的关键是：

1. 重建表的聚集索引。
2. 执行 DBCC UPDATEUSAGE (0)

由于这是标准版，重建将需要长时间锁定 - 但这看起来是恢复空间的唯一方法。