Abstract: Techniques related to instance recovery using Bloom filters are disclosed. A multi-node node database management system (DBMS) includes a first database server instance and a second database server instance. A recovery set includes a set of data blocks that have been modified by a first database server instance and not persisted. A Bloom filter is generated to indicate whether data blocks are excluded from the recovery set. The Bloom filter is sent to the second database server instance, which determines whether the Bloom filter indicates that a particular data block is excluded from the recovery set. Based on determining that the Bloom filter indicates that the particular data block is excluded from the recovery set, access to the particular data block is granted.

Abstract: Techniques are described herein for quick identification of a set of units of data for which recovery operations are to be performed to redo or undo changes made by the failed node. When a lock is requested by an instance, lock information for the lock request is replicated by another instance. If the instance fails, the other instance may use the replicated lock information to determine a set of data blocks for recovery operations. The set of data blocks is available in memory of a recovery instance when a given node fails, and does not have to be completely generated by scanning a redo log.

Abstract: According to embodiments, reconfiguration of lock masters for a cluster of nodes is optimized using coordinated hash indexes to index into the master hash table and into local hash tables stored on the nodes of the cluster. A DBMS uses a hybrid hash index, a portion of which represents a corresponding master hash index, to index into both the master hash table and into a local hash table for a given lock. The hash index used to store lock metadata in a particular local hash table bucket, on a particular node, encodes the lock master index, for a master hash table, to which the locks in the local hash table bucket correspond. Only the portions of the local hash table on the lock master that correspond to the index of the master hash table bucket need to be scanned in order to perform needed tasks for lock master reconfiguration.

Abstract: Techniques are described herein for quick identification of a set of units of data for which recovery operations are to be performed to redo or undo changes made by the failed node. When a lock is requested by an instance, lock information for the lock request is replicated by another instance. If the instance fails, the other instance may use the replicated lock information to determine a set of data blocks for recovery operations. The set of data blocks is available in memory of a recovery instance when a given node fails, and does not have to be completely generated by scanning a redo log.

Abstract: Techniques related to instance recovery using Bloom filters are disclosed. A multi-node node database management system (DBMS) includes a first database server instance and a second database server instance. A recovery set includes a set of data blocks that have been modified by a first database server instance and not persisted. A Bloom filter is generated to indicate whether data blocks are excluded from the recovery set. The Bloom filter is sent to the second database server instance, which determines whether the Bloom filter indicates that a particular data block is excluded from the recovery set. Based on determining that the Bloom filter indicates that the particular data block is excluded from the recovery set, access to the particular data block is granted.

Abstract: Embodiment provide that each pluggable database (PDB) in a container database is associated with a distinct distributed lock manager (DLM) domain. Thus, in order to access a PDB, a database server instance joins the DLM domain for the PDB. To perform actions on the PDB, the instance secures locks that belong to the DLM domain for the particular PDB. As such, buffers storing data for the PDB may be managed separately from buffers storing data for other PDBs using the PDB-specific DLM domains. An instance forcefully closing a particular PDB marks the DLM domain of the PDB as invalid, which allows detection of the forceful closure by a recovery instance. Detection of an invalid DLM domain by an instance causes the instance to automatically recover the PDB by accessing pertinent ranges of redo logs and replaying changes made to data blocks for the PDB indicated in the logs.

Abstract: According to embodiments, reconfiguration of lock masters for a cluster of nodes is optimized using coordinated hash indexes to index into the master hash table and into local hash tables stored on the nodes of the cluster. A DBMS uses a hybrid hash index, a portion of which represents a corresponding master hash index, to index into both the master hash table and into a local hash table for a given lock. The hash index used to store lock metadata in a particular local hash table bucket, on a particular node, encodes the lock master index, for a master hash table, to which the locks in the local hash table bucket correspond. Only the portions of the local hash table on the lock master that correspond to the index of the master hash table bucket need to be scanned in order to perform needed tasks for lock master reconfiguration.

Abstract: Embodiment provide that each pluggable database (PDB) in a container database is associated with a distinct distributed lock manager (DLM) domain. Thus, in order to access a PDB, a database server instance joins the DLM domain for the PDB. To perform actions on the PDB, the instance secures locks that belong to the DLM domain for the particular PDB. As such, buffers storing data for the PDB may be managed separately from buffers storing data for other PDBs using the PDB-specific DLM domains. An instance forcefully closing a particular PDB marks the DLM domain of the PDB as invalid, which allows detection of the forceful closure by a recovery instance. Detection of an invalid DLM domain by an instance causes the instance to automatically recover the PDB by accessing pertinent ranges of redo logs and replaying changes made to data blocks for the PDB indicated in the logs.

