Nous rencontrons actuellement des problèmes de performances car notre base de données devient trop volumineuse. Il y a des données stockées des 10 dernières années et je ne vois pas pourquoi les données de plus de 2 ans doivent être stockées dans les mêmes tables que les nouvelles données.

Maintenant que je n'ai pas une expérience très approfondie dans l'administration de bases de données, je cherche les meilleures façons d'archiver les anciennes données.

Info

• Il y a environ 310'000'000 enregistrements dans la base de données au total.

• La base de données a besoin de 250 Go sur le disque dur.

• La version du serveur est SQL Server 2008 avec le niveau de compatibilité SQL Server 2005 (90), mais nous prévoyons de mettre à niveau vers SQL Server 2012 bientôt

J'ai pensé à deux possibilités:

Nouvelle base de données

Créez une base de données similaire à celle du serveur de production et insérez toutes les anciennes données dans la nouvelle base de données.

• Inconvénient: les serveurs liés n'étant pas autorisés dans notre environnement, il serait difficile de joindre les anciennes données si nécessaire

Schéma historique

Créez un nouveau schéma fe [hist] avec les mêmes tables que dans la base de données de production. Insérez toutes les anciennes données dans ces nouvelles tables dans le nouveau schéma.

• Avantage: intégration facile, si d'anciennes données étaient nécessaires à l'avenir

• Préférez-vous l'une des solutions par rapport à l'autre?
  • Pourquoi?
• Y a-t-il de meilleures possibilités?
• Existe-t-il des outils avec lesquels cette tâche est facilement possible?
• D'autres réflexions?

Merci d'avance

modifier

Question supplémentaire:

La table d'archivage nouvellement créée aurait-elle également besoin de clés primaires / étrangères?

Ou devraient-ils simplement avoir les colonnes mais sans clés / contraintes?

Je pense que la réponse à bon nombre de vos questions est que cela dépend. Quels problèmes de performances rencontrez-vous? Il semble inhabituel qu'une base de données ait des problèmes de performances simplement en passant à 250 Go.

Peut-être que vos requêtes effectuent des analyses de table sur l'intégralité de la table de faits, même si seule une petite partie (par exemple, la dernière année) de la plage de dates est nécessaire? S'il existe une requête particulière qui est la plus importante à optimiser, envisagez de publier votre schéma, votre requête et un plan d'exécution réel dans une autre question pour voir si elle peut être optimisée.

Préférez-vous l'une des solutions par rapport à l'autre?

Je préfère généralement la base de données historique, et je pense que Guy décrit les bonnes raisons à cela dans sa réponse .

Le principal inconvénient que je vois pour une base de données d'historique (par opposition à un schéma) est que vous ne pouvez plus utiliser de clés étrangères pour votre table d'archives. Cela peut vous convenir, mais c'est quelque chose dont vous devez être conscient.

L'inconvénient que vous avez indiqué pour cette approche n'est pas précis; vous pourrez interroger facilement des bases de données sur le même serveur et l'optimiseur de requêtes gère généralement très bien les requêtes inter-bases de données.

Y a-t-il de meilleures possibilités?

Si vous devez interroger les données d'archive régulièrement, je pourrais envisager de partitionner la table par date . Cependant, il s'agit d'un grand changement qui peut entraîner de nombreuses implications en termes de performances, à la fois positives (par exemple, élimination de partition, chargement de données plus efficace) et négatives (par exemple, recherche de singleton plus lente, plus grand potentiel de biais de thread dans les requêtes parallèles). Je ne prendrais donc pas cette décision à la légère s'il s'agit d'une base de données très utilisée.

La table d'archivage nouvellement créée aurait-elle également besoin de clés primaires / étrangères? Ou devraient-ils simplement avoir les colonnes mais sans clés / contraintes?

Je recommanderais d'avoir au moins la clé primaire et des index uniques afin que vous puissiez obtenir les avantages d'intégrité des données qu'ils fournissent. Par exemple, cela vous évitera d'insérer accidentellement une année de données dans la table d'historique deux fois. Et comme avantage secondaire, il peut améliorer les performances si vous avez besoin d'interroger la table d'historique.

D'autres réflexions?

Étant donné que vous utilisez l'édition Entreprise et que vous prévoyez de mettre à niveau vers SQL 2008+, vous pouvez envisager la compression des données pour ce tableau. La compression réduira certainement l'espace disque, mais en fonction des ressources disque et CPU de votre serveur, elle peut également améliorer les performances des requêtes pour les lectures en réduisant les E / S disque et en améliorant l'utilisation de la mémoire (plus de données tiennent dans le cache à la fois).

Je préférerais avoir un schéma historique ou une deuxième base de données historique sur un serveur lié tous les jours. Il économise les coûts de licence est plus facile à gérer et à interroger. Vous pouvez ensuite également utiliser un schéma plus simple et supprimer certains des index en réduisant la taille de la base de données

