Partilhar via

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 SQL do Azurebanco de dados SQL no Microsoft Fabric

Existem algumas considerações e limitações a ter em conta ao trabalhar com tabelas temporais, devido à natureza do versionamento do sistema:

  • Uma tabela temporal deve ter uma chave primária definida, a fim de correlacionar 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 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 for particionada, a tabela de histórico será criada no grupo de arquivos padrão porque a configuração de particionamento não será 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. Como tal, ao projetar seu sistema, deve-se ter cuidado ao usar esses 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.

  • ON DELETE CASCADE e ON UPDATE CASCADE não são permitidos na tabela atual. Em outras palavras, quando a tabela temporal está a referenciar a tabela na relação de chave estrangeira (correspondente a parent_object_id em sys.foreign_key) opções CASCADE não são permitidas. Para contornar essa limitação, use a lógica do aplicativo ou após gatilhos para manter a consistência na exclusão na tabela de chave primária (correspondente a referenced_object_id no sys.foreign_key). Se a tabela de chave primária for temporal e a tabela de referência for não temporal, não haverá essa limitação.

  • Gatilhos "INSTEAD OF" não são permitidos nem na tabela atual nem na tabela de histórico para evitar invalidar a lógica de DML. 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 suportado

    • Captura de dados de alteração e rastreio 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. Nesse caso, o publicador é usado para uma carga de trabalho OLTP, enquanto o assinante é responsável por descarregar relatórios (incluindo consultas AS OF). Quando o agente de distribuição é iniciado, ele abre uma transação que é mantida aberta até que o agente de distribuição pare. ValidFrom e ValidTo são preenchidos até a 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 mesclagem: Não suportado 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 clusterizado de armazenamento de colunas e/ou um índice rowstore em forma de árvore B na tabela atual, além de um índice clusterizado de armazenamento de colunas na tabela de histórico, para um tamanho e desempenho de armazenamento ideais. Se você criar/usar sua própria tabela de histórico, é altamente recomendável criar esse tipo de índice que consiste em colunas de período começando com a coluna de fim de período. Esse índice acelera a consulta temporal e acelera as consultas que fazem parte da verificação de consistência de dados. A tabela de histórico padrão tem um índice de armazenamento de linhas clusterizado criado para você com base nas colunas de período (fim, início). No mínimo, recomenda-se um índice de armazenamento em linha 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
    • Índices
    • Estatística
    • Verificar restrições
    • Gatilhos
    • Configuração de particionamento
    • Permissões
    • Predicados de segurança em nível de linha

  • Uma tabela de histórico não pode ser configurada como tabela atual em uma cadeia de tabelas de histórico.

Observação

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

Conteúdo relacionado