Managing Performance

The potential for improving performance depends on the type of system you run Progress on.
Some options might not be available on your hardware or operating system platform. This
chapter discusses options for managing database performance.

this chapter contains the following sections:

 Tools For Monitoring Performance

 Server Performance Factors
 CPU Utilization
 Disk I/O
 Memory Utilization
 Operating System Resources
 Database Fragmentation
 Index Use
 Virtual System Tables

Introduction To Performance Managing

The Progress Version 9 Database relies on the following system resources to perform its work:
CPU — Manipulates data and executes programs
Disks and controllers — Read and write data from database
Memory — Stores data so it can be accessed quickly while performing operations
Operating system mechanisms — Allocate and use system resources
Network — Exchanges data between client and server systems

Performance is diminished if the database cannot use these resources efficiently. Performance
bottlenecks occur when a resource performs inadequately (or is overloaded) and prevents other
resources from accomplishing work. The key to improving performance is determining which
resource is creating a bottleneck. Once you understand your resource limitation, you can take
steps to eliminate bottlenecks.
Performance management is a continual process of measuring and adjusting resource use.
Because system resources depend on each other in complex relationships, you might fix one
problem only to create another. You should measure resource use regularly and adjust as
required.
To effectively manage performance, you must have solid knowledge of your system, users, and
applications. Because system and application performance can vary greatly depending on the
configuration

The following additional factors that can affect performance:

System tuning — Make sure your system is properly tuned and has sufficient capacity to
perform its workload at the proper rate.
Other applications — Make sure other applications are not competing with the database
for system resources.

Tools For Monitoring Performance

This section describes several tools that you can use to monitor the performance of a Version 9
database. It includes information about:
PROMON utility
Virtual System Tables
NT Performance Monitor

PROMON Utility
The Progress Monitor (PROMON) utility helps you monitor database activity and performance
 1- Create database server

2- Monitor using PROMON COMMAND

Virtual System Tables

Virtual system tables (VSTs) provide 4GL and SQL-92 applications access to the same database
information that you can collect with the PROMON utility. The virtual system tables, or schema
tables, have no physical records until the database manager generates them at run time. This
enables a 4GL or SQL-92 application to retrieve information as run-time data.

NT Performance Monitor
The NT Performance Monitor is a graphical tool, supplied with Windows NT, that lets you
monitor the performance of a local or remote Windows NT workstation. The Performance
Monitor measures the performance of workstation objects like processes and memory using a
defined set of counters. The Progress Version 9 database provides a comprehensive set of
counters ranging from measurements about the number of clients running to the number of
database records read or written. These counters are derived from the PROMON utility,
Summary of Activity option, and they report on the state and performance of a particular
database. Progress database support for the native NT performance monitor does not replace the
PROMON utility; it simply provides another mechanism that system administrators can use to
monitor performance-related data.
Increasing the BI Cluster Size
The BI file is organized into clusters on disk. As the database engine writes data to the BI file,
these clusters fill up. When a cluster fills, the engine must ensure that all modified database
buffer blocks referenced by notes in that cluster are written to disk. This is known as a
checkpoint. Checkpointing reduces recovery time and lets the engine reuse BI disk space.
Raising the BI cluster size increases the interval between checkpoints.
Raising the BI cluster size can reduce the I/O overhead of writing modified database buffers to
disk. It also lets you defer writes and collect more changes before writing a block; this lets you
write multiple changes with the same write.
Larger cluster sizes generally increase performance. However, they also have significant
drawbacks:
Increased disk space usage for the BI file.
Longer crash recovery periods.
Longer checkpoint times. (Run APWs to eliminate this drawback.)

Follow these steps to change the cluster size:

Use the PROSHUT command or the PROMON Shutdown a Database option to shut down
the database.
Enter the following command:

For size, specify the new cluster size in kilobytes. The number must be a multiple of 16
in the range 16 to 262128 (16K–256MB). The default cluster size is 512K. Cluster sizes
from 512 to 16384 are common.

Increasing the Number Of BI Clusters

