Patent application number | Description | Published |
20080235182 | Isolating Database Queries for Performance Processing - Methods, systems, and computer program products are provided for isolating database queries for performance processing. Embodiments typically include presenting to a user a prioritized list of potentially poorly performing queries; receiving from the user a selection of one or more potentially poorly performing queries; and executing performance processing of the selected queries. | 09-25-2008 |
20100185639 | Autonomic Self Configuring Building-Block Database Index - Methods, systems, and computer programs for executing a query having a first and second query value; in a database having at least two composite indexes, where the first index covers a first and second column and the second index covers the second column and a third column. Methods can include executing a query over the first and third columns, by using the first query values to probe the first index to obtain all related second column values, and using the obtained column values to probe the second index for all third column values which satisfy the second query value. A temporary composite index over the first and third columns for the query values can be created. A temporary composite index can be created for a query which was unexpected. | 07-22-2010 |
20100250574 | USER DICTIONARY TERM CRITERIA CONDITIONS - Techniques are disclosed for processing an abstract query which includes a dictionary term criteria condition. The dictionary term criteria condition is used to specify a set of one or more keywords, each of which should appear in a distinct document (of a defined set of documents) in order for the condition to be satisfied. In one embodiment, a user defines an abstract query by specifying a model entity (a logical focus for a query used to identify a set of documents associated with the model entity), logical fields (specifying query conditions and information to be returned), and a set of terms for a dictionary term criteria condition. | 09-30-2010 |
20110137890 | Join Order for a Database Query - In an embodiment, a portion of the execution plan is executed to produce a portion of records in a partial result set. If a first join of a table is performed that eliminates more than a first threshold number of records from the partial result set, a determination is made whether an estimated cost of a forced primary join is less than an estimated cost of a star join. If the estimated cost of the forced primary join is less than the estimated cost of the star join, then the table is moved first in a join order in the execution plan, the portion of the records in the partial result set is discarded, and the execution is re-started with a different portion of the execution plan to produce a different portion of the records. | 06-09-2011 |
20110270822 | DATABASE QUERY GOVERNOR WITH TAILORED THRESHOLDS - A query governor intelligently sets tailored thresholds for a query accessing a computer database. The query governor preferably generates a tailored threshold for each query sent to the database for execution. The tailored threshold for the query is preferably compared to an estimated query execution time to determine whether to execute the query. The query governor uses one or more factors applied to a standard threshold to generate the tailored threshold. The factors preferably include user factors and query factors. These factors are dynamically adjusted by the query governor in an intelligent way to increase optimal use of the database. Other factors may include factors such as job priority factor, resource factor and an application factor. | 11-03-2011 |
20120047125 | EXECUTING A QUERY PLAN WITH DISPLAY OF INTERMEDIATE RESULTS - In an embodiment, a FIRSTIO execution plan is selected that has a lowest estimated execution time for finding a number of records that satisfy the query and are simultaneously viewable. An ALLIO execution plan is selected that has a lowest estimated execution time for finding all records that satisfy the query. The FIRSTIO execution plan is executed for a first time period to create a FIRSTIO result set. The ALLIO execution plan is executed for a second time period to create an ALLIO result set. The FIRSTIO result set is displayed if the FIRSTIO result set comprises more records than the ALLIO result set. The ALLIO result set is displayed if the ALLIO result set comprises more records than the FIRSTIO result set. In an embodiment, the first and second time periods expire in response to the expiration of a maximum time specified by the query. | 02-23-2012 |
20120072412 | EVALUATING EXECUTION PLAN CHANGES AFTER A WAKEUP THRESHOLD TIME - In an embodiment an execution plan for a query is created. A wakeup threshold is set proportional to an amount of time taken by the creation of the execution plan. In various embodiments, the wakeup threshold is increased by a percentage equal to one minus a percentage of free resources at a computer system, is increased inversely proportional to an amount of execution time of a previous execution of the execution plan, or is decreased proportional to a number of times the execution plan was executed. A portion of the execution plan is executed to produce a portion of rows in a result set until the wakeup threshold expires. After the wakeup threshold expires, changes to the execution plan are evaluated. | 03-22-2012 |
20120124056 | DISAPPEARING INDEX FOR MORE EFFICIENT PROCESSING OF A DATABASE QUERY - A disappearing index allows faster processing of a database query without the startup time of a prior art sparse index. The disappearing index starts as a full index but is trimmed of index values that point to a row in the table that is not selected by the query. Thus the traditional index disappears as it becomes a sparse index tailored to the query. The query is able to execute faster using the now sparse index since the target database table is not accessed for duplicate values in the base table of the query. The query optimizer may determine to use a disappearing index based on estimates of the number of duplicate values in the base table. When the query is complete, the created disappearing table may be discarded or used for other queries that match the selection of the query that created the disappearing index. | 05-17-2012 |
20120158698 | EXECUTION PLANS WITH DIFFERENT DRIVER SOURCES IN MULTIPLE THREADS - In an embodiment, a first driver source specified by a first execution plan that implements a query is designated, and a second driver source specified by a second execution plan that implements the query is designated. A portion of the first execution plan and a portion of the second execution plan are executed. If a unique identifier of a first row returned by the executing the portion of the first execution plan does not match all unique identifiers of all rows from the second driver source that were saved to a result set by the executing the portion of the second execution plan, then the first row returned by the executing the portion of the first execution plan is added to the result set and the unique identifier of the first row that was returned by the executing the portion of the first execution plan is added to a unique identifier log. | 06-21-2012 |
20120179698 | Multiple Sparse Index Intelligent Table Organization - A method, system and computer program product are provided for reorganizing a database table according to multiple sparse indexes, wherein the reorganized table has superior I/O performance attributes versus the original table. More specifically, the table is reorganized such that random I/O is minimized by more tightly grouping rows in the table associated with each of the referencing sparse indexes together. This enables more associated rows from a given table relevant to a sparse index to be read into RAM for a given I/O operation. | 07-12-2012 |
20120330993 | CONTACT RECOMMENDATION SYSTEM FOR A USER COMMUNICATION - Techniques are described for allowing a first user to efficiently send contact information to a second user using a user communication of a messaging application such as email programs, instant messaging programs, social media websites, or chat rooms. The messaging application may maintain a name database that stores names that are relevant to a first user. When the first user then types or speaks a name into a user communication (e.g., an email, instant message, or voice message), the messaging application provides the first user with the names stored in the name database that match the name in the user communication. Additionally, the messaging application may use ranking data associated with each matched name to order the names according to relevance. The first user can then select the correct name (if there are multiple matched names) which prompts the messaging application to automatically send contact information to the intended recipient of the user communication either within the current user communication or in a separate communication. In this manner, the first user is able to efficiently send contact information of relevant names to a recipient. The recipient may then use the contact information to communicate with the suggested contact. | 12-27-2012 |
20130041887 | ADDING ENTRIES TO AN INDEX BASED ON USE OF THE INDEX - In an embodiment, a threshold value is calculated for a current entry in a first column of an index. If the current entry has been read a number of times by execution of an execution plan that is more than the threshold value and the current entry points to at least one row in a table and not all of the at least one row have been selected by the execution plan for inclusion in a result set as satisfying a query that the execution plan implements, then a new entry is added to the index. | 02-14-2013 |
20130060752 | USING A PARTIALLY BUILT INDEX IN A COMPUTER DATABASE SYSTEM - A partially built index is used in a computer database system. When a database index is being built, or rebuilt, the database manager keeps track of the records processed using a relative row number (RRN) to track what part of the partially built index is complete. Queries are optimized by a query optimizer associated with the database manager that uses the portion of the index that is complete with reference to the RRN. The remainder of the database table beyond the RRN can be estimated or implemented using the completed data or can be determined by searching the relevant portion of the database table. | 03-07-2013 |
20130066850 | USING A PARTIALLY BUILT INDEX IN A COMPUTER DATABASE SYSTEM - A partially built index is used in a computer database system. When a database index is being built, or rebuilt, the database manager keeps track of the records processed using a relative row number (RRN) to track what part of the partially built index is complete. Queries are optimized by a query optimizer associated with the database manager that uses the portion of the index that is complete with reference to the RRN. The remainder of the database table beyond the RRN can be estimated or implemented using the completed data or can be determined by searching the relevant portion of the database table. | 03-14-2013 |
20130097430 | ENCRYPTING DATA AND CHARACTERIZATION DATA THAT DESCRIBES VALID CONTENTS OF A COLUMN - A method, computer-readable storage medium, and computer system are provided. In an embodiment, in response to receiving a first command that specifies first data, a first cryptographic key, and a column identifier that identifies a column of rows in a database, the first data is encrypted into encrypted data using the first cryptographic key. The encrypted data is stored to a first row in the column in the database. In response to the receiving the first command, characterization data is created that specifies valid contents of the column of the rows. In response to receiving a query command that specifies a second cryptographic key and the column, the column is decrypted using the second key to create decrypted data. If the decrypted data does not satisfy the valid contents specified by the characterization data, an invalid cryptographic key action is performed. | 04-18-2013 |
20130097599 | RESUMING EXECUTION OF AN EXECUTION PLAN IN A VIRTUAL MACHINE - In an embodiment, a query implemented by a first execution plan is executed at a first virtual machine. In response to a move command that requests a move of the first virtual machine from a first computer to a second computer while the first virtual machine is executing the query implemented by the first execution plan at the first computer, an attribute of a resource used by the executing at the first virtual machine is saved to memory at the first computer and a driver source used by the executing at the first virtual machine is saved to the memory at the first computer. In response to a command that requests starting a second virtual machine at the second computer, a determination is made whether the driver source that comprises the state of the partial execution of the first execution plan exists in memory of the second computer. | 04-18-2013 |
20130159316 | DISAPPEARING INDEX FOR MORE EFFICIENT PROCESSING OF A DATABASE QUERY - A disappearing index allows faster processing of a database query without the startup time of a prior art sparse index. The disappearing index starts as a full index but is trimmed of index values that point to a row in the table that is not selected by the query. Thus the traditional index disappears as it becomes a sparse index tailored to the query. The query is able to execute faster using the now sparse index since the target database table is not accessed for duplicate values in the base table of the query. The query optimizer may determine to use a disappearing index based on estimates of the number of duplicate values in the base table. When the query is complete, the created disappearing table may be discarded or used for other queries that match the selection of the query that created the disappearing index. | 06-20-2013 |
20130159322 | CONTACT RECOMMENDATION SYSTEM FOR A USER COMMUNICATION - Techniques are described for allowing a first user to efficiently send contact information to a second user using a messaging application such as email programs, instant messaging programs, social media websites, or chat rooms. The messaging application may maintain a name database that stores names relevant to a first user. When the first user then inputs a name into a user communication (e.g., an email, instant message, or voice message), the messaging application provides the first user with the names stored in the name database that match the name in the user communication. Additionally, the messaging application may use ranking data associated with each matched name to order the names according to relevance. The first user can then select the correct name (if there are multiple matched names) which prompts the messaging application to automatically send contact information to the intended recipient of the user communication. | 06-20-2013 |
20130166536 | DATABASE QUERY GOVERNOR WITH TAILORED THRESHOLDS - A query governor intelligently sets tailored thresholds for a query accessing a computer database. The query governor preferably generates a tailored threshold for each query sent to the database for execution. The tailored threshold for the query is preferably compared to an estimated query execution time to determine whether to execute the query. The query governor uses one or more factors applied to a standard threshold to generate the tailored threshold. The factors preferably include user factors and query factors. These factors are dynamically adjusted by the query governor in an intelligent way to increase optimal use of the database. Other factors may include factors such as job priority factor, resource factor and an application factor. | 06-27-2013 |
20130263117 | ALLOCATING RESOURCES TO VIRTUAL MACHINES VIA A WEIGHTED COST RATIO - In an embodiment, a plurality of estimates of costs of executing a plurality of respective queries is received from a plurality of respective virtual machines using a plurality of respective estimated resources allocated to the plurality of respective virtual machines. A selected virtual machine of the plurality of respective virtual machines is selected with a lowest weighted cost ratio, as compared to all other of the plurality of respective virtual machines. A source virtual machine is found with a lowest current resource usage. An amount of a resource to deallocate from the source virtual machine is calculated, which further comprises estimating the amount of the resource to deallocate that does not raise the lowest current resource usage over a maximum resource threshold. The amount of the resource from the source virtual machine is deallocated. The amount of the resource is allocated to the selected virtual machine. | 10-03-2013 |
20130304723 | CHANGING THE COMPRESSION LEVEL OF QUERY PLANS - In an embodiment, a query plan is compressed to data in a cache at a high compression level if a runtime of a query that the query plan implements is greater than a high time threshold. The query plan is compressed to the data in the cache at a medium compression level if the runtime of the query that the query plan implements is less than the high time threshold and greater than a low time threshold. The query plan is stored to the data in the cache at an uncompressed level if the runtime of the query that the query plan implements is less than the low time threshold. | 11-14-2013 |
20140046928 | QUERY PLANS WITH PARAMETER MARKERS IN PLACE OF OBJECT IDENTIFIERS - In an embodiment, a first query is received that specifies a first object identifier. If a first query plan exists that implements the first query, except that the first query plan does not comprise the first object identifier and instead comprises a parameter marker in place of the first object identifier, a first query execution plan is created from the first query plan, substituting the first object identifier in the first query execution plan for the parameter marker, and the first query execution plan is executed to read a first object identified by the first object identifier. | 02-13-2014 |
20140101128 | ESTIMATING ROWS RETURNED BY RECURSIVE QUERIES USING FANOUT - In an embodiment, a recursive query is received that comprises a first select statement with a seed select statement and a second select statement with a recursive reference, wherein the recursive query further identifies at least two columns in at least one table, wherein the at least two columns have parent-child relationships represented by nodes in a graph, wherein the graph represents the organization of values in rows in the at least one table. A target recursion depth is calculated for the graph based on a fanout of the graph. In an embodiment, the target recursion depth is calculated by summing the fanout at each recursion depth of the graph multiplied by a number of nodes at each recursion depth of the graph. An estimated number of rows that the recursive query will return is estimated based on the target recursion depth. | 04-10-2014 |
20140101131 | SWAPPING EXPECTED AND CANDIDATE AFFINITIES IN A QUERY PLAN CACHE - In an embodiment, a hit percentage of an expected affinity for a first query is calculated, wherein the expected affinity comprises a first address range in a query plan cache, a hit percentage of a candidate affinity for the first query is calculated, wherein the candidate affinity comprises a second address range in a query plan cache, and if the hit percentage of the candidate affinity is greater than the hit percentage of the expected affinity by more than a threshold amount, query plans in the candidate affinity are swapped with query plans in the expected affinity. | 04-10-2014 |
20140101132 | SWAPPING EXPECTED AND CANDIDATE AFFINITIES IN A QUERY PLAN CACHE - In an embodiment, a hit percentage of an expected affinity for a first query is calculated, wherein the expected affinity comprises a first address range in a query plan cache, a hit percentage of a candidate affinity for the first query is calculated, wherein the candidate affinity comprises a second address range in a query plan cache, and if the hit percentage of the candidate affinity is greater than the hit percentage of the expected affinity by more than a threshold amount, query plans in the candidate affinity are swapped with query plans in the expected affinity. | 04-10-2014 |
20140101133 | ESTIMATING ROWS RETURNED BY RECURSIVE QUERIES USING FANOUT - In an embodiment, a recursive query is received that comprises a first select statement with a seed select statement and a second select statement with a recursive reference, wherein the recursive query further identifies at least two columns in at least one table, wherein the at least two columns have parent-child relationships represented by nodes in a graph, wherein the graph represents the organization of values in rows in the at least one table. A target recursion depth is calculated for the graph based on a fanout of the graph. In an embodiment, the target recursion depth is calculated by summing the fanout at each recursion depth of the graph multiplied by a number of nodes at each recursion depth of the graph. An estimated number of rows that the recursive query will return is estimated based on the target recursion depth. | 04-10-2014 |
20140149386 | DATABASE ROW ACCESS CONTROL - A method, system, and computer program product to create an access control bit mapping (ACBM) structure for a corresponding database table are disclosed. The ACBM structure may include a relative record number (RRN) bit map. The RRN bit map may describe the access rights for a parameter. The computer-implemented method may maintain one or more statistics describing the RRN bit map. The method may additionally provide for updating the ACBM structure. The method may also provide for using the ACBM structure to process a database query. | 05-29-2014 |
20140149387 | DATABASE ROW ACCESS CONTROL - A method, system, and computer program product to create an access control bit mapping (ACBM) structure for a corresponding database table are disclosed. The ACBM structure may include a relative record number (RRN) bit map. The RRN bit map may describe the access rights for a parameter. The computer-implemented method may maintain one or more statistics describing the RRN bit map. The method may additionally provide for updating the ACBM structure. The method may also provide for using the ACBM structure to process a database query. | 05-29-2014 |
20140172905 | PERFORMING A FUNCTION ON ROWS OF DATA DETERMINED FROM TRANSITIVE RELATIONSHIPS BETWEEN COLUMNS - In an embodiment, a request is received that specifies a function and a specified key value. Rows from all tables that are accessible from the specified key value are transitively searched, wherein the transitively searching further comprises finding values in a plurality of pairs of columns, wherein found rows that are found by the transitively searching comprise values in a respective first column of the plurality of pairs of columns that satisfy a dependency relationship with values in a respective second column of the plurality of pairs of columns. The function is executed against only the found rows. | 06-19-2014 |
20140172908 | PERFORMING A FUNCTION ON ROWS OF DATA DETERMINED FROM TRANSITIVE RELATIONSHIPS BETWEEN COLUMNS - In an embodiment, a request is received that specifies a function and a specified key value. Rows from all tables that are accessible from the specified key value are transitively searched, wherein the transitively searching further comprises finding values in a plurality of pairs of columns, wherein found rows that are found by the transitively searching comprise values in a respective first column of the plurality of pairs of columns that satisfy a dependency relationship with values in a respective second column of the plurality of pairs of columns. The function is executed against only the found rows. | 06-19-2014 |
20140173599 | SENDING TASKS BETWEEN VIRTUAL MACHINES BASED ON EXPIRATION TIMES - In an embodiment, if an estimated time to perform a task by a first virtual machine is less than or equal to an expiration time of the first virtual machine minus the current time, the task is performed by the first virtual machine. If the estimated time to perform the task by the first virtual machine is greater than the expiration time of the first virtual machine minus the current time, a selected virtual machine is selected from among a plurality of virtual machines with a smallest estimated time to perform the task and a request to perform the task is sent to the selected virtual machine. | 06-19-2014 |
20140173614 | SENDING TASKS BETWEEN VIRTUAL MACHINES BASED ON EXPIRATION TIMES - In an embodiment, if an estimated time to perform a task by a first virtual machine is less than or equal to an expiration time of the first virtual machine minus the current time, the task is performed by the first virtual machine. If the estimated time to perform the task by the first virtual machine is greater than the expiration time of the first virtual machine minus the current time, a selected virtual machine is selected from among a plurality of virtual machines with a smallest estimated time to perform the task and a request to perform the task is sent to the selected virtual machine. | 06-19-2014 |
20140201132 | STORING A KEY VALUE TO A DELETED ROW BASED ON KEY RANGE DENSITY - In an embodiment, a first key value is received. A plurality of candidate rows are found in a database table, wherein the plurality of candidate rows are deleted. For the plurality of candidate rows, a plurality of respective impacts on a plurality of respective densities of each of other key values that are stored within a first key range of the first key value are calculated. For the plurality of candidate rows, a plurality of function results of the plurality of respective impacts on the plurality of respective densities are calculated. A selected candidate row of the plurality of candidate rows with a smallest function result of the plurality of function results of the plurality of respective impacts on the plurality of respective densities is selected. The first key value is stored to the selected candidate row. | 07-17-2014 |
20140324874 | MANAGEMENT OF A DATABASE SYSTEM - A method, system, and computer program product to manage a database is disclosed. The method, system, and computer program product may include structuring the database to have a first table having an index and a second table. A first key of the first table may be related to a second key of the second table. The method, system, and computer program product may include creating an entry locator in the index. The method, system, and computer program product may include maintaining an association between the second key of the second table and the entry locator of the index. | 10-30-2014 |
20140324876 | MANAGEMENT OF A DATABASE SYSTEM - A method, system, and computer program product to manage a database is disclosed. The method, system, and computer program product may include structuring the database to have a first table having an index and a second table. A first key of the first table may be related to a second key of the second table. The method, system, and computer program product may include creating an entry locator in the index. The method, system, and computer program product may include maintaining an association between the second key of the second table and the entry locator of the index. | 10-30-2014 |
20150019583 | INTELLIGENTLY UTILIZING NON-MATCHING WEIGHTED INDEXES - System, method, and computer program product to intelligently utilize non-matching weighted objects, by determining that a sort sequence of a query does not match a sort sequence of a shared weight object of a database, modifying the query based on the sort sequence of the query, and executing the modified query to obtain a result set, wherein the result set does not include a set of rows that would have been returned using the shared weight object to process the unmodified query. | 01-15-2015 |
20150088903 | DATA ALLOCATION CONTAINERS IN A PARTITIONED TABLE OF A COMPUTER DATABASE SYSTEM FOR HOLDING DATA BASED ON USAGE - An apparatus and method utilize partitioned database tables divided into data allocation containers (DACs) where data is placed into the DACs based on usage of the data in past queries. Records that are used most often are placed together and records that are used less often are placed together to improve database performance. In preferred embodiments, a database manager determines where to place data into the DACs based on how often the data is selected by a database query using a DAC selection ratio (DSR). The database manager may determine when to perform table maintenance to move rows of data to the appropriate DACs based on a timestamp or last check date (LCD) stored in the database. | 03-26-2015 |
20150088912 | DATA ALLOCATION CONTAINERS IN A PARTITIONED TABLE OF A COMPUTER DATABASE SYSTEM FOR HOLDING DATA BASED ON USAGE - An apparatus and method utilize partitioned database tables divided into data allocation containers (DACs) where data is placed into the DACs based on usage of the data in past queries. Records that are used most often are placed together and records that are used less often are placed together to improve database performance. In preferred embodiments, a database manager determines where to place data into the DACs based on how often the data is selected by a database query using a DAC selection ratio (DSR). The database manager may determine when to perform table maintenance to move rows of data to the appropriate DACs based on a timestamp or last check date (LCD) stored in the database. | 03-26-2015 |