Abstract: The present disclosure provides more efficient techniques for removing a host from a multi-host database system. An instruction to remove a host system may be received. In response, a determination of whether the first host system does or does not store any source tables is made based on a host-type identifier for the host system. This determination may not require obtaining landscape information for each of the hosts in the database system. If the host system stores replica tables and does not store source tables, those replica tables may be dropped based on the determination that the first host system does not store any source tables. As such, in cases where table redistribution is not needed the landscape information is not obtained, thereby making the host removal process more efficient.

Abstract: A two phase move technique for moving groups of tables may reduce cross-host communication and length of table locks. A group including a first table and a second table may be moved to the destination host system. This is done by creating a third table replicating the first table and creating a fourth table replicating the second table on the destination host, and replicas of other tables in the group. The tables in the group are not locked against modifications during the creation of the replica tables. After the creation of the replicas, roles of the original tables and the created tables are switched such that the original tables are set to the replica role and the created tables stored on the destination are set to the source role. The original tables are dropped after the switching of the roles.

Abstract: A node type of a plurality of distributed nodes to which a table to be added to a distributed database should be assigned can be identified by applying a set of placement rules defined for the table. The set of placement rules can also be applied to determine whether the table should be partitioned into more than one partition. A table group name associated with the table can be obtained and used in conjunction with the node type and determination of whether to partition the table to store the table in the distributed database on at least one node of the plurality of nodes as one or more partitions.

Abstract: Described herein is a system and method for initiating a bulk insert in a distributed database. The system described herein provides for a client to identify target index servers of the data records by examining the data records. The system identifies a partition criterion of the target index servers and partitions the data records based on a partition criterion, into subsets of data records. The system builds buckets including the subsets of data records that correspond to a partition. The system inserts each bucket including the subset of the data corresponding to a specific partition to the respective target index server where the specific partition is physically located and inserts the subset of data records in the table locally. The system inserts each bucket in each respective target index server in parallel.

Abstract: A node type of a plurality of distributed nodes to which a table to be added to a distributed database should be assigned can be identified by applying a set of placement rules defined for the table. The set of placement rules can also be applied to determine whether the table should be partitioned into more than one partition. A table group name associated with the table can be obtained and used in conjunction with the node type and determination of whether to partition the table to store the table in the distributed database on at least one node of the plurality of nodes as one or more partitions.

Abstract: Described herein is a system and method for initiating a bulk insert in a distributed database. The system described herein provides for a client to identify target index servers of the data records by examining the data records. The system identifies a partition criterion of the target index servers and partitions the data records based on a partition criterion, into subsets of data records. The system builds buckets including the subsets of data records that correspond to a partition. The system inserts each bucket including the subset of the data corresponding to a specific partition to the respective target index server where the specific partition is physically located and inserts the subset of data records in the table locally. The system inserts each bucket in each respective target index server in parallel.

Abstract: A node type of a plurality of distributed nodes to which a table to be added to a distributed database should be assigned can be identified by applying a set of placement rules defined for the table. The set of placement rules can also be applied to determine whether the table should be partitioned into more than one partition. A table group name associated with the table can be obtained and used in conjunction with the node type and determination of whether to partition the table to store the table in the distributed database on at least one node of the plurality of nodes as one or more partitions.

Abstract: In one respect, there is provided a method. The method can include identifying, based on a plurality of queries executed at a distributed database, a disjoint table set. The identifying of the disjoint table set can include: identifying a first table used in executing a first query; identifying a second query also using the first table used in executing the first query; identifying a second table used in executing the second query but not in executing the first query; and including, in the disjoint table set, the first table and the second table. The method can further include allocating, based at least on the first disjoint table set, a storage and/or management of the first disjoint table set such that the first disjoint table set is stored at and/or managed by at least one node in the distributed database. Related systems and articles of manufacture are also disclosed.

Abstract: In one respect, there is provided a method. The method can include identifying, based on a plurality of queries executed at a distributed database, a disjoint table set. The identifying of the disjoint table set can include: identifying a first table that is used in executing a first query; identifying a second query that also uses the first table used in executing the first query; identifying a second table that is used in executing the second query but not in executing the first query; and including, in the disjoint table set, the first table and the second table. The method can further include allocating, based on the disjoint table set, a storage and/or management of the disjoint table set such that subsets of the disjoint table set are stored at and/or managed by different nodes in the distributed database system. Related methods and articles of manufacture are also disclosed.

Abstract: A node type of a plurality of distributed nodes to which a table to be added to a distributed database should be assigned can be identified by applying a set of placement rules defined for the table. The set of placement rules can also be applied to determine whether the table should be partitioned into more than one partition. A table group name associated with the table can be obtained and used in conjunction with the node type and determination of whether to partition the table to store the table in the distributed database on at least one node of the plurality of nodes as one or more partitions.

Abstract: A node type of a plurality of distributed nodes to which a table to be added to a distributed database should be assigned can be identified by applying a set of placement rules defined for the table. The set of placement rules can also be applied to determine whether the table should be partitioned into more than one partition. A table group name associated with the table can be obtained and used in conjunction with the node type and determination of whether to partition the table to store the table in the distributed database on at least one node of the plurality of nodes as one or more partitions.

Abstract: In one respect, there is provided a method. The method can include identifying, based on a plurality of queries executed at a distributed database, a disjoint table set. The identifying of the disjoint table set can include: identifying a first table that is used in executing a first query; identifying a second query that also uses the first table used in executing the first query; identifying a second table that is used in executing the second query but not in executing the first query; and including, in the disjoint table set, the first table and the second table. The method can further include allocating, based on the disjoint table set, a storage and/or management of the disjoint table set such that subsets of the disjoint table set are stored at and/or managed by different nodes in the distributed database system. Related methods and articles of manufacture are also disclosed.

Abstract: In one respect, there is provided a method. The method can include identifying, based on a plurality of queries executed at a distributed database, a disjoint table set. The identifying of the disjoint table set can include: identifying a first table used in executing a first query; identifying a second query also using the first table used in executing the first query; identifying a second table used in executing the second query but not in executing the first query; and including, in the disjoint table set, the first table and the second table. The method can further include allocating, based at least on the first disjoint table set, a storage and/or management of the first disjoint table set such that the first disjoint table set is stored at and/or managed by at least one node in the distributed database. Related systems and articles of manufacture are also disclosed.

Abstract: 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.

Abstract: A node type of a plurality of distributed nodes to which a table to be added to a distributed database should be assigned can be identified by applying a set of placement rules defined for the table. The set of placement rules can also be applied to determine whether the table should be partitioned into more than one partition. A table group name associated with the table can be obtained and used in conjunction with the node type and determination of whether to partition the table to store the table in the distributed database on at least one node of the plurality of nodes as one or more partitions.

Abstract: 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.

Abstract: A node type of a plurality of distributed nodes to which a table to be added to a distributed database should be assigned can be identified by applying a set of placement rules defined for the table. The set of placement rules can also be applied to determine whether the table should be partitioned into more than one partition. A table group name associated with the table can be obtained and used in conjunction with the node type and determination of whether to partition the table to store the table in the distributed database on at least one node of the plurality of nodes as one or more partitions.

Abstract: A node type of a plurality of distributed nodes to which a table to be added to a distributed database should be assigned can be identified by applying a set of placement rules defined for the table. The set of placement rules can also be applied to determine whether the table should be partitioned into more than one partition. A table group name associated with the table can be obtained and used in conjunction with the node type and determination of whether to partition the table to store the table in the distributed database on at least one node of the plurality of nodes as one or more partitions.

Abstract: 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.

Abstract: 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.