Hoster stellt PHP 5.6 ein - Neuinstallation 2.0.4.2 und Import von 1.0.6 Daten

[Singer]

Tutorial für die DB ist verstandenen aber die grundlegendes Shop Installation nicht noch mal neu... oder?

Sorry wenn die Fragen blöd erscheinen mögen, ich möchte nur sicher gehen

[Markus]

Hi Singer,

doch ... mach es Schritt für Schritt nach der Anleitung ... dann sollte es auch funktionieren.

Markus

[Singer]

Okay, macht nichts.

Sehe gerade ein PHPMyAdmin dass die alte DB  latin1_german1_ci war und die neue  utf8_general_ci

Muss ich da noch was ändern?

[Singer]

Bis hier schon mal VIELEN DANK Markus!

Die Änderung der HTACESS hat funktioniert - kein 500 Fehler.

Test Shop ist schon mal da nun kommt der Rest - ich bleibe gespannt...  

[Singer]

Bisher alles hübsch...

Frage zum SQLDumper.

Ich nehme an, dass ich die DB Sicherung vom 1.0.6 (PHP5) und das Einspielen im Test Shop 2.0.5 (der nach Änderung der htaccess auch auf PHP5 läuft) jeweils mit dem SQLDupmer erledigen kann, richtig?

Ich brauche jetzt nicht den MyOOSDumper, der PHP 7 fähig, ist für den 2.0.5 Shop, richtig?

Ist sicher wieder ne doofe Frage aber besser doof dastehen als blöde Fehler zu machen.

============================

Dann zum Umstieg auf PHP 7.3

Wenn der neue 2.05. Shop lauffähig ist, kann ich dann einfach auf PHP 7.3 umstellen oder muss ich die geänderte htaccess wieder in den original Zustand ändern? Und sind ggf. weiter Änderungen erforderlich?

[Singer]

Falls es jemanden interessiert  - MYSQLDUMPER konnte ich in der 2.0.5.0 Version nicht mehr installieren, auch trotz der geänderten htaccess. Ist evtl auch bekannt, ich hatte was anderes gehofft bzw. vermutet und weitere Hinweise konnte ich nicht ergoogln (oder ich war zu dusselig zum suchen), aber egal.

Habe nun in der 2.0.5.0 Version MYOOSDUMPER in der aktuellen Version installiert und damit die DB vom neuen und alten Shop gesichert (hier wurden mir beide DB angezeigt) und über der MYSQLDDUMPER in der alten 1.0.6. Installation konnte ich auch beide DB sichern. Das Einspielen sollte somit wohl kein Problem sein aber ich bleibe dennoch gespannt.

Das nur falls jemand mal in einer ähnlichen Situation sein sollte.

Morgen sehen wir weiter...

[Tante Uschi]

@ Singer

das machst Du richtig gut, hier eine Art Tagebuch zu schreiben, da ich gerade kurz davor bin das selbe Problem zu haben, MYSQLDUMPER funktioniert nämlich auch dann nicht wenn man Teile einer 2.0.4.2 Datenbank in die Datenbank eines erweiterten und umgebauten 2.0.4.2 Testshops einfügen will, was mich dabei speziell interessiert ist, ob die Indexeinträge unverändert bleiben?

Dies ist nämlich gerade mein Knackpunkt, da bei Einspielung einer Datenbanktabelle (z.B. categories) über phpmyadmin die vorhandene Tabelle gelöscht werden muss um eine Tabelle wieder zu importieren und entscheidend ist, was die Index Einträge der Tabelle dabei machen.

Für mich ist also interessant zu wissen, wie sich MYOOSDUMPER dabei verhält, behält er die Indexeinträge bei, ersetzt also einfach die Zeilen der Tabelle ohne diese vorher komplett zu löschen oder löscht er sie wie man es von Hand machen müsste behält dabei aber die Indexeinträge der Tabelle? Denn fehlerhafte Indexeinträge können sehr lästig sein.

Gruß

[noRiddle (revilonetz)]

