Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Versionshinweise

- Previous: Behobene Programmfehler in Version 8.1, Update 2
- Next: Application Server-Produktversionen

# Zusätzliche HADB-Informationen

In diesem Abschnitt werden weitere wichtige Informationen zu der in Anwendungsserver 8.1 enthaltenen HADB-Implementierung erläutert.

- HADB-Erweiterungen

- HADB-Dateisystem-Unterstützung

- Upgrade der High Availability-Datenbank

- Bekannte SQL-Einschränkungen

- High Availability-Lastenausgleich

## HADB-Erweiterungen

- Der neue Management-Befehl `hadbm setadminpassword` wurde bereitgestellt, um das zur Datenbankadministration verwendete Passwort ändern zu können. Der Befehl wird mit Optionen verknüpft, die angeben, welcher Management-Agent verwendet werden soll, und die das alte und neue Passwort enthalten. Weitere Informationen finden Sie in der Online-Dokumentation ( Man Page) `hadbm setadminpassword`.

- Der vorhandene Management-Befehl `hadbm listpackages` wurde geändert. Vorher war der Befehl mit keinen Operanden verknüpft und hat alle Pakete in der relevanten Management-Domäne aufgelistet. Durch die Änderung wurde ein optionaler Paketnamen-Operand eingeführt, der lediglich Pakete mit dem betreffenden Namen auflistet. Wenn der Operand nicht angegeben wird, werden alle Pakete aufgelistet. Weitere Informationen finden Sie in der Online-Dokumentation ( Man Page) `hadbm listpackages`.

- Der vorhandene Management-Befehl `hadbm createdomain` wurde geändert. Der Operand hostlist wurde erweitert. Er gibt jetzt auch die Portnummer des Management-Agenten an. Auf diese Weise wird die Domäne lediglich mithilfe des Operanden hostlist vollständig spezifiziert. Das alte Verhalten wird aus Gründen der Rückwärtskompatibilität immer noch unterstützt. Weitere Informationen finden Sie in der Online-Dokumentation (manpage) `hadbm createdomain`.

- Einige Fehlermeldungen des Managementsystems wurden geändert. Die Änderungen dienen dazu, Verständlichkeit, Einheitlichkeit und Genauigkeit der Fehlermeldungen zu verbessern. Die eigentlichen Änderungen werden in diesen Versionshinweisen nicht aufgelistet.

- Das Installations- und Deinstallationsverhalten wurde geringfügig geändert. Bei der Installation bzw. Deinstallation von HADB sollte immer der Softlink `/opt/SUNWhadb/4` erhalten bleiben. Dies war jedoch nicht immer der Fall:

- Die Möglichkeit zur Eingabe von Passwörtern in der Befehlszeile als Befehlsoption wurde verworfen. Dies ist für alle `hadbm`-Befehle relevant, die Passwörter als Befehlszeilenoptionen annehmen können. Für `hadbm`-Befehle gab es vorher folgende Methoden, um ein Passwort einzugeben:

  1. als Passwortdatei

  2. als Befehlszeilenoption

  3. als interaktive Eingabe

  Da Methode 2 (die Befehlszeilenoption) als unsicher erachtet wird, wurde sie verworfen. Eine Warnmeldung wird ausgegeben, wenn ein Passwort auf diese Weise eingegeben wird. Verwenden Sie stattdessen Methode 1 (Passwortdatei) oder Methode 3 (interaktive Ausgabe). Die Verwendung eines Passworts in der Befehlszeile wird in der nächsten Version überflüssig. Dies gilt für alle `hadbm`-Befehle, die eine Befehlszeilen-Passwortoption annehmen.

- HADB wurde aktualisiert und kann jetzt JGroups Version 2.2 verwenden. Der Quellcode des Programms wird zusammen mit HADB verteilt. Zur Unterstützung von Online-Upgrades von vorherigen HADB-Versionen sind im Lieferumfang von HADB sowohl JGroups 2.1 als auch 2.2 vorhanden. Für JGroups 2.1 wird nur der Byte-Code mitgeliefert.

## HADB-Dateisystem-Unterstützung

