SQL Server: modificar la tabla frente a soltar y crear

Question

Nuestra base de datos es SQL Server 2008 R2.Tenemos algunas tablas que tienen algunas columnas varchar(500) que quiero cambiar a datetime2 o bigint.Puedo garantizar que todos los datos de las columnas que se van a cambiar son válidos para el tipo adecuado.Los cambios de columna afectan a los índices, pero no a las claves.

Mientras debatíamos con colegas, hemos llegado a dos formas de abordar el problema.Ambos se realizarían mediante scripts T-Sql.

1. Cree una tabla temporal mediante selección, suelte la tabla anterior y vuelva a crear la tabla con los tipos de datos adecuados.Recrea los índices.
2. Modifique la tabla/tipos de datos actuales a través deALTER TABLE x ALTER COLUMN Y datetime2 y luego reconstruir o recrear los índices.

Como estoy seguro de que los datos se convertirán limpiamente, me inclino por el punto 2.Mi colega y un amigo DBA prefieren el número 1, pero mi colega no recuerda por qué lo entrenaron de esa manera.El amigo DBA está de vacaciones así que no le pregunté por qué.

¿Alguien puede darnos una idea de qué opción cree que es mejor y por qué?En última instancia, es mi decisión y me pregunto por qué se preferiría el número 1 al número 2.

Answer 1

Recientemente hice esto en mi organización en la que queríamos manejar una tabla con más de mil millones de filas.

Todo el crédito por la idea es para Aaron Bertrand y proviene de su publicación de blog. Tiros con truco:Esquema Switch-A-Roo

Pruebe el proceso a continuación en una mesa pequeña y siéntase cómodo antes de hacerlo en PROD.

1. crear 2 esquemas fake y shadow con autorización dbo.
2. Crea una tabla con las columnas y tipos de datos que quieras shadow esquema, p.e. create table shadow.Correct_Table ...
3. Inserta los datos y crea todos los índices que tiene la tabla original en el shadow tabla de esquema.
4. De esta manera, tendrá copias idénticas de la tabla con datos e índices, pero están en esquemas diferentes (lógicamente separados).
5. Una vez hecho esto, actualice las estadísticas en la tabla con shadow esquema.

6. Cambie los esquemas (esta es una operación de metadatos y es extremadamente rápida)

   --- 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. Haga una verificación final para ver si todo salió según lo planeado.Deberías hacer un select count(1) from dbo.Correct_table

8. Una vez que se confirme el paso 7 y esté satisfecho, suelte el shadow.table, shadow esquema y fake esquema como limpieza.

Answer 2

Así es como yo lo veo.

Ventajas del n.º 1

• Debido a que está utilizando una tabla separada, su tabla de producción permanece en uso hasta que termine.No tiene bloqueos (más allá de los necesarios para leer los datos).
• Esto también coincide con lo que dijo @AaronBertrand:puedes hacerlo poco a poco, probar, etc.
• Puede cambiar el orden de las columnas según sea necesario

Ventajas del n.º 2

• Es una operación de todo o nada.No hay posibilidad de que pierda datos que se insertaron/modificaron en la tabla original mientras no estaba mirando.
• Se conservan todos los permisos asignados específicamente al objeto.Si usa el n.° 1, debe asegurarse de crear un script y aplicarlo.

Dicho todo esto, normalmente usaré el n.° 2 para mesas pequeñas o cuando pueda sufrir una interrupción (aunque siempre haga una copia de seguridad de antemano) y el n.° 1 si no puedo tener una interrupción tan grande o tengo que reorganizar el orden de las columnas, etc.Si voy a hacer el punto 1, normalmente generaré el script a través de la GUI y luego lo revisaré detenidamente antes de ejecutarlo.

Answer 3

Tenga cuidado con la opción soltar y recrear:esto puede dejar a sys.depends en un estado extraño y causar problemas en los planes almacenados en caché donde el orden o el tipo de columnas cambian.

También deberá tomar medidas para mantener los permisos a nivel de objeto, ya que se perderán en el DROP y no recrearse automáticamente con el posterior CREATE.

ALTER TABLE En mi opinión, es la opción más limpia, pero asegúrese de realizar pruebas exhaustivas antes de hacerlo en producción para asegurarse de que todo esté bien después y para asegurarse de saber cuánto tiempo llevarán las operaciones (en una tabla con muchas filas, esto podría llevar bastante tiempo). ).

Answer 4

Mi colega terminó encontrando un artículo sobre a qué se refería: http://www.nigelrivett.net/SQLAdmin/AlterTableProblems.html.Después de leer esto y darnos cuenta de que se acercaba nuestro informe de fin de año, decidimos no realizar modificaciones en los tipos de columnas y volveremos a revisar esto en los próximos meses.Creo que después de leer el artículo, puedo optar por el método Soltar/Crear.

Gracias a todos por sus comentarios sobre esto.Hay muchos enfoques interesantes a considerar cuando decidimos seguir adelante.