Diseñar particiones para administrar subconjuntos de datos

Artículo
12/15/2008

Si crea particiones de una tabla o un índice, puede mover subconjuntos de datos de forma rápida y eficaz con la instrucción Transact-SQL ALTER TABLE...SWITCH de las maneras siguientes:

Puede agregar una tabla como partición a una tabla con particiones ya existente.
Puede cambiar una partición de una tabla con particiones a otra.
Puede quitar una partición para crear una sola tabla.

Estos escenarios pueden resultar útiles si desea agregar nuevos datos a una tabla con particiones y quitar datos antiguos de la misma tabla con particiones de forma regular. Esta operación puede implicar grandes o pequeñas cantidades de datos en diferentes escenarios. Si los nuevos datos que agrega deben cargarse, limpiarse o transformarse, se pueden tratar como una entidad independiente antes de agregarlos como una partición. Los datos antiguos se pueden archivar o guardar en el almacén. Independientemente del tamaño de la colección, la transferencia es rápida y eficaz ya que, a diferencia del caso de una instrucción INSERT INTO SELECT FROM, los datos no se mueven físicamente. Sólo cambian de una partición a otra los metadatos relativos a la ubicación del almacenamiento.

Ejemplo: AdventureWorks

En el escenario de particiones de la base de datos de ejemplo AdventureWorks, Adventure Works Cycles archiva sus datos antiguos de la tabla TransactionHistory en una tabla TransactionHistoryArchive; para ello, traslada las particiones de una tabla a otra. Esto se lleva a cabo mediante la creación de particiones de TransactionHistory en el campo TransactionDate. El intervalo de valores de cada partición es un mes. La tabla TransactionHistory conserva las transacciones actuales del año y TransactionHistoryArchive guarda las transacciones anteriores. Al crear las particiones de las tablas de esta forma, los datos antiguos del año correspondientes a un mes se pueden transferir mensualmente de TransactionHistory a TransactionHistoryArchive.

Al comenzar cada mes, los datos del mes más lejano incluidos en la tabla TransactionHistory pasan a la tabla TransactionHistoryArchive. Para realizar esta tarea, se produce el siguiente proceso:

La tabla TransactionHistoryArchive debe contar con el mismo esquema de diseño que la tabla TransactionHistory. También debe existir una partición vacía para recibir los nuevos datos. En este caso, TransactionHistoryArchive es una tabla con particiones que consta de dos particiones. Una incluye los datos anteriores a septiembre de 2003 y otra los datos de septiembre de 2003 en adelante. Esta última partición está vacía.
La función de partición de la tabla TransactionHistoryArchive se modifica para dividir esta partición vacía en dos; una de ellas definida para recibir la nueva partición de los datos de septiembre de 2003.
La primera partición de la tabla TransactionHistory, que contiene los datos creados durante septiembre de 2003, pasa a la segunda partición de la tabla TransactionHistoryArchive. Tenga en cuenta que debe definir una restricción CHECK en la tabla TransactionHistory para especificar que no se incluyan datos anteriores al 1 de septiembre (TransactionDate >= '9/01/2003'). Esta restricción garantiza que la partición 1 sólo contiene datos de septiembre de 2003 y que está lista para pasar a la partición de la tabla TransactionHistoryArchive que incluye estos datos. Tenga en cuenta también que los índices que no estén alineados con sus tablas correspondientes deben quitarse o deshabilitarse antes del cambio. Sin embargo, se pueden volver a crear después. Para obtener más información sobre la alineación de índices con particiones, vea Directrices especiales para índices con particiones.
La función de partición de la tabla TransactionHistory se modifica para mezclar sus dos primeras particiones en una única partición. Esta partición, ahora la partición 1, contiene los datos creados en octubre de 2003 y estará lista para pasar a TransactionHistoryArchive el próximo mes, siempre que se modifique la restricción CHECK existente para especificar que no se incluyan datos anteriores al 1 de octubre (TransactionDate >= '10/01/2003').
La función de partición de la tabla TransactionHistoryArchive se modifica de nuevo para mezclar la segunda partición, que contiene los datos de septiembre que se acaban de agregar, con la primera partición. Esta acción recupera la condición original de la tabla TransactionHistoryArchive, es decir, la primera partición incluye todos los datos y la segunda está vacía.
La función de partición de la tabla TransactionHistory se modifica de nuevo para dividir la última partición en dos particiones, de forma que el mes actual se separa del mes anterior y la partición queda lista para recibir nuevos datos.