Abstract: A storage device uses non-volatile memory devices for caching. The storage device operates in a mode referred to herein as write-back mode. In write-back mode, a storage device responds to a request to write data by persistently writing the data to a cache in a non-volatile memory device and acknowledges to the requestor that the data is written persistently in the storage device. The acknowledgement is sent without necessarily having written the data that was requested to be written to primary storage. Instead, the data is written to primary storage later.

Abstract: No-loss rapid recovery performs resynchronization efficiently while concurrently allowing availability to mirrored data on the storage device. No-loss rapid recovery has two stages and involves storage devices that have both a non-volatile cache and primary storage and that operate as mirror buddies. The first stage is referred to herein as the buddy-retention stage. During the buddy-retention stage, writes to mirrored data are not performed on the offline mirror buddy but are performed on the online mirror buddy. The mirrored data changed in the online mirrored buddy is retained in the non-volatile cache of the retention buddy. The next stage is referred to herein as the rapid resynchronization stage. In this stage, the changed mirrored data retained by the retention buddy for no-loss rapid recovery is used to resynchronize the offline buddy. The storage device is resynchronized using the changed mirrored data retained in the cache of the mirror buddy.

Abstract: Techniques are described herein for supporting multiple versions of a database server within a database machine comprising a separate database layer and storage layer. In an embodiment, the database layer includes compute nodes each hosting one or more instances of a database server. The storage layer includes storage nodes each hosting one or more instances of a storage server, also referred to herein as a “cell server.” In general, the database servers may receive data requests, such as SQL queries, from client applications and service the requests in coordination with the cell servers of the storage layer.

Abstract: Techniques are described herein for supporting multiple versions of a database server within a database machine comprising a separate database layer and storage layer. In an embodiment, the database layer includes compute nodes each hosting one or more instances of a database server. The storage layer includes storage nodes each hosting one or more instances of a storage server, also referred to herein as a “cell server.” In general, the database servers may receive data requests, such as SQL queries, from client applications and service the requests in coordination with the cell servers of the storage layer.

Abstract: Systems, methods, and other embodiments associated with detecting a node death in a clustered distributed system are described. In one embodiment, a method includes transmitting a ping message to a peer node in the network. If a reply to the ping message is not received from the peer node, a query is sent to table of port identifiers that lists ports in the cluster. In one embodiment, the query includes a port identifier associated with the peer node. The peer node is declared as inactive/dead when the query fails to locate a match in the table for the port identifier. When the query locates a match in the table for the port identifier, another ping message is periodically transmitted to the peer node.

Abstract: Dirty data in a storage device is made current through rapid re-silvering, which uses a mirrored and up-to-date version of the dirty data from another storage device to recover the data. Because under rapid re-silvering cache metadata in volatile memory survives the failure of the cache, the cache metadata is used to determine which subset of data from the other storage device needs to be copied to the storage device being re-silvered. During re-silvering, cache metadata is used to determine which I/O requests from clients are requests for data that is not stale.

Abstract: Techniques are described herein for supporting multiple versions of a database server within a database machine comprising a separate database layer and storage layer. In an embodiment, the database layer includes compute nodes each hosting one or more instances of a database server. The storage layer includes storage nodes each hosting one or more instances of a storage server, also referred to herein as a “cell server.” In general, the database servers may receive data requests, such as SQL queries, from client applications and service the requests in coordination with the cell servers of the storage layer.

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: No-loss rapid recovery performs resynchronization efficiently while concurrently allowing availability to mirrored data on the storage device. No-loss rapid recovery has two stages and involves storage devices that have both a non-volatile cache and primary storage and that operate as mirror buddies. The first stage is referred to herein as the buddy-retention stage. During the buddy-retention stage, writes to mirrored data are not performed on the offline mirror buddy but are performed on the online mirror buddy. The mirrored data changed in the online mirrored buddy is retained in the non-volatile cache of the retention buddy. The next stage is referred to herein as the rapid resynchronization stage. In this stage, the changed mirrored data retained by the retention buddy for no-loss rapid recovery is used to resynchronize the offline buddy. The storage device is resynchronized using the changed mirrored data retained in the cache of the mirror buddy.

