Fabian Schmied's questions

Tenho uma consulta muito simples em que uso um UNION ALL+ ORDER BYem duas consultas que retornam dados pré-ordenados de seus respectivos índices. Por algum motivo, o SQL não usa um Merge Join (Concatenation)para isso, mas um Concatenation, seguido por um Sort. Qual poderia ser o motivo?

Aqui está um exemplo completo de reprodução. (As INDEXdicas são necessárias para que o SQL Server use o índice, apesar do baixo número de linhas na tabela.)

CREATE TABLE T1(
    SequenceNumber bigint IDENTITY NOT NULL,
    TenantId uniqueidentifier NOT NULL,
    Object1Id uniqueidentifier NOT NULL,
    Payload nvarchar(max) NOT NULL,
    OtherNumber bigint NOT NULL,

  CONSTRAINT PK_T1 PRIMARY KEY CLUSTERED (TenantId,SequenceNumber ASC)
)

CREATE INDEX IX_TenantId_Object1Id_OtherNumber ON T1(TenantId, Object1Id, OtherNumber)

CREATE TABLE T2(
    SequenceNumber bigint IDENTITY NOT NULL,
    TenantId uniqueidentifier NOT NULL,
    Object2Id uniqueidentifier NOT NULL,
    Payload nvarchar(max) NOT NULL,
    OtherNumber bigint NOT NULL,

  CONSTRAINT PK_T2 PRIMARY KEY CLUSTERED (TenantId,SequenceNumber ASC)
)

CREATE INDEX IX_TenantId_Object2Id_OtherNumber ON T2(TenantId, Object2Id, OtherNumber)

DECLARE @tenantId UNIQUEIDENTIFIER = NEWID()
DECLARE @object1Id UNIQUEIDENTIFIER = NEWID()
DECLARE @object2Id UNIQUEIDENTIFIER = NEWID()

SELECT OtherNumber, Payload FROM T1 WITH (INDEX(IX_TenantId_Object1Id_OtherNumber)) WHERE TenantId = @tenantId AND Object1Id = @object1Id
UNION ALL
SELECT OtherNumber, Payload FROM T2 WITH (INDEX(IX_TenantId_Object2Id_OtherNumber)) WHERE TenantId = @tenantId AND Object2Id = @object2Id
ORDER BY OtherNumber

DROP TABLE T1
DROP TABLE T2

E esta é uma captura de tela do plano de execução:

Quando adiciono a MERGE UNIONopção, o SQL Server pré-classifica explicitamente os resultados individuais da consulta (em OtherNumbere Payload, por algum motivo).

Agora, uma reviravolta interessante: quando adiciono uma restrição UNIQUE às OtherNumbercolunas, o SQL Server repentinamente escolhe o Merge Join (Concatenation)operador. Por quê?

Testei isso localmente no SQL Server 2016 e no Azure SQL.

TL;DR: A questão abaixo se resume a: Ao inserir uma linha, existe uma janela de oportunidade entre a geração de um novo Identityvalor e o bloqueio da chave da linha correspondente no índice clusterizado, onde um observador externo poderia ver uma nova Identity valor inserido por uma transação concorrente? (No SQL Server.)

versão detalhada

Eu tenho uma tabela do SQL Server com uma Identitycoluna chamada CheckpointSequence, que é a chave do índice clusterizado da tabela (que também possui vários índices não clusterizados adicionais). As linhas são inseridas na tabela por vários processos e threads simultâneos (no nível de isolamento READ COMMITTEDe sem IDENTITY_INSERT). Ao mesmo tempo, existem processos que leem periodicamente as linhas do índice clusterizado, ordenadas por aquela CheckpointSequencecoluna (também em nível de isolamento READ COMMITTED, com a READ COMMITTED SNAPSHOTopção desativada).

Atualmente, confio no fato de que os processos de leitura nunca podem "pular" um ponto de verificação. A minha dúvida é: Posso contar com este imóvel? E se não, o que eu poderia fazer para torná-lo verdade?

