SQL Server - Modifier la table ou supprimer et créer

dba.stackexchange https://dba.stackexchange.com/questions/107078

Question

Notre base de données est SQL Server 2008 R2.Nous avons des tables qui contiennent des colonnes varchar(500) que je souhaite basculer vers datetime2 ou bigint.Je peux garantir que toutes les données des colonnes à changer sont valides pour le type approprié.Les modifications de colonnes affectent les index, mais pas les clés.

En discutant avec des collègues, nous sommes parvenus à deux manières d’aborder le problème.Ces deux opérations seraient effectuées via des scripts T-Sql.

  1. Créez une table temporaire via select into, supprimez l'ancienne table et recréez la table avec les types de données appropriés.Recréez les index.
  2. Modifiez les types de table/données actuels viaALTER TABLE x ALTER COLUMN Y datetime2 puis reconstruisez ou recréez les index.

Parce que je suis convaincu que les données seront converties proprement, je penche vers le numéro 2.Mon collègue et un ami DBA préfèrent le numéro 1, mais mon collègue ne se souvient plus pourquoi ils l'ont formé de cette façon.L'ami DBA est en vacances donc je ne lui ai pas demandé pourquoi.

Quelqu'un peut-il donner un aperçu de l'option qui lui semble la meilleure et pourquoi ?En fin de compte, c'est ma décision et je me demande pourquoi le n°1 serait préféré au n°2 ?

Était-ce utile?

La solution

J'ai récemment fait cela dans mon organisation dans laquelle nous voulions gérer une table avec plus d'un milliard de lignes.

Tout le mérite de l'idée revient à Aaron Bertrand et provient de son article de blog Coups astucieux :Schéma Switch-A-Roo

Testez le processus ci-dessous sur une petite table et installez-vous confortablement avant de le faire dans PROD.

  1. créer 2 schémas fake et shadow avec autorisation dbo.
  2. Créez un tableau avec les colonnes et les types de données que vous souhaitez shadow schéma, par ex. create table shadow.Correct_Table ...
  3. Insérez les données et créez tous les index que la table d'origine possède dans le shadow table de schéma.
  4. De cette façon, vous disposez de copies identiques de table avec des données et des index, mais elles se trouvent dans des schémas différents (logiquement séparés).
  5. Une fois terminé, mettez à jour les statistiques sur la table avec shadow schéma.

  6. Changer les schémas (il s'agit d'une opération de métadonnées extrêmement rapide)

    --- ALTER SCHEMA TargetSchema TRANSFER SourceSchema.TableName; 

BEGIN TRANSACTION;

  ALTER SCHEMA fake TRANSFER     dbo.original_table;
  ALTER SCHEMA dbo  TRANSFER  shadow.Correct_Table;

COMMIT TRANSACTION;

ALTER SCHEMA shadow TRANSFER fake.Lookup;

  7. Faites une dernière vérification pour voir si tout s’est déroulé comme prévu.Tu devrais faire un select count(1) from dbo.Correct_table

  8. Une fois l'étape 7 confirmée et que vous êtes satisfait, déposez le shadow.table, shadow schéma et fake schéma comme nettoyage.

Autres conseils

Voici comment je le vois.

Avantages pour le n°1

  • Parce que vous utilisez une table séparée, votre table de production reste utilisée jusqu'à ce que vous ayez terminé.Aucun verrou dessus (au-delà de ceux nécessaires à la lecture des données).
  • Cela va également avec ce que @AaronBertrand a dit :vous pouvez le faire au coup par coup, tester, etc.
  • Vous pouvez modifier l'ordre des colonnes selon vos besoins

Avantages pour le n°2

  • C'est une opération tout ou rien.Il n'y a aucune chance que vous perdiez les données insérées/modifiées dans le tableau d'origine alors que vous ne le cherchiez pas.
  • Toutes les autorisations spécifiquement attribuées à l'objet sont conservées.Si vous utilisez le n°1, vous devez vous assurer que vous avez rédigé un script et que vous l'appliquez.

Tout cela étant dit, j'utiliserai généralement le numéro 2 pour les petites tables ou lorsque je peux avoir une panne (faites toujours une sauvegarde au préalable) et le numéro 1 si je ne peux pas obtenir une panne aussi importante ou si je dois réorganiser l'ordre des colonnes, etc.Si je dois faire le n°1, je générerai généralement le script via l'interface graphique, puis je l'examinerai attentivement avant de l'exécuter.

Soyez prudent avec l'option déposer et recréer :cela peut laisser sys.depends dans un état étrange et causer des problèmes pour les plans mis en cache où l'ordre ou le type des colonnes change.

Vous devrez également prendre des mesures pour conserver les autorisations au niveau des objets, car celles-ci seront perdues dans le DROP et n'est pas automatiquement recréé avec les versions ultérieures CREATE.

ALTER TABLE est l'option la plus propre, IMO, mais assurez-vous de tester minutieusement avant de le faire en production, à la fois pour vous assurer que tout va bien par la suite et pour vous assurer de savoir combien de temps les opérations prendront (sur une table avec de nombreuses lignes, cela pourrait prendre un certain temps ).

Mon collègue a fini par trouver un article sur ce à quoi il faisait référence : http://www.nigelrivett.net/SQLAdmin/AlterTableProblems.html.Après avoir lu ceci et réalisé que notre rapport de fin d'année approchait, nous avons décidé de ne pas apporter de modifications aux types de colonnes et nous y reviendrons dans les prochains mois.Je pense qu'après avoir lu l'article, je pourrais simplement utiliser la méthode Drop/Create.

Merci à tous pour leurs commentaires à ce sujet.Autant d’approches intéressantes à considérer lorsque l’on décide d’aller de l’avant.

Licencié sous: CC-BY-SA avec attribution
Non affilié à dba.stackexchange
scroll top