Home
AdministeringIn addition to administering the database server, you can tune performance, replicate data, and archive data.
System administrationThese topics contain concepts, procedures, and reference information for database and database server administrators to use for managing and tuning HCL OneDB™ database servers.
Performance GuideThe HCL OneDB™ Performance Guide describes how to configure and operate your HCL OneDB™ database server to improve overall system throughput and to improve the performance of SQL queries.
Fragmentation guidelinesOne of the most frequent causes of poor performance in relational database systems is contention for data that resides on a single I/O device. Proper fragmentation of high-use tables can significantly reduce I/O contention. These topics discuss the performance considerations that are involved when you use table fragmentation.
Improve the performance of operations that attach and detach fragmentsWhen you use ALTER FRAGMENT ATTACH and DETACH statements to add or remove a large amount of data in a very large table, you can take steps to improve the performance of the ATTACH and DETACH operations.
Improving ALTER FRAGMENT ATTACH performanceYou can take advantage of the performance optimizations for the ALTER FRAGMENT ATTACH statement if your database meets certain requirements.
Indexes on attached tablesThe database server tries to reuse the indexes on the attached tables as fragments of the resultant index. However, the corresponding index on the attached table might not exist or might not be usable due to disk-format mismatches. In these cases, it might be faster to build an index on the attached tables rather than to build the entire index on the resultant table.
Example for situation when index on table is not usableWhen the index on a table is not usable, the database server estimates the cost of building the index fragment, compares this cost to rebuilding the entire index for all fragments on the resultant table, and chooses the index build with the least cost.

Example for situation when index on table is not usable

When the index on a table is not usable, the database server estimates the cost of building the index fragment, compares this cost to rebuilding the entire index for all fragments on the resultant table, and chooses the index build with the least cost.

Suppose you create tables and indexes as in the previous section, but the index on the third table specifies a dbspace that the first table also uses. The following SQL statements show this scenario:

CREATE TABLE tb1(a int, b int) 
   FRAGMENT BY EXPRESSION
      (a >=0 AND a < 5) IN db1,
      (a >=5 AND a <10) IN db2;
CREATE INDEX idx1 ON tb1(a);
CREATE TABLE tb2 (a int, b int, check (a >=10 and a<15)) 
   IN db3; 
CREATE INDEX idx2 ON tb2(a) 
   IN db3;

CREATE TABLE tb3 (a int, b int, check (a >= 15 and a<20)) 
   IN db4;
CREATE INDEX idx3 ON tb3(a) 
   IN db2 ;

This example creates the index idx3 on table tb3 in the dbspace db2. As a result, index idx3 is not usable because index idx1 already has a fragment in the dbspace db2, and the fragmentation strategy does not allow more than one fragment to be specified in a given dbspace.

Again, the database server estimates the cost of building the index fragment for column a on the consumed table tb3 and compares this cost to rebuilding the entire index idx1 for all fragments on the resultant table. Then the database server chooses the index build with the least cost.