Oracle International Corporation

Oracle Corporation

Gary C Ngai

Mark Charles Ramacher

Benoit Dageville

Amit Ganesh

Jonathan D Klein

Karl Dias

Yair Sarig

Marcus Fallen

Ajith Kumar Mysorenagarajarao

Graham Wood

Leng Leng Tan

Alex Tsukerman

John Mark Beresniewicz

Sujatha Muthulingam

Richard Sarwal

Hailing Yu

Michael Feng

Mike Feng

Juan R Loaiza

Tirthankar Lahiri

Roger J Bamford

Dieter Gawlick

J William Lee

Gianfranco Putzolu

Hasan Rizvi

Sushil Kumar

Garret Frederick Swart

Uri Shaft

Mohamed Ziauddin

Carol L Colrain

Balasubrahmanyam Kuchibhotla

Wei Huang

Dmitry Mikhailovich Potapov

Vasudha Krishnaswamy

Alok Pareek

Venkateshwaran Venkataramani

Arvind Nithrakashyap

Bhagat V Nainani

Sreedhar Mukkamalla

Jane Xin Chen

Wanli Yang

Vishwanath Karra

Francisco Sanchez

Rosanne Park Toohey

Amirali Valiani

Balasubrahmanya Kuchibhotla

Luxi Chidambaran

Hsiao-te Su

Amir Valiani

Connie Green

Venkateshwaran Venkatatamani

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

Future-based performance baselines

A computer is programmed with multiple software programs to record structures including (a) unstructured information to denote a transition between portions of code, and (b) metadata related to one or more attributes of the information. In addition, the computer writes two additional types of structures: section type, and dump type. The section type structure has metadata to indicate a beginning and an end, to bracket a group of structures located therebetween. The dump type has a dump header and a dump body. The dump header includes a symbol to indicate it's of dump type. The dump body is a set of values of an object used by the software program(s) during execution by the computer. A group of structures, within a section type, may include structures of each of the trace record type, dump type and section type.

Unified tracing service

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

A diagnosability system for automatically collecting, storing, communicating, and analyzing diagnostic data for one or more monitored systems. The diagnosability system comprises several components configured for the collection, storage, communication, and analysis of diagnostic data for a condition detected in monitored system. The diagnosability system enables targeted dumping of diagnostic data so that only diagnostic data that is relevant for diagnosing the condition detected in the monitored system is collected and stored. This in turn enables first failure analysis thereby reducing the time needed to resolve the condition detected in the monitored system.

Diagnosability system

Various embodiments of the invention provide solutions to allow more sophisticated management of the relationship between a database and its clients (which can be, inter alia, end users, business applications, etc.). Merely by way of example, some embodiments can facilitate the management of work requests in a database, as well as the management of the quality-of-service in a database system. In some embodiments, an identification handle may be assigned to a database work request. A database management application can use the identification handle to identify the work request, as well, perhaps, as any related work requests. The identification handle may also identify the database (and/or an instance thereof) and/or a clustered database node, and the identification handle may be transmitted to a mid-tier application, e.g., to notify the mid-tier about the processing of the work request, changes in quality-of service, server availability, etc.

Methods, systems and software for identifying and managing database work

A self-managing workload repository (AWR) infrastructure useful for a database server to collect and manage selected sets of important system performance statistics. Based on a schedule, the AWR runs automatically to collect data about the operation of the database system, and stores the data that it captures into the database. The AWR is advantageously designed to be lightweight and to self manage its use of storage space so as to avoid ending up with a repository of performance data that is larger than the database that it is capturing data about. The AWR is configured to automatically capture snapshots of statistics data on a periodic basis as well as purge stale data on a periodic basis. Both the frequency of the statistics data capture and length of time for which data is kept is adjustable. Manual snapshots and purging may also be performed. The AWR captured data allows for both system level and user level analysis to be automatically performed without unduly impacting system performance, e.g., by eliminating or reducing the requirement to repeat the workload in order to diagnose problems.

Self-managing performance statistics repository for databases

Growing community of inventors

Saratoga, CA, United States of America

Gary C Ngai