Compartilhar via

Considerações e limitações do registro contábil

Aplica-se a: SQL Server 2022 (16.x) e versões posteriores Banco de Dados SQL do AzureInstância Gerenciada do SQL do Azure

Há algumas considerações e limitações a serem levadas em conta ao trabalhar com tabelas de ledger, devido à natureza do versionamento do sistema e dos dados imutáveis.

Considerações e limitações gerais

Considere as informações abaixo ao trabalhar com o razão.

Considerações e limitações sobre a tabela do razão contábil

  • As tabelas existentes em um banco de dados que não são tabelas de razão não podem ser convertidas em tabelas de razão. Para obter mais informações, confira Migrar dados de tabelas regulares para tabelas de razão.
  • Depois que uma tabela de livro-razão é criada, ela não pode ser revertida para uma tabela que não seja de livro-razão.
  • Não há suporte para a exclusão de dados mais antigos em tabelas de livro-razão somente de apêndice ou na tabela de histórico em tabelas de livro-razão atualizáveis.
  • Não há suporte para TRUNCATE TABLE.
  • Quando uma tabela de ledger atualizável é criada, quatro colunas GENERATED ALWAYS são adicionadas a ela. Uma tabela do razão somente de anexação tem duas colunas adicionadas nela. Essas novas colunas contam para o número máximo de colunas com suporte no Banco de Dados SQL do Azure (1.024).
  • Não há suporte para tabelas na memória.
  • Não há suporte para conjuntos de colunas esparsas.
  • Não há suporte para a partição SWITCH IN/OUT.
  • DBCC CLONEDATABASE não é suportado.
  • Elas não podem ter índices de texto completo.
  • As tabelas do livro razão não podem ser uma tabela de grafos.
  • As tabelas de contabilidade não podem ser FileTables.
  • As tabelas de ledger não podem ter um índice rowstore não-clusterizado quando têm um índice columnstore clusterizado.
  • O controle de alterações não é permitido na tabela de histórico, mas é permitido nas tabelas do razão.
  • A captura de dados de alterações não é permitida na tabela de histórico, mas é permitida nas tabelas do razão.
  • A replicação transacional não tem suporte para tabelas de ledger.
  • Não há suporte para espelhamento de banco de dados.
  • A Ligação Azure Synapse é suportada, mas apenas para a tabela ledger, não para a tabela de histórico.
  • Altere o caminho de resumo manualmente após a restauração nativa de um backup de banco de dados para uma Instância Gerenciada de SQL do Azure.
  • Altere o caminho de digestão manualmente após a criação de um link para uma Instância Gerenciada SQL do Azure.
  • A Sincronização de Dados SQL não é compatível com tabelas de razão contábil.

Tipos de dados sem suporte

  • XML
  • SqlVariant
  • Tipo de dados definido pelo usuário
  • FILESTREAM
  • Vetor

Limitações das tabelas temporais

