Transferir datos de forma eficaz con cambios de particiones

Actualizado: 12 de diciembre de 2006

Puede utilizar la instrucción ALTER TABLE...SWITCH de Transact-SQL para transferir bloques de datos rápida y eficazmente de las maneras siguientes:

• Puede asignar una tabla como partición a una tabla con particiones existente.
• Puede cambiar una partición de una tabla con particiones a otra.
• Puede volver a asignar una partición para crear una sola tabla.

Para obtener información acerca de los conceptos de cambio de particiones, vea Diseñar particiones para administrar subconjuntos de datos. Para ver el código de ejemplo que implementa el cambio de particiones, vea Readme_SlidingWindow.

Requisitos generales para cambiar particiones

Cuando se transfiere una partición, los datos no se mueven físicamente. En realidad, sólo se cambian los metadatos acerca del almacenamiento de los datos. Esto significa que tanto la tabla de la que procede la partición (tabla de origen) como la tabla que la recibe (tabla de destino) deben existir en la base de datos antes de que realice la operación SWITCH.

Si agrega una tabla como una partición a una tabla con particiones ya existente o si mueve una partición de una tabla con particiones a otra, la partición de destino debe existir y estar vacía.

Si vuelve a asignar una partición para crear una tabla sin particiones, la tabla que recibe la partición debe estar creada y vacía.

Si cambia una partición de una tabla con particiones a otra, ambas tablas deben tener las particiones en la misma columna.

Tanto el origen como el destino de la instrucción ALTER TABLE...SWITCH deben encontrarse en el mismo grupo de archivos y sus columnas de valores grandes deben estar almacenadas en el mismo grupo de archivos. Los índices o particiones de índice correspondientes también deben encontrarse en el mismo grupo de archivos. Sin embargo, el grupo de archivos puede ser diferente del grupo de las tablas o los demás índices correspondientes.

Requisitos de la estructura de tablas e índices

Tanto la tabla de origen como la de destino deben utilizar la misma estructura. Esto significa lo siguiente:

• Las tablas deben tener las mismas columnas, con los mismos nombres y las mismas restricciones de tipo de datos, longitud, intercalación, precisión, escala, aceptación de valores NULL y PRIMARY KEY, así como la misma configuración en ANSI_NULLS y QUOTED IDENTIFIER. Además, las columnas deben estar definidas en el mismo orden. La propiedad IDENTITY no se tiene en cuenta.

  Advertencia:
  Si se lleva a cabo un cambio de particiones, es posible que se generen valores duplicados en las columnas IDENTITY de la tabla de destino y espacios en los valores de las columnas IDENTITY de la tabla de origen. Utilice DBCC CHECKIDENT para comprobar los valores de la identidad de las tablas y corregir los valores si así lo desea.

• La capacidad de aceptar valores NULL de las columnas de partición debe coincidir. Es decir, ambas deben ser NULL o NOT NULL. Si una de las tablas no tiene particiones, la aceptación de valores NULL de la columna correspondiente a la columna de partición de la otra tabla debe estar de acuerdo con dicha columna de partición.

  Importante:

  Se recomienda utilizar NOT NULL en la columna de partición de las tablas con particiones y también de las tablas sin particiones que son orígenes o destinos para operaciones ALTER TABLE...SWITCH. De esta forma, se asegura de que cualquier restricción CHECK en las columnas con particiones no deba comprobar los valores nulos. Los valores nulos se colocan normalmente en la partición situada más a la izquierda de una tabla con particiones. Cuando se cambia cualquier partición que no es la situada más a la izquierda y cuando la opción de base de datos ANSI_NULLS está establecida en ON, la ausencia de la restricción NOT NULL en las tablas de origen y de destino puede interferir con cualquier restricción CHECK que también esté definida en la columna de partición.

• Si las claves de partición correspondientes son columnas calculadas, la sintaxis de las expresiones que definen las columnas calculadas debe ser la misma y ambas columnas calculadas deben ser persistentes.
• Una columna definida con la propiedad ROWGUID debe corresponderse con una columna de la otra tabla, definida también con la propiedad ROWGUID.
• Las columnas xml deben estar escritas en la misma colección de esquemas XML.
• La configuración de la característica consecutiva de las columnas text, ntext o image debe ser la misma. Para obtener más información acerca de esta configuración, vea Datos consecutivos.
• Las tablas deben tener los mismos índices agrupados. Estos índices no pueden estar deshabilitados.
• Los índices no agrupados definidos en la tabla de destino también deben estar definidos en la tabla de origen y tener una estructura idéntica en términos de unicidad, subclaves y dirección de ordenación (ASC o DESC) en cada columna de clave de índice. Los índices no agrupados que están deshabilitados no necesitan satisfacer este requisito.

Requisitos de restricciones

