0

Attention : publication transactionnelle et indexes non clusters

twitterlinkedinmail

Récemment, en resynchronisant une publication transactionnelle avec un éditeur 2005 vers un abonné 2005, on s’est aperçu que le snapshot ne générait que les index clusters pour chaque article, pas les indexes non clusters. Enorme ! Nous avons revérifié avec un éditeur en 2000, et les indexes non clusters sont bien générés en même temps que les clusters.

Explication: lorsque l’agent de snapshot doit extraire le DDL des articles et sortir les données par bcp en parrallèle, il se base sur deux options passées lors du sp_addarticle:
@type: qui va indiquer à quel type de publication on a affaire. Dans notre cas, ce sera logbased (=transac)
@schema_option : bitmask qui va indiquer ce qui doit être généré au niveau DDL.

D’après les BOLs 2005, si @type = ‘logbased’, alors @schema_option doit être à 0x30F3, qui décomposé contient bien à la fois le bitmask pour les index clusterisés (0x10) et celui pour les indexes NC (0x40).

Je vous engage à tester ça depuis SSMS, en créant une publication transac bidon et en jetant un coup d’oeil aux propriétés de l’article:

Dans le script généré, effectivement on a bien un problème:

exec sp_addarticle
@publication = N'pubtest1',

@article = N'Address',
@source_owner = N'dbo',
@source_object = N'Address',
@type = N'logbased',
@description = null,
@creation_script = null,
@pre_creation_cmd = N'drop',
@schema_option = 0x000000000803509F,
@identityrangemanagementoption = N'manual',
@destination_table = N'Address',
@destination_owner = N'dbo',
@vertical_partition = N'false',
@ins_cmd = N'CALL sp_MSins_dboAddress',
@del_cmd = N'CALL sp_MSdel_dbo
Address',
@upd_cmd = N'SCALL sp_MSupd_dboAddress'
GO

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):

select 134434975 & 64
select 134434975 & 16

-----------
0

-----------
16

Suite à une petite discussion avec Paul Randal, il se trouve que nombre de ses clients ont eu le même problème en migrant. Donc si vous migrez une réplication de 2000 vers 2005, et que vous constatez des problèmes de perfs sur les abonnés, vérifiez si vous avez tous vos indexes NC, juste comme ça… 😉

A+ [ David B. ]


Continuez votre lecture sur le blog :

twitterlinkedinmail

David Baffaleuf

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.