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: 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, system and computer program product for low loss database backup and recovery. The method commences by transmitting, by a first server to a third server, a copy of a database snapshot backup, the transmitting commencing at a first time. Then capturing, by the first server, a stream of database redo data, the capturing commencing before or upon transmitting the database snapshot backup, and continuing until a third time. The stream of database redo data is received by an intermediate server after which the intermediate server transmits the stream of database redo data to the third server. Now, the third server has the database snapshot backups and the database redo data. The third server can send to a fourth server all or portion of the database redo data to be applied to the copy of the database snapshot backup restored there to create a restored database.

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: Techniques are described that determine occurrences of lost write by comparing version identifiers of corresponding replica data blocks and checkpoints of data files that include the data blocks. A method determines lost writes that may have occurred among a first set of data blocks and a second set of data blocks. Each data block in the first set of data blocks corresponds to a respective data block in the second set that is a version of data blocks in the first set. The data blocks in the first set and the second set are associated with version identifiers. The second set of data blocks is associated with a second checkpoint for which any version of a data block in the second set associated a version identifier below the second checkpoint has been acknowledged to a database server as having been written to persistent storage.

Abstract: A method, apparatus, and system for a time-based checkpoint target is provided for standby databases. Change records received from a primary database are applied for a standby database, creating dirty buffer queues. As the change records are applied, a mapping is maintained, which maps timestamps to logical times of change records that were most recently applied at the timestamp for the standby database. On a periodic dirty buffer queue processing interval, the mapping is used to determine a target logical time that is mapped to a target timestamp that is prior to a present timestamp by at least a checkpoint delay. The dirty buffer queues are then processed up to the target logical time, creating an incremental checkpoint. On a periodic header update interval, file headers reflecting a consistent logical time for the checkpoint are also updated. The intervals and the checkpoint delay are adjustable by user or application.

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: A method, system and computer program product for low loss database backup and recovery. The method commences by transmitting, by a first server to a third server, a copy of a database snapshot backup, the transmitting commencing at a first time. Then capturing, by the first server, a stream of database redo data, the capturing commencing before or upon transmitting the database snapshot backup, and continuing until a third time. The stream of database redo data is received by an intermediate server after which the intermediate server transmits the stream of database redo data to the third server. Now, the third server has the database snapshot backups and the database redo data. The third server can send to a fourth server all or portion of the database redo data to be applied to the copy of the database snapshot backup restored there to create a restored database.

Abstract: A method and apparatus for detecting split brain in a distributed system is provided. After determining that a rogue instance is no longer an active member of the cluster, a recovery instance detects activity associated with a redo log that is updated by the rogue instance to store log records that describe changes made by the rogue instance to data associated with the cluster.

Abstract: Techniques used in an automatic failover configuration having a primary database system, a standby database system, and an observer. In the automatic failover configuration, the primary database system remains available even in the absence of both the standby and the observer as long as the standby and the observer become absent sequentially. The failover configuration may use asynchronous transfer modes to transfer redo to the standby and permits automatic failover only when the observer is present and the failover will not result in data loss due to the asynchronous transfer mode beyond a specified maximum. The database systems and the observer have copies of failover configuration state and the techniques include techniques for propagating the most recent version of the state among the databases and the observer and techniques for using carefully-ordered writes to ensure that state changes are propagated in a fashion which prevents divergence.

Abstract: A method and apparatus for detecting split brain in a distributed system is provided. After determining that a rogue instance is no longer an active member of the cluster, a recovery instance detects activity associated with a redo log that is updated by the rogue instance to store log records that describe changes made by the rogue instance to data associated with the cluster.

Abstract: Techniques used in an automatic failover configuration having a primary database system, a standby database system, and an observer. In the automatic failover configuration, the primary database system remains available even in the absence of both the standby and the observer as long as the standby and the observer become absent sequentially. The failover configuration may use asynchronous transfer modes to transfer redo to the standby and permits automatic failover only when the observer is present and the failover will not result in data loss due to the asynchronous transfer mode beyond a specified maximum. The database systems and the observer have copies of failover configuration state and the techniques include techniques for propagating the most recent version of the state among the databases and the observer and techniques for using carefully-ordered writes to ensure that state changes are propagated in a fashion which prevents divergence.

Abstract: Techniques used in an automatic failover configuration having a primary database system, a standby database system, and an observer. In the automatic failover configuration, the primary database system remains available even in the absence of both the standby and the observer as long as the standby and the observer become absent sequentially. The failover configuration may use asynchronous transfer modes to transfer redo to the standby and permits automatic failover only when the observer is present and the failover will not result in data loss due to the asynchronous transfer mode beyond a specified maximum. The database systems and the observer have copies of failover configuration state and the techniques include techniques for propagating the most recent version of the state among the databases and the observer and techniques for using carefully-ordered writes to ensure that state changes are propagated in a fashion which prevents divergence.

Abstract: Techniques used in an automatic failover configuration having a primary database system, a standby database system, and an observer for preventing divergence among the primary and standby database systems while increasing the availability of the primary database system. In the automatic failover configuration, the primary database system remains available even in the absence of both the standby and the observer as long as the standby and the observer become absent sequentially. The failover configuration further permits automatic failover only when the observer is present and the standby and the primary are synchronized and inhibits state changes during failover. The database systems and the observer have copies of failover configuration state and the techniques include techniques for propagating the most recent version of the state among the databases and the observer and techniques for using carefully-ordered writes to ensure that state changes are propagated in a fashion which prevents divergence.

Abstract: Techniques used in an automatic failover configuration having a primary database system, a standby database system, and an observer for preventing divergence among the primary and standby database systems while increasing the availability of the primary database system. In the automatic failover configuration, the primary database system remains available even in the absence of both the standby and the observer as long as the standby and the observer become absent sequentially. The failover configuration further permits automatic failover only when the observer is present and the standby and the primary are synchronized and inhibits state changes during failover. The database systems and the observer have copies of failover configuration state and the techniques include techniques for propagating the most recent version of the state among the databases and the observer and techniques for using carefully-ordered writes to ensure that state changes are propagated in a fashion which prevents divergence.

Abstract: Techniques for reducing commit latency in a database system having a primary database system and a standby database system that is receiving a stream of redo data items from the primary. The standby sends an acknowledgment for a received item of redo data before the standby writes the redo data item to a redo log for the stream. When a no more redo event occurs in the standby, the standby sets a “no data lost flag” in the redo log if the stream of redo data items has no gaps and all of the redo data items received in the standby have been written to the redo log. The database system may operate in a first mode in which an acknowledgment is sent as just described and a second mode in which an acknowledgment is sent after the redo data item has been written to the redo log.

Abstract: Techniques for reducing commit latency in a database system having a primary database system and a standby database system that is receiving a stream of redo data items from the primary. The standby sends an acknowledgment for a received item of redo data before the standby writes the redo data item to a redo log for the stream. When a no more redo event occurs in the standby, the standby sets a “no data lost flag” in the redo log if the stream of redo data items has no gaps and all of the redo data items received in the standby have been written to the redo log. The database system may operate in a first mode in which an acknowledgment is sent as just described and a second mode in which an acknowledgment is sent after the redo data item has been written to the redo log.