SQL Export Größe

[virivsd]

0

Moin,

vielleicht kennt sich jemand bisschen mit SQL bzw dessen Exporteinstellungen aus.
Ich hab ne 400MB Datenbank, läuft automatisiert täglich ein Backup....
Datenbank: 400MB, Backup 80MB
Da haut folglich was nicht hin....Habe im Exportprogramm jetzt mal die Maximal InsertSize auf 0 gesetzt, siehe da, Export ist nun größer als der Wert der Datenbank(was ja auch sein kann)

[ATTACH=CONFIG]1371[/ATTACH]


Kann mir jemand erklären, was es hiermit auf sich hat?
ich meine rein logisch übersetzt müsste ich den Wert doch eher von 1024 erhöhen auf mindestens die Größe einzelner Tabellen und nicht auf 0 setzen?!?!?!
Das ist doch quasie einmal falschherum?

Hoffe ihr versteht mich.

Desweiteren hab ich ne BATCH aufm Server laufen die den mySQL Dump für mich macht....wie sag ich dem, dass er dann die gesamte Datenbank(also Inhalt) und nicht nur die ersten 1024kb reinnimmt. Scheint nämlich Standard zu sein.

[CTHTC]

0

Hallöchen.

Zur Datenbank selber müsste ich mal unseren Spezi ranholen aber zwei Sachen könntest Du mal probieren.

1. Mach mal von Deiner DB lokal auf dem Server eine Kopie und schau mal, wie groß die dann ist
2. Teste mal "MySQLDumper". Der rüsselt Dir eigentlich jede DB weg egal in welcher Größe

Gruß
CTHTC

[Gast11]

0

Moin,

vielleicht kennt sich jemand bisschen mit SQL bzw dessen Exporteinstellungen aus.
Ich hab ne 400MB Datenbank, läuft automatisiert täglich ein Backup....
Datenbank: 400MB, Backup 80MB

Hätte dir eigentlich CTHTC sagen können , sofern er Backups vom Forum macht.
In der SQL werden die Werte für die Felder gesetzt die du angibst , Feld A 20 Zeichen tatsächlich eingetragen 4
Die Datenbank hat nun die 20 Zeichen der Export aber nur die wirklich eingetragenen bzw kommt es auf den Export an . Ich meine den kannst du auch 1:1 machen was aber nicht wirklich Sinn ergibt.

[CTHTC]

0

Wenn ich Sicherungen mache, dann nehme ich ganz einfach die Export Funktion der DB und die haut mir alles 1:1 auf die Platte.

[virivsd]

0

In der SQL werden die Werte für die Felder gesetzt die du angibst , Feld A 20 Zeichen tatsächlich eingetragen 4
Die Datenbank hat nun die 20 Zeichen der Export aber nur die wirklich eingetragenen bzw kommt es auf den Export an . Ich meine den kannst du auch 1:1 machen was aber nicht wirklich Sinn ergibt.

Nochmal für Blöde bitte...
Ich kann mir nicht vorstellen, dass leere Felder ein solches Volumen ergeben.
Kannst du das nochmal genauer beschreiben bitte?


Gesendet von meinem MotoG3 mit Tapatalk

[Gast11]

0

Nochmal für Blöde bitte...
Ich kann mir nicht vorstellen, dass leere Felder ein solches Volumen ergeben.
Kannst du das nochmal genauer beschreiben bitte?

Ich hab ne 400MB Datenbank, läuft automatisiert täglich ein Backup....
Datenbank: 400MB, Backup 80MB]

Darum geht es ja das die nicht ein solches Volumen erzeugen. Von 1 : 1

[virivsd]

0

Also werden leere Inhalte entfernt?
Bedeutet leer, dass Tabellen fehlen könnten wenn kein Inhalt da wäre?
Was hat das dann mit der Max insert Size auf sich?

Gesendet von meinem MotoG3 mit Tapatalk

[Gast11]

0

Wieso sollte denn da etwas fehlen , die sind doch definiert. Naja vielleicht istd as auch zu lange her das ich das gemacht haben. Zumindest war es damals so.
Und alle wurde per GZip gemacht. Bei den Leitungen damals.


Feld 1 : 20 Feld 2: 50 Die Zuordnung was das ist wo das steht wie lang.
Ich sichere doch nur was da ist , da werden die Felder (Tabellen) an sich ja nicht gelöscht. Eine Tabelle ohne Inhalt hat weniger als eine Tabelle die Inhalt hat.

