Cambiando la columna de identidad de INT a BIGINT

El paso a paso o código que hallarás en este post es la solución más sencilla y efectiva que encontramos a tus dudas o problema.

Solución:

Como hay una primaria key definido en la columna de identidad, no podrá modificar directamente esta columna.

Se pueden usar los dos enfoques que ha mencionado en su pregunta y el tiempo de inactividad depende del rendimiento de su servidor y la cantidad de filas que residen en esa tabla.

1. Suelte el PK y modifique la columna; o

Primero suelte el PK

/****** Object: DROP Index [PK_DatabaseLog_DatabaseLogID]******/

ALTER TABLE [dbo].[TableName] DROP CONSTRAINT [PK_TableName_ID]
GO

Alterar columna

ALTER TABLE [dbo].[TableName] ALTER COLUMN [dbo.ID] BIGINT

Agregar principal key

/****** Object: ADD Index [PK_DatabaseLog_DatabaseLogID]******/
ALTER TABLE [dbo].[TableName] ADD  CONSTRAINT [PK_TableName_ID] PRIMARY KEY CLUSTERED 
(
    [ID] ASC
)

Este enfoque no suele llevar mucho tiempo. En mi entorno, toma unos segundos en tablas grandes que tienen más de 5 millones de filas.

2. El método copiar-soltar-renombrar, como se describe

También puede utilizar este enfoque. Sin embargo, para este enfoque necesita más tiempo de inactividad que el Enfoque uno, ya que debe sincronizar las tablas.

Aaron Bertrand tiene una serie de 4 partes sobre este tema, comenzando con:

Minimizar el impacto de ampliar una columna de IDENTIDAD – parte 1

Si es absolutamente necesario mudarse a bigintdebe minimizar el tiempo de inactividad y tener mucho tiempo para la planificación, el enfoque que documenta en la parte 4 es:

En un nivel muy alto, el enfoque es crear un conjunto de tablas ocultas, donde todas las inserciones se dirigen a una nueva copia de la tabla (con el tipo de datos más grande), y la existencia de los dos conjuntos de tablas es transparente. posible a la aplicación y sus usuarios.

Con más detalle, Aaron dice:

1. Cree instantáneas de las tablas, con los tipos de datos correctos.
2. Modifique los procedimientos almacenados (o el código ad hoc) para usar bigint para los parámetros. (Esto puede requerir modificaciones más allá de la lista de parámetros, como variables locales, tablas temporales, etc., pero este no es el caso aquí).
3. Cambie el nombre de las tablas antiguas y cree vistas con esos nombres que unen las tablas antiguas y nuevas.
   • Esas vistas tendrán en lugar de disparadores para dirigir correctamente las operaciones DML a las tablas adecuadas, de modo que los datos aún puedan modificarse durante la migración.
   • Esto también requiere que SCHEMABINDING se elimine de cualquier vista indexada, que las vistas existentes tengan uniones entre tablas nuevas y antiguas, y que se modifiquen los procedimientos que dependen de SCOPE_IDENTITY().
4. Migre los datos antiguos a las nuevas tablas en fragmentos.
5. Limpieza, consistente en:
   • Descartar las vistas temporales (que eliminarán los activadores INSTEAD OF).
   • Cambiar el nombre de las nuevas tablas a los nombres originales.
   • Corrección de los procedimientos almacenados para volver a SCOPE_IDENTITY().
   • Dejar caer las mesas viejas, ahora vacías.
   • Volviendo a colocar SCHEMABINDING en vistas indexadas y recreando índices agrupados.

valoraciones y comentarios

Si guardas algún reparo o forma de progresar nuestro sección eres capaz de añadir una reseña y con gusto lo observaremos.

---

---

Utiliza Nuestro Buscador