10
SQL-Server 2008 Wartung - Performanceprobleme
Hallo Zusammen,
ich habe hier ein DMS-System laufen (Accantum), welches auf einer SQL 2008 Datenbank schreibt.
Nun bekomme ich in letzter Zeit immer mehr Probleme, was die Performance angeht. Bei einer Suche eines Dokuments im Frontend bekomme ich hohe CPU-Lasten (90% und höher), die kurz andauern und dann entsprechend natürlich alles verlangsamen. Ich habe leider bisher absolut gar nichts mit SQL-Servern und -Datenbanken am Hut gehabt, daher sind meine Kentnisse bisher hier relativ bescheiden.
Ressourcen habe ich bereits erweitert, die VM hat 32 GB ram und 8 Kerne.
Das DB-Verzeichnis bringt folgende Größen zum Vorschein.
Es ist ein Maintanance-Plan hinterlegt (wobei hier beim ersten Task keine Verbindung angegeben ist):
Gesichert wird mit Veeam, SQL Log Trunking ist eingeschaltet.
Kann mir jemand helfen die nötigen Schritte auszuführen, damit die Datenbank wieder flott läuft?
Vielen Dank!
ich habe hier ein DMS-System laufen (Accantum), welches auf einer SQL 2008 Datenbank schreibt.
Nun bekomme ich in letzter Zeit immer mehr Probleme, was die Performance angeht. Bei einer Suche eines Dokuments im Frontend bekomme ich hohe CPU-Lasten (90% und höher), die kurz andauern und dann entsprechend natürlich alles verlangsamen. Ich habe leider bisher absolut gar nichts mit SQL-Servern und -Datenbanken am Hut gehabt, daher sind meine Kentnisse bisher hier relativ bescheiden.
Ressourcen habe ich bereits erweitert, die VM hat 32 GB ram und 8 Kerne.
Das DB-Verzeichnis bringt folgende Größen zum Vorschein.
Es ist ein Maintanance-Plan hinterlegt (wobei hier beim ersten Task keine Verbindung angegeben ist):
Gesichert wird mit Veeam, SQL Log Trunking ist eingeschaltet.
Kann mir jemand helfen die nötigen Schritte auszuführen, damit die Datenbank wieder flott läuft?
Vielen Dank!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 397925
Url: https://administrator.de/contentid/397925
Printed on: April 19, 2024 at 02:04 o'clock
10 Comments
Latest comment
Moin,
so wie das aussieht wurden bei deinem SQL-Server nichtmal die grundlegenden Best Practices eingehalten (DB+Log auf unterschiedl. Disks, tempDB nicht auf eigener Disk z.b.). Evtl wäre es sinnvoll dich als erstes mit dem Support der Applikation und dann ggfs. mit einem Systemhaus (mit SQL Expertise)zu sprechen um dann zusammen die Optimierung des Servers anzugehen.
Abgesehen davon fehlt einiges an Information. Anzahl User, Disk Subsystem und IO Last usw, usw.
lg,
Slainte
so wie das aussieht wurden bei deinem SQL-Server nichtmal die grundlegenden Best Practices eingehalten (DB+Log auf unterschiedl. Disks, tempDB nicht auf eigener Disk z.b.). Evtl wäre es sinnvoll dich als erstes mit dem Support der Applikation und dann ggfs. mit einem Systemhaus (mit SQL Expertise)zu sprechen um dann zusammen die Optimierung des Servers anzugehen.
Abgesehen davon fehlt einiges an Information. Anzahl User, Disk Subsystem und IO Last usw, usw.
lg,
Slainte
hi
mit den infos kommen wir nicht sonderlich weit.
Dein erster Ansprechpartner sollte der Support des DMS-Systems sein.
Wenn du dich selbst ein bisschen schlau machen willst:
Schau am einfachsten mal in den SSMS Activity Monitor und prüfen, welches Query da so lange braucht.
Dann suchst du dessen Tabellen und lässt seine Indexe mal neu erstellen.
Wenn das nix bringt, musst du mit dem QueryPlanAnalyzer gucken was an dem Query so langsam ist:
https://blogs.msdn.microsoft.com/sql_server_team/new-in-ssms-query-perfo ...
Und dann kommts halt drauf an was es ist....
mit den infos kommen wir nicht sonderlich weit.
Dein erster Ansprechpartner sollte der Support des DMS-Systems sein.
Wenn du dich selbst ein bisschen schlau machen willst:
Schau am einfachsten mal in den SSMS Activity Monitor und prüfen, welches Query da so lange braucht.
Dann suchst du dessen Tabellen und lässt seine Indexe mal neu erstellen.
Wenn das nix bringt, musst du mit dem QueryPlanAnalyzer gucken was an dem Query so langsam ist:
https://blogs.msdn.microsoft.com/sql_server_team/new-in-ssms-query-perfo ...
Und dann kommts halt drauf an was es ist....
1
Hi
1. man verkleinert eine DB nur im Worstcase oder nachdem man große Tabellen gelöscht hat, ansonsten sollte man das, vor allem bei der geringen Größe einfach lassen, die Meldung sagt ja bereits aus das es zu Fragmentierung kommt
2. AutoGrow am besten niemals auf % Bereiche stellen, idealerweise auf MB/GB Größen die eine neue Speicherzuweisung nicht so oft erforderlich machen, z.B. 10GB
3. Analysiere die Index-Einstellungen der Datenbank, oft werden seitens der "Hersteller" viele Tabelle mit falschen und gar keinen Indicies ausgestattet und die Abfragen laufen dann richtig kacke (KoFAX z.B. ist in der Grundeinstellung extrem beschisxxxx da muss man einiges von Hand nachsetzen damit das Schnell läuft)
4. Datenbanken verkleinert man nicht - wenn dann einmal und nicht über den Wartungsplaner
5. Anzahl TempDB = Anzahl maximaler Workerthreads, d.h. 8 Cores = 8 DB Files und diese auf schnellen Platten
6. Logs und DB File auf getrennten Laufwerken (nicht nur Partitionen - eigene Storagepfade zu den LUNS)
7. Man verkleinert keine DB's, maximal im Einzelfall (bin mir gerade nicht sicher ob ich das nicht schon geschrieben habe)
Besorg dir von Brent Ozar die SP Blitz Tools (https://www.brentozar.com/blitz/) , das wird auch schon einiges helfen - auch weiteren Fehlern auf die Schliche zu kommen.
Just my 2 Cent
@clSchak
1. man verkleinert eine DB nur im Worstcase oder nachdem man große Tabellen gelöscht hat, ansonsten sollte man das, vor allem bei der geringen Größe einfach lassen, die Meldung sagt ja bereits aus das es zu Fragmentierung kommt
2. AutoGrow am besten niemals auf % Bereiche stellen, idealerweise auf MB/GB Größen die eine neue Speicherzuweisung nicht so oft erforderlich machen, z.B. 10GB
3. Analysiere die Index-Einstellungen der Datenbank, oft werden seitens der "Hersteller" viele Tabelle mit falschen und gar keinen Indicies ausgestattet und die Abfragen laufen dann richtig kacke (KoFAX z.B. ist in der Grundeinstellung extrem beschisxxxx da muss man einiges von Hand nachsetzen damit das Schnell läuft)
4. Datenbanken verkleinert man nicht - wenn dann einmal und nicht über den Wartungsplaner
5. Anzahl TempDB = Anzahl maximaler Workerthreads, d.h. 8 Cores = 8 DB Files und diese auf schnellen Platten
6. Logs und DB File auf getrennten Laufwerken (nicht nur Partitionen - eigene Storagepfade zu den LUNS)
7. Man verkleinert keine DB's, maximal im Einzelfall (bin mir gerade nicht sicher ob ich das nicht schon geschrieben habe)
Besorg dir von Brent Ozar die SP Blitz Tools (https://www.brentozar.com/blitz/) , das wird auch schon einiges helfen - auch weiteren Fehlern auf die Schliche zu kommen.
Just my 2 Cent
@clSchak
1
Hallo,
32 GB Ram hört sich gut an, die DB ist aber dreimal so groß und keiner weiß, was sonst noch so auf dem Server passiert.
Ist das IO-Subsystem zusätzlich lahm, ist schnell Feierabend.
Der Wartungstask ist nicht gut - man sollte nur in Notfallsituationen produktive DB-Files verkleinern. Das Transaction Log kann abgeschnitten, das Datenwachstum überwacht werden.
Gruss Grinskeks
32 GB Ram hört sich gut an, die DB ist aber dreimal so groß und keiner weiß, was sonst noch so auf dem Server passiert.
Ist das IO-Subsystem zusätzlich lahm, ist schnell Feierabend.
- Grundperformance IO-Subsystem messen, insbesondere 8k und 4k Iops (Crystaldiskmark)
- Perfmon ausführen und avg. Disk Queue Length und Buffer cache hit ratio messen
- Perfmon standardbericht performance ausführen, wenn gerade was los ist auf dem Server
Der Wartungstask ist nicht gut - man sollte nur in Notfallsituationen produktive DB-Files verkleinern. Das Transaction Log kann abgeschnitten, das Datenwachstum überwacht werden.
Gruss Grinskeks
Moin,
wenn Du Deine DBs schon pflegen willst, solltest Du den Wartungsplan folgende Schritte ausführen lassen:
1. Datenbank Integrität prüfen
2. Index neu erstellen
3. Verlauf bereinigen
Hier kann ich Dir gerne eine Anleitung zukommen lassen. PM an mich, dann schicke ich sie Dir.
Ansonsten sollte man die DBs schrittweise vergrößern, wie oben vorgeschlagen, angepaßt an das Wachstum.
Wenn eine DB je Woche um 500MB wächst, dann kann man die natürlich immer um 500MB vergrößern, doch das kostet Leistung.
Lieber 5GB nehmen und danach wieder ausreichend Reserve haben.
Ansonsten gehören LogFiles und DB-Files auf getrennte Volumes. Und schnelle Platten haben SQL-DBs auch noch nie geschadet.
Gruß
Looser
wenn Du Deine DBs schon pflegen willst, solltest Du den Wartungsplan folgende Schritte ausführen lassen:
1. Datenbank Integrität prüfen
2. Index neu erstellen
3. Verlauf bereinigen
Hier kann ich Dir gerne eine Anleitung zukommen lassen. PM an mich, dann schicke ich sie Dir.
Ansonsten sollte man die DBs schrittweise vergrößern, wie oben vorgeschlagen, angepaßt an das Wachstum.
Wenn eine DB je Woche um 500MB wächst, dann kann man die natürlich immer um 500MB vergrößern, doch das kostet Leistung.
Lieber 5GB nehmen und danach wieder ausreichend Reserve haben.
Ansonsten gehören LogFiles und DB-Files auf getrennte Volumes. Und schnelle Platten haben SQL-DBs auch noch nie geschadet.
Gruß
Looser
Hi,
32 GB RAM muss man schauen: Durch index rebuild etc. wird der höchstens in Anspruch genommen. Nach Neustart des Dienstes hast du meist nur einen Bruchteil. Nicht die gesamte DB wird komplett in RAM ausgelagert.
Die Frage ist, wenn es bisher lief, ob es wirklich an der H/W, Konfig liegt! Ggf.ist mal was in die Binsen gegangen und du hast einen Nullsatz, etc. in einer Tabelle.
Du kannst mit dem SQL Profiler mit T_Replay die Abfregen mitschneiden. So könntest du auch mal kucken, was an dem Auslösen im Frontend denn wirklcih psasiert. Welche Prozeduren etc. angesprochen werden.
Trivial: Wenn es normal läuft und nur bei Abfragen hängen bleibt, ist ggf. die DB nicht mehr ganz in Takt. Im Profiler sieht man gut die Statements und dauch die Zeitdauer. Man kann auch einfach sp_execute in Abfrege Window kopieren und separat starten. ABER dafür sollte man die SQL Grundlagen können! Query ist meist kein Problem. Update und Insert Statements auf gut Glück aufs neue ausführen ist Mist.
Manchmal werden auch Trigger ausgelöst die wiederum andere Prozeduren anstoßen....
Was ist mit der Frontend App? Läuft die auch auf dem DB Server oder nur die Datenbank? Ist denn also überhaupt die sqlserver.exe am CPU Limit oder meinetwegen Dotnet, etc. an sich?
Wenn Ihr App + DB nicht getrennt habt wäre die Frage: Welcher Prozeß istam LImit??
Bei letzteren wärst du beim SQL Server nicht ganz falsch. Da auch hier durch Inskonsitente DB und Tabellen die Anwendung so austillen könnte, dass sie alles mit sich reisst!
Sicherung ist schon mal gut. Mit Veeam ist so ne Sache! Würde alternativ IMMER die DB direkt über den Server sichern. Geht im Online Betrieb und die DB bleibt intakt.
Google hilft dir dabei. Auch beim 2008er schluckt es UNC Pfade. Werden nur nich anzgeit. So kannst die einfach die BAK an anderen Ort ablegen. Nur Veeam wäre mir zu heikel!
Habt Ihr einen Wartungsvertrag? Ggf. frag doch die Progger bei Accantum direkt an, ob Sie via Remote mal drauf schauen können. Die kennen Ihren eigenen Code und sehen auch rasch wo es hängt!
Und ohne Vertrag dürften 30-60 min. Remote Support nicht all zu teuer sein.
Muss man immer Ausfallzeiten und Nutzen gegen rechnen. Oft hilft ein kleiner Anruf. ;)
mfg Crusher
32 GB RAM muss man schauen: Durch index rebuild etc. wird der höchstens in Anspruch genommen. Nach Neustart des Dienstes hast du meist nur einen Bruchteil. Nicht die gesamte DB wird komplett in RAM ausgelagert.
Die Frage ist, wenn es bisher lief, ob es wirklich an der H/W, Konfig liegt! Ggf.ist mal was in die Binsen gegangen und du hast einen Nullsatz, etc. in einer Tabelle.
Du kannst mit dem SQL Profiler mit T_Replay die Abfregen mitschneiden. So könntest du auch mal kucken, was an dem Auslösen im Frontend denn wirklcih psasiert. Welche Prozeduren etc. angesprochen werden.
Trivial: Wenn es normal läuft und nur bei Abfragen hängen bleibt, ist ggf. die DB nicht mehr ganz in Takt. Im Profiler sieht man gut die Statements und dauch die Zeitdauer. Man kann auch einfach sp_execute in Abfrege Window kopieren und separat starten. ABER dafür sollte man die SQL Grundlagen können! Query ist meist kein Problem. Update und Insert Statements auf gut Glück aufs neue ausführen ist Mist.
Manchmal werden auch Trigger ausgelöst die wiederum andere Prozeduren anstoßen....
Was ist mit der Frontend App? Läuft die auch auf dem DB Server oder nur die Datenbank? Ist denn also überhaupt die sqlserver.exe am CPU Limit oder meinetwegen Dotnet, etc. an sich?
Wenn Ihr App + DB nicht getrennt habt wäre die Frage: Welcher Prozeß istam LImit??
Bei letzteren wärst du beim SQL Server nicht ganz falsch. Da auch hier durch Inskonsitente DB und Tabellen die Anwendung so austillen könnte, dass sie alles mit sich reisst!
Sicherung ist schon mal gut. Mit Veeam ist so ne Sache! Würde alternativ IMMER die DB direkt über den Server sichern. Geht im Online Betrieb und die DB bleibt intakt.
Google hilft dir dabei. Auch beim 2008er schluckt es UNC Pfade. Werden nur nich anzgeit. So kannst die einfach die BAK an anderen Ort ablegen. Nur Veeam wäre mir zu heikel!
Habt Ihr einen Wartungsvertrag? Ggf. frag doch die Progger bei Accantum direkt an, ob Sie via Remote mal drauf schauen können. Die kennen Ihren eigenen Code und sehen auch rasch wo es hängt!
Und ohne Vertrag dürften 30-60 min. Remote Support nicht all zu teuer sein.
Muss man immer Ausfallzeiten und Nutzen gegen rechnen. Oft hilft ein kleiner Anruf. ;)
mfg Crusher
Habe mir jetzt mal die Fragmentierung angeschaut - wenn ich es richtig deute - dann habe ich vermutlich ein Problem zumindest aufgedeckt. Kann das damit zusammen hängen, da die Datenbank platte aus dynamischen Volumes besteht? Ich habe diese nicht angelegt, sondern die VMs übernommen und ensprechend vergrössert. Evtl. macht es Sinn hier statische Datenträger daraus zu machen? Und macht es Sinn diesen Komprimierungstask aus dem Wartungsplan rauszunehmen?
Nein, eine fragmentiert er Index hat nix mit einem fragmentiert en Datenträger zu tun.
Das bedeutet, das der Clustered Index schlecht gewählt ist und/oder die Wartung der Indexe nicht erfolgt.
Lass alle Indexe Mal neu erstellen, dann passt das wieder.
Beobachte dann, Welcher Index schnell wieder fragmentiert. Den muss man sich dann Mal ansehen und ggf korrigieren
Das bedeutet, das der Clustered Index schlecht gewählt ist und/oder die Wartung der Indexe nicht erfolgt.
Lass alle Indexe Mal neu erstellen, dann passt das wieder.
Beobachte dann, Welcher Index schnell wieder fragmentiert. Den muss man sich dann Mal ansehen und ggf korrigieren
Ich habe jetzt mal die hoch fragmentierten Indexe neu organisiert bzw. neu erstellen lassen.
3-4 Tabellen gehen kaum von der Fragmentierungsrate runter.
Die CPU-Last geht bei der SQLSERVER.exe dennoch hoch.
Das zeigt der Aktivitätenmonitor.
Besteht hier ein Problem mit der Tabelle DocumentPage?
Nachtrag:
Habe das Skript hier nochmal ausgeführt, das baut ALLE Indizies neu auf:
Nun scheint so, als würden die CPU-Last nicht mehr so hoch gehen bei suchen (nur ca. 15-20%, statt 95%)...
3-4 Tabellen gehen kaum von der Fragmentierungsrate runter.
Die CPU-Last geht bei der SQLSERVER.exe dennoch hoch.
Das zeigt der Aktivitätenmonitor.
Besteht hier ein Problem mit der Tabelle DocumentPage?
Nachtrag:
Habe das Skript hier nochmal ausgeführt, das baut ALLE Indizies neu auf:
DECLARE @Tabelle VARCHAR(255)
DECLARE @sql NVARCHAR(500)
DECLARE @faktor INT
SET @faktor = 80
DECLARE
TabellenZeiger CURSOR FOR
SELECT
OBJECT_SCHEMA_NAME([object_id])+'.'+name AS TableName
FROM
sys.tables
OPEN TabellenZeiger
FETCH NEXT FROM TabellenZeiger INTO @Tabelle
WHILE @@FETCH_STATUS = 0
BEGIN
SET @sql = 'ALTER INDEX ALL ON ' + @Tabelle + ' REBUILD WITH (FILLFACTOR = ' + CONVERT(VARCHAR(3),@faktor) + ')'
EXEC (@sql)
FETCH NEXT FROM TabellenZeiger INTO @Tabelle
END
CLOSE TabellenZeiger
DEALLOCATE TabellenZeiger
GONun scheint so, als würden die CPU-Last nicht mehr so hoch gehen bei suchen (nur ca. 15-20%, statt 95%)...
Laut Screenshot entsteht die Belastung ja beim Updatebefehl. Da müsste man Mal gucken was da schief läuft. Vermutlich ein sch... Index.
Auf welchen Feldern liegt denn der Clustered Index der Tabelle tbTempDocumentList ?
Auf welchen Feldern liegt denn der Clustered Index der Tabelle tbTempDocumentList ?
