Abstract:
Each of a plurality of Worker processes are allowed to perform any and all of the following tasks involving logged work items: (1) reading a subset of the work items from a log; (2) sequentially ordering work items for corresponding data objects; (3) applying a sequentially ordered set of work items to a corresponding data object; and (4) transmitting a subset of work items to a Worker process running on another database server in a cluster, if necessary. These tasks can be performed concurrently, at will, and as available, by the Worker processes. An improved checkpointing technique eliminates the need for the Worker processes to get to a synchronization point and stop. Instead, a Coordinator process examines the current state of progress of the Worker processes and computes a past point in the sequence of work items at which all work items before that point have been completely processed, and records this point as the checkpoint.
Abstract:
Herein are techniques of zero data loss with asynchronously replicated redo logs. In an embodiment, a first server instance (FSI) of a plurality of server instances (PSI) of a primary database (PDB) sends, to a standby database (SDB) during an shutdown of FSI, a first recovery count (RC) and a remainder of an instance redo log (IRL). In response to recovering FSI, a second server instance of PSI increments a recovery counter to a second RC (SRC), publishes SRC to PSI, and sends SRC to SDB. After restarting FSI, FSI makes a change to contents of PDB, and stores, into IRL, a redo entry that defines the change. During failover, a database management system (DBMS) detects whether RCs associated with FSRL and SSRL are unanimous. If unanimous, DBMS fully rolls forward SDB by replaying FSRL and SSRL. Otherwise, DBMS limits replay and indicates that FSRL and SSRL might be inconsistent.
Abstract:
A method, apparatus, and system for multi-instance redo apply is provided for standby databases. A multi-instance primary database generates a plurality of redo records, which are received and applied by a physical standby running a multi-instance standby database. Each standby instance runs a set of processes that utilize non-blocking, single-task threads for high parallelism. At each standby instance for the multi-instance redo, the plurality of redo records are merged into a stream from one or more redo strands in logical time order, distributed to standby instances according to determined apply slave processes using an intelligent workload distribution function, reemerged after receiving updates from remote instances, and applied in logical time order by the apply slave processes. Redo apply progress is tracked at each instance locally and also globally, allowing a consistent query logical time to be maintained and published to service database read query requests concurrently with the redo apply.
Abstract:
A method, apparatus, and system for multi-instance redo apply is provided for standby databases. A multi-instance primary database generates a plurality of redo records, which are received and applied by a physical standby running a multi-instance standby database. Each standby instance runs a set of processes that utilize non-blocking, single-task threads for high parallelism. At each standby instance for the multi-instance redo, the plurality of redo records are merged into a stream from one or more redo strands in logical time order, distributed to standby instances according to determined apply slave processes using an intelligent workload distribution function, remerged after receiving updates from remote instances, and applied in logical time order by the apply slave processes. Redo apply progress is tracked at each instance locally and also globally, allowing a consistent query logical time to be maintained and published to service database read query requests concurrently with the redo apply.
Abstract:
Techniques for processing changes in a cluster database system are provided. A first instance in the cluster transfers a data block to a second instance in the cluster before a redo record that stores one or more changes that the first instance made to the data block is durably stored. The first instance also transfers, to the second instance, a block change timestamp that indicates when a redo record for the one or more changes was generated by the first instance. The first instance also separately sends, to the second instance, a last store timestamp that indicates when the last redo record that was durably stored was generated by the first instance. The block change timestamp and the last store timestamp are used by the second instance when creating redo records for changes (made by the second instance) that depend on the redo record generated by the first instance.
Abstract:
A method and system for replicating database data is provided. One or more standby database replicas can be used for servicing read-only queries, and the amount of storage required is scalable in the size of the primary database storage. One technique is described for combining physical database replication to multiple physical databases residing within a common storage system that performs de-duplication. Having multiple physical databases allows for many read-only queries to be processed, and the de-duplicating storage system provides scalability in the size of the primary database storage. Another technique uses one or more diskless standby database systems that share a read-only copy of physical standby database files. Notification messages provide consistency between each diskless system's in-memory cache and the state of the shared database files. Use of a transaction sequence number ensures that each database system only accesses versions of data blocks that are consistent with a transaction checkpoint.
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 computer program product, system, and computer implemented method for management of a consolidated database and implementing pluggable database recovery with redo filtering in a consolidated database according to some embodiments. Generally, the process includes ongoing activities that maintain activity logs and summarize the activity for respective activity logs (e.g., in an activity vector maintained in a consolidated database catalog). In some embodiments, event-based activities corresponding to recovery processes are triggered by an administrator or an automated process, completed and then do not occur again until another triggering event. The event-based activities can leverage the summary information to quickly determine which online activity logs are relevant to the type of recovery operation for a particular pluggable database. In this way the approach provided herein enables recovery without requiring that all log activity be analyzed to determine whether it is relevant to a particular pluggable database.
Abstract:
A database session in an active standby server on which an active standby database resides receives a DML statement. The session is suspended while the statement is redirected over a database link to a primary database on which the statement is executed. Information associated with execution of the statement is communicated to the session in the active standby server. Redo records describing changes to the contents of the primary database are applied to the active standby database and control is returned to the session. Prior to commitment of a transaction including the statement, a query directed to data to which the statement was directed is received at the active standby server from a client and executed on the active standby database absent use of a database link based on whether information associated with a database session associated with the client matches the information associated with execution of the statement.
Abstract:
Embodiments incrementally refresh a clone of a source PDB while the source PDB accepts write operations. Specifically, refreshing the PDB clone incorporates changes made to the source PDB since a refresh reference time stamp, which marks the time at which the PDB clone was created or, if the PDB clone has been previously refreshed, the time at which the PDB clone was last refreshed. A PDB clone is incrementally refreshed by incorporating, into the PDB clone data, those source data blocks that have changed since the refresh reference time stamp. Recovery is performed on the PDB clone, once the blocks are copied, to apply any changes made to the source PDB while the blocks were being copied, which recovery makes the PDB clone files consistent. This recovery is based on redo entries recorded for the source PDB during the time it took to copy the blocks to the PDB clone.