sql server 复制

This article will review performance issues in replicating schema changes on tables involved in SQL Server Replication (Merge).

本文将回顾在SQL Server复制（合并）中涉及的表上复制架构更改时的性能问题。

We had SQL Server merge replication configured on one of our databases to replicate data from publisher to subscriber and vice versa. Replicate schema changes was enabled on the publication to send the DDL changes made on replicated tables at publishers to subscribers.

我们在一个数据库上配置了SQL Server合并复制，以将数据从发布者复制到订阅者，反之亦然。 在发布上启用了复制架构更改，以将在发布服务器上对复制表所做的DDL更改发送给订阅服务器。

When we applied the deployment scripts which modify the existing replicating tables by adding new columns or dropping existing columns at publisher, these schema changes took a lot of time to replicate to subscribers. Let us see what happens internally when there is a schema change on the table involved in SQL Server merge replication and why it is taking time to replicate schema changes.

当我们应用通过在发布服务器上添加新列或删除现有列来修改现有复制表的部署脚本时，这些架构更改需要大量时间才能复制到订阅服务器。 让我们看看当SQL Server合并复制所涉及的表上发生架构更改时内部会发生什么以及为什么要花时间来复制架构更改。

To illustrate this let us create a merge publication with replicate schema changes option enabled.

为了说明这一点，让我们创建一个启用了复制模式更改选项的合并发布。

Below are the server and database details in my environment. Please change the T-SQL scripts by replacing your publisher server, database and subscriber server, database names.

以下是我的环境中的服务器和数据库详细信息。 请通过替换发布服务器，数据库和订阅服务器，数据库名称来更改T-SQL脚本。

• Publisher Server: PUBSERV01 发布服务器：PUBSERV01
• Publication Database: test_pub 发布数据库：test_pub
• Subscriber Server: SUBSERV01 订阅服务器：SUBSERV01
• Subscriber Database: test_sub1 订户数据库：test_sub1

Please follow below steps to create table, publication, adding table to publication and creating subscribers using T-SQL scripts.

请按照以下步骤创建表，发布，将表添加到发布以及使用T-SQL脚本创建订阅服务器。

配置SQL Server合并复制 (Configuring SQL Server Merge Replication)

Create table “schema_test” in publisher database and enable database for SQL Server Replication (Merge).

在发布者数据库中创建表“ schema_test”，并为数据库启用SQL Server复制（合并）。

use [test_pub]
CREATE TABLE schema_test (ID INT )use master
exec sp_replicationdboption @dbname = N'test_pub', @optname = N'merge publish', @value = N'true'
GO

Now let us configure merge publication using T-SQL script. Execute sp_addmergepublication at publisher on database that is being published. Replace the snapshot folder as per your need.

现在，让我们使用T-SQL脚本配置合并发布。 在正在发布的数据库上的发布服务器上执行sp_addmergepublication。 根据需要更换快照文件夹。

USE [test_pub]EXEC sp_addmergepublication @publication = N'test',@description = N'Merge publication of database ''test_pub''.',@sync_mode = N'native',@retention = 14,@allow_push = N'true',@allow_pull = N'true',@allow_anonymous = N'true',@enabled_for_internet = N'false',@snapshot_in_defaultfolder = N'false',@alt_snapshot_folder = N'D:\Replication\ReplData',@compress_snapshot = N'false',@ftp_port = 21,@ftp_subdirectory = N'ftp',@ftp_login = N'anonymous',@allow_subscription_copy = N'false',@add_to_active_directory = N'false',@dynamic_filters = N'false',@conflict_retention = 14,@keep_partition_changes = N'false',@allow_synctoalternate = N'false',@max_concurrent_merge = 0,@max_concurrent_dynamic_snapshots = 0,@use_partition_groups = N'false',@publication_compatibility_level = N'100RTM',@replicate_ddl = 1,@allow_subscriber_initiated_snapshot = N'false',@allow_web_synchronization = N'false',@allow_partition_realignment = N'true',@retention_period_unit = N'days',@conflict_logging = N'both',@automatic_reinitialization_policy = 0

Once the publication is created, Navigate to the Local Publications under the replication folder in SQL Server Management Studio. Right click on the publication you created and click on Properties -> Subscription Options and make sure replicate schema changes is enabled.

创建发布后，请导航到SQL Server Management Studio中复制文件夹下的“本地发布”。 右键单击您创建的发布，然后单击属性->订阅选项 ，并确保启用复制模式更改。

