2. Maximum Application Availability with Oracle Database 12c
Kuassi Mensah Director Product Management

3. The following is intended to outline our general product direction
The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. 3

4. My Next Session
Oracle In-Database MapReduce: When Hadoop Meets Exadata
7/25/13, 12:00– 13:00, Room 431

5. Program Agenda Problems to Solve New Concepts Transaction Guard
Application Continuity
Application Design Considerations

6. Problems to Solve Upon Database Outage Four Problems Confront
Applications
Hang
Errors
Outcome of In-Flight Work
Resubmission of In-Flight Work

7. Current Situation Hang -> Fast Application Notification (FAN)
Errors Handling? Not formalized
In-Flight Work? Lost!
Resubmission of In-Flight Work? N/A!

8. Program Agenda Problems to Solve New Concepts Transaction Guard
Application Continuity
Application Design Considerations

9. Recoverable Error Formalized
OracleException.IsRecoverable property
Applications No longer need to maintain own list of error codes (e.g., ora-1033, ora-1034, ora-xxx)
JDBC throws SQLRecoverableException

10. Database Request Unit of Work
Request Begins
PoolDataSource pds = GetPoolDataSource();
Connection conn = getConnection(pds);
PreparedStatement pstmt = … …
SQL, PL/SQL, local calls, RPC
conn.commit();
conn.close();
Request Body Usually ends with COMMIT
Request Ends

11. Program Agenda Problems to Solve New Concepts Transaction Guard
Application Continuity
Application Design Considerations

12. Transaction Guard
Tool that supports known outcome for every transaction
Without Transaction Guard, retry can cause logical corruption
Used by Application Continuity
Can be used independently of Application Continuity
Work
Request
4. Reliable Commit Outcome
2. DB Calls
4. Enforce Outcome
3. Errors
12c ORACLE Database

13. Transaction Guard – Typical Usage
Upon database instance crash
FAN aborts dead session
Application gets an error
Pool removes orphan connection from pool
If “recoverable error” then
Get last LTXID from dead session
Obtain new database session
Get transaction status

14. Transaction Guard In Action
Client/Mid-tier
Database
Time
getConnection()
Txn.Commit();
get Last LTXID
<new session>
Commit outcome?
COMMIT/ROLLBACK
start transaction
assign LTXID
COMMIT?
Return & Preserve COMMIT OUTCOME
SQL, PL/SQL, RPC
Results
Recoverable Error
COMMIT
TG in
Action
Get Logical TX ID

15. Transaction Guard Configuration
On Service
COMMIT_OUTCOME
Values – TRUE and FALSE
Default – FALSE
Applies to new sessions
RETENTION_TIMEOUT
Units – seconds
Default – 24 hours (86400)
Maximum value – 30 days ( )
Adding and Modifying a Service for a Server Pool
srvctl add service -database orcl -service GOLD -poolname ora.Srvpool -commit_outcome TRUE -retention notification TRUE srvctl modify service -database orcl -service GOLD -commit_outcome TRUE -retention notification TRUE
Adding an Administration-Manager Service
srvctl add service -database codedb -service GOLD -prefer serv1 -available serv2 -commit_outcome TRUE -retention notification TRUE
If you are using a single-instance database, use the DBMS_SERVICE.MODIFY_SERVICE PL/SQL procedure to modify services, and you should always use FAN. Example 25-3 modifies a service (but substitute the actual service name for <service-name>).
Modifying a Service (PL/SQL)
DECLARE params dbms_service.svc_parameter_array; BEGIN params('COMMIT_OUTCOME'):='true'; params('RETENTION_TIMEOUT'):=604800; params('AQ_HA_NOTIFICATIONS'):='true'; dbms_service.modify_service('<service-name>',params); END; / 15

16. Transaction Guard in Oracle database 12c
JDBC-thin, ODP.NET, OCI, OCCI
Commit Models
Local TXN
Auto-commit, Commit on Success
Commit embedded in PL/SQL
DDL, DCL, Parallel DDL
Remote, Distributed
Exclusions XA
R/W DBLinks from Active Data Guard or Read Only

17. Program Agenda Problems to Solve New Concepts Transaction Guard
Application Continuity
Design Considerations

18. Application Continuity
Mask Database Outage When Successful
Replays in-flight work on recoverable errors
Masks many hardware, software, network, storage errors and outages when successful
Improves end user experience
Work
Request
5. Response
2. DB Calls
4. Replay
3. Errors
12c ORACLE Database