When you create a new database or truncate an existing database, the database engine, by
default, creates four BI clusters, each of which is 512K. As the engine fills a cluster, the cluster
is checkpointed, and the engine writes to the next cluster on the chain.
Illustrates the default BI clusters.
In some cases, the database engine cannot write to the next cluster because the next cluster
contains an active transaction. When the engine cannot use the next cluster on the chain, it
creates a new cluster and begins writing to it. While the engine creates the new cluster, no
database update activity can occur, thus impacting database performance. Figure 14–10
illustrates how BI clusters fill over time.

The BI clusters typically grow to their optimal number over time. You can calculate the current
number of BI clusters for a database by dividing the BI physical file size by the BI cluster size.
For example, a database BI file with a BI cluster size of 128K and a physical size of 91,7504
has 7 BI clusters.
Whenever the BI file is truncated, you should consider growing the number of BI clusters to its
optimal size before restarting the database, thus preventing the database engine from adding
clusters on an as-needed basis. The BI file is truncated:
Automatically by the database engine when you start after-imaging (RFUTIL AIMAGE
BEGIN)
Automatically by the database engine when you perform an index rebuild (PROUTIL
IDXBUILD)
Manually (PROUTIL TRUNCATE BI)
Follow this step to increase the number of BI clusters:
Enter the following command:

For n, specify the number of BI clusters that you want to create for the specified database.
Progress creates four BI clusters by default. If you specify a BIGROW value of 9, Progress
creates an additional 9 BI file clusters for a total of 13 clusters.

Increasing the BI Block Size

The database engine reads and writes information to the BI file in blocks. Increasing the size of
these blocks allows the engine to read and write more data at one time. This can reduce I/O rates
on disks where the BI files are located.
The default BI block size (8K) is sufficient for applications with low transaction rates. However,
if performance monitoring indicates that BI writes are a performance bottleneck and your
platform's I/O subsystem can take advantage of larger writes, increasing the BI block size might
improve performance.

Follow these steps to change the BI block size:

Use the PROSHUT command or the PROMON Shutdown a Database option to shut down
the database.
Enter the following command to change the BI block size:

For size, specify the new BI block size in kilobytes. Valid values are 0, 1, 2, 4, 8, and 16.
If you have a single AI file and after-imaging is enabled when you enter this command,
you must use the After-image Filename (-a) parameter to specify the AI filename.
You can also change the BI cluster size with this command.

Enabling Threshold Stall

Often a database administrator does not want the database to perform an emergency shutdown
when the Recovery Log Threshold limit is reached. The Threshold Stall (-bistall) startup
parameter quiets the database when the recovery log threshold is reached. Instead of an
emergency shutdown, the database stalls forward processing until the database administrator
intervenes. This provides the database administrator the options of shutting down the database,
making more disk space available, and increasing the threshold amount. A message is added to
the database log (.lg) file stating that the threshold stall is enabled.
Using PROQUIET To Adjust the BI Threshold
You can adjust the value of the threshold by providing a valid threshold value for the
PROQUIET command. The value can be increased above the current value or reduced to a value
of one cluster larger than the recovery log file size at the time the PROQUIET command is
issued.
Follow these steps to adjust the BI threshold:
Use the PROQUIET command to enable a database quiet point:

db-name is the name of the database for which you want to adjust the BI threshold.

During a database quiet processing point, all file write activity to the database is stopped.
Any processes that attempt to start a transaction while the quiet point is enabled must wait
until you disable the database quiet processing point.

2) Adjust the threshold size using the -bithreshold parameter:

db-name
Specifies the name of the database for which you want to adjust the BI threshold.
n
Specifies the new value for the threshold.

Use the PROQUIET command to disable the quiet point

