Datenbank-Schema prüfen

Diese Seite ist noch nicht vollständig übersetzt.

Siehe en:Verify Database Schema

Wenn Sie Ihre Moodle Installation aktualisiert haben, insbesondere wenn Sie Ihr System über mehrere Versionsschritte geupgradet haben, ist es möglich, ja geradezu wahrscheinlich, dass sich kleine Unterschiede bei den Tabellendefinitionen Ihrer Datenbank zu einer vollkommen neuinstallierten, aktuellen Moodle-Datenbank eingeschlichen haben. Dies kann passieren, wenn kleine Tabellenänderungen durch die Upgrade-Skripte nicht berücksichtigt wurden. Die meisten dieser nicht nachvollzogenen Tabellenveränderungen mögen harmloser Natur sein, andere wiederum verursachen seltsame, unerwartete Fehler.

Wenn zum Beispiel ein Feld nunmehr verpflichtend einen Wert haben muss, dann müßte ein Upgrade-Skript die Felder des Altbestands entsprechend mit einem Vorgabewert füllen, ansonsten würde eine Programmverarbeitungsroutine, welche ja nunmehr immer einen Wert in diesem Feld erwartet, möglicherweise fehlerhaft darauf reagieren.

Um die Konsistenz Ihrer Datenbank nach dem Upgrade sicherzustellen, vergleichen Sie am besten das Datenbankschema ihres in "Produktion" befindlichen Systems mit dem Schema einer Neuinstallation derselben Versionsnummer. Es gibt eine Reihe von Möglichkeiten dies zu tun. Wir wollen Ihnen hier eine einfache kommandozeilenbasierende Methode für Windows und Unix aufzeigen.

• Führen Sie das Upgrade ihres Moodle Systems vollständig durch
• Erstellen Sie mit dem folgenden Befehl ein Datenbankschema von Ihrem soeben aktualisierten System:

   mysqldump -d -u root -p myproductiondb >production.schema

• Copy the code of your production database to a new (web accessible) location (this is important, it *must* be the same version)
• Create a new, empty database and moodledata area for the new site as per the Installation instructions
• Edit the config.php file to point at the new database and locations, or delete it and use the install script
• Run the install script to generate the (if applicable) config.php file and the database (admin and site values are not important)
• Generate the database schema from your new site using the following command:

   mysqldump -d -u root -p mycleandb >clean.schema

• Run the following command to detect the differences

   diff -y production.schema clean.schema >db.diff

Nun können Sie die db.diff Datei mit Ihrem bevorzugten Editor öffnen und sich die Unterschiede in den Datenbankschematas ansehen.

Auswertung der db.diff Datei

Beispiel für eine Ausgabe:

    --
    -- Table structure for table `mdl_backup_config`
       @@ -129,11 +93,11 @@
        DROP TABLE IF EXISTS `mdl_backup_config`;
        CREATE TABLE `mdl_backup_config` (
   -  `id` int(10) unsigned NOT NULL auto_increment,
   +  `id` bigint(10) unsigned NOT NULL auto_increment,
      `name` varchar(255) NOT NULL default ,
      `value` varchar(255) NOT NULL default ,
       PRIMARY KEY  (`id`),
   -  UNIQUE KEY `name` (`name`)
   +  UNIQUE KEY `mdl_backconf_nam_uix` (`name`)
        ) ENGINE=MyISAM AUTO_INCREMENT=15 DEFAULT CHARSET=utf8 COMMENT='To store backup configuration variables';

In einer db.diff Datei können viele Änderungsbereiche aufgeführt sein.

• Eine Zeile mit einem vorangestellten - kennzeichnet eine Zeile, die herausgenommen wurde.
• Eine Zeile mit einem vorangestellten + kennzeichnet eine Zeile, die hinzugekommen ist (Produktion -> Neuinstallation).

In unserem Beispiel wurde der Datentyp int durch eine bigint Definition ersetzt und gleichzeitig hat sich die Unique Index Definition von name auf nunmehr mdl_backconf_nam_uix geändert. Technisch gesehen, hätten beide Veränderungen während des Laufes eines Upgrade-Skriptes berücksichtigt werden müssen, sind aber vergessen worden. Auf Grund der Natur der beiden obigen Tabellendefinitionsunterschiede dürften diese die Funktionsweise von Moodle in der Regel nicht beeinflussen, sollten aber korrigiert werden.

Muss ich mir Sorgen machen?

Veränderungen bei den Feldtypdefinitionen sind unkritisch, solange die Datentypen kompatibel zueinander sind (z. B. int -> bigint). Ebenso sind Wechsel bei den Tabellenschlüsseln häufig zu beobachten, gehören aber auch in die Kategorie von Unterschieden, die gewöhnlich keine Probleme beim Betrieb bereiten sollten.

Wonach Sie besonders Ausschau halten müssen, sind fehlende Felddefinitionen und Veränderungen bei den DEFAULT-Werten der Felder.

Siehe auch

• The missing indexes report in SiteAdmin->Misc->XMLDB editor->Check Indexes
• Moodle Databases Forum