Oracle Cloud Infrastructure-Dokumentation

Clientkonfiguration für kontinuierliche Verfügbarkeit in Autonomous Database

Sie müssen Anwendungen für geplante Wartungsaktivitäten nicht neu starten, wenn Sie Application Continuity aktivieren und die Best Practices für die Codierung befolgen.

Übergeordnetes Thema: Application Continuity in Autonomous Database verwenden

Verbindung mit Datenbankservices mit aktivierter Application Continuity herstellen

Oracle-Datenbankservices bieten Transparenz für die zugrunde liegende Autonomous Database-Infrastruktur.

Die High Availability- und Application Continuity-Vorgänge basieren auf der Verwendung von Autonomous Database-Verbindungsservices. Um die Anwendungskontinuität zu erhalten, verwenden Sie einen Datenbankservice, wenn Sie sich bei der Datenbank anmelden.

Die Namen der vordefinierten Datenbankservices in Autonomous Database sind je nach Workload unterschiedlich, wie unter Datenbankservicenamen für Autonomous Database beschrieben.

Empfohlene Vorgehensweisen zur Unterstützung von Draining verwenden

In Autonomous Database müssen Anwendungsserver nie neu gestartet werden, wenn die geplante Wartung den Best Practices folgt.

Bei der geplanten Wartung wird empfohlen, Zeit für den Abschluss der aktuellen Arbeit bereitzustellen, bevor die Wartung gestartet wird. In Autonomous Database geschieht dies automatisch, und die Arbeit wird abgelassen, bevor Wartungsaktivitäten gestartet werden, wenn Sie die folgenden Richtlinien befolgen:

  • FAN mit Oracle-Verbindungspools oder Oracle-Treibern
  • Verbindungstests

Verwenden Sie Draining in Kombination mit der von Ihnen gewählten Failover-Lösung für Anforderungen, die nicht innerhalb der zugewiesenen Zeit für Draining abgeschlossen werden. Ihre Failover-Lösung versucht, Sessions wiederherzustellen, die nicht in der zugewiesenen Zeit ablaufen.

Verbindungen an den Connection Pool zurückgeben

Die Anwendung sollte die Verbindung bei jeder Anforderung an den Connection Pool zurückgeben. Es wird empfohlen, dass eine Anwendung eine Verbindung nur für die Zeit auscheckt, die sie benötigt. Eine Verbindung zu halten, anstatt sie an den Pool zurückzugeben, wird nicht ausgeführt. Eine Anwendung sollte daher eine Verbindung auschecken und dann diese Verbindung sofort einchecken, wenn die Arbeit abgeschlossen ist. Die Verbindungen sind dann für die spätere Verwendung durch andere Threads oder Ihren Thread verfügbar, wenn sie erneut benötigt werden. Das Zurückgeben von Verbindungen zu einem Connection Pool ist eine allgemeine Empfehlung, unabhängig davon, ob Sie FAN zum Drain oder Verbindungstests zum Drain verwenden.

Oracle-Verbindungspool verwenden

Mit einem FAN-bewussten Oracle-Verbindungspool wird empfohlen, die geplante Wartung zu verbergen. Wenn die Wartung fortschreitet und abgeschlossen ist, werden Sessions verschoben und neu verteilt. 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. Unterstützte Oracle Pools sind UCP, WebLogic GridLink, Tuxedo, OCI Session Pool und ODP.NET Managed und Unmanaged Provider. Für die Verwendung von FAN sind keine Anwendungsänderungen erforderlich, es sei denn, Sie stellen sicher, dass die Verbindungen zwischen den Anforderungen an den Pool zurückgegeben werden.

UCP mit einem Verbindungspool eines Drittanbieters verwenden

Wenn Sie einen Java-basierten Anwendungsserver eines Drittanbieters verwenden, besteht die effektivste Methode für Draining und Failover darin, die gepoolte Datenquelle mit UCP zu ersetzen. Dieser Ansatz wird von vielen Anwendungsservern unterstützt, darunter Oracle WebLogic Server, IBM WebSphere, IBM Liberty, Apache Tomcat, Red Hat WildFly (JBoss), Spring und Hibernate usw.

