Code für kontinuierliche Verfügbarkeit

Ihre Anwendungen erreichen kontinuierliche Verfügbarkeit, wenn geplante Wartungsvorgänge, ungeplante Ausfälle und unausgewogene Belastungen der Datenbank vor der Anwendung verborgen werden. Eine Kombination aus Best Practices für Anwendungen, einfacher Konfiguration und Oracle Autonomous Database stellt sicher, dass Ihre Anwendungen kontinuierlich verfügbar sind.

Die beste Methode zum Verbergen geplanter Wartungsaktivitäten vor Ihren Anwendungen besteht darin, die Arbeit von jedem Datenbank-Workload-Speicherort vor dem Wartungsfenster für diesen Workload-Speicherort transparent per Drain zu entfernen. Die Verbindungspools und Mid-Tiers von Oracle, einschließlich WebLogic Server, Oracle Universal Connection Pool (UCP), OCI Session Pool und nicht verwalteter ODP.NET-Provider sind Fast Application Notification-(FAN-)fähig und werden daher benachrichtigt, bevor Datenbankservices verschoben werden, um ein ordnungsgemäßes Draining der Arbeit vor der Wartung zu ermöglichen. Die FAN-Benachrichtigung löst automatisch das Schließen inaktiver Verbindungen und das Öffnen neuer Verbindungen am neuen Serviceort aus und ermöglicht so eine konfigurierbare Zeit für den Abschluss aktiver Arbeiten an dem Serviceort, der in Kürze heruntergefahren wird. Die wichtigsten JDBC-Mid-Tiers von Drittanbietern, wie IBM WebSphere, ermöglichen bei Konfiguration mit UCP dasselbe Verhalten. Für JDBC-basierte Anwendungen, die UCP nicht verwenden können, stellt Oracle Lösungen mit Oracle-Treibern und Verbindungstests bereit.

Um ungeplante Ausfälle aufgrund eines Komponenten- oder Kommunikationsfehlers zu verbergen, stellt Oracle Folgendes bereit:

  • Benachrichtigung. FAN ist der erste Schritt zum Verbergen von Ausfällen. FAN benachrichtigt Clients und beendet ihren aktuellen Netzwerk-Wait-Status, wenn ein Ausfall auftritt. Dadurch wird verhindert, dass Anwendungen durch lange Netzwerk-Waits blockiert werden. Wichtig: FAN ruft auch das Rebalancing von Sessions auf, wenn Services wieder verfügbar sind.

  • Recovery. Nachdem der Client benachrichtigt wurde, stellt Transparent Application Continuity (TAC) oder Application Continuity (AC) eine Verbindung zu einem neuen Workload-Speicherort (eine andere Datenbankinstanz in der Real Application Clusters-(RAC-)Konfiguration, in der die Datenbank ausgeführt wird) wieder her und wiederholt die aktive (nicht festgeschriebene) Arbeit nach Möglichkeit. Durch die Wiederholung der aktiven Arbeit am neuen Speicherort kann die Anwendung in der Regel weiter ausgeführt werden, ohne über den Fehler informiert zu werden.

TAC oder AC wird auch während der geplanten Wartung für Sessions ausgeführt, die während des zugewiesenen Drain-Intervalls keinen Drain-Vorgang (Abschluss des aktuellen Datenbankvorgangs) ausführen.

Verwandte Themen

Checkliste für Anwendungskonfiguration

Mithilfe der folgenden Richtlinien können Sie die Anwendung kontinuierlich zur Verfügung stellen:

Tipp:

In dem Continuous Availability for Applications on ATP-Direct Whitepaper erhalten Sie Informationen zu den Best Practices bei der Implementierung der kontinuierlichen Verfügbarkeit für Anwendungen mit einer Autonomous Database.

Mit Datenbankservices verbinden

Datenbankservices bieten Transparenz für die zugrunde liegende Infrastruktur: FAN, Verbindungsdaten, Transparent Application Continuity (TAC), Application Continuity (AC), Switchover, Consumer-Gruppen und viele andere Features und Vorgänge basieren auf der Verwendung von Services.

Autonomous Database on Dedicated Exadata Infrastructure bietet mehrere Paare vordefinierter Datenbankservices zur Auswahl, wie unter Namen vordefinierter Datenbankservices für autonome Datenbanken beschrieben. Alle stellen FAN und Draining bereit, und für die beiden Transaktionsverarbeitungspaare ist TAC standardmäßig aktiviert. Zum Ändern der TAC- oder AC-Einstellungen für alle vordefinierten Services ist eine API verfügbar (siehe Serviceattribute für Failover aktivieren).