Increasing the AI Block Size
As with before-imaging, the database engine reads and writes information to the AI file in
blocks. Increasing the size of AI blocks lets the engine read and write more AI data at one time.
This can reduce I/O rates on disks where the AI files are located. In general, the default AI block
size (8K) is sufficient for systems with low transaction rates. However, if performance
monitoring indicates that AI writes are a performance bottleneck and your platform’s I/O
subsystem can take advantage of larger writes, increasing the AI block size might improve
performance. A larger AI block size might also improve performance for roll-forward recovery
processing.
Follow these steps to change the AI block size:
Use the PROSHUT command or the PROMON Shutdown a Database option to shut down
the database.
If after-imaging is enabled, disable it by entering the following command:

Truncate the BI file to bring the database and BI files up to date and eliminate any need
for database recovery. To do this, enter the following command:

Typically, if you change the AI block size, you should also change the BI block size. If
you have not already, you might want to use this command to do so.

Change the AI block size by entering the following command:

For size, specify the size of the AI read and write block in kilobytes. The minimum value
allowed is the size of the database block. Valid values are 0, 1, 2, 4, 8, and 16. If you
specify 0, Progress uses the default size (8K) for your operating system platform

5 Perform a full backup of the database.

NOTE: You must perform this step because backups and AI files created before you
change the AI block size are no longer valid with the new AI block size.

Enable after-imaging by entering the following command:

Restart the database and continue processing

Monitoring Memory Utilization
Use the following PROMON options to monitor memory usage:
Activity — Shows the amount of shared memory used by the database and the number of
shared-memory segments
Shared Resources Status (an R&D option) — Shows the amount of shared memory
allocated
Shared-memory Segments Status (an R&D option) — Shows the ID number, size, and
amount used for each shared-memory segment

Database Fragmentation
Over time, as records are deleted from a database and new records are added, gaps can occur on
the disk where the data is stored. This fragmentation can cause inefficient disk space usage and
poor performance with sequential reads. You can eliminate fragmentation by dumping and
reloading the database.

Analyzing Database Fragmentation

To determine the degree of fragmentation for tables in a database, use PROUTIL with the
TABANALYS qualifier:

You can run PROUTIL with the TABANALYS qualifier while the database is in use; however,
PROUTIL generates only approximate information.

In the TABANALYS display, check the following fields:

Count — The total number of record fragments found for each table in the database.
Fragments Factor — The degree of record fragmentation for each table. If the value is
2.0 or greater, dumping and reloading will improve disk space usage and performance. If
the value is less than 1.5, dumping and reloading is unnecessary.
Scatter Factor — The degree of distance between records in the table. The optimal value
for this field varies from database to database. To determine the optimal value for your
database, run the TABANALYS qualifier on a freshly loaded database.
The following shows a sample excerpt from a PROUTIL TABANALYS display.

Analyzing Index Use

Use PROUTIL’s IDXANALYS qualifier to get information about index blocks and utilization.
To execute the IDXANALYS qualifier, enter the following command:

db-name

Specifies the name of the database.

The IDXANALYS qualifier provides:
The number of fields and levels in each index
The size of each index, in blocks and in bytes
The percent utilization within the index (that is, the degree of disk space efficiency)
A factor value that indicates whether to rebuild each index
A summary of indexes
Compacting Indexes
When space utilization of an index is reduced to 60% or less as indicated by the PROUTIL
IDXANALYS utility, use the PROUTIL IDXCOMPACT utility to perform index compaction
online. Performing index compaction increases space utilization of the index block to the
compacting percentage specified. For example:

Performing index compaction reduces the number of blocks in the B-tree and possibly the
number of B-tree levels, which improves query performance.
The index compacting utility operates in phases:
Phase 1: If the index is a unique index, the delete chain is scanned and the index blocks
are cleaned up by removing deleted entries.
Phase 2: The nonleaf levels of the B-tree are compacted starting at the root working toward
the leaf level.
Phase 3: The leaf level is compacted.

Rebuilding Indexes
Use the IDXBUILD (Index Rebuild) qualifier of the PROUTIL utility to:
Compress index blocks to minimize space usage.
Activate all deactivated indexes in the database.
Repair corrupted indexes in the database. (Index corruption is normally signaled by error
messages.)
NOTE: When you run the Index Rebuild qualifier, the database must not be in use.
To run the IDXBUILD qualifier with PROUTIL, enter the following command:

db-name
Specifies the name of the database whose indexes you want to build.
To improve performance, use the Merge Number (-TM) and Speed Sort (-TB) startup parameters.

Use the Some option to rebuild only specific indexes. Use the All option to rebuild all indexes.
After you enter a selection and you name those indexes you want to rebuild, the utility prompts
if you have enough disk space for index sorting. If you enter yes, the utility sorts the indexes
you are rebuilding, generating the indexes in order by their keys. This sorting results in a faster
index rebuild and better space use in the index blocks.
To estimate whether you have enough free space to sort the indexes or not, use the following
formulas:
If you rebuild all the indexes in your database, sorting the indexes requires up to 75 percent
of the total database size in free space.
If you rebuild an individual index, sorting that index requires as much as the following
amount of free space:
(size of one index entry) * (number of records in file) * 3
The Index Rebuild qualifier with PROUTIL rebuilds an index or set of indexes in a series of
three phases:
1. The utility scans the database file, clearing all index blocks that belong to the indexes you
are rebuilding and adding those blocks to the free block list.
2. The utility scans the database file and rebuilds all the index entries for every data record.
If you chose to sort the index, the utility writes the index entries to the sort file. Otherwise,
the utility writes the index entries to the appropriate index at this point.
3. This phase only occurs if you chose to sort the indexes. In this phase, the utility sorts the
index entries in the sort file into groups and enters those entries into their respective entries
in order, one index at a time.
The Index Rebuild qualifier accomplishes most of its work without displaying messages, unless
it encounters an error condition.

Other important points for performance improvmen that

you can perform :
1. Make sure you have the right indexes for your application.
No amount of database tuning will make up for a poorly written application so do not neglect to look
into it. But if you are in a bind, do the obvious database tuning first and then come back to the
application. The PRO of having the appropriate index allows the database to pick the right records
with the minimal amount of disk I/O. The CON of having too many indices is that ever update of the
record will require updates to those indices what chart the fields of the record which have been
updated, therefore one record update might be multiple I/O operations.

2. Stripe data extents on as many separate spindles as possible.

One disk drive can do one data transfer at a time. Two disk drives can do two transfers at a time. The
more the better and you want the IO load evenly balanced over the available drives. The most
effective way to balance the load across multiple drives is to create a stripe set that combines all the
drives into one logical drive with the data evenly spread across them. But if you lose one drive, you
lose all so you have to combine striping with mirroring to get reliability.

Another way is to create data extents that each contains a piece of the total database. For example, if
you have four drives, create 16 extents and put four on each drive. Put extent 1 on the first drive,
extent 2 on the second, extent 3 on the third, extent 4 on the fourth, extent 5 on the first, and so on.

A drawback to this "manual striping" is that as the database grows, the balance is disturbed when you
add extents.

3. Use a database block size of 8 kb.

Larger block sizes provide greater IO efficiency and more efficient use of storage. Many UNIX file
systems have a fundamental block size or page size that is 4 kb or 8 kb. You get the best
performance when the database block size matches the file system's page size or is a multiple of the
file systems page size.

On Linux 4 kb should be used if the kernel version is less than 2.6, which came out in December of
2003. In kernel versions prior to 2.6, the Linux virtual memory architecture did not allow for larger
page sizes. 8kb may be used with kernel versions 2.6 and newer.

On Windows, you should use 4 kb.

4. Set BI cluster size to 16 MB.

Larger bi cluster sizes increase the duration of checkpoints allowing more time for modified database
blocks to be written to disk in an orderly fashion by the page writers. Duration for the last 8
checkpoints are displayed in promon's Checkpoints display. If they are at least a minute long, you are
fine. Longer is ok but not needed. If they are shorter than a minute, you should increase the cluster
size.

