{"id":125,"date":"2009-06-18T09:28:06","date_gmt":"2009-06-18T08:28:06","guid":{"rendered":"https:\/\/www.alldb.fr\/blogs\/?p=125"},"modified":"2023-04-20T07:04:16","modified_gmt":"2023-04-20T06:04:16","slug":"replication-sql-server-attention-publication-transactionnelle-et-indexes-non-clusters","status":"publish","type":"post","link":"https:\/\/blog.capdata.fr\/index.php\/replication-sql-server-attention-publication-transactionnelle-et-indexes-non-clusters\/","title":{"rendered":"Attention : publication transactionnelle et indexes non clusters"},"content":{"rendered":"\"twitter\"<\/a>\"linkedin\"<\/a>\"mail\"<\/a>

R\u00e9cemment, en resynchronisant une publication transactionnelle avec un \u00e9diteur 2005 vers un abonn\u00e9 2005, on s’est aper\u00e7u que le snapshot ne g\u00e9n\u00e9rait que les index clusters pour chaque article, pas les indexes non clusters. Enorme ! Nous avons rev\u00e9rifi\u00e9 avec un \u00e9diteur en 2000, et les indexes non clusters sont bien g\u00e9n\u00e9r\u00e9s en m\u00eame temps que les clusters.<\/p>\n

Explication: <\/strong>lorsque l’agent de snapshot doit extraire le DDL des articles et sortir les donn\u00e9es par bcp en parrall\u00e8le, il se base sur deux options pass\u00e9es lors du sp_addarticle:
\n– @type<\/strong>: qui va indiquer \u00e0 quel type de publication on a affaire. Dans notre cas, ce sera logbased <\/strong><\/em>(=transac)
\n– @schema_option<\/strong> : bitmask qui va indiquer ce qui doit \u00eatre g\u00e9n\u00e9r\u00e9 au niveau DDL.<\/p>\n

D’apr\u00e8s les BOLs 2005, si @type = ‘logbased’<\/strong>, alors @schema_option<\/strong> doit \u00eatre \u00e0 0x30F3<\/strong>, qui d\u00e9compos\u00e9 contient bien \u00e0 la fois le bitmask pour les index clusteris\u00e9s (0x10) et celui pour les indexes NC (0x40).<\/p>\n

Je vous engage \u00e0 tester \u00e7a depuis SSMS, en cr\u00e9ant une publication transac bidon et en jetant un coup d’oeil aux propri\u00e9t\u00e9s de l’article:<\/p>\n

\"\"<\/a><\/p>\n

Dans le script g\u00e9n\u00e9r\u00e9, effectivement on a bien un probl\u00e8me:<\/p>\n

exec sp_addarticle
\n@publication = N'pubtest1',<\/tt>
\n@article = N'Address',
\n<\/tt> <\/tt>@source_owner = N'dbo',
\n<\/tt> <\/tt>@source_object = N'Address',
\n@type = N'logbased'<\/strong>,
\n<\/tt> <\/tt>@description = null,
\n<\/tt> <\/tt>@creation_script = null,
\n<\/tt> <\/tt>@pre_creation_cmd = N'drop',
\n@schema_option = 0x000000000803509F<\/strong>,
\n<\/tt> <\/tt>@identityrangemanagementoption = N'manual',
\n<\/tt> <\/tt>@destination_table = N'Address',
\n@destination_owner = N'dbo',
\n<\/tt> <\/tt>@vertical_partition = N'false',
\n<\/tt> <\/tt>@ins_cmd = N'CALL sp_MSins_dbo<\/tt>Address<\/tt>',
\n@del_cmd = N'CALL sp_MSdel_dbo<\/tt>Address<\/tt>',
\n<\/tt> <\/tt>@upd_cmd = N'SCALL sp_MSupd_dbo<\/tt>Address<\/tt>'
\nGO<\/tt><\/p>\n

Le bitmask 0x803509F contient bien le 0x10, mais pas le 0x40. Pour en avoir le coeur net, utilisez le ET logique en transac (134434975=0x803509, 64=0x40, 16=0x10):<\/tt><\/p>\n

select 134434975 & 64
\nselect 134434975 & 16<\/tt><\/p>\n

-----------
\n0<\/tt><\/p>\n

-----------
\n16
\n<\/tt>
\nSuite \u00e0 une petite discussion avec Paul Randal, il se trouve que nombre de ses clients ont eu le m\u00eame probl\u00e8me en migrant. Donc si vous migrez une r\u00e9plication de 2000 vers 2005, et que vous constatez des probl\u00e8mes de perfs sur les abonn\u00e9s, v\u00e9rifiez si vous avez tous vos indexes NC, juste comme \u00e7a… \ud83d\ude09<\/p>\n

A+ [ David B. ]
\n
\n<\/tt>
\n