Wenn Sie HADB für eines der folgenden Dateisysteme konfigurieren möchten, müssen Sie einige wichtige Informationen beachten:

- ext2 und ext3– HADB unterstützt ext2- und ext3-Dateisysteme für Red Hat Application Server 3.0. Für Red Hat Application Server 2.1 unterstützt HADB nur das ext2-Dateisystem.

- `Veritas`– Wenn Sie das Veritas-Dateisystem unter Solaris einsetzen, wird die Nachricht `“WRN:` `Direct disk I/O mapping failed“` in die Verlaufsdatei geschrieben. Die Meldung weist darauf hin, dass HADB kein direktes I/O für Daten- und Protokollgeräte aktivieren konnte. Direktes I/O ist eine Performance-Verbesserung, die die CPU-Kosten für das Schreiben von Diskseiten verringert. Das Prinzip führt auch dazu, dass weniger Verwaltungsaufwand für unreine Datenseiten im Betriebssystem erforderlich ist.

  Um direktes I/O zusammen mit dem Veritas-Dateisystem zu verwenden, wählen Sie eine der folgenden Vorgehensweisen:

  - Erstellen Sie die Daten- und Protokollgeräte unter einem Dateisystem, für das die Option `mincache=direct` gilt. Die Option wird auf alle unter diesem Dateisystem erstellten Dateien angewendet. Weitere Informationen finden Sie in der Beschreibung des Befehls `mount_vxfs(1M)`.

  - Verwenden Sie Toll Veritas Quick I/O, um direktes I/O auf die Dateien des Dateisystems anzuwenden. Weitere Informationen finden Sie im VERITAS File System 4.0 Administrator's Guide for Solaris.

    Diese Konfigurationen wurden nicht mit Anwendungsserver 8.1 2005Q2 Update 2 getestet.

    Informationen über Installation und Konfiguration von HADB mit der Anwendungsserver-Software finden Sie im Anwendungsserver Enterprise Edition High Availability Administration Guide.

## Upgrade der High Availability-Datenbank

- Tasks/Datenzusammenführung vor dem Upgrade

- Upgrade-Verfahren

- Testen des Upgrades

- Spezielle Bereitstellungs- und Upgrade-Informationen

### Tasks/Datenzusammenführung vor dem Upgrade

##### Bevor Sie beginnen

Die Benutzer müssen HADB-Verlaufsdateien, Management-Agent-Konfigurationsdateien, Protokolldateien und Repository sowie alle Datengeräte außerhalb des Installationspfads abgelegt haben. Sollte dies nicht der Fall sein, muss dies noch vor dem Upgrade erfolgen. So verschieben Sie Management-Repository- und Konfigurationsdateien:

1. Beenden Sie alle alten Management-Agenten und führen Sie die HADB-Knoten weiter aus.

2. Verschieben Sie an jedem Host das Repository-Verzeichnis an den neuen Pfad.

3. Kopieren Sie auf jedem Host das Verzeichnis `dbconfig` an den neuen Pfad.

4. Aktualisieren Sie auf jedem Host die Datei `mgt.cfg` und wählen Sie den korrekten Pfad für `dbconfig` und das Repository-Verzeichnis.

5. Starten Sie die Management-Agenten unter Verwendung der aktualisierten Datei `mgt.cfg`.

### Upgrade-Verfahren

Zur Aufrüstung von HADB-Version 4.4.x auf Version 4.4.2-7 gehen Sie wie folgt vor:

1. Führen Sie die oben genannten Tasks vor dem Upgrade nach Bedarf aus.

2. Installieren Sie HADB-Version 4.4.2-7 auf allen HADB-Hosts (in einem anderen Pfad als Version 4.4.x, zum Beispiel unter `/opt/SUNWhadb/4.4.2-7`).

3. Installieren Sie HADB-Version 4.4.2-7 auf den `hadbm`-Client-Hosts, wenn diese sich von den HADB-Hosts unterscheiden.

4. Beenden Sie alle Management-Agenten, die auf den HADB-Hosts ausgeführt werden.