Verbindungstests verwenden

Wenn Sie keinen Oracle Pool mit FAN verwenden können, wird die Session von den Autonomous Database- oder angegebenen Clienttreibern drainiert. Wenn Services während der Wartung umgespeichert oder gestoppt werden oder ein Switchover mit Autonomous Data Guard auf eine Standbysite erfolgt, suchen die Oracle Database- und Oracle-Clienttreiber nach sicheren Orten, an denen Verbindungen gemäß den folgenden Regeln freigegeben werden können:

  • Standardverbindungstests für die Verbindungsgültigkeit beim Ausleihen oder Zurückgeben aus einem Verbindungspool
  • Benutzerdefinierte SQL-Tests für die Verbindungsgültigkeit
  • Anforderungsgrenzen sind gültig, und die aktuelle Anforderung wurde beendet

Verbindungstests mit Autonomous Database verwenden

Sie können Verbindungstests für Autonomous Database hinzufügen, löschen, aktivieren oder deaktivieren.

Verwenden Sie die Ansicht DBA_CONNECTION_TESTS, um die verfügbaren Verbindungstests anzuzeigen.

Beispiel:

SQL> EXECUTE 
   dbms_app_cont_admin.add_sql_connection_test('SELECT COUNT(1) FROM DUAL');
SQL> EXECUTE 
   dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.sql_test, 
                                             'SELECT COUNT(1) FROM DUAL');
SQL> SELECT * FROM DBA_CONNECTION_TESTS;

Konfigurieren Sie denselben Verbindungstest, der in Ihrer Datenbank im Verbindungspool oder Anwendungsserver aktiviert ist. Konfigurieren Sie außerdem das Leeren und Löschen des Pools bei einem Verbindungstestfehler, der mindestens das Doppelte der maximalen Poolgröße oder MAXINT beträgt.

Verbindungstests mit Thin Java-Treiber verwenden

Wenn Sie Verbindungstests verwenden möchten, die lokal für den Treiber sind und die volle FAN-Unterstützung von UCP nicht verwenden können:

  • validate-on-borrow=true aktivieren
  • Legen Sie die Java-Systemeigenschaften fest:
    • -Doracle.jdbc.fanEnabled=true
    • -Doracle.jdbc.defaultConnectionValidation=SOCKET

Und dann einen der folgenden Tests verwenden:

  • java.sql.Connection.isValid(int timeout)
  • oracle.jdbc.OracleConnection.pingDatabase()
  • oracle.jdbc.OracleConnection.pingDatabase(int timeout)
  • Eine HINT zu Beginn des Test-SQL:
    • /*+ CLIENT_CONNECTION_VALIDATION */

Verbindungstests mit OCI-Treiber verwenden

Wenn Sie den OCI-Treiber direkt verwenden möchten, verwenden Sie OCI_ATTR_SERVER_STATUS. Dies ist die einzige Methode, die eine Codeänderung ist. Überprüfen Sie in Ihrem Code das Server-Handle, wenn Sie Verbindungen ausleihen und zurückgeben, um zu sehen, ob die Session getrennt ist. Während der Wartung wird der Wert von OCI_ATTR_SERVER_STATUS auf OCI_SERVER_NOT_CONNECTED gesetzt. Wenn Sie den OCI-Sessionpool verwenden, wird diese Verbindungsprüfung für Sie durchgeführt.

Das folgende Codebeispiel zeigt, wie OCI_ATTR_SERVER_STATUS verwendet wird: 

ub4 serverStatus = 0OCIAttrGet((dvoid *)srvhp,
          OCI_HTYPE_SERVER,             
        (dvoid *)&serverStatus, (ub4 *)0, OCI_ATTR_SERVER_STATUS,
      errhp);if (serverStatus ==
        OCI_SERVER_NORMAL)printf("Connection is
        up.\n");else if (serverStatus ==
        OCI_SERVER_NOT_CONNECTED) printf("Connection is down.\n");

