Consideraciones y limitaciones de las tablas temporales

  • Artículo

Se aplica a: SQL Server 2016 (13.x) y versiones posteriores Azure SQL Database Azure SQL Managed Instance

Hay algunas consideraciones y limitaciones que se deben tener en cuenta al trabajar con tablas temporales debido a la naturaleza del control de versiones del sistema:

  • Una tabla temporal debe tener una clave principal definida para poner en correlación los registros entre la tabla actual y la de historial. La tabla de historial no puede tener definida una clave principal.

  • Las columnas de periodo SYSTEM_TIME que se usan para registrar los valores ValidFrom y ValidTo deben definirse con el tipo de datos datetime2.

  • La sintaxis temporal funciona en tablas o vistas que se almacenan localmente en la base de datos. Con objetos remotos, como tablas en un servidor vinculado o tablas externas, no se pueden usar la cláusula FOR ni predicados de periodo directamente en la consulta.

  • Si el nombre de una tabla de historial se especifica durante su creación, debe determinar el nombre del esquema y la tabla.

  • De forma predeterminada, es la tabla de historial PAGE es comprimida.

  • Si la tabla actual tiene particiones, la tabla de historial se crea en el grupo de archivos predeterminado, ya que la configuración de particiones no se replica automáticamente desde la tabla actual a la de historial.

  • Las tablas temporales y de historial no pueden usar FileTable ni FILESTREAM. FileTable y FILESTREAM permiten la manipulación de datos fuera de SQL Server y, por tanto, no se puede garantizar el control de versiones del sistema.

  • Un nodo o una tabla perimetral no se puede crear o modificar como una tabla temporal.

  • Aunque las tablas temporales son compatibles con los tipos de datos BLOB, como (n)varchar(max), varbinary(max), (n)text e image, suponen importantes costos de almacenamiento y afectan al rendimiento debido a su tamaño. Por lo tanto, al diseñar el sistema, debe tener cuidado al usar estos tipos de datos.

  • La tabla de historial debe crearse en la misma base de datos que donde reside la actual. No se admiten consultas temporales a través de servidores vinculados.

  • La tabla de historial no puede tener restricciones (de clave principal, clave externa, tabla o columna).

  • No se admiten vistas indexadas con consultas temporales (las consultas que usan la cláusula FOR SYSTEM_TIME).

  • La opción en línea (WITH (ONLINE = ON) no tiene ningún efecto sobre ALTER TABLE ALTER COLUMN en las tablas temporales con control de versiones del sistema. La columna ALTER no se ejecuta como una operación en línea, independientemente del valor que se haya especificado para la opción ONLINE.

  • Las instruccionesINSERT y UPDATE no pueden hacer referencia a las columnas de periodo SYSTEM_TIME. Se bloquean los intentos de insertar valores directamente en estas columnas.

  • TRUNCATE TABLE no se admite cuando SYSTEM_VERSIONING es ON.

  • No se permite la modificación directa de los datos en una tabla de historial.

  • ON DELETE CASCADE y ON UPDATE CASCADE no se permiten en la tabla actual. Dicho de otro modo, cuando la tabla temporal hace referencia a una tabla de la relación de clave externa (correspondiente a parent_object_id en sys.foreign_key), no se permiten las opciones CASCADE. Para abordar esta limitación, utilice la lógica de aplicación o los desencadenadores AFTER para mantener la coherencia de eliminación en la tabla de clave principal (correspondiente a referenced_object_id en sys.foreign_key). Si la tabla de clave principal es temporal y la de referencia no lo es, significa que no hay ninguna limitación de este tipo.

  • Los desencadenadores INSTEAD OF no se permiten en la tabla actual o de historial para evitar que se invalide la lógica de DML. Los desencadenadores AFTER solo se permiten en la tabla actual. Estos desencadenadores se bloquean en la tabla de historial para evitar que se invalide la lógica de DML.

  • El uso de tecnologías de replicación está limitado:

    • Grupos de disponibilidad: totalmente admitidos.

    • Captura de datos modificados y seguimiento de cambios: solo se admiten en la tabla actual.

    • Replicación transaccional y de instantáneas: solo es compatible con un publicador único sin la función de temporalidad habilitada, y con un suscriptor que tenga dicha función habilitada. No se admite el uso de varios suscriptores debido a una dependencia del reloj del sistema local, que puede provocar que los datos temporales sean incoherentes. En este caso, el publicador se usa para una carga de trabajo OLTP, mientras que el suscriptor sirve para la descarga de informes (incluidas las consultas AS OF). Cuando se inicia el agente de distribución, este abre una transacción que se mantiene abierta hasta que se detiene el agente de distribución. ValidFrom y ValidTo se rellenan con la hora de inicio de la primera transacción en la que se inicia el agente de distribución. Puede ser preferible ejecutar el agente de distribución según una programación en lugar de seguir el comportamiento predeterminado de ejecutarlo continuamente, si rellenar ValidFrom y ValidTo con una hora cercana a la hora actual del sistema es importante para la aplicación o la organización. Para obtener más información, consulte Escenarios de uso de tablas temporales.

    • Replicación de mezcla: no es compatible con las tablas temporales.

  • Las consultas normales solo afectan a los datos de la tabla actual. Para consultar los datos en la tabla de historial, debe usar consultas temporales. Para más información, vea Consulta de los datos de una tabla temporal con control de versiones del sistema.

  • Una estrategia de indexación óptima consiste en incluir un índice de almacén de columnas agrupado o un índice de almacén de filas de árbol B en la tabla actual, y un índice de almacén de columnas agrupado en la tabla de historial para que el rendimiento y el tamaño de almacenamiento sean óptimos. Si crea o usa una tabla de historial propia, se recomienda encarecidamente crear este tipo de índice que consta de columnas de periodo empezando por el fin de la columna de periodo. Este índice acelera las consultas temporales y las que forman parte de la comprobación de coherencia de datos. La tabla de historial predeterminada cuenta con un índice de almacén de filas agrupado que se ha creado en función de las columnas de periodo (fin e inicio). Como mínimo, se recomienda un índice de almacén de filas no agrupado.

  • Los objetos o las propiedades siguientes no se replican desde la tabla actual en la de historial cuando se crea la tabla de historial:

    • Definición de periodo
    • Definición de identidad
    • Índices
    • Estadísticas
    • Restricciones CHECK
    • Desencadenadores
    • Configuración de partición
    • Permisos
    • Predicados de seguridad de nivel de fila

  • Una tabla de historial no se puede configurar como actual en una cadena de tablas de historial.

Nota:

La documentación utiliza el término árbol B generalmente en referencia a los índices. En los índices del almacén de filas, el motor de la base de datos implementa un árbol B+. Esto no se aplica a los índices de almacén de columnas ni a los índices de tablas optimizadas para memoria. Para obtener más información, consulte la guía de diseño y arquitectura de índices de SQL Server y Azure SQL.

Contenido relacionado