5. Starten Sie die Management-Agent-Prozesse mithilfe der Software der neuen Version, jedoch mit den alten Konfigurationsdateien. Für die verbleibenden Schritte verwenden Sie den Befehl `hadbm`, der im `bin`-Verzeichnis der neuen Version zu finden ist.

6. Registrieren Sie das Paket in der Management-Domäne (der Standardpaketname lautet V4.4, sodass evtl. ein anderer Paketname erforderlich ist, um Konflikte mit vorhandenen Paketen zu vermeiden, die denselben Namen tragen):

       hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.2-7 V4.4.2-7

7. Führen Sie den Befehl `hadbm listpackages` aus und prüfen Sie, ob das neue Paket in der Domäne registriert ist.

8. Starten Sie die Datenbank mit der neuen `hadbm`-Version 4.4.2-7 neu. Wenn es erforderlich ist, die Geräte- und Verlaufsdateien zu verschieben, führen Sie ein Online-Upgrade aus und legen dabei in einem Schritt neue Pfade für Geräte und Verlaufsdateien fest:

       hadbm set packagename=V4.4.2-7,devicepath=new_devpath,
       historypath=new_histpath

   Wenn sich die Geräte und Verlaufsdateien anderenfalls bereits außerhalb des Installationsverzeichnisses befinden, führen Sie den folgenden Befehl aus, der lediglich einen Bilddurchlauf-Neustart der Knoten auslöst:

       hadbm set packagename=V4.4.2-7 Datenbankname

9. Prüfen Sie (mithilfe des Befehls `hadbm status`), ob der Datenbankstatus "running" lautet und ob die Datenbank normal funktioniert und die Client-Transaktionen übermittelt.

10. Wenn alles funktioniert, kann die alte Installation später entfernt werden. Bevor Sie die Registrierung des alten Pakets aufheben, entfernen Sie alle Verweise auf das alte Paket aus der `ma`Repository. Anderenfalls schlägt der Befehl `hadbm unregisterpackage` fehl und gibt die Fehlermeldung "package in use" aus.Eine Dummy-Neukonfigurationsoperation, z. B. `hadbm set connectiontrace= wie voriger Wert` entfernt alle Verweise auf das alte Paket. Heben Sie jetzt die Registrierung des alten Pakets auf:

        hadbm unregisterpackage [--hosts=Hostliste] alter Paketname

11. Entfernen Sie die alte Installation aus dem Dateisystem.

### Testen des Upgrades

Um unter Solaris zu testen, ob das Upgrade erfolgreich war, prüfen Sie, ob das Upgrade ordnungsgemäß durchgeführt wurde:

1. Vergewissern Sie sich, dass die laufenden Prozesse die neuen Binärdateien verwenden. Prüfen Sie in allen HADB-Knoten Folgendes:

       neuer Pfad/bin/ma -v
       neuer Pfad/bin/hadbm -v

2. Prüfen Sie, ob die Datenbank ausgeführt wird. Der folgende Befehl sollte zeigen, dass alle HADB-Knoten den Status “running” aufweisen.

       neuer Pfad/bin/hadbm status -n

3. Vergewissern Sie sich, dass Produkte mit Verwendung von HADB ihre Zeiger so geändert haben, dass sie auf den neuen HADB-Pfad verweisen.

4. Die Produkte mit Verwendung von HADB können ihre Upgrade-Tests ausführen, um zu prüfen, dass das HADB-Upgrade ebenfalls funktioniert.

   Wenn nach einem Online-Upgrade die neue Version nicht ordnungsgemäß funktioniert, wechseln Sie wieder zur Verwendung der vorherigen HADB-Version. Wenn jedoch eine Änderung am Management-Agent-Repository durchgeführt wurde, kann die HADB selbst heruntergestuft werden. Allerdings muss der neue Management-Agent weiter ausgeführt werden.

### Spezielle Bereitstellungs- und Upgrade-Informationen

In diesem Abschnitt werden zusätzliche Informationen über HADB-Bereitstellung und Upgrade aufgeführt.

- Bereitstellung

- Online-Upgrade von 4.4.1 auf 4.4.2

#### Bereitstellung

