• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Datenbank Speichererweiterung

Moin, Moin, ich versuche gerade, den Fehler mit der Datenbank zu beheben.

Ich habe für 30 Tage einen eigenen Server installiert. Und werde ihn vor Ablauf der Frist wieder kündigen. Ich habe dort das Datenbank-Backup der Foodblog-Datenbank importiert. Vorteil ist, dass ich die Datenbank nun über phpMyAdmin aufrufen kann, was mir im Strato-Kundenaccount ja verwehrt wird.

Ich habe, da mich viele Kollegen darauf aufmerksam gemacht haben, dass bei WordPress die Datenbank gern durch zu viele Revisionen von Blogbeiträgen zugefüllt werden, diese mit diesem Befehl gelöscht:

DELETE FROM wp_posts WHERE post_type="revision"

Es wurden etwa 20.000 Datensätze gefunden und gelöscht. Danach habe ich die Datenbank optimiert.

Resultat: 80 MB Speicherplatz Gewinn. Die Datenbank hat in phpMyAdmin nun anstelle 940 MB noch 860 MB. (Keine 2 GB, wie im Kundenaccount von Strato angegeben)

Nun weist Strato selbst darauf hin, dass man mit MySQLDumper oder MyOOS Dumper auch größere Datenbanken im Kundenaccount importieren kann.

Also beide Skripte auf den Webspace kopiert und Installationsroutine versucht zu durchlaufen.

Der Fehler bei der Foodblog-Datenbank mit >2 GB lautete:

Es ist ein Fehler aufgetreten - Fehlercode (Access denied for user ‚Datenbankuser@‚sslproxy007.swh.1u1.it' (using password: YES))

Nun bekomme ich bei beiden Skripten aber ganz ähnliche Fehlermeldungen:

MySQL-ERROR
MySQL meldet:
Access denied for user ‚Datenbankuser@‚keyaira.swh.1u1.it' (using password: YES)
Fehler bei der Anfrage:
Error establishing a database connection!

Und das nicht nur bei der Foodblog-Datenbank, die ja angeblich zu groß ist. Sondern auch bei einer neu erstellten, leeren Datenbank, in die ich das Datenbank-Backup importieren wollte.

Was bedeutet denn dieser SQL-Error, der gemeldet wird? Tatsächlich Probleme bei Strato? Denn da sich der Support auch nach einem Telefonanruf nach zwei Tagen nicht gemeldet hat, zeigt eigentlich, dass Strato vermutlich definitiv technische Probleme hat.
 
MySQL-ERROR
MySQL meldet:
Access denied for user ‚Datenbankuser@‚keyaira.swh.1u1.it' (using password: YES)
Fehler bei der Anfrage:
Error establishing a database connection!

Was bedeutet denn dieser SQL-Error, der gemeldet wird? Tatsächlich Probleme bei Strato? Denn da sich der Support auch nach einem Telefonanruf nach zwei Tagen nicht gemeldet hat, zeigt eigentlich, dass Strato vermutlich definitiv technische Probleme hat.
Falscher Benutzername und / oder falscher Kennwort. Doch eigentlich offensichtlich, oder?
 
Deine Frage war doch "Was bedeutet denn dieser SQL-Error, der gemeldet wird?" oder? Die Antwort ist nach meinem Verständnis recht einfach: Falscher Benutzername und / oder falsches Kennwort oder falscher Datenbankserver. Was die "italienische Verlinkung" dort macht kann ich nicht sagen - stammt nicht von mir - kommt von dir.
 
Und was macht denn eigentlich eine italienische Verlinkung von 1und1 bei Strato?
Sieht nach einem Gateway aus - zumal im ersten Fehler der Host "sslproxy007" heisst. Strato, 1&1, Web.de, GMX, sind alles der gleiche Konzern "United Internet". Kann gut sein dass Teile der Infrastruktur zwischen den Markennamen geteilt werden.

Keine 2 GB, wie im Kundenaccount von Strato angegeben
Es ist gut möglich dass Strato den Disk-Space und nicht den realen Datenverbrauch überwacht. Mysql hat die doofe Angewohnheit dass je nach Engine (bspw InnoDB) die Dateien nur grösser aber nicht kleiner werden können außer man dumpt die Datenbank, löscht sie vollständig, erstellt sie neu und spielt die Datenbank ein. Im Fall wenn Strato zufällig innodb_file_per_table verwendet, reicht es aus die einzelnen Tabellen zu löschen.

. Vorteil ist, dass ich die Datenbank nun über phpMyAdmin aufrufen kann, was mir im Strato-Kundenaccount ja verwehrt wird.
Warum sollte Strato verwehren PhpMyAdmin zu verwenden? Falls es nicht vom Anbieter verfügbar ist, kann man PhpMyAdmin einfach selber auf dem Webspace installieren, ich würde es aber zur Sicherheit hinter einen .htaccess Passwortschutz legen.

Benutzername und Kennwort sind korrekt!
Laut Mysql nicht, die Fehlermeldung lügt nicht :p
Entweder es ist tatsächlich ein Fehler im Zugang (Hostname, Benutzer, oder Passwort), oder der Benutzer ist nicht von diesem Host aus erlaubt - die Zugangsdaten sind generell an Hosts/IP (oder localhost) gebunden.
 
Warum sollte Strato verwehren PhpMyAdmin zu verwenden? Falls es nicht vom Anbieter verfügbar ist, ...
Laut dem zuvor genannten FAQ-Eintrag ist phpMyAdmin direkt im Kundenmenu verfügbar.

Es ist ein Fehler aufgetreten - Fehlercode (Access denied for user ‚Datenbankuser@‚sslproxy007.swh.1u1.it' (using password: YES))
Ist mir das früher bei diesen Fehlermeldungen nur nie aufgefallen, oder wo kommt das Komma her?


Naja, MySQL 5.5 ist eh seit Ewigkeiten EOL, insofern kümmert mich das Ganze auch nicht weiter...
 
Ist mir das früher bei diesen Fehlermeldungen nur nie aufgefallen, oder wo kommt das Komma her?
Ich würde vermuten, dass die Fehlermeldung nicht kopiert sondern abgetippt wurde und dabei die einfachen Anführungszeichen per Autokorrektur durch typographische (Anfang unten, Ende oben) ersetzt, was wie ein Komma aussieht.
Was den Loginfehler betrifft, evtl. mal das Passwort bei Strato im Kundenbereich für den Datenbank-User neu setzen (und nur Buchstaben und Zahlen verwenden), um Probleme mit Umlauten/Sonderzeichen und eine falsch notierten Kennwort zu umgehen.
 
Warum sollte Strato verwehren PhpMyAdmin zu verwenden?
Starto bietet das an, aber ich bekomme beim Aufrufen der Verwaltung der Datenbank mit PhpMyAdmin eine Fehlermeldung, die Strato bisher auch seit zwei Wochen noch nicht beheben konnte.
Falls es nicht vom Anbieter verfügbar ist, kann man PhpMyAdmin einfach selber auf dem Webspace installieren, ich würde es aber zur Sicherheit hinter einen .htaccess Passwortschutz legen.
Das habe ich vor, es gelingt mir aber leider nicht. :(
Laut Mysql nicht, die Fehlermeldung lügt nicht :p
Entweder es ist tatsächlich ein Fehler im Zugang (Hostname, Benutzer, oder Passwort), oder der Benutzer ist nicht von diesem Host aus erlaubt - die Zugangsdaten sind generell an Hosts/IP (oder localhost) gebunden.
Es sind genau die Daten, die ich in der wp-config.php habe.
 
Ich würde vermuten, dass die Fehlermeldung nicht kopiert sondern abgetippt wurde und dabei die einfachen Anführungszeichen per Autokorrektur durch typographische (Anfang unten, Ende oben) ersetzt, was wie ein Komma aussieht.
Ich habe die Fehlermeldung einkopiert. Im Original sind sowohl 'Benutzername 'als auch die 'URL' durch den Apostrophen (Auslassungszeichen) eingegrenzt.
Was den Loginfehler betrifft, evtl. mal das Passwort bei Strato im Kundenbereich für den Datenbank-User neu setzen (und nur Buchstaben und Zahlen verwenden), um Probleme mit Umlauten/Sonderzeichen und eine falsch notierten Kennwort zu umgehen.
Das habe ich bereits getan und das Passwort neu vergeben. Ohne Erfolg, gleiche Fehlermeldung beim Login.
 
Das Merkwürdige bei der Fehlermeldung in meinem Kundenaccount bei Strato beim Aufrufen der Verwaltung der Datenbank ist ja, dass dort, wo ich zur Sicherheit beim Posten in diesem Forum nur „Datenbankbenutzer“ hingeschrieben habe, jedesmal ein anderer Datenbankbenutzer erscheint. Und jedesmal ein solcher, der in meinem Kundenaccount gar nicht vorhanden ist, somit also gar keine Datenbank unter diesem jeweiligen Namen angelegt ist.
 
Alternative Problemlösung durch Import des Datenbank-Backups in eine neue Datenbank.

Der Zugriff über MySQLDumper funktioniert jetzt.

Jedoch erhalte ich folgende Meldung:

"Maximale Dateigröße: 64M
Wenn Ihre Backup-Datei größer als das angegebene Limit ist, dann müssen Sie diese per FTP in den "work/backup"-Ordner hochladen. Danach wird diese Datei hier in der Verwaltung angezeigt und lässt sich für eine Wiederherstellung auswählen."

Frage: Wo bei Strato lade ich diese per FTP hoch?
 
Ich gebe mir einmal selbst die Antwort: Der Ordner work/backup befindet sich im msd-Ordner auf dem Webspace. ;)
 
Dachte, ich hätte eine Lösung gefunden, jetzt erhalte ich folgende Meldungen:

"Leider konnte nicht automatisch ermittelt werden mit welchem Zeichensatz diese Backupdatei seinerzeit angelegt wurde.
Sie müssen die Kodierung, in der Zeichenketten in dieser Datei vorliegen, manuell angeben.
Danach stellt MySQLDumper die Verbindungskennung zum MySQL-Server auf den ausgewählten Zeichensatz und beginnt mit der Wiederherstellung der Daten.
Sollten Sie nach der Wiederherstellung Probleme mit Sonderzeichen entdecken, so können Sie versuchen, das Backup mit einer anderen Zeichensatzauswahl wiederherzustellen.
Viel Glück. ;)"

Fehlermeldung:
Code:
/*!40101 SET character_set_client = @saved_cs_client */; -> Variable 'character_set_client' can't be set to the value of 'NULL'
 
Es steht nichts in der mysql.cnf bei dir drin? utf8 bei älteren MySQL? Oder schon utf8mb4?

In der Datenbank utf8 als Kodierung genutzt kann stimmte Mehrbyte-Unicode-Zeichen nicht korrekt darstellen, deswegen haben moderne Einstellungen utf8mb4 für die Tabellen/Datenbank.
Und was bei deinem Dump der Herkunftsdatenbnk vorliegt weiß ich nicht. Probiers halt mit utf8, solange du nicht Chinesisch, Japanisch, Emojies oder ähnliches hast, dürfte das bei deutschen Umlauten passen.
 
Last edited:
... dann würde ich den Export nochmals erstellen und dabei die entsprechenden Daten angeben,
 
Diese Datenbank, die ich importieren will, habe ich nicht selbst erstellt. Sie ist ein Backup der Datenbank vom Hoster, die vor dem technischen Problem mit der Datenbank automatisch erstellt wurde.
 
Back
Top