Tabelas de registro atualizáveis são baseadas na tecnologia de tabelas temporais e herdam a maioria das limitações, mas não todas. A lista a seguir descreve as limitações herdadas de tabelas temporais.

  • 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, além do nome da exibição do razão.
  • Por padrão, a tabela de histórico é PAGE compactada.
  • Se a tabela atual estiver particionada, a tabela de histórico será criada no grupo de arquivo 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 poderão ser FILETABLE e poderão conter colunas de qualquer tipo de dados compatível que não seja 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. O Graph não tem suporte no ledger.
  • Embora as tabelas temporais deem suporte a tipos de dados de blobs, como (n)varchar(max), varbinary(max), (n)text e image, elas incorrerão em custos significativos de armazenamento e terão implicações de desempenho devido a seu tamanho. Assim, ao criar seu sistema, tome cuidado ao usar esses tipos de dados.
  • A tabela de histórico deve ser criada no mesmo banco de dados da tabela atual. O servidor vinculado não suporta consultas temporais.
  • A tabela de histórico não pode ter restrições (chave primária, chave estrangeira, tabela ou coluna).
  • A opção online (WITH (ONLINE = ON) não tem nenhum efeito em ALTER TABLE ALTER COLUMN no caso de tabela temporal versionada pelo sistema. ALTER COLUMN não é executada online, independentemente de qual valor tenha sido especificado para a opção ONLINE.
  • As instruções INSERT e UPDATE não podem fazer referência às colunas GENERATED ALWAYS. As tentativas de inserir valores diretamente nessas colunas são bloqueadas.
  • UPDATETEXT e WRITETEXT não são suportados.
  • Não são permitidos gatilhos na tabela de histórico.
  • O uso de tecnologias de replicação é limitado:
    • Sempre ativo: com suporte total
    • Instantâneo, mesclagem e replicação transacional: não há suporte para tabelas temporais
  • Uma tabela de histórico não pode ser configurada como tabela atual em uma cadeia de tabelas de histórico.
  • Os seguintes objetos ou propriedades não serão replicados da tabela atual para a tabela de histórico quando esta for criada:
    • Definição de período
    • Definição de identidade
    • Índices
    • Estatísticas
    • Verificar restrições
    • Gatilhos
    • Configuração de particionamento
    • Permissões
    • Predicados de segurança em nível de linha

Considerações sobre mudanças no esquema

Adicionar colunas

Há suporte para adicionar colunas anuláveis. Não há suporte para a adição de colunas não anuláveis. Ledger foi projetado para ignorar valores NULL ao calcular o hash de uma versão de linha. Com base nisso, quando uma coluna anulável é adicionada, o livro-razão modifica o esquema das tabelas do livro-razão e do histórico para incluir a nova coluna, porém, isso não afeta os hashes das linhas existentes. A adição de colunas em tabelas do razão contábil é registrada em sys.ledger_column_history.

Remoção de colunas e tabelas

Normalmente, a remoção de uma coluna ou tabela apaga completamente os dados subjacentes do banco de dados e é fundamentalmente incompatível com a funcionalidade do livro-razão, que exige que os dados sejam imutáveis. Em vez de excluir os dados, o livro-razão simplesmente renomeia os objetos ao serem removidos para que sejam logicamente removidos do esquema do usuário, mas continuem a existir fisicamente no banco de dados. Todas as colunas removidas também ficam ocultas no esquema da tabela de registros, ficando invisíveis para o aplicativo do usuário. No entanto, os dados desses objetos removidos permanecem disponíveis para o processo de verificação do livro-razão e permitem que os usuários inspecionem quaisquer dados históricos por meio das visões correspondentes do livro-razão. A exclusão de colunas em tabelas do razão geral é registrada em sys.ledger_column_history. A remoção de uma tabela de ledger é capturada em sys.ledger_table_history. As tabelas do livro razão removidas e seus objetos dependentes são marcados como removidos nas exibições do catálogo do sistema e renomeados.

  • As tabelas de ledger removidas são marcadas como removidas configurando is_dropped_ledger_table em sys.tables e são renomeadas com o seguinte formato: MSSQL_DroppedLedgerTable_<dropped_ledger_table_name>_<GUID>.
  • Tabelas de histórico descartadas para tabelas de ledger atualizáveis são renomeadas usando o seguinte formato: MSSQL_DroppedLedgerHistory_<dropped_history_table_name>_<GUID>.
  • As exibições do livro-razão removidas são marcadas como removidas ao serem configuradas em sys.views e renomeadas usando o seguinte formato: MSSQL_DroppedLedgerView_<dropped_ledger_view_name>_<GUID>.

Observação

O nome de tabelas contábeis descartadas, tabelas de histórico e exibições de razão pode ser truncado se o comprimento da tabela ou exibição renomeada exceder 128 caracteres.

Alterando colunas

Todas as alterações que não afetam os dados subjacentes de uma tabela do ledger são suportadas sem necessidade de tratamento especial, pois elas não afetam os hashes capturados no ledger. Essas alterações incluem:

  • Alteração de nulidade
  • Ordenação de cadeias de caracteres Unicode
  • O comprimento das colunas de comprimento variável

No entanto, não há suporte para operações que possam afetar o formato dos dados existentes, como a alteração do tipo de dados.

Conteúdo relacionado

  • Last updated on