Abstract: A respective volatility attribute associated with each of one or more tables of a computerized database is used in any of various aspects to (a) determine how table data is stored in a physical storage device; (b) regulate the use of a materialized query table using database table data; and/or (c) influence circumstances under which indexes are created or advised by database analytic software. Various optional additional uses of a volatility attribute to manage a database are disclosed. Preferably, database parameters are automatically monitored over time and database table volatility state is automatically determined and periodically adjusted.

Abstract: A query is received. Based on statistics for a database, a first query access plan is generated for executing the query on the database. A first result set for the query is obtained by implementing the first query access plan on the database. Based on at least one trend in the statistics, a target time after which implementing the first query access plan will fail a set of criteria is forecasted. In response to the forecasting and based on the statistics, a replacement query access plan is generated prior to the target time. After the target time, a second result set for the query is obtained by implementing the replacement query access plan rather than the first query access plan.

Abstract: Disclosed aspects relate to query hint learning in a database management system. A hint in a first query is detected by the database management system. The first query has a first signature. A second query is received by the database management system. The second query has a second signature. A determination is made by the database management system that the second signature correlates with the first signature. A query plan is established by the database management system. The query plan is based on the second query and uses the hint in the first query. In response to receiving the second query, the database management system processes the query plan.

Abstract: Disclosed aspects relate to query hint learning in a database management system. A hint in a first query is detected by the database management system. The first query has a first signature. A second query is received by the database management system. The second query has a second signature. A determination is made by the database management system that the second signature correlates with the first signature. A query plan is established by the database management system. The query plan is based on the second query and uses the hint in the first query. In response to receiving the second query, the database management system processes the query plan.

Abstract: Disclosed aspects relate to query hint management for a database management system. With respect to a hint for a query, a set of hint profile data is established. The database management system detects a triggering event. Based on the set of hint profile data, the database management system determines to perform a hint action in response to the triggering event. Performance of the hint action is initiated.

Abstract: A database table is monitored to automatically determine its volatility, and at least one volatility attribute expressing volatility state is saved. The volatility attribute is used to manage the database, e.g., to determine an optimum query execution strategy for a query involving data in the table, and/or for determining whether to re-optimize a previously saved query execution strategy and/or for managing storage and retrieval of table data. Preferably, parameters of the database table are captured at regular sampling intervals and a figure of merit representing volatility is computed from the parameter values. Preferably, the database supports the SQL database language, and the volatility attribute is or includes the SQL VOLATILE attribute. In an additional embodiment, the database manager may express volatility of a database table as a value within a range.

Abstract: Methods to perform an operation comprising upon determining that a received query requests values of sensitive data stored in a secure database table of a database, computing a security score for the received query based on a determined specificity of a selection predicate of the received query, and upon determining that the security score exceeds a security threshold, performing a predefined operation to restrict access to the requested values of the sensitive data.

Abstract: A database table is monitored to automatically determine its volatility, and at least one volatility attribute expressing volatility state is saved. The volatility attribute is used to manage the database, e.g., to determine an optimum query execution strategy for a query involving data in the table, and/or for determining whether to re-optimize a previously saved query execution strategy and/or for managing storage and retrieval of table data. Preferably, parameters of the database table are captured at regular sampling intervals and a figure of merit representing volatility is computed from the parameter values. Preferably, the database supports the SQL database language, and the volatility attribute is or includes the SQL VOLATILE attribute. In an additional embodiment, the database manager may express volatility of a database table as a value within a range.

Abstract: A first database management system (DBMS) running on first computer having a first set of computing resources determines that with respect to the first set of computing resources a first query access plan for executing a query satisfies a set of query optimization criteria. A determination is then made that with respect to a second set of computing resources the first query access plan fails a set of preliminary criteria. In response to this failure determination, a second query access plan for executing the query is generated. Prior to having a second DBMS running on a second computer having the second set of computing resources receive a request to execute the query, a determination is made that with respect to the second set of computing resources the second query access plan satisfies the set query optimization criteria.

