SQL-Manager - Optimieren vs. Verkleinern

Hallo,

erstaunt habe ich festgestellt, dass ich eine DB locker verdoppeln kann, indem ich den Befehl "optimieren" verwende.
"Verkleinere" ich die Datenbank danach falle ich um locker 30% nach unten.

Start 2,5 GB
Optimieren ca. 4-5 GB
Verkleinern 1,5 GB

Kann mir jmd (gerne auch von der Datev) sagen, was hier der Hintergrund ist? 10% Luft am Ende der Datenbank sind m.E. nach üblich und realistisch. aber 66% (oder 50% wie bei Lohn und Gehalt)......

grüße
Tobias Heinrich

Das würde mich allerdings auch interessieren. Mir ist fast die Platte übergelaufen, als ich versucht hab die Rewe-Datenbank zu "optimieren".

Ich hab den Vorgang abgebrochen, nachdem die Platte fast voll war.

@DATEV: Eine Anzeige der voraussichtlichen Zeit/Restzeit für die Vorgänge wäre nicht schlecht --> damit man weiß, wieviel Kaffee man kochen muss ;-)

Gruß

Udo Kubatov

Hallo Herr Kubatov,

Das würde mich allerdings auch interessieren. Mir ist fast die Platte übergelaufen, als ich versucht hab die Rewe-Datenbank zu "optimieren".

Vielleicht gibt's dann jetzt eine wohlwollende Antwort der Datev. *hoff*

@DATEV: Eine Anzeige der voraussichtlichen Zeit/Restzeit für die Vorgänge wäre nicht schlecht --> damit man weiß, wieviel Kaffee man kochen muss ;-)

Ich schätze mal, da hier nur der Befehl an den SQL-Server weitergegeben wird, gibt es keine Chance hier irgendwas anzeigen zu lassen ...

Grüße
Tobias Heinrich

Hallo, an alle Ratsuchenden,
mich betrifft dieses Thema ebenfalls und ich bin neugierig auf Antworten aus dem Hause Datev.
Leider ist es mal wiederso, das kein "Wissender" entweder die Newsgoups liest oder keine Lust hat zu antworten.
Ich finde die Newsgroups sollten auch die Plattform bieten, diese relativ allgemeinen Themen zwischen Anwendern und Entwicklern ZÜGIG zu beantworten.
Wartezeiten von 3 Wochen etc. sind m.E. nicht gerade das, was man von einer NEWSgroup erwartet, zumal diese ja auch noch aus dem Hause Datev stammt.

Warten wir mal weiter ab !!

Sehr geehrter Herr Heinrich, sehr geehrter Herr Kubatov, sehr geehrter Herr Kuster,

es tut mit leid, dass Sie keine schnellere Antwort auf Ihre Fragen bekomen haben.

Der Microsoft SQL Server ist ein Datenbanksystem, bei dessen Design sehr darauf geachtet wurde, dass der Aufwand für Administrationsaufgaben minimiert wurde und in vielen Situationen gar nicht erst entsteht. Es reagiert weitgehend selbständig und flexibel auf Lastanforderungen sowie Änderungen in der Umgebung und ist damit im besten Sinne selbstoptimierend. Nach unseren Erfahrungen funktionieren die dafür implementierten Mechanismen fast immer sehr gut.

Da aber nicht ausgeschlossen werden kann, dass es in seltenen Ausnahmesituationen doch einmal nötig sein könnte, wurden im Expertenmodus des SQL-Managers zwei Optimierungsmöglichkeiten zugänglich gemacht.
Zum einen ist es möglich, dass nach umfangreichen Löschoperationen die für einen schnellen Zugriff angelegten "Indexbäume" einen ungünstigen Aufbau bekommen ("entartete Zweige"). Für diesen Zweck gibt es die Möglichkeit, einen Index komplett neu aufzubauen.
Zum zweiten führt der SQL Server über Größe und inhaltliche Verteilung der einzelnen Werte in den Spalten der Tabellen Statistiken, um Datenbankzugriffe optimieren zu können. Normalerweise bemerkt das System selbst, wenn diese Statistiken nicht mehr der Realität entsprechen und baut sie über einen Hintergrund-Task neu auf. Es kann aber nicht ausgeschlossen werden, dass nach umfangreichen Datenübernahmen dieser Task nicht schnell genug aktiv wird und deshalb komplexe Datenbankzugriffe nicht optimal abgewickelt werden.

