Category Archives: Datenbanken

Genug RAM gibt es gar nicht…

Posted on by

“ ‚Auf der Suche nach der Wahrheit, muß der Adept allerlei Prüfungen des Geistes und Körpers über sich ergehen lassen.‘ „Prüfungen kann ich ertragen, Meister, aber an Langweile werde ich sterben.“ “ ( aus den Büchern Groths )

So geht es mir auch grade 🙂 Ich bin auf der Suche nach der Wahrheit hinter einem DNS Fehler, aber diese Wahrheit bedeutet Stress pur. Bosten läuft zum dritten Marathon durch, und kein Ergebnis, dafür aber Heldenleistungen bei den Prozesswerten.

Dabei fing alles mit einer harmlosen Frage an :

Bluefish3

Sehr lang ist noch milde ausgerückt, denn SQL Dumps werden von MySQLdumper dummerweise so gemacht, daß sie riesige Anweisungsketten sind, die mit einem einzigen INSERT mal ebend hunderttausende bis Millionen von Tabellenzeilen schreiben. Der MysqlServer schafft das deutlich besser als BlueFish 🙂

Wie man hier schön sehen kann, sollte ein Texteditor so nicht in der Prozessliste aussehen:

3.7 GByte RAM verbrauch für ein 2 GB SQL File

3.7 GByte RAM verbrauch für ein 2 GB SQL File

Und seit ca. 20 Minuten sieht man das Bild :

Bluefish2
Keine Ahnung was am Laden von 2 GB Text so viel CPU ziehen kann 😉  Sehr positiv, der Rest vom System reagiert noch richtig gut 🙂 Wozu hat man auch 8 Kerne ? Die langweilen sich ja sonst eh den ganzen Tag.

Nach 30 Minuten glaube ich langsam daran, daß sich …. nein… jetzt, fertig? Dramatik bei BlueFish.. RAM Verbrauch droppt von 3.7 GB auf 1.9 GB , aber dafür mußte etwas ausgelagert werden.. Gnome ist jetzt leider der Meinung, daß BlueFish nicht mehr auf Eingaben reagiert ( stimmt ), und möchte es terminieren, aber Bluefish ackert noch 😉  … Eine Geduldsprobe sonders gleichen..  Das Bluefish verloren hat, weil mir der Geduldsfaden geplatzt ist 🙂

Alternativen sind gefragt !

Die Anwendungen im Desktop sind alles Luschen, da müssen die Kollegen von der Bash ran 🙂

3 Minuten zum Entpacken des SQL Dumps von BZIP2 in Rohtext.
1 Sekunde zum Prüfen mit head, daß kein use database; im Dump steht.
10 Sekunden um zu sehen, daß der SQL beim Einsortieren die gesuchte Tabelle bereits eingefügt hat
10 weitere Sekunden um einen Select laufen zu lassen, der die gesuchten Informationen ausgibt.

In your Face DESKTOP ! 😀

Und das alles nur, weil der (sich beschwerende ) Kunde, seinen SOA Eintrag selbst gelöscht hat.

Was lernen wir daraus ?

  1. Ein Boston mp3 alleine macht noch keine gute Musikschleife
  2. Überbewerte Deinen Texteditor nicht, er ist nur für typische Desktopanwendungsfälle gemacht
  3. Bash rulz!

 

Solution – mysqldump – No database selected when selecting the database

Posted on by

International shortform:

Hi, if you reached this page, because it’s one of five webpages regarding this specific error message, please scroll down to the end.

Und für alle anderen, die lange Form:

Die Shell kann komisch sein, aber die Abwesenheit der Bashshell ist noch zu viel komischeren Sachen fähig, eine davon ist der Bug von Mysqldump keine Datenbank angegeben zu haben.

Hintergrund: Wenn man in Java mit Exec() einen Befehl startet, hat man keine Shell vor sich und damit auch eine Menge Sicherheitsprobleme nicht mehr. Nachteil : u.a. „*“ wird nicht mehr funktionieren, denn das wird von der Bash geparst. Keine Bash => Kein „*“ Keine „<>“ .