- Speichern Sie Geräte-, Protokoll- und Verlaufsdateien nur auf lokalen Festplatten. Verwenden Sie keine entfernt bereitgestellten Dateisysteme.

- Wenn mehrere Knoten auf einem Host platziert wurden, wird empfohlen, dass die Geräte zu allen Knoten der verschiedenen Festplatten gehören. Anderenfalls würde die Leistung durch die Konkurrenzsituation zwischen den Festplatten herabgesetzt werden. Symptome für dieses Problem sind in den Verlaufsdateien anhand von Meldungen ersichtlich wie `BEWARE - last flush/fputs took too long`. Wenn ein Knoten über mehrere Datengerätedateien verfügt, wird empfohlen, separate Festplatten für diese Gerätedateien zu verwenden.

- Verwenden Sie lokale Festplatten (möglichst eine andere als die für Datengeräte verwendete Festplatte), um HADB-Binärdateien auf HADB-Hosts zu installieren. NFS-Verzögerungen oder Zugriffskonflikte können zu Knotenneustarts mit der Warnung "`Process blocked for` `nnn``, max block time is` `nnn`" in den Verlaufsdateien führen.

- Legen Sie die HADB-Geräte, Verlaufsdateien, Management-Agent-Verzeichnisse und agent config-Dateien nicht im HADB-Paketpfad ab. Dies führt zu Problemen beim Upgrade auf neuere Versionen sowie beim Löschen des alten Paketpfads.

- Diese HADB-Version wird offiziell für maximal 28 Knoten unterstützt, und zwar für 24 aktive Datenknoten mit 4 Ersatzknoten.

- Es wird empfohlen, dieselbe Version für den JDBC-Treiber und den HADB-Server zu verwenden.

- IPv6 wird nicht unterstützt, sondern lediglich IPv4.

- Die Länge der Befehlszeile unter Windows ist auf 2048 Byte beschränkt.

- Das Netzwerk muss für UDP Multicast konfiguriert sein.

- Aufgrund des übermäßigen Swappings von RedHat Enterprise Linux 3.0, Updates 1 bis 3, empfehlen wir es nicht als Bereitstellungsplattform. Das Problem wurde in RedHat Enterprise Linux 3.0, Update 4 behoben.

- Möglichkeit, `NSUP` mit Echtzeit-Priorität auszuführen.

  Die Prozesse des Knoten-Supervisors (`NSUP`) (`clu_nsup_srv` ) stellen die hohe Verfügbarkeit von HADB mithilfe des termingemäßen Austauschs von "heartbeat"-Nachrichten sicher. Die zeitliche Koordinierung wird beeinträchtigt, wenn ein `NSUP` mit anderen Prozessen gemeinsam untergebracht wird, da dies zu einem Ressourcenschwund führt. Die Folge sind eine falsche Netzwerkpartitionierung und Knotenneustarts (vorher wird die Warnung “Process blocked for `n` seconds” in den Verlaufsdateien ausgegeben), die zu abgebrochenen Transaktionen und anderen Ausnahmefehlern führen.

  Um dieses Problem zu lösen, muss für `clu_nsup_srv` (unter `Installationspfad``/lib/server` zu finden) das `suid`-Bit gesetzt sein und Eigentümer der Datei muss der Benutzer "root" sein. Dies wird manuell durch folgende Befehle erzielt:

      # chown root clu_nsup_srv
      # chmod u+s clu_nsup_srv

  Dadurch wird der Prozess `clu_nsup_srv`, wenn er gestartet wird, als Benutzer `root` ausgeführt. Dies wiederum ermöglicht dem Prozess, sich selbst automatisch Echtzeit-Priorität nach dem Start zuzuweisen. Zur Vermeidung von Sicherheitsproblemen bei Verwendung von `setuid` wird die Echtzeit-Priorität ganz am Anfang festgelegt und der Prozess kehrt zur effektiven UID zurück, sobald die Priorität geändert wurde. Andere HADB-Prozesse senken ihre Priorität auf Zeitteilungspriorität ab.

  Wenn NSUP die Echtzeit-Priorität nicht setzen konnte, wird der Warnhinweis “Could not set realtime priority” (`Unix: Fehler-Nr. wird auf EPERM` gesetzt) ausgegeben, der in der Datei `ma.log` dargelegt ist, und der Prozess wird ohne Echtzeit-Priorität fortgesetzt.

  Es gibt Fälle, in denen es nicht möglich ist, Echtzeit-Prioritäten festzulegen; beispielsweise in folgenden Situationen:

  - Bei Installation in nichtglobalen Zonen von Solaris 10

  - Wenn die Berechtigungen `PRIV_PROC_LOCK_MEMORY` (Ermöglichen, dass ein Prozess Seiten im physischen Speicher sperren kann) und/oder `PRIV_PROC_PRIOCNTL` in Solaris 10 aufgerufen werden.

  - Benutzer deaktivieren die Berechtigung `setuid`

  - Benutzer installieren die Software als tar-Dateien (Installationsoption nonroot für `App.server`)

  Der Prozess `clu_nsup_srv` ist nicht CPU-konsumierend und sein Ressourcenbedarf ist gering. Wenn er mit Echtzeit-Priorität ausgeführt wird, beeinflusst er nicht die Leistung.