Schritte für die Verwendung von Application Continuity

Führen Sie die folgenden Schritte aus, um Application Continuity zu verwenden:

  • Aktivieren und konfigurieren Sie Application Continuity oder Transparent Application Continuity (TAC) als Voraussetzung für Ihren Datenbankservice in Autonomous Database. Weitere Informationen finden Sie unter Application Continuity in Autonomous Database konfigurieren.

  • Oracle empfiehlt dringend, die neuesten Clienttreiber zu verwenden. 19c-Clienttreiber von Oracle Database und höher bieten vollständige Unterstützung für Application Continuity (AC) und Transparent Application Continuity (TAC). Verwenden Sie einen der folgenden unterstützten Clienttreiber:

    • Oracle JDBC-Replay-Treiber 19c oder höher. Dieses JDBC-Treiberfeature wird mit Oracle Database 19c für Application Continuity bereitgestellt

    • Oracle Universal Connection Pool (UCP) 19c oder höher mit Oracle JDBC-Replay-Treiber 19c oder höher

    • Oracle Weblogic Server 12c mit Active GridLink oder JDBC-Anwendungsserver anderer Anbieter, die UCP mit Oracle JDBC-Replay-Treiber 19c oder höher verwenden

    • Java-Verbindungspools oder Standalone-Java-Anwendungen mit Oracle JDBC-Replay-Treiber 19c oder höher

    • Oracle Call Interface-Sessionpool 19c oder höher.SQL*Plus 19c (19.8) oder höher

    • ODP.NET in Pool, Unmanaged Driver 19c oder höher ("Pooling=true"-Standardwert in 12.2 und höher)

    • Oracle Call Interface-basierte Anwendungen mit OCI-Treiber 19c oder höher

Verbindungen an den Connection Pool zurückgeben

Die Anwendung muss die Verbindung bei jeder Anforderung an den Oracle-Verbindungspool zurückgeben. Als Best Practice für den Anwendungsnutzung wird es empfohlen, Verbindungen für das benötigte Zeit auszuchecken und sie nach Abschluss der aktuellen Aktionen wieder in den Pool einzuchecken, wenn sie abgeschlossen sind. Dies ist wichtig für die beste Anwendungsperformance zur Laufzeit, für das Rebalancing von Arbeiten zur Laufzeit und während Wartungs- und Failover-Ereignissen. Diese Praxis ist auch für das Entleeren wichtig.

Wenn Sie einen Oracle-Verbindungspool wie Universal Connection Pool (UCP) oder OCI Session Pool oder ODP.Net Unmanaged Provider verwenden oder WebLogic Active GridLink verwenden, werden in dieser Übung Anforderungsgrenzen eingebettet, die Application Continuity verwendet, um sichere Orte zum Fortsetzen und Beenden der Erfassung zu identifizieren. Dies ist für Application Continuity erforderlich und wird für Transparent Application Continuity empfohlen.

Transparent Application Continuity erkennt außerdem Anforderungsgrenzen, wenn ein Pool nicht verwendet wird oder wenn die Wiedergabe deaktiviert ist. Die Bedingungen für die Entdeckung einer Grenze sind:

  • Keine offene Transaktion
  • Cursor werden an den Anweisungscache zurückgegeben oder abgebrochen
  • Es ist kein nicht wiederherstellbarer Sessionstatus vorhanden (siehe "Sessionstatus zwischen Anforderungen bereinigen" in diesem Dokument)

In der Anwendung verwendete veränderbare Funktionen aktivieren

Veränderbare Funktionen können bei jeder Ausführung einen neuen Wert zurückgeben. Die Speicherung der ursprünglichen Ergebnisse mutierbarer Funktionen wird für SYSDATE, SYSTIMESTAMP, SYS_GUID und sequence bereitgestellt.NEXTVAL. Wenn die ursprünglichen Werte nicht beibehalten werden und bei der Wiedergabe andere Werte an die Anwendung zurückgegeben werden, wird die Wiedergabe abgelehnt.