Das kennt man noch. Was jetzt kommt, ist allerdings extrem schwer zu debuggen, deswegen bin ich auch ein klein bisschen stolz als einziger im Netz eine Lösung präsentieren zu können, auch wenn die eher trivialer Natur ist. Sucht mal nach der Fehlermeldung, es gibt nur 4 Seiten, die diese Meldung behandeln 😉 (OK, jetzt 5 )

Das hier ist der Befehl:

/usr/bin/mysqldump  --add-locks -e --force -R --triggers --add-drop-table --hex-blob -h localhost --password=dbpass --user=dbuser dbname;

Das erzeugt die Fehlermeldung :

mysqldump: Got error: 1046: No database selected when selecting the database

obwohl eine Datenbank angegeben ist. Gibt man den  Befehl in die Shell ein, geht es sofort ohne Anpassungen. Kleine Anmerkung, auf die Fehlermeldung an sich muß man geistig erstmal kommen, richtig wäre nämlich „no databasename given“

Wie löst man das jetzt, wenn man doch schon alles richtig angegeben hat ?

Na man drückt dem Befehl die Pistole auf die Brust, so daß er sich nicht mehr herausreden kann ;D

/usr/bin/mysqldump  --add-locks -e --force -R --triggers --add-drop-table --hex-blob -h localhost --password=dbpass --user=dbuser --databases dbname

Der kleine Zusatz „–databases“ ist eigentlich dazu da, mehr als eine Datenbank in einen SQL-Dump zu integrieren. Es geht aber auch nur mit einer einzigen Datenbank und komischerweise kommt der Parser jetzt nicht mehr durch einander und erkennt die Datenbank am Ende des Befehls. Es gibt so bescheuerte Bugs 😀

Ok, Hello there.  You found this page, because it’s the only one marked as solution to the problem, that you give mysqldump a databasename and it says, that you did not. It’s a bug that occurs only in the absence of bash. You counter it by adding „–databases “ infront of your databasename. See the above example if your uncertain how to do it.

If you wanne see more articles in english, please leave a comment about it. Cu.

 

2038 ist schneller da als man denkt

Posted on by

In 23 Jahren, wenn die Unixwelt Y2K erlebt, wird die Welt zusammenbrechen.

Wir haben ja jetzt 2015 und die gängigste Datenbank MySQL legt Timestampfelder immer noch als 32-Bit Feld an. Es sollte ja eigentlich kein Problem sein dort intern 64-Bit zu benutzen, aber wie das so ist, die Tücke liegt im Detail.

MySQL speichert die Daten in einer großen Datei im Binärformat. In dem Augenblick wo dieser Feldtype auf 64-Bit umgestellt wird, muß zwangsweise mysql_upgrade laufen, sonst gibt es nur Probleme. Und wie das Leben so spielt,  mysql_upgrade wird bei normalen Updates eigentlich nie ausgeführt. Da muß man als Admin selbst machen.

„Wenn das noch 23 Jahre sind, warum nervst Du jetzt schon rum?“

Ich kenne Euch halt 🙂 Dabei wollte ich auf etwas anderes hinaus:

Führt öfter mal mysql_upgrade durch. Erst dieser Befehl schreibt die Strukturen im Mysql um z.b. wenn neue Felder in der „mysql“ Datenbank hinzugekommen sind. Mit den Updates von Fedora 20 auf 21 z.b. mußte so ein mysql_upgrade auch zwangsweise laufen, wenn man die neuen „Features“ benutzen wollte.

Zurück zum Jahr 2038. Es werden dann mehr als 40 Jahre zwischen den Leuten liegen, die Y2K mitgeplant haben und denen, die dann für die Systeme verantwortlich sind. Da darf man annehmen, daß die meisten das auf die gleiche leichte Schulter nehmen werden, wie Ihre Vorfahren.

Deswegen wünsche ich heute schon einen schönen Weltuntergang 😉