- Konfiguration von IP-Netzwerk-Multipathing für HADB für Solaris (nur unter Solaris 9 getestet).

  Sun empfiehlt, dass Solaris-Hosts, auf denen HADB ausgeführt wird, mit Netzwerk-Multipathing eingerichtet werden, um die höchstmögliche Netzwerkverfügbarkeit sicherzustellen. Die Einrichtung von Network-Multipathing wird in allen Einzelheiten im IP Network Multipathing Administration Guide behandelt. Wenn Sie sich dafür entscheiden, Multipathing mit HADB zu verwenden, lesen Sie im IP Network Multipathing Administration Guide den Abschnitt "Verwaltung von Netzwerk-Multipathing", um Multipathing einzurichten, bevor Sie mit dem Anpassen des Multipathing-Setups für HADB fortfahren (siehe unten). Der IP Network Multipathing Administration Guide gehört zur System Administrator Collection von Solaris 9 und kann von der Adresse `http://docs.sun.com` heruntergeladen werden.

  - Einrichten der Netzwerkschnittstellenfehler-Erkennungszeit

    Damit HADB die Multipathing-Ausfallsicherung ordnungsgemäß unterstützt, darf die Netzwerkschnittstellenfehler-Erkennungszeit gemäß Spezifikation durch den Parameter `FAILURE_DETECTION_TIME` in `/etc/default/mpathd` 1000 Millisekunden nicht übersteigen. Bearbeiten Sie die Datei und ändern Sie den Wert dieses Parameters auf `1000`, wenn der Originalwert höher ist:

        FAILURE_DETECTION_TIME=1000

    Damit die Änderung wirksam ist, geben Sie den folgenden Befehl aus:

        pkill -HUP in.mpathd

  - Mit HADB zu verwendende IP-Adressen

    Gemäß Erläuterungen im Solaris IP Network Multipathing Administration Guide umfasst das Multipathing die Gruppierung physischer Netzwerkschnittstellen in Multipath-Schnittstellengruppen. Jede physische Schnittstelle in einer derartigen Gruppe ist mit zwei IP-Adressen assoziiert: einer physischen Schnittstellenadresse und einer Testadresse. Lediglich die physische Schnittstellenadresse kann zum Übertragen von Daten verwendet werden. Die Testadresse dient nur für interne Solaris-Zwecke. Wenn `hadbm create --hosts` ausgeführt wird, darf jeder Host mit nur einer physischen Schnittstellenadresse der Multipath-Gruppe spezifiziert werden.

  - Beispiel

    Angenommen, Host 1 und Host 2 verfügen jeweils beide über zwei physische Netzwerkschnittstellen. Auf jedem Host werden diese beiden Schnittstellen als Multipath-Gruppe eingerichtet und beim Ausführen von `ifconfig -a` erhalten Sie Folgendes:

    Host 1

        bge0: flags=1000843<mtu 1500 index 5 inet 129.159.115.10 netmask ffffff00
        broadcast 129.159.115.255 groupname mp0
        bge0:1: flags=9040843<mtu 1500 index 5 inet 129.159.115.11 netmask ffffff00
        broadcast 129.159.115.255
        bge1: flags=1000843<mtu 1500 index 6 inet 129.159.115.12 netmask ffffff00
        broadcast 129.159.115.255 groupname mp0
        bge1:1: flags=9040843<mtu 1500 index 6 inet 129.159.115.13 netmask ff000000
        broadcast 129.159.115.255

    Host 2

        bge0: flags=1000843<mtu 1500 index 3 inet 129.159.115.20 netmask ffffff00
        broadcast 129.159.115.255 groupname mp0
        bge0:1: flags=9040843<mtu 1500 index 3 inet 129.159.115.21 netmask ff000000
        broadcast 129.159.115.255
        bge1: flags=1000843<mtu 1500 index 4 inet 129.159.115.22 netmask ffffff00
        broadcast 129.159.115.255 groupname mp0
        bge1:1: flags=9040843<mtu 1500 index 4 inet 129.159.115.23 netmask ff000000
        broadcast 129.159.115.255

    Hier sind die physischen Netzwerkschnittstellen auf beiden Hosts, als `bge0` und `bge1` aufgelisteten Schnittstellen. Die als `bge0:1` und `bge1:1` aufgelisteten Schnittstellen sind Multipath-Testschnittstellen (sie werden daher im `ifconfig`-Output mit DEPRECATED gekennzeichnet). Siehe dazu auch den IP Network Multipathing Administration Guide.

    Zum Einrichten von HADB in dieser Umgebung wählen Sie eine physische Schnittstellenadresse von jedem Host. In diesem Beispiel wählen wir `129.159.115.10` von Host 1 und `129.159.115.20` von Host 2. Zum Erstellen einer Datenbank mit einem Datenbankknoten pro Host verwenden Sie das folgende Argument für `hadbm create`:

        --host 129.159.115.10,129.159.115.20

    Zum Erstellen einer Datenbank mit zwei Datenbankknoten auf jedem Host verwenden Sie das folgende Argument:

        --host 129.159.115.10,129.159.115.20,129.159.115.10,129.159.115.20

    In beiden Fällen muss die Variable `ma.server.mainternal.interfaces` auf beiden Hosts auf `129.159.115.0/24` festgelegt werden.

