Table massive dans la base de données SQL 2005 a besoin de meilleures performances!

Question

Je travaille sur une application Web axée sur des données qui utilise une base de données SQL 2005 (édition standard).

L'une des tables est assez grand (8 millions de lignes + grand avec environ 30 colonnes). La taille de la table affecte évidemment la performance du site qui est à sélectionner des éléments de la table par procs stockées. Le tableau est indexé mais la performance est médiocre en raison de l'énorme quantité de lignes dans la table - cela fait partie du problème - la table est lue également mis à jour, nous ne pouvons pas ajouter / supprimer des index sans l'un des les opérations pire.

Le but que j'ai ici est d'augmenter les performances lors de la sélection des articles de la table. Le tableau contient des données « actuelles » et anciens / données à peine effleuré. La solution la plus efficace que nous pouvons penser à ce stade est de séparer la table dans 2, soit un pour les anciens éléments (avant une certaine date, soit 1 janvier 2005) et l'un des éléments nouveaux (égal ou avant le 1er janvier 2005) .

Nous savons que des choses comme vues partitionnées distribuées - mais toutes ces fonctionnalités nécessitent Enterprise Edition, que le client ne sera pas acheter (et non, jeter le matériel à elle ne va pas se passer non plus)

.

Answer 1

Vous pouvez toujours rouler votre propre « partage du pauvre / DPV, » même si elle ne sent pas la bonne façon de le faire. Ceci est juste une large approche conceptuelle:

1. Créer une nouvelle table pour les données de l'année en cours - même structure, les mêmes indices. Ajustez la procédure stockée qui écrit au principal, grande table à écrire sur les deux tables (juste temporairement). Je recommande de faire la logique de la procédure stockée dire IF CURRENT_TIMESTAMP> = « [une date tout sans temps] » - ce qui rendra facile à remblayer les données contenues dans ce tableau qui date d'avant la modification de la procédure qui commence à enregistrer là.

2. Créer une nouvelle table pour chaque année dans votre histoire en utilisant SELECT INTO de la table principale. Vous pouvez le faire dans une autre base de données sur la même instance pour éviter la surcharge dans la base de données actuelle. Les données historiques ne va pas changer, je suppose, donc dans cette autre base de données, vous pouvez même faire lire que lorsqu'il est fait (ce qui permettra d'améliorer considérablement les performances de lecture).

3. Une fois que vous avez une copie de toute la table, vous pouvez créer des vues qui font référence à juste l'année en cours, une autre vue que référence 2005 à l'année en cours (en utilisant ALL UNION entre la table actuelle et ceux de l'autre base de données qui sont> = 2005), et un autre qui fait référence à tous les trois ensembles de tables (celles qui sont mentionnées, et les tableaux qui datent d'avant 2005). Bien sûr, vous pouvez briser ce encore plus, mais je voulais juste garder le concept minimal.

4. Modifier vos procédures stockées qui lisent les données d'être « plus intelligents » - si la plage de date demandée relève de l'année civile en cours, utilisez l'affichage le plus petit qui est seulement local; si la plage de dates est> = 2005 puis utilisez le second point de vue, utilisez bien le troisième point de vue. Vous pouvez suivre la même logique avec les procédures stockées qui écrivent, si vous faites plus que l'insertion de nouvelles données qui ne concerne que l'année en cours.

5. À ce stade, vous devriez être en mesure d'arrêter l'insertion dans la table massive et, une fois que tout est prouvé à travailler, déposer et récupérer l'espace disque (et je veux dire libérer de l'espace dans le fichier de données (s) pour la réutilisation, ne pas effectuer un psy db -. puisque vous utiliserez cet espace nouveau)

Je n'ai pas tous les détails de votre situation, mais s'il vous plaît suivre si vous avez des questions ou des préoccupations. Je l'ai utilisé cette approche dans plusieurs projets de migration, y compris celui qui se passe en ce moment.

Answer 2

  

le rendement est médiocre en raison de l'énorme quantité de lignes dans la table

8 millions de lignes ne sonnent pas tout ce que fou. Avez-vous vérifié vos plans de requête?

  

la table est lu comme également mis à jour

Vous mettez à jour en fait une colonne indexée ou est-il également lu et inséré ?

  

(et non, jeter le matériel à elle ne va pas se passer non plus)

C'est dommage parce que la RAM est la saleté pas cher.

Answer 3

Reconstruire tous vos index. Cela stimulera les performances des requêtes. Comment faire est cette et plus sur l'effet sur la reconstruction de cluster et non indice -clustered ici

En second lieu effectuer de fragmentation sur votre disque sur lequel la base de données est stockée.