Wenn Sie mutables für PL/SQL benötigen, geben Sie GRANT KEEP nach Bedarf aus.

Beispiel:

SQL> GRANT KEEP DATE TIME to adb_user;
SQL> GRANT KEEP SYSGUID to adb_user;
SQL> GRANT KEEP SEQUENCE mySequence to adb_user on mysequence.myobject;

Nebenwirkungen

Wenn eine Datenbankanforderung einen externen Aufruf enthält, wie das Senden von MAIL oder das Übertragen einer Datei, wird dies als Nebeneffekt bezeichnet.

Nebenwirkungen sind äußere Handlungen, sie rollen nicht zurück. Wenn die Wiedergabe erfolgt, gibt es die Wahl, ob Nebenwirkungen wiedergegeben werden sollen. Viele Anwendungen wiederholen Nebenwirkungen wie Journaleinträge und das Senden von E-Mails als doppelte Ausführungen verursachen kein Problem. Für Application Continuity werden Nebeneffekte wiedergegeben, es sei denn, die Anforderung oder der Benutzeraufruf ist für die Wiedergabe explizit deaktiviert. Umgekehrt, da Transparent Application Continuity standardmäßig aktiviert ist, gibt TAC keine Nebeneffekte wieder. Der Capture-Prozess ist deaktiviert und wird an der nächsten impliziten, von TAC erstellten Grenze erneut aktiviert.

Best Practices für Entwickler für kontinuierliche Verfügbarkeit

Befolgen Sie diese Best Practices, um kontinuierliche Verfügbarkeit in Autonomous Database zu codieren.

Verbindungen an den Connection Pool zurückgeben

Die wichtigste Übung für Entwickler besteht darin, Verbindungen an den Connection Pool am Ende jeder Anforderung zurückzugeben. Dies ist wichtig für die beste Anwendungsperformance zur Laufzeit, für das Drainieren von Arbeiten und für das Rebalancing von Arbeiten zur Laufzeit und während der Wartung sowie für die Übergabe von Failover-Ereignissen. Einige Anwendungen haben eine falsche Vorstellung, dass das Festhalten an Verbindungen die Leistung verbessert. Eine Verbindung wird weder ausgeführt noch skaliert.

Sessionzustand zwischen Anforderungen bereinigen

Es wird empfohlen, den Sessionzustand zwischen Datenbankanforderungen zu bereinigen.

Wenn eine Anwendung eine Verbindung zum Verbindungspool zurückgibt, bleiben Cursor mit dem FETCH-Status und dem für diese Session festgelegten Sessionstatus erhalten, es sei denn, es wird eine Aktion zum Löschen ausgeführt. Wenn Ihre Anwendung den Status festlegt, sollten Sie die Cursor in den Anweisungscache zurückversetzen und den anwendungsbezogenen Sessionzustand löschen, um zu verhindern, dass diese Datenbanksession später wieder verwendet wird. Durch Bereinigen des Sessionstatus wird sichergestellt, dass TAC Grenzen erkennen kann.

Um den Status zwischen Anforderungen mit Oracle Database 23ai automatisch zu bereinigen, legen Sie das Serviceattribut RESET_STATE=LEVEL1 fest. Dadurch werden Zustandsverluste vermieden und durch spätere Verwendung des Connection Pools aus Cursor abgerufen.

Wenn Sie Oracle Database 19c verwenden, verwenden Sie DBMS_SESSION.RESET_PACKAGE, um globale PL/SQL-Variablen zu löschen, verwenden Sie TRUNCATE, um temporäre Tabellen zu löschen, SYS_CONTEXT.CLEAR_CONTEXT, um den Kontext zu löschen und die Cursor abzubrechen, indem Sie sie in den Anweisungscache zurückgeben.