19. Phases in Application Continuity
1-Capture
2-Reconnect
3-Replay
Demarcates database request
Holds original calls with binds & validation
Manages queues
Checks request has replay enabled
Handles timeouts
Creates a new connection
Validates target database
Uses Transaction Guard to enforce last commit
Replays held calls
Continues replay, if user visible results match, based on validations
Continues request

20. Application Continuity In Action
Oracle JDBC Driver
RAC Database
Instance1
Instance2
Instance3
Call 1
Call 2
Proxy 1
Application
Proxy 2
Connection
Replay Context

21. DEMO

22. Solution Coverage Application Continuity for Java
Client
JDBC-Thin driver
UCP, WebLogic Server
Database
SQL, PL/SQL, RPC
Select, ALTER SESSION, DML, DDL, COMMIT/ROLLBACK/SAVEPOINT
Transaction models: Local, Parallel, Remote, Distributed
Mutable function support
Hardware acceleration on current Intel & SPARC chips

23. Exclusions Global Request Target Database
Do not use default database service
Excludes XA
For Java, deprecated concrete classes
Restricted calls
Alter System
Alter Database
Not supported for Active Data Guard with read/write database links
Does not support:
Logical Standby
Golden Gate
Here are some restrictions and other considerations that apply to Application Continuity. There are basically three levels of restrictions for Application Continuity. They are:
Global - This restriction prevents Application Continuity from being enabled or used on any request. Do not use the database service , that is, the default service corresponding to the DB_NAME or DB_UNIQUE_NAME. The use of the database service is not recommended for high availability, because this service cannot be enabled or disabled. Replay is not supported for applications developed using Oracle XA. For applications using JDBC, there is no support for oracle.sql deprecated concrete classes like BLOB, CLOB, BFILE, OPAQUE, ARRAY, STRUCT or ORADATA.
Request - This restriction disables Application Continuity for part of a request. For JDBC stream arguments, replay is on a "best effort" basis. For example, if the application is using physical addresses, the address is no longer valid with the outage and cannot be repositioned. Replay is disabled if the transaction executes the ALTER SYSTEM or ALTER DATABASE statement. Replay is not supported if you are using Active Data Guard with read/write database links to another database.
Target - Application Continuity is not supported for logically different databases - Oracle Logical Standby and Oracle Golden Gate.
ClassCastException during runtime with concrete classes:
CLOB clob = (CLOB)rs.getClob(1); -- ClassCastException!

24. Restrictions When Does Replay Not Occur?
Normal Runtime
Reconnect
Replay
Any call in same request
after
successful commit in dynamic mode (default)
a restricted call
disableReplay API
Error is not recoverable
Reconnection failure
Replay initiation timeout
Max connection retries
Max retries per incident
Target database not valid for replay
Last call committed in dynamic mode
Validation detects different results
If disabled, the disable is in effect until the next request. The following events will disable replay for the request:
Normal Runtime: Capture happens on all original calls, until a successful COMMIT (in dynamic mode), or unless disabled for the request.
Reconnect: Replay does not occur if the error is not recoverable, if timeouts have been exceeded, if the target database is not the same or an ancestor, or if the request has committed
Replay: is aborted and the original error is returned, if the validation for the replayed call does not pass. The call must return the same user visible results that the application has seen and potentially made a decision on

25. Program Agenda Problems to Solve New Concepts Transaction Guard
Application Continuity
Application Design Considerations

