Section 3 : Redondance de chaque base locale
Figure 21 : Redondance des bases locales.
Dans chacun des sites, il existe une base de données de
production et une base de données temporaire sur laquelle on
paramétrera les options de réplication et, aussi, cette
même base peut servir de redondance. En effet, lorsque la base de
données principale est « down » à cause d'un
quelconque incident, la seconde pourra servir de base de production. Pour
transférer les données, il faudra implémenter un lot
DTS5 qui aura pour but de Mettre à jour les lignes et
colonnes des tables de la base secondaire (considéré ici dans
notre cas comme tampon de réplication).
5 Lot DTS : Ensemble de tâches groupées à
exécuter, effectuant des traitements précis sur des bases de
données.
Mise en place d'un système de réplication de base
de données entre sites distants
Par BILEY NDONGO ALPHONSE ROSELIN
CHAPITRE 8 : OPTIMISATION DE LA REPLICATION
Section 1 : Simulation de la
réplication
L'implémentation de la réplication a
été effectuée avec succès au niveau de
l'Entreprise, mais seulement, les machines virtuelles ayant des ressources
limitées, ne nous permettent pas de vous en faire ici une
démonstration.
Néanmoins nous nous permettons de vous faire une
démonstration de la configuration de la réplication d'une part,
et l'utilisation d'un lot DTS pour le transfert et la mise à jour d'une
base de données d'autre part.
Section 2 : Optimisation de la réplication
Une solution informatique est dite complète lorsqu'elle
n'oublie point les critères de haute disponibilité. Cette
solution doit pouvoir :
· détecter des erreurs matérielles et
logicielles ;
· relancer le fonctionnement suite à une
défaillance ;
· réintégrer une machine tombée en
panne.
Au vu de ces obligations nous devons respecter une ligne de
conduite pour optimiser notre système de réplication dans le but
de réduire au mieux les défaillances techniques. Plusieurs
habitudes sont à acquérir :
1: Evitez de publier des données inutiles.
Essayez de réduire le nombre de données
publiées. Cela peut offrir de sérieux gains de performance
étant donné que SQL ServerTM ne publiera que les nombres requis
de données. De plus, cela peut réduire le trafic réseau et
améliorer les performances générales de
réplication.
Mise en place d'un système de réplication de base
de données entre sites distants
Par BILEY NDONGO ALPHONSE ROSELIN
2: Mettez les logs de la base de données
publiée et celui de la base de données de distribution sur des
disques séparés.
Parce que le fait de loguer prend du temps d'écriture,
il est important que le tableau contenant les fichiers logs de SQL ServerTM
puisse avoir accès à suffisamment de ressources en
lecture/écriture. Séparer les fichiers logs sur deux disques est
la solution de choix.
3: Ne configurez pas la base de distribution pour qu'elle
s'étende ou se réduise automatiquement.
Microsoft recommande de fixer une taille pour la base de
distribution. La régler en mode automatique amène des pertes de
performance. Il faut donc choisir une taille raisonnable dès le
début.
4: Mettez le composant de réplication sur son propre
serveur.
Cette topologie est utilisée quand le niveau
d'activité de réplication augmente ou quand les ressources
serveur deviennent limitées. Elle réduit le chargement de
l'Editeur (Publisher), mais augmente le trafic réseau
général. Cette topologie requiert une installation MS-SQL
ServerTM séparée: une pour l'Editeur et une pour le
Distributeur.
5: Lancez l'assistant de capture instantanée
(Snapshot Agent) aussi rarement que possible.
Le « Snapshot Agent » fait de multiples copies de
données de l'Editeur vers le Distributeur, ce qui amène une
dégradation de certaines performances. Essayez de ne planifier le
lancement de l'assistant que durant les moments de faible usage du processeur
et les périodes calmes pour minimiser les pertes de performances.
6: Evitez la réplication continue.
Si possible, planifiez les réplications à
intervalles réguliers au lieu de choisir la réplication
continue.
7: Evitez de répliquer les colonnes text, ntext et
image.
Mise en place d'un système de réplication de base
de données entre sites distants
Par BILEY NDONGO ALPHONSE ROSELIN
Ces types de données requièrent plus d'espace
disque et de temps processeur que les autres types de données.
8: Ne répliquez l'exécution de
procédures stockées que quand un grand nombre de lignes est
affecté.
Par exemple, au lieu de répliquer un très grand
nombre de déclarations INSERT, UPDATE et DELETE, vous pouvez
créer une procédure stockée qui contient toutes ces
déclarations. Ne répliquez que l'exécution de la
procédure stockée. Cela peut réduire le traffic
réseau et améliorer les performances globales de
réplication.
9: Sélectionnez l'option "Maximize Throughput for
Network Applications"
Cela peut améliorer les performances de SQL ServerTM
étant donné que Windows NT allouera plus de RAM à SQL
ServerTM qu'à son fichier cache.
10: Sélectionnez l'option "Mémoire Serveur
Minimale".
Cette option est utilisée pour fixer une taille
d'allocation mémoire minimum pour SQL Server. Si le serveur est un
Distributeur externe ou un Editeur et Distributeur combinés, Microsoft
recommande que l'option "Mémoire Serveur Minimale" soit fixée
à au moins 16 Mo, pour éviter la disponibilité de
mémoire basse pendant les activités de réplication
11: Si vous travaillez avec SQL ServerTM 2000 dans un
éditeur central avec une topologie distributeur externe (quand le
composant de distribution de réplication se trouve sur son propre
serveur dédié) et que l'Editeur est relié au Distributeur
par un LAN ou WAN lent, pensez à compresser vos fichiers de capture
instantanée.
Cette nouvelle fonctionnalité de réplication de
SQL ServerTM 2000 permet de diminuer le trafic réseau.
12: Essayez de permettre le Pull ou les abonnements anonymes
pour améliorer les performances du Distributeur.
L'amélioration est due au fait que le travail de
l'Assistant de Distribution (Distribution Agent) sera
déplacé du Distributeur aux Abonnés.
Mise en place d'un système de réplication de base
de données entre sites distants
Par BILEY NDONGO ALPHONSE ROSELIN
13: Augmentez la propriété « MxBcpThreads
» de l'Assistant de Capture Instantanée.
Cette propriété spécifie le nombre
d'opérations de copies multiples qui peuvent être lancées
en parallèle.
En augmentant cette valeur, les opérations de copies
multiples seront plus rapides, car elles se feront en même temps.
Il ne faut pas non plus fixer cette propriété
trop haute: cela peut amener à des dégradations de performance,
car SQL ServerTM devra prendre plus de temps pour gérer les tâches
supplémentaires. Incrémentez la propriété de deux
en deux, et surveillez les performances...
14: Mettez à zéro la propriété
« OutputVerboseLevel » de l'Assistant de Distribution, de l'Assistant
de Lecture de Logs et l'Assistant de Fusion et de l'Assistant de Capture
Instantanée.
Cette propriété spécifie si la sortie doit
être complète. Elle peut avoir trois valeurs: -
0: seuls les messages d'erreur sont affichés
- 1: tous les rapports de progression sont affichés
- 2: tous les messages d'erreur et les rapports de progression
sont affichés (valeur par défaut).
15: Mettez à 1 la propriété «
HistoryVerboseLevel » de l'Assistant de Distribution, de l'Assistant de
Lecture de Logs et l'Assistant de Fusion et de l'Assistant de Capture
Instantanée.
Cette propriété spécifie la taille de
l'historique à loguer.
16: Si vous travaillez avec SQL ServerTM 2000, pensez
à utiliser la propriété d'assistant « UseInprocLoader
».
Mise en place d'un système de réplication de base
de données entre sites distants
Par BILEY NDONGO ALPHONSE ROSELIN
Si cette propriété est
sélectionnée, le processus d'entrée BULK INSERT sera
utilisé pour appliquer des fichiers de capture. Vous ne pouvez pas
utiliser cette propriété avec le mode BCP, ni avec des
abonnés OLE DB ou ODBC.
17: Augmentez le paramètre « ReadBatchSize
» de l'Assistant de Lecture de Log.
Ce paramètre spécifie le nombre maximum de
transactions lues à partir du fichier log de la base de publication. La
valeur par défaut est 500. Cette option devrait être
utilisée quand un grand nombre de transactions est écrit sur une
base de publication, mais que seulement une partie de celles-ci sont
marquées pour la réplication.
18: Si vous travaillez avec la réplication
transactionnelle, augmentez le paramètre « CommitBatchSize »
de l'assistant de distribution.
Ce paramètre spécifie le nombre de transactions
envoyées avant que la déclaration COMMIT soit envoyée. La
valeur par défaut est 100.
19: Créez un index pour chaque colonne
utilisée dans la clause WHERE du filtre.
Si vous n'utilisez pas de tels index, alors SQL ServerTM devra
lancer un scan sur la table entière.
20: Si vous travaillez avec la réplication de fusion,
utilisez des filtres statiques plutôt que dynamiques.
Parce que SQL ServerTM requiert plus de temps processeur pour
gérer les filtres dynamiques que statiques.
Mise en place d'un système de réplication de base
de données entre sites distants
Par BILEY NDONGO ALPHONSE ROSELIN
| 