Now add table “schema_test” to the merge publication created earlier. Execute below stored procedure on publisher database.

现在，将表“ schema_test”添加到之前创建的合并发布中。 在发布者数据库上执行以下存储过程。

USE [test_pub]EXEC sp_addmergearticle @publication = N'test',@article = N'schema_test',@source_owner = N'dbo',@source_object = N'schema_test',@type = N'table',@description = N'',@creation_script = N'',@pre_creation_cmd = N'drop',@schema_option = 0x000000010C034FD1,@identityrangemanagementoption = N'none',@destination_owner = N'dbo',@force_reinit_subscription = 1,@column_tracking = N'false',@subset_filterclause = N'',@vertical_partition = N'false',@verify_resolver_signature = 1,@allow_interactive_resolver = N'false',@fast_multicol_updateproc = N'true',@check_permissions = 0,@subscriber_upload_options = 0,@delete_tracking = N'true',@compensate_for_errors = N'false',@stream_blob_columns = N'true',@partition_options = 0

Once the table is added to publication, create a snapshot agent for the publication “test”.

将表添加到发布后，为发布“ test”创建快照代理。

Here I used a snapshot agent to run under the SQL Server Agent process account. Make sure the account you to run the snapshot agent have the permission on the snapshot folder you used earlier.

在这里，我使用快照代理在SQL Server代理进程帐户下运行。 确保您要运行快照代理的帐户对您先前使用的快照文件夹具有权限。

Also, Replace the publisher_login and publisher_password with your own credentials which are used to connect publisher. This script should be executed on publisher database.

另外，用您自己的用于连接发布者的凭据替换publisher_login和publisher_password。 该脚本应在发布者数据库上执行。

USE [test_pub]EXEC sp_addpublication_snapshot @publication = N'test',@frequency_type = 1,@frequency_interval = 0,@frequency_relative_interval = 0,@frequency_recurrence_factor = 0,@frequency_subday = 0,@frequency_subday_interval = 0,@active_start_time_of_day = 500,@active_end_time_of_day = 235959,@active_start_date = 0,@active_end_date = 0,@job_login = NULL,@job_password = NULL,@publisher_security_mode = 0,@publisher_login = N'sa',@publisher_password = N''

Right click on the publication you just created, launch SQL Server replication monitor Click on your publication (test) navigate to Agents Tab. Make sure the snapshot is completed.

右键单击刚创建的发布，启动SQL Server复制监视器。单击发布（ 测试 ），导航到“ 代理”选项卡。 确保快照已完成。

Once the snapshot is completed add the subscriber to publication. Here in my case I used push subscription and the merge agent is scheduled to run for every one minute. This script needs to be run on publisher database.

快照完成后，将订户添加到发布中。 在本例中，我使用了推送订阅，并且合并代理计划每隔一分钟运行一次。 该脚本需要在发布者数据库上运行。

Merge agent is configured to run under SQL Server Agent service account and SQL Server login “sa” was used to connect subscriber. Make sure the logins used for connecting subscriber has access to subscriber database.

合并代理配置为在SQL Server代理服务帐户下运行，并且使用SQL Server登录名“ sa”来连接订户。 确保用于连接订户的登录名可以访问订户数据库。

Add subscription script varies in case of pull subscription.

如果是请求订阅，则添加订阅脚本会有所不同。

USE [test_pub]
EXEC sp_addmergesubscription @publication = N'test',@subscriber = N'SUBSERV01',@subscriber_db = N'test_sub1',@subscription_type = N'Push',@sync_type = N'Automatic',@subscriber_type = N'Local',@subscription_priority = 0,@description = NULL,@use_interactive_resolver = N'False'EXEC sp_addmergepushsubscription_agent @publication = N'test',@subscriber = N'SUBSERV01',@subscriber_db = N'test_sub1',@job_login = NULL,@job_password = NULL,@subscriber_security_mode = 0,@subscriber_login = N'sa',@subscriber_password = '',@publisher_security_mode = 1,@frequency_type = 4,@frequency_interval = 1,@frequency_relative_interval = 1,@frequency_recurrence_factor = 1,@frequency_subday = 4,@frequency_subday_interval = 1,@active_start_time_of_day = 0,@active_end_time_of_day = 235959,@active_start_date = 20190124,@active_end_date = 99991231,@enabled_for_syncmgr = N'False',@enabled_for_syncmgr = N'False'

