> Tech > Déporter les fonctions de reporting

Déporter les fonctions de reporting

Tech - Par iTPro - Publié le 24 juin 2010
email

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 gratuitement cette ressource

Les 7 étapes d’un projet de dématérialisation RH

Les 7 étapes d’un projet de dématérialisation RH

Dans ce livre blanc, nous vous donnons les clés pour concevoir votre projet de dématérialisation RH. Vous découvrirez chacune des étapes qui vous permettront d’apporter de nouveaux services aux collaborateurs, de vous adapter aux nouvelles pratiques et de renforcer la marque employeur.

Tech - Par iTPro - Publié le 24 juin 2010