Der Speicherplatzbedarf der gesamten Datenbank wird wesentlich durch das Datenvolumen der einzelnen Tabellen bestimmt. Wenn man die durchschnittliche Satzlänge einer Tabelle abschätzt und die voraussichtliche Anzahl der Datensätze, dann müssen diese beiden Werte miteinander multipliziert werden, um den Speicherplatzbedarf der gesamten Tabelle abzuschätzen. Der Speicherplatzbedarf der einzelnen Tabellen wird addiert und man erhält den Platzbedarf für alle in der Datenbank zu speichernden Daten. Oft werden solche Zahlen für den Zeitpunkt der Inbetriebnahme mit einer Planung der jährlichen Zuwachsrate kalkuliert.
Zu dem Platz der Nettodaten kommen in der Regel noch 10 % bis 50 % weiterer Speicherplatzbedarf für die Strukturen zur Verwaltung der Datenbank (z. B. Indices, Interne Tabellen zur Verwaltung von Zugriffsrechten und zur Speicherplatzverwaltung).

Mal aus einem US Forum:

you avoid this by leaving the default (1024). Other values have been introduced for rare special cases, where inserts would not work in the standard configuration. normally, except when using really large imports (GB), everything will be fine; if you do not get any error message dialog from the import, everything has been imported.

Da würde ich in deinem Fall erstmal einen Import versuchen an einer Test Datenbank bevor du den Wert veränderst.

Scheinbar doch nicht so schlimm.

Max INSERT size Defines the maximum size of the extended INSERT statements, which can hold multiple rows in one statement. Note that a MySQL server limits the size of a query sent to the server by the server variable max_allowed_packet. Be sure to use a lower value in this dialog, otherwise MySQL will kill your connection when importing that file.

Wieso sich bei dir aber dabei die Größe ändert ????

[virivsd]

0

Fazit: es kann also durchaus sein, dass alle Daten in der 80mb datei enzhalten sind ?!

Danke für den Versuch der Erklärung
Dennoch prallt es im Hirn immernoch auf Widerstand. Vielleicht widerstrebt das offensichtliche meiner Logik.
Ich glaub ich umgeh das ganze indem ich zudem einfach den gesamten SQLserver sicher spiegel

[CTHTC]

0

Fazit: es kann also durchaus sein, dass alle Daten in der 80mb datei enzhalten sind ?!

Imho nein, denn wie sollte das denn Funktionieren?
Wenn eine DB 400MB groß ist, wie sollte sie dann plötzlich auf 80 GB schrumpfen? Das klingt mir irgendwie unlogisch. Die Daten verschwinden ja nicht plötzlich.
Wie gesagt probier mal eine Kopie oder den Dumper, dann siehst Du ja, was als Ergebnis rauskommt.

[virivsd]

0

Eben so seh ich das auch....ich werd den scheis einfach Spiegeln um sicher zu gehen.
Verstehe nur den Sinn nicht, dass standardisiert die SQL Daten so abgespeckt werden,...das hat ja Null mit Backup zu tun

[CTHTC]

0

Na bei mir werden die DB nicht verändert. Ich weiß ja nicht, wass da Dein Provider macht.

[virivsd]

0

Kein Provider, ist die Server Datenbank vom Warenwirtschaftssystem auf der Arbeit

[CTHTC]

0

OK, dann muss der Serveradmin ja irgendwas gedeichselt haben, wenn die DB nicht 1:1 übernommen wird.

[virivsd]

0

Ne denke nicht. Hab 2 Programme getestet und das reine konsolensteuerung vom MySQL für den Dump probiert, selbe Resultate. Scheint wie gesagt ne Standardkonfiguration zu sein

[CTHTC]

0

OK, dann muss ich mich leider ausklinken. So tief in der Materie stecke ich da nicht drin.

[Gast11]

0

Ist bei mir auch zu lange her , für mich ist das halt nur unlogisch wenn das Backup die gleiche grösse wie die DB hätte. Wir reden hier ja von einer DB und keiner sequentieller Datenspeicherung. Bei der wirklich 1.1 oder grösser sein müsste ohne Kompression.

Bei einer SQL werden/wurden die Felder halt vordefiniert. ZB linke Seite:

Tablet Modell : nun das definierte Feld an Zeichen sagen wir mal 120
Netzbetreiber: nun das definierte Feld an Zeichen sagen wir auch 120

In der SQL wäre nun schon mal 240 Zeichen belegt (egal ob da was steht oder nicht)
Vom Dumper sollte da nur stehen Tabelle Grösse Länge Position und je nach dem was der User einträgt zwischen 0 und 240 plus Verwaltungsdaten

Zumindest war das bei den Woltlabboards so.

Aber da sprichst du besser euren Admin an.

[CTHTC]

0

Werden denn in der DB die Felder als belegt markiert nur, weil sie von der Größe her definiert sind? Das kann ich mir gar nicht vorstellen. Dann wäre ja auch eine leere DB schon recht groß nur durch die Definitionen.

[virivsd]

0

Ich werde mir mal so ne Sicherung bei mir am Rechner einspielen. mal sehen was alles da ist...

[CTHTC]

0

ICh habe das schon mal bei mir aufn Server gemacht und da war die DB wirklich 1:1 gespeigelt. Alles andere würde ja auch keinen Sinn machen, wenn es sich um eine Sicherung handelt - oder ?