Nach dem notwendigen Upgrade von 4.7.8 auf 4.7.10 (Bugfix Vendorlist) erhalten wir sporadische mysql Fehler und Abbrüche des Bestellprozesses - hier ein Auszug aus dem Exception.log
oxConnectionException-oxException (time: 2014-02-02 18:55:03): [2006]: mysql:EXECUTE error: [2006: MySQL server has gone away] in EXECUTE with parameters select COUNT(*) from oxtplblocks where oxactive=1 and oxshopid='oxbaseshop' and oxmodule in ( 'invoicepdf', 'rmit_ppAmount', 'sit_powersearch', 'wn_cke', 'wn_cke_dirfix', 'Sparkassen_Internetkasse', 'd3modcfg_lib', 'd3clrtmp_lib', 'd3install_lib', 'd3log_lib', 'd3_googleanalytics', 'd3seccheck_lib', 'd3usersonline' ) , for user ----------------
Stack Trace: #0 /...../core/adodblite/adodbSQL_drivers/mysql/mysql_driver.inc(369): adodb_throw('mysql', 'EXECUTE', 2006, 'MySQL server ha...', 'select COUNT(*)...', false, Object(object_ADOConnection))
#1 /..../core/adodblite/generic_modules/pear_module.inc(70): mysql_driver_ADOConnection->do_query('select COUNT(*)...', -1, -1, false)
#2 /..../core/adodblite/generic_modules/pear_module.inc(56): pear_ADOConnection->GetRow('select COUNT(*)...', false, true)
#3 /..../core/oxlegacydb.php(89): pear_ADOConnection->GetOne('select COUNT(*)...', false)
#4 /..../core/oxutilsview.php(508): oxLegacyDb->getOne('select COUNT(*)...')
#5 /..../core/smarty/plugins/prefilter.oxblock.php(44): oxUtilsView->getTemplateBlocks('email/html/regi...')
und einer aus dem php_error.log:
[02-Feb-2014 05:25:46 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /..../core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 05:25:47 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /..../core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 05:25:51 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /....core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 06:05:39 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /..../core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 06:05:39 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /..../core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 06:05:39 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /..../adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 06:05:39 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /..../core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 06:05:39 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /..../core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 07:34:06 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /..../core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 07:34:06 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /..../core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 07:34:06 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /..../core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 07:34:06 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /.....core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 07:34:06 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /..../core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 07:34:07 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /..../core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 07:34:07 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /..../core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 07:34:07 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /..../core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 07:34:07 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /..../core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 07:34:08 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /..../core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 07:34:12 Europe/Berlin] PHP Strict Standards: Only variables should be assigned by reference in /..../core/adodblite/adodbSQL_drivers/mysql/mysql_meta_module.inc on line 377
[02-Feb-2014 08:35:54 Europe/Berlin] PHP Fatal error: Uncaught exception 'oxAdoDbException' with message 'mysql:EXECUTE error: [2006: MySQL server has gone away] in EXECUTE with parameters select oxproductive from oxshops where oxid = "oxbaseshop", for user ---------
' in /..../core/adodblite/adodb-exceptions.inc.php:84
Was tun? Weiß jemand Rat?
Die Fehler treten täglich auf und der Shop ist seither nicht mehr stabil…
Die ADODB-Exceptions wurden mit 4.7.10 verfeinert und jetzt werden Exceptions geschmissen, die vorher nicht aufgetreten sind. Die Fehlermeldungen zeigen ja konkret an, mit welchen SQL-Statements die Fehler auftreten.
Zumeist fehlt eine Tabellenspalte oder Ähnliches bzw. die Module wurden nicht sauber programmiert.
Der Fehler ist immer der selbe - siehe obiger Log Auszug:
mysql_meta_module.inc on line 377
select oxproductive from oxshops where oxid = “oxbaseshop”, for user ---------
Das kommt doch aus dem Oxid CORE System???
(Den User habe ich auskommentiert)
Hat niemand eine Idee? Der Shop fliegt uns ständig um die Ohren - das war vorher nicht so - kann man die optimierungen wieder rückgängig machen???
Hi,
nimm doch mal alle installierten Module raus und füge sie Stück für Stück wieder hinzu. Zwischendurch probierst Du, ob der Shop funktioniert.
Gruß
Der Punkt ist - das ist ein produktiver Shop - die Module sind nicht zum Spaß aktiviert, sondern werden benötigt.
Zweitens tritt der Fehler sporadisch auf - ca. 4x am tag aber nicht reproduzierbar.
Außerdem lief der Shop mit all diesen Modulen bis VOR dem Upgrade absolut fehlerfrei.
Zu guter Letzt- das SQL Statement, welches abbricht ist wie oben erwähnt immer das selbe und außerdem noch trivial:
select oxproductive from oxshops where oxid = "oxbaseshop", for user ---------
ich wüsste nicht aus welchem Modul das stammen sollte. - das ist wird doch von Oxid Core abgesetzt oder?
Der Sinn, die Module zu deaktivieren erschließt sich mir nicht ganz???
Das machst Du um herauszufinden, ob und an welchem Modul es ggf liegt. Und bitte zunächst in der Entwicklungsumgebung 
Gruß
Danke für den Hinweis.
Was lerne ich daraus?
Um oxid updates unfallfrei verwenden zu können benötige ich nicht nur wie bisher 3 umgebungen (dev, test, prod).
bisher machte ich grössere updates in der testumgebung, dort bin ich schon auf 4.8. nein, ich brauche auch für minor releases eine separate testumgebung um z.b. von 4.7.8 auf 4.7.10 zu gehen. im konkreten fall habe ich also pech . zumal das problem nur unter last auftritt und ich im test auch nicht mehr auf 4.7 zurück kann!
ganz schön aufwendige release- und updatepolitik
Also bitte. Bisher habe ich versucht, Dir Ratschläge zugeben, wie Du dem Verhalten auf die Spur kommen kannst. Dabei ist Dir natürlich freigestellt, ob Du diese Ratschläge beachtest oder nicht.
Der Punkt “tritt nur unter Last auf” kam vorher noch nicht. Insofern hat das wohl ganz wenig mit Updatepolitik zu tun.
Marco,
ich weiss nicht wie ich es noch anders ausdrücken soll:
Ich würde deinen Ratschlag liebend gerne umsetzen - allerdings muss ich dafür eine 4. (!!) Umgebung hochziehen das ist nicht nur aufwendig sondern in Anbetracht der Tatsache, dass ich eine lapidaren Patch einspielen wollte, mehr als ärgerlich.
Ich will hier kein Fingerpointing machen - die nackte Tatsache ist, dass für mich Oxid Updates mittlerweile echt ein Wagnis sind, das ich immer weniger gern eingehen möchte.
Das ist eine Feststellung und hat nichts mit Deinen Ratschlägen zu tun - die ja ok sind, aber leider bin ich momentan handlungsunfähig diesbezüglich (aus oben genannten Gründen) - und das möchte ich hier fest halten.
Aber, aber, aber…
es geht hier doch lediglich um ein patch Update über zwei Nummern: 4.7.8 auf 4.7.10. Was kann da schief laufen, das nicht wieder rückgängig gemacht werden könnte?
Und warum ist in dem Fall die Entwicklungsumgebung für diesen Shop schon auf 4.8?
Verstehste, ich versuche herauszubekommen, was Du da grad treibst, um Dich hier unterstützen zu können. “Handlungsunfähig” ist immer der Zustand, den man am wenigsten haben möchte.
Gruß
Ok - ich gebe mir Mühe…
Die Sache ist folgende - nachdem ich in der Testumgebung den Upgrade auf 4.8 gemacht habe ging zunächst gar nichts mehr .
Grund ist, dass wir leider immer noch an das BASIC Template gebunden sind, was unter 4.8 gänzlich und wohl leider endgültig ausscheidet. (dazu gibts irgendwo auch einen Thread von mir).
Also gehe ich hin und ziehe meine DEV Umgebung ebenso auf 48.x hoch und beginne mit der Umstellung von Basic auf Azure…das dauert aber noch ne Weile…weil der Auftraggeber quasi keine optischen Veränderungen zum Basic Template wünscht.
Somit bin ich in DEV und Test auf 4.8.x
Prod lief aber unter 4.7.8 absolut stabil bis auf ein Problem, dass man aus der Lieferantenauswahl nicht in die Produktdetails verzweigen konnte.
Dieses Problem war laut Bugtracker unter 4.7.10 behoben - also freue ich mich und spiele 4.7.10 ein.
Das Problem ist jetzt auch weg, aber dafür habe ich ein anderes…
“Schach”.
Also - ich bin jetzt ein Stück weiter, nicht wirklich schlauer aber weiter:
Nach mehreren einschlägigen Erfahrungen mit dem 1und1 Hosting, hatte ich den Verdacht, dass wir evtl. kein Problem im Oxid Shop haben, sondern ggf. ein Problem mit der mysql Performance, - serverbedingt.
Also sind wir jetzt auf einem Managed Server mit 2 GB RAM.
Die Mysql Performance ist immer noch nicht ok - die Leute von 1und1 sagen mir, ich solle die Indexe neu erstellen, bzw. aktualisieren.
Leider finde ich hier widersprüchliche Aussagen im Netz, die einen sagen, Mysql aktualisiert beim insert die indexe selbst, die anderen sagen, (wie 1und1) diese müsse man von Zeit zu Zeit rebuilden.
Meine Fragen an die Profis:
WIE Aktualisiere ich die Indexe im Oxid Shop, insbesonder bei InnoDB Files? Muss ich per ALTER Table alle weglöschen und neu erstellen?
Gibt es von Oxid (oder sonst jemandem) hierfür ein Script?
Gibt es eine Script zur Überprüfung der DB Struktur?
Fragen über Fragen, aber ich komme einfach nicht weiter…
[SOLVED!]
Ich denke ich habs jetzt geschafft:
Aus irgendeinem Grund, den ich noch nicht kenne wurden in diversen Tabellen die Indizes disabled.
Nachdem ich alle Tabellen mit
SHOW INDEX FROM <table>
abgefragt habe und beim Ergebnis disabled Keys wieder mit
ALTER TABLE <table> ENABLE KEYS
aktiviert habe, scheint alles wieder ultraflott zu laufen…
Testphase beginnt jetzt aber ich bin zuversichtlich…
Wenn jemand weiss oder eine Ahnung hat, warum die indizes disabled wurden…ich bn gespannt!