Considerações e limitações da tabela temporal

Aplica-se a: SQL Server 2016 (13.x) e versões posteriores Base de Dados SQL do Azure Azure SQL Managed InstanceBase de dados SQL no Microsoft Fabric

Ao trabalhar com tabelas temporais, esteja ciente das seguintes considerações e limitações devido à natureza da versionação do sistema:

  • Uma tabela temporal deve ter uma chave primária definida, para correlacionar os registos entre a tabela atual e a tabela de histórico. A tabela de histórico não pode ter uma chave primária definida.

  • As colunas de período de SYSTEM_TIME usadas para registrar os valores ValidFrom e ValidTo devem ser definidas com um tipo de dados de datetime2.

  • A sintaxe temporal funciona em tabelas ou exibições que são armazenadas localmente no banco de dados. Com objetos remotos, como tabelas em um servidor vinculado ou tabelas externas, você não pode usar a cláusula FOR ou os predicados de ponto diretamente na consulta.

  • Se o nome de uma tabela de histórico for especificado durante a criação da tabela de histórico, você deverá especificar o esquema e o nome da tabela.

  • Por padrão, a tabela de histórico é comprimida em PAGE.

  • Se a tabela atual estiver particionada, a tabela de histórico é criada no grupo de ficheiros predefinido porque a configuração de partição não é replicada automaticamente da tabela atual para a tabela de histórico.

  • As tabelas temporais e de histórico não podem usar FileTable ou FILESTREAM. FileTable e FILESTREAM permitem a manipulação de dados fora do SQL Server, portanto, o controle de versão do sistema não pode ser garantido.

  • Uma tabela de nó ou borda não pode ser criada como ou alterada para uma tabela temporal.

  • Embora as tabelas temporais ofereçam suporte a tipos de dados de blob, como (n)varchar(max), varbinary(max), (n)texte image, elas incorrem em custos de armazenamento significativos e têm implicações de desempenho devido ao seu tamanho. Ao desenhar o seu sistema, tenha cuidado ao usar estes tipos de dados.

  • A tabela de histórico deve ser criada no mesmo banco de dados que a tabela atual. Não há suporte para consultas temporais em servidores vinculados.

  • A tabela de histórico não pode ter restrições (chave primária, chave estrangeira, tabela ou restrições de coluna).

  • Não há suporte para visões indexadas em cima de consultas temporais (consultas que usam a cláusula FOR SYSTEM_TIME).

  • A opção online (WITH (ONLINE = ON) não tem efeito sobre ALTER TABLE ALTER COLUMN numa tabela temporal versionada pelo sistema. A coluna ALTER não é realizada como uma operação online, independentemente do valor que foi especificado para a opção ONLINE.

  • As instruções INSERT e UPDATE não podem fazer referência às colunas de período SYSTEM_TIME. As tentativas de inserir valores diretamente nessas colunas são bloqueadas.

  • TRUNCATE TABLE não é suportado enquanto que SYSTEM_VERSIONING é ON.

  • A modificação direta dos dados em uma tabela de histórico não é permitida.

  • Para evitar invalidar a lógica da linguagem de manipulação de dados (DML), INSTEAD OF os gatilhos não são permitidos nem na tabela atual nem na tabela de histórico. AFTER gatilhos são permitidos apenas na tabela atual. Esses gatilhos são bloqueados na tabela de histórico para evitar invalidar a lógica DML.

  • O uso de tecnologias de replicação é limitado:

    • Grupos de disponibilidade: Totalmente suportados

    • Captura de dados de alterações e acompanhamento de alterações: Suportado apenas na tabela atual

    • Snapshot e replicação transacional: suportado apenas para um único editor sem habilitação de temporalidade e um assinante com temporalidade habilitada. O uso de vários assinantes não é suportado devido a uma dependência do relógio do sistema local, o que pode levar a dados temporais inconsistentes. Neste caso, o publicador é utilizado para uma carga de trabalho de processamento de transações em linha (OLTP), enquanto o subscritor serve para descarregar a geração de relatórios (incluindo consultas AS OF). Quando o agente de distribuição começa, abre uma transação que permanece aberta até o agente de distribuição parar. ValidFrom e ValidTo são preenchidos até à hora de início da primeira transação iniciada pelo agente de distribuição. Pode ser preferível executar o agente de distribuição em um cronograma em vez do comportamento padrão de executá-lo continuamente, se ter ValidFrom e ValidTo preenchidos com um tempo próximo ao horário atual do sistema for importante para seu aplicativo ou organização. Para obter mais informações, consulte Cenários de uso da tabela temporal.

    • Replicação de fusão: Não suportada para tabelas temporais

  • As consultas regulares afetam apenas os dados na tabela atual. Para consultar dados na tabela de histórico, você deve usar consultas temporais. Para obter mais informações, consulte Consultar dados numa tabela temporal com versão do sistema.

  • Uma estratégia de indexação ideal inclui um índice columnstore agrupado ou um índice rowstore de árvore B na tabela corrente, e um índice columnstore agrupado na tabela de histórico, para otimizar o espaço de armazenamento e o desempenho. Se criar ou usar a sua própria tabela de histórico, crie este tipo de índice composto por colunas de período que começam pela coluna de fim de período. Este índice acelera as consultas temporais e as consultas que fazem parte da verificação de consistência dos dados. A tabela de histórico predefinida cria um índice rowstore agrupado com base nas colunas de período (fim, início). No mínimo, use um índice de rowstore não clusterizado.

  • Os seguintes objetos/propriedades não são replicados da tabela atual para a tabela de histórico quando a tabela de histórico é criada:

    • Definição do período
    • Definição de identidade
    • Indexes
    • Estatísticas
    • Verificar restrições
    • Triggers
    • Configuração de particionamento
    • Permissions
    • Predicados de segurança em nível de linha

  • Não podes configurar uma tabela de histórico como a tabela atual numa cadeia de tabelas de histórico.

Note

A documentação usa o termo árvore B geralmente em referência a índices. Em índices de armazenamento em linha, o Mecanismo de Base de Dados implementa uma árvore B+. Isso não se aplica a índices de armazenamento em colunas ou a índices em tabelas com otimização de memória. Para mais informações, consulte o guia de arquitetura e estrutura de índices do SQL Server e do SQL do Azure.

Conteúdo relacionado

  • Last updated on