Auf die Indices muß man in der Tat achten. Irgendwo gibt es in sowohl in mySQLDumper als auch in myOOS[Dumper] eine Checkbox dafür (weiß gerade nicht wo, länger nicht benutzt). Es ist nämlich sinnvoll für einen schnnelleren Import die Indices zu deaktivieren um sie anschließend wieder zu aktivieren.
Jedenfalls kann es sein, wenn man nicht aufpasst oder es schlicht nicht weiß, daß nach Reimport oder Wiederherstellung einer DB oder auch nur bestimmter Tabellen, die Indices deaktiviert sind.
Man kann das prüfen indem man diesen Befehl absetzt:

Code: SQL  [Auswählen]

SHOW INDEXES FROM tabellenname;

Das Problem ist nur, daß man das per Hand für alle Tabellen machen müsste.

Wer es braucht kann ein kleines PHP-Skript bauen und im Backend implementieren.
Mit diesem Code schreibt man alle relevanten Daten in ein Array und kann sich dieses entweder ausgeben lassen oder die Daten in eine HTML-Ausgabe (z.B. Tabelle) schreiben.

Code: PHP  [Auswählen]

require_once(dirname(__FILE__).'/includes/application_top.php');

$table_query = xtc_db_query("SHOW TABLES");
while ($row = xtc_db_fetch_row($table_query)) {
    $tables[] = $row[0];
}
natsort($tables);

foreach($tables as $key => $table_name) {
    $ind_sql = "SHOW INDEXES FROM ".$table_name;
    $ind_query = xtc_db_query($ind_sql);
    while($indxs = xtc_db_fetch_array($ind_query)) {
        $indxs_table_arr[$table_name][] = array('Key_name' => $indxs['Key_name'], 'Column_name' => $indxs['Column_name'], 'Cardinality' =>  $indxs['Cardinality'], 'Comment' => $indxs['Comment']);
    }
}
//echo '<pre>'.print_r($indxs_table_arr, true).'</pre>';

Wenn bei Comment "disabled" steht sind die Indices deaktiviert und man muß diesen Befehl laufen lassen:

Code: SQL  [Auswählen]

ALTER TABLE tabellenname ENABLE KEYS;

Wenn Cardinality leer oder 0 ist sollte man

Code: SQL  [Auswählen]

ANALYZE TABLE tabellenname;

laufen lassen.
Die Cardinality zeigt an wieviele verschiedene Einträge für einen Index die jeweilige Tabelle hat.
Wenn die Cardinality leer ist oder 0 wirkt der betroffene Index nicht und die Queries die ihn benutzen sollten sind langsam.
So sollte  z.B. bei Verwendung von Artikelnummern der Index idx_products_model auf der Tabelle products der Anzahl der Artikel in der Tabelle entsprechen.

Das alles per Hand zu machen ist natürlich aufwändig.
Ich empfehle deshalb sich ein Skript zu bauen welches eine Art Datenbank-Pflege-Tool darstellt und mit welchem man die erwähnten Prüfungen und Fixes per Click durchführen kann.
So ein Tool fehlt eigtl. im modified eCommerce Shop.

Gruß,
noRiddle

[Timm]

Gilt das gleiche für phpmyadmin? Wenn man da eine DB exportiert und in einem Testshop wieder importiert? Dann wäre der Testshop vermutlich langsamer als der Originalshop.

Werden die Indizes bei einem Shopupdate durch das DB Strukturupdate wieder automatisch gesetzt?

Gruß Timm

[Tante Uschi]

@  noRiddle

vielen Dank dafür !

Gruß

[noRiddle (revilonetz)]

@FräuleinGarn
Wenn du in phpMyAdmin eine DB oder auch einzelne Tabellen exportierst passiert nichts mit den Indices.
Schau mal in so eine generierte +.sql-Datei mit einem Editor. Da wirst du so etwas in der Art sehen (am Beispiel Tabelle categories):

Code: SQL  [Auswählen]

ALTER TABLE `categories`
  ADD PRIMARY KEY (`categories_id`),
  ADD KEY `idx_categories_parent_id` (`parent_id`);

Damit werden die Indices gesetzt.

Wenn irgend etwas im Shop lahm ist kann man in phpMyAdmin auch schnell mal prüfen ob alles okay ist mit den gesetzten indices oder Keys. Wenn man für eine Tabelle auf "Struktur" klickt sieht man unten die gesetzten Indices und auch die "Kardinalität" (cardinality) und eine Spalte für "Kommentar". In letzter würde stehen wenn Keys disabled sind.

Gruß,
noRiddle

