Oracle Cloud Infrastructure-Dokumentation

Clientkonfiguration für kontinuierliche Verfügbarkeit in Autonomous Database

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

Übergeordnetes Thema: Anwendungskontinuität in Autonomous Database verwenden

Verbindungen über Datenbankservices mit aktivierter Anwendungskontinuität herstellen

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

Die Hochverfügbarkeits- und Application Continuity-Vorgänge basieren auf der Verwendung von Autonomous Database-Verbindungsservices. Um Anwendungskontinuität abzurufen, verwenden Sie einen Datenbankservice, wenn Sie eine Verbindung zu Ihrer Datenbank herstellen.

Die Namen der vordefinierten Datenbankservices in Autonomous Database unterscheiden sich je nach Workload, wie unter Namen der Datenbankservices für Autonomous Database beschrieben.

Empfohlene Praktiken verwenden, die Draining unterstützen

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

Bei einer geplanten Wartung wird empfohlen, Zeit für den Abschluss der aktuellen Arbeit anzugeben, bevor die Wartung gestartet wird. In Autonomous Database geschieht dies automatisch. Wenn Sie die folgenden Richtlinien befolgen, wird das Draining ausgeführt, bevor Sie Wartungsaktivitäten starten:

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

Verwenden Sie Draining in Kombination mit der ausgewählten Failover-Lösung für Anforderungen, die nicht innerhalb der zugewiesenen Draining-Zeit abgeschlossen werden. Ihre Failover-Lösung versucht, Sessions wiederherzustellen, die während der zugewiesenen Zeit keinen Drain-Vorgang ausgeführt haben.

Verbindungen an den Verbindungspool zurückgeben

Die Anwendung sollte die Verbindung bei jeder Anforderung an den Verbindungspool zurückgeben. Als Best Practice wird empfohlen, dass eine Anwendung eine Verbindung nur für die benötigte Zeit auscheckt. Wenn eine Verbindung gehalten wird, anstatt sie an den Pool zurückzugeben, wird die Performance beeinträchtigt. Eine Anwendung sollte daher eine Verbindung auschecken und diese Verbindung sofort wieder einchecken, sobald die Arbeit abgeschlossen ist. Die Verbindungen können dann später von anderen Threads oder bei Bedarf von Ihrem Thread erneut verwendet werden. Das Zurückgeben von Verbindungen an einen Verbindungspool ist eine allgemeine Empfehlung, unabhängig davon, ob Sie FAN oder Verbindungstests für den Drain verwenden.

Oracle-Verbindungspool verwenden

Zum Ausblenden der geplanten Wartung wird die Verwendung eines FAN-fähigen Oracle-Verbindungspools empfohlen. Während der Wartung und bei ihrem Abschluss werden Sessions verschoben und durch Rebalancing 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. Zu den unterstützten Oracle-Pools gehören UCP, WebLogic GridLink, Tuxedo, OCI-Sessionpool sowie ODP.NET verwaltete und nicht verwaltete Provider. Für die Verwendung von FAN sind keine Anwendungsänderungen erforderlich. Sie müssen lediglich sicherstellen, dass Ihre Verbindungen zwischen den Anforderungen an den Pool zurückgegeben werden.

UCP mit einem Drittanbieterverbindungspool verwenden

Wenn Sie einen Java-basierten Anwendungsserver eines anderen Herstellers verwenden, ist die effektivste Methode für Draining und Failover die Ersetzung der gepoolten Datenquelle durch UCP. 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.

Verbindungstests verwenden

Wenn Sie keinen Oracle-Pool mit FAN verwenden können, führen die Autonomous Database- oder bereitgestellten Clienttreiber ein Draining der Session aus. Wenn Services während der Wartung umgespeichert oder gestoppt werden oder ein Switchover zu einer Standbysite mit Autonomous Data Guard erfolgt, suchen die Oracle Database- und Oracle-Clienttreiber nach den folgenden Regeln nach sicheren Orten zum Freigeben von Verbindungen:

  • Standardverbindungstests für Verbindungsgültigkeit bei Ausleihe oder Rückgabe aus einem Verbindungspool
  • Benutzerdefinierte SQL-Tests für Verbindungsgültigkeit
  • Anforderungsgrenzen sind wirksam, und die aktuelle Anforderung ist beendet

Verbindungstests mit Autonomous Database verwenden

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

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

Beispiele:

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 der Datenbank im Verbindungspool oder Anwendungsserver aktiviert ist. Konfigurieren Sie auch das Leeren und Löschen des Pools bei nicht erfolgreichen Verbindungstests auf mindestens das Zweifache der maximalen Poolgröße oder MAXINT.

Verbindungstests mit Thin-Java-Treiber verwenden

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

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

