The number of tuning parameters in Mimer SQL is, intentionally, very limited. The two most important tuning parameters in Mimer SQL are the size of the Database Cache and the number of Request threads. Both these parameters can easily be determined after only a few days run-time experience. On some UNIX platforms, the use of 'Raw Device' databanks also significantly improves performance.
The simplicity by which the Mimer SQL system can be tuned removes the need for highly skilled RDBMS experts to supervise the operations, significantly reducing the maintenance costs for Mimer SQL-based systems.
Most RDBMS require that the contents of the database have to be reloaded regularly to maintain performance, which will mean that the database is unavailable to the users and may require a high level of expertise to actually perform. A Mimer SQL table is stored in a highly optimized balanced tree structure called a B*-tree. These trees expand and contract dynamically as required, and the algorithms used during this process ensure that data is always stored in an optimal manner.
The use of B*-trees means that there is never any need to reorganize a Mimer SQL database, or any benefit to be gained by so doing, since the B*-tree structures are always kept perfectly balanced. This feature is especially important as the database size grows. Consider, for example, the implications of a re-load of several Gigabytes of data in a production environment.
By implementing the relational model with separate B*-tree structures for each table and secondary index, Mimer SQL also ensures that even when application enhancements mean that the database schema needs to be altered, this can be achieved by only altering those tables affected. Also the use of the relational model and the implementation of views means that existing application code need not be affected by underlying changes to the database schema as long as the data required by the application is still available.
Mimer SQL's use of a careful replacement protocol during the dynamic table reorganizations and of the similar protocol used when updating tables with secondary indices ensures that these structures are always kept free of inconsistencies even in the event of a system failure. The use of these protocols means that there is no need for any repair utilities to correct such inconsistencies.
In Mimer SQL, tables are created in databanks. A databank is a standard direct access file and contains an arbitrary number of tables. The use of bitmaps to control free space means that there is minimal initialization required when a databank is expanded. Mimer SQL databanks therefore expand dynamically when required as long as the Operating System allows this, which usually means as long as free disk space is available.
The fact that Mimer SQL databanks are standard OS files allows them to be moved using standard OS commands. Moving databank files may be necessary to make the best use of available disk space, or to balance disk loads. In addition, the databank files may be backed up using standard OS utilities.
The use of standard OS files also allows Operating System facilities such as disk striping, solid state disk devices, RAID systems, and networked drives to be used where these are available without requiring any special facilities to be used within Mimer SQL.
The Concurrency Control techniques utilized by Mimer SQL for transaction handling also eliminate the requirement for any DBA intervention to resolve deadlocks or other lock related problems such as those caused when a client fails.
Upright Database Technology AB
Voice: +46 18 780 92 00
Fax: +46 18 780 92 40