Anwendungen

Oracle Database recovery

29. August 2009 · Anwendungen · andreas · Kein Kommentar

Stellt sich Oracle beim Datenbank-Recovery etwas umständlich an, so muß man etwas tiefer in die Trickkiste greifen:

Erfahrungsgemäß läuft ein

RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

meist damit gegen die Wand, daß Oracle versucht, auf ein nicht existierendes, archiviertes Logfile zuzugreifen. Ergebnis sind in der Regel der Fehler

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '<woauchimmer>system01.dbf'

was aber nicht unbedingt bedeutet, daß sich das Problem tatsächlich auf die eine Datei beschränkt.

Sollte dies der Fall sein, muß für ein erfolgreiches Recovery noch das aktuelle Redo-Log verwendet werden. Hierzu ist zuerst das aktuelle Log zu ermitteln

SELECT member FROM v$logfile , v$log WHERE v$log.status='CURRENT' AND v$logfile.group# = v$log.group#;

anschließend nochmals ein Recovery zu starten, hierbei allerdings weder ‘AUTO’ noch ‘CANCEL’ zu wählen sondern das soeben ermittelte Logfile anzugeben.

RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

Hat alles geklappt, sollte ein

ALTER DATABASE OPEN RESETLOGS;

zum gewünschten Erfolg führen.


mod_mostread übergeht Beiträge

30. Mai 2009 · Anwendungen · andreas · Kein Kommentar

Nach der Aktivierung von mod_mostread (“Meistgelesene Beiträge”) war die Verwunderung groß, denn die Liste stimmt nicht mit denen unter “Popular” im Kontrollzentrum überein.

Das Problem liegt in der Auswahl der Beiträge - während “Popular” eine Übersicht über alle vorhandenen Beiträge bietet, werden bei mod_mostread nur solche gezählt, die einem Bereich und einer Kategorie zugeordnet sind. Nicht kategorisierte Beiträge werden von mod_mostread übergangen.


MySQL, Unicode und die Kommandozeile

8. März 2009 · Anwendungen · andreas · Kein Kommentar

Manchmal können komplizierte Dinge so einfach sein - mit dem richtigen Parameter klappt der Import von Unicode-Dateien problemlos über die MySQL-Kommandozeile:

mysql --default_character_set utf8 datenbank < sql-file

Splash page in Joomla!

7. März 2009 · Anwendungen · andreas · 3 Kommentare

Will man eine Splash page in Joomla! anlegen, so ist “um die Ecke denken” angesagt. Als erstes wird die gewünschte Seite als “index.html” (wahlweise auch “splash.html” oder was auch immer) ins Hauptverzeichnis der Installation geschoben und die “.htaccess” um folgenden Eintrag ergänzt:

DirectoryIndex index.html index.php

Ruft nun ein Besucher die Domain der Website auf, so wird als erstes die “index.html” präsentiert, aus der man dann zu Joomla! weiterverlinken kann.

Das klappt auch prima, bis man im Menü der Website auf den Link zur Startseite (Default Menu Item) klickt und entsetzt feststellt, daß Joomla! diesen grundsätzlich nur mit einem “/” als URL hinterlegt und man wieder auf der Splash page landet.

Leider lässt sich dieses Verhalten weder im Menu Manager noch in den Moduloptionen ändern und ein Hack der entsprechenden Moduldatei ist auch nicht so prickelnd.

Ein Workaround ergibt sich aber über einen Umweg:

Es wird ein neues Menü angelegt (z.B. “Dummy”) in dem man einen Link zur Startseite der Joomla!-Installation packt und dieses Item wird als Default Menu Item gekennzeichnet, das Menü selbst aber nicht auf der Site eingebunden.

Im eigentlichen Menü zeigt der vorher noch auf “/” verlinkende Menüpunkt nun auf die vollständige URL, so daß die Splash page nicht mehr angesprungen wird.


Erstellungsdatum ohne Uhrzeit in Joomla!

7. März 2009 · Anwendungen · andreas · Kein Kommentar

Leider gibt es keine einfache Möglichkeit, in Joomla! bei der Anzeige des Erstellungsdatums die Uhrzeit auszublenden.

Die verschiedenen Ausgabeformate sind in den Sprachdateien unter “language//.ini” gespeichert, also z.B. “language/en-GB/en-GB.ini” Hier kann dann direkt die Definition von “DATE_FORMAT_LC2” angepasst werden, daß sie wie folgt aussieht:

DATE_FORMAT_LC2=%A, %d %B %Y

Diese Vorgehensweise hat aber den Nachteil, daß hierbei eine Core-Datei geändert wird, die theoretisch mit jedem Update wieder überschrieben werden kann und somit eine Dauerbaustelle eingerichtet wird.

Als sinnvollere Vorgehensweise bietet sich entweder die Einführung einer eigenen Sprachdatei im Template an oder - falls man sowieso mit Overlays arbeitet - eine Änderung der entsprechenden Ausgabe in der Overlaydatei. Hier kann einfach nach “JText::_(‘DATE_FORMAT_LC2’)” gesucht und “DATE_FORMAT_LC2” durch ein eigenes Ausgabeformat ersetzt werden.