{"id":2829,"date":"2015-11-30T05:40:58","date_gmt":"2015-11-30T10:40:58","guid":{"rendered":"https:\/\/academy.sqlbak.com\/?p=2829"},"modified":"2023-10-17T05:31:05","modified_gmt":"2023-10-17T09:31:05","slug":"transaction-log","status":"publish","type":"post","link":"https:\/\/academy.sqlbak.com\/transaction-log\/","title":{"rendered":"Transaction Log"},"content":{"rendered":"
The transaction log is a crucial part of each database that records all transactions and database changes made by each transaction. The purpose of the transaction log is to keep record of all changes that were made in the database.\u00a0Let’s consider the example from the picture below:<\/p>\n
One more thing that has to be mentioned is that a database can have one or more transaction log files. Using two or\u00a0more transaction logs will not make your database work faster, because writing can occur\u00a0only into one file at a time, meaning that parallel I\/O operations are not possible. The scenario under which\u00a0multiple transaction log files are recommended is when the first one can not grow anymore.<\/p>\n
The transaction log stores every transaction made in a database, except those that are minimally logged (such as SELECT INTO or BULK IMPORT). Each transaction log record has its own unique number, called the Log Sequence Number (LSN), and is stored in the transaction log’s Virtual Log File (VLF), whose size is not fixed. A transaction log can have any number of virtual log files:<\/p>\n
The log file will grow until it fills all free space on the disk where it is located unless log records are removed. As time passes, old log records become unnecessary for the recovery process, so they must be deleted to free space for new log records. Such a process in SQL Server where all unnecessary records are removed to reduce the size of the log file is called transaction log truncation<\/em>.<\/p>\n The way\u00a0this truncation happens is dependent on the recovery model that was selected for\u00a0your database.<\/p>\n The transaction log is truncated when\u00a0checkpoint occurs. At that time, all committed transactions are written to the data file\u00a0and virtual log files can be reused. Look at the picture below:\u00a0<\/p>\n After the checkpoint occurs, virtual log files 1 and 2 are no longer in use because transactions 11 and 12 have been committed. SQL Server marks virtual log files 1 and 2 as reusable. Such a process is known as truncation of the transaction log. All committed transactions have been truncated, but the physical size of the transaction log remains the same. If there is a need to make the transaction log file smaller, turn AUTO_SHRINK option on and it will physically shrink the log file (where possible) at periodic intervals:<\/p>\n To set up auto shrink using SSMS, right-click on the database for which you want to set up transaction log auto shrink, select \u201cProperties\u201d, then \u201cOptions\u201d. Choose \u201cAuto Shrink\u201d and switch from “False” to “True”, and then click \u201cOK\u201d.<\/p>\n <\/p>\n So after the transaction has been committed, SQL Server can reuse the space. But be careful with this option as there is no way to control when auto shrink starts. Also, such operations where the file grows then shrinks, then again grows, and again shrinks, take more resources.<\/p>\n In this case, the transaction log is truncated only during the transaction log backup. In the full or bulk-logged recovery model when the checkpoint occurs, all dirty pages are written to the disk, but SQL Server will not mark any of the virtual log files as reusable. The transaction log will be truncated only after the transaction log backup is completed:<\/p>\n <\/p>\n Remember, if the database is running under the full or bulk-logged recovery model and the full backup has been never made, the transaction log will be truncated at each checkpoint.<\/p>\n As mentioned above, the transaction log is automatically truncated under the simple recovery model, but how can you manage the transaction log if the database uses a full or bulk-logged recovery model? This is achieved through regular transaction log backups.<\/p>\n Moreover, it is recommended to monitor the transaction log space. Use the following command:<\/p>\n That returns the following table:<\/p>\n <\/p>\n Another\u00a0useful command that can help to find out how many virtual logs are in the transaction log file\u00a0that is being currently used:<\/p>\n <\/p>\n The transaction log is a crucial part of each database that records all transactions and database changes made by each transaction. The purpose of the transaction log is to keep record of all changes that were made in the database.\u00a0Let’s consider the example from the picture below:<\/p>\n","protected":false},"author":10,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[157],"tags":[],"yoast_head":"\nSimple Recovery Model<\/h3>\n
ALTER DATABASE<\/span> your_database<\/em> SET<\/span> AUTO_SHRINK ON\r\n<\/span>ALTER DATABASE<\/span> your_database<\/em> SET AUTO_SHRINK OFF<\/span><\/pre>\n
Full or Bulk-Logged Recovery Models<\/h3>\n
BACKUP<\/span> LOG<\/span> your_database <\/em>TO DISK<\/span> = 'log.bak'<\/span><\/pre>\n
Maintenance of the Transaction Log<\/h2>\n
DBCC<\/span> SQLPERF(LOGSPACE)<\/pre>\n
\n
DBCC<\/span> LOGINFO<\/pre>\n
\n