Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

High performance

SESAM/SQL is a powerful database server for all areas of application and is able to execute different types of tasks without the tasks interfering with each other. A distinction is made between two basic task types:

  • OLTP applications
    In OLTP applications, a large number of users access the same databases and application programs. Examples of such applications are order processing systems, reservation systems and inventory management systems. This is often referred to as “productive operation”.
    OLTP transactions normally comprise a relatively small number of read and write statements. This involves repeating a few different transactions a great number of times.
    Refer to section "Online transaction processing (OLTP)" for a more detailed treatment of OLTP.

  • End-user computing (EUC)
    End-user computing - e.g. statistical evaluations - usually involves extremely complex database queries. This often involves reading entire databases and performing complex calculations.

SESAM/SQL makes use of state-of-the-art technologies in conjunction with the transaction monitor openUTM to implement highly efficient OLTP operation with fast response times. At the same time, parallelism functions and a powerful optimizer ensure that end-user computing does not impede OLTP operation. This is an important prerequisite for the creation of client/server architectures in which, for example, PC applications (spreadsheets, word processing, etc.) initiate complex queries in order to edit or further process data. The most important technologies and functions are described below.

Multithreading

Multithreading architecture enables the SESAM/SQL Database Handler (DBH) to process jobs in parallel, thus making use of the time in which jobs wait for the completion of I/O operations. The processing of a different executable job is activated for the duration of the I/O operation. This results in a considerable increase in throughput. It also allows longrunning and complex database queries to be processed piecewise without impeding OLTP operation. The load determines the number of threads the DBH uses, i.e. not all the threads are always in use.

Multitasking

SESAM/SQL-Server is available in a standard edition for single-task operation and in an enterprise edition for multitask operation.

In a multitasking architecture, the SESAM/SQL Database Handler (DBH) can be loaded with several tasks when performance requirements are high. This allows the DBH load to be distributed to several processors in multi-processor systems.

the relocation of CPU-intensive actions.

SESAM/SQL relocates CPU-intensive activities to so-called service tasks allowing them to run in parallel to the actual DBH operation. Service tasks are available for instance for CPUintensive database administration functions and for sorting intermediate results.

Cost-based optimizer

When an application issues an SQL statement, SESAM/SQL creates an access plan. This plan describes the type and order of the individual processing steps of the SQL statement. The cost-based optimizer ensures that a particularly efficient access plan is created, in which as few system resources as possible are used (CPU time, I/O accesses, etc.).

Shared SQL

The optimized access plan is maintained in main memory and can be used by several different users. Shared SQL provides significant performance improvements, in particular for OLTP applications where specific processing steps are repeated many times.

Shared record lock

If a read access is executed on a record, this record is normally locked for other transactions. A “shared record lock”, however, makes it possible for other transactions to read this record. This reduces the number of locks and more parallel transactions can be executed. The transaction performance increases. Transaction security is not impeded in any way by this extended locking concept, since shared record locks are only possible when data is not being updated.

Data compression

SESAM/SQL automatically compresses data when it is stored. Thus reduces storage space requirements.

  • Only significant values are stored, non-significant values do not occupy any storage space.

  • The NUMERIC and DECIMAL data types are stored with their significant length only, without leading zeros.

  • The CHARACTER data type is only stored in its significant length with no trailing spaces.

Compressing the data to significant values can configure the database to cope with maximum requirements. Thus making it simple:

  • to define columns for which only a few records contain values

  • to define columns when setting up the database, even though they are not needed until subsequent applications

  • to retain column definitions even if there are now no values for them.

Because the compressed records are shorter and therefore occupy fewer storage blocks, data can be accessed more rapidly. It is also possible to keep more records in main memory, thus reducing the number of disk accesses.

The linked-in variant is designed to allow particularly efficient processing of a single application program. This involves linking the DBH permanently into the application program. The connected databases are assigned exclusively to the application program. The advantages over the independent DBH lie in the fact that the linked-in variant spends no time on communication between the application program and the DBH and expends no resources on administering locks.

The application area of SESAM/SQL-LINK lies in the processing of batch programs which access the database exclusively.

Any differences in functionality or aspects which need to be observed when using the linked-in DBH are described in the SESAM/SQL manuals at the point where the user requires this information.

SESAM/SQL-LINK is not available for SX servers.

Global storage

The performance of a database system is not influenced by the power of the processor alone. In database systems in particular, a large number of read and write accesses to disk are performed which, compared to main memory, are relatively slow. For this reason especially fast storage media were developed for the BS2000 systems. For example, global storage - a battery-buffered semiconductor storage device - provides an access time 2000 times faster than hard disks. SESAM/SQL can use global storage as a data cache thus considerably accelerating read and write access to disk. This in turn leads to a significant improvement in overall performance.

Block mode

In block mode, you can define a cursor. Block mode causes several records to be placed in a buffer the first time the FETCH NEXT statement is executed. When the FETCH statement is executed for the first time, the user is only given the first record. Each time the FETCH statement is executed again, a further record is provided from the buffer (without further task-to-task communication) until the buffer is empty. The next FETCH statement again places several records into the buffer. This block mode speeds up cursor processing considerably.

64-bit load variant of the SESAM/SQL DBH

The 64-bit load variant of the SESAM/SQL DBH is loaded automatically on all current BS2000 servers with SESAM/SQL.
This can be recognized from the DBH start message on the insert “(64-Bit VERSION)” for /390 servers and “(X86-64-VERSION)” for x86 servers.


Enhanced buffer options

The 64-bit load variant permits more powerful handling of the input/output load through a higher maximum value for the buffer for system-access data (DBH option SYSTEM-DATA-BUFFER) and for the buffer for user-access data (DBH option USER-DATA-BUFFER) , see the “Database Operation” manual.

At the same time in this case the buffers do not utilize the normal address space of the task (2 GB), which means that greater values are possible for the other options.