Trifox, Inc. -- Database Access Experts

VORTEXaccelerator

[*] Introduction
[*] More Reading
[*] Get Evaluation

Introduction

By transparently maintaining open cursors, VORTEXaccelerator eliminates the need to create multiple cursors, thereby reducing the amount of work the database kernel has to do to exercise each SQL statement. By caching all cursors into shared memory, accelerator saves large amounts of memory for each application. The efficient use of resources increases the total number of users that can interact with the database and the performance gains are scalable. Without new hardware, customers are able to connect more users and complete transactions faster thereby elimininating the need for upgrades that application enhancements often require.

VORTEXaccelerator, the transaction processing monitor for multi-user applications, dramatically increases the number of users who can concurrently log into a specific SQL production application -- up to 10 times the previous number of users. Instead of performance degredation, too, VORTEXaccelerator improves the response time.

VORTEXaccelerator is completely transparent to both the developer and end user. Any application attached to the VORTEXserver, Trifox's virtual database interface, can take advantage of the accelerator.

VORTEXaccelerator achieves these performance improvements solely by managing database resources more effectively. It does not require additional programming or hardware.

Cursor Management: Traditional Approach

Each client creates as many cursors as it needs.

Traditionally, a database management system translates each SQL statement it encounters into an internal control block called a cursor. Each cursor can take more than 10K of non-sharable memory. Since most production systems have several users running the same applicaiton concurrently, they can generate many identical SQL statements, thus creating many identical cursors. In addition, each new user further multiplies the number of open cursors. For example, the SQL statement

SELECT * FROM STAFF WHERE DEPT=&dept

creates a new cursor whenever it is encountered, each time binding a different &dept variable to the cursor.

This approach is very expensive in both CPU time and memory consumption. Creating a new cursor involves parsing the SQL statement, verifying that the requested columns and tables exist, checking the user's authorization, and creating an access path to the data. In addition, the proliferation of these cursors in local memory is a major factor limiting the number of users who can run concurrently.

Cursor Management: VORTEXaccelerator

VORTEXaccelerator manages these resources more efficiently by reusing cursors whenever possible. This reuse eliminates much of the database system overhead. More significantly, placing cursors in shared memory frees up significant local memory, thus allowing many more users to run concurrently. As the hardware platform becomes more powerful, the performance improvement scales as well.

Compatibility

VORTEXaccelerator requires VORTEXserver.