Caso Sensibilidade ao consultar o SQL Server 2005 a partir de .NET usando OleDB

Question

Eu tenho uma consulta que estou executando a partir de um aplicativo .NET para um banco de dados SQL Server e parece demorar um pouco para completar (5+ minutos). Eu criei um aplicativo de teste em C # para tentar ver o que estava falando tanto tempo (a consulta deve retornar rapidamente).

Como eu estava reconstruindo a consulta adicionando em elementos para ver qual parte estava demorando tanto, acabei reconstruir a consulta praticamente na íntegra onde a única diferença foi os espaços na consulta original e uma diferença de capitalização. Esta diferença retornou um resultado em cerca de 100 milissegundos.

Alguém viu isso antes? Eu estou querendo saber se existem serviços desligado no nosso servidor (uma vez que um colega de trabalho tem o mesmo problema) ou em nossos computadores.

Agradecemos antecipadamente por qualquer ajuda com isso.

amostra de código abaixo (a diferença de na primeira linha da consulta no final (fk_source vs. fk fonte_):

//Original
    OleDbCommand comm = new OleDbCommand("select min(ctc.serial_no) as MIN_INTERVAL from countstypecode ctc, source s, countstype ct, counts c where ct.value_id=c.value_id and s.c_id=ct.fk_source and " +
      "ct.timeinterval=ctc.typename and ct.timeinterval in ('15min','1h','1day') and c.time_stamp >=  CONVERT(datetime,'01-01-2008',105)  and c.time_stamp < " +
      "CONVERT(datetime,'01-01-2009',105)  and s.c_id = '27038dbb19ed93db011a315297df3b7a'", dbConn);

//Rebuilt
    OleDbCommand comm = new OleDbCommand("select min(ctc.serial_no) as MIN_INTERVAL from countstypecode ctc, source s, countstype ct, counts c where ct.value_id=c.value_id and s.c_id=ct.fk_Source and " +
      "ct.timeinterval=ctc.typename and ct.timeinterval in ('15min','1h','1day') and c.time_stamp >= CONVERT(datetime,'01-01-2008',105) and c.time_stamp < " +
      "CONVERT(datetime,'01-01-2009',105) and s.c_id='27038dbb19ed93db011a315297df3b7a'", dbConn);

Answer 1

Eu suspeito que esta é uma questão cache de procedimento. Um dos benefícios de procedimentos armazenados é que o plano é armazenado para você, o que acelera as coisas. Infelizmente, é possível obter um mau plano no cache (mesmo quando usando consultas dinâmicas).

Apenas por diversão, eu verifiquei meu cache de procedimento, correu uma consulta ad hoc, verificado novamente, então eu corri a mesma consulta com capitlization diferente e fiquei surpreso ao ver a contagem procedimento superior.

Tente este ....

Ligar ao SQL Server Management Studio.

DBCC MemoryStatus

Select Columns... From TABLES.... Where....

dbcc MemoryStatus

Select Columns... From tables.... Where....

dbcc MemoryStatus

Eu acho que você verá que os TotalProcs muda quando as alterações de instrução (mesmo quando a única mudança é case sensitive).

Atualizando suas estatísticas podem ajudar. Isso é um processo bastante lento em execução, de modo que você pode querer executar que durante um período lento.

Answer 2

Uma vez que você estiver usando SQL Server 2005, você já tentou com um objeto SqlCommand em vez do objeto OleDbCommand?

Answer 3

Não estou vendo a diferença em suas consultas o que afetaria o desempenho - o que sobre o cache ou índice / estatística mudanças entre as execuções? O plano de execução pode ter mudado devido a estatísticas ou mudanças de índice.

Em relação ao caso: Caso pode importa se o banco de dados está definido para ser case-sensistive, mas para ambas as consultas para ser executado em um banco de dados de maiúsculas e minúsculas, não teria que ser colunas nomeadas em ambos os formatos - o analisador de consulta vai obedecer o caso -. não vai causar uma diferença de desempenho

Answer 4

Em primeiro lugar, você está 100% certo sua a consulta que está acontecendo de errado? Verifique o perfil de rastreamento no servidor SQL para ver quanto tempo sua tomada no DB.

Em segundo lugar, você está recebendo o mesmo número de resultados de volta. A capitalização não deve importa por padrão no servidor SQL, mas poderia ter sido configurado de forma diferente.

Answer 5

Se eu tivesse uma consulta que levou "5+ minutos", eu não estaria preocupado com os 100 milissegundos que leva para igualar-se o caso da cadeia.

Answer 6

Obrigado por todas as suas respostas, eu vou responder a cada um deles:

1) Russ, concordo que SQLConnection seria melhor, mas infelizmente eu não começa a definir o tipo de conexão. Acabei de criar um pequeno aplicativo para testar esta consulta, mas a consulta é criada dinamicamente em uma aplicação muito maior.

2) gbjbaanb, não é um problema de servidor eu acho, porque eu posso correr ambas as consultas do estúdio de gestão em quase ao mesmo tempo, ela só parece ser um problema quando executado através oledb em .net (1.1 e 2.0) . Nós executar um profiler sobre ele e o arquivo de rastreamento confirmou que levou mais de 5 minutos para completar a consulta quando chamado desta forma.

3) Joel Coehoorn, concordou, mas realmente o que eu estou tentando chegar aqui é "porquê" porque agora não sabemos quão grande o problema é e onde ela se encontra.

4) Cade Roux, A diferença é muito reprodutíveis, então eu não acho que é um problema com mudanças de índice ou cache desde que eu executar os testes de volta para trás com os mesmos resultados e que eles levam quase ao mesmo tempo em SQL Server para executar.

Answer 7

Graças ao G Mastros para a resposta mais completa, embora em retrospecto a atualização nas estatísticas foi sugerido pelo Cade. solução G mastos' foi melhor no entanto adequado para o meu nível de experiência SQL Server,.

Obrigado por ajudar a todos!

Eu vou olhar em porque esta diferença aparentemente inocente tem consequências tão grandes