Command attempted:
if @@trancount > 0 rollback tran
(Transaction sequence number: 0x0000CD53000011DE001000000000, Command ID: 1)

Error messages:
Syntax error, permission violation, or other nonspecific error (Source: MSSQLServer,
Error number: 20025)
Get help: http://help/20025
Syntax error, permission violation, or other nonspecific error (Source: MSSQLServer,
Error number: 42000)
Get help: http://help/42000

Ce n’est même pas la peine d’essayer de voir ce qu’il y a au bout des deux liens http://help/… proposés. En gros l’agent de distribution a trouvé une erreur en essayant d’appliquer une transaction. Le but est de retrouver le code SQL qui correspond à la transaction en échec. Lancer une trace Profiler sur le distributeur ne servira pas à grand chose car la transaction en question sera noyée dans le flot de mises à jour sur les tables systèmes de la réplication. En fait la chose la plus importante dans le log d’erreur est le numéro de transaction: 0×0000CD53000011DE001000000000

Pour retrouver l’ordre correspondant sur le distributeur, utiliser sp_browsereplcmds, regarder la première ligne:

use distribution
sp_browsereplcmds @xact_seqno_start = '0x0000CD53000011DE001000000000'

0x0000CD53000012EE000E	NULL	NULL	1	30	0	0	NULL	NULL
0x00000000000000000000
{CALL sp_MSins_EMAIL MOBILE DATA ('MICHAEL.HEARSLEY#TATOINE.COM', 'J74K6L')}	1

0x0000CD5300001304000F	NULL	NULL	1	30	0	0	NULL	NULL
0x00000000000000000000
{CALL sp_MSins_EMAIL MOBILE DATA ('EDUARDO.ALFONSO#JPMM.COM', 'J91RCX')}	1

0x0000CD530000131A0018	NULL	NULL	1	30	0	0	NULL	NULL
0x00000000000000000000
{CALL sp_MSins_EMAIL MOBILE DATA ('MARK.D.SPELLMAN#ATTACH.CO.UK', 'J731FZ')} 1

0x0000CD530000133B000E	NULL	NULL	1	30	0	0	NULL	NULL
0x00000000000000000000
{CALL sp_MSins_EMAIL MOBILE DATA ('XAVIER.BARTOLDI#NRJ.PICATRIX.COM', 'J92HBF')} 1

...

Effectivement si on lance l’exécution de la proc à la main sur le subscriber:

CALL sp_MSins_EMAIL MOBILE DATA ('MICHAEL.HEARSLEY#TATOINE.COM', 'J74K6L')

Msg 102, Level 15, State 1, Line 1
Incorrect syntax near 'MOBILE'.

Il y a des espaces dans le nom de la proc. L’assistant graphique de mise en place de la réplication créera la procédure avec des underscores, donc pas de souci, c’est juste pour l’exemple.

[ David B. ]

Continuez votre lecture sur le blog :

• Attention : publication transactionnelle et indexes non clusters (David BAFFALEUF) [SQL Server]
• Suppression accidentelle de ligne : comment retrouver le coupable ? (David BAFFALEUF) [SQL Server]
• Pourquoi il faut sauvegarder les bases systèmes (David BAFFALEUF) [SQL Server]
• Point-in-time recovery et fn_dump_dblog() (David BAFFALEUF) [SQL Server]
• Oracle, les Rpms plus de souci avec YUM (Thierry GASCARD) [Oracle]

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 à 0×30F3, qui décomposé contient bien à la fois le bitmask pour les index clusterisés (0×10) et celui pour les indexes NC (0×40).

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 0×803509F contient bien le 0×10, mais pas le 0×40. 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 Server]
• Regénérer le DDL des indexes FULL TEXT (David BAFFALEUF) [SQL Server]
• Bench avec NetApp / Datacore / ESX (David BAFFALEUF) [SQL Server]
• Attention aux requêtes en double avec Windev et MySQL ! (Cédric PEINTRE) [MySQL]
• XtraDB sauvegarde votre cache, et ça marche ! (Cédric PEINTRE) [MySQL]