Las restricciones CHECK definidas en la tabla de destino también deben estar definidas en la tabla de origen ya sea como una coincidencia exacta, o bien como una correspondencia de la restricción CHECK de la tabla de destino.

Por ejemplo, si la tabla de destino tiene una restricción en una columna Column1 de tipo int que especifica Column1 < 100, la columna Column1 correspondiente de la tabla de origen debe contar con la misma restricción, o bien con una restricción cuyos valores sean un subconjunto de la restricción de la tabla de destino, como Column1 < 90. Las restricciones CHECK que especifican varias columnas deben estar definidas con la misma sintaxis.

Si agrega una tabla sin particiones como partición a una tabla con particiones ya existente, debe haber una restricción definida en la columna de la tabla de origen correspondiente a la clave de partición de la tabla de destino. Así se garantiza que el intervalo de valores se ajusta a los valores de límite de la partición de destino.

Si cambia una partición de una tabla con particiones a otra tabla con particiones, los valores de límite de la partición de origen deben ajustarse a los valores de límite de la partición de destino. Si no se ajustan, debe definirse una restricción en la clave de partición de la tabla de origen para garantizar que todos los datos de la tabla se ajustan a los valores de límite de la partición de destino.

Advertencia:
Evite la conversión de tipos de datos en las definiciones de las restricciones. Las restricciones que incluyen una conversión implícita o explícita de tipos de datos y están definidas en las tablas de origen del cambio de particiones pueden provocar el error de ALTER TABLE...SWITCH.

Si la tabla de destino cuenta con restricciones FOREIGN KEY, la tabla de origen debe tener las mismas claves externas definidas en las columnas correspondientes; además, estas claves externas deben hacer referencia a la misma clave principal que las de la tabla de destino. Las claves externas de la tabla de origen no pueden estar marcadas como is_not_trusted (se puede ver en la vista de catálogo sys.foreign_keys), a menos que la clave externa correspondiente de la tabla de destino también esté marcada como is_not_trusted. Para obtener más información acerca de esta configuración, vea Directrices para deshabilitar índices. SQL Server aplica las reglas CASCADE definidas en las claves externas de la tabla de destino a la nueva partición desplazada.

Requisitos adicionales para mover particiones

Para mover particiones también deben cumplirse los siguientes requisitos adicionales:

• Los índices de la tabla de origen o de la tabla de destino deben estar alineados con la tabla, tanto si una o ambas tienen particiones.

• No pueden existir índices de texto en la tabla de origen ni en la de destino.

• La tabla de destino no puede contener índices XML.

• Si la tabla de origen incluye la clave principal, no puede existir una relación activa clave principal/clave externa entre la tabla de origen y la de destino.

• Si la tabla de destino incluye la clave externa, no puede existir una relación activa clave principal/clave externa entre la tabla de origen y la de destino.

• Una clave externa de otra tabla no puede hacer referencia a la tabla de origen.

• La tabla de origen y la de destino no pueden participar en una vista con enlaces de esquema. Por tanto, en ellas no se pueden definir vistas indizadas.

• No pueden existir reglas definidas en la tabla de origen ni en la de destino.

  [!NOTA] Las reglas son una característica de compatibilidad con versiones anteriores. La implementación preferida es utilizar restricciones CHECK. Para conocer las limitaciones de CHECK, vea Requisitos de restricciones anteriormente en este tema.

• La tabla de origen y la tabla de destino no puede ser orígenes de una réplica.

• Un cambio de particiones supone la ejecución de una instrucción ALTER TABLE. Por tanto, debe disponer de los permisos de base de datos necesarios asociados con la instrucción ALTER TABLE. El conjunto de permisos no tiene que ser el mismo entre las tablas de origen y de destino.

Cuando se mueven particiones de tabla, no se activan desencadenadores INSERT, UPDATE o DELETE ni acciones en cascada, por lo que no es necesario que las tablas de origen o de destino cuenten con desencadenadores definidos de forma similar.

[!NOTA] Cuando se lleva a cabo una operación ALTER TABLE…SWITCH, se obtiene un bloqueo de modificación de esquema en las tablas de origen y de destino para garantizar que ninguna otra conexión haga referencia ni siquiera a los metadatos de las tablas durante el cambio. Para obtener más información acerca de los bloqueos, vea Modos de bloqueo.

Para mover particiones de tabla

• ALTER TABLE (Transact-SQL)

Vea también

Conceptos

Diseñar particiones para administrar subconjuntos de datos

Otros recursos

DBCC CHECKIDENT (Transact-SQL)
ALTER PARTITION FUNCTION (Transact-SQL)
ALTER PARTITION SCHEME (Transact-SQL)
Readme_SlidingWindow

Ayuda e información

Obtener ayuda sobre SQL Server 2005

Historial de cambios