Modification de l'indexation sur la table existante dans SQL Server 2000

Question

Voici le scénario:

SQL Server 2000 (8.0.2055)

Le tableau a actuellement 478 millions de lignes de données. La colonne Primary Key est une INT avec IDENTITY. Une contrainte unique est imposée sur deux autres colonnes avec un index non groupé. Il s'agit d'une application fournisseur et nous sommes uniquement responsables de la maintenance de la base de données.

Maintenant, le vendeur a recommandé de faire ce qui suit "pour améliorer les performances"

1. Drop the PK et index en cluster
2. Drop the index non cluster sur les deux colonnes avec l'UNIQUE CONTRAINTE
3. Recréer le PK, avec un indice de NON CLUSTERED
4. Créer un index clusterisé sur les deux colonnes avec l'UNIQUE CONTRAINTE

Je ne suis pas convaincu que c'est la bonne chose à faire. J'ai un certain nombre de préoccupations. En supprimant le PK et les index, vous allez créer un tas avec 478 millions de lignes de données. Ensuite, la création d'un INDICE CLUSTERED sur deux colonnes serait une tâche vraiment gigantesque. Est-ce que créer une autre table avec la même structure et le nouveau schéma d'indexation, puis copier les données, abandonner l'ancienne table et renommer la nouvelle serait une meilleure approche?

Je ne suis pas sûr non plus comment les processus stockés réagiront. Vont-ils continuer à utiliser le plan d'exécution mis en cache, étant donné qu'ils ne sont pas recompilés explicitement.

Je ne suis tout simplement pas capable de comprendre quel type d '«amélioration des performances» ce changement apportera. Je pense que cela aura effectivement l'effet inverse.

Toutes les pensées sont les bienvenues.

Merci à l'avance,

Raj

Answer 1

Tous les procs stockés recompile automatiquement. Cela se produira de toute façon lorsque les statistiques changent et après la maintenance de l'index de toute façon. À un certain point, vous devez réorganiser 478 millions de lignes (supprimer/créer des index) ou déplacer (nouvelle table). Aucun des deux n'est meilleur que l'autre, malheureusement. Je ressens votre douleur: nous avons de grandes tables similaires avec de nouvelles colonnes en attente et des changements d'index. Cela dit, vous devriez le faire à l'étape 2-1-4-3 pour éviter la maintenance inutile de l'index sans cluster lorsque vous supprimez/créez l'index clusterisé.

Supprimez la contrainte unique. L'index clusterisé peut être unique et regroupé. Une construction unique est juste un autre index qui serait inutile. En ce qui concerne les performances, demandez peut-être au vendeur pourquoi.

Answer 2

La création d'une autre table avec la même structure et le nouveau schéma d'indexation, puis de copier les données, de supprimer l'ancienne table et de renommer la nouvelle, serait une meilleure approche?

Je crois que c'est ce que SQL Enterprise Manager fera de toute façon dans les coulisses si vous utilisez les outils visuels pour le faire. Si vous effectuez une modification de schéma, par exemple ajouter une colonne au milieu d'une table ou modifier des clés primaires, vous disposez d'un petit bouton vous permettant d'effectuer des modifications de script. Si vous affichez ce script, vous pouvez voir les étapes qu'Enterprise Manager suivra pour faire ce que vous avez demandé.

Answer 3

La seule chose que je voudrais examiner sérieusement est la question de savoir quel type ces deux autres colonnes sont - quelle est leur taille, par rapport à l'identité INT (4 octets) ??

La raison pour laquelle je demande: la clé en cluster seront ajoutés à tous les indices non regroupés sur la table, aussi - et si vous avez près de 500 millions de lignes, il fera une énorme différence si le regroupement La clé est un seul INT de 4 octets, ou par exemple deux GUID de 16 octets. Ce n'est pas seulement sur le disque, remarquez que les pages sont chargées dans la mémoire vive de SQL Server dans leur intégralité - donc, en gonflant potentiellement votre clé de clustering, vous encourez des pénalités de performance en raison du plus grand nombre de pages sur le disque (et en RAM) que vos indices non-clusterisés auraient besoin. La seule raison impérieuse que je pourrais voir pour passer en revue avec ces changements serait si en regroupant la table en utilisant ces deux autres colonnes, vous gagneriez quelque chose en termes de performance de requête, par exemple. si certaines des requêtes les plus fréquentes seraient plus rapides, du fait que la table est maintenant mise en cluster par ces deux colonnes. C'est vraiment difficile à savoir à moins de savoir ce que sont réellement les modèles d'accès et de requête ....