Abstract: Techniques are described for failing over from a primary database to the replicated logical database of the primary database. Techniques are also described for the client-side object references to be preserved when failing over to the logical replica database, for AS OF and other queries preserved, and for versioning of checksums, signatures and structures across logical replicas.

Abstract: Techniques are described for Transaction Guard to impose at-most-once execution by generating and using the database's native transaction identifier, DB XID. In an implementation, DB XID is unique within a (pluggable) database instance (with local undo) and uniquely identifies a transaction in the database. The Transaction Guard that is extended to use native transaction information determines the commit outcome using the native transaction identifier of the transaction instead of relying on the persistence of the Logical Transaction Identifier (LTXID) in a separate table. Using the native transaction identifier, the Transaction Guard significantly improves performance by eliminating the extra write(s) incurred during commit operations.

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 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: A system and method for communicating a side effect of a data request, from a data server and through one or more caches, inline with a response to the request. Instead of sending a separate notification of the side effect (e.g., instructions to invalidate data cached in one or more caches), the notification is included in the response. As the response traverses caches on its way to the requestor, each cache applies the side effect with the proper timing. Thus, data invalidation may be performed prior to caching data included in the request and/or forwarding the response toward the requester. A final cache configured to serve the response to the requestor may remove the side effect notification before serving the response.

Abstract: A system and method for communicating a side effect of a data request, from a data server and through one or more caches, inline with a response to the request. Instead of sending a separate notification of the side effect (e.g., instructions to invalidate data cached in one or more caches), the notification is included in the response. As the response traverses caches on its way to the requestor, each cache applies the side effect with the proper timing. Thus, data invalidation may be performed prior to caching data included in the request and/or forwarding the response toward the requester. A final cache configured to serve the response to the requestor may remove the side effect notification before serving the response.