Hochverfügbarkeit für den Anwendungsentwickler Oracle Datenbank 12c

Transkript

1 Oracle Database Days 12c Alle Details zum neuen Datenbank Release aus erster Hand <Insert Picture Here> Dezember 2013 Januar 2014 Februar 2014 Information Lifecycle Management Database Application Development Database Administration Alle Termine und weitere Informationen: tinyurl.com/odd12c Hochverfügbarkeit für den Anwendungsentwickler Oracle Datenbank 12c Sebastian Solbach, ORACLE Deutschland B.V. Co. KG

2 Agenda HA in der Anwendungsentwicklung? Basis Setup (Datenbank) Transaction Guard (OCI/ODP.NET/JDBC) Application Continuity (nur JDBC) Best Practices Diverses

3 Das Problem: In-Flight Work Pre-12c Situation Netzwerk / Datenbank Ausfall führt zu einem ungewissen Transaktionsstatus Neustart der Mid-Tier Frustration der Benutzer Abgebrochene Arbeit Doppelte Buchungen Entwicklungsaufwand

4 Maximum Application Availability (MAA2) Mehr als 1 Problem Datenbank Ausfall konfrontiert Entwickler mit 5 Problemen: 1. Ausfall festestellen 2. Wiederaufnahme im vorgegebenen Zeitfenster 3. Exception Handling 4. Transaktionsstatus herausfinden 5. Weiterführung der aktuellen Transaktion

5 Pre-12c Situation HA Mechanismen und Einschränkungen Ausfall Fast Application Notification (FAN) / Fast Connection Failover Recovery Zeitfenster? Abhängig von Ausfallzenario und Technologie Exception Handling? Fehler & Reaktionen nicht vollständig formalisiert Aktuelle Transaktion? Ungewiss Weiterführen aktueller Transaktion? Nicht verfügbar!

6 Ausfall feststellen: Fast Application Notification Applikationen verlieren Zeit Warten auf TCP/IP Timeouts Fehler bei geplanten Ausfällen Verbindungsabbrüche bei Nichtverfügbarkeit des Services Keine Neu-Verbindungsversuche bei Serviceverfügbarkeit Verbindungen auf überlastete Knoten FAN & FCF Down Service/Knoten down <50ms für Failover Planned Down Entleerung des Connectionspools ohne Verbindungsabbrüche Up Verteilung der Arbeitslast bei Serviceverfügbarkeit RLB % - Informationen zur optimalen Verteilung Affinity Optimierung Workload lokal zu halten Alle 12c Treiber verwenden FAN über ONS

7 Datenbanklösungen für MAA Real Application Cluster Automatische Fehlererkennung in <30 Sekunden Schnelles konfigurierbares Instanz Recovery Geplante Übernahme ohne Downtime RAC One Node Automatische Fehlererkennung in <30 Sekunden Neustart der Datenbank & Instanz Recovery Geplante Übernahme ohne Downtime Active Data Guard / Data Guard (Automatische) Fehlererkennung in <2 Minuten Neustart der Datenbank in Desaster Recovery Entfernung Geplante Übernahme mit Downtime

8 Exception Handling? Recoverable Error Formalisiert: OracleException.IsRecoverable property JDBC throws SQLRecoverableException Applikationen brauchen keine eigene Liste mit Fehlercodes (z.b., ORA-1033, ORA-1034, ORA-xxx)

9 Lösungen für Transaktionsstatus & Fortführung Neu in Oracle Database 12 c Transaction Guard Application Continuity Verlässliches Protokoll und API den Status der letzten Transaktionen zu überprüfen Automatische Wiederholung (Replay) der Benutzertransaktion nach einem Ausfall oder während einer Wartung

11 Verwenden eines eigenen Services!!!... und das gilt nicht nur für RAC, Data Guard und Multitenant (PDB) Oracle Datenbank 12c & Oracle Client 12c srvctl modify service -db ORCL -service APPCON -failovertype TRANSACTION -replay_init_time 300 -failoverretry 30 -failoverdelay 3 -notification TRUE -commit_outcome TRUE Services in der Datenbank: SHOW_TIPP?P_ID=741

12 Service Konfiguration Transaction Guard COMMIT_OUTCOME Werte : TRUE oder FALSE, Default: FALSE Greift sofort bei neuen Sessions RETENTION_TIMEOUT Einheit: Sekunden, Default: 24 Stunden (86400) Maximalwert: 30 Tage ( ) AQ_HA_NOTIFICATIONS Werte: TRUE oder FALSE, Default: FALSE (noch) Auf TRUE setzen für FAN!!

13 Service Konfiguration Application Continuity Zusätzlich für Application Continuity FAILOVER_TYPE Werte : NONE, SESSION, SELECT, TRANSACTION, Default: NONE Für AC auf TRANSACTION setzen REPLAY_INITIATION_TIMEOUT = 300 Zeit in Sekunden nach der ein Replay abgebrochen wird FAILOVER_RETRIES = 60 Anzahl der Verbindungsversuche für einen Replay FAILOVER_DELAY = 3 Verzögerung in Sekunden zwischen den Verbindungsversuchen

