Oracle International Corporation

Tak Fung Wang

Angelo Pruscino

Wilson Wai Shun Chan

Wilson Wai Chan

Tolga Yurek

Michael Zoll

David Brower

Andrey Gusev

Yu Kin Ho

Chandrajith Ramachandran Unnithan

Sashikanth Chandrasekaran

Roger J Bamford

Carol L Colrain

William Havinden Bridge, Jr

Vinay H Srihari

Neil MacNaughton

Patricia C Grewell

John C Hsu

Eugene Reddy Ho

Cheng-Lu Hsu

Deepti Srivastava

Dungara Ram Choudhary

Wai Shun Wilson Chan

Ahmed S Abbas

Chiyeh Hou

Troy Anthony

Walter Battistella

William Jr Bridge

Neil Macnaughton

Techniques are provided for determining access affinity between services in a database cluster, and for placing workload of those services based, at least in part, on the access affinity. The techniques involve generating access records that indicate when sessions that are associated with each service operate on data blocks that were accessed by another session that is associated with another service. Access affinity information is generated based on the access records, where the access affinity information indicates access affinity (e.g. conflict scores) between each pair of services. The cluster then selects which node is to perform the work of a given session based on the access affinity information and the service associated with the session.

Methods and systems for conflict detection and mitigation between services in an autonomous database cloud environment

Disclosed is a method, a computer program product, and a computer system for implementing automatic connection load balancing of database connections between instances of a cluster. Load imbalances are detected globally in the cluster, and can be corrected autonomously by the local instances. The local controller/orchestrator detects the imbalance, computes a target for the instance, and makes any necessary adjustments on the instance, where a server marks the connections to redistribute, and then implements draining and/or planned failover to move sessions.

Automatic connection load balancing between instances of a cluster

The fail-over computer cluster enables multiple computing devices to operate using adaptive quorum rules to dictate which nodes are in the fail-over cluster at any given time. The adaptive quorum rules provide requirements for communications between nodes and connections with voting file systems. The adaptive quorum rules include particular recovery rules for unplanned changes in node configuration, such as due to a disruptive event. Such recovery quorum rules enable the fail-over cluster to continuing to operate with various changed configurations of its node members as a result of the disruptive event. In the changed configuration, access to voting file systems may not be required for a majority-group subset of nodes. If no majority-group subset remains, nodes may need direct or indirect access to voting file systems.

Computer cluster using expiring recovery rules

Computer cluster with adaptive quorum rules

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.

Planned cluster node maintenance with low impact on application throughput

Techniques for mastering resources in a cluster of nodes are provided. A global backup lock manager (GBLM) is maintained for a cluster of nodes that implement distributed lock management. Before a server instance is taken down, for example, for maintenance purposes, such as installing a new version of the server instance code, the mastership information that the server instance stores is reflected in the mastership information maintained by the GBLM. Thus, shutting down the server instance does not involve remastering the resources mastered by the server instance. As a result, shutting down the server instance may take minimal time.

Global backup lock manager

A method for locking resources, including: receiving, by an accelerator, a first request from a first client to lock a first resource; evaluating, by a computer processor of a server, a hash function using an identifier of the first resource as an input to the hash function; identifying, by the computer processor and based on evaluating the hash function, a first hash bucket in a shared memory residing in a physical memory of the server; detecting that the first hash bucket is occupied; and sending the first request to a master lock monitor residing in a user space of the server based at least on detecting that the first hash bucket is occupied.

Lock acceleration

Described herein are techniques for dynamically monitoring and managing resource usages of processes running on a node in a multi-node database system. High resource usages of processes can be proactively detected and alleviated, thereby making such a node to perform significantly better than otherwise.

Intelligent flood control management

Techniques for monitoring resources of a computer system are provided. A monitoring process collects and reports utilization data for one or more resources of a computer system, such as CPU, memory, disk I/O, and network I/O. Instead of reporting just an average of the collected data over a period of time (e.g., 10 seconds), the monitoring process at least reports individually collected resource utilization values. If one or more of the utilization values exceed specified thresholds for the respective resources, then an alert may be generated. In one approach, the monitoring process is made a real-time priority process in the computer system to ensure that the memory used by the monitoring process is not swapped out of memory. Also, being a real-time priority process ensures that the monitoring process obtains a CPU in order collect resource utilization data even when the computer system is in a starvation mode.

Real-time database exception monitoring tool using instance eviction data

Measuring processes are started at a plurality of priority levels. A different one of the measuring processes is started for each of the priority levels. Subsequently, for each of the measuring processes, it is determined whether each measuring process is scheduled for executing at a respective target rate. In response to determining that a particular measuring process of the measuring processes is not scheduled for executing at a particular target rate, resource allocation to at least one monitored process running at a particular level of the priority levels is adjusted. The at least one monitored process is not any of the measuring processes.

Dynamically monitoring and rebalancing resource allocation of monitored processes based on execution rates of measuring processes at multiple priority levels

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.

Adaptive cluster timer manager

Database server instances in a database server cluster broadcast, to other instances in the cluster, information concerning certain problem events. Because each server instance is aware of problems that other server instances are experiencing, each server instance is enabled to make more intelligent decisions regarding the actions that it should perform in response to the problems that the server instance is experiencing. Instead of terminating itself, a server instance might opt to wait for a longer amount of time for an operation to complete. The server instance may do so due to the server instance having received information that indicates that other server instances are experiencing similar problems. Whenever the information received from other server instances makes it appear that a problem is unlikely to be solved in the cluster as a whole by terminating a server instance, that server instance may continue to wait instead of terminating itself.

Cluster neighborhood event advisory

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.

Adaptive region locking

A system and method for estimating data conflicts in a multi-node system is disclosed. According to an embodiment of the invention, tracing the execution of a workload on a single node and analyzing the trace records makes it possible to predict how many data conflicts would occur if the workload were executed across multiple nodes. Also disclosed is a method and mechanism for generating a load distribution plan for a multi-node system.

Method and mechanism for predicting data conflicts and generating a load distribution plan in a multi-node system

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.

Growing community of inventors

Redwood City, CA, United States of America

Tak Fung Wang