Abstract: Dirty data in a storage device is made current through rapid re-silvering, which uses a mirrored and up-to-date version of the dirty data from another storage device to recover the data. Because under rapid re-silvering cache metadata in volatile memory survives the failure of the cache, the cache metadata is used to determine which subset of data from the other storage device needs to be copied to the storage device being re-silvered. During re-silvering, cache metadata is used to determine which I/O requests from clients are requests for data that is not stale.

Abstract: Systems, methods, and other embodiments associated with detecting a node death in a clustered distributed system are described. In one embodiment, a method includes transmitting a ping message to a peer node in the network. If a reply to the ping message is not received from the peer node, a query is sent to table of port identifiers that lists ports in the cluster. In one embodiment, the query includes a port identifier associated with the peer node. The peer node is declared as inactive/dead when the query fails to locate a match in the table for the port identifier. When the query locates a match in the table for the port identifier, another ping message is periodically transmitted to the peer node.

Abstract: Techniques are provided for isolating faults in a software program by providing at least two code paths that are capable of performing the same operation. When a fault occurs while the one of the code paths is being used to perform an operation, data that indicates the circumstances under which the fault occurred is stored. For example, a fault-recording mechanism may store data that indicates the entities that were involved in the failed operation. Because they were involved in an operation that experienced a fault, one or more of those entities may be “quarantined”. When subsequent requests arrive to perform the operation, a check may be performed to determine whether the requested operation involves any of the quarantined entities. If the requested operation involves a quarantined entity, a different code path is used to perform the operation, rather than the code path from which the entity is quarantined.

Abstract: A storage device uses non-volatile memory devices for caching. The storage device operates in a mode referred to herein as write-back mode. In write-back mode, a storage device responds to a request to write data by persistently writing the data to a cache in a non-volatile memory device and acknowledges to the requestor that the data is written persistently in the storage device. The acknowledgement is sent without necessarily having written the data that was requested to be written to primary storage. Instead, the data is written to primary storage later.

Abstract: Techniques are provided for isolating faults in a software program by providing at least two code paths that are capable of performing the same operation. When a fault occurs while the one of the code paths is being used to perform an operation, data that indicates the circumstances under which the fault occurred is stored. For example, a fault-recording mechanism may store data that indicates the entities that were involved in the failed operation. Because they were involved in an operation that experienced a fault, one or more of those entities may be “quarantined”. When subsequent requests arrive to perform the operation, a check may be performed to determine whether the requested operation involves any of the quarantined entities. If the requested operation involves a quarantined entity, a different code path is used to perform the operation, rather than the code path from which the entity is quarantined.

Abstract: Various embodiments of the invention provide solutions that can offer a consistent framework for tools that assist in the configuration, tuning, and/or troubleshooting of a database and/or an RDBMS. Merely by way of example, one set of embodiments provides a software framework for an advisor component of a database and/or RDBMS. In accordance with some embodiments, the framework might specify a common data model for such advisor components. The data model can include, merely by way of example, a set of one or more findings (which might, in some cases, describe the result of an analysis of a circumstance in the database, RDBMS, and/or a mid-tier application used with the database) and/or a set of one or more recommendations (which might provide suggestions for addressing the circumstance). In particular embodiments. In particular embodiments, the data model might include a set of on or more rationales, which can explain the recommendations.

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 method and system of reclaiming storage space in data storage systems is disclosed. In one embodiment, a high water mark of a data container is adjusted after data in the data container is compacted. As a result, unused space in the data container can be reclaimed.

Abstract: An intelligent database infrastructure wherein the management of all database components is performed by and within the database itself by integrating management of various components with a central management control. Each individual database component, as well as the central management control, is self-managing. A central management control module integrates and interacts with the various database components. The database is configured to automatically tune to varying workloads and configurations, correct or alert about bad conditions, and advise on ways to improve overall system performance.