Oracle International Corporation

Mark Charles Ramacher

Gary C Ngai

Benoit Dageville

Karl Dias

Graham Wood

Yair Sarig

Marcus Fallen

Ajith Kumar Mysorenagarajarao

Jonathan D Klein

Leng Leng Tan

Alex Tsukerman

Juan R Loaiza

Venkateshwaran Venkataramani

John Mark Beresniewicz

Uri Shaft

Mohamed Ziauddin

Sushil Kumar

Richard Sarwal

Michael Feng

Mike Feng

Tirthankar Lahiri

Jane Xin Chen

Hailing Yu

Shivani Gupta

Mohamed Zait

Carol L Colrain

Balasubrahmanyam Kuchibhotla

William Bridge

Khaled Yagoub

Dinesh Das

Vasudha Krishnaswamy

Sujatha Muthulingam

Gianfranco Putzolu

Stephen John Vivian

Eric P Voss

Sandeep Jain

Wanli Yang

Raghu Hanumanth Reddy Patti

Manas Goswami

Gregory Pongracz

Lip Boon Doo

Vishwanath Karra

Kannan Muthukkaruppan

Ana Maria Hernandez McCollum

Amit Jasuja

Francisco Sanchez

Russell John Green

Sreenath Bodagala

Cecilia Gervasio Grant

Farouk Abushaban

Balasubrahmanya Kuchibhotla

Luxi Chidambaran

Hsiao-te Su

Cornelius G Doherty

Amir Valiani

Rahul Rawat

Connie Green

Venkateshwaran Venkatatamani

Jayakumar Sadras

Konstantina Dialeris Green

Sreekanth Vedavyas

Jacco Draaller

Sriram Kini

Mineharu Takahara

Annesharmila Immanueljoseph

Anurag Mathur

Ze Tian Ding

Techniques for suppressing notifications are disclosed. An incident may repeatedly flap between various resolved and unresolved states. Furthermore, other incident attributes may flap between various states such as, for example, varying levels of incident severity. Each change in state results in the transmission of a notification. In order to reduce the number of notifications, the system estimates a flapping window for the incident based on the flapping behavior of prior incidents. The system computes a notification suppression window based at least in part on the estimated flapping window. The system suppresses notifications corresponding to changes in incident state that are detected during the notification suppression window. The notification suppression window may be extended in response to extending the estimated flapping window.

Method and system for managing notifications for flapping incidents

Techniques that improve manageability of systems. Techniques are provided for creating different types of baselines that are more flexible and dynamic in nature. A future-based baseline may be created defining a period of time, wherein at least a portion of the period of time is in the future. A baseline may be created that is a composite of multiple baselines. In general, baselines may be specified having one or more periods of time that are either contiguous or non-contiguous. A template for creating a set of baselines based on a set of time periods may also be created, where the template can be used to create a baseline for each of the set of time periods. A moving window baseline may be created having an associated time window that changes with passage of time, where accordingly the data associated with the baseline may also dynamically change with passage of time.

Creating composite baselines based on a plurality of different baselines

A system of remote nodes may be divided into sets of partner nodes. One remote node becomes a partner of another remote node. As partners, the nodes agree to monitor each other's health and report anomalies, such as a failure of one of the nodes, to a monitoring server. The nodes do so using a persistent communication link, such as an open socket. Using the described techniques, the monitoring load of a system is distributed in part away from the monitoring server and to the nodes themselves. This may reduce the resources required of the monitoring server. At the same time, since nodes are now being monitored by partner nodes that are likely to be closer than the monitoring server, and/or on account of the monitoring being performed via a persistent communication link, certain failures can be detected in real-time or near real-time.

Detect process health remotely in a realtime fashion

Future-based performance baselines

A computer readable medium storing a database query language statement tuning base in a tuning base memory location is disclosed. The tuning base includes tuning information for one or more query language statements. The tuning information for each statement includes one or more tuning actions for the statement, and a signature to allow an optimizer to identify the one or more tuning actions for the statement.

SQL tuning base

