Sap Se

Sap Ag

Sap Global IP Group, Sap Ag

Lars Fricke

Christian Bensberg

Daniel Baeumges

Norman May

Martin Heidel

Andreas Tonder

Juchang Lee

Franz Faerber

Wolfgang Lehner

Wolfgang Stephan

Thomas Peh

Guido Moerkotte

Edward-Robert Tyercha

Sangyong Hwang

Joern Schmidt

Florian Wolf

Holger Bischoff

Axel Hertzschuch

Steffen Geissinger

Thorsten Glebe

Michael Muehle

Oliver Horn

Roland Sedler

Hans-Joerg Leu

Johannes Beigel

Emanuel Ziegler

Christian Bartholomä

Michael Mühle

Hans-Jörg Leu

Volker Diesel

Christian Hensberg

A system includes determination of a plurality of queries of a workload, determination of a data source comprising a plurality of data rows, and determination of a sample data source based on a cardinality of each of the plurality of queries with respect to the data source and an estimated cardinality of each of the plurality of queries with respect to the data source, wherein the estimated cardinality of a query with respect to the data source is determined based on the sample data source.

Workload-based sampling

A system includes determination of a query on a table, the query including a first predicate and a second predicate, determination of a sample of the table, the sample comprising a plurality of tuples of the table, determination of a first conditional probability of selecting a tuple of the sample satisfying the first predicate and the second predicate, determination of a second conditional probability of selecting a tuple of the sample satisfying the first predicate and not satisfying the second predicate, adjustment of the first conditional probability based on the second conditional probability, a number of tuples of the sample satisfying the second predicate, a number of tuples of the sample not satisfying the second predicate, and a number of tuples of the sample satisfying the first predicate and not satisfying the second predicate, and determination of a selectivity of the query on the table based on the first adjusted conditional probability.

Selectivity estimation using non-qualifying tuples

A method, a system, and a computer program product for analysis of query filtering mechanisms for table fragments. A query plan for execution of a query is generated. The query requires access to at least one table stored in a database system. The query includes one or more filter predicates. The table is partitioned into a plurality of fragments. A determination whether a fragment in the table is compressed and whether the fragment is associated with an index is made. A filter predicate is selected for processing the fragment. For the selected filter predicate, a filter evaluation of the selected filter predicate for the fragment is determined. The filter evaluation of the selected predicate is executed for the fragment.

Filter evaluation for table fragments

A first store and a second store can be configured to store a first partition of a table of a database and a second partition of the table of the database, respectively. A database management system can be configured to at least update at least a first portion of the first partition where the update includes an update to a first primary key column in the first partition and verify that the first primary key column is unique across the first partition and the second partition. A first row having a first primary key value of the first primary key column from the first partition can be deleted, when the first primary key value in the first partition conflicts with a second primary key value of a second primary key column in the second partition.

Synchronized updates across multiple database partitions

An update to a partitioning column for a partitioned table in a database can be performed by handling rows for which the update will not require moving to a different partition separately (e.g. 'locally') for each partition followed by re-inserting those rows that will require moving to a different partition and deleting them from the original partition. The re-inserted rows are directed to a correct partition by application of the partitioning criteria for the table. Methods, articles, and systems are described.

Updating a partitioning column

A system includes a database having one or more tables having multiple partitions. The database includes memory modules to store the multiple partitions, a query processor, a data manipulation language (DML) processor configured to process operations to manipulate data in one or more of the partitions and a statistics module. For each partition, the statistics module maintains a partition profile and stores the partition profile in a statistics cache. The partition profile includes at least a first interval of data range values per column for one or more columns. The statistics module updates at least the first interval of a partition profile for a partition with new data range values responsive to the DML processor processing an operation to manipulate data in the partition. The database includes a partition pruning module that is configured to include partitions responsive to a received query based on the partition profile.

Using statistics for database partition pruning on correlated columns

A dynamic split node defined within a calculation model can receive data being operated on by a calculation plan generated based on the calculation model. A partition specification can be applied to one or more reference columns in a table containing at least some of the received data. The applying can cause the table to be split such that a plurality of records in the table are partitioned according to the partition specification. A separate processing path can be set for each partition, and execution of the calculation plan can continue using the separate processing paths, each of which can be assigned to a processing node of a plurality of available processing nodes.