14 Rechte & Datenbank Parameter Applikationsbenutzer braucht Rechte auf das DBMS_APP_CONT Package GRANT EXECUTE ON DBMS_APP_CONT TO <app-name>; REMOTE_LISTENERS muss alle Listener kennen, über die die Clients sich initial verbinden (im Normalfall nur SCAN) alter system set REMOTE_LISTENERS='SCAN.domain.com:1521'

16 Transaction Guard Verlässliche Information über eine Transaktion nach einem Ausfall Mit Hilfe von Transaction Guard kann die Applikation auf alle Fehler richtig reagieren Verhindert Logische Korruptionen druch Wiederholung Application Continuity verwendet Transaction Guard Transaction Guard ist verfügbar mit JDBCthin, OCI/OCCI, ODP.NET

17 Herausforderung: Commit Ergebnis Unterbrechung der Kommunikation während eines COMMIT Java/JDBC Applikation bekommt eine Fehlermeldung : Failed Keine Information über das Ergebnis dieser in-flight Transaktion Typisches Szenario t0: Applikation prüft Status der Transaktion und erhält Not COMMITTED. Auf Basis dieser Information wird das weitere Vorgehen bestimmt t1: Transaktion wird doch noch abgeschlossen Es gibt (bis 12c) keinen verlässliche Möglichkeit den Status einer in-flight Transaktion zu prüfen

18 Transaction Guard Verlässliche Information des COMMIT Ergebnisses 1. RDBMS assoziiert zu jeder in-flight Transaktion eine logische TransaktionsID (LTXID) LTXID wechselt NUR bei einem erfolgreichen COMMIT oder ROLLBACK 2. LTXID wird z.b. an JDBC kommuniziert 3. Falls die Verbindung abbricht LogicalTransactionId ltxid = oldconn.getlogicaltransactionid(); OracleConnection newconn = getconnection(); CallableStatement cstmt = newconn.preparecall(get_ltxid_outcome); RDBMS: Falls GET_LTXID_OUTCOME weder Committed noch Rollback zurückgibt, wird die Transaktion daran gehindert zu COMMITTEN

19 Transaction Guard Schematische Darstellung Applikation/Treiber - RDBMS Interaktion Applikation/Treiber Datenbank Zeit getconnection() SQL, PL/SQL, RPC start transaction assign LTXID Results Txn.Commit(); get Last LTXID <new session> Commit outcome? COMMIT/ROLLBACK COMMIT Recoverable Error Get LTXID outcome COMMIT? Return & Preserve COMMIT OUTCOME TG in Aktion

20 Transaction Guard Der Komplette Java Code... boolean committed = false; boolean call_completed = false; try { CallableStatement cstmt = conn.preparecall(get_ltxid_outcome); cstmt.setbytes(1, ltxid[i].getbytes()); cstmt.registeroutparameter(2, OracleTypes.BIT); cstmt.registeroutparameter(3, OracleTypes.BIT); cstmt.execute(); committed = cstmt.getboolean(2); call_completed = cstmt.getboolean(3); System.out.println("LTXID committed? " + committed); System.out.println("User call completed? " + call_completed); } catch (SQLException sqlexc) { System.out.println("Calling GET_LTXID_OUTCOME failed"); sqlexc.printstacktrace(); }

21 Transaction Guard Treiber Unterstützung mit Supportete Commit Modelle Local TXN Auto-commit, Commit on Success Commit embedded in PL/SQL DDL, DCL, Parallel DDL Remote, Distributed Ausgeschlossen XA in 12.1 R/W DBLinks von Active Data Guard / Read Only

23 Application Continuity Maskiert ungeplante und geplante Ausfälle In-flight Prozess läuft weiter Wiederholt in-flight Prozess nach einem Recoverable Error Verbirgt viele Hardware, Software, Netzwerk, Storage Fehler und Ausfälle Unterstützt JDBC-Thin, UCP, WebLogic Server und 3 rd Party Java Applikationen Oracle RAC, RAC One, & Active Data Guard

24 Die Einheit: Datenbank Request Legt die Grenzen für die Wiederholung fest Begin Request PoolDataSource pds = GetPoolDataSource(); Connection conn = getconnection(pds); PreparedStatement pstmt = SQL, PL/SQL, local calls, RPC conn.commit(); conn.close(); Request Body schließt gewöhnlich mit COMMIT ab End Request