Verbindungszeichenfolge für High Availability konfigurieren

Oracle empfiehlt die unten gezeigte Konfiguration der Verbindungszeichenfolge für die Verbindung mit Oracle Autonomous Database. In der von Oracle bereitgestellten Datei tnsnames.ora eingebettete Verbindungszeichenfolgen werden auf diese Weise konfiguriert. Verwenden Sie nicht die Easy Connect-Benennung für den Client, da diese Verbindungen keine High-Availability-Funktionen haben.

Verwenden Sie diesen TNS für alle Oracle-Clients ab Version 12.2:

alias = 
(DESCRIPTION =
(CONNECT_TIMEOUT= 120)(RETRY_COUNT=20)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)
 (ADDRESS_LIST =
   (LOAD_BALANCE=on)
   (ADDRESS = (PROTOCOL = TCP)(HOST=scan-host)(PORT=1521)))
 (CONNECT_DATA=(SERVICE_NAME = service-name)))

Verwenden Sie Folgendes für JDBC-Verbindungen mit Oracle-Treiberversion 12.1 oder niedriger.

alias =
(DESCRIPTION =
(CONNECT_TIMEOUT= 15)(RETRY_COUNT=20)(RETRY_DELAY=3)
(ADDRESS_LIST =
  (LOAD_BALANCE=on)
  (ADDRESS = (PROTOCOL = TCP)(HOST=scan-host)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME = service-name)))

Fast Application Notification (FAN) verwenden

FAN benachrichtigt eine Anwendung sofort, wenn ein Service ausfällt oder wiederaufgenommen wird. Ohne FAN können Anwendungen nach Hardware- und Netzwerkausfällen mit TCP/IP-Timeout hängen bleiben und beim Wiederaufnehmen von Ressourcen das Rebalancing versäumen. Alle Oracle-Pools und Oracle-Anwendungsserver verwenden FAN. JAVA-Anwendungsserver von Drittanbietern können UCP verwenden, um FAN zu aktivieren.

Für die Verwendung von FAN sind keine Anwendungsänderungen erforderlich. Hierbei handelt es sich lediglich um Konfigurationsänderungen.

Für einen kontinuierlichen Service während einer geplanten Wartung verwenden Sie FAN mit:

  • Oracle-Pools oder
  • UCP mit JDBC-Anwendungsservern von Drittanbietern oder
  • Den neuesten Oracle-Clienttreibern

Für einen kontinuierlichen Service bei ungeplanten Ausfällen verwenden Sie FAN mit:

  • Transparent Application Continuity oder
  • Application Continuity

FAN-Abdeckung

FAN-Ereignisse sind in folgende Komponenten integriert:

  • Oracle Fusion Middleware und Oracle WebLogic Server
  • Oracle Data Guard Broker
  • Oracle JDBC Universal Connection Pool oder Treiber für JDBC Thin- und Oracle Call Interface-(OCI-)Schnittstellen
  • ODP.NET-Verbindungspool für nicht verwaltete und verwaltete Provider
  • Oracle Tuxedo
  • SQL*Plus
  • Oracle Database-Treiber für Sprachen wie Python, Node.js und PHP
  • Global Data Services
  • JDBC-Anwendungsserver von Drittanbietern mit Oracle JDBC Universal Connection Pool
  • Listener

So aktivieren Sie FAN im Client

Verwenden Sie den TNS-Alias, der unter Verbindungszeichenfolge für High Availability konfigurieren angezeigt wird. Mit dieser Verbindungszeichenfolge wird das Oracle Notification Service-(ONS-)Abonnement auf dem Client automatisch für den FAN-Ereignisempfang konfiguriert, wenn Sie einen Clienttreiber von Oracle Database 12c oder höher verwenden. ONS stellt einen sicheren Kommunikationspfad zwischen der Database Tier und der Clienttier bereit, über den der Client über die Serviceverfügbarkeit (Stoppen oder Starten von Komponenten) benachrichtigt werden kann, sowie einen Load-Balancing-Hinweis zur Laufzeit für eine bessere Arbeitsplatzierung während des normalen Betriebs.