Mais puisque vous avez l'édition entreprise, vous avez la troisième option qui consiste à partitionner vos tables qui, une fois mises en place, facilite l'archivage des données et l'interrogation des anciennes données est transparente pour vos utilisateurs et vous n'aurez pas besoin de modifier l'application .

D'après mon expérience, une deuxième base de données serait le choix préféré pour deux raisons.

1. Vous pouvez restaurer les données à partir d'une sauvegarde historique, puis supprimer les tables et index dont vous n'avez pas besoin.
2. Vous pouvez le déplacer vers un autre serveur à des fins de génération de rapports, ce qui présente l'avantage de ne pas utiliser les ressources du serveur principal

Vous devrez toujours supprimer toutes les données historiques de la base de données principale, mais cela pourrait être planifié dans.

Ignorer la licence pour l'instant car ce n'est pas là que je passe mon temps.

À mon humble avis, la base de données d'archives est la plus simple à mettre en œuvre et à maintenir. Ce sont des entités distinctes, faiblement couplées. Le contrôle des mouvements de données et des charges / ressources a des limites claires. Peut facilement migrer vers une instance ou un serveur différent pour une meilleure gestion des performances et le coût n'est pas un problème majeur. Notez que le plus simple! = Le moins cher ou le moins d'effort. Il a en fait un peu plus de tâches, mais ce sont toutes des tâches simples avec deux exceptions importantes:

1. application des contraintes - rien de tel que les contraintes de bases de données croisées dans SQL Server, vous devez donc décider s'il s'agit d'une rupture de contrat.
2. les requêtes entre bases de données utilisent des requêtes distribuées qui dépendent toujours d'OLEDB, qui est obsolète. Cela signifie que vous pourriez rencontrer des problèmes avec de nouveaux types de données et si vous rencontrez des problèmes de performances, il est peu probable qu'ils soient résolus

Le schéma d'archivage ou simplement la table d'archivage est un peu plus complexe à implémenter mais beaucoup plus facile à utiliser. Tous les objets de la même base de données vous évitent de répliquer et de gérer les contrôles d'accès. Pas de requêtes entre bases de données facilitant le réglage, la surveillance, le dépannage des performances, etc.

Partitionnement de table est une excellente solution et offre de nombreux avantages d'une table / schéma d'archive, mais offre une transparence aux utilisateurs / requêtes. Cela dit, il est le plus complexe à mettre en œuvre et nécessite des soins continus qui ne sont pas faciles pour un débutant.

Quelques considérations importantes:

• Les requêtes renvoient-elles régulièrement des données historiques / froides ou les données froides sont-elles rarement consultées?
• Les données historiques sont-elles immuables ou sont-elles mises à jour / supprimées régulièrement?
• 310 m de lignes est «modéré» (en supposant que tout dans un tableau) en fonction de la taille des lignes. Avez-vous des données sur la taille des lignes? Combien de Go est cette ligne de 310 m?
• Quel est le taux de croissance de ce tableau?
• Êtes-vous en mesure de modifier le code d'application et ses requêtes SQL?

Ce sont des considérations importantes car elles peuvent avoir un impact significatif sur la solution que vous choisissez ou peuvent même ne pas autoriser certaines solutions. Par exemple, si vos données historiques sont modifiées / mises à jour régulièrement (plus d'une fois par semaine), l'utilisation d'une base de données distincte signifie que vous devez soit utiliser le DTC pour ces requêtes, soit gérer manuellement la sécurité des transactions (non trivial pour garantir toujours correct). Le coût est nettement plus élevé que les données historiques immuables.

En outre, si vous envisagez de mettre à niveau, pensez à 2016 et à la nouvelle fonctionnalité Stretch Database: https://msdn.microsoft.com/en-us/library/dn935011.aspx

Je préférerais diviser la base de données en une base de données logique distincte pour les raisons suivantes:

1. Besoins en ressources

En le divisant en une base de données distincte, il peut être stocké sur un lecteur différent et surveillé à un rythme différent des données de production principales.

2. Performance

En répartissant les données dans une base de données distincte, la base de données de production principale est réduite en taille, ce qui améliore les performances globales.

3. Sauvegardes plus simples

La sauvegarde des données archivées peut ne pas être considérée comme aussi essentielle que les enregistrements «en direct / actuels» dans la base de données SQL principale. Cela peut signifier que les données archivées pourraient être sauvegardées moins souvent. En raison également de la nature séquentielle de la façon dont les données archivées sont enregistrées, il peut être possible de sauvegarder des sections de la base de données archivée une fois puis plus jamais. Par exemple, une fois que les données d'archive sont écrites dans la base de données des archives de modification pour 2014, il n'y aura plus de modification de ces données.

Remarque: Je pense que la réponse à bon nombre de vos questions dépend de votre situation, de la nature des données et des problèmes de performances que vous rencontriez.