*NACHTRAG*
Struktur-Updates bei Shop-Updates machen an Indices nichts kaputt.

[Timm]

Danke dir. Mir ging es beim Strukturupdate nicht um kaputtmachen, sondern erneutes Setzen eines Indizes, falls er fehlen sollte. Wobei das auch kaputtmachen wäre, wenn man selbst an den Indizes was optimiert hätte.

Hab nun mal live Shop 2.0.4.2 und Testshop 2.0.5.0 verglichen. In der Tabelle products sind die Indizes in beiden Shops gleich.

Allerdings in der von dir angesprochenen Tabelle categories fehlt es an Werten für Kardnalität für die Indizes parent_id und categories_status im Testshop.

[ Für Gäste sind keine Dateianhänge sichtbar ]

[ Für Gäste sind keine Dateianhänge sichtbar ]

Die DB des Testshops wurde aus einer in PHPmyadmin exportierten DB des Liveshops und mit PHPmyadmin wieder importierten DB im Testshop erstellt. Komisch.

Das könnte ja nun schlecht sein, wenn man diese DB exportiert und in einem Liveshop eingpflegt. Warum auch immer (kein Backup oder sowas) Ich werde bei einem Update die original DB updaten, weil ja auch Bestellungen dazugekommen sind seit Testbeginn.

Gruß Timm

[noRiddle (revilonetz)]

Ein Struktur-Update ändert ja nur gewollte Dinge, wirft Indices raus die nicht gewünscht sind, setzt bei Bedarf neue und ergänzt evtl. Tabellen und Felder.

Bei dem Index auf categories_status wäre es jetzt nicht so schlimm weil es da ohnehin lediglich 2 verschiedene Werte gibt und der Index ohnehin nichts bringt.
Bei parent_id könnte er wichtig sein.
Einfach mal das durchfühern und die Cardinalities sind da.

Code: SQL  [Auswählen]

ANALYZE TABLE categories;

Gruß,
noRiddle

[Timm]

Ja das funktioniert. Vielen Dank.

Hatte erst auf Tabellenstruktur analysieren geklickt und das ging nicht. Dann auf der Startseite der DB die Tabelle categories angeklickt und dann ganz unten "markierte Tabelle analysieren" (was das selbe wie deine Codezeile ist, aber manch einer traut sich ja vielleicht nicht die SQL Statements abzusetzen und macht es lieber mit sichtbaren Mausklicks). Danach waren für beide Kardinalitäten wieder Werte vorhanden.

Ich frag mich halt nur wie es dazu kommen kann, dass es gefehlt hat? Zumal danach ja dann noch das normale DB Update und das DB Struktur Update für 2.0.5.0 über die DB lief. Und dennoch ist der Wert für Kardinalität des Indizes parent_id nicht vorhanden gewesen. Also setzt das Update doch nicht nicht vorhandene Indizes und Kardinalitäten automatisch. Das wiederum heißt, dass man sich alle Tabellen mal anschauen müsste und die Indizes gegen eine frische Testinstallation vergleichen müsste, wenn man irgendwann mal bei Serverumzug zb die DB exportiert und importiert hat. Oder würde es reichen alle Tabellen zu analysieren? Schwieriges Thema. Oder werden diese Kardinalitäten aus den Inhalten der Tabellen berechnet und können so gar nicht vom Update gesetzt werden, weil bei jedem unterschiedlich?

Gruß Timm

[noRiddle (revilonetz)]

Die Cardinality setzt mySQL selbst, hat nichts mit irgendwelchen Updates zu tun.
Warum die Cardinality manchmal zu niedrig oder gar 0 ist soll angeblich von vielen INSERT, UPDATE und DELETE Aktionen kommen. Man kann sagen, imho, wenn man oft viele Artikel neu einpflegt und andere löscht sollte man ab und zu

Code: SQL  [Auswählen]

ANALYZE TABLE tabellenname;

laufen lassen. Dasselbe gilt für Kategorien und allen anderen Inhalte.

Wie ich bereits sagte, so ein DB-Pflege-Tool fehlt eigtl. im modified -Shop.
(Ich habe so etwas mal für einen Kunden gebaut. Das Tool kann aber noch mehr und ist zu speziell für den Nutzer, sodaß ich es nicht einfach zeilen kann.)

Gruß,
noRiddle