Aktivieren Sie FAN abhängig vom Client wie folgt in den Eigenschaften der Anwendungskonfiguration:

  • Universal Connection Pool oder JDBC Thin-Treiber (ab 12.2)

    Legen Sie die Eigenschaft FastConnectionFailoverEnabled fest.

  • WebLogic Active GridLink für Oracle

    RAC-FAN und Fast Connection Failover sind standardmäßig aktiviert.

  • Oracle WebLogic Server, IBM WebSphere, IBM Liberty, Apache Tomcat, Red Hat WildFly (JBoss), JDBC-Anwendungen

    Verwenden Sie Universal Connection Pool als Ersatz für den Verbindungspool.

  • ODP.Net-Clients (verwaltete und nicht verwaltete Provider)

    Legen Sie "HA events = true;pooling=true" in der Verbindungszeichenfolge fest, wenn Sie ODP.Net 12.1 oder früher verwenden.

  • Oracle Call Interface-(OCI-)Clients und OCI-basierte Treiber

    Oracle Call Interface-(OCI-)Clients ohne native Einstellungen können die Datei oraacces.xml verwenden und events auf true setzen.

    Python, Node.js und PHP verfügen über native Optionen. In Python und Node.js können Sie beim Erstellen eines Verbindungspools einen Ereignismodus festlegen. Bearbeiten Sie in PHP php.ini, und fügen Sie den Eintrag oci8.events=on hinzu.

  • SQL*Plus

    FAN ist standardmäßig aktiviert.

Die vordefinierten Datenbankservices bieten TCPS-Verbindungen, die eine TLS-Wallet-basierte Authentifizierung verwenden. Je nach Anwendungstyp (JDBC oder Oracle Call Interface) muss die Wallet-Konfiguration bestimmte Regeln befolgen, wie unter Clients für FAN mit optionalen Wallets konfigurieren beschrieben.

Empfohlene Vorgehensweisen zum Zulassen von Draining verwenden

Als Best Practice für die Anwendungsnutzung wird empfohlen, Verbindungen für die benötigte Zeit auszuchecken und sie nach Abschluss der aktuellen Aktion wieder in den Pool einzuchecken. Das ist wichtig für eine gute Performance, für das Rebalancing von Arbeit zur Laufzeit und während Wartungsfenstern für das Draining der Arbeit.

Oracle empfiehlt die Verwendung eines FAN-bewussten Oracle-Verbindungspools zum Ausblenden der geplanten Wartung. Es ergeben sich keine Auswirkungen für Benutzer, wenn eine Anwendung einen Oracle-Pool mit FAN verwendet und zwischen Anforderungen Verbindungen zum Pool zurückgibt. Sie müssen keine Anwendungsänderungen vornehmen, um FAN zu verwenden. Wenn ein Oracle-Verbindungspool das FAN-Ereignis für eine geplante Ausfallzeit empfängt, werden alle Verbindungen auf der Instanz zum Draining markiert. Eingecheckte Verbindungen werden sofort geschlossen, damit sie nicht wiederverwendet werden. Da genutzte Verbindungen in den Pool zurückgegeben werden, werden sie geschlossen. Dadurch können alle Verbindungen im Laufe der Zeit ordnungsgemäß geschlossen werden.

Wenn Sie einen Java-basierten Anwendungsserver eines Drittanbieters verwenden, besteht die effektivste Methode für Draining und Failover darin, die gepoolte Datenquelle durch UCP zu ersetzen. Viele Anwendungsserver unterstützen diesen Ansatz, darunter Oracle WebLogic Server, IBM WebSphere, IBM Liberty, Apache Tomcat, Red Hat WildFly (JBoss), Spring, Hibernate und andere. Whitepaper von Oracle und anderen Providern, wie IBM, beschreiben die Verwendung von UCP mit diesen Anwendungsservern. Mit UCP als Datenquelle können UCP-Features wie Fast Connection Failover, Runtime Load Balancing, Application Continuity und Transparent Application Continuity mit vollständiger Zertifizierung verwendet werden.

Transparent Application Continuity (TAC) oder Application Continuity (AC) aktivieren

TAC überwacht Session- und Transaktionsstatus transparent und zeichnet sie auf, sodass eine Datenbanksession nach behebbaren Ausfällen wiederhergestellt werden kann. Für die beiden Transaktionsverarbeitungspaare vordefinierter Datenbankservices ist TAC standardmäßig aktiviert.

AC ist anpassbar, sodass Sie bei einem Failover wahlweise Nebeneffekte wiedergeben oder komplexe Callbacks hinzufügen können, die TAC nicht zulässt. Verwenden Sie AC, wenn Sie Oracle 12c-Treiber (JDBC Thin oder Oracle Call Interface) verwenden, Nebeneffekte oder Callbacks anpassen möchten oder eine Anwendung verwenden, die Status wie temporäre Sessiondauertabellen verwendet und Anforderungen nicht bereinigt.

