This chapter discusses techniques that you can use to improve the performance of SOLID Server.
Tuning SQL Statements and Applications
Tuning the SQL statements, especially in applications where complex queries are involved, is generally the most efficient means of improving the database performance.
You should tune your application before tuning the RDBMS because:
- during application design you have control over the SQL statements and data to be processed
- you can improve performance even if you are not familiar with the internal working of the RDBMS you are going to use
- if your application is not tuned well, it will not run well even on a well-tuned RDBMS
So, find out what data your application processes, what are the SQL statements used and what operations the application performs on the data.
Using SOLID Server Diagnostic Tools
SOLID Server provides the following tools that may be helpful in tuning applications:
- the SQL info facility
- the EXPLAIN PLAN statement
For additional information on how to use these tools, refer to chapter SOLID Server Diagnostic Tools.
Indexes can be used to improve the performance of queries. A query that references an indexed column in its WHERE clause can use the index. If the query selects only the indexed column, the query can read the indexed column value directly from the index, rather than from the table.
If a table has a primary key, SOLID Server orders the rows on disk in the order of the values of the primary key. Otherwise the rows are ordered using the ROWID, i.e. the rows are stored on disk in the order they are inserted into the database.
Indexes improve the performance of queries that select a small percentage of rows from a table. You should consider using indexes for queries that select less than 15% of table rows.
Full table scan
If a query does not use an index, SOLID Server must perform a full table scan to execute the query. This involves reading all rows of a table sequentially. Each row is examined to determine whether it meets the criteria of the querys WHERE clause. Finding a single row with an indexed query can be substantially faster than finding the row with a full table scan. On the other hand, a query that selects more than 15% of a tables rows may be performed faster by a full table scan than by an indexed query.
To perform a full table scan, every block in the table is read. For each block every row stored in the block is read. To perform an indexed query the rows are read in the order in which they appear in the index, regardless of which blocks contain them. If a block contains more than one selected row it may be read more than once. So, there are cases when a full table scan requires less I/O than an indexed query.
An index can be made up of more than one column. Such an index is called a concatenated index. It is recommended to use concatenated indexes when possible.
Whether or not a SQL statement uses a concatenated index is determined by the columns contained in the WHERE clause of the SQL statement. A query can use a concatenated index if it references a leading portion of the index in the WHERE clause. A leading portion of an index refers to the first column or columns specified in the CREATE INDEX statement.
Example:
create index job_sal_deptno on emp(job, sal, deptno);
This index can be used by these queries:
select * from emp where job = clerk and sal = 800 and deptno = 20;
select * from emp where sal = 1250 and job = salesman;
select job, sal from emp where job = manager ;
The following query does not contain the first column of the index in its WHERE clause and cannot use the index:
select * from emp where sal = 6000;
Choosing columns to index
The following list gives guidelines choosing columns to index:
- index columns that are used frequently in WHERE clauses
- index columns that are used frequently to join tables
- index columns that are used frequently in ORDER BY clauses
- index columns that have few of the same values or unique values in the table.
- do not index small tables (tables that use only a few blocks) because a full table scan may be faster than an indexed query
- if possible choose a primary key that orders the rows in the most appropriate order
- if only one column of the concatenated index is used frequently in WHERE clauses, place that column first in the CREATE INDEX statement
- if more than one column in concatenated index is used frequently in WHERE clauses, place the most selective column first in the CREATE INDEX statement
Your operating system may store information in
- real memory
- virtual memory
- expanded storage
- disk
Your operating system may also move information from one location to another. Depending on your operating system, this movement is called paging or swapping. Many operating systems page and swap to accommodate large amounts of information that do not fit into real memory. However, this takes time. Excessive paging or swapping can reduce the performance of your operating system and indicates that your systems total memory may not be large enough to hold everything for which you have allocated memory. You should either increase the amount of total memory or decrease the amount of database cache memory allocated.
The information used by SOLID Server is stored either in memory or on disk. Since memory access is faster than disk access, it is desirable for data requests to be satisfied by access to memory rather than access to disk.
The basic element of the database server memory management system is a pool of central memory buffers of equal size. The size of the memory buffers and their amount can be configured to meet the demands of different application environments.
Database cache uses available memory to store information that is read from the hard disk. When an application next time requests this information, the data is read from memory instead of from the hard disk. The default value of cache depends on the platform used and can be changed by changing the CacheSize parameter. Increasing the value is recommended when there are several concurrent users.
The following values can be used as a starting point:
- a dedicated server with 16 MB RAM: Cachesize 4 MB
- a dedicated server with 32 MB RAM: Cachesize 10 MB
- a dedicated server with 64 MB RAM: Cachesize 30 MB
NOTE. You should increase the value of Cachesize very carefully. Too large a value leads to very poor performance.
Tuning I/O
The performance of many software systems is inherently limited by disk I/O. Often CPU activity must be suspended while I/O activity completes.
Distributing I/O
Disk contention occurs when multiple processes try to access the same disk simultaneously. To avoid this, move files from heavily accessed disks to less active disks until they all have roughly the same amount of I/O.
Follow these guidelines:
- use a separate disk for log files
- divide your database into several files and place each of these database files on a separate disk
- consider using a separate disk for the external sorter
SOLID Server does all sorting by default in memory. The amount of memory used for sorting is determined by the parameter SORTARRAYSIZE in the [SQL] section. If the amount of data to be sorted does not fit into the allocated memory, you may want to increase the value of the parameter SORTARRAYSIZE. If there is not enough memory to increase the value of SORTARRAYSIZE you should activate external sort that stores intermediate information to disk.
The external disk sort is activated by adding the following section and parameters in the configuration file solid.ini:
[sorter]
TmpDir_1 = c:\tmp
Additional sort directories are added with similar definitions:
[sorter]
TmpDir_1 = c:\tmp
TmpDir_2 = d:\tmp
TmpDir_3 = e:\tmp
Tuning Checkpoints
Checkpoints affect:
- recovery time performance
- runtime performance
Frequent checkpoints can reduce the recovery time in the event of a system failure. If the checkpoint interval is small, then relatively few changes to the database are made between checkpoints and relatively few changes must be recovered.
Checkpoints cause SOLID Server to perform I/O, so they momentarily reduce the runtime performance. This overhead is usually small.
Copyright © 1992-1997 Solid Information Technology Ltd All rights reserved.