Ab heute gibt es Oracle WebLogic Server on JRockit Virtualization Edition als Download. Vor ein paar Wochen gab es bereits ein Meldung bei heise.de zu neuen Java-Virtualisierungswerkzeugen von Oracle – Oracle präsentiert Java-Virtualisierungswerkzeuge. Die technische Basis für dieses Produkt wurde Ende 2006 von der Firma BEA als Liquid VM angekündigt (theserverside.com – JRockit’s Liquid VM could be the first real Java OS). Hinter der JRockit Virtualization Edition steckt der Ansatz eine Java VM direkt auf virtualisierter Hardware, ohne Betriebssystem-Schicht, laufen zu lassen. Einen ähnlichen Ansatz stellt das Projekt JNode.org (Java New Operating System Design Effort) dar.

Oracle liefert die JRockit Virtualization Edition zusammen mit Weblogic als 370 MB grosses Zip-File. Darin sind folgende Dateien enthalten:

# unzip -t wlsvePackage.zip
Archive:  wlsvePackage.zip
    testing: wlsve/                   OK
    testing: wlsve/system.img         OK
    testing: wlsve/vm.cfg             OK
    testing: wlsveimagetool.jar       OK
    testing: README.txt               OK
    testing: wlsve_medrec_domain_with_odb.pdf   OK
    testing: THIRDPARTYLICENSEREADME.txt   OK

Hauptbestandteil ist das Disk-Image system.img

$ qemu-img info wlsve/system.img
image: wlsve/system.img
file format: raw
virtual size: 1.0G (1073741824 bytes)
disk size: 1.0G

Als Dateisystem wird in diesem Disk-Image ext2 verwendet, die Disk lässt sich daher unter Linux ohne Schwierigkeiten direkt mounten.

# mount -o loop wlsve/system.img /mnt
# cd /mnt
# ls -l
total 20
drwx------ 8 root root 4096 2010-04-14 02:48 application
drwx------ 3 root root 4096 2010-04-14 02:49 boot
drwx------ 8 root root 4096 2010-04-14 02:49 jrockitve
drwx------ 2 root root 4096 2010-04-14 02:48 lost+found
-rw------- 1 root root  361 2010-04-14 02:49 VERSION

Für den Betrieb einer Virtuellen-Maschine mit JRockit VE wird eigentlich Oracle VM benötigt. In einem ersten Test ließ sich das Disk-Image aber auch in einer normalen Xen-Umgebung booten. Hierzu wurde die Konfigurations-Datei vm.cfg mit folgendem Inhalt versehen:

name="wlsve01"
bootloader="/usr/bin/pygrub"
memory=1024
disk=['tap:aio:/var/nfs/system.img,sda1,w']
vif=['bridge=xenbr0']

Der Start der Xen-Domain erfolgt dann wie gewohnt mit den entsprechenden Xen-Befehlen.

# xm create -c vm.cfg

Gestern Abend hat Oracle die Version 11g für den Enterprise Manager veröffentlicht. Entsprechende Infos und Videos zu diesem Launch gibts bei Oracle unter: Introducing Oracle Enterprise Manager 11g Grid Control!. Für mich überraschend steht die Software (zumindest für Linux) auch gleich zum Download bereit (Oracle Enterprise Manager Downloads). Da lohnt sich natürlich gleich ein Blick was sich alles verändert hat!

Middleware und RDBMS sind nicht mehr im Installationsumfang enthalten

D.h. diese Komponenten müssen vorab bereits installiert werden! Dies war einer der Punkte der mich bei Grid Control immer gestört hatte die enthaltenen Versionen von Middleware und RDBMS waren meist etwas angestaubt. So hat man mehr Flexibiltät bei der Installation.

Kleiner wird das Installationsumfang dadurch allerdings nicht. Die drei Zip-Files sind zusammen 4 GB groß:

[root@w0007 linux64]# ls -l
total 4324640
-rwxr-xr-x 1 frank frank 1430649163 2010-04-23 14:34 GridControl_11.1.0.1.0_Linux_x86-64_1of3.zip
-rwxr-xr-x 1 frank frank 1589674193 2010-04-23 14:56 GridControl_11.1.0.1.0_Linux_x86-64_2of3.zip
-rwxr-xr-x 1 frank frank 1408054490 2010-04-23 14:36 GridControl_11.1.0.1.0_Linux_x86-64_3of3.zip

