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.

The file may have lots of blocks of changes. The - lines show lines to be taken out and the + lines the ones to replace them (from the production to the clean). In unserem obigen Beispiel wurde der Datentyp int durch eine bigint Definition ersetzt und gleichzeitig hat sich wurde der Unique Index von name auf nunmehr mdl_backconf_nam_uix geändert. Wahrscheinlich beeinflußen diese beiden Änderungen nicht die Funktionsweise von Moodle.

So here, the int has been replaced with a bigint and the key name changed. Both of these, technically, should have been changed at some point by upgrade scripts but have been missed. In this case they are unlikely to affect the operation of Moodle.

Sollte ich mir Sorgen machen?

Changes in field types (as long as they are compatible) and key name changes seem to be the common issues but should not cause problems. Things to look out for would be along the lines of missing fields and changes to default values.

See Also

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