Hello !
Habe n "noch nich aktiv im Einsatz-pMx 01.10", habs durch Zufall entdeckt:
Klicke ich im Adminpanel auf "Datenbank optimieren" erscheint die Meldung:
Error sql_query():
qry: SHOW TABLE STATUS FROM {dbname}
descr: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'meine DB' at line 1 ( mysql 1064 )
details:
file: /admin/modules/optimize.php # line: 44, cmd: sql_query(SHOW TABLE STATUS FROM {dbname}),
file: /admin/case/case.optimize.php # line: 35, cmd: include(SHOW TABLE STATUS FROM {dbname}, /admin/modu...),
file: /admin.php # line: 830, cmd: include(SHOW TABLE STATUS FROM {dbname}, /admin/modu..., /admin/case...),
admin/modules/optimize.php + file: /admin/case/case.optimize.php + /admin.php gelöscht und erneut hochgeladen.
Der Debug-Modus gibt folgendes aus:
GET: Array
[op] => optimize
[panel] => 1
Ein Datenbank-Backup läßt sich erstellen.
Habe zwar zu "mysql 1064" etwas gefunden, jedoch hats mich nich weitergebracht.
Das seltsame ist ja, sonst rennt die Seite wie geschmiert.
Optimieren führe ich seit längerem per phpMyAdmin durch.
Nen Link zur Seite kann ich nicht schreiben, ist mit nem Verzeichnischutz versehen.
Moin :)
Zitatfor the right syntax to use near 'meine DB' at line 1
Heisst die Datenbank wirklich so?
Also mit dem Leerzeichen?
Hi Andi !
Neee, so heißt die nicht.Hab ich so fürs Forum hier geändert, unter Einstellungen und in der config.php unter "$mxConf['dbname']" steht es richtig (ohne Leerzeichen).
Meine Überlegung ist, der Eintrag sollte stimmen, denn Links, Content, ... werden korrekt angezeigt.
Das macht mich ja stutzig :gruebel:
Betrifft "nur" die DB-Optimierung (bisher).Die Seite liegt bei Hosteurope innerhalb meines Webpacks (PHP-Version: 5.2.6, MySQL-Version: 5.0.32-Debian_7etch8-log) und hat ne eigene TLD.
Auch die Option "alle SQL-Anfragen anzeigen?" hab ich aktiviert.Auf die richtige Fährte bin ich noch nicht gekommen...
tjo da klick ich mal dran , denn ich hab mit dem optimize-befehl im pragma auch probleme. ich erhalt zwar keine fehlermeldung , sondern eine liste der optimierten tabellen, wenn ich dann aber über phpmyadmin in die db schau stelle ich fest das das garnicht stimmt.
unabhängig davon sicher ich die db mit mysqldumper . bei dem ist eingestellt: vor dem backup tabellen optimieren. macht er das ? nein . dort bekomme ich für den bruchteil einer sekunde eine warnmeldung . das backup ( der nicht optimierten tabellen) funktioniert aber .
Moin :)
bevor sich noch mehr dranhängen, etwas hintergründiges.
Das Tabellen-Optimier-Teil wurde vor x-Jahren bereits von phpNuke übernommen und funktioniert auf diese Weise schon auf hunderttausenden Installationen....
Die Tabellenoptimierfunktion macht nix anderes, als 2 mysql-Befehle in einer Schleife auszuführen.
- Zuerst werden mit >>SHOW TABLE STATUS (http://dev.mysql.com/doc/refman/5.1/de/show-table-status.html) from dbname<< alle Tabellen ausgelesen und deren "Optimierstatus" berechnet.
Wer sich alle DB-Anfragen anzeigen lässt und dann die Syntax dieser einzelnen Abfrage mit dem verlinkten Handbuch vergleicht, der sieht, dass die von pragmaMx verwendete Syntax der Abfrage absolut korrekt ist.
Warum das jetzt bei xmjay, nen Fehler wirft, ist weder im Handbuch zu erkennen, noch sonstwie zu erklären. Eventuell liegt das irgendwie an der Serverkonfiguration. Das müssen wir in Ruhe prüfen.
Mit der eigentlichen Optimierfunktion hat dieses Problem von xmjay noch garnichts zu tun. Durch den Fehler beim Auslesen der Tabellen kommt das Script erst garnicht so weit.
- Dann wird aus den ermittelten Tabellendaten eine Schleife gebildet. Bei jedem Durchlauf wird der Befehl >>OPTIMIZE TABLE (http://dev.mysql.com/doc/refman/5.1/de/optimize-table.html) tabellenname<< auf eine Tabelle (tabellenname) angewendet. Auch hier ist die Syntax absolut korrekt. Siehe verlinktes Handbuch (http://dev.mysql.com/doc/refman/5.1/de/optimize-table.html).
Also auch hier, arbeitet das Script korrekt. Ob durch irgendwelche Konfigurationsoptionen, die Optimierung nicht durchgeführt wird, darauf hat das Script keinen Einfluss.
Problematisch bei dem Script ist (und das werden wir irgendwann mal ändern), dass bei der Anzeige der eingesparten Daten davon ausgegangen wird, dass der Optimierbefehl auch wirklich ausgeführt wurde und nach dem Optimieren nicht nochmal der Status der Tabelle ermittelt wird. So kann es durchaus zu Fehlanzeigen kommen. Der Befehl wurde aber an den mySql Server geschickt. Was der wieder draus macht, darauf hat das Script keinen Einfluss.
@ xmjay
Teste mal bitte mit der angehängten optimze.php, ob die fehlermeldung auch noch kommt. Habe testweise den DB-Namen in der Abfrage "escaped". Kanns mir zwar nicht vorstellen....
@ grafikmurkser
Was stimmt denn nicht? Alle Tabellen, oder nur bestimmte?
Einige Tabellen, die "memory" als Speicherengine haben, werden evtl. nicht korrekt optimiert....
Hallo Andi , eine Nachfrage beim Hoster ergab folgendes :
"Bitte verwenden Sie die Optimierungsmöglichkeiten Ihres CMS und des Backup-Programmes "mysqldumper" nicht mehr.
Die dort enthaltenen Befehle werden vom Server abgelehnt"
Antwort auf Deine Frage : keine Tabelle lässt sich optimieren .
Hoi :)
ZitatDie dort enthaltenen Befehle werden vom Server abgelehnt
Also hier ein Serverproblem ;)
Wie gesagt, die "unwahre" Anzeige müssen wir demnächst korrigieren.
Ich habe es gerade im Bugtracker eingetragen.
jep Andi ...
Hab aber erst heute die Antwort bekommen. Sonst hätte ich hier garnix geschrieben....
Hi !
@ Andi:
Mit der angehängten optimze.php erscheint die Meldung nicht mehr und die DB läßt sich optimieren :thumbup:.
Insgesamt eingesparter Speicherplatz: 0.063 Kb
Hello !
Habe die hier angehängte "optimze.php" auf meine Haupseite hochgeladen, siehe da, funktioniert dort ebenfalls.
Zuvor erschien dort keine Meldung, jedoch wurde nicht optimiert (siehe Screenshot).
Mit der geänderten "optimze.php" wird optimiert und es werden die Dateien aufgelistet mit Info, ob optimiert wurde und wieviel kb oder ob der Table bereits optimiert wurde.
:bye: