The RLOG file is required for
rolling back open transactions during operation or for a warm start
rolling forward completed transactions for a warm start
The RLOG file therefore contains the before-images and after-images for each update. The RLOG file is created by the DBH at the start of a session. It consists of two physical files with the names
confname.RLOG.time-stamp.1
confname.RLOG.time-stamp.2
You can use DBH load parameters or DAL commands to determine the disks on which you want the RLOG file to be created. For recovery reasons it is advisable to maintain duplicate RLOG files. You can either use DRV for this purpose or have UDS/SQL maintain a duplicate RLOG file. In this case, the DBH creates two more files with the following names:
confname.RLOG.time-stamp.1.SAVE
confname.RLOG.time-stamp.2.SAVE
The DBH deletes the RLOG file once the associated session has been terminated without errors. Following a crash, the associated RLOG file is not deleted until a warm start has been performed for all databases affected by the crash.
The DBH protects the RLOG file with an internal password.
Selecting the volume for the RLOG file
When selecting the volumes for the RLOG file, it is important to take recovery and performance aspects into account.
Security
For security reasons the RLOG file should not be placed on the same disks as database files.
When the RLOG file is maintained in duplicate by UDS/SQL, a check is made to see whether you have specified two independent volumes as the storage location. If you have not, configuration of the RLOG files is rejected.
In the case of RLOG files which have been created in duplicate on SF pubsets which are buffered in the global storage, a check is also made to see whether they are buffered in different units. If they are not, configuration of the RLOG files is rejected.
The check cannot be performed by UDS/SQL for RLOG files on SM pubsets because the relevant information cannot be ascertained for SM pubsets. UDS/SQL therefore can no longer completely prevent the existence of "single points of failure".
As the RLOG files are extremely important for ensuring the consistency of the data during ongoing operation, each RLOG file is protected by a password of its own. Generally the DBH deletes RLOG files when they are no longer required. If in exceptional circumstances an RLOG file has to be deleted for other reasons, you can issue the password using the RLOGPASS utility routine in the UDS-SQL-T delivery unit. This password is designed not only to protect the contents of the files against unauthorized access; it is also used to prevent the files from being inadvertently deleted.
Performance
If the RLOG file causes a bottleneck in an application, you can take the following measures:
Create the RLOG file on a disk that is not otherwise accessed. 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.
If you require an even higher throughput rate, you can store the file on a faster device (e.g. SSD, see the manual "Introduction to System Administration"). Another option is to store the RLOG file on a public disk that is buffered via the global storage (GS).
CAUTION!