La réplication transactionnelle semblait être la réponse, parce que nous voulions alléger le fardeau du publieur et parce que les requêtes de reporting n'effectuaient pas de mises à jour de la base de données. Or, à l'évidence, il n'était pas possible de répliquer toute la base de données. Comme celle-ci
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.
Téléchargez cette ressource

État des lieux de la sécurité cloud-native
L’État des lieux de la sécurité cloud-native vous offre une analyse complète des problématiques, des tendances et des priorités qui sous-tendent les pratiques de sécurité cloud-native dans le monde entier. Une lecture indispensable pour renforcer votre stratégie de sécurité dans le cloud. Une mine d’infos exclusives pour élaborer votre stratégie de sécurité cloud-native.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les risques liés à l’essor fulgurant de l’IA générative
- Pourquoi est-il temps de repenser la gestion des vulnérabilités ?
- Reporting RSE : un levier d’innovation !
- De la 5G à la 6G : la France se positionne pour dominer les réseaux du futur
- Datanexions, acteur clé de la transformation numérique data-centric