Abstract: Techniques for taking one or more nodes of a multi-node database system offline are provided. Initially, the multi-node database system uses a first data access management system (e.g., a distributed lock management system) to manage access to data stored in a database. In response to determining that one or more nodes need to be taken offline or otherwise become unavailable, the remaining nodes implement a second data access management system (e.g., an affinity-based access system) to manage access to data stored in the database. After the offline nodes are brought back online, all the nodes in the multi-node database system implement the first data access management system again. The transitions between the two data access management system may involve multiple phases that involve communicating different types of information between nodes that are taken offline and nodes that are not taken offline.

Abstract: Techniques for adaptive trace logging include, in one embodiment, obtaining input data on trace logging behavior and computing resources used by trace logging. Based on the obtained input data, an adaptive trace logging module automatically takes action at runtime to reduce the amount of computing resources consumed by tracing logging. For example, the action taken may include decreasing a trace logging level of an executing software program to reduce the number of trace logging messages added to a trace log. In another embodiment, the techniques include detecting a condition of an executing software program that warrants a change to a trace logging level of the executing program. The adaptive trace logging module automatically changes the trace logging level of the executing program as-needed for the detected condition. For example, the adaptive trace logging module may increase the trace logging level of an executing program upon detecting a deadlock or other abnormal condition of the executing program.

Abstract: A method, system, and computer program product. The method for non-intrusive redeployment of a standby database facility comprises configuring a database system having a shared lock manager process to synchronize two or more concurrent access instances, then granting lock requests for access to a cache of database blocks. At some moment in time, the shared lock manager process may fail, and a monitor process detects the failure or other stoppage of the shared lock manager process. A new shared lock manager process and other processes are started, at least one of which serves for identifying the database blocks in the cache that have not yet been written to the database. The identified blocks are formed into a recovery set of redo operations. During this time, incoming requests for access to the cache of database blocks are briefly blocked, at least until the recovery set of redo operations has been formed.

Abstract: Techniques for taking one or more nodes of a multi-node database system offline are provided. Initially, the multi-node database system uses a first data access management system (e.g., a distributed lock management system) to manage access to data stored in a database. In response to determining that one or more nodes need to be taken offline or otherwise become unavailable, the remaining nodes implement a second data access management system (e.g., an affinity-based access system) to manage access to data stored in the database. After the offline nodes are brought back online, all the nodes in the multi-node database system implement the first data access management system again. The transitions between the two data access management system may involve multiple phases that involve communicating different types of information between nodes that are taken offline and nodes that are not taken offline.

Abstract: Described herein are techniques for adaptively managing timers that are used in various layers of a node. In many cases, the number of timers that occur in the system is reduced by proactively and reactively adjusting values of the timers based on conditions affecting the system, thereby making such a system to perform significantly better and more resiliently than otherwise.

Abstract: A method and apparatus for managing locks in a database system is provided. A master node grants a lock on a first resource and a group of resources that includes the first resource to a first requester node. The requester node receives a mapping corresponding to the group of resources that may indicate that a lock already exists for a second resource in the group. If the requester node desires a lock on a resource located in the group, the requester node grants itself the lock without notifying the master node. A second requester node requests a lock for a particular resource in the group of resources. The first requester node grants the lock on the particular resource and updates the mapping to indicate that a different node holds a lock for the particular resource.

Abstract: Techniques for adaptive trace logging include, in one embodiment, obtaining input data on trace logging behavior and computing resources used by trace logging. Based on the obtained input data, an adaptive trace logging module automatically takes action at runtime to reduce the amount of computing resources consumed by tracing logging. For example, the action taken may include decreasing a trace logging level of an executing software program to reduce the number of trace logging messages added to a trace log. In another embodiment, the techniques include detecting a condition of an executing software program that warrants a change to a trace logging level of the executing program. The adaptive trace logging module automatically changes the trace logging level of the executing program as-needed for the detected condition. For example, the adaptive trace logging module may increase the trace logging level of an executing program upon detecting a deadlock or other abnormal condition of the executing program.

Abstract: Techniques are provided for responding to the termination of a node by selecting another node, and assigning to the selected node the affinity relationships that existed between the terminated node and one or more objects. The resources that belong to the objects involved in the affinity relationships are remastered to the selected node. The selected node then performs recovery of the resources that had been opened by the terminated node and/or serves as a failover node to execute the transactions that had been executing on the terminated node.

Abstract: Described herein are techniques for adaptively managing timers that are used in various layers of a node. In many cases, the number of timers that occur in the system is reduced by proactively and reactively adjusting values of the timers based on conditions affecting the system, thereby making such a system to perform significantly better and more resiliently than otherwise.

Abstract: In a multi-node database system, a list of data blocks to perform recovery operations on in the event of failure of a given node is dynamically maintained on another node. List is available when the given node fails, and allows the database to be made available more quickly.

Abstract: Techniques are provided for responding to the termination of a node executing one or more transactions by selecting another node to complete the transactions, and assigning to the selected node the affinity relationships that existed between the terminated node and the objects being accessed by said transactions.

Abstract: In a multi-node database system, a list of data blocks to perform recovery operations on in the event of failure of a given node is dynamically maintained on another node. List is available when the given node fails, and allows the database to be made available more quickly.