Beide Operationen erfordern zeitweise sehr viel Platz innerhalb der Datenbank, unter anderem wegen der dabei nötigen Sortiervorgänge. Wie viel Platz das im einzelnen ist, hängt vor allem von der Größe der größten Tabelle ab sowie von Art, Anzahl und Breite der darauf angelegten Indizes.

Diesen Platz können Sie durch ein "verkleinern" der Datenbank anschließend wieder zurückerhalten. Sie sollten dies aber keinesfalls tun, so lange Ihre Festplatte nicht zu klein wird. Zum einen braucht der SQL Server immer wieder "Luft" in seinen Strukturen, um solche umfangreichen Operationen durchführen zu können. Nach dem Verkleinern muss er sich dann den Plattenplatz dafür jedesmal wieder aufwändig allokieren. Zum anderen werden Datenbanken über längere Zeit gesehen fast immer nur größer und fast nie kleiner. Durch regelmäßiges Verkleinern werden Sie also nur ihre Festplatte fragmentieren, weil mit der Zeit die verschiedenen Datenbankdateien über die gesamte Platte verteilt werden. Damit hebeln Sie nur implementierte Performance-Optimierungen wie das "prefetchen" in bestimmten Situationen aus.

Wenn Sie also weder ein Problem mit der Performance noch mit dem verfügbaren Plattenplatz haben, ist es das Beste, wenn Sie weder "optimieren", noch "verkleinern".

Mit freundlichen Grüßen
Hans Luntz
Tätig im Auftrag der
DATEV eG

Hallo newsgroup,

lt. Teamservice der Datev ist die Funktion "Verkleinern" der Datenbanken für lokale SQL-Datenbanken am Einzelplatz bzw. beim Peer to Peer - Netz in Verbindung mit der 2 GB-Grenze notwendig bzw. sinnvoll.
Auf "richtigen" Serversystemen (ohne Platzprobleme) schließt man sich der u. a. Meinung an.

Gruß
Domenic Tillmann

Auf "richtigen" Serversystemen (ohne Platzprobleme) schließt man sich der u. a. Meinung an.

Hallo,

also meiner Meinung nach, ist "Luft" in der Größenordnung von 60-70% des originalbestandes etwas viel, selbst für eine wachsende Datenbank. Ich werde also lieber regelmäßig (alle paar Wochen) selbst Hand anlegen und Optimieren/Verkleinern.
Ich gehe auch davon aus (und mag mcih täuschen), dass für die im "normalen" Betrieb erforderlichen Anpassungen der Indices, der frei Platz nicht in dieser Größenordnung benötigt wird.

Defragmentieren sollte man m.E. nach sowieso ebenfalls regelmäßig.

Grüße und vielen Dank für die Antwort
Tobias Heinrich

Liebe Kollegen,

an anderem Orte wurde erwähnt, daß ein "Optimieren" und "Verkleinern" der Datenbanken in der Praxis einen spürbaren Performence- Schub bringen könnte.

Immerhin... Schaden wird es sicherlich nicht... (Nach einer Datensicherung...)

Frage: Gibt es eine Möglichkeit, mit einem einzigen Befehl (Mausklick) ein Optimieren bzw. ein Verkleinern aller angehängten SQL- Daten nach der Installation der DVD 8.2 mit ihren unfangreichen Datenanpassungen auszulösen?

Wir haben die Erfahrung gemacht, daß insbesonder im Bereich Eigenorganisation eine (aber welche?) Datenbank optimiert werden möchte, damit das Rechnungsschreiben signifikant schneller läuft.

Verkleinern wird zu Performanceeinbussen
führen.
Defragmentieren empfiehlt sich auch nicht
bei Server und sql.

Verkleinern wird zu Performanceeinbussen
führen.