Wenn Ihre Anwendung zustandslos ist, wie REST, APEX, Microservice und die meisten Webanwendungen, ist es Best Practice, RESET_STATE zu verwenden.

COMMIT nicht in PL/SQL einbetten und COMMIT bei Erfolg und Autocommit vermeiden

Es wird empfohlen, einen Commit der obersten Ebene (OCOMMIT oder COMMIT() oder OCITransCommit) zu verwenden. Wenn Ihre Anwendung COMMIT verwendet, das in PL/SQL oder AUTOCOMMIT oder COMMIT ON SUCCESS eingebettet ist, kann nach einem Ausfall oder Timeout möglicherweise kein Recovery durchgeführt werden. PL/SQL ist nicht reentrant. Nachdem ein Commit in PL/SQL ausgeführt wurde, kann dieser PL/SQL-Block nicht erneut weitergeleitet werden. Anwendungen müssen entweder die Auswahl des Commits aufheben, was nicht so klingt, da diese Daten möglicherweise gelesen wurden, oder für Batch einen Checkpoint und eine Neustarttechnik verwenden. Wenn Sie AUTOCOMMIT oder COMMIT ON SUCCESS verwenden, geht die Ausgabe verloren.

Wenn Ihre Anwendung einen Commit der obersten Ebene verwendet, werden Transparent Application Continuity (TAC), Application Continuity (AC) und TAF Select Plus vollständig unterstützt. Wenn Ihre Anwendung COMMIT verwendet, das in PLSQL oder AUTOCOMMIT oder COMMIT ON SUCCESS eingebettet ist, ist es möglicherweise nicht möglich, die Wiedergabe für Fälle auszuführen, in denen der Aufruf einschließlich COMMIT nicht abgeschlossen wurde.

ORDER BY oder GROUP BY in Abfragen verwenden

Application Continuity stellt sicher, dass die Anwendung dieselben Daten bei der Wiedergabe sieht. Wenn dieselben Daten nicht wiederhergestellt werden können, akzeptiert Application Continuity die Wiedergabe nicht. Wenn eine SELECT ORDER BY- oder GROUP BY-Reihenfolge verwendet, wird diese beibehalten. In Autonomous Database verwendet der Abfrageoptimierer am häufigsten denselben Zugriffspfad, der bei der gleichen Reihenfolge der Ergebnisse helfen kann. Application Continuity verwendet auch eine AS OF-Klausel, um dieselben Abfrageergebnisse zurückzugeben, bei denen AS OF zulässig ist.

Überlegungen zu SQL*Plus

SQL*Plus ist oft unser Go-to-Tool zum Ausprobieren. SQL*Plus spiegelt natürlich nicht unsere tatsächliche Anwendung wider, die in der Produktion verwendet wird. Daher ist es immer besser, die echte Anwendungstest-Suite zu verwenden, um Ihren Failover-Plan zu testen und Ihren Schutz zu messen. SQL*Plus ist keine gepoolte Anwendung und verfügt daher nicht über explizite Anforderungsgrenzen. Einige Anwendungen verwenden SQL*Plus beispielsweise für Berichte. Um SQL*Plus mit Failover zu verwenden, prüfen Sie Folgendes:

  1. FAN ist immer für SQL*Plus aktiviert. Verwenden Sie die empfohlene Verbindungszeichenfolge, mit der ONS-Endpunkte automatisch konfiguriert werden.

  2. Wenn Sie SQL*plus verwenden, müssen Sie Roundtrips zur Datenbank minimieren: https://blogs.oracle.com/opal/sqlplus-12201-adds-new-performance-features

  3. SQL*Plus wird für TAC ab Oracle Database 19c unterstützt. Für beste Ergebnisse legen Sie eine große Arraysgröße fest. Beispiel (Setzen Sie die Arraysgröße 1000). Vermeiden Sie die Aktivierung von serveroutput, da dies zu einem nicht wiederherstellbaren Sessionzustand führt.