The new Transbase® version 6.9 is now available. It provides new functional features like dataspaces, SQL extensions, replication (in particular in combination with Transbase® CD) as well as performance improvements, especially for multi-core CPUs.
A Transbase® master database can be replicated onto several slave databases which are solely read-only and can be used either as hot standby or for dynamic load balancing within a so-called database grid. A single process tbrepl controls all aspects of replication, both on master and on slave side.
For easier operation behind firewalls, Transbase can be configured to use (two) static TCP/IP ports, only. Former versions used dynamic ports for the communication between application and database server instead.
Transbase CD has been significantly extended for a concept of generation deltas. Multiple updates on a Transbase® CD database can be packed into a generation delta. In order to distribute such deltas online, it is highly compressed. Upon receiving such delta, a client database can be updated in a very robust manner requiring few or none CPU resources depending on whether transfer volume or processing time shall be minimized.
Dataspaces have been designed and implemented in the Transbase kernel to reduce fragmentation of pages in fast growing databases and to better control space allocation within disk files.
The new WITH clause allows for the (temporary) definition of intermediate query results which can be reused in a subsequent query.
A new datatype CLOB is provided to store unlimited CHARACTER based data, much like the BLOB datatype. The main distinction is that CLOB is restricted to STRING data; in particular, CLOB columns are converted automatically to and from database code page and can be fulltext indexed.
Parallel query execution has been improved once more. The concept of dynamically allocated threads has been extended and improved. One of the major changes is that IO relevant nodes now are being parallelized. Thus a significant gain of performance is achieved, especially on RAID based IO systems that provide increased parallel access.
To further increase throughput in parallel database operation, the global database cache has been partitioned into up to 128 so-called cache partitions. Only a single cache partition must be locked exclusively to fix and unfix a page in memory. Therefore, up to 128 threads can work in parallel on different cache partitions, thereby effectively eliminating the performance bottleneck observed with a single large cache partition.
Further Information:
