Hoffentlich nützliche Tipps

Sofern man mit Eclipse BIRT auch PDFs erzeugen möchte, die nicht nur Helvetica, Times-Roman oder Courier als Schrift verwenden, müssen die zusätzlichen Fonts in der Runtime-Umgebung bereitsgestellt und eingebunden werden.

Im Internet finden sich einige Hinweise darauf, wie man zusätzliche TrueType-Fonts in die Eclipse BIRT Runtime einbinden kann. Leider beziehen sich diese Hinweise meistens auf ältere BIRT-Versionen (2.x und 3.x).

Zu neueren Versionen (ab 4.x) gibt es kaum Informationen, auch eine offizielle Anleitung scheint nicht verfügbar zu sein. In diesem Tipp haben wir daher beispielhaft zusammengestellt, wie es funktioniert.

Die Umgebung:

• Redhat- oder Oracle-Linux
• Tomcat Version >= 7
• Birt Version >= 4.3.1

Die BIRT Runtime wird als birt.war im Tomcat deployed. Der Inhalt des birt.war-Files liegt nach dem Deployment unter /webapps/birt.
Hier findet sich im Unterverzeichnis WEB-INF/lib die Datei org.eclipse.birt.runtime_4.3.x.vxxxxxxxx–xxxx.jar (der genaue Name ist abhängig von der BIRT Versionsnummer). In diesem jar-File eingepackt ist die für uns wichtige Datei fontsConfig.xml. In dieser Datei stehen die Suchpfade für die Font-Dateien.

In älteren BIRT-Versionen wurde dieses jar-File beim Deployment ausgepackt und man konnte die Datei fontsConfig.xml einfach editieren. Bei den neueren Versionen ist dies leider nicht mehr der Fall – beim Deployment bleibt das .jar-File wie es ist.
Prinzipiell könnte man die Datei fontsConfig.xml aus dem .jar extrahieren (JAR ist ja auch nur ZIP), editieren und anschließend wieder neu zusammenpacken.
Leider ist diese .jar-File signiert, und die Signatur wäre nach der Änderung ungültig.

Wenn man jedoch einfach die fontsConfig.xml aus dem .jar extrahiert und einen Blick hinein wirft kann man die voreingestellten Suchpfade sehen – also die Pfade, in denen BIRT standardmäßig nach Font-Dateien sucht. In der Datei sind alle möglichen Pfade für Windows und Linux/Unix hinterlegt – man kann sich einfach einen aussuchen.
Wir haben uns für /usr/share/fonts/truetype entschieden. Das Unterverzeichnis existiert auf Linux/Unix normalerweise nicht, daher muss man es erst anlegen. Anschließend kopiert man die benötigten TrueType-Dateien in dieses Verzeichnis.

Jetzt muss noch Tomcat bzw. BIRT neu gestartet werden (nur zu diesem Zeitpunkt wird nach vorhandenen Fonts gesucht), und schon stehen die neuen Fonts für die BIRT Runtime zur Verfügung.

Aufpassen muss man jedoch, dass man alle notwendigen Fontvarianten (also z.B. auch Bold und Italic) kopiert – diese sind nicht unbedingt alle in einer Datei enthalten.
Um den genauen Inhalt der Fontdateien zu sehen wechselt man in das Verzeichnis mit den TrueType Fonts und ruft das Programm ttmkfdir auf. Dieses Programm analysiert die im Verzeichnis vorhandenen .ttf-Dateien und erzeugt daraus die Datei fonts.scale.
In dieser Datei wird aufgelistet, welche .ttf-Datei welche Schriftart in welchen Zeichensätzen (z.B. iso8859-15 oder ansi-1251) und welchen Schriftschnitten enthält. Alle diese Varianten können im BIRT-Report verwendet werden.

In diesem Tipp wird das Vorgehen für Linux beschrieben. Unter Windows funktioniert es jedoch analog genauso.

Sie arbeiten mit Oracle ASM, welches auf einer externen Storage liegt. Das ASM-Volume soll nun vergrößert werden.
Die Storage ist beispielsweise über FibreChannel angeschlossen. Aus Gründen der Ausfallsicherheit wird Multipath verwendet.
Daher muss jetzt auf mehreren Ebenen die Größenänderung bis zum ASM durchgereicht werden.

1. Zuerst wird das Volume auf der Storage wie gewünscht vergrößert
2. Linux erkennt die geänderte Größe nicht automatisch.
   1. Variante A:
      Auf allen beteiligten Clusterknoten (bei RAC) müssen die entsprechenden Multipath-Platten (jede einzelne auf jedem Knoten!) neu gescannt werden:
      echo 1 > /sys/block//device/rescan
      z.B. echo 1 > /sys/block/sdb/device/rescan
   2. Variante B:
      Jedes Device muss mit „blockdev“ neu eingelesen werden (jedes einzeln auf jedem Knoten!):
      blockdev –rereadpt /dev/sdxx
      z.B. blockdev –rereadpt /dev/sdb
