This parameter defines the size of each primary and secondary log file. The size of these log files limits the number of log records that can be written to them before they become full and a new log file is required.
A primary log file can be reused when the changes recorded in it have been committed. If the log file size is small and applications have processed a large number of changes to the database without committing the changes, a primary log file can quickly become full. If all primary log files become full, the database manager will allocate secondary log files to hold the new log records.
When a log file is full, it is closed and not overwritten. If archive logging is configured then the log file will be subsequently archived.
A log file that is too small can affect system performance because of the processing time of archiving old log files, allocating new log files, and waiting for a usable log file.
A log file that is too large can reduce your flexibility when managing archived log files and copies of log files, since some media might not be able to hold an entire log file.
Also, the size of the log file can impact the frequency of which log files are archived and the amount of time it takes to archive an individual log file. These factors will impact the availability of log files in the archive location for disaster recovery scenarios if something happens to the primary server. The ARCHIVE LOG FOR DATABASE command can be used to truncate and archive log files on a more frequent basis if necessary.
If you are using log retention, the current active log file is closed and truncated when the last application disconnects from a database. When the next connection to the database occurs, the next log file is used. Therefore, if you understand the logging requirements of your concurrent applications, you might be able to determine a log file size that will not allocate excessive amounts of wasted space.