In the case of large database applications, I/O behavior plays a crucial role in the performance of the application. A description of the files in which I/O bottlenecks may occur and how such bottlenecks can be eliminated is provided below.
Session Log File (SLF)
No I/O bottleneck can occur for the SLF.
Status file
No I/O bottleneck can occur for the status file.
Realms
An I/O bottleneck for realms can be eliminated by many methods:
Increase the database buffer
Increasing the database buffer reduces the number of I/Os and can thus eliminate the bottleneck. The amount of main memory available should, however, also be taken into account to ensure that the corresponding increase in the paging rate is acceptable.
It is, of course, also important that the correct database buffer (2-Kbyte, 4-Kbyte or 8-Kbyte) be increased, so you will first need to determine the appropriate database page size.
The UDS/SQL monitor can be used to check whether increasing the database buffer has reduced the number of physical I/Os.
Create a separate database buffer for a database
If particular database is critical for performance, you can create a separate database buffer for it. This will ensure that the pages of that database are not displaced by I/Os on other databases, but also means that the dedicated buffer will not be available for I/Os on other databases.
Distribute realms to different disks
If increasing the database buffer does not have the desired effect, you can distribute the realms on different disks to reduce the number of I/Os on a disk and thus eliminate the I/O bottleneck.
Use a disk cache or a solid state disk (SSD)
If the I/O bottleneck cannot be eliminated by increasing the database buffer or by distributing realms on different disks, you can use a disk cache for accelerated I/O or some other external fast storage medium for more demanding requirements.
Modify the application
In some cases, an I/O bottleneck may occur due to the inefficient sequence of database calls in an application. Updating the application from this viewpoint could reduce the number of I/Os substantially; however a detailed analysis of the application is required for this purpose.
RLOG file
Every updating transaction requires a write operation on the RLOG file. Although multiple transactions can be committed with a single I/O operation (group commit), the RLOG file could become a bottleneck in applications with several updating transactions. The following solutions are available in such cases:
Place the RLOG file on a separate disk
The RLOG file is written sequentially. You should create the RLOG file in such a manner that writing can take place as quickly as possible and without being influenced by other activities on the system.
Use a disk cache or an SSD
If the bottleneck cannot be eliminated with measure indicated above, it is advisable to use a disk cache or a fast external storage medium.
Use a global storage (GS)
If the bottleneck cannot be removed with an SSD either, the pubset on which the RLOG file is located can be buffered via a global storage. If the RLOG file is mirrored, to Availability Units of the Global Storage will be required in order the guarantee the independent redundancy of the two RLOG files.
ALOG file
The ALOG file is generally not critical for performance, since it is only written when the ALOG buffer is full.
If the ALOG file does become a bottleneck, however, it is best to place it on a disk on which no other access occurs. You should then create the ALOG file in such a manner that writing can take place as quickly as possible and without being influenced by other activities on the system.
Temporary realms
Temporary realms are generally not critical for performance.
However, if they do slow down performance, you can try increasing the 4-Kbyte system buffer (since temporary realms always have a page size of 4 Kbytes). If this does not help either, you will need to distribute the temporary realms on multiple disks.