Oracle International Corporation

Kevin S Neel

Carol L Colrain

Douglas N Surber

Stefan Heinrich Roesch

Tong Zhou

Nancy Reiko Ikeda

Jean De Lavarene

Jonathan Giloni

Ravi Shankar Thammaiah

Paul Parkinson

Saurabh Kumar Verma

Michael McMahon

Pablo Silberkasten

Arturo Ismael Quinto

Todd Jeffery Little

Wei-Ming Hu

Vivekanandhan Raja

Mark Dilman

Kant C Patel

Feroz Alam Khan

Leonid Novak

Bhaskar Mathur

Hubert Ken Sun

Michael James Stewart

Lakshminaray Chidambaran

Saravanakumar Ramasubramanian

Yunrui Li

Lakshminarayanan Luxi Chidambaran

Srinath Krishnaswamy

Stephen John Vivian

Hochak Hung

Krishna Mohan Itikarlapalli

Rohan Ankalikar

Sreekumar K Seshadri

Xiaoli Qi

Manoj Dhanapal

Pedro Arturo Cornejo Torres

Michael Cusson

Scot McKinley

Hubert Sun

Feroz A Khan

Michael J Stewart

Nancy R Ikeda

Techniques are described for preserving the inflight sessions failing over from a primary database to the replicated logical database of the primary database. In an implementation, prior to failover, when the primary database server receives a commit for a transaction, the process stores a commit indication that the transaction has been committed by performing a corresponding SQL command. The commit indication is replicated to the logical replica database by virtue of the replication of the SQL command and its execution on the logical replica database. Accordingly, the standby database server in the failover session may successfully request for the outcome of the transaction. Techniques are also described for the client-side LOB references to be preserved when failing over to the logical replica database, for AS OF queries preserved, and for versioning of checksums, signatures and structures across logical replicas.

Failover of database sessions to a logical replica database

In accordance with an embodiment, described herein is a system and method for connection concentration in a database environment. A transparency engine provided between client applications and a database can include a connection pool (e.g., UCP connection pool). The transparency engine can operate as a proxy engine for the database and as a session abstraction layer for the client applications, to enable the client applications to utilize features provided by the connection pool without code changes. The transparency engine can receive application connections from the client applications, and concentrate the application connections on a smaller number of database connections maintained in the connection pool.

System and method for connection concentration in a database environment

