标签: change-tracking

我们有一个只有大约 500 行的表，但这对我们来说非常重要。

我想查看发生在此表上的所有更改。应使用时间戳跟踪更改。

我不希望在应用程序代码中进行跟踪，因为我也想跟踪通过psqlshell发生的更改。

我对特定于 PostgreSQL 的解决方案感到满意，因为在这种情况下我没有使用不同的数据库。

在我的应用程序中，有一个运行在 SQL Server 2012 上的数据库，我有一个作业（计划任务），它定期执行一个昂贵的查询并将结果写入一个表，稍后可以由应用程序查询。

理想情况下，我只想在自上次执行查询后发生更改时运行该昂贵的查询。由于源表非常大，我不能只选择所有候选列的校验和或类似的东西。

我有以下想法：

• 每当我更改源表中的某些内容时，将上次更改的时间戳、“必须是查询”标志或类似内容显式写入跟踪表。
• 使用触发器来做同样的事情。

但是，我真的很想知道是否有一种轻量级的方法来检测表上的更改，而无需我明确跟踪写入。例如，我可以获取ROWVERSION表格的“当前”或类似的信息吗？

我有这个数据库表，它应该使全文索引保持最新。但是我根本没有看到它发生（日志中没有错误，因为我看到的最后一个日志是我手动触发它时）。

这是我所看到的......

但在桌子上...

这可能是它不会自动发生的原因吗？

在解决将断开连接的设备与中央数据库服务器同步的问题时，我们在服务器上升级到 SQL Server 2012 后遇到了问题。看起来 CHANGE_TRACKING_MIN_VALID_VERSION 返回的值比它应有的值高 1（或至少比升级前的值高）。

我一直在研究如何设置简单示例的Arshad Ali 的精彩示例。

我已经运行了从 #1 到 #5 的脚本，以在 SQL Server 2008 和 2012 环境中的 Employee 表中插入、删除和更新一行。

在 2008 年，以下语句返回 0：

SELECT CHANGE_TRACKING_MIN_VALID_VERSION(OBJECT_ID('Employee'))

在 2012 年，它返回 1。

在测试中通过更多脚本 (6-8) 工作时，我将保留期设置为 1 分钟，以期强制执行清理操作。我离开了一天，显然它运行了一夜。

在 2008 年的实例中，CHANGE_TRACKING_CURRENT_VERSION 和 CHANGE_TRACKING_MIN_VALID_VERSION 是相等的 (11)。在 2012 年的实例中，CHANGE_TRACKING_MIN_VALID_VERSION 比 CHANGE_TRACKING_CURRENT_VERSION (11) 高一 (12)。当数据库长时间空闲时，这可能会对同步过程产生影响。我们发现进程可能会陷入循环，尤其是在执行以下测试以确定是否需要重新初始化而不是同步时：

