Changer le type de données de la colonne PK de la table énorme

Question

Maintenant que nous avons épuisé la capacité int sur une colonne PK (qui est un IDENTITY ), j'aimerais faire ceci pour bigint , mais le simple ALTER TABLE ne semble pas capable de gérer cette grosse table. Ma question est donc la suivante: comment puis-je modifier le type d'une colonne PK en conservant les valeurs réelles et dois-je également modifier les tables de référencement?

Answer 1

Outre la suggestion de KLE, les requêtes suivantes pourraient vous aider:

Pour désactiver toutes les contraintes sur les tables faisant référence à oldTable, essayez d'exécuter le résultat de la requête suivante:

SELECT 'ALTER TABLE ' + OBJECT_NAME(fk.parent_object_id) + ' NOCHECK CONSTRAINT ' + fk.name
FROM sys.foreign_keys fk
INNER JOIN sys.foreign_key_columns AS fkc ON fk.OBJECT_ID = fkc.constraint_object_id
WHERE OBJECT_NAME (fk.referenced_object_id) = 'oldTable'

Pour déplacer toutes les données dans la nouvelle table, essayez, avec la modification du champ:

INSERT INTO newTable
SELECT CONVERT(BIGINT, ID) AS ID, COL1, COL2, ..., COLN
FROM oldTable

Pour supprimer l'ancienne table:

DROP TABLE oldTable

Pour renommer la nouvelle table avec l'ancien nom:

sp_rename newTable, oldTable

Pour réactiver toutes les contraintes sur les tables faisant référence à oldTable, essayez d'exécuter le résultat de la requête suivante:

SELECT 'ALTER TABLE ' + OBJECT_NAME(fk.parent_object_id) + ' CHECK CONSTRAINT ' + fk.name
FROM sys.foreign_keys fk
INNER JOIN sys.foreign_key_columns AS fkc ON fk.OBJECT_ID = fkc.constraint_object_id
WHERE OBJECT_NAME (fk.referenced_object_id) = 'oldTable'

J'espère que ça aide…

Answer 2

Ce que nous ferions est:

  

enregistrez votre table

1. créer une nouvelle table avec la structure correcte
2. désactiver toutes les contraintes sur ces tables et celles qui les référencent
3. déplace toutes les données dans la nouvelle table, avec modification du champ; cela peut être fait par lots
4. supprimer l'ancienne table lorsqu'elle est vide
5. renommez la nouvelle table avec l'ancien nom

6. active toutes les contraintes sur toutes les tables (certaines colonnes FK et certaines contraintes ont probablement aussi besoin d'être corrigées ... Mais elles ne sont pas PK, elles sont donc modifiables)

     

   6 édité (merci à Alexey)

C'est propre, faisable par lots, bien compris.

Answer 3

Vous devrez également modifier les tables enfants. Après tout, vous allez maintenant essayer d’y insérer un gros int. Je changerais d'abord sur les tables enfants

Ce n'est pas un processus facile ou court. Je vous suggère de dire à vos utilisateurs que la base de données va être en panne pour maintenance (vous pouvez évaluer combien de temps il faut pour faire dev) à une date donnée et réinitialiser la base de données en mode mono-utilisateur pendant que vous effectuez ces changements. Vous ne voulez pas perdre les données ajoutées (ou modifiées) par les utilisateurs dans une table pendant que vous passez à la seconde. si, pour une raison quelconque, vous ne pouvez pas avoir de fenêtre de maintenance (et je le recommande vivement pour des raisons d’intégrité des données), vous devez alors modifier les tables enfants en premier pour éviter les erreurs d’insertion si vous êtes vraiment près de la limite et resterez stable. voir les grands nombres presque immédiatement.

Assurez-vous de bien écrire la structure de la base de données dans son intégralité, y compris les valeurs par défaut, les déclencheurs, les index de constructions, etc., afin de tout recréer.

Assurez-vous de faire tout cela avec des scripts sur dev. Cela facilitera grandement la tâche une fois que vous aurez testé le processus.

Answer 4

Je pense que vous pouvez uniquement créer une nouvelle base de données avec le type de données PK modifié, puis exporter / importer des données ou insérer en bloc dans un nouveau fichier, puis renommer une nouvelle base de données. Bien sûr, cela est vrai si vous avez plusieurs tables référencées et que votre nouveau type de données PK n'est pas compatible avec previous.