rapport au pic des 6 mois précédents.
(Nous avons instauré la réplication
dans la dernière partie de 2000).
Bien que SQL Server réplique une grande quantité de données très rapidement,
les ressources de CPU utilisées sur
le distributeur sont plutôt lentes parce
que la réplication transactionnelle est
très efficace. L’utilisation de la CPU continue
à  diminuer même quand nous ajoutons
continuellement des utilisateurs au
serveur. La figure 4 affiche les nombres
d’utilisateurs.
Les ressources que les serveurs de
reporting utilisent sont aussi dans des limites
acceptables. Nous surveillons ces
ressources en permanence et activons
un plan d’urgence dès qu’elles s’approchent
de niveaux inacceptables. Nous
ajoutons simplement davantage d’abonnés
et mettons à  jour la table des pointeurs
pour pointer les rapports vers ces
serveurs, puis nous distribuons la charge
sans que les utilisateurs s’en aperçoivent
– et sans rien modifier aux applications.
Le temps de réponse de certaines requêtes
est aussi une autre manière de
mesurer notre réussite. La figure
5 montre un exemple de l’une de ces requêtes.
Vous pouvez constater qu’elle a
affiché un gain de 500 % de performances
après l’instauration de la réplication.
Bien que cette solution réussisse
généralement, elle impose quelques limitations.
Certains problèmes de réplication
demandent que l’on reconstruise
une publication et que l’on resynchronise
les données en utilisant un nouvel instantané. De plus, en raison de problèmes
de verrouillage, nous ne pouvons
pas toujours créer de nouveaux instantanés
pendant les heures d’activité
normales pendant que le système est occupé.