Selon les modifications que vous apportez, il peut parfois être plus facile de prendre une fenêtre de maintenance. Pendant cette fenêtre (où personne ne devrait pouvoir modifier les données du tableau), vous pouvez :
- supprimez tous les index/contraintes pointant vers l'ancienne colonne et désactivez les déclencheurs
- ajouter un nouveau nullable colonne avec le nouveau type de données (même s'il est censé être NOT NULL)
- mettre à jour la nouvelle colonne en la définissant égale à la valeur de l'ancienne colonne (et vous pouvez le faire par blocs de transactions individuelles (par exemple, affectant 10000 lignes à la fois en utilisant
UPDATE TOP (10000) ... SET newcol = oldcol WHERE newcol IS NULL) et avec CHECKPOINT pour éviter de surcharger votre log) - une fois les mises à jour terminées, supprimez l'ancienne colonne
- renommer la nouvelle colonne (et ajouter une contrainte NOT NULL si nécessaire)
- reconstruire les index et mettre à jour les statistiques
La clé ici est qu'elle vous permet d'effectuer la mise à jour de manière incrémentielle à l'étape 3, ce que vous ne pouvez pas faire en une seule commande ALTER TABLE.
Cela suppose que la colonne ne joue pas un rôle majeur dans l'intégrité des données - si elle est impliquée dans un groupe de relations de clé étrangère, il y a plus d'étapes.
MODIFIER
De plus, et je me demandais à voix haute, je n'ai fait aucun test pour cela (mais en l'ajoutant à la liste). Je me demande si la compression page + ligne aiderait ici? Si vous modifiez un INT en un BIGINT, avec la compression en place, SQL Server doit toujours traiter toutes les valeurs comme si elles tenaient toujours dans un INT. Encore une fois, je n'ai pas testé si cela rendrait une modification plus rapide ou plus lente, ou combien de temps il faudrait pour ajouter de la compression en premier lieu. Il suffit de le jeter là-bas.