25 Phasen bei Application Continuity 1-Laufzeit Operationen 2-Reconnect 3-Replay Überwachung der einzelnen Datenbank Requests Ermittlung was / was nicht wiederholt werden kann Speichert den orginären Aufruf inkl. Bind Variablen und Validierung Prüft ob für den Request Replay aktiviert wurde Verwaltung von Timeouts Eröffnet neue Verbindung Validiert die Zieldatenbank/Zielinstanz Verwendet Transaction Guard zur Ermittlung des COMMIT Ergebnisses Wiederholung der gespeicherten Aufrufe Verifizierung der Ergebnisse mit den Vorhergehenden. Führt den Request weiter, falls die Wiederholung erfolgreich ist

26 Konfiguration Application Continuity JDBC / WLS JDBC URL oder Property Datei # Verwendung der neuen 12.1 Replay DataSource datasource=oracle.jdbc.replay.oracledatasourceimpl WebLogic Console oder UCP/Weblogic Property Datei # Auswählen der neuen 12.1 replay datasource=oracle.jdbc.replay.oracledatasourceimpl Setzen von ONS nicht mehr notwendig, da in 12c die ONS Server automatisch konfiguriert werden (via. Listener)

27 Verwenden des Services in JDBC Oracle Client 12c = (TRANSPORT_CONNECT_TIMEOUT=3)(CONNECT_TIMEOUT=5) (RETRY_COUNT=3)(FAILOVER=ON)(ADDRESS= (PROTOCOL=tcp)(HOST=SCAN.domain.com)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=APPCON))

28 Ausnahmen: Replay deaktiviert Global Request Target Database Default Datenbank Service oder Default PDB Service XA in 12.1 Verwendung einiger JDBC-Klassen aus dem Package oracle.sql Eigentlich logisch (restricted calls): Alter System Alter Database Active Data Guard mit read/write Datenbanklinks Nicht verfügbar bei Logical Standby Golden Gate

29 Restriktionen: Wann wird nicht wiederholt? Normal Runtime Reconnect Replay Aufrufe im selben Request nach Einem erfolgreichen Commit im dynamischen Modus Auftreten eines restricted call disablereplay API Fehler ist nicht recoverable Fehler beim erneuten Verbindungsaufbau Zieldatenbank nicht für Replay geeignet Letzter Aufruf erfolgreich committed im dynamischen Modus Validierung erkennt Unterschied im Ergebnis

31 Generell geeignet oder manuelle Anpassung? Nein WLS / UCP Ja Return Conn. to Pool Nein Property to Return Nein Manuell: begin & endrequest setzen Ja Set Property Ja Application Continuity möglich

32 Was muss noch beachtet werden Wenn Dann Kein Oracle Connection Pool Markieren von Request Grenzen oracle.sql JDBC-Klassen Unerwünschte Seiteneffekte Mutable Funktionen (Sysdate) Callbacks Ersetzen durch Standard JDBC Interface (java.sql) Verwenden der disable API, falls ein Aufruf nicht wiederholt werden sollte Ermöglichen (Grants) veränderliche Werte gleich zu belassen (z.b. sequence.nextval) Registrierung von Callbacks zur Änderung des Status einer Applikation ausserhalb eines Requests Bei WebLogic & UCP Labelling verwenden

33 Deaktiveren von Replay? Verwenden der disablereplay() API für Aufrufe, die nicht wiederholt werden sollen/dürfen, insbesondere für Externe Aktionen: Autonome Transaktionen UTL_HTTP, UTL_URL UTL_FILE, UTL_FILE_TRANSFER UTL_SMPT, UTL_TCP UTL_MAIL DBMS_PIPE (nicht empfohlen bei RAC) DBMS_ALERT (Ebenfalls Vorsicht bei RAC: Community Tipp) GERMAN_COMMUNITIES.SHOW_TIPP?P_ID=1621

34 Optinale Datenbank Konfiguration Mutables Rechte vergeben Damit z.b. Sysdate bei einem Replay denselben Wert zurückgibt: GRANT [KEEP DATE TIME KEEP SYSGUID].. [to USER] REVOKE [KEEP DATE TIME KEEP SYSGUID][from USER] GRANT KEEP SEQUENCE.. [to USER] on [sequence object]; REVOKE KEEP SEQUENCE [from USER] on [sequence object]; ALTER SEQUENCE.. [sequence object] [KEEP NOKEEP]; CREATE SEQUENCE.. [sequence object] [KEEP NOKEEP];

36 Kill Session Was passiert, wenn der DBA eine Session killt? Natürlich greift AC nicht unbedingt immer gewollt! SQL> alter system kill session 'sid, noreplay; SQL> alter system disconnect session 'sid, noreplay; SQL> execute DBMS_SERVICE.DISCONNECT_SESSION( [service name], DBMS_SERVICE.NOREPLAY) ;

37 Lizenzen für produktiven Einsatz Transaction Guard: Enterprise Edition Application Continuity: RAC oder Active Data Guard Option Oracle Database Licensing Information 12c Release 1 (12.1) 14/editions.htm#DBLIC116

38 Links & weitere Informationen DBA Community OTN Whitepapers Dokumentation

39