The essence of relational databases is transactional integrity. This transactional integrity can be maintained if all the transactions occurring within the database are kept atomic, i.e. the changes in the log are either applied or not applied. This feature empowers relational database systems (like MS SQL Server) to perform automatic recovery after a system crash or power failure and restore the database to a consistent state. In MS SQL Server, transactional logging is an important characteristic that should be enabled to implement this mechanism.
An important consideration with regards to this is space requirement. In typical situations, you may require both the before and after image of each updated data row to be recorded. Since there will be transaction record overhead for each row that is being logged, the amount of data updated will be much less in size than the log space consumption for narrow rows. The log space consumed usually depends on several variables and it is not easy for you to predict or presume. Some of the prominent reasons for log space exhaustion include large atomic transactions, uncommitted transactions, exceeding the truncation threshold, and exceeding the checkpoint handler truncation bandwidth.
Transactional replication and database mirroring are also prime contributors to transaction log filling up. In both the mechanisms, you need to send a stream of changes to the secondary systems after reading the transaction log. If there are changes in the log that haven’t been read, there is a good chance that the log will grow in size. If your transaction log is full, you might receive random errors on executing queries. All the database operations would fail and your database would come to a grinding halt.
Minimizing Transaction Log Space Consumption
As a workaround to this, you may choose to any of the below given methods for minimizing the transaction log space consumption:
- You may perform log backups frequently. This will eliminate the need to keep log contents all the time.
- If you do not intend to perform point-in-time recovery in the near future, you can choose to switch to SQL Server simple recovery model. (Full recovery model is only needed for database mirroring and other similar database configurations)
- If you are still using SQL Server 2005 or prior versions, you can choose to destroy the log contents manually. However, this is not recommended.
The above mentioned steps will eliminate the need to keep logs. In order to reduce the size of your log file, you will have to shrink it manually using the command DBCC SHRINKFILE. In case you plan to move back to Full recovery mode again after switching to Simple recovery, you must perform full database backup. You will have to manually grow the file via ALTER DATABASE after shrinking it to do away with any performance issues with the log.
Leave a Reply