26. Application Assessment
Decide
What to do
Request Boundaries
Mark Request Boundaries, if you are not using Oracle Pools
JDBC Concrete Classes
Replace deprecated concrete classes with Java interfaces
Side Effects
Use disable API if a database request has an external call that should not be replayed
Callbacks
Ensure a callback is registered if state changes outside any request (WLS/UCP labeling included by default)
Mutable Functions
Grant keeping mutable values if these are compatible with your application
Before using Application Continuity in your application, your application owner needs to make the following checks:
Mark Request Boundaries if the application is not using Oracle pools or is not releasing connections to Oracle Pools.
Request Boundaries tag the beginning and end of each request.
Determine whether the application borrows and returns connections from the WebLogic Server Pool or Universal Connection Pool for each request, or whether beginRequest and endRequest APIs should be added to the application's own connection pool to identify request boundaries.
If you are using Oracle Pools, but are not releasing connections, there is often a property to set to release. Releasing connections scales much better.
Determine whether the application uses Oracle JDBC concrete classes. For using Application Continuity, the deprecated concrete classes must be replaced.
For information about the deprecation of concrete classes, including actions to take if an application uses them, see My Oracle Support Note (
3) Assess the impact of restrictions and side-effects on your application. Use the disable replay API for any request that should not be replayed.
For example, if a request makes external calls using one of the external PL/SQL messaging actions, or uses autonomous transactions, check this request. Decide if it should be replayed or not.
Assess if you application sets state outside the database request.
If state is set when a user starts a request, outside that request, replay needs to know about it in order to re-execute the calls.
When using Oracle WebLogic Server or the Universal Connection Pool, connection labeling is recommended. The labeling is used for both runtime and replay.
If using an application’s own callback, register this at the WebLogic Admin Console, or at UCP, or JDBC replay driver levels
Decide on whether the application can keep mutables at replay. When a request is replayed, this function obtains a new value every time it is called. Keep mutable values when they are compatible with the application.
Grant keeping original values for seq.NEXTVAL,  SYSDATE, SYSTIMESTAMP, and SYS_GUID and sequences during failover.
Special
Almost every application should use the service setting session_state_consistency value DYNAMIC. If you are not sure do not touch it.
If session_state_consistency is dynamic, the application changes the environment or settings during the request. Replay is disabled after the first commit until the end of request. Dynamic is the default mode and most applications should use this mode.

27. Side Effects
When Replay is enabled, some calls may be repeated. Apps may need to use disableReplay() API to prevent this:
Autonomous transactions
UTL_HTTP , UTL_URL
UTL_FILE, UTL_FILE_TRANSFER - files operations
UTL_SMPT, UTL_TCP, UTL_MAIL - sending messages
DBMS_PIPE, RPCs - to external sources
DBMS_ALERT - or other notifications

28. Configuration Configure JDBC Replay Driver
Set replay data source in property file datasource=oracle.jdbc.replay.OracleDataSourceImpl
Enable Application Continuity on Service
Set FAILOVER_TYPE = TRANSACTION
Review settings for:
REPLAY_INITIATION_TIMEOUT = 1800
FAILOVER_DELAY = 3 seconds
FAILOVER_RETRIES = 60 retries
SESSION_STATE_CONSISTENCY = DYNAMIC
COMMIT_OUTCOME = TRUE

29. Mutables and Grant Privileges
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];
If owned, ALTER SEQUENCE.. [sequence object] [KEEP|NOKEEP];
CREATE SEQUENCE.. [sequence object] [KEEP|NOKEEP];
1. The database user running the application may have the KEEP DATE TIME and KEEP SYSGUID privileges granted, and the KEEP SEQUENCE object privilege on each sequence whose value is to be kept. 
For example:
grant KEEP DATE TIME to user2;
grant KEEP SYSGUID to user2;
grant KEEP SEQUENCE on sales.seq1 to user2;
Note that GRANT ALL ON <object> does not include (that is, does not grant the access provided by) the KEEP DATE TIME and KEEP SYSGUID privileges and the KEEP SEQUENCE object privilege.
Do not grant DBA privileges to database users running applications for which you want replay to be enabled. Grant only privileges only to application users and only the privileges that that are necessary for such users.
2. Most applications need sequence values to be kept at replay.  Sequences in the application may use the KEEP attribute, which keeps the original values of sequence.NEXTVAL for the sequence owner. The following example sets the KEEP attribute for a sequence (in this case, one owned by the user
executing the statement; for others, use GRANT KEEP SEQUENCE) :
SQL> CREATE SEQUENCE my_seq KEEP;
Or, if the sequence already exists but without KEEP:
SQL> ALTER SEQUENCE my_seq KEEP;
Note that specifying ALTER SEQUENCE ... KEEP/NOKEEP applies to the owner of the sequence. It does not affect other users (not the owner) that have the KEEP SEQUENCE object privileges. If you want KEEP for all users, be sure to GRANT the KEEP SEQUENCE object privilege to these users (or to revoke it from each if you do not want it).
SQL> GRANT KEEP SEQUENCE on sales.seq1 to user2;

30. Maximum Application Availability with Oracle database 12c
Hang
Errors & Connection Handling
Outcome of In-Flight Work
Resubmission of In-Flight Work