Exemplo: Ao inserir linhas com valores de identidade 1, 2, 3, 4 e 5, o leitor não deve ver a linha com valor 5 antes de ver a linha com valor 4. Os testes mostram que a consulta, que contém uma ORDER BY CheckpointSequencecláusula ( e uma WHERE CheckpointSequence > -1cláusula), bloqueia de forma confiável sempre que a linha 4 deve ser lida, mas ainda não confirmada, mesmo que a linha 5 já tenha sido confirmada.

Acredito que, pelo menos em teoria, pode haver uma condição de corrida aqui que pode fazer com que essa suposição seja quebrada. Infelizmente, a documentação Identitynão diz muito sobre como Identityfunciona no contexto de várias transações simultâneas, apenas diz "Cada novo valor é gerado com base na semente e incremento atuais". e "Cada novo valor para uma determinada transação é diferente de outras transações simultâneas na tabela." ( MSDN )

Meu raciocínio é que deve funcionar de alguma forma assim:

1. Uma transação é iniciada (explícita ou implicitamente).
2. Um valor de identidade (X) é gerado.
3. O bloqueio de linha correspondente é obtido no índice clusterizado com base no valor de identidade (a menos que o escalonamento de bloqueio seja ativado, caso em que toda a tabela é bloqueada).
4. A linha é inserida.
5. A transação é confirmada (possivelmente muito tempo depois), então o bloqueio é removido novamente.

Acho que entre os passos 2 e 3, há uma janela muito pequena onde

• uma sessão simultânea pode gerar o próximo valor de identidade (X+1) e executar todas as etapas restantes,
• permitindo assim que um leitor vindo exatamente naquele ponto do tempo leia o valor X+1, perdendo o valor de X.

Claro, a probabilidade disso parece extremamente baixa; mas ainda assim - isso pode acontecer. Ou poderia?

(Se você estiver interessado no contexto: esta é a implementação do SQL Persistence Engine do NEventStore. O NEventStore implementa um armazenamento de evento apenas anexado, onde cada evento obtém um novo número de sequência de ponto de verificação ascendente. Os clientes leem os eventos do armazenamento de eventos ordenados por ponto de verificação para realizar cálculos de todos os tipos. Depois que um evento com ponto de verificação X é processado, os clientes consideram apenas eventos "mais recentes", ou seja, eventos com ponto de verificação X+1 e acima. Portanto, é vital que os eventos nunca possam ser ignorados, como eles nunca seriam considerados novamente. No momento, estou tentando determinar se a Identityimplementação do ponto de verificação com base atende a esse requisito. Estas são as instruções SQL exatas usadas : Schema , Writer's query ,Pergunta do Leitor .)

Se eu estiver certo e a situação descrita acima puder surgir, vejo apenas duas opções de lidar com eles, ambas insatisfatórias:

• Ao ver um valor de sequência de ponto de verificação X+1 antes de ter visto X, descarte X+1 e tente novamente mais tarde. No entanto, porque Identityé claro que pode produzir lacunas (por exemplo, quando a transação é revertida), X pode nunca vir.
• Então, mesma abordagem, mas aceite o intervalo após n milissegundos. No entanto, que valor de n devo assumir?

Alguma ideia melhor?

Na minha aplicação, com um banco de dados rodando no SQL Server 2012, tenho um trabalho (tarefa agendada) que executa periodicamente uma consulta cara e grava os resultados em uma tabela que pode ser consultada posteriormente pelo aplicativo.

Idealmente, eu gostaria de executar essa consulta cara apenas se algo mudou desde que a consulta foi executada pela última vez. Como as tabelas de origem são muito grandes, não posso simplesmente selecionar uma soma de verificação sobre todas as colunas candidatas ou algo assim.

Tenho as seguintes ideias:

• Escreva explicitamente um carimbo de data/hora da última alteração, um sinalizador "deve haver consultas" ou algo assim em uma tabela de rastreamento sempre que eu alterar algo em uma tabela de origem.
• Use um gatilho para fazer o mesmo.

No entanto, eu realmente gostaria de saber se existe uma maneira leve de detectar alterações em uma tabela sem que eu rastreie explicitamente as gravações. Posso, por exemplo, pegar o "atual" ROWVERSIONde uma tabela ou algo assim?