Split processing paths for a database calculation engine

Partitioning of a source table of a database to a target table is initiated. Thereafter, a replay table is generated that is populated with triggers for database operations performed on the source table for subsequent replay for the target partitions. Data is later moved (e.g., asynchronously moved, etc.) from the source table to the target table. The database operations are replayed on the target table T subsequent to the moving of the data using the replay table. In addition, the source table is dropped when all of the data has been moved to the target table and there are no operations requiring replay. Related apparatus, systems, techniques and articles are also described.

Database table re-partitioning using trigger-based capture and replay

Partitioning of source partitions of a table of a database to target partitions is initiated. Thereafter, a transition partition specification is specified that identifies the source partitions and the target partitions. Data is then moved (e.g., asynchronously moved, etc.) from the source partitions to the target partitions. Concurrently with the moving of the data, operates are handled using the transition partition specification. Subsequently, the source partitions are dropped when all of the data has been moved to the target partitions and there are no open transactions accessing the source partitions. Related apparatus, systems, techniques and articles are also described.

Database table re-partitioning using two active partition specifications

A table creation request pertaining to a table in a database maintained on a multi-node data partitioning landscape that comprises a plurality of processing nodes can specify a number of partitions to be generated. At run time, a currently available number of processing nodes in the multi-node data partitioning landscape can be queried, and this currently available number of processing nodes can be compared with the specified number of partitions to be generated for the created table. The table can be generated with the specified number of partitions such that the generated partitions are located across the plurality of partitions according to a load balancing approach if the number of processing nodes equals the number of partitions to be generated or according to other information in the table request if the number of processing nodes does not equal the specified number of partitions.

Table creation for partitioned tables

Tables in a distributed database can require redistribution, for example to provide improved collocation of tables or table partitions that require joining at a node of multiple nodes across which the distributed database is distributed. Based at least in part on a set of table redistribution parameters, a table redistribution plan can be generated to include redistribution of a table from a first node to a second node. The set of table redistribution parameters can include a grouping parameter indicating at least one other table with which the table should be collocated. The table redistribution plan can be executed to cause the moving of the table from the first node to the second node.

Table redistribution in distributed databases

A recipient node of a multi-node data partitioning landscape can receive, directly from a requesting machine without being handled by a master node, a first data request related to a table. A target node of a plurality of processing nodes can be identified to handle the data request. The determining can include the recipient node applying partitioning information to determine a target data partition of the plurality of data partitions to which the data request should be directed and mapping information associating each data partition of the plurality of data partitions with an assigned node of the plurality of processing nodes. The recipient node can redirect the data request to the target node so that the target node can act on the target data partition in response to the data request.

Independent table nodes in parallelized database environments

An estimation algorithm can generate a uniqueness metric representative of data in a database table column that is split across a plurality of data partitions. The column can be classified as categorical if the uniqueness metric is below a threshold and as non-categorical if the uniqueness metric is above the threshold. A first estimation factor can be assigned to the column if the column is classified as categorical or a larger second estimation factor can be assigned if the column is non-categorical. A cost estimate for system resources required to perform a database operation on the database table can be calculated. The cost estimate can include an estimated total number of distinct values in the column across all of the plurality of data partitions determined using the assigned first estimation factor or second estimation factor and a number of rows in the table as inputs to an estimation function.

Unique value calculation in partitioned table

Data replication in a database includes identifying a source database system. The source database includes a main index file and a delta log file. To create a replica, one or more symbolic links to the source database system are generated. The symbolic links identify a path to a physical location of the source database. A replica of the source database is generated based on the symbolic links. The replica includes a copy of the main index file and delta log file. Information associated with the replica and the symbolic links is stored in a recovery log. Replica are provided transparently to most database engine components by re-using partitioning infrastructure. Components 'see' replica as tables with a single partition; that partition is a local replica.

Replication mechanisms for database environments

A computer-implemented system and method for performing distinct operations on multiple tables of shared memory of parallel computing environments are disclosed. A distinct operation is executed on each table of a plurality of tables, each distinct operation eliminating duplicate data from each table, the executing creating a hierarchy of table pairs and distinct results, the distinct results comprising a reduced row set for each table. Duplicates on each reduced row set are detected to complete the distinct operation on the plurality of tables.

Growing community of inventors

Karlsruhe, Germany

Lars Fricke