Consideraciones y limitaciones de las tablas temporales

Aplica a: SQL Server 2016 (13.x) y versiones posteriores Azure SQL DatabaseAzure SQL Managed InstanceBase de datos SQL en Microsoft Fabric

Cuando trabajes con tablas temporales, ten en cuenta las siguientes consideraciones y limitaciones debido a la naturaleza del versionado del sistema:

  • Una tabla temporal debe tener definida una clave primaria para correlacionar los registros entre la tabla actual y la tabla 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 se especifica el nombre de una tabla de historial durante la creación de la tabla de historial, debe especificar el esquema y el nombre de la tabla.

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

  • Si la tabla actual está particionada, la tabla de historial se crea en el grupo de archivos predeterminado porque la configuración de partición no se replica automáticamente de la tabla actual a la tabla 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. Cuando diseñes tu sistema, ten 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 sobre consultas temporales (consultas que utilizan 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 sentencias INSERT y UPDATE no pueden hacer referencia a las columnas de período 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.

  • Para evitar invalidar la lógica del lenguaje de manipulación de datos (DML), no se permiten desencadenadores INSTEAD OF ni en la tabla actual ni en la tabla de histórico. 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 soportados

    • Captura y seguimiento de datos de cambios: soportado solo 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 utiliza para una carga de trabajo de procesamiento de transacciones en línea (OLTP), mientras que el suscriptor se usa para descargar la generación de informes, incluidas las consultas AS OF. Cuando el agente de distribución inicia, abre una transacción que permanece abierta hasta que el agente de distribución se detiene. ValidFrom y ValidTo se rellenan con la hora de inicio de la primera transacción que 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 fusión: No soportada para 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, consulte Consultar datos en una tabla temporal con control de versiones del sistema.

  • Una estrategia de indexación óptima incluye un índice clúster de almacén de columnas o un índice de almacén de filas de árbol B en la tabla actual, y un índice clúster de almacén de columnas en la tabla histórica, para optimizar el tamaño de almacenamiento y el rendimiento. Si creas o usas tu propia tabla de historiales, crea este tipo de índice compuesto por columnas de periodo que comienzan por la columna de fin de periodo. Este índice acelera las consultas temporales y las consultas que forman parte de la comprobación de consistencia de datos. La tabla de historial predeterminada crea un índice clusterizado de rowstore basado en las columnas de periodo (fin, inicio). Como mínimo, utiliza un índice de rowstore 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 período
    • Definición de identidad
    • Indexes
    • Statistics
    • Restricciones de verificación
    • Desencadenadores
    • Configuración de particiones
    • Permissions
    • Predicados de seguridad a nivel de fila

  • No puedes configurar una tabla de historial como la tabla actual en una cadena de tablas de historial.

Note

La documentación utiliza el término árbol B generalmente en referencia a los índices. En los índices rowstore, el Motor de 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

  • Last updated on