Hallo Zusammen ...
Der Titel für den Thread ist weng schwierig zu wählen, weil auch das Problem ziemlich merkwürdig ist - ich versuche es mal genau zu erklären:
Ich habe hier eine MSSQL-Datenbank. Es geht um eine Tabelle, in der ca. 70 Millionen Datensätze sind. Indizes sollten auch ganz gut gewählt sein. In der Datenbank befinden sich Daten mit einem Zeitstempel von verschiedenen Hardware-Geräten, zurück bis Anfang 2008.
Jetzt muss ich aus diesen ganz vielen Datensätzen Daten für ein bestimmtes Gerät und einen ganz bestimmten Tag herausfischen.
Dies mache ich in einer asp-Webseite, weil es Client-Programme gibt, die diese Daten ständig anfordern. (Code weiter unten). Was allermeistens gefragt wird, sind die Daten sagen wir mal 2 Wochen zurück. Das geht dann innerhalb von 0,5 bis 1 Sekunde. Es werden also ständig Daten von den unterschiedlichen Geräten angefordert, die sich im Bereich von jetzt 2 Wochen zurück befinden. Je weiter die Daten zurückliegen, desto seltener werden die angefragt.
Jetzt kommt mein Problem:
Ich möchte jetzt Daten eines Tages aus dem Januar 2008 abfragen, und das dauert so lange, dass der Servertimeout (120 Sekunden oder so) nicht ausreicht. Nehme ich allerdings die von der Webseite aufgerufene Query gebe die im Query-Analyzer ein und erfrage die Daten damit, geht das innerhalb von nicht mal einer halben Sekunde.
Es sieht also so aus, dass die Abfragen, egal über welchen Zeitraum, aus dem Query-Analyzer heraus immer nicht mal ein halbe Sekunde dauern, aus der asp-Seite heraus aufgerufen, umso länger dauern, je weiter sie zurückliegen.
Während ich das schreibe und diesen Zusammenhang formuliere, könnte es evtl. sein, dass es umso länger dauert, je seltener Bereiche der Tabelle aus dem Skript heraus aufgerufen (und vielleicht gecached) werden?
Bin auf jeden Fall völlig ratlos, wie ich an dieses Problem herangehen soll. Die Indizierung der Tabelle scheint ja zu passen, weil ich an die Daten extrem flott herankomme.
Hier mein Code:
Ich habe auch schon mit unterschiedlichen CursorLocation, LockType, Persist Security Info, CursorLocation experimentiert, arbeite in meiner SP (in der die Query steckt) mit with (nolock), es bleibt immer gleich. (Auch aus dem Query Analyzer rufe ich die "Exec Storedprocedure auf".
Hat jemand einen Tip?
Oder vielleicht eine gänzlich andere Idee des Datenzugriffs?
Als Background-Info: Der Webserver, der auch die hier verwendete asp-Seite hat, hat viele Skripte, die alle das eine eingebundene Datenzugriffsskript verwenden, und das Connection-Objekt müsste eigentlich woederverwendet werden. Es gibt pro Sekunde 100e Datenzugriffe, und alle sind schnell, außer diesem einen, und auch nur dann, wenn ich bestimmte Zeitbereiche aus dieser einen Tabelle aufrufe.
DANKE erstmal fürs Lesen bis hierher
und noch viel mehr Danke für Tips.
Schönen Gruß aus Schweinfurt
Der Titel für den Thread ist weng schwierig zu wählen, weil auch das Problem ziemlich merkwürdig ist - ich versuche es mal genau zu erklären:
Ich habe hier eine MSSQL-Datenbank. Es geht um eine Tabelle, in der ca. 70 Millionen Datensätze sind. Indizes sollten auch ganz gut gewählt sein. In der Datenbank befinden sich Daten mit einem Zeitstempel von verschiedenen Hardware-Geräten, zurück bis Anfang 2008.
Jetzt muss ich aus diesen ganz vielen Datensätzen Daten für ein bestimmtes Gerät und einen ganz bestimmten Tag herausfischen.
Dies mache ich in einer asp-Webseite, weil es Client-Programme gibt, die diese Daten ständig anfordern. (Code weiter unten). Was allermeistens gefragt wird, sind die Daten sagen wir mal 2 Wochen zurück. Das geht dann innerhalb von 0,5 bis 1 Sekunde. Es werden also ständig Daten von den unterschiedlichen Geräten angefordert, die sich im Bereich von jetzt 2 Wochen zurück befinden. Je weiter die Daten zurückliegen, desto seltener werden die angefragt.
Jetzt kommt mein Problem:
Ich möchte jetzt Daten eines Tages aus dem Januar 2008 abfragen, und das dauert so lange, dass der Servertimeout (120 Sekunden oder so) nicht ausreicht. Nehme ich allerdings die von der Webseite aufgerufene Query gebe die im Query-Analyzer ein und erfrage die Daten damit, geht das innerhalb von nicht mal einer halben Sekunde.
Es sieht also so aus, dass die Abfragen, egal über welchen Zeitraum, aus dem Query-Analyzer heraus immer nicht mal ein halbe Sekunde dauern, aus der asp-Seite heraus aufgerufen, umso länger dauern, je weiter sie zurückliegen.
Während ich das schreibe und diesen Zusammenhang formuliere, könnte es evtl. sein, dass es umso länger dauert, je seltener Bereiche der Tabelle aus dem Skript heraus aufgerufen (und vielleicht gecached) werden?
Bin auf jeden Fall völlig ratlos, wie ich an dieses Problem herangehen soll. Die Indizierung der Tabelle scheint ja zu passen, weil ich an die Daten extrem flott herankomme.
Hier mein Code:
Code:
Dim sConnect Dim odb,rs,sQry sConnect = "Provider=SQLOLEDB.1;Persist Security Info=False;" sConnect = sConnect & "User ID=benutzer;" sConnect = sConnect & "Initial Catalog=datenbank;" sConnect = sConnect & "Data Source=serverip;" sConnect = sConnect & "Password=passwort;" Set odb = Server.CreateObject("ADODB.Connection") odb.ConnectionString = sConnect odb.CursorLocation = 2 On Error Resume Next odb.Open If Err <> 0 Then echo "No Connect",1 Exit Function End If Set rs = server.CreateObject("ADODB.Recordset") rs.ActiveConnection = odb rs.CurosrType=0 rs.LockType=1 rs.CursorLocation=2 rs.Source = "Exec Storedprocedure" odb.CommandTimeout = 60 On Error Resume Next rs.Open If Err <> 0 Then echo "Fehler beim Ausführen der Query" Exit Function End If
Hat jemand einen Tip?
Oder vielleicht eine gänzlich andere Idee des Datenzugriffs?
Als Background-Info: Der Webserver, der auch die hier verwendete asp-Seite hat, hat viele Skripte, die alle das eine eingebundene Datenzugriffsskript verwenden, und das Connection-Objekt müsste eigentlich woederverwendet werden. Es gibt pro Sekunde 100e Datenzugriffe, und alle sind schnell, außer diesem einen, und auch nur dann, wenn ich bestimmte Zeitbereiche aus dieser einen Tabelle aufrufe.
DANKE erstmal fürs Lesen bis hierher
und noch viel mehr Danke für Tips.
Schönen Gruß aus Schweinfurt
Comment