Remplacer la colonne d'identité d'int à bigint

J'utilise SQL Server 2008, et j'ai une table qui contient environ 50 rangées de moulin.

Cette table contient une colonne d'identité principale de type int .

Je veux mettre à jour cette colonne pour qu'elle soit bigint .

J'ai besoin de savoir comment faire cela de manière rapide qui ne rendra pas mon server de database indisponible, et ne supprimera ni ne ruinera aucune de mes données

Comment devrais-je le faire mieux? Quelles sont les conséquences de faire cela?

Eh bien, ce ne sera pas un moyen rapide de le faire, vraiment …

Mon approche serait la suivante:

  1. créer une nouvelle table avec une structure identique – sauf que la colonne ID est BIGINT IDENTITY au lieu de INT IDENTITY

    —- [mettez votre server en mode mono-user exclusif ici; l'user ne peut pas utiliser votre server à partir de ce point]

  2. find et désactiver toutes les contraintes de key étrangère référençant votre table

  3. tournez SET IDENTITY_INSERT (your new table) ON

  4. insérez les lignes de votre ancienne table dans la nouvelle table

  5. tournez SET IDENTITY_INSERT (your new table) OFF

  6. supprime ton ancienne table

  7. Renommez votre nouvelle table à l'ancien nom de la table

  8. mettre à jour toutes les tables qui ont une reference FK à votre table pour utiliser BIGINT au lieu de INT (cela devrait être possible avec une simple ALTER TABLE ..... ALTER COLUMN FKID BIGINT )

  9. recréer à nouveau toutes les relations de foreign keys

  10. maintenant vous pouvez returnner votre server à l'utilisation normale de multi-users

Qu'est-ce que je rate?

Pourquoi ne pouvez-vous pas faire ceci:

 ALTER TABLE tableName ALTER COLUMN ID bigint 

Je suppose que je l'essaie dans un environnement de test d'abord, mais cela fonctionne toujours pour moi

Probablement le meilleur moyen est de créer une nouvelle table avec une colonne BIGINT IDENTITY, déplacer datatables existantes en utilisant SET IDENTITY_INSERT ON; puis renommez les tables. Vous devrez le faire pendant une window de maintenance, comme vous le feriez si vous changiez le type de données dans Management Studio (ce qui créerait pareillement une nouvelle table, déplacerait datatables et bloquerait tout le monde dans le process).

Pourquoi quelqu'un voudrait utiliser un BigInt au lieu de Int comme IDENTITY?

Considérez ce scénario: Votre database existe dans plusieurs environnements dont 1 instance dans un environnement de production en direct et plusieurs autres instances dans (TestA, B, C, etc.), (QA A, B, C, etc.), (Demo A, B, C, etc), (UAT A, B, C, etc.), (Entraînement A, B, C, etc.) et ainsi de suite … Vous ne voulez même pas savoir …

Ce champ IDENTITY de la database est utilisé pour transmettre un numéro unique à un fournisseur tiers qui est un environnement partagé dans les environnements de non-production. Le fournisseur facture un arm et une jambe afin de mettre en place plusieurs environnements de sorte que l'entreprise en a un pour la DB de production et un pour tous les autres.

Donc … quand les tests se produisent dans des environnements non productifs, ces nombres ne peuvent jamais se croiser de n'importe quel environnement de non-production dans lequel vous testez. Et les tests incluent des tests de stress … envoyer des centaines de milliers de lignes à la fois.

Pour couronner le tout … TOUS ces environnements sont rafraîchis avec la production afin que le champ Identité soit réinitialisé avec tout ce qui était en production. Il faut donc garder une trace de la propagation utilisée dans chaque environnement, puis réinitialiser l'IDENTITÉ à une nouvelle propagation qui n'a jamais été utilisée auparavant. Le fournisseur tiers vomira si un nombre déjà est envoyé à nouveau dans ces environnements. Et le fournisseur ne veut pas ou ne peut pas actualiser ou réinitialiser ces numéros de leur côté.

Ceci est un vrai problème mondial et le domaine actuel rest à être un int dans TOUS les environnements et la gestion de suivi de ces écarts est mis à jour chaque sortingmestre ou chaque fois que quelqu'un fait un test de stress massif de milliers de transactions.

Donc, dans environ 10 ans, cette IDENTITÉ devra être mise à jour vers un BIGINT ou quelqu'un devra convaincre le fournisseur tiers de se rafraîchir de son côté.

Ah oui, la direction pourrait donner un âne de rat à ce sujet jusqu'à ce que tout s'écroule tout à coup.

Alors le HACK "ALTER TABLE tableName ALTER COLUMN ID bigint" fera très bien l'affaire. Le traitement de l'espace et de l'index est bon marché!