IF CHANGE_TRACKING_MIN_VALID_VERSION(object_id(N'dbo.Employee')) > @sync_last_received_anchor 
       RAISERROR (N'SQL Server Change Tracking has cleaned up tracking information for table ''%s''...

有没有其他人经历过这种行为变化？有人有解释吗？

我们将部署带有只读辅助服务器的 SQL Server 2012 可用性组，并希望在使用 CDC 或更改跟踪的同时针对辅助服务器执行 SSIS 提取（目前尚未决定使用哪个）。

我希望 CDC 和 CT 的底层实现将允许它们的功能存在并在辅助设备上使用，但尚未能够找到任何以这种方式或另一种方式说明的内容。

有没有人有任何经验（以及更好的官方文档）指出此解决方案的可行性（或不可行）？

我们现在倾向于使用变更跟踪，因为我们对历史数据没有硬性要求，但我希望能够识别任一实施的任何问题/风险。

我正在考虑在我的系统中提供数据库级别的更改跟踪。我需要能够跟踪实体级别的更改，而不仅仅是单个表。

现在，我们在每个感兴趣的表上都有触发器，将表 PK 写入Change_Event表中。然后我们可以查询该表，并将其归结为代表整个实体的 PK。然后，我们可以检索该实体的数据并对其执行相关操作。

作为示例，请考虑以下（简化的）示例：

CREATE TABLE Employee
(
    Id INT IDENTITY PRIMARY KEY,
    Name VARCHAR(250) NOT NULL,
    Telephone VARCHAR(15) NOT Null
);

CREATE Table Visit
(
    Id INT IDENTITY PRIMARY KEY,
    VisitDate DATETIME2 Not NULL,
    [Address] VARCHAR(500) NOT NULL,
    VisitorId INT NOT NULL,
    CONSTRAINT FK_Visit_VisitorId FOREIGN KEY (VisitorId) REFERENCES Employee (Id)
);

INSERT into Employee (Name, Telephone)
VALUES ('John Doe', '123456789'),
('Jane Smith', '999555333');

INSERT INTO Visit (VisitDate, Address, VisitorId)
VALUES (SYSDATETIME(), '123 Fake St', 1), …

我在 Windows Server 2012 R2 Standard 6.3 上使用 Microsoft SQL Server 2016 (SP2-GDR) (KB4505220) - 13.0.5101.9 (X64) Jun 15 2019 23:15:58 版权所有 (c) Microsoft Corporation 标准版（64 位） （内部版本 9600：）

数据库大小约为 870 GB。这是 SQL 标准，我在服务器上有 128 GB 的 RAM。数据库位于 SSD 驱动器上。数据文件与日志文件位于不同的驱动器上，Tempdb 也有自己的 SSD 驱动器。服务器平均获得大约 1200 个查询/秒，它可以高达 2000 个查询/秒。重新编译保持较低，每秒只有 1 到 8 次。页面预期寿命不错，平均 61 分钟。

服务器有 6 个物理核心 + 超线程。

我们在数千个设备连接并尝试将更改与跟踪键同步的系统上大量使用 SQL Server 的更改跟踪。

它通常运行良好，但有时，有一天或另一天，服务器的闩锁会猛增，从 0 毫秒到平均 60677 毫秒。

当我检查正在运行哪些查询时，我只能看到同步查询，全部被阻止，带有“PAGELATCH_UP”，全部试图访问更改跟踪表，被阻止的 300 多个查询。

我有几个问题：

• SQL Server 是否在查找更改跟踪更改时锁定整个表？
• 使用 SQL Entreprise 会得到更好的结果还是不会改变任何东西？
• 知道为什么更改跟踪在大多数情况下运行良好，但每周都没有明显原因崩溃吗？

这些是我的更改跟踪表大小。我的查询阻塞的表是前三个表，只有几 …

我在一个大约有 300 万行的表上打开了 SQL Server 更改跟踪。

开启变更追踪：

ALTER DATABASE FooDB
SET CHANGE_TRACKING = ON
(CHANGE_RETENTION = 10 DAYS, AUTO_CLEANUP = OFF)

ALTER TABLE [dbo].[fooTable]
ENABLE CHANGE_TRACKING
WITH (TRACK_COLUMNS_UPDATED = OFF)

如果我单独编辑行，一切都很好，每个插入/更新/删除都会存储一个更改。

如果我运行更新多行的更新查询，我只会在更新中获得第二行的更改记录。

所以：

UPDATE fooTable SET name = UPPER(name) where id between 100 and 200

其次是（以确保对每一行进行实际更新）

UPDATE fooTable SET name = LOWER(name) where id between 100 and 200

仅生成记录 101 的更改记录。

SQL Express 2014

多年来，我们一直在使用变更跟踪解决方案来导出用于 BI 目的的增量。但它直接在生产数据库上运行。为了降低系统负载，我们希望它在一组单独的数据库上运行。

我们通过恢复备份和添加事务日志备份来创建这些数据库。数据库处于备用模式，所以只读。

切换到这些新数据库后，我们开始在处理增量并检查计数与我们随增量提供的总计数后看到差异。

差异通常只是每个表的几条记录，但在具有数百万行且频繁发生数千次变异的表上。并且事务日志备份每 15 分钟完成一次。而且这些更改看起来比这些备份之一的内容要小得多。

所以我们觉得这与未提交的事务有关。

我们发现了这个，它解释了一个类似的问题：

更改跟踪当前版本并不总是可靠的

但是使用MAX(commit_ts)fromsys.dm_tran_commit_table而不是的解决方案CHANGE_TRACKING_CURRENT_VERSION()似乎并没有解决差异。

由于变更跟踪功能似乎也在内部使用当前版本。

在追加另一个事务日志备份后，先前返回的变更跟踪版本似乎再次与数据一致。还将数据库联机，也解决了该问题。

使数据库联机不是一种选择，因为我们每天都需要再次进行完全恢复以使数据保持最新。与当前情况相比，新恢复的数据库的性能相当糟糕。

问题是，我们如何从处于待机模式的数据库中获取最后一个一致的更改跟踪版本。

我在 Windows Server 2012 R2 Standard 6.3 上使用 Microsoft SQL Server 2016 (SP2-GDR) (KB4505220) - 13.0.5101.9 (X64) Jun 15 2019 23:15:58 版权所有 (c) Microsoft Corporation 标准版（64 位） (Build 9600

:) 我有多个数据库，在高插入/更新表上启用了 CHANGE_TRACKING。我的保留期是 2 天，启用了自动清理。数据库兼容性设置为 130 (SQL 2016)

跟踪的一些表很大，每天可能有数千次插入/更新。这是change_tracking 表的内容。

这是我们为获取更改而执行的查询示例。

SELECT Columns
FROM CHANGETABLE(CHANGES MyTable, @TrackingKey) AS CT 
INNER JOIN MyTable b ON b.Key=CT.Key
WHERE b.Status = 1

我不时看到在某些表上获取最新更改的查询需要很长时间才能完成并生成大量 CPU。为了解决这个问题，我在每晚运行的更改跟踪表上设置了每日更新统计信息。它有很大帮助，但有时，在用户活动频繁的日子里，即使在白天，我也必须运行此更新统计信息。当我在这些表上运行更新统计信息时，情况恢复正常，获取最新更改的查询可以正常运行一段时间。

我们对应用程序的一些重要部分使用更改跟踪，因此它必须起作用。

是否有任何选项，我可以启用跟踪标志来帮助更改跟踪统计信息？任何对高活动数据库进行更改跟踪的人都可以给我一些建议吗？

所以我最终决定做一个工作来检查自上次统计更新以来更改跟踪表是否更改了超过 20k 行，然后该作业将更新更改跟踪表上的统计信息。

如果它可以帮助其他人，我会将查询放在这里。此查询为您提供更改跟踪表的所有统计信息，其中该表自上次更新统计信息以来更改了 2 万次以上。它为您提供了一个带有要更新的 object_name 的“更新统计信息”。您只需要在您的数据库上运行查询的结果。我会根据我的工作量对其进行微调，看看 20k 是否是最好的数字。

SELECT 
 -- st.object_id                          AS [Table ID]
 --, OBJECT_NAME(st.object_id) …