tempo de resposta

[Fabio Cordeiro alexandre]

Boa tarde pessoal,

gostaria de uma ajuda.

Estou executando duas queries, na querie1 tem os campos que quero e na
querie2 botei o *. As duas queries tem as mesma condições.

Na primeira querie1 eu tenho um tempo de resposta de 2 minutos e na
querie2 eu tenho 4 segundos.

Logicamente, achei muito estranho isso e rodei o statistics io e
obtive os seguintes resultados:

querie1
(1 row(s) affected)
Table 'AuItemAuto'. Scan count 1, logical reads 6, physical reads 0,
read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob
read-ahead reads 0.
Table 'CRT_STATUS_ATENDIMENTO'. Scan count 0, logical reads 2,
physical reads 0, read-ahead reads 0, lob logical reads 0, lob
physical reads 0, lob read-ahead reads 0.
Table 'CRT_TIPO_ATENDIMENTO'. Scan count 1, logical reads 2, physical
reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads
0, lob read-ahead reads 0.
Table 'CRT_EQUIPE'. Scan count 0, logical reads 2, physical reads 0,
read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob
read-ahead reads 0.
Table 'CRT_OPERADOR'. Scan count 0, logical reads 2, physical reads 0,
read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob
read-ahead reads 0.
Table 'ModalidadeSeguro'. Scan count 1, logical reads 3, physical
reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads
0, lob read-ahead reads 0.
Table 'CRT_RECEPTIVO_MOVIMENTACAO'. Scan count 1, logical reads
18614613, physical reads 0, read-ahead reads 0, lob logical reads 0,
lob physical reads 0, lob read-ahead reads 0.
Table 'Cliente'. Scan count 10854, logical reads 32702, physical reads
0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob
read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0,
read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob
read-ahead reads 0.
Table 'CRT_PRODUTO_AGENDAMENTO'. Scan count 1, logical reads 629,
physical reads 0, read-ahead reads 0, lob logical reads 0, lob
physical reads 0, lob read-ahead reads 0.
Table 'AuContratoAuto'. Scan count 1, logical reads 3406, physical
reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads
0, lob read-ahead reads 0.

querie2
1 row(s) affected)
Table 'AuItemAuto'. Scan count 1, logical reads 6, physical reads 0,
read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob
read-ahead reads 0.
Table 'CRT_STATUS_ATENDIMENTO'. Scan count 0, logical reads 2,
physical reads 0, read-ahead reads 0, lob logical reads 0, lob
physical reads 0, lob read-ahead reads 0.
Table 'CRT_TIPO_ATENDIMENTO'. Scan count 0, logical reads 2, physical
reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads
0, lob read-ahead reads 0.
Table 'Cliente'. Scan count 1, logical reads 7, physical reads 0,
read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob
read-ahead reads 0.
Table 'ModalidadeSeguro'. Scan count 1, logical reads 3, physical
reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads
0, lob read-ahead reads 0.
Table 'AuContratoAuto'. Scan count 1, logical reads 10, physical reads
0, read-ahead reads 0, lob logical reads 2, lob physical reads 0, lob
read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0,
read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob
read-ahead reads 0.
Table 'CRT_RECEPTIVO_MOVIMENTACAO'. Scan count 1, logical reads 1715,
physical reads 0, read-ahead reads 0, lob logical reads 0, lob
physical reads 0, lob read-ahead reads 0.
Table 'CRT_EQUIPE'. Scan count 1, logical reads 2, physical reads 0,
read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob
read-ahead reads 0.
Table 'CRT_OPERADOR'. Scan count 1, logical reads 4, physical reads 0,
read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob
read-ahead reads 0.
Table 'CRT_PRODUTO_AGENDAMENTO'. Scan count 1, logical reads 622,
physical reads 0, read-ahead reads 0, lob logical reads 0, lob
physical reads 0, lob read-ahead reads 0.

Não consigo entender o porque dessa leitura logica tão alta da querie1.

Alguém pode me dar uma luz??

Abração.

--
Fábio Cordeiro Alexandre

[anderson figueiredo]

tem algum index com os campos em include?

2012/1/20 Fabio Cordeiro alexandre <fabio.corde...@gmail.com>

--
Anderson Figueiredo
Analista/Programador
61 - 8418-5222

61 - 7815-8623

964*296

[Vitor Fava]

Boa Tarde.

Em alguma dessas tabelas existe alguma coluna LOB ou BLOB?

Atenciosamente.

[Fabio Cordeiro alexandre]

Vitor,

não.

Anderson,

as tabelas tem índices e já brinquei de criar alguns índices a mais,
porém não resolveu o problema.

2012/1/20 Vitor Fava <vito...@gmail.com>:

--
Fábio Cordeiro Alexandre

[Rodrigo Ribeiro Gomes]

Fáibio, vc viu o plano ?

O plano da querie 2 por acaso faz um table scan ou paralelismo ?

[Rodrigo Ribeiro Gomes]

O motivo da minha pergunta é pra saber se o sql server fez um scan nessa tabela que tem as leituras diferentes.

