Ajout de colonnes aux tables de production

Quelle est la meilleure façon d'ajouter des colonnes à de grandes tables de production sur SQL Server 2008 R2? Selon les livres en ligne de Microsoft:

Les modifications spécifiées dans ALTER TABLE sont implémentées immédiatement. Si les modifications nécessitent des modifications des lignes du tableau, ALTER TABLE met à jour les lignes. ALTER TABLE acquiert un verrou de modification de schéma sur la table pour s'assurer qu'aucune autre connexion ne référence même les métadonnées de la table pendant la modification, à l'exception des opérations d'index en ligne qui nécessitent un verrou SCH-M très court à la fin.

(http://msdn.microsoft.com/en-us/library/ms190273.aspx)

Sur une grande table avec des millions de lignes, cela peut prendre un certain temps. Prendre une panne est-il la seule option? Quelle est la meilleure façon de gérer ce genre de situation?

"Ça dépend"

Si vous ajoutez une colonne qui ne nécessite pas l'ajout de données aux lignes, cela peut être assez rapide.

Par exemple, l'ajout d'un entier ou d'un caractère nécessite des mouvements physiques de ligne. L'ajout d'un varchar nullable sans défaut ne devrait pas (sauf si le bitmap NULL doit être développé)

Vous devez l'essayer sur une copie de production restaurée pour obtenir une estimation

Créer une nouvelle table, copier, renommer peut prendre plus de temps si vous devez rajouter des index et des clés sur une table de milliards de lignes.

J'ai changé des milliards de tables de lignes qui ont pris quelques secondes pour ajouter une colonne nullable.

Ai-je dit de faire une sauvegarde en premier?

Si la colonne est NULLable, l'impact doit être négligeable. Si la colonne ne peut pas être NULL et que la valeur doit être définie, cela peut être très différent. Ce que je ferais dans ce cas est, au lieu d'ajouter une contrainte non nulle et par défaut en une seule fois, d'ajouter efficacement des données à chaque ligne:

• ajouter la colonne comme NULLable - devrait être rapide dans la plupart des cas
• mettre à jour les valeurs par défaut
  • vous pouvez le faire par lots si nécessaire
  • vous pouvez également l'utiliser pour appliquer une logique conditionnelle où certaines lignes peuvent ne pas obtenir la valeur par défaut
• ajouter les contraintes non nulles / par défaut
  • ce sera plus rapide lorsqu'aucune des données n'est NULL, mais devrait toujours être mesurable

Convenez avec @gbn que vous pouvez tester cela en restaurant une copie de la production et en l'essayant là ... vous aurez une bonne idée du timing (en supposant que le matériel est quelque peu similaire) et vous pouvez également voir l'impact sur le journal des transactions.

Avez-vous envisagé:

1. Création d'une nouvelle table qui inclut les modifications apportées à la définition de table.
2. Insertion dans la nouvelle définition de table en sélectionnant dans la table d'origine.
3. Renommer la table d'origine en _orig, puis renommer la nouvelle table en son nom d'origine.

L'inconvénient ici est que vous devez avoir suffisamment d'espace dans la base de données pour effectuer cette modification. Vous pouvez toujours avoir besoin d'un verrou de lecture sur la table pour éviter toute lecture sale.

Cependant, vous minimisez l'impact sur les utilisateurs finaux s'il existe une possibilité ou un besoin d'accéder simultanément à la table d'origine. Il devrait également minimiser les durées de verrouillage.