Comment répliquer la base de données A vers B, puis tronquer les données sur la base de données A, laissant B seul?

Question

J'ai un problème avec ma base de données SQL Server 2005. La base de données doit gérer 1000 insertions par seconde en permanence. Cela s'avère très difficile lorsque la base de données doit également gérer le reporting des données, donc l'indexation. Il semble ralentir après quelques jours seulement atteindre 300 inserts par seconde. Par 10 jours, il est presque non fonctionnel.

L'exigence est de stocker 14 jours de données. Jusqu'à présent, je ne peux en gérer que 3 ou 4 avant que tout ne s'effondre. Y a-t-il une solution simple à ce problème? Je pensais que je pouvais répliquer la base de données primaire permettant à la nouvelle base de données d'être la base de données de rapports stockant les 14 jours de base de données, puis de tronquer la base de données primaire tous les jours. Cela fonctionnerait-il?

Answer 1

Il est peu probable que vous souhaitiez que les rapports s'exécutent sur une base de données capturant 1000 enregistrements par seconde. Je suggère deux bases de données, une traitant le flux constant d'insertions et une deuxième base de données de rapports qui charge les enregistrements à intervalle, soit en interrogeant le premier pour un ensemble fini depuis le dernier chargement ou en mettant en cache les données entrantes et en les chargeant séparément . Cependant, la génération de rapports en temps quasi réel par rapport à une base de données capturant 86 millions de lignes par jour et portant environ 1,2 milliard de lignes nécessitera d'importantes demandes de planification et de matériel. En outre, sur le backend que vous atteignez le jour 14 et commencer à supprimer les anciennes données, vous mettrez plus de charge sur la base de données. Si vous pouvez exécuter sans journalisation, cela aidera le système principal, mais le système de génération de rapports avec des demandes d'indexation et autres nécessitera des considérations de performances assez importantes.

Answer 2

Si le serveur a plusieurs disques durs, j'essaierais de scinder la base de données (ou même les tables) en partitions.

Answer 3

Ouais, vous n'avez pas besoin de copier une base de données, puis de tronquer/supprimer la base de données en direct à la volée. Ma conjecture est que la lenteur est parce que vos journaux de transactions se développent comme des fous?

Je pense que vous essayez de dire que vous voulez "rétrécir" la base de données périodiquement. Si vous avez un schéma de sauvegarde complet, je pense que si vous sauvegardez les journaux de transactions de temps en temps, cela rétrécira les choses à la normale à nouveau.