3. Über „dmesg“ oder „fdisk -l /dev/sdxx“ sollte man jetzt die geänderte Größe sehen. Bitte wirklich jedes einzelne Device überprüfen!
4. Jetzt muss noch der Multipath-Deamon die geänderte Größe erkennen:
   multipathd -k“resize map <multipath_name>“
   (z.B. multipathd -k“resize map asm_data“)
   Dieser Schritt muss ebenfalls auch allen beteiligten Clusterknoten erfolgen!
5. Jetzt kann die ASM Diskgroup vergößert werden. Dieser Schritt muss nur auf einem Knoten durchgeführt werden:
   sqlplus / as sysasm
   SQL> alter diskgroup resize all;Alternativ kann man auch eine einzelne Platte in der Diskgroup vergrößern:
   SQL> alter diskgroup resize disk ;
   also z.B.
   SQL> alter diskgroup testdata resize disk TESTDATA_0000;
6. Über asmcmd kann man direkt überprüfen, dass das Volume vergrößert ist.

Das war’s auch schon. Diese Aktionen können vollständig Online erfolgen.

Wenn man versucht, Java in einer VirtualBox mit Windows zu starten, passiert scheinbar nichts! Im TaskManager sieht man jedoch den Prozess javaw.exe, welcher 100% einer CPU belegt.

Ursache ist eine Unverträglichkeit zwischen der 3D-Erweiterung in der VirtualBox und der 3D-Verwendung von Java. Das passiert insbesondere dann, wenn man die Gasterweiterungen in der VirtualBox aktualisiert hat.

Die Lösung ist jedoch einfach:

Im Windows in der VirtualBox einfach eine systemweite Umgebungsvariable anlegen:
J2D_D3D=false

Dann versucht Java nicht mehr, mit der 3D-Erweiterung zu arbeiten und funktioniert wieder problemlos!

Bei Oracle Linux 6 kann es zu seltsamen „Wartezuständen“ beim Login (z.B. über ssh) oder beim „su“ kommen.
Die üblichen Verdächtigen (UseDNS in der /etc/ssh/sshd_conf, fehlender Nameserver in /etc/resolv.conf) sind bereits gefixt, das Problem besteht dennoch.
Im „top“ ist pro Prozessorcore ein Prozess „powersave_cpux“ und „migration_cpux“ zu sehen, die die Prozessoren teilweise zu 100% auslasten. Dies ist aufgefallen bei verschiedenen neueren Dell-Servern mit 6Core-CPU, kann aber auch andere Server betreffen.

Das Problem kommt von einem buggy Kernelmodul: acpi_pad
Kurzfristig hilft, dieses Modul einfach zu entladen „rmmod acpi_pad“.
Danach sollte schon alles ganz normal laufen.

Damit dieses Modul bei reboot nicht wieder geladen wird muss folgende Zeile in die Datei /etc/modprobe.d/blacklist.conf eingetragen werden:
blacklist acpi_pad

Der Fehler betrifft (mindestens) auch alle anderen Redhat-Varianten, also RedHat 6 selbst, oder auch CentOS 6.
Prinzipiell können auch Debian, Ubuntu, SuSE, …. betroffen sein

Es gibt in Oracle viele Möglichkeiten, um Mails direkt aus der Datenbank zu verschicken.
In diesem Artikel wird beschrieben, wie man Mails nur mit Hilfe des utl_smtp-Packages verschicken kann.
Dadurch kann man beliebige Mails komponieren und hat nicht das Problem, dass die von Oracle bereitgestellten Packages je nach Datenbankversion unterschiedlich leistungsfähig sind und unter Umständen nicht das bieten, was gerade benötigt wird.

Mails direkt aus Oracle versenden – komfortabel und mit Umlauten

Noch ein Hinweis: dieser Beitrag stammt aus dem Jahr 2005 und bezieht sich noch auf Oracle 10g! Wir sehen jedoch, dass er immer noch sehr häufig heruntergeladen wird. Das beschriebene Vorgehen funktioniert auch immer noch.

Zwischenzeitlich würden wir jedoch andere Verfahren verwenden. Da das utl_mail-Package immer noch einige unverständliche Restriktionen aufweist, nehmen wir beispielsweise das apex_mail Package (ja, das funktioniert auch außerhalb von Apex!). Dieses deckt auch ohne zusätzliche Programmierung die meisten Anforderungen vollständig ab.