Patent application number | Description | Published |
20080235481 | Managing memory in a system that includes a shared memory area and a private memory area - A method and apparatus for auto-tuning memory is provided. Memory on a computer system comprises at least one shared memory area and at least one private memory area. Addresses in the shared memory area are accessible to multiple processes. Addresses in the private memory area are dedicated to individual processes. Initially, a division in the amount of memory is established between the shared and private memory areas. Subsequently, a new division is determined. Consequently, memory from one memory area is “given” to the other memory area. In one approach, such sharing is achieved by causing the shared and private memory areas to be physically separate from each other both before and after a change in the division. The division of the amount of memory may be changed to a new division by deallocating memory from one of the memory areas and allocating that memory to the other of the memory areas. | 09-25-2008 |
20090077016 | FULLY AUTOMATED SQL TUNING - Techniques are provided for a fully-automated process for tuning database query language statements that selects database query language statements for tuning, tunes the database query language statements and generates tuning recommendations, tests the tuning recommendations, and determines whether to implement the tuning recommendations based on the test results. The fully-automated tuning process may also automatically implement certain tuning recommendations and monitor the performance of the database query language statements for which tuning recommendations have been implemented. | 03-19-2009 |
20090077017 | SQL PERFORMANCE ANALYZER - Techniques are provided for analyzing performance differences for a set of database query language statements on two different database systems. The performance analysis is based on quantitative measurements and estimates of the execution of the set of database query language statements on the two different database systems. This performance analysis process may be used by database administrators to predict impacts to performance due to a change in a database system. | 03-19-2009 |
20090105982 | DIAGNOSABILITY SYSTEM: FLOOD CONTROL - 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. | 04-23-2009 |
20090105989 | NON-INTRUSIVE GATHERING OF DIAGNOSTIC DATA USING ASYNCHRONOUS MECHANISMS - 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. | 04-23-2009 |
20090105991 | RULE-BASED ENGINE FOR GATHERING 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. | 04-23-2009 |
20090106219 | SQL Execution Plan Verification - Approaches, techniques, and mechanisms are disclosed for ensuring that a database command is executed according to a query plan that has been verified to be actually optimal. Except in rare circumstances, a database server does not execute a query plan unless it is first verified by the database server. The database server receives a request to execute a database command. The database server determines an unverified plan is the best plan for satisfying the request. Rather than risk the unknown behavior of an unverified plan, the database server instead satisfies the request according to a verified plan. Subsequently—for example as part of a scheduled job—the database server executes the unverified plan to determine performance statistics. Based at least on the performance statistics, the database server determines whether or not to verify the unverified plan. Techniques for concurrent and optimistic verifications are also disclosed. | 04-23-2009 |
20090106262 | SCRUBBING AND EDITING OF DIAGNOSTIC DATA - 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. | 04-23-2009 |
20090106278 | DIAGNOSABILITY SYSTEM - 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. | 04-23-2009 |
20090106320 | Automatic Recognition and Capture of SQL Execution Plans - Approaches, techniques, and mechanisms are disclosed for capturing and utilizing information related to query plans exhibiting interesting characteristics. A database server receives a request to execute a command. The database server executes the command according to a query plan. In response to determining that the command matches one or more pre-defined criteria, the database server captures information related to the execution of the first command. The criteria may include, for example, whether or not the command is repeatable, the existence of bind variables, access of a particular object, high resource utilization, receipt from a particular user, client, or application, etc. The information recorded may include, for example, performance statistics collected during execution of the first plan, data indicating the execution context during execution of the first plan, and properties of the first plan. The recorded information may subsequently be utilized by the database server in executing other database other database commands. | 04-23-2009 |
20090106321 | Maintaining and Utilizing SQL Execution Plan Histories - Approaches, techniques, and mechanisms are disclosed for maintaining a history of query plans executed for a database command, along with information related to each query plan. A database server receives a request to execute a particular command. The database server determines a plan for executing the particular command. The database server adds first information to a plan history associated with the particular command. The plan history comprises information related to a plurality of plans that have been generated for the particular command. The first information may include, for example, properties of the plan (including an outline of the plan) as well as statistics collected during execution of the plan. The database server may implement techniques for periodically refreshing information in a plan history. The database server may also implement techniques for purging old or less important plans. | 04-23-2009 |
20090106363 | INTELLIGENT COLLECTION OF DIAGNOSTIC DATA FOR COMMUNICATION TO DIAGNOSIS SITE - 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. | 04-23-2009 |
20090106589 | GATHERING CONTEXT INFORMATION USED FOR ACTIVATION OF CONTEXTUAL DUMPING - 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. | 04-23-2009 |
20090106595 | GATHERING INFORMATION FOR USE IN DIAGNOSTIC DATA DUMPING UPON FAILURE OCCURRENCE - 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. | 04-23-2009 |
20090106596 | USER-TRIGGERED DIAGNOSTIC DATA GATHERING - 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. | 04-23-2009 |
20090106601 | DIAGNOSTIC DATA REPOSITORY - 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. | 04-23-2009 |
20090106741 | UNIFIED TRACING SERVICE - 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. | 04-23-2009 |
20090119247 | EFFICIENT HASH BASED FULL-OUTER JOIN - In a database system, a full outer join is computed using a hash-based join. | 05-07-2009 |
20090248621 | METHOD AND MECHANISM FOR OUT-OF-THE-BOX REAL-TIME SQL MONITORING - Methods, systems, and computer program products for monitoring database queries and executions is disclosed. The query syntax may conform to the structured query language (SQL). The approach supports various performance statistics to be monitored at each step of the query statement's execution plan and for each row processed in order to meet requirements of a near real-time query monitoring solution. Such statistics include timing information plus some miscellaneous statistics like the number of rows processed, the amount of memory used, the amount of data spilled to disk, etc. | 10-01-2009 |
20100005340 | Test execution of user SQL in database server code - Systems, methods, and other embodiments associated with test execution of user SQL in server code are described. One example method includes producing a reproduced execution environment that reproduces a portion of an execution environment in which a user SQL runs. The example method may also include running the user SQL in the reproduced execution environment and capturing a statistic associated with performance of the user SQL while the user SQL runs in the reproduced execution environment. The method may conclude by storing, displaying, and/or providing a signal concerning the statistic. | 01-07-2010 |
20100030758 | Hybrid optimization strategies in automatic SQL tuning - Systems, methods, and other embodiments associated with hybrid optimization strategies in automatic SQL tuning are described. One example method includes receiving a first (e.g., cost-based) execution plan for a user structured query language statement (User SQL) from a first (e.g., cost-based) optimizer. The example method may also include receiving a second (e.g., rules-based) execution plan for the User SQL from a second, different (e.g., rules-based) query optimizer. The method may include identifying a preferred execution plan based on data produced by test executing the execution plans in a reproduced execution environment that reproduces at least a portion of an execution environment in which the user SQL runs. The method may also include controlling a database to execute the User SQL using the preferred execution plan. | 02-04-2010 |
20110276550 | FINE GRAIN SYNCHRONIZATION FOR DATABASE REPLAY - A method, apparatus, and computer readable medium for preserving data dependency during replay of database commands without strictly preserving a global ordering of the database commands is provided. A capture process captures a workload of database commands executed by a production system. The captured workload includes object identifiers that identify database objects that were referenced directly or indirectly during execution of the database commands by the production system. The captured workload also includes an indication of whether the database objects were potentially read or written during execution of the commands. The workload is processed to determine that an object accessed during execution of a command was previously modified during execution of one or more other commands. A replay process on a test database system prevents the command from being replayed until after the one or more other commands have been replayed to modify the object. | 11-10-2011 |
20140236921 | SQL EXECUTION PLAN VERIFICATION - Approaches, techniques, and mechanisms are disclosed for ensuring that a database command is executed according to a query plan that has been verified to be actually optimal. Except in rare circumstances, a database server does not execute a query plan unless it is first verified by the database server. The database server receives a request to execute a database command. The database server determines an unverified plan is the best plan for satisfying the request. Rather than risk the unknown behavior of an unverified plan, the database server instead satisfies the request according to a verified plan. Subsequently—for example as part of a scheduled job—the database server executes the unverified plan to determine performance statistics. Based at least on the performance statistics, the database server determines whether or not to verify the unverified plan. Techniques for concurrent and optimistic verifications are also disclosed. | 08-21-2014 |
20150081669 | FULLY AUTOMATED SQL TUNING - Techniques are provided for a fully-automated process for tuning database query language statements that selects database query language statements for tuning, tunes the database query language statements and generates tuning recommendations, tests the tuning recommendations, and determines whether to implement the tuning recommendations based on the test results. The fully-automated tuning process may also automatically implement certain tuning recommendations and monitor the performance of the database query language statements for which tuning recommendations have been implemented. | 03-19-2015 |