Verwenden Sie dann einen der folgenden Tests:

  • java.sql.Connection.isValid(int timeout)
  • oracle.jdbc.OracleConnection.pingDatabase()
  • oracle.jdbc.OracleConnection.pingDatabase(int timeout)
  • HINT am Anfang der 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 darstellt. Prüfen Sie in Ihrem Code das Server-Handle beim Ausleihen und Zurückgeben von Verbindungen, um festzustellen, ob die Session getrennt wurde. Während der Wartung wird der Wert OCI_ATTR_SERVER_STATUS auf OCI_SERVER_NOT_CONNECTED gesetzt. Bei Verwendung des OCI-Sessionpools erfolgt diese Verbindungsprüfung automatisch.

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

So verwenden Sie Application Continuity:

  • Als Voraussetzung müssen Sie Application Continuity oder Transparent Application Continuity (TAC) für Ihren Datenbankservice in Autonomous Database aktivieren und konfigurieren. Weitere Informationen finden Sie unter Application Continuity on Autonomous Database konfigurieren.

  • Oracle empfiehlt dringend, die neuesten Clienttreiber zu verwenden. Clienttreiber aus Oracle Database 19c 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 Hersteller, 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

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

    • ODP.NET in Pool, nicht verwalteter Treiber 19c 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

Die Anwendung sollte die Verbindung bei jeder Anforderung an den Oracle-Verbindungspool zurückgeben. Als Best Practice für die Anwendungsnutzung wird empfohlen, Verbindungen nur für die benötigte Zeit auschecken (ausleihen) und nach Abschluss der aktuellen Aktionen in den Pool einchecken. Dies ist wichtig für die beste Anwendungsperformance zur Laufzeit, für das Recovery zur Laufzeit und während Wartungs- und Failover-Ereignissen. Diese Vorgehensweise ist auch für das Draining wichtig.

Wenn Sie einen Oracle-Verbindungspool wie Universal Connection Pool (UCP), OCI-Sessionpool, oder ODP.Net Unmanaged Provider verwenden oder wenn Sie WebLogic Active GridLink verwenden, bettet die folgende Vorgehensweise Anforderungsgrenzen ein, mit denen Application Continuity die Erfassung an einem sicheren Ort fortsetzen und beenden kann. Dies ist für Application Continuity erforderlich und wird für Transparent Application Continuity empfohlen.

Darüber hinaus ermittelt Transparent Application Continuity Anforderungsgrenzen, wenn ein Pool nicht verwendet wird oder die Wiedergabe deaktiviert ist. Folgende Bedingungen gelten für das Erkennen einer Grenze:

  • Keine offene Transaktion
  • Cursor werden in den Anweisungscache zurückgegeben oder abgebrochen
  • Es ist kein nicht wiederherstellbarer Sessionstatus vorhanden (weitere Informationen finden Sie unter "Sessionstatus zwischen Anforderungen löschen")

In der Anwendung verwendete Mutables aktivieren

Veränderbare Funktionen können bei jeder Ausführung einen neuen Wert zurückgeben. Die Beibehung der ursprünglichen Ergebnisse veränderbarer Funktionen wird für SYSDATE, SYSTIMESTAMP, SYS_GUID und sequence.NEXTVAL unterstützt. 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 veränderbare Funktionen für PL/SQL benötigen, geben Sie nach Bedarf GRANT KEEP aus.

Beispiele:

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;

Auswirkungen

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

Nebenwirkungen sind externe Aktionen, die nicht zurückgerollt werden. Bei der Wiedergabe können Sie auswählen, ob Nebenwirkungen wiedergegeben werden sollen. Viele Anwendungen wiederholen Nebeneffekte wie Journaleinträge oder das Senden von E-Mails, da doppelte Ausführungen kein Problem verursachen. Für Application Continuity werden Nebeneffekte wiedergegeben, es sei denn, die Wiedergabe wird für die Anforderung oder den Benutzeraufruf explizit deaktiviert. Da Transparent Application Continuity standardmäßig aktiviert ist, gibt TAC keine Nebenwirkungen wieder. Der Capture-Vorgang ist deaktiviert und wird bei der nächsten von TAC erstellten impliziten Grenze erneut aktiviert.

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

Befolgen Sie diese Best Practices, um Code für kontinuierliche Verfügbarkeit in Autonomous Database zu schreiben.

Verbindungen an den Verbindungspool zurückgeben

Die wichtigste Vorgehensweise für Entwickler besteht darin, Verbindungen am Ende jeder Anforderung an den Verbindungspool zurückzugeben. Dies ist wichtig für die beste Anwendungsperformance zur Laufzeit, für das Draining und Rebalancing zur Laufzeit und während der Wartung sowie für die Verarbeitung von Failover-Ereignissen. Einige Anwendungen haben eine falsche Annahme, dass das Halten von Verbindungen die Performance verbessert. Wenn Sie eine Verbindung halten, wird sie weder ausgeführt noch skaliert.

