Umgang mit großen Datenmengen

[dexter]

Hallo,
ich habe ein Problem mit der Abfragegeschwindigkeit über eine sehr große Tabelle. Alles was ich bisher ausprobiert habe liefert nicht die gewünschte Antwortzeit von unter 2 Sekunden.

Die Tabelle ist wie folgt aufgebaut:
Company | File | Date | Hits
Die Tabelle enthält ca. 2.200.000 Datensätze. Dort enthalten sind Daten für ein Jahr. Es kommen täglich ca. 30.000 Datensätze hinzu, mit aktuellem Datum. Alte Daten bleiben erhalten und ändern sich nicht. Die Hits für einen File sind tageweise zusammengefasst.

Die Abfragen sollen das Ergebins liefern, welche Files wie oft für eine bestimmte Company in einem bestimmten Zeitraum aufgerufen wurden. Die Auflistung der Daten soll nach den meisten Hits erfolgen. Abfragen die über mehrere Monate gehen sind dabei nicht unüblich.

Da ich ein Paging auf der Anzeigeseite (ASPX-Seite) einbauen möchte, muss also auch noch ein Ranking im SQL Statement erfolgen.
Es wäre kein Problem die Daten bei der ersten Anfrage aufzubereiten und dann für die nächsten Seiten zur Verfügung zu haben. Sodass ein schneller Seitenwechsel auf der ASPX-Seite vollziehbar wäre.

Ich wäre dankbar, wenn ich einen Hinweis bekommen könnte in welcher Richtung ich weiter vorgehen kann. (Analysis Services, Reporting Services oder Datamining?)

[Rumtata]

Hi,

Die Tabelle ist wie folgt aufgebaut:
Company | File | Date | Hits
Die Tabelle enthält ca. 2.200.000 Datensätze. Dort enthalten sind Daten für ein Jahr. Es kommen täglich ca. 30.000 Datensätze hinzu, mit aktuellem Datum. Alte Daten bleiben erhalten und ändern sich nicht. Die Hits für einen File sind tageweise zusammengefasst.

Zuerst sind 2.5 Millionen Datensätze nicht unbedingt sonderlich viel, so dass ich mal vermute, dass wahrscheinlich kein Schlüssel für die Abfrage verwendet wird und der Server jedesmal einen Table Scan hinlegen muss ( lesen jedes Datensatzes ). Deshalb würde ich zuerst mal den "Database Engine Tuning Advisor" anwenden. Der ist über das Mangement Studio unter Tools erreichbar und kann Dir erste Anhaltspunkte geben, welcher zusätzliche Schlüssel der Datenbank bei der Abfrage helfen würde ...

Da ich ein Paging auf der Anzeigeseite (ASPX-Seite) einbauen möchte, muss also auch noch ein Ranking im SQL Statement erfolgen.
Es wäre kein Problem die Daten bei der ersten Anfrage aufzubereiten und dann für die nächsten Seiten zur Verfügung zu haben. Sodass ein schneller Seitenwechsel auf der ASPX-Seite vollziehbar wäre.

Ich wäre dankbar, wenn ich einen Hinweis bekommen könnte in welcher Richtung ich weiter vorgehen kann. (Analysis Services, Reporting Services oder Datamining?)

Was Paging angeht, gibt es im SQL Server 2005 folgende Möglichkeit:
http://www.davidhayden.com/blog/dave...2/30/2652.aspx

HTH,
Karsten

[dexter]

Hallo Karsten,
danke für die schnelle Antwort.

Der Query plan zeigt mir eine 90%-ige Inanspruchnahme eines Index Scan. Der Primary Key der Tabelle setzt sich zusammen aus Company, Date und File. Das ist auch gleichzeitig mein Clustered Index. Der Tuning Advisor liefert mir keine weiteren Vorschläge zur Optimierung.

[Rumtata]

Dann wäre es jetzt gut, wenn Du die Struktur der Tabelle inkl. derer Indizes und Deine Abfrage posten könntest, vielleicht fällt ja etwas ins Auge ...

Gruß,
Karsten

[ebis]

Dann wäre es jetzt gut, wenn Du die Struktur der Tabelle inkl. derer Indizes und Deine Abfrage posten könntest, vielleicht fällt ja etwas ins Auge ...

Gruß,
Karsten

den Queryplan kann er ja auch gleich mit posten...

[Andreas Kosch]

Hallo,

Der Primary Key der Tabelle setzt sich zusammen aus Company, Date und File.

wie viele Zeichen ist diese Kombination lang? Ein zusammengesetzter Primärschlüssel verträgt sich in der Regel nicht mit den höheren Ansprüchen an die Performance, wenn der PK an andere Stelle auch als Fremdschlüssel in der Datenbank auftaucht ;-)

Meine "üblichen Verdächtigen" stehen auf der folgenden Checkliste (d.h. die einzelnen Punkte sollten erfüllt werden):

1. Datenbank- und LOG-dateien nicht auf einem RAID5, sonder statt dessen RAID10
2. Logdatei auf einer anderen Festplatte bzw. Festplatten-Array als die Datenbankdatei
3. Historische (d.h. alte, nicht mehr benötigte) Daten in eine Tabelle auslagern, die auf einer anderen FILEGROUP liegt, wobei diese FILEGROUP auch auf einer separaten Platte untergebracht wird (d.h. die historischen Daten belasten den Datenbank-Cache nicht mehr).
4. tempdb-Systemdatenbank auf 2 separaten Festplatten (Datenbankdatei und Log getrennt), die tempdb-Datenbank sollte auf der schnellsten (!) Festplatte bzw. dem schnellsten Array liegen.
5. ensprechender RAM-Ausbau (Datenbank-Cache)
6. Standalone-Maschine nur für den MS SQL Server

P.S: Erst das Setup vom MS SQL Server 2008 stellt von Anfang an die Konfiguration der verschiedenen Laufwerke zur Verfügung:

• Wurzelverzeichnis für die Daten
• Verzeichnis für Benutzerdatenbanken
• Verzeichnis für die Logdateien der Benutzerdatenbanken
• Verzeichnis für die die tempdb-Systemdatenbank
• Verzeichnis für die Logdateien der tempdb-Systemdatenbank

Beim MS SQL Server 2000/2005 muss das der DBA noch nachträglich von Hand erledigen.