TSQL Wartungsplan Blockierungen bei 24/7 Datenbanken

SuperKnuffel

Benutzer
Beiträge
6
Hallo in die Runde,

wie handhabt ihr Wartungspläne bei 24/7 aktiv genutzten Datenbanken?

Hintergrund ist folgender:

Der Wartungstask läuft los und baut die Indizes neu auf, aktualisiert die Statistiken usw. usf.
Soweit alles schön.

Allerdings wird die Datenbank permanent aktiv genutzt und die Aktionen führen zu massiven Blockierungen die darauf hinauslaufen das es Anwendungen in den Abgrund reißt.

Es gibt defakto kein wirkliches Zeitfenster in dem der Task "in Ruhe" durchlaufen kann.

Von der Größenordnung her geht es hier um Datenbankgrößen >40GB.

Vielen Dank für sachdienliche Tipps.
 
Werbung:
Ähm, 40GB ist ja eher klein, aber in dem Umfeld, wo ich bin, laufen Datenbanken 24/7 und die Maintenance-Sachen laufen ohne zu stören.
Ist aber kein M$SQL.
 
Ich würde mal ein paar Fragen in den Raum werfen:
Welche Tasks genau werden angeworfen und warum? (Rebuild all indices, ..)
Welche Server Version wird verwendet?

Und auch:
Welche Art von Operationen laufen dort 24/7?
 
Ich würde mal ein paar Fragen in den Raum werfen:
Welche Tasks genau werden angeworfen und warum? (Rebuild all indices, ..)
Welche Server Version wird verwendet?

Und auch:
Welche Art von Operationen laufen dort 24/7?
Hallo dabadepdu,

vielen Dank für deine Nachfragen.

Es werden "alle" Tasks ausgeführt welche der MSSQL Agent bietet.
Im Profiler sowie im Zustand der Blockierungen sind der Index Neuaufbau sowie Update Statistics aufgefallen.

Es handelt sich um einen MS-SQL 2016 Server.
Service Pack Stufe weiß ich gerade nicht - aber ich vermute so aktuell wie es Windows Update im Standard anbietet.
Von der Hardware her wird das grundsätzlich ,,ausreichend'' sein - Details weiß ich aber nicht.

Es handelt sich um ein produzierendes Gewerbe mit einem angepasstem ERP System.
In der Nacht, wenn der Task läuft, werden "einfache" Abfragen auf Stammdatensätze durchgeführt sowie Produktionsrückmeldungen mit entsprechenden Folgeaktionen.
Zusätzlich laufen noch Hintergrund Tasks welche mehr oder minder komplexe Abfragen durchführen.
Grundsätzlich sind die Arten der Operationen also sehr vielfältig.

Vielleicht gibt es Ratschläge aus der Praxis wie in einem solchen Szenario mit der Datenbank-Reorganisation umgegangen wird.

Vielen Dank und Grüße
 

So based on this analysis, we can see that the update statistics does not cause blocking issues.


With Enterprise Edition and Managed Instances you can perform rebuild operations with the ONLINE=ON option. This minimizes locking as an index rebuild runs. As with everything there are caveats.


Ach ja: Evtl. reicht ein Reorganize statt Rebuild des Index.
 
der Neuaufbau der Indizes sowie der Statistiken ist ein Teil zur Optimierung der Datenbank damit der SQL-Server die Abfragen bestmöglich optimieren und ausführen kann.

Auf Details hier einzugehen würde am Thema vorbei führen.
Das könnte auch aus einem Werbeprospekt stammen, bis zu den Details. Die Details sind meistens spannend.

Man kann natürlich die halbe Nacht optimieren, aber wenn es den produktiven Betrieb beeinträchtigt, würde ich es nicht mehr "Optimierung" nennen.
Also konkret: Vielleicht sind ja die Indizes aus der laufenden Woche optimal genug, um den Job zu machen. Vielleicht reicht die Optimierung am WE vollkommen aus, oder sogar seltener.
Stichwort dazu wäre Indexfragmentierung, auch ein fragmentierter Index funktioniert noch, idR viel besser, als kein Index. Ich habe auch noch nie davon gehört, dass ein Optimizer nicht nur die Existenz oder Art eines Index in seine Query Optimierung einbezieht, sondern auch dessen Fragementierungsgrad.
Du kannst Dir also mal anschauen, wie fragmentiert irgendwelche Indizes überhaupt sind. Dann kannst Du überlegen, welche Fragementierung aktzeptabel ist. Und dann kannst Du sicher auch mal schauen, wann überhaupt Fragementierung entsteht. Grundannahme, vor allem dort, wo viel eingefügt UND gelöscht wird oder geändert (also bei Änderungen, die Non Key Fields betreffen und trotzdem einen Index haben).