Der Installationsvorgang

Die Installation lief in meinem Fall problemlos ab, die einzige wirkliche Änderung gegenüber Version 10gR5 ist das eine Datenbank-Instanz und der Weblogic Applicationserver bereits vor der Installation des Enterprise Manager aufgesetzt werden müssen.

Komponenten-Stack / Verzeichnisse

An der Verzeichnisstruktur des Enterprise Manager hat sich in Version 11gR1 hingegen einiges getan, man erkennt deutlich wie nun unterschiedliche Produktlinien langsam zusammenkommen. Neu ist der Begriff des Middleware-Home. Unterhalb dieses Verzeichnisses gibt es dann eine Fülle weiterer Verzeichnissbäume und Oracle Homes:

[oracle@oragrid middleware]$ ls -l
total 152
drwxr-xr-x 45 oracle oinstall  4096 Apr 24 13:27 agent11g
-rw-r-----  1 oracle oinstall   218 Apr 24 12:43 domain-registry.xml
drwxr-x---  7 oracle oinstall  4096 Apr 23 12:45 jdk160_14_R27.6.5-32
drwxr-x---  7 oracle oinstall  4096 Apr 23 12:45 jrockit_160_14_R27.6.5-32
drwxr-x---  2 oracle oinstall  4096 Apr 23 12:47 logs
drwxr-x---  7 oracle oinstall 24576 Apr 23 12:58 modules
-rw-r-----  1 oracle oinstall   623 Apr 23 13:00 ocm.rsp
drwxr-x---  5 oracle oinstall  4096 Apr 23 12:47 oepe_11gR1PS1
drwxr-xr-x 55 oracle oinstall  4096 Apr 24 12:39 oms11g
drwxr-xr-x 28 oracle oinstall  4096 Apr 23 21:05 oracle_common
drwxr-xr-x 48 oracle oinstall  4096 Apr 23 21:11 Oracle_WT
drwxr-xr-x  4 oracle oinstall  4096 Apr 23 12:58 patch_oepe1032
drwxr-xr-x  5 oracle oinstall  4096 Apr 23 13:03 patch_wls1032
-rw-r-----  1 oracle oinstall 57384 Apr 23 12:47 registry.dat
-rw-r-----  1 oracle oinstall  2640 Apr 23 12:47 registry.xml
drwxr-x---  3 oracle oinstall  4096 Apr 24 12:43 user_projects
drwxr-x---  8 oracle oinstall  4096 Apr 23 12:40 utils
drwxr-x---  7 oracle oinstall  4096 Apr 23 12:47 wlserver_10.3

Der Plattenplatz-Bedarf hat mit dieser Version ebenfalls nochmals zugelegt, das Middleware Home belegt nach der Installation satte 8 GB, hier eine grobe Aufteilung:

[oracle@oragrid middleware]$ du -sh *
1.1G	agent11g
4.0K	domain-registry.xml
172M	jdk160_14_R27.6.5-32
187M	jrockit_160_14_R27.6.5-32
8.0K	logs
122M	modules
4.0K	ocm.rsp
254M	oepe_11gR1PS1
3.9G	oms11g
833M	oracle_common
1.2G	Oracle_WT
16K	patch_oepe1032
60K	patch_wls1032
64K	registry.dat
4.0K	registry.xml
12K	user_projects
35M	utils
518M	wlserver_10.3

In den nächsten Teilen folgt dann eine Übersicht zu neuen Features und der Bedienung des Enterprise Managers.

Die Firma Quest hat vor wenigen Tagen die Software LiteSpeed Engine for Oracle veröffentlicht. Hierbei handelt es sich um eine RMAN-Erweiterung. Die LiteSpeed Engine bietet vor allem Kompremierung von Backup-Pieces und Verschlüsselung. Die nachfolgenden Zeilen geben einen Überblick zu Installation und Konfiguration.

Schritt 1 – Download
Eine Test-Version (30 Tage Laufzeit) kann von der Quest-Homepage nach einer Registierung heruntergeladen werden.

Schritt 2 – Installation
Um die Software installieren zu können, benötigt man das Package sharutils (Shell Archive Utilities). Beim verwendeten Fedora 9 war dieses Package noch nicht intalliert.

# rpm -q sharutils
sharutils-4.6.3-2.fc9.x86_64
# yum install sharutils

