Atualmente, os documentos da Microsoft fornecem um exemplo de como habilitar tabelas temporais em tabelas existentes em ALTER TABLE, exemplos de controle de versão do sistema: A. Adicionar controle de versão do sistema a tabelas existentes
Usando a sintaxe lá, mas especificando um padrão constante, tenho:
ALTER TABLE InsurancePolicy
ADD PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo),
ValidFrom datetime2 GENERATED ALWAYS AS ROW START HIDDEN NOT NULL
-- DEFAULT SYSUTCDATETIME(), /* default specified in the docs */
DEFAULT CONVERT(DATETIME2, '2023-08-14') /* use a constant default */
ValidTo datetime2 GENERATED ALWAYS AS ROW END HIDDEN NOT NULL
DEFAULT CONVERT(DATETIME2, '9999-12-31 23:59:59.99999999') ;
Quando executo esta instrução, posso observar um evento SP:StatementStartingcom TextData:SELECT [ValidFrom],[ValidTo] FROM [dbo].[InsurancePolicy]
Isso me diz que o SQL Server está olhando para esses dados (provavelmente para determinar que ValidTo e ValidFrom estão em conformidade com algumas restrições).
O bloqueio de modificação do esquema + a verificação da tabela está me incomodando.
Em teoria, a varredura é desnecessária porque os valores são constantes. Nos documentos da Microsoft, exemplo B, eles mencionam "(um certo conjunto de verificações de dados ocorre em segundo plano)" Mas talvez essas verificações sejam desnecessárias quando as colunas são novas. Então:
Existe alguma maneira de habilitar tabelas temporais online? Sem colocar um cadeado sch-m na mesa enquanto a mesa é digitalizada?
Não. As verificações são realizadas quando
PERIOD FOR SYSTEM_TIMEé adicionado, elas não podem ser evitadas, e a alteração do esquema é realizada sob umSch-Mbloqueio.Você teria que realizar uma migração gradual para novas tabelas manualmente ou implementar sua própria solução de rastreamento de histórico.
O recurso interno de tabelas temporais parece simples e conveniente, mas vem com falta de controle e flexibilidade, bem como alguns comportamentos indesejáveis, dependendo do uso pretendido.