Sensibilità maiuscole / minuscole durante l'interrogazione di SQL Server 2005 da .NET mediante OleDB

Question

Ho una query che sto eseguendo da un'applicazione .NET a un database SQL Server e sembra che ci voglia un po 'di tempo per completarla (5+ minuti). Ho creato un'app di prova in c # per provare a vedere di cosa parlava così a lungo (la query dovrebbe tornare rapidamente).

Mentre stavo ricostruendo la query aggiungendo elementi per vedere quale porzione stava impiegando così tanto tempo, ho finito per ricostruire la query praticamente alla lettera dove l'unica differenza erano gli spazi nella query originale e una differenza di maiuscole. Questa differenza ha restituito un risultato in circa 100 millisecondi.

Qualcuno l'ha mai visto prima? Mi chiedo se ci sono servizi disattivati ??nel nostro server (poiché un collega ha lo stesso problema) o sui nostri computer.

Grazie in anticipo per qualsiasi aiuto in merito.

Esempio di codice di seguito (la differenza nella prima riga della query alla fine (fk_source vs. fk _Source):

//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

Sospetto che si tratti di un problema di cache delle procedure. Un vantaggio delle procedure memorizzate è che il piano è archiviato per te, il che accelera le cose. Sfortunatamente, è possibile ottenere un piano errato nella cache (anche quando si utilizzano query dinamiche).

Solo per divertimento, ho controllato la mia cache delle procedure, ho eseguito una query ad hoc, ho verificato di nuovo, quindi ho eseguito la stessa query con maiuscole / minuscole diverse e sono rimasto sorpreso di vedere il conteggio delle procedure più elevato.

Prova questo ....

Connetti a SQL Server Management Studio.

DBCC MemoryStatus

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

dbcc MemoryStatus

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

dbcc MemoryStatus

Penso che scoprirai che TotalProcs cambia quando cambia l'istruzione (anche quando l'unica modifica fa distinzione tra maiuscole e minuscole).

Potrebbe essere utile aggiornare le tue statistiche. È un processo piuttosto lento, quindi potresti volerlo eseguire durante un periodo lento.

Answer 2

Dato che stai usando SQL Server 2005, hai provato con un oggetto SqlCommand invece dell'oggetto OleDbCommand?

Answer 3

Non vedo differenze nelle tue query che potrebbero influire sulle prestazioni: che dire della cache o delle variazioni dell'indice / delle statistiche tra le esecuzioni? Il piano di esecuzione potrebbe essere cambiato a causa di statistiche o modifiche all'indice.

Riguardo al caso: il caso può essere importante se il database è impostato per la distinzione tra maiuscole e minuscole, ma affinché entrambe le query vengano eseguite in un database con distinzione tra maiuscole e minuscole, dovrebbero essere presenti colonne denominate in entrambi i formati: il parser delle query obbedirà il caso - non causerà una differenza di prestazioni.

Answer 4

in primo luogo, sei sicuro al 100% che la query non vada bene? Controllare il profilo di traccia nel server sql per vedere quanto tempo impiega nel DB.

In secondo luogo, stai ottenendo lo stesso numero di risultati. La capitalizzazione non dovrebbe avere importanza per impostazione predefinita nel server sql, ma avrebbe potuto essere impostata diversamente.

Answer 5

Se avessi una query che impiegava " 5+ minuti " ;, non sarei preoccupato per i 100 millisecondi necessari per abbinare il caso della stringa.

Answer 6

grazie per tutte le tue risposte, risponderò a turno a turno:

1) Russ, sono d'accordo che SQLConnection sarebbe meglio, ma sfortunatamente non riesco a impostare il tipo di connessione. Ho appena creato una piccola app per testare questa query, ma la query viene creata in modo dinamico in un'applicazione molto più grande.

2) gbjbaanb, penso che non sia un problema del server, poiché posso eseguire entrambe le query dallo studio di gestione in circa lo stesso tempo, sembra solo essere un problema quando si esegue oledb in .net (1.1 e 2.0) . Abbiamo eseguito un profiler su di esso e il file di traccia ha confermato che sono stati necessari più di 5 minuti per completare la query quando chiamato in questo modo.

3) Joel Coehoorn, d'accordo, ma in realtà quello che sto cercando di ottenere qui è "perché" perché in questo momento non sappiamo quanto sia grande questo problema e dove si trovi.

4) Cade Roux, La differenza è molto riproducibile, quindi non penso che sia un problema con le modifiche all'indice o la memorizzazione nella cache poiché ho eseguito i test back-to-back con gli stessi risultati e che impiegano circa lo stesso tempo in Esecuzione di SQL Server.

Answer 7

Grazie a G Mastros per la risposta più completa, anche se a posteriori l'aggiornamento di statistiche è stato suggerito da Cade. La soluzione di G Mastos si adattava meglio al mio livello di esperienza con SQL Server.

Grazie per aiutare tutti!

Esaminerò perché questa differenza apparentemente innocente ha conseguenze così grandi