Tables/bases de données séparées pour les opérations de génération de rapports et de CRUD

Question

Périodiquement, les utilisateurs exécutant des rapports bloquent les utilisateurs effectuant des opérations CRUD et provoquant des interruptions. J'aimerais créer des emplacements en double des tables actuelles pour les utilisateurs du rapport. Je pensais à créer un travail qui sauvegarde la base de données de mon application et la restaure dans une base de données de rapports sur le même serveur afin que les utilisateurs exécutant des rapports soient séparés de ceux effectuant des opérations CRUD. Le travail sera exécuté toutes les 10 minutes environ. Les premiers tests montrent que le début à la fin sera d'environ 30 secondes. L'espace disque n'est pas un problème.

Est-ce une bonne/mauvaise idée? Quels pièges devrais-je surveiller? Y a-t-il une meilleure manière de faire cela?

Answer 1

Cela semble être une bonne idée. La seule chose que je voudrais savoir est que vous devez mettre à jour toutes les 10 minutes? Cela pourrait également ralentir les choses pendant la mise à jour. Habituellement, ceux-ci sont faits du jour au lendemain (pour avoir le moins d'impact sur les autres), ou si pendant la journée, à seulement 3 points fixes (disons 10 h, 13 h et 16 h).

Answer 2

Naturellement, pour la plupart des applications d'entreprise, la base de données de transactions est toujours séparée de la base de données de génération de rapports. Le système de transaction est optimisé pour OLTP et la base de données de reporting peut être dénormalisée pour répondre aux besoins des scénarios de reporting. C'est donc presque une suggestion naturelle.

Answer 3

Soyez prudent lorsque vous effectuez des sauvegardes fréquentes, ce qui peut entraîner beaucoup de temps d'arrêt!

Solutions communes

Il est en effet une pratique courante de créer une instance distincte juste pour les rapports. Certaines personnes vont même un peu plus loin et mettent des rapports sur une machine physique ou une grappe distincte pour isoler davantage cette partie de la charge.

Les deux peuvent être gérés avec réplication (ce qui évite le problème d'indisponibilité). Ou vous pourriez juste faire une sauvegarde tous les soirs et faire un rapport contre cela.

Je voudrais également mentionner que l'approche haut de gamme est data warehousing, où vous transformez essentiellement cette nouvelle base de données de rapports en un référentiel optimisé pour la lecture, plus efficace pour la création de rapports. Cela prend beaucoup de temps à mettre en œuvre, donc c'est pas le le correctif rapide que vous recherchez.

Réflexions

Une dernière chose: je l'ai vu quelques magasins sur le point de ce problème, essayez d'éviter de traiter avec elle. Voici le point à retenir: rapports tend à augmenter à certains moments du mois ou année, donc si vous êtes normalement sur le point de tuer votre serveur de base de données, la dernière semaine du mois pourrait vous pousser sur le bord!

Cette question est très similaire: https://stackoverflow.com/questions/190512/sql-server-separate-database-for-reports

Answer 4

Avant de faire une mise à niveau chariot élévateur à fourche, vous pourriez voir si mettre

...from sometable WITH (NOLOCK) 

sur vos requêtes de rapports pallie le problème. Il peut au moins vous donner du temps pour déterminer ce qui est optimal.