GetDate na restrição padrão em algumas tabelas no SQL Server 2012

Question

Como você espera, eu tenho problemas com o GetDate na restrição padrão em algumas tabelas no SQL Server 2012.

Eu tenho duas mesas como abaixo (A e B):

CREATE TABLE [dbo].[TABLE_A_OR_B] (
[TABLE_A_OR_B_PK]   BIGINT          IDENTITY (1, 1) NOT NULL,
[CREATE_DATETIME]   DATETIME2 (7)   CONSTRAINT [DF_TABLE_A_OR_B_CREATE_DATETIME] DEFAULT (getdate()) NOT NULL,
[CREATE_USER]       VARCHAR (100)   CONSTRAINT [DF_TABLE_A_OR_B_CREATE_USER] DEFAULT (suser_sname()) NOT NULL,
...
CONSTRAINT [PK_TABLE_A_OR_B] PRIMARY KEY CLUSTERED ([TABLE_A_OR_B_PK] ASC)
);

E tenho procedimento em que estou fazendo duas inserções - primeiro para a tabela A e o segundo para B sem coluna create_dateTime. Entre eles está muitas coisas.

Agora adivinhe o que está na coluna create_dateTime nas tabelas A e B?

Duas vezes - talvez após 1 000 000 registros, nunca antes - existe na Tabela A DateTime maior que na Tabela B para registros da mesma execução do SP (verificada) como:

row in A: 2013-11-07 00:02:22.7000000 
row in B: 2013-11-07 00:02:22.6970000

Você pode me dar algumas pistas por quê?

Respostas para comentários:
1. Sem gatilhos.
2. Não 1 000 000 registros por vez, é a contagem total de registros na tabela no momento de erro Primeira aparência. Esta informação é para análise estatística - hoje ocorreu um erro após xx milhares de registros após o último erro - por isso é muito aleatório.
3. Sim, as declarações são 100% executadas neste pedido.
4. Sem transação ou único - dois processos diferentes - o mesmo erro.
5. Certamente DateTime2.

Importante! Alguém me disse que o GetDate tem precisão para 3 milissegundos, então talvez obtenha as rodadas de milissegundos com o método Round Robin, então duas vezes para o mesmo ou quase mesmo tempo (diff <3ms) pode dar duas aproximações diferentes?

Answer 1

GetDate para a mudança de tempo de sysdatime nas restrições parece resolver o problema.

Answer 2

Se você inserir e confirmar a primeira inserção na Tabela A e, em seguida, inserir e confirmar a segunda inserção na Tabela B, é muito possível obter esse resultado, porque levará essa diferença de tempo para inserir os dois registros. Mesmo se você não confirmar a inserção em transações separadas.

Quando a tabela crescer, a inserção levará cada vez mais tempo por muitos motivos. Se a tabela tiver índice em cada inserção, o índice precisará tomar nota onde o registro foi salvo ou organizado. Segundo, a fragmentação nas páginas internamente no SQL Server fará a inserção para levar mais tempo. Verifique sua estrutura de índice se desejar inserções mais rápidas, mantenha o fator de preenchimento baixo.

Se você deseja sempre o mesmo tempo, crie uma variável, obtenha tempo e faça a inserção em ambas as tabela usando essa variável.

Espero que ajude.

Answer 3

GETDATE() é derivado do relógio do sistema operacional - se algo fez com que o relógio no servidor mudasse (para um tempo anterior), você alcançará sua viagem (aparente) no tempo.

O que poderia causar essas mudanças? Os óbvios são um ajuste manual ou se o servidor estiver definido para sincronizar automaticamente seu relógio com uma fonte externa - como outra máquina em seu domínio ou via NTP. Também pode haver outras causas possíveis.