Abstract: In a disk drive that includes a magnetic head and a flexible printed circuit board (FPCB) coupled to an actuator for the magnetic head, a method of writing servo information includes: receiving a signal based on an electrical property of a material included in the FPCB, wherein the electrical property of the material changes as the actuator moves; determining a radial position of the magnetic head relative to a disk of the disk drive based on the signal; and controlling a radial velocity of the magnetic head relative to the disk of the disk drive based on the radial position.

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

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

Abstract: Systems and methods to define and store performance baselines. A baseline may be defined as a pair of snapshots, each snapshot containing the same set of statistics and having a timestamp value associated therewith. The present invention allows for the designation, automatically or manually, of statistics collected over a certain period of time to be stored and used for comparison. Baselines may be used, for example, to manually or automatically compare with current system performance, compare difference-difference values and set thresholds to monitor current system performance.

Abstract: A self-managing workload repository infrastructure (or “AWR” for Automatic workload repository) which is useful for a database server to collect and manage useful system performance statistics. The AWR runs automatically to collect performance data about the operation of the database system, and stores the data that it captures into the database. The collection process is done inside the database, and the collection process is highly efficient as data is retrieved directly from the shared memory of the database kernel. The data captured allows both system level and user level analysis to be performed without unduly impacting system performance, e.g., by eliminating or reducing the requirement to repeat the workload in order to diagnose problems. 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. The captured performance data includes one or more of the top N (e.g.

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.