Hallo,
ich hab eine Datenbank "aufgeräumt"/gelöscht, die Datenbank wurde aber nicht kleiner (Dateisystem),
Dann habe ich verkleinern und optimieren gewählt und schwups wurde die DB erheblich kleiner;
https://apps.datev.de/help-center/documents/1043303
Kann ich das auch mit Lohn, Rewe, DMS usw. machen oder eher nicht zu empfehlen?
... ich hätte auch große Lust, diverse 'aufgeblähte' SQL-Datenbanken zu verkleinern.
Vermutlich haben sie große Ähnlichkeit mit einem Schweizer Käse.
Man fragt sich bei solchen großen 'Löchern im Käse' : "ist das Kunst oder kann das weg ?"
... allerdings wurde hier in der Community schon heftig vor solchen Optimierungs-Aktionen gewarnt ...
... was mich dann letztlich von entsprechenden Versuchen abgehalten hat
Ich frage mich allerdings, ob man nicht von Entwicklerseite anlässlich der gelegentlichen Updates und Upgrades des SQL-Servers die Datenbanken 'umkopieren' und dadurch optimieren könnte
... vielleicht passiert das ja auch schon längst und man erfährt bloß nichts davon
... dass man besser nicht auf eigene Faust an den SQL-Datenbanken 'herumstricken' sollte, leuchtet mir ein.
Wer will schon den beliebten Spruch hören: "jetzt hilft nur noch ein Rücksichern eines Backups" oder wer will/kann sich eine kostspielige "Spezialoperation eines SQL-Datenbank-Chirurgen der Datev" leisten
ist irgendwie an mir vorbei gegangen…
war das hier schon diskussion?
die datenbank hab ich natürlich vorher gesichert und dann einfach mal gemacht..
bei den „grossen“ lass ich es dann mal lieber.. soll der sql mal machen..
Wer mit dem DATEV- Bordmittel: SQL- Manager Datenbanken erst optimiert und dann verkleinert, der kann bei intakten Daten eigentlich nichts schrotten.
Unbedingt bedenken, daß relativ schnell die Datenbank während des Betriebes wieder erweitert wird, was durchaus Latenzen im Sekundenbereich auslösen kann. (Hardware Fileserver: 64 GB Speicher und ausreichend SSD)
latenzen will ich nicht.. gut, die eine datenbank wurde quasi eh nicht genutzt und da macht das ohnehin nichts..
aber von 15 auf 5gb war ein guter wert.
in dem verlinkten dokument heisst es erst verkleinern und dann optimieren ?
... ich selbst hatte auch mal das Bedürfnis, darüber zu diskutieren ... 😉
z.B. hier:
da ging es mehr ums splitten?
egal.. ist ja eh irgendwie im sande verlaufen
@chrisocki schrieb in dem o.g. Thread :
[...]
Ach so: Von den Möglichkeiten im SQL-Manager wie "DB verkleinern" oder "DB komprimieren" = FINGER WEG!!! Damit können Sie auch zuverlässig eine Datenbank schrotten... Diese Funktionen immer nur im Supportfall und wenn es gar nicht mehr anders geht!
[...]
... hörte sich so an, also ob man in der Häckselmaschine "SQL-Server" leicht die Finger (bzw. Daten) verlieren könnte
... seltsam ist es aber schon, dass einem Optimierungsmöglichkeiten angeboten werden, die man besser nicht nutzen sollte 😎
Ich würde es so formulieren:
Wenn die Datenbank oder die darunterliegende Hardware bereits kaputt ist, dann werden die SQL- Datenmanager- Befehle das gnadenlos aufklären.
Wenn der SQL- Server täglich getestet, und dann für Sicherungszwecke heruntergefahen und neu gestartet wird, dann sollte es keine Probleme mit der Datenbank und vergessenen Sperren geben. /ich weiß, daß es nicht mehr notwendig ist, aber bei SSD darf der Cache Nachts gerne gelöscht werden. Das bewirkt, daß der erste DAP- Start am frühen Morgen 4 Sekunden länger dauert.
Frage in die Runde: Ist irgend jemanden durch diese Befehle jemals ein Problem entstanden?
@martinkolberg schrieb:
Frage in die Runde: Ist irgend jemanden durch diese Befehle jemals ein Problem entstanden?
Nein
@siro schrieb:
@martinkolberg schrieb:Frage in die Runde: Ist irgend jemanden durch diese Befehle jemals ein Problem entstanden?
Nein
... also zero Probleme bei @siro 😎,
... aber vermutlich gibt es noch mehr Datev-Installationen und auch Datev-Installateure, die evtl. schlechte Erfahrungen mit 'zickigen' SQL-Datenbanken gemacht haben.
.. ich erinnere mich an Andeutungen von @einmalnoch (in einem anderen Thread), dass solche 'Spezialoperationen' an SQL-Datenbanken **bleep** 'hässlich' und kostspielig sein können
@vogtsburger schrieb: ... hörte sich so an, also ob man in der Häckselmaschine "SQL-Server" leicht die Finger (bzw. Daten) verlieren könnte
Nun ja, der Finger bleibt wohl in jedem Fall dran... 😉
... seltsam ist es aber schon, dass einem Optimierungsmöglichkeiten angeboten werden, die man besser nicht nutzen sollte
Wenn es technische Gründe gibt, kann die Funktion eine Abhilfe darstellen (Festplattenplatz neigt sich dem Ende zu).
In jedem Falle sollte man folgendes beachten:
1. Alle SQL-Datenbanken haben "Luft im Bauch". Dies macht der SQL um einer Fragmentierung der Datenbanken vorzubeugen. Man läuft also hier Gefahr, die Performance zu "verschlimmbessern", da nach der Verkleinerung die Sektoren neu beschrieben werden.
2. Der SQL wird sich im Anschluss wieder Platz verschaffen... Wenn die DB-Kapazität eine zur Verfügung stehende Mindestmenge unterschreitet, wird der SQL 10% der bestehenden DB-Größe auf der Festplatte neu allokieren. Somit ist die Verkleinerung ggf. nur "temporär".
3. Bei der Verkleinerung werden die Daten neu geschrieben. Frühere SQL-Versionen haben dazu sogar eine neue DB angelegt und die Daten dorthin verschoben. Wie schon andere geschrieben haben, kommt es dann auf die zugrundeliegende Maschine an. Hardwarefehler können hier dann eine Menge Kopfschmerzen bereiten.
Letztendlich muss ein jeder selber wissen, ob eine Verkleinerung im Hinblick auf die aktuellen Festplatten/SSD-Preise in Erwägung ziehen möchte. Bei der Datensicherung werden die Daten im Regelfall komprimiert und die "Luft ist raus".
Es gibt also aus meiner persönlichen Sicht keine Notwendigkeit hier an den Datenbanken herumzubasteln. Der SQL verwaltet dies schon ganz gut selber. Ausnahme ist oder sollte der Supportfall sein und bleiben.
Beste Grüße
Christian Ockenfels
hallo,
ich habe das Microsoft-Dokument mal dazu gelesen... mal kann es machen, aber es lohnt sich eigentlich nur nach größeren Aufräum- oder Löschaktionen, abschneiden von Tabellen usw.
Da ich so eine Löschaktion gemacht habe, habe ich es einfach mal probiert.
Letztlich Sicherung gefahren und dann verkleinert und optimiert.. Ende vom Lied: ca. 10% kleinere Datenbank und 10% schnellere SQL-Prüfung mit Sicherung.. Kriege gewinnt man damit nicht :-).
Beim Arbeiten habe ich noch nichts gemerkt.. die DB's waren vorher schnell und sind es immer noch..