Techniques that enable a user or customer at a system site to review and, if desired, modify data identified at the system site for transmission to a diagnosis site prior to the transmission. The identified diagnostic data may be modified such that data that the user does not want to be sent to the diagnosis site (e.g., sensitive data) is excluded from the data communicated to the diagnosis site. The data may be modified by removing or excluding the sensitive data from the data that is communicated to the diagnosis site or replacing the sensitive data with non-sensitive data. The modified data may then be communicated from the system site to the diagnosis site in the form of a package.

Scrubbing and editing of diagnostic data

An infrastructure is provided for gathering diagnostic data that is relevant to an error or other conditions detected in a monitored system. A diagnosability framework is provided that automates the gathering of relevant diagnostic data upon occurrence of the condition in the monitored system. In one embodiment, context data is determined for the condition detected in the monitored system. A rule-based engine is provided that is configured to automatically determine one or more actions to be performed for the condition detected in the monitored system based on the determined context data. The actions may include performing tasks that gather diagnostic data that is relevant to the detected condition, store the gathered diagnostic data in a repository, recommend one or more diagnostic actions to a user, and other diagnostic related actions.

User-triggered diagnostic data gathering

Rule-based engine for gathering diagnostic data

Techniques for indicating the status or health of a software system in a simple and summarized manner. In one embodiment, a health meter is displayed that displays a status value indicating the status or health of the software system. The status or health of the system as indicated by the health meter may be based upon one or more characteristics or perspectives (or components) of the system, such as performance, resource utilization, reliability, availability, scalability, and status values computed for the components.

Health meter

Techniques for intelligently identifying diagnostic data to be communicated from a product or system site (e.g., a customer site) to a diagnosis site (e.g., a vendor site). An appropriate amount of diagnostic data is identified to facilitate efficient and quick diagnosis and error resolution. Techniques are also provided that enable a customer to review the data identified for transmission to the diagnosis site prior to the transmission.

Intelligent collection of diagnostic data for communication to diagnosis site

Techniques for controlling collection of diagnostic data in a monitored system. A set of flood control rules are configured for the monitored system for controlling the gathering of diagnostic data in the monitored system. The set of flood control rules may include one or more default flood control rules. The set of flood control rules are user-configurable enabling the user of the monitored system to set policies for dynamically controlling gathering of diagnostic data for the monitored system. In one embodiment, diagnostic data gathering is controlled based upon a number of previous occurrences of a condition in some predefined or user-configured time frame that triggers diagnostic data gathering and/or a number of previous executions of an action performed in some predefined or user-configured time frame responsive to the condition in the monitored system.

Diagnosability system: flood control

Gathering context information used for activation of contextual dumping

Techniques for systematically gathering, organizing, and storing diagnostic data related to multiple monitored systems (e.g., multiple instances of a product or multiple products). A centralized repository is provided that is organized in a hierarchical manner to facilitate proper organization of the diagnostic data related to multiple monitored systems. In one embodiment, a root directory comprising one or more subdirectories is provided for storing diagnostic data collected for each monitored system. Multiple root directories may be provided under a common base directory for storing diagnostic data corresponding to multiple monitored systems. This enables correlation of diagnostic data across multiple monitored systems.

Diagnostic data repository

Techniques for non-intrusive performance of diagnostic actions including actions that result in gathering of diagnostic data in response to a condition detected in a monitored system. In one embodiment, the diagnostic actions are performed asynchronously by processes or threads that are different from the failing process or thread that receives or detects the condition that triggers the diagnostic actions such that the failing process or thread can continue processing without being affected by the executions of the diagnostic actions. Multiple asynchronous processes or threads that are different from the failing process or thread may be spawned to perform multiple diagnostic actions in parallel. The asynchronous processes or threads may be monitored to ensure that they do not adversely impact the monitored system.

Non-intrusive gathering of diagnostic data using asynchronous mechanisms

One or more usage models are provided for a database. Each usage model includes a set of rules that are used to analyze database performance. A usage model in one or more usage models is determined. Database information is determined based on the usage model. The database information is then analyzed based on rules associated with the usage model. One or more performance problems are determined based on the analysis.

Automatic database diagnostic usage models

Growing community of inventors

Belmont, CA, United States of America

Mark Charles Ramacher