Skip to content

Added link to Replication Log Reader Agent documentation #10065

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 22, 2025
Merged

Added link to Replication Log Reader Agent documentation #10065

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions docs/relational-databases/track-changes/about-change-data-capture-sql-server.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -105,8 +105,8 @@ The capture process responsible for populating the change table accommodates a f
The capture process is also used to maintain history on the DDL changes to tracked tables. The DDL statements that are associated with change data capture make entries to the database transaction log whenever a change data capture-enabled database or table is dropped or columns of a change data capture-enabled table are added, modified, or dropped. These log entries are processed by the capture process, which then posts the associated DDL events to the cdc.ddl_history table. You can obtain information about DDL events that affect tracked tables by using the stored procedure [sys.sp_cdc_get_ddl_history](../system-stored-procedures/sys-sp-cdc-get-ddl-history-transact-sql.md).

> [!WARNING]
> - **MaxCmdsInTran** was not designed to always be turned on. It exists to work around cases where someone accidentally performed a large number of DML operations in a single transaction (causing a delay in the distribution of commands until the entire transaction is in the distribution database, locks being held, etc.). If you routinely fall into this situation, review your application logic to find ways to reduce the transaction size.
> - **MaxCmdsInTran** is not supported if the given publication database has both CDC and replication enabled. Using **MaxCmdsInTran** in this configuration may lead to data loss in CDC change tables. It may also cause PK errors if the **MaxCmdsInTran** parameter is added and removed while replicating a large Transaction.
> - [**MaxCmdsInTran**](../replication/agents/replication-log-reader-agent.md#-maxcmdsintran-number_of_commands) was not designed to always be turned on. It exists to work around cases where someone accidentally performed a large number of DML operations in a single transaction (causing a delay in the distribution of commands until the entire transaction is in the distribution database, locks being held, etc.). If you routinely fall into this situation, review your application logic to find ways to reduce the transaction size.
> - [**MaxCmdsInTran**](../replication/agents/replication-log-reader-agent.md#-maxcmdsintran-number_of_commands) is not supported if the given publication database has both CDC and replication enabled. Using **MaxCmdsInTran** in this configuration may lead to data loss in CDC change tables. It may also cause PK errors if the **MaxCmdsInTran** parameter is added and removed while replicating a large Transaction.


## Agent jobs
Expand Down