Sessionstatus zwischen Anforderungen berichtigen

Als Best Practice wird empfohlen, den Sessionstatus zwischen Datenbankanforderungen zu löschen.

Wenn eine Anwendung eine Verbindung an den Verbindungspool zurückgibt, bleiben Cursor im FETCH-Status und der für diese Session festgelegte Sessionstatus erhalten, es sei denn, es wird eine Aktion ausgeführt, um sie zu löschen. Wenn Ihre Anwendung den Status festlegt, sollten Sie Ihre Cursor in den Anweisungscache zurückgeben und den anwendungsbezogenen Sessionstatus löschen, um bei einer späteren Wiederverwendung dieser Datenbanksession Lecks zu vermeiden. Durch die Reinigung des Sessionstatus wird sichergestellt, dass TAC Grenzen erkennen kann.

Um den Status zwischen Anforderungen mit Oracle Database 23ai automatisch zu löschen, legen Sie das Serviceattribut RESET_STATE=LEVEL1 fest. Dadurch werden Statuslecks und das Abrufen von Cursorn bei späterer Verwendung des Verbindungspools vermieden.

Wenn Sie Oracle Database 19c verwenden, können Sie mit DBMS_SESSION.RESET_PACKAGE globale PL/SQL-Variablen löschen. Mit TRUNCATE können Sie temporäre Tabellen löschen. Mit SYS_CONTEXT.CLEAR_CONTEXT können Sie den Kontext löschen und die Cursor stornieren, indem Sie sie an den Anweisungscache zurückgeben.

Wenn Ihre Anwendung zustandslos ist, wie bei REST, APEX, Microservice und den meisten Webanwendungen, sollten Sie RESET_STATE verwenden.

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

Es wird empfohlen, einen Commit der obersten Ebene zu verwenden (OCOMMIT, COMMIT() oder OCITransCommit). Wenn Ihre Anwendung einen in PL/SQL eingebetteten COMMIT-Vorgang oder AUTOCOMMIT oder COMMIT ON SUCCESS verwendet, kann das Recovery nach einem Ausfall oder Timeout möglicherweise nicht 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 nicht ordnungsgemäße Commit-Entnahme rückgängig machen, da die Daten möglicherweise gelesen wurden, oder einen Checkpoint für einen Batch und eine Neustartmethode 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, kann es möglicherweise nicht wiederholt werden, wenn der Aufruf einschließlich COMMIT nicht abgeschlossen wurde.

ORDER BY oder GROUP BY in Abfragen verwenden

Application Continuity stellt sicher, dass der Anwendung bei der Wiedergabe dieselben Daten zugeführt werden. Wenn eine Wiederherstellung derselben Daten nicht möglich ist, akzeptiert Application Continuity die Wiedergabe nicht. Wenn bei einer SELECT-Anweisung ORDER BY oder GROUP BY verwendet wird, wird die Reihenfolge beibehalten. In Autonomous Database verwendet die Abfrageoptimierung in den meisten Fällen denselben Zugriffspfad, was bei der gleichen Reihenfolge der Ergebnisse helfen kann. Application Continuity verwendet auch eine AS OF-Klausel, um dieselben Abfrageergebnisse zurückzugeben, sofern AS OF zulässig ist.

Überlegungen zu SQL*Plus

SQL*Plus ist oft das Tool der Wahl, um Dinge auszuprobieren. SQL*Plus spiegelt natürlich nicht die eigentliche Anwendung wider, die in der Produktion verwendet wird. Daher ist es immer besser, die echte Anwendungs-Test-Suite zu verwenden, um den Failover-Plan zu testen und den tatsächlichen Schutz zu messen. SQL*Plus ist keine Pool-Anwendung und weist daher keine expliziten Anforderungsgrenzen auf. Einige Anwendungen verwenden SQL*Plus beispielsweise für Berichte. Um SQL*Plus mit Failover zu verwenden, beachten Sie Folgendes:

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

  2. Bei der Verwendung von SQL*plus besteht der Schlüssel darin, Roundtrips zur Datenbank zu minimieren: https://blogs.oracle.com/opal/sqlplus-12201-adds-new-performance-features

  3. SQL*Plus wird ab Oracle Database 19c für TAC unterstützt. Für optimale Ergebnisse legen Sie große Arrays fest. Beispiel: "Set-Arraysize 1000". Vermeiden Sie die Aktivierung der Serverausgabe, da dadurch ein nicht wiederherstellbarer Sessionstatus entsteht.