You can also use SQL Server Management GUI to configure publication, add tables to replication and to create subscribers.

您还可以使用SQL Server管理GUI来配置发布，向复制添加表以及创建订阅服务器。

• SQL Server Replication (Merge) – What gets replicated and what doesn’t which shows how to configure merge publication, adding tables and creating subscribers using SQL Server Management Studio. SQL Server复制（合并）的文章-复制的内容和没有复制的内容，这些内容显示了如何使用SQL Server Management Studio配置合并发布，添加表和创建订阅服务器。

Once the initial snapshot is applied on subscribers please refer to below steps.

将初始快照应用于订户后，请参考以下步骤。

SQL Server Replication (Merge) tracks the data changes using triggers. For each table added to merge replication three triggers one for insert, one for update and one for delete were created on the table. Also, few procedures, views and conflict table were created for each table added to merge publication. You can view them using table dependencies or you can query them using article id.

SQL Server复制（合并）使用触发器跟踪数据更改。 对于添加到合并复制的每个表，在表上创建了三个触发器，一个用于插入，一个用于更新，一个用于删除。 同样，为添加到合并发布的每个表创建的过程，视图和冲突表很少。 您可以使用表依赖性查看它们，也可以使用商品ID查询它们。

Navigate to the replicated table and right click on the table and click on View Dependencies.

导航到复制的表，然后右键单击该表，然后单击“ 查看依赖关系”。

sysmergearticles has an entry of each table added to merge publication. This table has information about the procedures, conflict table, filters if configured, conflict table, conflict resolvers and identity ranges if auto identity management is chosen. Query this table on publisher database to find the article id of the table. Query sys.objects using the first part of the article id to find the objects related to replicated table.

sysmergearticles具有添加到合并发布的每个表的条目。 该表包含有关过程，冲突表，过滤器（如果已配置），冲突表，冲突解决程序和身份范围（如果选择了自动身份管理）的信息。 在发布者数据库上查询该表以找到该表的文章ID。 使用商品ID的第一部分查询sys.objects，以查找与复制表相关的对象。

Now, on the publisher database, let us add new column to the table “schema_test”.

现在，在发布者数据库上，让我们向表“ schema_test”中添加新列。

ALTER TABLE schema_test
ADD ID2 INT

After adding new column, the schema change commands were inserted in sysmergeschemachange table and all the procedures, triggers, views related to the article (table) were modified to incorporate newly added column.

添加新列后，将模式更改命令插入sysmergeschemachange表中，并修改与该文章（表）相关的所有过程，触发器，视图以合并新添加的列。

From the below image we can see all the objects related to replicated table were modified.

从下图可以看到与复制表相关的所有对象均已修改。

When the add new column command gets replicated to the subscriber these procedures, views, triggers were again modified at the subscriber as well to incorporate new column.

当将add new column命令复制到订阅服务器时，这些过程，视图和触发器在订阅服务器上也再次进行了修改，以合并新的列。

In my case, we received the deployment/upgrade script from developers with multiple ALTER TABLE statements to add new columns on same table as shown in below script.

就我而言，我们从开发人员那里收到了部署/升级脚本，其中包含多个ALTER TABLE语句，以便在同一表上添加新列，如以下脚本所示。

ALTER TABLE schema_test
ADD ID3 INTALTER TABLE schema_test
ADD ID4 INTALTER TABLE schema_test
ADD ID5 INTALTER TABLE schema_test
ADD ID6 INTALTER TABLE schema_test
ADD ID7 INTALTER TABLE schema_test
ADD ID8 INTALTER TABLE schema_test
ADD ID9 INTALTER TABLE schema_test
ADD ID10 INTALTER TABLE schema_test
ADD ID11 INTALTER TABLE schema_test
ADD ID12 INT

Now these changes were considered as individual DDL changes and all the objects related to the article were modified for each alter table statement issued on the replicated table.

现在，这些更改被视为单独的DDL更改，并且针对在复制表上发布的每个alter table语句，修改了与该文章相关的所有对象。

For example, if we have 18 SQL Server Replication internal objects related to the article “schema_test” and we added 10 columns using 10 alter table statements. All these 18 objects are modified 10 times (Total modifications will be 180).

例如，如果我们有18个与文章“ schema_test”相关SQL Server Replication内部对象，并且使用10个alter table语句添加了10列。 所有这18个对象均被修改10次（总修改为180）。

On the publisher database it took 15 seconds to add 10 columns if new columns were added in multiple ALTER TABLE statements:

在发布者数据库上，如果在多个ALTER TABLE语句中添加了新列，则需要15秒才能添加10列：

Launch the SQL Server replication monitor and we can see it took 13 seconds to sync these changes to subscriber. This may vary if your table structure is complex. Sync time would go high if you have lot of tables involved merge replication and adding/dropping columns using multiple alter table statements more tables.

启动SQL Server复制监视器，我们看到将这些更改同步到订阅服务器花了13秒钟。 如果您的表结构复杂，这可能会有所不同。 如果您有很多涉及合并复制的表以及使用多个alter table语句添加/删除列的更多表，则同步时间会变长。

Now let us compare timings by adding 10 more columns to table “schema_test” using single ALTER TABLE statement as shown in below T-SQL script.

现在，让我们比较时序，方法是使用单个ALTER TABLE语句在表“ schema_test”中增加10列，如下面的T-SQL脚本所示。

ALTER TABLE schema_test
ADD ID13 INT, ID14 INT, ID15 INT, ID16 INT, ID17 INT, ID18 INT, ID19 INT, ID20 INT, ID21 INT, ID22 INT

Now it took one second to add 10 new columns to the table “schema_test” because the SQL Server Replication internal objects were modified only once instead of 10 times.

现在花了一秒钟的时间向表“ schema_test”中添加了10个新列，因为SQL Server Replication内部对象仅被修改了一次，而不是10次。

Launch the SQL Server replication monitor and check the sync timings. It took around four seconds to sync the schema changes to subscriber. Please refer to the below snapshot from replication monitor.

启动SQL Server复制监视器，并检查同步时间。 将架构更改同步到订户花费了大约四秒钟。 请从复制监视器参考以下快照。

In this case the SQL Server Replication internal objects are modified only once at publisher and once at subscriber when the schema changes synced to subscriber. So, avoid using multiple ALTER TABLE statements to add columns or drop columns on the same table which is involved in merge replication.

在这种情况下，当架构更改同步到订阅服务器时，SQL Server复制内部对象仅在发布服务器和订阅服务器上被修改一次。 因此，避免使用多个ALTER TABLE语句在合并复制所涉及的同一表上添加列或删除列。

When I performed same tests using transactional replication results are as below.

当我使用事务复制执行相同的测试时，结果如下。

在事务型SQL Server复制中使用多个ALTER TABLE语句 (Using multiple ALTER TABLE statements in transactional SQL Server replication)

At the publisher, adding 10 new columns with multiple ALTER TABLE statements took 3 seconds (As there are no systems objects created related to the replicated table like in merge replication)

在发布者处，用多个ALTER TABLE语句添加10个新列花了3秒钟（因为没有像合并复制那样创建与复制表相关的系统对象）

To replicate these schema changes to subscriber it took 3 seconds.

将这些架构更改复制到订阅服务器需要3秒钟。

在事务型SQL Server复制中使用单个ALTER TABLE语句 (Using single ALTER TABLE statement in transactional SQL Server replication)

At the publisher, adding 10 new columns using single ALTER TABLE took less than a second and to replicate these schema changes to subscribers it took 1 second.

在发布者处，使用单个ALTER TABLE添加10个新列用了不到一秒钟的时间，并将这些架构更改复制到订阅服务器上花费了1秒。

Using a single ALTER TABLE statement to add new columns or drop existing columns on same existing table is always better either in case of SQL Server merge replication or transactional replication.

在SQL Server合并复制或事务复制的情况下，使用单个ALTER TABLE语句添加新列或删除同一现有表上的现有列总是更好。

目录 (Table of contents)

SQL Server Replication with a table with more than 246 columns

Foreign key issues while applying a snapshot in SQL Server merge replication

SQL Server Replication (Merge) – What gets replicated and what doesn’t

SQL Server Replication (Merge) – Performance Issues in replicating schema changes

Merge SQL Server replication parameterized row filter issues

SQL Server Replication on a mirrored database

Log shipping on a mirrored database

具有超过246列的表SQL Server复制

在SQL Server合并复制中应用快照时出现外键问题

SQL Server复制（合并）–复制什么，什么不复制

SQL Server复制（合并）–复制架构更改中的性能问题

合并SQL Server复制参数化的行筛选器问题

镜像数据库上SQL Server复制

镜像数据库上的日志传送

翻译自: https://www.sqlshack.com/sql-server-replication-merge-performance-issues-in-replicating-schema-changes/

sql server 复制