Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: Techniques are provided to allow users to define a global service that is offered across multiple replicated databases. Database clients connect to and use a global service just as they do with regular services on a single database today. Upon receiving a connection request, a collection of components, referred to collectively as the Global Data Service framework (GDS framework), automatically chooses the best database server instances to which to connect a client. Once those connections have been established, the clients determine which database server instance, of those database server instances to which they are connected, to send requests to based, at least in part, on advisory messages sent to the clients by the GDS framework.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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 first server reports logical identifiers that identify transactional sets of commands to a client. The first server commits information about a set of commands to indicate that the set has committed. A second server receives, from the client, a request that identifies the set based on the logical identifier that the client had received. The second server determines whether the request identified the latest set received for execution in a corresponding session and whether any transactions in the set have not committed. If any transaction has not committed, the second server enforces uncommitted state of the identified set by blocking completion of the identified set issued in the first session. The identified set may then be executed in the second session without risk of duplication.