Schritte für die Verwendung von Transparent Application Continuity

  • Informationen zum Aktivieren von Transparent Application Continuity im verwendeten Datenbankservice finden Sie unter Serviceattribute für Failover aktivieren.

  • Verwenden Sie einen der folgenden unterstützten Clients.

    Oracle empfiehlt dringend, die neuesten Clienttreiber zu verwenden. Oracle Database 19c-Clienttreiber und höher bieten vollständige Unterstützung für TAC.

    • Oracle JDBC-Replay-Treiber 18c oder höher. Dieses JDBC-Treiberfeature wird mit Oracle Database 18c für Application Continuity bereitgestellt.
    • Oracle Universal Connection Pool (UCP) 18c oder höher mit Oracle JDBC-Replay-Treiber 18c oder höher.
    • Oracle WebLogic Server Active GridLink oder JDBC-Anwendungsserver anderer Hersteller, die UCP mit Oracle JDBC-Replay-Treiber 18c oder höher verwenden.
    • Java-Verbindungspools oder Standalone-Java-Anwendungen mit Oracle JDBC-Replay-Treiber 18c oder höher.
    • Oracle Call Interface-Sessionpool 19c oder höher.
    • SQL*Plus 19c (19.3) oder höher
    • ODP.NET in Pool, Unmanaged Driver 18c oder höher ("Pooling=true" wird in Version 12.2 und höher standardmäßig verwendet).
    • Oracle Call Interface-basierte Anwendungen mit OCI-Treiber 19c oder höher.

  • Verbindungen an den Verbindungspool zurückgeben.

    Sie müssen keine Änderungen an der Anwendung vornehmen, um Anforderungsgrenzen zu identifizieren, wenn die Anwendung folgende Verbindungen verwendet:

    • Von den Oracle-Verbindungspools oder
    • Vom Oracle JDBC-Replay-Treiber 18c oder höher oder
    • Von Oracle Call Interface-basierten Anwendungen mit 19c oder höher

    Wenn Sie Verbindungspools verwenden, sollte die Anwendung die Verbindung nach Abschluss jeder Anforderung an den Pool zurückgeben. Oracle empfiehlt, dass Anwendungen eine Verbindung nur nach Bedarf aufrechterhalten. Das Aufrechterhalten einer nicht benötigten Verbindung ist nicht empfehlenswert. Transparent Application Continuity mit den aufgeführten Treibern erkennt auch, wo Grenzen hinzugefügt werden können, und erstellt eigene Grenzen.

  • Verwenden Sie FAILOVER_RESTORE.

    Durch Aktivieren von Transparent Application Continuity werden vordefinierte Sessionstatus automatisch wiederhergestellt. Wenn Sie zusätzlich zum Standardset voreingestellte Sessionstatus benötigen, können Sie ein Callback- oder UCP-Label registrieren, um diese Status wiederherzustellen. Wenn Sie komplexe Sessionstatus wie temporäre Tabellen oder SYS_CONTEXT wiederherstellen müssen, verwenden Sie Application Continuity, das diese Flexibilität bietet.

  • Veränderbare Funktionen in der Anwendung aktivieren

    Veränderbare Funktionen können bei jeder Ausführung einen neuen Wert zurückgeben. Die Speicherung der ursprünglichen Ergebnisse wird für SYSDATE, SYSTIMESTAMP, SYS_GUID und sequence.NEXTVAL unterstützt. In Application Continuity 19c und höher ist der Parameter KEEP für veränderbare SQL-Funktionen automatisch aktiviert. Wenn Ihre Anwendung veränderbare Funktionen verwendet oder für diese sensibel ist, muss ein DBA die Berechtigung GRANT KEEP erteilen. Wenn die Berechtigung KEEP erteilt wird, wird das ursprüngliche Funktionsergebnis bei der Wiedergabe angewendet. Beispiel: 

    SQL> GRANT [KEEP DATE TIME | KEEP SYSGUID] … TO USER
    SQL> GRANT KEEP SEQUENCE mySequence TO myUser ON sequence.object

  • Nebeneffekte sind deaktiviert

    Ein Nebeneffekt ist eine externe Aktion wie das Senden von E-Mails, Übertragen von Dateien oder Verwenden von TCP. Transparent Application Continuity erkennt Nebeneffekte und gibt sie nicht wieder. Wenn Sie die Nebeneffekte wiedergeben möchten, verwenden Sie Application Continuity, das diese zusätzliche Flexibilität bietet.

