2010-04-28 15 views
6

Tengo dos tablas con 10-20 millones de filas que tienen claves principales GUID y 12 tablas relacionadas a través de clave externa. Las tablas base tienen 10-20 índices cada una.Método para alterar clave principal de GUID a BigInt en tablas relacionadas con SQL Server

Estamos pasando de GUID a claves principales BigInt. Me pregunto si alguien tiene alguna sugerencia sobre un enfoque. En este momento este es el enfoque que estoy pensando:

  1. Borrar todos los índices y las teclas F de todas las tablas implicadas.
  2. agregar la columna 'NewPrimaryKey' a cada mesa
  3. Haga la identidad clave en las dos tablas base
  4. Script, el cambio de datos "tabla de actualización x, establecer NewPrimaryKey = y donde OldPrimaryKey = z
  5. Cambiar el nombre del PrimaryKey originales a 'oldprimarykey'
  6. Cambiar el nombre de la columna 'NewPrimaryKey' 'PrimaryKey'
  7. Guión volver todos los índices y fkeys

¿esto parece como un buen enfoque? ¿Alguien sabe de una herramienta o script que ayudaría con esto?

TD: Editado por información adicional. Consulte esta publicación de blog que aborda un enfoque cuando el GUID es el principal: http://www.sqlmag.com/blogs/sql-server-questions-answered/sql-server-questions-answered/tabid/1977/entryid/12749/Default.aspx

+0

¿Qué ruta acabas de llevar? Además de lo que ha dicho, la aplicación deberá asegurarse de saber que PrimaryKey ahora es su nuevo tipo de datos y no Guid. – user420667

Respuesta

0

Ciertamente suena como esta estrategia funcionaría - dejando caer las limitaciones, el cambio de la columna de debajo de ellos (cambios de tipo, el nombre sigue siendo el mismo) y volviendo a crear las limitaciones es bastante elegante.

¿El objetivo es finalmente soltar las columnas GUID? Si es así, en realidad no se recuperar el espacio a menos que las tablas se copian o reconstruidas, así que tal vez el siguiente ajuste:

...
4.Script el cambio de datos "tabla de actualización x, establecer NewPrimaryKey = y donde oldPrimaryKey = z
5. gota PrimaryKey original 'oldprimarykey'
6.Rename la columna 'NewPrimaryKey' 'PrimaryKey'
7.Script volver todos los índices y fkeys (construcción de índices agrupados "reconstruya" tablas)
8. Para todas las tablas que no tienen índices agrupados, haga algo para asegurarse de que se reconstruyan y su espacio sea recuperado (dicha compilación y luego soltar un índice agrupado)

¡No hace falta decirlo, pruébelo en una caja de desarrollo antes de ejecutar en producción!

+0

Para compatibilidad con versiones anteriores de algunos correos electrónicos antiguos con enlaces, necesitamos mantener el ID anterior en las dos tablas base, de modo que si aparece un enlace anterior, podemos ubicarlo; de lo contrario, en las tablas relacionadas podemos colocar la columna anterior – BoomTownTech

3

Su enfoque es cómo lo haría.

¿Realmente necesitas bigint? un int 4 bytes regular irá a 2 mil millones (2,147,483,647).

int, bigint, smallint, and tinyint

+0

Podríamos llegar a eso en 10 años más o menos ... ¿es simplemente un problema de espacio o un int proporcionar un rendimiento drásticamente mejor en los índices? – BoomTownTech

+3

16 bytes para guid (uniqueidentifier), u 8 para bigint, o solo 4 bytes para int regular. Esto no es solo espacio en el disco, sino también en la memoria caché. Además, obtendrá más claves en una página (búsqueda más rápida), y cada índice incluye el PK, por lo tanto, cuanto más pequeño, mejor. –

0

También me gustaría añadir:

Asegúrese de que tiene una buena copia de seguridad actual antes de comenzar. Cambie el servidor para que se ejecute en modo de usuario único (avise a los usuarios de un período de interrupción primero). No desea que los usuarios intenten ingresar datos mientras esto sucede.

Cuestiones relacionadas