| Patent application number | Description | Published |
| 20080263556 | REAL-TIME SYSTEM EXCEPTION MONITORING TOOL - 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. | 10-23-2008 |
| 20110060724 | DISTRIBUTED DATABASE RECOVERY - A method and apparatus for recovery a cluster database is provided. Database recovery is divided among a plurality of surviving database server instances in the cluster. A surviving instance is responsible for recovering data blocks to which the surviving instance is assigned. One form of block-to-instance assignment may be based on mastership of the blocks. If a data block is locked by a surviving instance at the time of failure, then no recovery of that data block may be necessary. Else, if a copy of a data block that is to be recovered is stored on a surviving node in the cluster, then one or more redo records are applied to that copy (if necessary). A redo record that corresponds to that data block might not need to be applied to the copy if the redo record reflects changes (to the data block) that are already reflected in the copy. | 03-10-2011 |
| 20110083043 | HISTORY-BASED CONFLICT RESOLUTION - Processes in a cluster maintain a historical record of problem events as those events occur in the cluster. The record may describe (a) attributes of each event and (b) the resolution action that was performed to resolve each event. Whenever a new event occurs, a process determines whether any entries in the record reflect occurrences of an event with attributes like those of the new event. If a “matching” entry exists, then the process increments that entry's counter. If the historical record indicates that similar events have previously occurred more than a specified number of times, then the process may select and perform a resolution action that differs from the resolution action that is indicated in the entry. Additionally, patterns in the attributes of a recurring problem may be used to predict when the problem is likely to recur. Preventative actions may be taken to avoid recurrence of the problem. | 04-07-2011 |
| 20110093422 | TIME-BASED CONFLICT RESOLUTION - A conflict resolution mechanism collects statistical data regarding how much time certain common actions or waits take. For example, the mechanism may collect statistics on disk I/O for each disk device. Statistics may include the average access time, for example. Such statistics may be collected over a sliding window of time. With the statistical data that the mechanism collects, the mechanism can make a more intelligent judgment regarding whether a process is in a “hanging” condition. For example, if the average I/O to a disk is 10 seconds for the past hour, and if a process is doing disk I/O to that disk for 5 seconds, then the mechanism will not yet determine that the process is hanging. In order to determine whether the process is hanging, the mechanism looks at the average time and the longest time for the particular actions that the process is performing. | 04-21-2011 |
| 20110106778 | LOCK MANAGER ON DISK - A method and apparatus for managing shared resources in a clustered database management system is provided. In an embodiment, multiple master nodes exist in a database management system. A master node receives a lock request from a second node. The lock request is a request for a lock on a shared resource. The master node grants the lock request to the second node. While the second node holds the lock, the second node causes the master node to modify the shared resource. | 05-05-2011 |