Anschließend kann die Quest-Software selbst installiert werden, die Installation erfolgt als Oracle-User nicht als root! Die üblichen Oracle Umgebungs-Variablen ($ORACLE_HOME) müssen passend gesetzt sein.

$ bash LiteSpeedEngineforOracle_110168.sh install

Die Software wird direkt ins entsprechende ORACLE_HOME unter $ORACLE_HOME/Quest/LEO installiert.

Schritt 3 – RMAN Konfiguration
Damit die LiteSpeed Engine richtig mit RMAN zusammenarbeitet, muss sie im RMAN entsprechend konfiguriert werden:

$ rman
RMAN> connect target /
RMAN> CONFIGURE CHANNEL DEVICE TYPE sbt
PARMS='SBT_LIBRARY=/opt/oracle/ora10g/Quest/LEO/libleo64.so';

Schritt 4 – Backup durchführen
Ein Backup könnte dann wie folgt durchgeführt werden:

RMAN> backup device type sbt database format='leo://level=4://tmp/backup_%U.leo';

Die LiteSpeed Engine verfügt mit leo auch über ein Kommandozeilen-Werkzeug, hiermit lassen sich z.B. Informationen über kompremierte Backup-Pieces anzeigen:

$ leo stat backup_2nk8dgql_1_1.leo

/tmp/backup_2nk8dgql_1_1.leo

  Raw size (bytes)             597164032
  Compressed size (bytes)      115510927
  Compression ratio            80.66%
  Compression level            4
  Encryption type              None
  Start time                   Fri 27 Feb 2009 10:47:49 AM CET
  End time                     Fri 27 Feb 2009 10:48:27 AM CET
  Real time (sec)              37.68
  User CPU time (sec)          17.21
  System CPU time (sec)        0.66
  Written by LEO version       1.1.0.168
  Method                       RMAN
  DBNAME                       B08
  DBID                         229074788
  Filetype                     Datafile

Die Web-Oberfläche Database Control zur Verwaltung einer Oracle Datenbank Instanz bietet die Möglichkeit eigene benutzerdefinierte Metriken (UDM – User Defined Metrics) anzulegen. Möchte man eine Reihe von eigenen Metriken in verschiedenen Instanzen verwalten, wird dies über die Web-Oberfläche schnell mühsam.

In diesem Fall bietet es sich an, die von der Web-Oberfläche im Hintergrund erzeugte XML-Datei selbst zu editieren. Die XML-Datei befindet sich im Pfad $ORACLE_HOME/INSTANZNAME/sysman/emd/collection und nennt sich oracle_database_ORACLESID.xml.

Wird die XML-Datei von Hand editiert, ist besonders darauf zu achten, dass die Struktur der Datei erhalten bleibt. Als Beispiel für einen entsprechenden Eintrag wird die Anzahl Zeilen der Tabelle EMP stündlich ermittelt, die Warn-Schwelle liegt bei einem Wert von 10:

<!-- this file is generated by collector -->
<targetcollection TYPE="oracle_database" NAME="B05">
...
        <CollectionItem NAME="BLOG_TEST">
                <Schedule>
                        <IntervalSchedule INTERVAL="1" TIME_UNIT="Hr"/>
                </Schedule>
                <MetricColl NAME="SQLUDM">
                        <Condition COLUMN_NAME="NumValue" WARNING="10" MESSAGE="%Message%">
                                <KeyColumn COLUMN_NAME="ID">BLOG_TEST</KeyColumn>
                        </Condition>
                        <ItemProperty NAME="ID">BLOG_TEST</ItemProperty>
                        <ItemProperty NAME="sqlstmt">select count(*) from scott.emp</ItemProperty>
                        <ItemProperty NAME="UserName">system</ItemProperty>
                        <ItemProperty NAME="password" ENCRYPTED="TRUE">de3503b8b5736253</ItemProperty>
                        <ItemProperty NAME="valuetype">NUMBER</ItemProperty>
                </MetricColl>
        </CollectionItem>
</TargetCollection>

Werden in einem Unternehmen viele Datenbank-Instanzen auf unterschiedlichen Servern eingesetzt, empfiehlt sich der Einsatz von Oracle Grid Control als großer Bruder zu Database Control. Hier lassen sich beliebig viele Oralce-Instanzen zentral verwalten.

