MS SQL Server
  1. MS SQL Server
  3. Conseils pour améliorer les performances de la database de taille supérieure à 40 Go (Sql Server 2005) et augmenter d'environ 3 Go par mois
Intereting Posts
Comment puis-je afficher les valeurs des lignes dans le server SQL des colonnes? ExecuteScalar () analogique dans une requête Linq to Sql personnalisée Est une bonne pratique pour désactiver les index avant l'insertion de nombreux loggings sur SQL Server? Impossible de créer CLUSTERED INDEX sur une vue à cause de LEFT JOIN ou de la sous-requête Exportation de données de SQL vers XML – Valeur NULL Comment merge des lignes de deux tables lorsqu'il n'y a pas de relation entre les tables dans sql en utilisant logstash avec Sql Server Essayer d'installer les pilotes MSSQL avec EasyPHP 12 Requête de données circulaires SQL Server SQL Select Anniversaires à venir pyodbc.connect () fonctionne, mais pas sqlalchemy.create_engine (). connect () Puis-je exécuter UPDATE et INSERT pour une condition de correspondance de fusion SQL? SQL Server: Conversion de données EDI vers XML Erreur ASP et ADO: Aucune valeur donnée pour un ou plusieurs parameters requirejs SQL Ajout de plusieurs lignes et soustraction de trois tables avec des contraintes de date Complètement coincé

Conseils pour améliorer les performances de la database de taille supérieure à 40 Go (Sql Server 2005) et augmenter d'environ 3 Go par mois

La database actuelle ou notre projet a dépassé les 40 Go ce mois-ci et augmente en moyenne d'environ 3 GB par mois. Maintenant, toutes les tables sont mieux normalisées et une indexing correcte a été utilisée. Mais toujours à mesure que la taille augmente, il faut plus de time pour lancer des requêtes basiques comme 'select count (1) from table'. Alors pouvez-vous partager quelques points supplémentaires qui aideront dans ce front. La database est Sql Server 2005. Plus loin si nous implémentons le Partitionnement ne créerait-il pas un overhead?

Merci d'avance.

  1. assurez-vous d'avoir des index appropriés / appropriés
  2. assurez-vous de disposer d'une bonne stratégie de maintenance de l'index (par exemple, recréer / défragmenter / conserver les statistics à jour pour vous assurer que les index restnt performants)
  3. identifier les requêtes peu performantes et les optimiser (peut avoir été écrit / testé par rapport à de petits volumes de données lorsque les problèmes de performance ne se seraient pas manifestés)
  4. envisagez de partitionner vos données (par exemple, SQL 2005 et versions antérieures prend en charge le partitionnement si vous avez Enterprise Edition). Edit: pour élaborer sur le partitionnement de SQL Server, je recommand vivement de lire cet article MSDN sur le pourquoi et le comment. D'une manière générale, Randy Shoup (architecte eBay) a également fait un bon exposé à QCon 2008 sur l'évolutivité, dont l'un des points keys de la mise à l'échelle d'un système en général est la partition. C'est résumé ici .
  5. le matériel de votre server db est-il suffisant? pourrait-il bénéficier de plus de memory? Edit: en regardant votre commentaire avec vos informations de matériel, je pense que vous pourriez faire avec (au less) jeter plus de RAM dedans
  6. vous pouvez bénéficier d'une dénormalisation. Difficile d'être spécifique sans connaître la structure exacte de la database, mais la dénormalisation peut améliorer certaines requêtes au désortingment de la duplication des données / de l'espace disque

Une database de 40 Go n'est en aucun cas considérée comme une grande database de nos jours. Et une croissance de 3 Go par mois n'a rien d'inhabituel.

Cependant, dans les domaines, vous devez vraiment faire attention à certaines petites choses que vous pourriez get dans des bases de données plus petites. Puisque vous écrivez à propos de l'émission d'une requête "SELECT COUNT (1) …", vous voudrez peut-être réfléchir à la nécessité de telles requêtes. Cela ressemble à une fonctionnalité de type "affichage du nombre de lignes dans la table". Avez-vous vraiment besoin de ce que vous appelez des «requêtes de base» ou pouvez-vous vous en passer? Considérant particulièrement cette requête: avez-vous besoin du résultat pour être précis ou pourrait-il être aussi une "bonne estimation"? Si c'est le cas, vous voudrez peut-être append un indice WITH (NOLOCK) ici et là, où la précision n'est pas obligatoire. Cependant, utilisez NOLOCK judicieusement car il renverra des données erronées à une vitesse incroyable. 🙂

Beaucoup de bonnes suggestions ont été mentionnées par AdaTheDev, laissez-moi append un point:

Rien ne vous donne de meilleures performances qu'un schéma solide et solide. Et, qui sait, ce qui a été jugé approprié au moment où vous avez conçu le schéma, peut avoir besoin d'être révisé maintenant après avoir été en production pendant un certain time. Ceci est particulièrement vrai pour les indices.

Vous devriez jeter un oeil ici: Amélioration des performances de SQL Server

Votre machine est assez faible, mais comme vous n'avez même pas mentionné le disque que vous utilisez, c'est probablement le problème. Vous aurez besoin d'un disque très rapide pour soutenir une database de 40 Go avec 4 Go de RAM, plusieurs disques rayés seraient un ssortingct minimum.

Je commencerais par utiliser Performance Monitor et SQL Server Profiler pour déterminer quelles sont les limites de performance les plus critiques sur votre système. Après cela, vous avez probablement une bonne idée par où commencer.

Voici un sharepoint départ: Résolution des problèmes de performances dans SQL Server 2005

Je pense que dans certains points, vous avez besoin de partitionnement. C'est une approche fondamentale pour mettre à l'échelle la database.

En outre, vous voudrez peut-être aller aux principes de base et repenser à la raison de la croissance de la DB et de sa structure. 3GB par mois en plus (et en augmentant probablement si vous avez du succès) va vous causer des ennuis tôt ou tard 😉