#### Online-Upgrade von 4.4.1 auf 4.4.2

Es ist nicht möglich, online von 4.2 oder 4.3 auf 4.4 upzugraden. Die Version 4.4 unterstützt jedoch Online-Upgrades für zukünftige Versionen. Zum Aufrüsten von 4.4.1 auf 4.4.2 gehen Sie wie folgt vor:

1. Installieren Sie 4.4.2 auf allen HADB-Hosts (in einem anderen Pfad als Version 4.4.1 – beispielsweise `/opt/SUNWhadb/4.4.2-6`).

2. Installieren Sie die neue Version auf den `hadbm client`-Hosts.

3. Beenden Sie alle Management-Agenten, die auf den HADB-Hosts ausgeführt werden.

4. Starten Sie die Management-Agent-Prozesse mithilfe der Software der neuen Version, jedoch mit den alten Konfigurationsdateien. Für die verbleibenden Schritte verwenden Sie den Befehl `hadbm`, der im `bin`-Verzeichnis der neuen Version zu finden ist.

5. Registrieren Sie das Paket in der Management-Domäne (der Standard-Paketname lautet hier `V4.4`, sodass evtl. ein anderer Paketname erforderlich ist, um Konflikte mit vorhandenen Paketen zu vermeiden, die denselben Namen haben):

       hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.2-6 V4.4.2

6. Starten Sie die Datenbank mit der neuen Version neu (mit dem folgenden Befehl wird ein Bildlauf-Neustart der Knoten ausgeführt):

       hadbm set packagename=V4.4.2 Datenbankname

7. Prüfen Sie (mithilfe des Befehls `hadbm status`), ob der Datenbankstatus “running” lautet und ob die Datenbank normal funktioniert und die Client-Transaktionen übermittelt.

