ich hoffe sehr mir kann wer weiterhelfen, da ich etwas am verzweifeln bin.
Wir setzten den SBS08 Enterprise mit der dazu gehörigen SQL 08 Datenbank auf dem SBS08 ein.
Der SBS ist eine VM von ESXi4.0 mit 12 GB RAM und 4x2,93GHz
Die Mitarbeiter arbeiten auf einem Terminal Server mit Windows 2008 Standard 24GB RAM und 4x2,93GHz.
Der SBS und der TS laufen auf getrennten physikalischen Maschinen und sind über einen SWITCH mit 1 GB-LAN verbunden.
Zum Problem:
Wir setzten eine Software ein, welche auf MSACCESS 2003 aufbaut. Die Datenbank dieser Software liegt auf dem SQL 2008 Server.
Sobald ein User eine "größere" Anfrage an die Datenbank stellt, dauert dies im Durchschnitt 2,5min was jedoch nicht normal ist.
Nun suche ich eine Möglichkeit festzustellen, an welcher stelle die Anfrage so lange dauert (SQL Verbindungsaufbau? Datenabfrage?..)
Gibt es eine Möglichkeit dies Life über den SQL Server zu beobachten?
Dazu gibt es ja auch den Analyseservice, welchen ich gerne einmal über die SQL Datenbank laufen lassen würde. Jedoch verstehe ich diesen leider nicht so ganz.
Verstehe ich das so richtig:
Man muss manuell eine SQL Abfrage erstellen (z.B die Abfrage nach Kundendaten), diese wird in den Analyse Dienst geladen und so lange durch gelaufen wie man es bei der Konfiguration angibt. Darauf hin startet der Dienst eine Auswertung und sagt "dies jenes und das" kann/sollte geändert werden?
Wie schon erwähnt bin ich leider ein Anfänger in SQL und würde notfalls auch auf einen empfohlenen SQL Experten zurück greifen, hoffe jedoch dies wird nicht von Nöten sein und das mir hier wer ein paar hilfreiche Tipps geben kann.
Wenn Du eine Abfrage im SQL-Server Manager geöffnet hast, kannst Du Abfragen analysieren lassen. Auch der geschätzte Ausführungsplan ist bestimmt interessant.
Wo liegen die Abfragen jetzt? In Access? Wenn ja, dann solltet ihr die in den SQL-Server verlagern, der kann dann die Ressource vom Server richtig nutzen. Dazu brauchts aber jemanden, der Ahnung davon hat.
wie die anderen schon richtig sagen, kann das Problem lang laufender Abfragen an vielen verschiedenen Stellen liegen. Um dort wirklich zu analysieren und zu optimieren, brauchst du i.d.R. sehr tiefe SQL-Server-Kenntnisse.
Es kann sein, dass einfach Indizes fehlen. Hier könnte dir der angesprochene Assistent evtl. nützliche Hinweise geben. Es kann aber auch sein, dass die Abfrage schlicht schlecht gebaut ist, dann kann nur der Autor der Abfrage etwas daran ändern.
Die 4 CPUs sind die virtuellen CPUs, die du der VM zugewiesen hast? Was läuft sonst noch auf dem Host? Auch in der CPU-Zuweisung kann eine Performancebremse liegen: Wenn eine VM mit 4 CPUs ausgestattet ist, kann der Hypervisor der VM nur dann Rechenzeit zuweisen, wenn gerade 4 CPUs frei sind. Bei ungünstiger VM-Konfiguration kann es dazu kommen, dass die VM dann über mehrere Zyklen nicht berücksichtigt wird ...
Zusätzlich zu den schon gemachten Angaben noch folgende Tipps:
Zu deiner Frage (Gibt es eine Möglichkeit dies Life über den SQL Server zu beobachten?):
Bei Deiner Version des SBS ist meiner Meinung nach der SQL Server Profiler
mit dabei. Den findest Du im Management Studio unter "Tools".
Mit diesem Profiler kannst du mitschneiden, was direkt auf dem SQL Server läuft (aber eben nur dort). Je nach Einstellung werden Dir dort die SQL Abfragen life angezeigt.
Zur Verwendung findest Du im Internet ein feines Ebook:
--> Bei Google nach "Mastering Profiler eBook" suchen.
Den Mitschnitt kannst Du dann abspeichern und gegen den "Database Engine Tuning Advisor" laufen lassen.
Der macht Dir dann Vorschläge zur Verbesserung der Datenbank (Indexe, Statistiken, etc.).
Bevor Du diese anwendest, unbedingt Rücksprache mit dem Softwarehersteller halten.
Des Weiteren ist es möglich, die Profilerdatei mit dem Performance Monitor
zusammenzulegen (Siehe eBook). Dann siehst Du, bei welcher Abfrage welche Performance Counter sich wie verhalten.
Dies kann bei der Suche nach dem Bottleneck hilfreich sein. Die interessanten Performance Counters findest Du bei Microsoft
im Technet.
Wenn Du noch mehr Angaben brauchst, einfach posten.
