Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: Techniques for gathering information during runtime of a monitored system such that the information is available for facilitating diagnostics for the monitored system. In one embodiment, upon detection of a condition (such as an error condition) in the monitored system, a portion of the gathered information provides contextual information that facilitates gathering of diagnostic data that is relevant for the detected condition. This facilitates capturing of diagnostic data that is relevant for diagnosing the detected condition. The information gathered and stored during runtime may include information related to local variables, information related to tagged information (e.g., tagged functions/processes) executing in the monitored system, information related to potential impacts to the monitored system due to failures, metadata information, and other information.

Abstract: 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.

Abstract: 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.

Abstract: 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.