Oracle DataPump hat sich bei vielen Anwendern aufgrund seiner Vorteile als Import/Export-Werkzeug durchgesetzt. Neben den Werkzeugen impdp und expdp lässt sich die DataPump auch via PL/SQL steuern. Hierzu dient das Package DBMS_DATAPUMP. Die Verwendung für einen Schema-Export zeigt folgendes Beispiel:

DECLARE
  v_DPHandle_n      NUMBER;
  v_TimeStamp_vc    VARCHAR2(15);
  v_JobName_vc      VARCHAR2(30);
  v_DumpFilename_vc VARCHAR2(50);
  v_LogFilename_vc  VARCHAR2(50);
  v_JobStatus_vc    VARCHAR2(50);
  v_SchemaName_vc   VARCHAR2(8)  := 'SCOTT';

  -- dieses Oracle-Verzeichnis muss evtl. vorher angelegt werden
  --
  -- CREATE OR REPLACE DIRECTORY DPUMP_TEST_DIR AS '/tmp';
  --
  -- evtl. muessen auch Schreib-/Lese-Rechte gesetzt werden
  --
  -- GRANT READ, WRITE ON DIRECTORY DPUMP_TEST_DIR TO orauser;
  --
  v_DumpDir_vc      VARCHAR2(20) := 'DPUMP_TEST_DIR';
BEGIN
  v_TimeStamp_vc    := TO_CHAR(sysdate, 'YYYYMMDD-HH24MISS');
  v_JobName_vc      := v_TimeStamp_vc || '_' || v_SchemaName_vc;

  -- wichtig ist der Platzhalter %U, je nach Parallelitaet werden so
  -- mehrere Dump-Files erzeugt
  v_DumpFilename_vc := v_SchemaName_vc || '_' || v_TimeStamp_vc || '_%U.dmp';
  v_LogFilename_vc  :=  v_SchemaName_vc || '_' || v_TimeStamp_vc || '.log';

  -- Datapump-Job oeffnen
  v_DPHandle_n := DBMS_DATAPUMP.open(
    operation   => 'EXPORT',
    job_mode    => 'SCHEMA',
    job_name    => v_JobName_vc
  );

  -- Dump-File fuer den Job definieren
  DBMS_DATAPUMP.add_file(
    handle    => v_DPHandle_n,
    filename  => v_DumpFilename_vc,
    directory => v_DumpDir_vc
  );

  -- Log-File definieren
  DBMS_DATAPUMP.add_file(
    handle    => v_DPHandle_n,
    filename  => v_LogFilename_vc,
    directory => v_DumpDir_vc,
    filetype  => DBMS_DATAPUMP.KU$_FILE_TYPE_LOG_FILE
  );

  -- welches Schema soll exportiert werden?
  DBMS_DATAPUMP.metadata_filter(
    handle => v_DPHandle_n,
    name   => 'SCHEMA_EXPR',
    value  => '= ''' || v_SchemaName_vc || ''''
  );

  -- Parallelitaet auf 4 setzen
  DBMS_DATAPUMP.SET_PARALLEL(
    handle => v_DPHandle_n,
    degree => 4
  );

  -- eigene Eintraege im Log-File sind moeglich
  DBMS_DATAPUMP.LOG_ENTRY(
    handle => v_DPHandle_n,
    message => '---> Schema Export via PL/SQL'
  );

  -- Job starten
  DBMS_DATAPUMP.start_job(v_DPHandle_n);

  -- auf das Job Ende wird normalerweise nicht gewartet
  -- mit WAIT_FOR_JOB laesst sich dies aber bei Bedarf
  -- realisieren
  DBMS_DATAPUMP.WAIT_FOR_JOB(
    handle => v_DPHandle_n,
    job_state => v_JobStatus_vc
  );

END;
/

Ein allgemeiner Hinweis zu Oracle DataPump:
DataPump-Prozesse laufen immer auf dem Oracle-Server!
Dies hat in der Praxis folgende Auswirkungen:

• Der Betriebssystem-Benutzer, dem die Oracle-Server Prozesse zugeordnet sind, braucht Schreib-Rechte auf dem gewünschten Export-Verzeichnis (läuft die Datenbank-Instanz als Windows-Dienst und dem Benutzer LocalSystem ist kein Schreiben auf Netzwerk-Shares möglich, da dieser Benutzer keine Netzwerk-Shares sieht)
• Es gibt keinen Client-/Server-Modus (z.B. Export eines Schemas von einem entfernten Oracle Server über einen lokalen Oracle Client)