Déporter les fonctions de reporting

dépassait 40
Go, le temps qu’il aurait fallu au
Snapshot Agent pour créer un instantané
aurait été prohibitif et aurait nécessité
plus de matériel pour le distributeur
et les abonnés. En outre, comme toutes
les tables participant à  la réplication transactionnelle
doivent contenir une clé primaire,
il nous aurait fallu modifier la base
de données.

La solution finale s’est articulée sur
les procédures stockées personnalisées
de l’application. Pendant notre réglage
de performances, nous avons à  grand
peine capturé et analysé les traces et les
données de mesures SQL pour identifier
les procédures stockées et le code SQL
ad hoc dans l’application du centre d’appel
qui prenaient le plus de temps pour
s’exécuter et utilisaient le plus de capacité
de la CPU. Nous avons attribué les
procédures stockées et les instructions
SQL à  deux catégories, dont chacune demandait
une technique d’optimisation
différente : des requêtes OLTP (online
transaction processing) d’exécution courte et des requêtes de reporting en
lecture seule d’exécution longue. Les requêtes
en lecture seule se prêtaient parfaitement
à  la déportation (et, par conséquent,
allégeaient le fardeau de la CPU).
Nous avons songé à  dévier les requêtes
en lecture seule vers un entrepôt de données
ou un data mart mais y avons renoncé
parce qu’elles faisaient partie intégrante
de l’application et devaient donc
s’exécuter presque en temps réel. Mais il
nous est apparu que nous pouvions répliquer
les portions de la base de données
que ces requêtes utilisaient et les
dévier vers les serveurs secondaires. Non
seulement cette solution augmentait la
capacité système disponible à  court
terme en nous permettant de déporter
le travail chez les abonnés, mais elle était
aussi innovante et évolutive pour le
futur. Dans la deuxième moitié de 2000,
nous avons commencé à  déporter
certains fonctions de reporting sur des
serveurs répliqués.