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

Aplica-se a: SQL Server 2016 (13.x) e versões posteriores Banco de Dados SQL do AzureInstância Gerenciada de SQL do AzureSQL database in Microsoft Fabric

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

  • Uma tabela temporal deve ter uma chave primária definida para correlacionar os registros 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 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 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 predicados de período diretamente na consulta.

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

  • Por padrão, a tabela de histórico fica PAGE compactada.

  • Se a tabela atual for particionada, a tabela de histórico é criada no grupo de arquivos padrão porque a configuração de particionamento 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 e, 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 blobs, como (n)varchar(max), varbinary(max), (n)text e image, elas gerarão custos significativos de armazenamento e terão implicações de desempenho devido a seu tamanho. Ao projetar seu sistema, tenha cuidado ao usar esses tipos de dados.

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

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

  • Exibições indexadas não têm suporte em 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 em uma tabela temporal versionada pelo sistema. A coluna ALTER não é executada como uma operação online, independentemente de qual valor 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 tem suporte enquanto SYSTEM_VERSIONING é ON.

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

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

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

    • Grupos de disponibilidade: Totalmente suportados

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

    • Instantâneo e replicação transacional: com suporte apenas para um único editor sem o temporal habilitado e um assinante com o temporal habilitado. Não há suporte ao uso de vários assinantes devido a uma dependência do relógio do sistema local, o que poderia levar a dados temporais inconsistentes. Neste caso, o publicador é usado para uma carga de trabalho de processamento de transações online (OLTP), enquanto o assinante serve para descarregar a geração de relatórios (incluindo consultas AS OF). Quando o agente de distribuição inicia, ele abre uma transação que permanece aberta até que o agente de distribuição pare. ValidFrom e ValidTo são preenchidos até o início da primeira transação iniciada pelo agente de distribuição. Talvez seja preferível executar o agente de distribuição conforme uma agenda, em vez de usar o comportamento padrão de executá-lo continuamente, se ter ValidFrom e ValidTo preenchidos com um horário próximo ao horário atual do sistema for importante para seu aplicativo ou organização. Para saber mais, consulte Cenários de uso de tabela temporal.

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

  • As consultas comuns afetam somente os dados na tabela atual. Para consultar os dados na tabela de histórico, você deverá usar consultas temporais. Para obter mais informações, consulte Consultar dados em uma tabela temporal com versão controlada pelo sistema.

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

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

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

  • Você não pode configurar uma tabela de histórico como a tabela atual em uma cadeia de tabelas de histórico.

Note

A documentação usa o termo árvore B geralmente em referência a índices. Em índices de rowstore, o Mecanismo de Banco de Dados implementa uma árvore B+. Isso não se aplica a índices columnstore nem a índices em tabelas otimizadas para memória. Para obter mais informações, confira o Guia de arquitetura e design do índice do SQL Server e SQL do Azure.

Conteúdo relacionado

  • Last updated on