标签: ghost-cleanup

我有几个表，行数在 5M 到 1.5G 之间

每个表都有其 BLOB 字段，其大小从 100 字节到 30 兆字节不等，并存储为“行外大值类型”= ON

表存储在不同的文件组中，每个文件组有 3-4 个文件@不同的 LUN@非常快的 SAN

这些表每天增长 5-100 Gb 和 600k - 1.5M 行

经过一段时间后，从 2 周到 6 个月不等，一些行被删除或移动到存档数据库，因此 - 工作表中没有任何超过 6 个月的行。

服务器当前配置：

• SQL 服务器引擎是 2008 R2 SP1 Enterprise @ 24 核，@ 64Gb RAM
• SQL Server 使用额外的启动标志运行：

-T 3640; （消除了为存储过程中的每个语句向客户端发送 DONE_IN_PROC 消息。这类似于 SET NOCOUNT ON 的会话设置，但是当设置为跟踪标志时，每个客户端会话都以这种方式处理）

-T 1118;（将 tempDB 中的分配从一次 1pg（对于前 8 页）切换到一个范围。）

-T 2301;（启用特定于决策支持查询的高级优化。此选项适用于大型数据集的决策支持处理）

-T 1117;（一次增长所有数据文件，否则依次增长。）

-E; （增加为文件组中每个文件分配的区数。此选项对于运行索引或数据扫描的用户数量有限的数据仓库应用程序可能有用）

-T 834; （导致 SQL Server 对为缓冲池分配的内存使用 Windows …

我正在运行一个高事务数据库（平均约 175k 事务/分钟，每小时添加和删除近 900 万条记录）

直到最近，这还不是什么大问题，因为我们已经添加和删除了大约 750 万条记录，但是随着最新数据的涌入，幽灵清理似乎无法跟上清理表/索引上未使用的空间。

几天前，我们在 16 个表（主要是其中的 2 个）中达到了 53 GB 的“未使用空间”，因此开始研究 ghost 清理过程，发现它每 5 秒运行一次，并运行超过 10 页。

我目前的解决方案是清晨我正在运行以下命令的三个线程：

DECLARE @2hours datetime = dateadd(hour,2,getutcdate())

WHILE getutcdate() < @2hours
BEGIN
    DBCC FORCEGHOSTCLEANUP ('DBNAME') WITH  NO_INFOMSGS
END

赶上前一天晚上的积压（当我们大部分删除发生时）

我想知道是否有任何方法可以将默认设置从 5 秒和 10 页更改为每秒一次或运行超过 20 页，有没有办法做到这一点，或者我应该继续启动多个清理过程来清除数据，或者是否有任何其他操作可以帮助解决此问题

重新索引至少每周一次在最受影响的索引上运行（大多数是每隔一天）

AlwaysOn 高可用性集群上的 SQL Server 2012 Enterprise SP3_CU8（明天升级到 CU9）也带有复制（在单独的服务器上分发）

我发现很多的ShrinkD，ghostcleanuptask和BTree Split/Shrink我的SQL Server日志。

在这些记录事件的时候，性能计数器显示lazy writes很慢，日志刷新率很高，write/sec接近30000，磁盘IO也很高。

我确定服务器流量是正常的，当时没有出现数据文件异常增长，但是日志文件比平时大了一倍。我使用该dump_log()函数来获取日志的统计信息：

我的配置：

• Windows Server 2008 sp2
• SQL Server 2014
• 数据库 target_recovery_time = 60 秒
• 数据库自动收缩和索引自动收缩 = false
• 每小时日志备份
• 物理盘：pcie ssd 3.0T，使用率70%

我最近：

• 清理无用索引
• 重组碎片索引
• 增加了每天500w左右的自动归档数据操作备份和删除

每天4:00-5:00存档，我怀疑ghost清理和我的物理备份删除和存档有关。日志文件是昨天同一时间的两倍。

我的问题：

• SQL Server 日志中的“缩小”是什么？
• 是收缩数据库吗？网上查不到相关信息，如果AUTO_SHRINK触发了，没有skrink job，是怎么触发的？谢谢。

属于 SQL Server Always Availability Group 的一部分的数据库（具有用于横向扩展只读工作负载的同步和异步LOB_DATA可读辅助数据库）正在经历分配类型的版本幽灵记录的累积。

这种情况发生在应用了高级别的INSERT操作的表上。

REBUILD对该表的聚集索引的删除将删除分配类型的任何版本幻影记录IN_ROW_DATA，但不会删除分配类型的版本幻影记录LOB_DATA。

执行手动故障转移会删除版本幻影行，但这是不可取的。

当我调查版本幽灵行累积的根本原因时，是否有其他方法可以删除分配类型的版本幽灵记录LOB_DATA？