Da Daten ja ziemlich heilig sind, werden sie selten gelöscht. Demnach könnte es viele Indizes geben, die überhaupt nicht oder selten optimiert werden müssen.

Die Frage nach der Version betraf die Möglichkeiten, überhaupt non blocking Verfahren einsetzen zu können, also den Fähigkeiten des Servers.
Ob MS SQL Server das überhaupt kann oder ab welcher Version müsstest Du prüfen.

Statistiken sind ein anderes Thema, müssen aber auch nicht täglich aktualisiert werden. Beispiel, eine Tabelle, auf der massiv Import Export Delete ausgeführt wird, kann sehr schwankende Bilder abgeben. Statistiken sollten das grobe Mengengerüst der DB wiedergeben.

Also Tipp
1: Optmiere nicht wild in der Gegend rum, sondern nur das Nötige
2: Das Gleiche gilt für Statistiken.
3: Suche Operationen, die massiv und unnötig Datenoperationen machen. Also Applikation oder Script Tuning.
4: Wähle die schonensten Formen von Index Rebuild, etc. ggF. kannst Du bei aktuellen Versionen ja sogar non blocking als Schalter wählen (was wahrscheinlich die Dauer negativ beeinflusst)
5: Schaue in Logs (Ereignisse) nach Meldungen wie z.B. Log Escalation. Findest Du sowas, versuche es zu vermeiden
6: Handarbeit

Handarbeit meint, selbst zu optimieren. Es gibt offenbar frei verfügbare Scripte von Leuten, die die gleichen Probleme mit MS SQL Server haben.
Zu 5. Das ist etwas, was man sowieso nicht haben will. MS macht es sich da einfach. Wenn die Ressourcen eng werden, kommt halt Log Escalation, ein Prozess hat die Locks und darf machen und der Rest schaut in die Röhre. Ob das bei Index Rebuild auch so gnadenlos durchgezogen wird, und was Ursache und Wirkung ist, keine Ahnung. Es betrifft auch die Frage, die schon gestellt wurde. Kann MS SQL das überhaupt non blocking.
 
Guten morgen und vielen Dank für die ausführlichen sowie sachdienlichen Antworten Dukel und dabadepdu.

Ich werde mir das ganze in Ruhe anschauen und die Reorganisation umstrukturieren.

Vielen Dank und ich wünsche einen effektiven Tag.
 
Fürs Archiv, bin gerade über das hier gestolpert:

 
Es werden "alle" Tasks ausgeführt welche der MSSQL Agent bietet.
Im Profiler sowie im Zustand der Blockierungen sind der Index Neuaufbau sowie Update Statistics aufgefallen.
Was meinst Du mit "alle" Tasks? Der Agent bietet erstmal gar keine Tasks an. Da mußt schon einen Wartungsplan oder Script als Job ausführen.
Und ich hoffe doch sehr, das Du "nur" Update Statistics und Index Maintenance machst und sonst nix.
Das Update der Statistiken darf den Server nicht beeinträchtigen. Das blockiert auch keinerlei Abfragen. Index Rebuild muss man auch nicht immer machen. Dazu gibt es von Microsoft schöne Vorgaben bei wieviel Prozent man einen Reorg macht oder ein Rebuild. Indizes können auch mit der Option ONLINE bearbeitet werden. Index Maintenance muss sowieso nicht täglich gemacht werden. Wochenende reicht da völlig aus.
Handarbeit meint, selbst zu optimieren. Es gibt offenbar frei verfügbare Scripte von Leuten, die die gleichen Probleme mit MS SQL Server haben.
Zu 5. Das ist etwas, was man sowieso nicht haben will. MS macht es sich da einfach. Wenn die Ressourcen eng werden, kommt halt Log Escalation, ein Prozess hat die Locks und darf machen und der Rest schaut in die Röhre. Ob das bei Index Rebuild auch so gnadenlos durchgezogen wird, und was Ursache und Wirkung ist, keine Ahnung. Es betrifft auch die Frage, die schon gestellt wurde. Kann MS SQL das überhaupt non blocking.
Die Lock (nicht Log) Escalation hat erstmal mit Resourcenengpass gar nix zu tun. Kommt ja auf die Operationen an, nicht wahr. Außerdem kann ein DBMS sowieso kein preemtives Multitasking. Liegt in der Natur der Sache.
 
Die Lock (nicht Log) Escalation hat erstmal mit Resourcenengpass gar nix zu tun. Kommt ja auf die Operationen an, nicht wahr. Außerdem kann ein DBMS sowieso kein preemtives Multitasking. Liegt in der Natur der Sache.
Danke für die Korrektur. Dass Lock Escalation nichts mit Resourcenengpässen zu tun hat, könntest Du gern genauer erklären. Und was das mit Multitasking eines DBMS zu tun hat, preemptiv (nicht preemtiv).
 
Werbung:
Zurück
Oben