Utiliser SQL-DMO pour automatiser la personnalisation

SQL-DMO qui peut personnaliser
programmatiquement n’importe
quel job agent de réplication sur n’importe
quel serveur. (Cette application
est dans le fichier DMO_job.zip que
vous pouvez télécharger à  l’adresse
http://www.itpro.fr, Club Abonnés.)
Vous pouvez ajouter cette application au menu déroulant Tools d’Enterprise
Manager comme un outil externe. Cet
outil semble faire partie d’Enterprise
Manager et vous permet d’effectuer
une configuration standard et custom
sans quitter Enterprise Manager.
L’application fonctionne de la façon
suivante. Premièrement, elle affiche
une liste des serveurs enregistrés.
Pour chaque serveur que l’utilisateur
choisit, l’application trouve et liste les
noms de tous les abonnements aux publications
créées sur ce serveur,
comme le montre la figure 3. Dans
cette application, le nom figurant pour
un abonnement est une concaténation
des noms suivants : éditeur, base de
données de réplication, publication,
abonné et base de données de destination.
A l’aide de ces noms, vous pouvez
trouver les objets publication et abonnement
dans le modèle SQL-DMO.
Dans ce modèle, chaque objet publication
contient une collection d’objets
abonnement. Chaque objet abonnement
contient la propriété DistributionJobID,
que vous pouvez utiliser
pour trouver le propre objet job
Distribution Agent de l’objet d’abonnement.
Chaque objet publication a
aussi comme attribut la propriété
SnapshotJobID, que vous pouvez utiliser
pour trouver l’objet job Snapshot
Agent de l’objet de publication. Après
avoir trouvé les deux objets job-agent pour chaque abonnement sélectionné,
vous êtes prêt à  insérer les étapes personnalisées
dans ces jobs. Le listing 1
montre le code qui crée une liste de
tous les noms de serveurs enregistrés.
La procédure ListServers() donne la
liste des serveurs enregistrés. Quand
un utilisateur sélectionne un serveur,
l’application enregistre le nom de celui-
ci dans la variable sServer. Le listing
2 concatène et affiche les noms listés
de tous les abonnements aux publications
qui ont été créées sur le serveur
sélectionné. La figure 3 montre des
exemples des noms listés de certains
abonnements. Pour économiser de la
place, j’ai omis les déclarations de type
données.
Nous l’avons vu, le nom indiqué
pour chaque abonnement se présente
sous la forme serveur-base de données
de réplication-publication-abonnement.
C’est une combinaison des
noms d’un serveur de publication,
d’une base de données de réplication,
d’une publication, et d’un abonnement,
respectivement. Quand un utilisateur
choisit un nom de la liste, l’application
l’analyse syntaxiquement par
rapport à  des noms de serveur, base de
données (réplication), publication et
abonnement, et sauvegarde les parties
dans les variables sServer, sDB,
sPublication et sSubscription, respectivement.
Pour des raisons de place, j’ai omis le code qui analyse syntaxiquement
un nom de la liste. Le code du listing
3 utilise ces variables sauvegardées
pour se connecter à  l’éditeur et identifie
les objets base de données de réplication,
publication et abonnement
dans leurs collections respectives. A
noter qu’un objet base de données de
réplication a une collection d’objets publication nommée TransPublications
comme sa propriété et, à  son tour,
chaque objet publication a une collection
d’objets abonnement nommée
TransSubscriptions comme sa propriété.
Le listing 3 montre comment
identifier un objet publication dans un
objet abonnement dans les collections
TransPublications et TransSubscriptions,
respectivement. Ensuite, l’application
recherche l’objet job
Snapshot Agent de la publication sélectionnée
et l’objet job Distribution
Agent de l’abonnement par leurs ID
de job, comme le montre le listing 4.
Après avoir localisé ces deux objets
job-agent, vous êtes prêt à  commencer
la personnalisation des jobs.
Premièrement, insérez une nouvelle
étape dans le job Snapshot Agent
après la deuxième étape du job. Cette
nouvelle étape devient la troisième
étape du job et vous lui attribuez
StepID3 pour indiquer sa position,
comme le montre le listing 5. Rappelons
que la commande à  l’étape 3
est de démarrer un ou plusieurs jobs
Distribution Agent (je ne montre
qu’un début de job ici). Dans SQLDMO,
vous insérez une nouvelle
étape en créant un nouvel objet étape
étape-job, en attribuant les propriétés
de l’étape, puis en ajoutant la nouvelle
étape aux étapes de l’objet job.
Vous devez aussi modifier le flux de la
deuxième étape ; en cas de défaillance,
son OnFailStep continuait
son flux vers l’ancienne étape 3, mais
celle-ci est maintenant l’étape 4,
comme le montre la figure 2. Le listing
5 montre comment créer la troisième
étape et modifier la deuxième.
Ensuite, vous devez personnaliser
les jobs Distribution Agent sélectionnés,
comme le montre le listing 6. A
nouveau, je n’utilise qu’un job Distribution
Agent. Chaque job inclut deux
nouvelles étapes insérées. L’une d’elles
appelle une procédure stockée avant
la deuxième étape originale pour abandonner
les index et les clés sur les
tables de destination et sauvegarder
leurs scripts. Aussitôt insérée, cette
nouvelle étape devient l’étape 2. Vous
insérez l’autre nouvelle étape après la
deuxième étape originale (qui est maintenant
la troisième). La nouvelle étape
appelle la procédure stockée distante
sur l’abonné pour exécuter les scripts
que la première nouvelle étape (maintenant
étape 2) sauvegarde. Cette nouvelle
étape devient l’étape 4.
Mécaniquement parlant, le code
du listing 6 est semblable à  celui du listing
5 (qui personnalise le job Snaphot
Agent), donc le listing 6 ne montre que
les lignes importantes. Vous pouvez
trouver le listing complet pour cette
application SQL-DMO automatisée
dans le fichier DMO_job.zip.