Es sollte bei vielen Kanzleien bei der Datensicherung einen Performance- Schub geben, da nach der Einführung von PRO diverse Datenbanken noch in der Originalgröße auf dem System liegen, die sich aber sicherlich auf einen Bruchteil der Größe einschrumpfen lassen (Z.B. Rewe, Anlag usw. alt)

Dann sind möglicherweise durch die Datenanpassungen oder einfach nur durch die tägliche Arbeit einige Datenbanken derart ungünstig indiziert, daß es in der Praxis flotter geht, wenn genau diese Datenbanken optimiert werden.

Später, wenn die Datenbanken eine gute Größe erreicht haben, wird noch ein Systemeigenes Defrag der Festplatte durchgeführt.

Daher meine (bis heute unbeantwortete) Frage nach einer Mehrfachauswahl im SQL- Manager.

Performancegewinn, egal ob im produktiven Betrieb oder DaSi, ist hier nicht unbedingt zu erwarten.

Im produktiven Betrieb organisiert sich der MS-SQL weitestgehend selber. Insbesondere hier ist ein manuelles Eingreifen eher hinderlich. Wenn eine DB an ihre Speichergrenze stösst, genehmigt sich der SQL-Server 10% der bestehenden DB-Grösse und hängt diese mit einem "Block" an. Somit ist das Thema Defragmentierung vom Tisch, da der SQL einen durchgehenden Block auf der HDD in Anspruch nimmt.

Die Datensicherung kann hierbei sogar noch gewinnen, da sie nur durchgehende Blöcke lesen muß. Die frisch angehängten Bereiche sind leer und werden durch die Komprimierung in der Datensicherung-Software erst gar nicht mitgesichert. Insofern hier auch kein Problem.

Problematisch ist eher das manuelle optimieren und verkleineren, da hier der SQL technisch eine komplette Kopie der DB erstellt. D.h. kurzfristig braucht der SQL quasi den doppelten Platz auf der HDD nur um die Funktionen auszuführen.

Aus diesen Gründen empfiehlt hier DATEV auf die Finger von diesen Funktionen zu lassen und nur im Bedarfsfall die DB derart zu malträtieren...

BTW: Performance im Server gewinnt man durch schnelle Plattensysteme (Cache-Controller und/oder SSD-->Enterprise-SSD!). Wenn dann noch ausreichend RAM vorhanden ist, damit der SQL auch noch cachen kann...

Gruß

C.O.

Hallo NG,

es gibt neue Aussagen der Datev zum Thema: SQL Server Datenbanken optimieren

gruss rw

Danke für diesen Hinweis.

Es steht geschrieben: "Wir empfehlen das Skript RunMaintenanceWE.cmd regelmäßig aufzurufen, mindestens einmal wöchentlich .". An anderer Stelle steht: "Zur Verwaltung der Datenbanken wird im DATEV-Umfeld der Microsoft SQL Server eingesetzt. In der Regel optimiert der Microsoft SQL Server seine Datenbanken selbst ."

Dann steht das alte DATEV- Zitat von Herrn Hans Lunzt: "Wenn Sie also weder ein Problem mit der Performance noch mit dem verfügbaren Plattenplatz haben, ist es das Beste, wenn Sie weder "optimieren", noch "verkleinern"."

Bisher hatten wir vielleicht ein Mal Jährlich die Datenbanken manuell optimiert und geshrinkt, um das Volumen der Datensicherung nach der Pro- Umstellung zu reduzieren.

Fragen:

- Was bewirkt diese neu empfohlende wöchentliche Aktion?
- Darf diese Aktion überhaupt auf SSD im Server ausgeführt werden ?
- Ist theoretisch irgend eine Verbesserung auf SSD im Server durch diese Aktion zu erwarten

Würde mich auch über Hintergrundinformationen freuen.

Ich auch.

Im Moment verstehe ich das so, dass der SQL-Server die Optimierung bei Bedarf selbst macht, und die Batches nur dazu dienen, den Zeitpunkt zu bestimmen, damit das nicht in der Produktionszeit passiert.

Gruß aus Hamburg