O que eu penso é que na primeira query ele deve ter usado um nested loops, que acabou lendo a tabela varias vezes... dai o numero alto de leituras...

E na segunda, ele deve ter usado um table scan, por isso deu menos leituras...

Se foi isso que aconteceu, provavelmente, quando voce colocou as colunas na query 1, as estisticas para essas colunas nao estavam legais, dai ele escolheu um plano ruim...

Quando voce usou o * , ele ja optou por consultar estatísticas diferentes...

Bom, eu acho que pode ser isso, estoun esperando sua resposta sobre os planos!!!!

[]'s

[Fabio Cordeiro alexandre]

Rodrigo,

Bom dia, fiz uns testes aqui e basicamente foi isso que aconteceu. Na
escolha das colunas ele optou por um plano ruim. Eu criei um covered
index e mesmo assim o table scan foi mas eficiente!! A minha duvida
tinha ficado nesse aspecto, porém percebi que a tabela que tinha o
maior numero estimado de retorno de linhas no plano tinha a condição e
o campo ser null ou um valor passado para a SP que continha essa
querie.

Tive que tirar essa condição para que ele utilizasse o table seek da tabela.

Obrigado a todos pela ajuda.

Em 20 de janeiro de 2012 17:10, Rodrigo Ribeiro Gomes
<rodrigo...@gmail.com> escreveu:

--
Fábio Cordeiro Alexandre

[Rodrigo Ribeiro Gomes]

Legal.

so me responde uma coisa: quando voce criou o indice nas colunas usadas, ele passou a fazer o table scan, mesmo colocando o nome das colunas ?

 é pra eu saber se o prob era estatísticas mesmo, pq se foi isso mesmo, quando vc criou o indice, o sql server automaticamente criou estatisticas para essas mesmas colunas do indice.

[]'s

[Fabio Cordeiro alexandre]

Sim,

mas o que tinha acontecido na primeira querie é que na condição
(where) era passado (@variavel is null or campo = @variavel) e ele
estava desconsiderando o table hint.

Agora eu estou tendo um outro problema com outra querie da mesma sp
que mesmo colocando o table hint e na condição (campo = @variavel) ele
está fazendo o table scan. =/

Já atualizei a estatística da tabela!! E mesmo utilizando a table hint
(forceseek) o plano não é bom.

Em 24 de janeiro de 2012 08:56, Rodrigo Ribeiro Gomes
<rodrigo...@gmail.com> escreveu:

--
Fábio Cordeiro Alexandre

[Rodrigo Ribeiro Gomes]

Mas o sql deve ta escolhendo o table scan porque realmente ele e melhor do que o seek...

Com o seek o numero de leituras e muito maior, assim ele opta por fazer um scan

[Fabio Cordeiro alexandre]

Mas essa é uma duvida que eu tenho,

será que o otimizador de consulta sempre escolhe o plano de execução
mais apropriado, por exemplo, nesse segundo caso que vi hoje, quando
vi o numero de leituras logicas e físicas era o oposto do que o plano
de execução estava me mostrando. Eu vi que tem como você forçar a
utilização de um plano de execução, mas pode encontrar problemas caso
ocorra alguma alteração tanto de banco quanto de base de dados. Nesse
mesmo caso, duas queries de duas tabelas que as estruturas são
semelhantes e o índice foi criado em cima dos mesmos tipos de campo
resultavam em planos diferentes. Um era seek e o outro era scan.

Em 24 de janeiro de 2012 10:24, Rodrigo Ribeiro Gomes
<rodrigo...@gmail.com> escreveu:

--
Fábio Cordeiro Alexandre

[Demétrio Silva]

Olá Fábio,

Sem sempre o QO vai escolher o melhor plano ( vai depender das
estatísticas, índices, etc. ).

Sugiro uma olhada no blog do Fabiano, pois lá tem muita informação sobre o QO.

Lembro que o Fabiano fez um WebCast com o título "Entenda porque o
Query Optimizer é mais esperto que você", mas não achei na net para
lhe passar o link.

Abraço,

Em 24 de janeiro de 2012 15:13, Fabio Cordeiro alexandre
<fabio.corde...@gmail.com> escreveu:

--
Demétrio Silva
MCP - MCTS MCITP - MCT - SQL Server 2008

[Fabio Cordeiro alexandre]

Vlw pela dica Demétrio.

vou buscar esse WebCast.

--
Fábio Cordeiro Alexandre

[Rodrigo Ribeiro Gomes]

Fábio, nessa segunda querie, voce esta fazendo os testes com a variável, ou colocando um valor no lugar dela ?

Porque quando voce usa uma variável o sql faz uma magic density, e estima o numero de linhas nao com base nas estatisticas, e sim com base em porcetagem do numero de linhas... (Procura por Variable sniffing).

Outra coisa, e que o QO nem sempre escolhe o melhor plano. Ele vai escolher um plano "bom o suficiente". Isso é pra que a fase de otimizacao nao leve tanto tempo, visto que dependendo da query, para escolher o melhor plano, pode levar horas...