Alex Shelemin's questions

É bem conhecido que o isolamento Read Committed é propenso a diferentes anomalias. Li a série de The Great Paul White sobre níveis de isolamento. O post relevante para a discussão é este:

• O Nível de Isolamento Comprometido de Leitura

Ele afirma (novamente, é razoavelmente bem conhecido), que uma instrução executada sob isolamento de leitura confirmada:

Can encounter the same row multiple times;
Can miss some rows completely;

Minha pergunta é sobre a parte das 'linhas ausentes'. Exemplos que falam sobre linhas ausentes geralmente demonstram o problema usando consultas como:

select count(*) from table.

Minha pergunta é que as linhas podem ser perdidas em uma consulta de seleção 'regular' ? Ou seja, uma consulta como

select * from table

ou mesmo

select * from table where id = @id

também perder as linhas que são confirmadas antes do início dessa consulta? Esta pergunta se aplica apenas a Read confirmada com bloqueio (não RCSI), pois o RCSI não permite esses tipos de anomalias.

Eu tenho uma tabela bastante grande com uma das colunas sendo dados XML com um tamanho médio de entrada XML de aproximadamente 15 kilobytes. Todas as outras colunas são ints regulares, bigints, GUIDs etc. Para ter alguns números concretos, digamos que a tabela tenha um milhão de linhas e tenha aproximadamente 15 GB de tamanho.

O que notei é que esta tabela é muito lenta para selecionar dados se eu quiser selecionar todas as colunas. Quando eu faço

SELECT TOP 1000 * FROM TABLE

leva cerca de 20 a 25 segundos para ler os dados do disco - mesmo que eu não imponha nenhuma ordem no resultado. Eu executo a consulta com o cache frio (ou seja, após DBCC DROPCLEANBUFFERS). Aqui estão os resultados das estatísticas de IO:

Contagem de varredura 1, leituras lógicas 364, leituras físicas 24, leituras antecipadas 7191, leituras lógicas lob 7924, leituras físicas lob 1690, leituras antecipadas lob 3968.

Ele pega ~ 15 MB de dados. O plano de execução mostra o Clustered Index Scan como eu esperava.

Não há nenhum IO acontecendo no disco além de minhas consultas; Também verifiquei se a fragmentação do índice clusterizado está próxima de 0%. Esta é uma unidade SATA de nível de consumidor, no entanto, ainda acho que o SQL Server seria capaz de verificar a tabela mais rapidamente do que ~ 100-150 MB/min.

A presença do campo XML faz com que a maioria dos dados da tabela sejam localizados nas páginas LOB_DATA (na verdade, ~90% das páginas da tabela são LOB_DATA).

Acho que minha pergunta é - estou correto ao pensar que as páginas LOB_DATA podem causar verificações lentas não apenas por causa de seu tamanho, mas também porque o SQL Server não pode verificar o índice clusterizado com eficiência quando há muitas páginas LOB_DATA na tabela?

Ainda mais amplamente - é considerado razoável ter tal estrutura de tabela/padrão de dados? As recomendações para usar o Filestream geralmente indicam tamanhos de campo muito maiores, então não quero seguir esse caminho. Eu realmente não encontrei nenhuma boa informação sobre este cenário em particular.

Tenho pensado na compactação XML, mas ela precisa ser feita no cliente ou com SQLCLR e exigiria bastante trabalho para implementar no sistema.

Tentei a compactação e, como os XMLs são altamente redundantes, posso (no aplicativo ac#) compactar o XML de 20 KB para ~ 2,5 KB e armazená-lo na coluna VARBINARY, evitando o uso de páginas de dados LOB. Isso acelera SELECTs 20x vezes em meus testes.

Eu tenho uma consulta que une algumas tabelas e tem um desempenho muito ruim - as estimativas de linha estão muito (1000 vezes) erradas e a junção de loops aninhados é escolhida, resultando em várias varreduras de tabela. A forma da consulta é bastante simples, parecendo algo assim:

SELECT t1.id
FROM t1
INNER JOIN t2 ON t1.id = t2.t1_id
LEFT OUTER JOIN t3 ON t2.id = t3.t2_id
LEFT OUTER JOIN t4 ON t3.t4_id = t4.id 
WHERE t4.id = some_GUID

Brincando com a consulta, notei que, quando sugiro usar uma junção de mesclagem para uma das junções, ela é executada muito mais rápido. Isso eu posso entender - Merge join é uma opção melhor para os dados que são unidos, mas o SQL Server simplesmente não estima corretamente escolhendo os Nested Loops.

O que não entendo completamente é por que essa dica de junção altera todas as estimativas para todas as operadoras de planos? Ao ler diferentes artigos e livros, presumi que as estimativas de cardinalidade são executadas antes de o plano ser criado, portanto, usar uma dica não alteraria as estimativas, mas diria explicitamente ao SQL Server para usar uma implementação de junção física específica.

O que vejo, no entanto, é que a sugestão de mesclagem faz com que todas as estimativas se tornem praticamente perfeitas. Por que isso acontece e existem técnicas comuns para fazer o otimizador de consulta fazer uma estimativa melhor sem uma dica - considerando que as estatísticas obviamente permitem isso?

UPD: planos de execução anônimos podem ser encontrados aqui: https://www.dropbox.com/s/hchfuru35qqj89s/merge_join.sqlplan?dl=0 https://www.dropbox.com/s/38sjtv0t7vjjfdp/no_hints_join.sqlplan?dl =0

Eu verifiquei as estatísticas usadas por ambas as consultas usando TF 3604, 9292 e 9204, e elas são idênticas. No entanto, os índices que são verificados/buscados diferem entre as consultas.

Além disso, tentei executar a consulta com OPTION (FORCE ORDER)- ela é ainda mais rápida do que usar merge join, escolhendo HASH MATCH para cada junção.