Abstract: Creating a relational database table that identifies at least one application as belonging to a logical group. All components that belong to the logical group are listed and a unique schema name is created for each component by combining a logical schema name of each component with a designated system name for the component. Each component co-exists in a single database instance.

Abstract: A method and software for change data capture are disclosed, in which change data is extracted from a recovery log and stored in a database object. The change data indicates what modification has been performed to a source object on the OLTP system. In some embodiments of the present invention, a database statement may be generated and executed to extract and load the change data, and the recovery log itself may be shipped from an OLTP system to a staging system.

Abstract: A method and software for change data capture is described, in which change data is extracted from a recovery log in a single pass and stored into multiple database objects, such as change tables. The change data indicates modifications that has been performed to multiple source objects that correspond to the multiple database objects. In a preferred embodiment, this can be accomplished with a single multi-table insert SQL statement.

Abstract: Creating a relational database table that identifies at least one application as belonging to a logical group. All components that belong to the logical group are listed and a unique schema name is created for each component by combining a logical schema name of each component with a designated system name for the component. Each component co-exists in a single database instance.

Abstract: Fast purging of change data from a named change data database table by: (1) partitioning the table into partitions to separate data to be retained from data to be dropped and dropping the partition holding the data to be purged; or (2) creating a temporary change data database table and inserting the change data to be retained into a temporary table, dropping the named change data table, renaming the temporary table as the named table and inserting the change data within the temporary table into the renamed change table; or (3) creating a temporary change data table and copying data above a given value from the named table into the temporary database table, truncating the named table and inserting the data from the temporary into the named table and dropping the temporary table.

Abstract: A synchronous change data capture system and methodology are described in which, for each statement of a transaction, a transaction identifier that uniquely identifies each transaction is recorded along with the change data. When the transaction is committed, the transaction identifier and a system change number for the commit is recorded in a transaction table. To identify the commit system change number for each statement in the change data, the transaction identifier in the change data is used to fetch the commit system change number from the transaction table.

Abstract: A method of change data captured is disclosed, in which modifications made to on-line transaction processing (OLTP) tables (e.g. inserts, updates, and deletes) are maintained in a database object, referred to as a change table. The change data in the change table is then made available to analysis applications in a controlled manner, such as in accordance with a publication-subscription model.

Abstract: A method and software for change data capture is described, in which change data is extracted from a recovery log in a single pass and stored into multiple database objects, such as change tables. The change data indicates modifications that has been performed to multiple source objects that correspond to the multiple database objects. In a preferred embodiment, this can be accomplished with a single multi-table insert SQL statement.

Abstract: Fast purging of change data from a named change data database table by: (1) partitioning the table into partitions to separate data to be retained from data to be dropped and dropping the partition holding the data to be purged; or (2) creating a temporary change data database table and inserting the change data to be retained into a temporary table, dropping the named change data table, renaming the temporary table as the named table and inserting the change data within the temporary table into the renamed change table; or (3) creating a temporary change data table and copying data above a given value from the named table into the temporary database table, truncating the named table and inserting the data from the temporary into the named table and dropping the temporary table.

Abstract: A synchronous change data capture system and methodology are described in which, for each statement of a transaction, a transaction identifier that uniquely identifies each transaction is recorded along with the change data. When the transaction is committed, the transaction identifier and a system change number for the commit is recorded in a transaction table. To identify the commit system change number for each statement in the change data, the transaction identifier in the change data is used to fetch the commit system change number from the transaction table.

Abstract: A method and apparatus for refreshing stale materialized views is provided. Prior to executing a query to refresh a materialized view from data in the base tables of the materialized view, the query is rewritten to refresh the materialized view from data in one or more other materialized views. To take advantage of the efficiency gained by refreshing a materialized view based on another materialized view, a refresh sequence is established based on the dependencies between materialized views in the database system. The dependencies indicate which materialized views can be refreshed from which other materialized views. When a materialized view can be refreshed based on any one of a number of eligible materialized views, the refresh sequence may additionally take into account the relative benefit associated with refreshing the materialized view with each of the eligible materialized views.

Abstract: A method and apparatus are provided for performing deferred incremental refresh of summary tables that are derived from two or more base tables. Incremental refresh is performed by assigning a hypothetical load sequence to the base tables of the summary table. For each base table that contains new data that affects the summary table, a join is performed between (1) the new data in the base table, (2) the pre-update state of base tables that follow the base table in the hypothetical load sequence, and (3) the post-update state of base tables the precede the base table in the hypothetical load sequence. The results of the join are then merged with the existing summary table to refresh the summary table. According to one aspect of the invention, efficiency is improved by performing the joins for the various base tables in parallel.

Abstract: A method and apparatus for identifying new data stored in data warehouses by storing the new data records at contiguous storage locations, and storing range data that specifies the range of the contiguous storage locations. New data is identified in the database by storing the start location and the end location of the contiguous range of data location, enabling server processes to access the new data records based on the stored range data, without needing to identify the new data records on a row-by-row basis. The arrangement for identifying new data is effective for updating existing summary information of existing data in view of the new data, for example, by generating a delta summary. The delta summary, representing summary information corresponding to the new data, can then be merged with the existing summary data to complete updating the summary data in view of the new data.