Abstract: A first database management system (DBMS) running on first computer having a first set of computing resources determines that with respect to the first set of computing resources a first query access plan for executing a query satisfies a set of query optimization criteria. A determination is then made that with respect to a second set of computing resources the first query access plan fails a set of preliminary criteria. In response to this failure determination, a second query access plan for executing the query is generated. Prior to having a second DBMS running on a second computer having the second set of computing resources receive a request to execute the query, a determination is made that with respect to the second set of computing resources the second query access plan satisfies the set query optimization criteria.

Abstract: A respective volatility attribute associated with each of one or more tables of a computerized database is used to adjust an extension file size value associated with a database table file space. Various optional additional uses of a volatility attribute to manage a database are disclosed. Preferably, database parameters are automatically monitored over time and database table volatility state is automatically determined and periodically adjusted.

Abstract: A computer-implemented method for reusing deleted database records includes, receiving, by a database manager executing within a computing device, a first query request to insert, into a database table, a first set of database records. The database manager identifies a first set of entries within a journal log bundle. The database manager also determines, in response to identifying a first set of entries, that there is a third set of deleted database records located on a same page as a second set of database records. The database manager also, in response to determining that there is a third set of deleted database records located on a same page as the second set of database records, inserts into the database table the first set of database records using the third set of deleted database records.

Abstract: A respective volatility attribute associated with each of one or more tables of a computerized database is used to adjust an extension file size value associated with a database table file space. Various optional additional uses of a volatility attribute to manage a database are disclosed. Preferably, database parameters are automatically monitored over time and database table volatility state is automatically determined and periodically adjusted.

Abstract: A computer-implemented method for determining a query execution plan based on transaction state may include determining that a first set of database values in a database table are in a committed transaction state and that a second set of database values in the database table are in an uncommitted transaction state. In response to the determining, the first set of database values may have a first set of statistics generated and the second set of database values may have a second set of statistics generated. The first and second set of statistics may be for use in determining a query execution plan.

Abstract: Disclosed aspects relate to query hint management for a database management system. With respect to a hint for a query, a set of hint profile data is established. The database management system detects a triggering event. Based on the set of hint profile data, the database management system determines to perform a hint action in response to the triggering event. Performance of the hint action is initiated.

Abstract: Disclosed aspects relate to transforming a user-defined table function (UDTF) to a derived table in a database management system (DBMS). It may be detected by the DBMS that a query indicates the UDTF. A derived table may be constructed from the UDTF. The derived table may be derived from a set of statements of the UDTF. The derived table may be introduced to the query to fulfill the UDTF. A query plan may be generated for the query by the DBMS. The query plan may be generated in response to introducing the derived table in the query.

Abstract: Disclosed aspects relate to transforming a user-defined table function (UDTF) to a derived table in a database management system (DBMS). It may be detected by the DBMS that a query indicates the UDTF. A derived table may be constructed from the UDTF. The derived table may be derived from a set of statements of the UDTF. The derived table may be introduced to the query to fulfill the UDTF. A query plan may be generated for the query by the DBMS. The query plan may be generated in response to introducing the derived table in the query.

Abstract: A computer-implemented method for determining a query execution plan based on transaction state may include determining that a first set of database values in a database table are in a committed transaction state and that a second set of database values in the database table are in an uncommitted transaction state. In response to the determining, the first set of database values may have a first set of statistics generated and the second set of database values may have a second set of statistics generated. The first and second set of statistics may be for use in determining a query execution plan.

Abstract: A query is received. Based on statistics for a database, a first query access plan is generated for executing the query on the database. A first result set for the query is obtained by implementing the first query access plan on the database. Based on at least one trend in the statistics, a target time after which implementing the first query access plan will fail a set of criteria is forecasted. In response to the forecasting and based on the statistics, a replacement query access plan is generated prior to the target time. After the target time, a second result set for the query is obtained by implementing the replacement query access plan rather than the first query access plan.

Abstract: A method for managing a database is disclosed. Managing the database includes managing a table of the database, the table having a set of fields including a first field in a first row of the table. Managing the table includes selecting, in the first field, a first input value configured to identify a first dynamic data function utilized to determine a first output value for the first field. Managing the table includes determining the first output value for the first field using the first dynamic data function. Managing the table includes returning (for a read request) the first output value for the first field.