8. Wenn alles funktioniert, kann die alte Installation später entfernt werden:

   Bevor Sie die Registrierung des alten Pakets aufheben, entfernen Sie alle Verweise auf das alte Paket aus der `ma`-Repository. Anderenfalls schlägt `hadbm unregisterpackage` fehl und gibt die Fehlermeldung "package in use" aus.Eine Dummy-Neukonfigurationsoperation, z. B. hadbm set connectiontrace=`<wie voriger wert>` entfernt alle Verweise auf das alte Paket. Heben Sie jetzt die Registrierung des alten Pakets auf:

       hadbm unregisterpackage [--hosts=<host_list>] <old_package_name>

   Entfernen Sie die alte Installation aus dem Dateisystem (siehe HADB-Installationsanweisungen.

## Bekannte SQL-Einschränkungen

- Es ist nicht möglich, einen sekundären Index einer Tabelle vom Typ `UNIQUE` zu erstellen.

- Der Ausdruck `(DISTINCT column)` ist in einem Aggregatausdruck nicht zulässig; es sei denn, es handelt sich um den einzigen ausgewählten Ausdruck.

- Alle Tabellen müssen mit einer Primärschlüssel-Spezifikation erstellt werden (d. h., Tabellen ohne Primärschlüssel werden nicht unterstützt).

- `FULL OUTER JOIN` wird nicht unterstützt.

- `IN`-Unterabfragen, bei denen es sich um Tabellenunterabfragen handelt, werden nicht unterstützt; beispielsweise:

      SELECT SNAME FROM S WHERE (S1#,S2#) IN (SELECT S1#,S2# FROM SP
      WHERE P#='P2')

- Andere Beschränkungen als `NOT NULL` und `PRIMARY KEY` werden nicht unterstützt.

- Es besteht die Möglichkeit, einer Ressource einen neuen Eigentümer zuzuweisen. Wenn dieser Schritt durchgeführt wird, werden jedoch die dem aktuellen Eigentümer gewährten Zugriffsrechte nicht auf den neuen Eigentümer übertragen.

- Zwei oder mehr verschachtelte `NOT EXISTS`-Unterabfragen, bei denen die einzelnen Unterabfragen nicht (direkt) mit der äußeren Ebene der Abfragen in Wechselbeziehung stehen, werden nicht unterstützt.

- Spalten-Zugriffsrechte werden nicht unterstützt.

- Zeilenwert-Constructors sind nur in einer `VALUES`-Bedingung zulässig.

- Unterabfragen werden in Zeilenwert-Constructors nicht als Wertausdrücke akzeptiert.

- Die folgenden Datentypen können beim Erstellen von Primärschlüsseln nicht verwendet werden:

  - `REAL`

  - `FLOAT`

  - `DOUBLE PRECISION`

  - `DECIMAL`

  - `NUMERIC`

## High Availability-Lastenausgleich

In Application Server ist Folgendes enthalten: Lastenausgleich für HTTP-, IIOP- und JMS-Clients, Failover-Unterstützung für HTTP-Sitzungen, Unterstützung für EJB-Clustererstellung und -Failover, hochverfügbare EJB-Timer, Wiederherstellung verteilter Transaktionen, Unterstützung für parallele Anwendungsaktualisierungen sowie eine Hochverfügbarkeitsdatenbank zur Speicherung des Übergangsstatus von J2EE-Anwendungen.

Die Hochverfügbarkeit ermöglicht den Failover-Schutz für Application Server-Instanzen in einem Cluster. Wenn eine Application Server-Instanz zusammenbricht, übernimmt eine andere Application Server-Instanz die Sitzungen des nicht mehr verfügbaren Servers. Sitzungsinformationen werden in der HADB gespeichert. Die HADB unterstützt Persistenzspeicherung für HTTP-Sitzungen, Stateful Session Beans und Single Sign On-Anmeldeinformationen.

- Previous: Behobene Programmfehler in Version 8.1, Update 2
- Next: Application Server-Produktversionen

- © 2010, Oracle Corporation and/or its affiliates