If you have the Workgroup database, keep the cluster size small. 512 k or less will be better than
large cluster sizes because there will not be any page writers to write modified database blocks to
disk.
5. Set BI block size to 8 kb (Usually the default value).
Allows for more efficient writing of the bi, which is always done using synchronous writes. The default
BI block size (8K) is sufficient for applications with low transaction rates. However, if performance
monitoring indicates that BI writes are a performance bottleneck and your platform's I/O subsystem
can take advantage of larger writes, increasing the BI block size might improve performance.

When using OpenEdge Replication it is advisable to set the BI block size to 16 kb to keep it in sync
with the AI blocksize for improved performance of OpenEdge replication.

6. Set AI block size to the same as BI block size.

7. Set -bibufs to 25.

8. Always run the before-image writer (BIW).

The before-image writer's job is to write filled bi buffers so the server does not have to do it. This
gives the server more time to do useful work. With self-service clients, the server and the client are in
the same process, but you still want the server to do useful work.

9. If you use after-image journaling (you should, but not for performance reasons), run the
after-image writer (AIW).
The after-image writer's job is to write filled AI buffers so the server does not have to do it. This gives
the server more time to do useful work. With self-service clients, the server and the client are in the
same process, but you still want the server to do useful work.

10. Always run at least one asynchronous page writer (APW).

The asynchronous page writer's job is to write modified database blocks to disk in an orderly fashion
so the server does not have to do it and so that the modified blocks do not have to all be written to
disk at the very end of a checkpoint. Promon reports these writes as "buffers flushed" in several
places. You want that number to be less than 10 for almost every checkpoint.

11. I lied. I have more than ten.

12. Set -spin to 50,000

Finding the optimal value for spin is hard. With newish fast systems, I use the number of processors
times 20,000 as a "rule of thumb". But 50,000 is easier to remember and a good place to start. I have
seen one case where a value of 2,000,000 worked pretty well, but that is unusual.

13. Put BI extent on separate drive from data extents if possible.

You want writing to the bi extent to be as efficient as possible and no interference from other
activity. If you have many databases on the same machine, then you should put the bi extent in with
the data extents. You did stripe the data extents, didn't you. If using a RAID array there is no
separate drive unless there are multiple RAID sets on the system in which case put it on a different
RAID set on the same system.

14. Use two drives for AI extents, with extents alternating between them.
The purpose of after-image journaling is to provide for a way to recover if the drive(s) holding your
database fail. Therefore you MUST NOT store any AI extents on the same drives as the data
extents Alternating between two drives allows filled extents to be archived without slowing down
writing of the current extent. If you do not have enough drives, put all the AI extents on the same
drive. If using a RAID array there is no separate drive unless there are multiple RAID sets on the
system in which case put the AI files on a different RAID set on the same system.

15. DO NOT USE RAID 5 OR RAID 6.

RAID 5 and RAID 6 systems have improved over time and reliability has increased
dramatically. RAID 5 and 6 are great for read oriented operations.
RAID 5 and 6 can experience a degradation of performance for high volume write operations if the
volume of data being written exceeds the cache memory available to the RAID controller. The degree
of performance loss could be significant
Gus has observed that it is highly likely to experience a 45 percent performance loss in normal
operations and more when doing maintenance or recovery operations, regardless of whether RAID 5
or RAID 6 is implemented via software, or in the hardware when the RAID controller cache memory is
saturated.

16. Do not run other stuff on the database server machine.

The more stuff you run on the machine that has the database on it, the more resources you take away
from database performance. That means no print serving, file serving, mail serving, screen savers,
Microsoft Office, and so on.

17. Do not run on variable database extents.

Variable database extents take time to extend whenever database needs to write more blocks onto
disk. Use fixed database extents, which use pre-allocated space, so that database doesn't need to
lose time extending them on disk. Also, variable database extents are more likely to get very
fragmented over time, whereas fixed database extents may allocate more continuous disk space
(whenever possible).

18. Perform database dump and load.

Depending on the database structure, it is possible that over time records will get fragmented
within database extent files, especially if there are many disparate tables located in the same area.
Run database analysis to determine records' fragmentation. All large tables with Scatter Factor
greater than 2 will benefit from dump and load, or they could be moved into their own data area (with
the appropriate records-per-block factor).