Optimiser la performance

les instructions DELETE provoquent
dans l’étape sch, en sélectionnant l’option
Delete all data in the existing table
(using TRUNCATE) dans l’onglet
Snapshot de la boîte de dialogue
Properties d’un article, qu’illustre la figure
8. Il en résulte une instruction
TRUNCATE <table> au lieu d’une instruction
DELETE FROM <table> dans
le fichier .sch. TRUNCATE TABLE désalloue
toutes les pages associées à  la
table en une opération et ne journalise
que l’opération de désallocation. Par
conséquent, il faut toujours un temps
constant – ou complexité O(c) – quel
que soit le nombre d’enregistrements
et d’index d’une publication. Un test
effectué dans le même exemple de publication
montre que quand on sélectionne
l’option TRUNCATE, l’étape sch
prend moins d’une seconde, au lieu de
58 minutes. Toutefois, on ne peut utiliser
l’option TRUNCATE qu’à  une
condition : la table cible ne peut
pas contenir une contrainte de clé étrangère. Si la table cible est référencée
par une contrainte de clé étrangère,
l’instruction TRUNCATE correspondante
dans l’étape sch échouera.
Pour optimiser complètement son
l’étape sch, le Distribution Agent doit
abandonner toutes les contraintes de
clés étrangères associées à  toutes les
tables cible avant d’entreprendre
l’étape sch, puis les recréer après
l’étape l’étape sch.

Résoudre le goulet d’étranglement
bcp. Malheureusement, on ne peut pas corriger le goulet d’étranglement
bcp par la configuration de la
même manière que l’on peut configurer
l’instruction TRUNCATE. Le seul
moyen d’optimiser l’étape bcp
consiste à  abandonner tous les index et
les contraintes de clés avant l’étape
bcp et à  les recréer après elle. Le fait
d’abandonner et de recréer les index et
les contraintes de clés réduit la complexité
de bcp à  un temps linéaire proportionnel
à  la taille de la publication –
O(n) – parce que bcp n’a plus à  effectuer
le tri et l’indexation. Cette étape
bcp optimisée s’adaptera à  un nombre
quelconque d’index dans une publication.
La publication dans mon exemple
comprend 10 index clustered, 29 index
non clustered et une contrainte de clé
étrangère. L’abandon de tous les index
et clés prend 2 minutes et 8 secondes ;
la recréation de tous les index et clés
prend 10 minutes et 36 secondes, et
l’exécution de l’étape bcp prend 28 minutes
– soit un total de 41 minutes par
rapport à  55 minutes. Ces tests confirment
que le résultat de l’optimisation
de l’étape bcp n’est pas aussi spectaculaire
que celui de l’étape sch en raison
de la time complexity linéaire de
l’étape bcp. L’élimination des deux
goulets d’étranglement sch et bcp dans
l’exemple fait gagner au total 72 minutes.

Pas de raccourci possible pour
l’optimisation. Pour optimiser les
étapes sch et bcp, on peut être tenté
par un raccourci. Supposons, par
exemple, que vous définissiez le
paramètre @creation_script de la procédure cataloguée sp_addarticle
vis-à -vis d’un fichier script custom
quand vous ajoutez chaque article à  la
publication. Un tel fichier script custom
abandonnerait tous les index et
clés dans chaque table cible.
Rappelons que le Distribution Agent
applique les étapes sch, bcp et idx séquentiellement.
Le but est de remplacer
le fichier .sch par un fichier script
custom tout en conservant les fichiers
script .bcp et .idx d’origine. La tâche
semble facile parce que le remplacement
du fichier .sch n’exige aucun effort
particulier, excepté la préparation
des fichiers script custom.

Malheureusement, cette idée ne
marche pas pour deux raisons. Tout
d’abord, vous envisagez peut-être
d’utiliser le fichier .idx que le Snapshot
Agent a créé, pour recréer les
contraintes de clés étrangères et les index
que le script custom a abandonnées.
Or, le fichier .idx n’inclut pas des
contraintes de clés étrangères primaires
et uniques parce que, dans le fichier
.idx, le Snapshot Agent capture
ces contraintes de clés comme des index.
Ainsi, dans la figure 6, UNIQUE
CLUSTERED INDEX [PK_ADDRESS]
vient d’une contrainte de clé primaire
nommée [PK_ADDRESS] mais ne survit
que comme un index. La seconde
raison est la plus importante : bien que
le paramètre @schema_option de la
procédure cataloguée sp_addarticle
vous permette de désactiver le scripting
de Snapshot Agent et d’utiliser le
paramètre @creation_script fourni, la
valeur du paramètre @creation_script
désactive également la génération des
fichiers .sch et .idx. Par conséquent, il
n’y aura pas de fichier .idx disponible
pour recréer les index que le fichier
@creation_script a abandonnés.
Associer le paramètre @creation_
script à  un fichier script custom n’atteint
pas l’objectif souhaité.