Ich habe eine Entwicklungs- und eine UAT-Umgebung. Dev ist bei uns, UAT ist beim Kunden.
Unsere DEV-Maschine ist ein XEON 4 Kern @2,33GHz, 4Go RAM mit Windows Server 2003 Der physische UAT-Rechner ist derselbe, aber es wird ein virtueller Rechner verwendet (unter VMWare). Ich weiß nicht, die genauen Parameter für diese VM verwendet.
Das Problem ist, dass der SQL Server auf dem Entwicklungsrechner sehr gut läuft und der auf dem UAT-Rechner sehr, sehr langsam ist.
Das Öffnen von SQL Server Management Studio dauert auf dem UAT-Rechner 2 Minuten. Auch das Ausführen einer einfachen Select-Anfrage ist sehr langsam. Die Datenbank ist recht klein (6 GB). Das Öffnen jeder anderen Anwendung auf diesem Server funktioniert problemlos.
Wir glauben also, dass es ein Problem mit der Sql-Server-Instanz gibt, und ich muss die Ursache dafür herausfinden.
Das habe ich überprüft:
- Die Konfiguration des Servers ist ähnlich wie die von DEV.
- genügend Speicherplatz auf der Festplatte vorhanden ist
- die Prozessoren sind nicht überlastet (10 % Auslastung ist die Höchstgrenze)
- Der Speicher scheint ebenfalls in Ordnung zu sein.
- Daten und Protokolldateien werden automatisch erweitert
- SQL Server-Wiederherstellungsmodell: FULL
Im Datenbankprotokoll scheint dieser Fehler mindestens einmal aufgetreten zu sein (ich habe nur Zugriff auf einen kleinen Teil):
2008-10-14 19:16:54.84 spid55
Autogrow der Datei 'xxxxx_log' in Datenbank 'xxxxxx' wurde abgebrochen durch Benutzer abgebrochen oder nach 6766 Millisekunden abgebrochen. Verwenden Sie ALTER DATABASE, um einen kleineren FILEGROWTH-Wert für diese Datei für diese Datei oder setzen Sie explizit eine neue Dateigröße festzulegen.
Da genügend Speicherplatz auf der Festplatte vorhanden ist, was könnte die Ursache sein? Könnte es mit meinem Perfs-Problem zusammenhängen? Was sollte ich überprüfen, um die Ursache des Problems zu finden?
Ich bin kein SqlServer-Experte, also wenn jemand einen Vorschlag hat, würde ich ihn gerne hören. Danke!
Update 1 :
SQL Server-Wiederherstellungsmodell: FULL
Die Datenbank ist neu, daher haben wir bisher keine Sicherungskopie erstellt.
Ich kenne die Größe der Protokolldatei nicht, ich werde das überprüfen.
Update 2 :
Das Problem mit Management Studio ist gelöst.
Die Ursache liegt darin, dass auf dem Server kein Internetzugang vorhanden ist und dass Management Studio beim Starten von : http://weblogs.sqlteam.com/tarad/archive/2006/10/05/13676.aspx
Aber es scheint, dass das Perf-Problem nicht mit diesem Problem zusammenhängt. Ich suche noch.