Schritte für die Verwendung von Application Continuity

  • Informationen zum Aktivieren von Application Continuity im verwendeten Datenbankservice finden Sie unter Serviceattribute für Failover aktivieren.

  • Verwenden Sie einen der folgenden unterstützten Clients.

    • Oracle JDBC-Replay-Treiber 12c oder höher. Dieses JDBC-Treiberfeature wird mit Oracle Database 12c für Application Continuity bereitgestellt.
    • Oracle Universal Connection Pool (UCP) 12c oder höher mit Oracle JDBC-Replay-Treiber 12c oder höher.
    • Oracle WebLogic Server Active GridLink und JDBC-Anwendungsserver anderer Hersteller, die UCP mit Oracle JDBC-Replay-Treiber 12c oder höher verwenden.
    • Java-Verbindungspools oder Standalone-Java-Anwendungen mit Oracle JDBC-Replay-Treiber 12c oder höher mit Anforderungsgrenzen oder Datenquelle in Pool.
    • Anwendungen und Sprachtreiber mit Oracle Call Interface Session Pool 12c Release 2 oder höher.
    • SQL*Plus 19.3 oder höher.
    • ODP.NET in Pool, Unmanaged Driver 12c Release 2 oder höher ("Pooling=true"; "Application Continuity=true" wird in Version 12.2 und höher standardmäßig verwendet).

  • Verbindungen an den Verbindungspool zurückgeben.

    Sie müssen keine Änderungen an der Anwendung vornehmen, um Anforderungsgrenzen zu identifizieren, wenn die Anwendung einen Oracle-Verbindungspool oder einen JDBC-Pool eines anderen Herstellers verwendet, der Anforderungsgrenzen unterstützt. Als Best Practice wird empfohlen, einen Oracle-Pool zu verwenden und die Verbindungen zwischen Anforderungen an diesen Pool zurückzugeben. Oracle empfiehlt, dass Anwendungen eine Verbindung nur nach Bedarf aufrechterhalten. Das Aufrechterhalten einer nicht benötigten Verbindung ist nicht empfehlenswert und verhindert eine transparente geplante Wartung.

  • Verwenden Sie FAILOVER_RESTORE.

    Die meisten allgemeinen Status werden automatisch mit FAILOVER_RESTORE=LEVEL1 wiederhergestellt. Wenn Ihre Anwendung zusätzlich zum Standardset voreingestellte Sessionstatus verwendet, können Sie ein Callback- oder UCP-Label registrieren, um diese Status wiederherzustellen. Legen Sie FAILOVER_RESTORE=LEVEL1 für den Service fest, und verwenden Sie:

    • Verbindungsinitialisierungs-Callback für Java oder den (älteren) TAF-Callback für Oracle Call Interface oder
    • Universal Connection Pool oder WebLogic Server Connection Labeling

  • Veränderbare Funktionen in der Anwendung aktivieren

    Veränderbare Funktionen können bei jeder Ausführung einen neuen Wert zurückgeben. Die Speicherung der ursprünglichen Ergebnisse wird für SYSDATE, SYSTIMESTAMP, SYS_GUID und sequence.NEXTVAL unterstützt. In Application Continuity 19c und höher ist der Parameter KEEP für veränderbare SQL-Funktionen automatisch aktiviert, sodass keine Aktion erforderlich ist. Wenn Sie veränderbare Funktionen für PL/SQL benötigen, muss ein DBA die Berechtigung GRANT KEEP erteilen. Wenn die Berechtigung KEEP erteilt wird, wird das ursprüngliche Funktionsergebnis bei der Wiedergabe angewendet. Beispiel: 

    SQL> GRANT [KEEP DATE TIME | KEEP SYSGUID] … TO USER
    SQL> GRANT KEEP SEQUENCE mySequence TO myUser ON sequence.object

  • Bestimmen, ob Nebeneffekte wiedergegeben werden sollen

    Ein Nebeneffekt ist eine externe Aktion wie das Senden von E-Mails, Übertragen von Dateien oder Verwenden von TCP. Bei Application Continuity werden Nebeneffekte wiedergegeben, sofern die Anwendung nichts anderes angibt. Wenn eine externe Aktion einer Anforderung nicht wiedergegeben werden soll, kann diese Anforderung eine Verbindung verwenden, für die Application Continuity nicht aktiviert ist, oder die Wiedergabe kann für diese Anforderung mit der API disableReplay() für Java oder OCIRequestDisableReplay() für Oracle Call Interface deaktiviert werden. Wenn Sie nicht alle Nebeneffekte wiedergeben möchten, verwenden Sie Transparent Application Continuity.