{"id":3525,"date":"2022-10-03T07:00:00","date_gmt":"2022-10-03T04:00:00","guid":{"rendered":"https:\/\/www.dataplatform.gr\/?p=3525"},"modified":"2023-11-05T21:37:49","modified_gmt":"2023-11-05T18:37:49","slug":"giati-den-mporo-na-kano-shrink-to-transaction-log-ston-sql-server-k","status":"publish","type":"post","link":"https:\/\/www.dataplatform.gr\/en\/giati-den-mporo-na-kano-shrink-to-transaction-log-ston-sql-server-k\/","title":{"rendered":"Why can't I shrink the transaction log in SQL Server and why is it full?"},"content":{"rendered":"

In previous<\/a> article we had seen what the Transaction Log is. This time we'll see how we can empty it and make it shrink, we'll also see what we can do case by case when it won't let us.<\/p>\n\n\n\n

Suddenly one day we see that the transactions in a certain database in SQL Server are not running and that the disk where the Transaction Log files are stored is full. What are we doing;<\/p>\n\n\n\n

How do we shrink the transaction log?<\/h2>\n\n\n\n

For starters, with the following function we will see the size of the transaction log of each base and its percentage of use:<\/p>\n\n\n\n

dbcc sqlperf(logspace);<\/pre>\n\n\n\n
After running it, we see that on a specific basis it has reached 40GB and uses its 100%:<\/p>\n\n\n\n
\"\"
01<\/figcaption><\/figure>\n\n\n\n
To see the name of the transaction log file that has been filled, run the following in the database:<\/p>\n\n\n\n
select name,(size*8\/1024\/1024) SizeGB from sys.database_Files where type_desc = 'LOG';<\/pre>\n\n\n\n
\"\"
02<\/figcaption><\/figure>\n\n\n\n
Now that we have the name with the function DBCC SHRINKFILE<\/em> we can try shrinking the file down to 1024mb:<\/p>\n\n\n\n
USE [StackOverflow2013]\nGO\nDBCC SHRINKFILE ('StackOverflow2013_log5' , 1024);<\/pre>\n\n\n\n
However, it shows us the following message that tells us that the space is needed, so we have not done something right:<\/p>\n\n\n\n
\"\"
03<\/figcaption><\/figure>\n\n\n\n
Why doesn't it let us shrink the transaction log?<\/h2>\n\n\n\n
Let's see how much space they take up Virtual Log Files<\/em><\/strong> where is in Active status <\/strong>which cannot be deleted:<\/p>\n\n\n\n
select sum(vlf_size_mb) ActiveVLFsizeMB from sys.dm_db_log_info(DB_ID('StackOverflow2013'))\nwhere 1=1\nand vlf_status = 2;\n\n--\u0391\u03bd \u03b7 \u03ad\u03ba\u03b4\u03bf\u03c3\u03b7 \u03b5\u03af\u03bd\u03b1\u03b9 \u03c0\u03c1\u03b9\u03bd \u03c4\u03b7\u03bd 2016 \u03c4\u03cc\u03c4\u03b5 \u03b4\u03b5\u03bd \u03b4\u03bf\u03c5\u03bb\u03b5\u03cd\u03b5\u03b9 \u03c4\u03bf view \u03ba\u03b1\u03b9 \u03c4\u03c1\u03ad\u03c7\u03bf\u03c5\u03bc\u03b5 \u03c4\u03b7\u03bd loginfo:\ndbcc loginfo;\n<\/pre>\n\n\n\n
We see that it takes several gigabytes. This means that whether there is a transaction in progress<\/strong> either \/ and must to backup the transaction log<\/strong> in case our base is in Full recovery model.<\/strong><\/p>\n\n\n\n
\"\"
04<\/figcaption><\/figure>\n\n\n\n
Let's see what Recovery Model<\/strong> is our base:<\/p>\n\n\n\n
select name,recovery_model_desc from sys.databases;<\/pre>\n\n\n\n
We see that it is in Full<\/strong>, which means that in order to reduce the percentage and let us shrink the transaction log we should first take a transaction log backup:<\/p>\n\n\n\n
\"\"
05<\/figcaption><\/figure>\n\n\n\n
Let's try to run a job that will take a transaction log backup:<\/p>\n\n\n\n
exec msdb.dbo.sp_start_job 'DatabaseBackup - USER_DATABASES - LOG';<\/pre>\n\n\n\n
After the backup is finished, wait a bit and try again to see the log:<\/p>\n\n\n\n
dbcc sqlperf(logspace);<\/pre>\n\n\n\n
\"\"
06<\/figcaption><\/figure>\n\n\n\n
We see again that it is 100%, so even though nothing is running in the base, some transaction must have been left open. We can search for this with the function DBCC OPENTRAN<\/em>:<\/p>\n\n\n\n
dbcc opentran;<\/pre>\n\n\n\n
We see that there is an open transaction on session id 68\u2026:<\/p>\n\n\n\n
\"\"
07<\/figcaption><\/figure>\n\n\n\n
Checking with the following what is currently running in the database with session_id 68 finds no result:<\/p>\n\n\n\n
select * from sys.dm_exec_requests where session_id=68;<\/pre>\n\n\n\n
But somewhere here I had mocked you, as from the beginning I had left a transaction which, although the delete had completed, I had not closed it with commit or rollback<\/strong> and remained active in the transaction log:<\/p>\n\n\n\n
\"\"
08<\/figcaption><\/figure>\n\n\n\n
We can now do kill<\/em> the session id 68 and to see the status of the rollback with the following: <\/p>\n\n\n\n
kill 68\nkill 68 with statusonly<\/pre>\n\n\n\n
\"\"
09<\/figcaption><\/figure>\n\n\n\n
Now we need to back up the transaction log again:<\/p>\n\n\n\n
exec msdb.dbo.sp_start_job 'DatabaseBackup - USER_DATABASES - LOG';<\/pre>\n\n\n\n
So now if we look again at the active Virtual Log Files we will see that the size has dropped:<\/p>\n\n\n\n
select sum(vlf_size_mb) ActiveVLFsizeMB from sys.dm_db_log_info(DB_ID('StackOverflow2013'))\nwhere 1=1\nand vlf_status = 2;\n\n--\u0391\u03bd \u03b7 \u03ad\u03ba\u03b4\u03bf\u03c3\u03b7 \u03b5\u03af\u03bd\u03b1\u03b9 \u03c0\u03c1\u03b9\u03bd \u03c4\u03b7\u03bd 2016 \u03c4\u03cc\u03c4\u03b5 \u03b4\u03b5\u03bd \u03b4\u03bf\u03c5\u03bb\u03b5\u03cd\u03b5\u03b9 \u03c4\u03bf view \u03ba\u03b1\u03b9 \u03c4\u03c1\u03ad\u03c7\u03bf\u03c5\u03bc\u03b5 \u03c4\u03b7\u03bd loginfo:\ndbcc loginfo;<\/pre>\n\n\n\n
\"\"
10<\/figcaption><\/figure>\n\n\n\n
And we check the transaction log rate again:<\/p>\n\n\n\n
dbcc sqlperf(logspace);<\/pre>\n\n\n\n
We will see that it is now used under 1% of the transaction log:<\/p>\n\n\n\n
\"\"
11<\/figcaption><\/figure>\n\n\n\n
So now we will be able to do shrink<\/em>:<\/p>\n\n\n\n
USE [StackOverflow2013]\nGO\nDBCC SHRINKFILE ('StackOverflow2013_log5' , 1024);<\/pre>\n\n\n\n
We see that it completed successfully this time:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
If we look again at the space in the transaction log:<\/p>\n\n\n\n
dbcc sqlperf(logspace);<\/pre>\n\n\n\n
We will see that it dropped from the physical size of 50GB to the 1GB we set for it:<\/p>\n\n\n\n
\"\"
12<\/figcaption><\/figure>\n\n\n\n
If any previous VLF remains active<\/h2>\n\n\n\n
If the following message appears, it means that a Virtual Log File that precedes the next ones that have been emptied is still active (we can see it with dbcc loginfo<\/em> looking for those with status 2). <\/p>\n\n\n\n
\"\"
13<\/figcaption><\/figure>\n\n\n\n
Then we try to take a transaction log backup again and then shrink again.<\/p>\n\n\n\n
<\/p>\n\n\n\n
If it still shows us this message, even though we have let it pass and some time may be responsible for an Availability Group, transactional replication or something else.<\/p>\n\n\n\n
So as an emergency solution we can temporarily lose the Point in Time feature for after the last transaction log backup but fix the problem by running the following:<\/p>\n\n\n\n
USE [StackOverflow2013] \nGO  \nALTER DATABASE [StackOverflow2013]\nSET RECOVERY SIMPLE;  \nGO  \n\nCHECKPOINT;\nDBCC SHRINKFILE ('StackOverflow2013_log5', 1);  \nGO  \n\nALTER DATABASE [StackOverflow2013]\nSET RECOVERY FULL;  \nGO <\/pre>\n\n\n\n
<\/p>\n\n\n\n
Sources:<\/h2>\n\n\n\n