Techniques are disclosed herein for identifying, recording and restoring the state of a database session and various aspects thereof. A session template data structure is generated that includes session attribute values describing various aspects of the session that is established between a client system and a database management system (DBMS and enables the client system to issue to the DBMS commands for execution. Based on the session attribute values, DBMS may generate a template identifier corresponding to the session template data structure. The template identifier may be stored in an association with the session state that it partially (or in whole) represents. In an embodiment, when another state of a session is captured, if the template identifier for the state is the same, then rather than storing the attribute-value pairs for the other state, the template identifier is further associated with the other state. In an embodiment, a request boundary is detected where the session is known to be at a recoverable point. If recovery of the session is needed, the session state is restored, and replay of commands start from this point. Each command replayed is verified to produce the same session state as it produced by the original execution. If the session is determined to be a safe point, then all the commands recorded for replay prior to the safe point may be deleted. In an embodiment, the template is used to set the initial state when borrowing from a session pool. The state tracking is also used to identify that the session can be failed over safely during planned operation as the session is unlikely to drain by itself even when not used.

Session state tracking

Techniques are described to perform an automatic reset of a database session to generate an environment that resembles a brand new session without the computational cost of creating a brand new session. In an embodiment, a DBMS receives a request from a client application to execute commands within a session. The DBMS identifies that the end request boundary, the end of the logical work unit for the client application, is reached within the session. The DBMS verifies that the end request boundary is at a resettable point of a session state of the session for the session to be safely reset. If the verification is successful, the DBMS performs a reset of the session to prevent any leakage of application-related session state to the next request.

Automated reset of session state

Techniques are described for performing session termination(s) for active sessions in response to a planned operation on a database server of a DBMS. In an embodiment, the DBMS receives a request for a planned operation on a database server. The database server may have session(s) established with a client system to receive request(s) to execute database command(s) on the DBMS. In response, the DBMS transmits to the client system a notification to drain a session with the database server, and the DBMS marks the sessions at the database to drain. The DBMS is configured to terminate any drain-marked sessions by the database server when a rule is satisfied, and the failover is expected to succeed, and/or that the session is unlikely to drain or to failover at a later point in the session lifecycle. The DBMS may identify, in a rule set, a rule having rule instructions to detect a possible termination point for the session before the drain timeout period expires. Based on the execution of the rule instructions before the drain timeout expires, the DBMS determines that a termination point for the session is detected where that session will failover. In such a way, sessions are failed over early and at points where the failover is expected to succeed.

Termination of database sessions for planned failover

Techniques are disclosed herein for identifying, recording and restoring the state of a database session and various aspects thereof. A session template data structure is generated that includes session attribute values describing various aspects of the session that is established between a client system and a database management system (DBMS and enables the client system to issue to the DBMS commands for execution. Based on the session attribute values, DBMS may generate a template identifier corresponding to the session template data structure. The template identifier may be stored in an association with the session state that it partially (or in whole) represents. In an embodiment, when another state of a session is captured, if the template identifier for the state is the same, then rather than storing the attribute-value pairs for the other state, the template identifier is further associated with the other state. In an embodiment, a request boundary is detected where the session is known to be at a recoverable point. If recovery of the session is needed, the session state is restored, and replay of commands start from this point. Each command replayed is verified to produce the same session state as it produced at original execution. If the session is determined to be a safe point, then all the commands recorded for replay prior to the safe point may be deleted. In an embodiment, the template is used to set the initial state when borrowing from a session pool The state tracking is also used to know that the session can be failed over safely during planned operation as the session is unlikely to drain by itself even when not used.

Session templates

Techniques are described for closing one or more connections with a database management system (DBMS) as part of a planned operation such as maintenance and load balancing. In an embodiment, a request is received for a planned operation of a database server of a DBMS that requires releasing and migrating database sessions. Over a database connection with the database server, the DBMS or a Client-Driver on the client system that interfaces with the DBMS, may receive request(s) from the client system. Based on the request(s), a safe point, for the database connection with the database server, at which the database connection of the client system with the database server can be closed without affecting the success of execution of next one or more command that the client system intended to request the DBMS to execute on the database server, is determined. In an embodiment, in response to the request(s), the DBMS and/or Client-Driver, while the connection is valid, provide to the client system an invalid status for a connection test request. Such a response may cause the client system to use a different database connection to connect with the DBMS. After returning the response to the client system, the DBMS and/or Client-Driver causes the database session with the DBMS to close. In an embodiment, for database sessions to be released, the DBMS identifies a safe point in a database session by a detected request boundary or where the session states are determined to be recoverable or the failover is determined to be expected to succeed. At such a safe point, all database session states are known, and failing the session over to another database instance offering the requested service can be performed safely and transparent to applications.

Safe release of database sessions for planned maintenance operations

In accordance with an embodiment, described herein is a system and method for high availability and load balancing in a database environment. A transparency engine can be provided between client applications and a database, and can operate as a proxy engine for the database and as a session abstraction layer for the client applications, to enable the client applications to utilize database features provided by the connection pool without code changes to the client applications. The transparency can keep track of session states, request boundaries and cursors to efficiently reuse the database connections across the client applications. The transparency engine can use the request boundaries and indicators from the database to detect safe places to drain database connections in the event of database outages.

System and method for high availability and load balancing in a database environment

A system and method for reducing communications overhead in a distributed transaction processing environment such as an XA environment. In accordance with an embodiment communication overhead is reduced in a transaction by deferring a transaction end communication. The deferred transaction end communication is determined from a subsequent XA transaction communication thereby reducing the number of networks calls required for each transaction and enhancing system performance.

System and method for reducing communications overhead in a distributed transactions environment by modifying implementation of the transaction end function

A method, machine, and computer-readable medium is provided for managing transactional sets of commands sent from a client to a server for execution. A server receives, from a client in a second session, a request that identifies a set of commands that were sent by the client in a first session. The set of commands comprises one or more transactions. The server determines that at least one transaction of the one or more transactions in the set of commands has not committed. Based at least in part on determining that the at least one transaction of the one or more transactions has not committed, the server blocks, from the second session, completion of the at least one transaction in the first session to prevent committing of the at least one transaction in the first session.

Idempotence for database transactions

A system and method for reducing communications overhead in a distributed transaction processing environment such as an XA environment. In accordance with an embodiment communication overhead is reduced in a transaction start method by deferring a transaction start communication. The deferred transaction start communication is determined from a subsequent transaction processing communication thereby reducing the number of networks calls required for each transaction and enhancing system performance.

System and method for reducing communications overhead in a distributed transactions environment by modifying implementation of the transaction start function

A process, apparatus, and computer-readable medium are provided for rebuilding a database session when a previous database session becomes unavailable and the commands previously sent for execution on the previous database session satisfy certain criteria. The process includes determining whether or not a set of commands sent by a client for execution on the previous database session is acceptable to replay based at least in part on whether or not the set of commands satisfies one or more criteria. The process further includes determining that the previous database session is unavailable due to a planned or unplanned recoverable error. In response to determining that the previous database session is unavailable, if the set of commands is acceptable for replay, the set of commands is sent for execution on a new database session to rebuild the state, which was exposed to the client from the previous database session, on the new database session. The process masks the outage from the application.

Recovering stateful read-only database sessions

Methods, devices, and storage media are provided for preserving the context of a server-client session. A server generates an initial context and a context for each user command executed in a first session and sends context to a client with the return for each command. The context describes software, session state, returned data, and/or hardware characteristics of a server-side environment for the first session. The client receives and stores the context with each user command. Upon determining that the database session should be rebuilt in the second session, the client sends initial context. A server for the second session receives the initial context and determines whether commands should be replayed in the second session. If commands are replayed, the server validates that server environment and client-visible results for each command in the second session match that from execution in the first session using the context for that command.

Preserving server-client session context

Transactional and non-transactional data for maintaining session state is described. In a session, a server instance receives, from a client, a request to execute transactional commands and non-transactional commands. The server instance sends at least one first directive executable at the client to store, in a first set of information, one or more first items representing one or more particular transactional commands that are open but not yet committed. The first set of information is maintained separately from a second set of information including one or more second items representing one or more particular non-transactional commands that have been processed. Based on committing one or more particular transactional commands, the server instance sends at least one second directive executable at the client to purge, from the first set of information, the one or more first items without purging, from the second set of information, the one or more second items.

Transactional and non-transactional data for maintaining session state

Growing community of inventors

San Mateo, CA, United States of America

Kevin S Neel