Questions tagged «change-data-capture»

4
何时使用CDC跟踪历史记录?
SQL Server更改数据捕获是一项功能,可从SQL Server事务日志中读取历史数据并将其存储在特殊表中。 然后,通过使用特殊的表值函数(TVF),它允许用户查询此数据,从而有可能获得特定表上的所有更改,或者仅获得特定时间内由更改导致的净更改。 CDC具有一定优势 可以将其配置为仅跟踪某些表或列。 它能够在一定程度上处理模型更改。 它不会像触发器那样严重影响性能,因为它可以与事务日志一起使用。 它很容易启用/禁用,并且不需要在表上跟踪其他列。 它还有一些缺点: 历史数据的数量可以快速变得巨大。 您无法跟踪更改的对象(至少不能删除)。 由于历史数据是基于事务日志的,因此需要花费一些时间来追赶。 它取决于SQL Server代理。如果代理未运行或崩溃,则不会跟踪任何历史记录。 我已经阅读了很多有关CDC的文章,虽然我现在知道如何使用它,但是我仍然不确定它是否适合我。 CDC对于哪些任务/方案是正确的工具?(例如,是否允许用户将数据对象还原到某个时间点?审核?显示数据的完整历史记录?) 您什么时候不应该使用CDC,而应该使用基于触发器的自定义解决方案? 是否可以在运营数据库中使用CDC并在运营应用程序中使用CDC数据?(例如,将其显示给最终用户)还是这显然是滥用此功能? 我通常听到CDC是一种审核工具,但是这不是SQL Server Audit的目的吗?它们是否都是用于同一任务的不同工具?还是CDC可以用于其他用途? 我目前的情况是要求我构建一个可靠的数据框架,该框架应该作为将来多个应用程序的基础。确切的要求是模糊的,但是一个要求是它应该能够跟踪数据历史记录,并将旧条目以及其他表中的所有相关数据还原。我现在正在评估CDC作为一种选择,但是不确定是否要这样做,因为我找不到真正推荐的用例。 虽然我很欣赏针对我的特定情况的建议,但是答案应该提供有关何时或何时不使用Change Data Capture的一般建议。

3
在不使用触发器的情况下,在SQL Server中查找触发查询的客户端的身份?
我目前正在使用Change Data Capture(CDC)来跟踪数据更改,并且希望跟踪提交进行了更改的查询的客户端的主机名和IP地址。如果有5个不同的客户端通过相同的用户名登录,则一个客户端将面临跟踪5个客户端中的哪一个引发查询的难题。我发现的其他可能的解决方案包括使用以下命令更改CDC表: ALTER TABLE cdc.schema_table_CT ADD HostName nvarchar(50) NULL DEFAULT(HOST_NAME()) 但是,这将返回在其上触发查询的服务器的主机名,而不是触发该查询的客户端的主机名。 有办法解决这个问题吗?这将有助于记录客户端的主机名或IP地址(或其他唯一身份)。我不想使用触发器,因为它会减慢系统速度,而且CDC还会生成系统表,因此显然不可能在上面设置触发器。

3
变更数据捕获-如何知道谁进行了变更?
跟踪谁进行了CDC识别的更改。 按照我的datetime hack,我尝试了相同的方法,将suser_sname添加为cdc更改跟踪表上具有默认值的新字段。但是,这似乎返回了cdc进程的所有者,而不是在基表上发起更改的用户。我也尝试了original_login,但是返回了SQL服务帐户登录名。同样,可能与cdc进程相关,而不与发起更改的用户相关。 我在堆栈溢出中发现了一个类似的问题,但是除了从前端或通过触发器跟踪更改之外,没有其他答案,这似乎无法实现使用cdc的目的。我不会重新发布,但是由于原始版本存在stackoverflow上,所以我想在这里尝试一下,特别是如果R2或2012已引入一种更好的方法。 简而言之:我怎么知道谁在变更数据捕获中进行了更改?

1
如何判断备份文件是否包含CDC?
使用SQL Server 2008到2014年,我知道如何在启用更改数据捕获(CDC)的情况下备份和还原数据库,但是我正在寻找一种查询完整备份文件以确定其是否包含CDC数据的方法。 最好的办法是RESTORE FILELISTONLY从数据库获取文件列表,但获取CDC状态以确定还原是否需要使用KEEP_CDC标志? 有没有办法确定备份是否包含CDC数据? 谢谢!

2
更改数据捕获和__ $ update_mask二进制文件
我们正在使用CDC捕获对生产表所做的更改。更改后的行将被导出到数据仓库(informatica)。我知道__ $ update_mask列存储以varbinary形式更新的列。我也知道我可以使用各种CDC函数从该掩码中找出那些列是什么。 我的问题是这个。谁能为我定义该掩膜后面的逻辑,以便我们识别仓库中已更改的列?由于我们在服务器外部进行处理,因此无法轻松访问那些MSSQL CDC函数。我宁愿自己在代码中分解面具。对于此解决方案,SQL端的cdc函数的性能存在问题。 简而言之,我想通过__ $ update_mask字段手动识别已更改的列。 更新: 作为替代方案,也可以将人类可读的变更列清单发送到仓库。我们发现执行此操作的性能远胜于原始方法。 以下CLR对这个问题的回答符合这种选择,并包括为将来的访客解释口罩的详细信息。但是,对于相同的最终结果,使用XML PATH接受的答案是最快的。

3
捕获SQL Server CDC中更改的日期时间
因此,我们已经开始探索在我们的一个生产数据库中使用变更数据捕获。我们想知道每次更改的日期时间。通读演练和教程等内容,似乎标准方法是使用LSN与cdc.lsn_time_mapping系统表相关。当谈论一天中成千上万的变化时,这种方法行得通,但不是很简单,也不是很有效。 在测试环境中,我对变更跟踪表进行了以下调整。我发表了一条ALTER TABLE声明,在末尾添加一列,[__ChangeDateTime]并将其设置为默认值GetDate()。该方法似乎有效,更改跟踪仍然正常运行,捕获了日期时间。 但是混用系统表会让我有些紧张。 如果这不是Microsoft从一开始就添加的系统字段,则必须说明其原因。由于他们改而选择了LSN来cdc.lsn_time_mapping方法,我是否通过以这种方式创建自己的hack来解决问题? 更新: 在测试过程中发现,有时GetDate()不够精确,无法满足我们的需求-多个更改同时共享。建议使用sysdatetime()和datetime2将值移至纳秒级。显然只有2008年以上的选项。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.