Hallo zusammen,
ich habe folgendes Problem derzeit:
Ich habe Laptops (Clients) auf denen per Merge Replikation eine verkleinerte Version der Hauptdatenbank aus einer Zentrale landet. Auf den Clients läuft der SQLExpress 2008 R2.

Die Clients werden natürlich immer wieder Heruntergefahren und irgendwann später wieder gestartet.
Die Anwendung, welche auf die lokale SQLExpress Datenbank zugreift, läuft beim Starten allerdings in TimeOuts, da die ersten Abfragen auf die Datenbank zu lange brauchen.

Ich habe das ganze einmal mit dem Management Studio versucht nach zu vollziehen. Es gibt bei uns einige gespeicherte Prozeduren, welche Joins über 5-6 Tabellen machen, welche recht groß sind (160.000 Einträge und mehr), diese Abfragen brauchen bei der ersten Ausführung bis zu 4 Minuten und man hört ganz deutlich wie die kleine Festplatte des Laptops am rattern ist ;)
Bei jeder weiteren Abfrage danach dauert es dann aber nur noch wenige Sekunden.
Starte ich den Dienst neu, dauert die Abfrage wieder 4 Minuten.
Ich nehme mal an (bin mir da aber auch nicht sicher) das der Server bei den ersten Abfragen auf die Tabellen diese speziell vorbereitet und in eine Art Cache lädt.
Die Abfrage um die es hier geht, beinhaltet laut Ausführungsplan, nur Clustered Index Seeks oder Key Lookups, das Problem scheint mir nur in der Menge der Einträge zu liegen (die ich auch nicht verkleinern darf, da die Clients diese Datenmenge brauchen).

Als Lösungsansatz hatte ich die Idee gehabt einfach ein Startup Script zu schreiben, welches beim Rechner Start dann einfach in der lokalen Datenbank ein paar dieser Prozeduren aufruft. Jedoch bin ich der Meinung das es doch sicher bessere Möglichkeiten gibt. Gibt es den eine Möglichkeit auf dem SQLExpress da für mehr Performance zu sorgen?

Gleich vorweg: Die Datenbank ist sauber modelliert und strukturiert. Es wurden sinnvolle Verknüpfungen, Indexe, etc... gesetzt. An der Datenbank Struktur kann ich nur schwer Änderungen vor nehmen, da die Datenbank unter Replikation steht, ich kann also eigentlich nur den Inhalt anpassen, bzw die Client Server konfigurieren.

Vllt. weiß ja hier jemand Rat, oder kann mir zumindest einmal erklären, warum das so langsam ist, liegt das an der Express Edition oder wäre das auch bei einem richtigen MS SQL Server so, der gerade frisch gestartet wurde?

Vielen Dank für eure Hilfe
Chris

Edit - weitere Details (IO und Time Statistics):

Ausführungsplan: http://img10.imageshack.us/img10/6022/abfrage.png

Okey herrausgekommen ist dabei das hier:

SQL Server parse and compile time: 
   CPU time = 31 ms, elapsed time = 546 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

(0 row(s) affected)
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'PERSON'. Scan count 0, logical reads 819522, physical reads 7774, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'ANTRAG'. Scan count 10, logical reads 410004, physical reads 12625, read-ahead reads 214, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CATALOGS'. Scan count 1, logical reads 2, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'KONTAKT'. Scan count 0, logical reads 2, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 8141 ms,  elapsed time = 207828 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

PERSON umfasst ca 126.000 Datensätze, ANTRAG hat ca. 136.000 Datensätze.
Führe ich die Abfrage nocheinmal aus kommt es zu diesem Ergebnis:

SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

(0 row(s) affected)
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'PERSON'. Scan count 0, logical reads 819522, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'ANTRAG'. Scan count 10, logical reads 410004, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CATALOGS'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'KONTAKT'. Scan count 0, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 2500 ms,  elapsed time = 2500 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

Der Abfrageplan zeigt, zwei Dinge: 1. Nur seeks 2. Angeblich extrem wenige Rows. Du hast folglich ein Statistikproblem: Der Optimizer denkt, deine Tabellen sind fast leer, weshalb die loop joins auch optimal wären. Führe folgendes Statement aus:

EXEC sp_updatestats

Und berichte von den Ergebnissen!

Also folgende 2 Probleme konnten identifiziert werden.

1. Deine Festplatte ist das Problem. Es werden etwa 10.000 Festplattenzugriffe getätigt. Da du in deinem Laptop nur eine Festplatte drin hast (und diese somit auch von anderen Prozessen verwendet wird) und Notebook-Festplatte eh. etwas langsamer sind gehe ich mal von 18-20 ms pro Read aus wodurch du auf die 207s Execution kommst. Davon gehen nochmal 0,5 Sekunden fürs Compilieren und Optimieren weg was aber nicht ins Gewicht fällg. Die Anzahl der "read-ahead reads" ist sehr gering weswegen ich empfehle mit dem Tool Contig von Sysinternals (Microsoft) das Datenbank-File zu defragmentieren. Das sollte den ganzen Lesevorgang beschleunigen.

2. Deine Indexe sind nicht optimal. Nach einer Optimierung sollten diese die Anzahl der Lesezyklen auf der Festplatte deutlich verkleinern. Sollte also der Schritt 1 (Defragmentieren des Datenbankfiles) nicht das gewünschte Ergebnis bringen , mach bitte folgendes.
Wiederhole bitte den Vorgang von eben nochmal, lass dir die Ausführungspläne anzeigen und speichere diese als XML ab. Schick Sie mir dann bitte und ich kann Sie bei mir wieder einlesen und sie betrachten. Dann kann ich dir ein paar konkrete Optimierungsvorschläge machen.