The transaction log file contains recovery and auditing information.
The transaction log stores all changes to the database. By default, all databases use transaction logs. Running a database with a transaction log provides greater protection against failure and better performance.
The timestamp of a transaction log file is updated only when the file grows or when it is closed. If database operations cause the transaction log file to grow without the database file growing, the timestamp of the transaction log file is more recent than the timestamp of the database file. If the database is shut down, the transaction log file and the database timestamps are updated.
To move or rename the transaction log file, use the Transaction Log utility (dblog). See Transaction Log utility (dblog) in the Utility Guide.
The size of the transaction log can also affect recovery times. To control transaction log file growth, ensure that all your tables have compact primary keys. If you perform updates or deletes on tables that do not have a primary key or a unique index not allowing NULL, the entire contents of affected rows are entered in the transaction log. If you define a primary key, the database server needs to store only the primary key column values to uniquely identify a row. If the table contains many columns or wide columns, the transaction log pages fill up much faster if no primary key is defined. Writing extra data affects performance and consumes disk space.
If a primary key does not exist, the server looks for a UNIQUE NOT NULL index on the table (or a UNIQUE constraint). A UNIQUE index that allows NULL is not enough.
To truncate the transaction log, start the server with the -m server startup switch. After truncation, shut down the server and restart it without the switch. See -m iqserv15 server option in the Utility Guide.