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_dboAddress',
@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 :
- Retrouver une transaction en échec (David Baffaleuf) [SQL ServerVintage]
- Repeupler un index FullText (Benjamin VESAN) [SQL Server]
- Réplication MySQL : Resynchronisation d’un Slave MySQL (Capdata team) [MySQL]
- Regénérer le DDL des indexes FULL TEXT (David Baffaleuf) [SQL Server]
- Migration PostgreSQL via SLONY-I ou comment réduire le temps de coupure (Capdata team) [PostgreSQL]