У нас есть сценарий SQL, который мы используем для создания публикации и ее статей вместе с подпиской по запросу. Это довольно просто, так как мы явно не исключаем какие-либо статьи, а передаем их всем подписчику (база данных, используемая для запросов, которые используются в наших отчетах, чтобы предотвратить чрезмерную нагрузку на базу данных приложения).
Сценарий как часть настройки публикаций статей перебирает каждую статью в исходной базе данных и для таблиц, выполняет следующее:
DECLARE @Ins nvarchar(255) = 'CALL sp_MSins_'+@articleSchema+@articleName
DECLARE @Del nvarchar(255) = 'CALL sp_MSdel_'+@articleSchema+@articleName
DECLARE @Upd nvarchar(255) = 'CALL sp_MSupd_'+@articleSchema+@articleName
exec sp_addarticle
@publication = @PublishName,
@article = @Joined,
@source_owner = @articleSchema,
@source_object = @articleName,
@type = N'logbased',
@description = null,
@creation_script = null,
@pre_creation_cmd = N'drop',
@schema_option = 0x00000000080350DF,
@identityrangemanagementoption = N'manual',
@destination_table = @articleName,
@destination_owner = @articleSchema,
@vertical_partition = N'false',
@ins_cmd = @Ins,
@del_cmd = @Del,
@upd_cmd = @Upd
Моя проблема связана с параметром @schema_option для хранимой процедуры sp_addarticle.
Я использовал сценарий, найденный здесь:
https://blogs.msdn.microsoft.com/repltalk/2010/02/24/decrypting-schema_option-parameters-binary-value-for-a-transactional-replication-article/
для проверки моего расчетного (побитового или) значения 0x00000000080350DF и в соответствии с этим скриптом для статей в таблице включены следующие параметры:
**SCHEMA OPTIONS HERE ARE**
—————————————
0x01 Generates the object creation script (CREATE TABLE, CREATE PROCEDURE, and so on). This value is the default for stored procedure articles.
0x02 – Generates the stored procedures that propagate changes for the article, if defined.
0x04 – Identity columns are scripted using the IDENTITY property.
0x08 – Replicate timestamp columns. If not set, timestamp columns are replicated as binary.
0x10 – Generates a corresponding clustered index. Even if this option is not set, indexes related to primary keys and unique constraints are generated if they are already defined on a published table.
0x40 – Generates corresponding nonclustered indexes. Even if this option is not set, indexes related to primary keys and unique constraints are generated if they are already defined on a published table.
0x80 – Replicates primary key constraints. Any indexes related to the constraint are also replicated, even if options 0x10 and 0x40 are not enabled.
0x1000 – Replicates column-level collation
0x4000 – Replicates UNIQUE constraints. Any indexes related to the constraint are also replicated, even if options 0x10 and 0x40 are not enabled
0x10000 – Replicates CHECK constraints as NOT FOR REPLICATION so that the constraints are not enforced during synchronization
0x20000 – Replicates FOREIGN KEY constraints as NOT FOR REPLICATION so that the constraints are not enforced during synchronization
0x8000000 – Creates any schemas not already present on the subscriber
Как вы можете видеть, может показаться, что опция 0x40 для включения генерации некластеризованных индексов должна быть включена для статей таблицы.
Однако после запуска агента моментальных снимков создается моментальный снимок, и агент чтения журнала делает свое дело. Если я получу доступ к свойствам публикации, я увижу, что для табличных статей параметр некластеризованные индексы" имеет значение false.
Кто-нибудь знает, почему эта опция не включена для табличных статей? Я пытался интерпретировать документацию по technet: https://technet.microsoft.com/en-us/library/ms173857(v=sql.105).aspx, но не обнаружил причину, по которой этот флаг будет игнорироваться.
Я не могу просто изменить параметр в диалоговом окне свойств в студии управления, поскольку для нашего продукта мы не обязательно имеем прямой доступ к экземпляру SQL Server наших клиентов, но должны выполнять сценарии удаленно с установочной машины через powershell, из которых этот скрипт один.
Заранее спасибо.
