Fall Empfindlichkeit bei der Abfrage von SQL Server 2005 von .NET OleDB

Question

Ich habe eine Abfrage, die ich von einer .NET-Anwendung zu einer SQL Server-Datenbank bin Ausführung und es scheint eine ganze Weile in Anspruch nehmen (5+ Minuten). Ich habe eine Test-app in c #, um zu versuchen, um zu sehen, was so lange spricht (die Abfrage sollte schnell zurück).

Als ich die Abfrage wurde die Rekonstruktion von in Hinzufügen von Elementen zu sehen, welcher Teil wurde so lange dauern werde, wurde ich praktisch wörtlich die Abfrage zu rekonstruieren, wo der einzige Unterschied die Räume in der ursprünglichen Abfrage und eine Kapitalisierung Unterschied war. Dieser Unterschied ergab ein Ergebnis in etwa 100 Millisekunden.

Hat sich das jemand vorher gesehen? Ich frage mich, ob es Dienste in unserem Server ausgeschaltet (da ein Mitarbeiter hat das gleiche Problem) oder auf unseren Computern.

Vielen Dank im Voraus für jede Hilfe bei dieser.

Codebeispiel unten (der Unterschied in dem in der ersten Zeile der Abfrage am Ende (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

Ich vermute, dass dies eine Prozedur-Cache Problem. Ein Vorteil von gespeicherten Prozeduren ist, dass der Plan für Sie gespeichert ist, welche beschleunigt alles. Leider ist es möglich, einen schlechten Plan im Cache zu bekommen (auch wenn dynamische Abfragen verwendet wird).

Just for fun, überprüfte ich meine Prozedur-Cache, lief wieder eine Ad-hoc-Abfrage, geprüft, dann lief ich die gleiche Abfrage mit verschiedener capitlization und ich war überrascht, dass das Verfahren zu sehen höher zählen.

Try this ....

Eine Verbindung mit SQL Server Management Studio.

DBCC MemoryStatus

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

dbcc MemoryStatus

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

dbcc MemoryStatus

Ich glaube, Sie werden feststellen, dass die TotalProcs ändert sich, wenn die Anweisung Änderungen (auch wenn die einzige Änderung ist Groß- und Kleinschreibung).

Aktualisieren der Statistiken helfen können. Das ist ein ziemlich langsam laufender Prozess, so dass Sie können, dass während einer langsamen Zeit ausgeführt werden sollen.

Answer 2

Da Sie SQL Server 2005 verwenden, müssen Sie mit einem SqlCommand-Objekt versucht, anstelle des OleDbCommand Objekt?

Answer 3

Ich bin kein Unterschied in Ihren Abfragen zu sehen, die die Leistung beeinflussen würde - was ist das Caching oder Index / Statistiken Änderungen zwischen den Läufen? Der Ausführungsplan aufgrund Statistiken oder Indexänderungen geändert hat.

In Bezug auf den Fall: Fall kann Rolle, ob die Datenbank zu Fall-Empfindlicher gesetzt ist, aber für beide Abfragen in Groß- und Kleinschreibung Datenbank auszuführen, müsste es zu Spalten in beiden Formaten genannt - der Abfrageparser gehorchen der Fall ist -. es wird kein Unterschied in der Leistung führen

Answer 4

Zum einen sind Sie 100% sicher sein die Abfrage, die nicht in Ordnung ist? Überprüfen Sie die Trace-Profil in SQL Server, um zu sehen, wie lange seine Aufnahme in die DB.

Zweitens werden Sie die gleiche Anzahl von Ergebnissen zurück zu bekommen. Die Aktivierung sollte nicht standardmäßig in SQL Server egal, aber es könnte anders eingerichtet wurde.

Answer 5

Wenn ich eine Abfrage, die „5+ Minuten“ nahm, würde ich nicht über die 100 Millisekunden besorgt es, den Fall der Zeichenfolge übereinstimmen.

Answer 6

Vielen Dank für Ihre Antworten, ich auf jeden wiederum reagieren werden:

1) Russ, ich bin einverstanden, dass SQLConnection- besser wäre, aber leider komme ich nicht die Art der Verbindung zu setzen. Ich habe nur eine kleine App diese Abfrage zu testen, aber die Abfrage dynamisch in einer viel größeren Anwendung erstellt wird.

2) gbjbaanb, Es ist kein Server-Problem Ich denke, weil ich in etwa zur gleichen Zeit beiden Abfragen aus dem Management Studio ausführen kann, scheint es nur ein Problem zu sein, wenn sie durch oledb in .net (1.1 und 2.0 läuft) . Wir haben einen Profiler darauf laufen und die Trace-Datei bestätigt, dass es mehr als 5 Minuten in Anspruch nahm, die Abfrage zu beenden, wenn diese Art und Weise genannt.

3) Joel Coehoorn, Einverstanden, aber wirklich, was ich versuche zu hier zu bekommen ist „warum“, weil gerade jetzt wissen wir nicht, wie groß dieses Problem ist und wo es liegt.

4) Cade Roux ist der Unterschied sehr reproduzierbaren, so dass ich glaube nicht, dass es ein Problem mit Indexänderungen oder Caching ist, da ich die Tests ausgeführt werde wieder mit den gleichen Ergebnissen zu unterstützen und dass sie nehmen etwa zur gleichen Zeit in SQL Server ausgeführt wird.

Answer 7

Dank G Mastros für die vollständigste Antwort, obwohl die Aktualisierung der Statistik im Nachhinein wurde von Cade vorgeschlagen. G mastos' Lösung war besser geeignet, um mein Niveau von SQL Server Erfahrung aber nicht.

Danke für die Hilfe jeder!

Ich werde schauen in warum dieser scheinbar harmlosen Unterschied so große Folgen hat