We have a TFS2017 environment. The size is growing every week for a long time now.
In this environment , i have multiple collection ; the size of Transaction Log File , is very big (overtop the 155 Gb)
My question is : It's safe to do a shirnk of the log file for the defined TFS collection ? (without loss data or getting error in administration console) ?
Thanks
Yes. You can.
The log file is there so you can restore to a point in time between full backups. If you have backups enabled on your server and regularly take a full backup, then you can truncate the logs after each full backup.
If you want to just "delete the logs" then temporarily turn off TFS by running this on every application tier server you have: TFSServiceControl quiesce, then truncate the logs, then turn TFS back on using TFSServiceControl unquiesce.
You may also want to verify your backup strategy. If all is well, you shouldn't see a ever growing log file.
See:
https://learn.microsoft.com/en-us/azure/devops/server/command-line/tfsservicecontrol-cmd?view=azure-devops-2019
i'm working on huge DB, and while insert\work with big files, log file increase to 60GB and over, and eat all my drive so it can't continue processing.
i tried shrink log file but it work afterwards, and while working it increase again so i thought to move the log file (only) to my 2nd drive where i got more space.
i tried by Detach and Attach but it didnt work , error :
An error occurred when attaching the database(s). Click the hyperlink
in the Message column for details.
i also tried manually by alter command:
ALTER DATABASE [databasename]
MODIFY FILE ( NAME = filename , FILENAME = "new file location and name");
but it make the DB "recovery pending" and i had to restore it back from backup.
any other options?
Since you restored from backup, you can add the MOVE command to your restore command to move the log file to a new drive during the restore.
USE [master]
GO
RESTORE DATABASE [YourDatabase] FROM DISK = 'c:\mssql\backup\Full.bak'
WITH CHECKSUM,
MOVE 'YourDatabase_Log' TO 'E:\newdir\Log.ldf',
RECOVERY, REPLACE;
In order to keep your log file from growing too much, you need to increase the frequency of your log backups, assuming you aren’t on SIMPLE RECOVERY MODEL. Shrinking without backing up is not going to do much, if anything at all. When you backup a log file, the committed transactions are backed up and cleared from the log, freeing up space. As you have witnessed your log file will continue to grow based on the workload. Thus, regular shrinking of the log file isn’t really going to help you.
I have a production DB restored in the dev environment on SQL Server 2012.
I wanted to shrink the log file to save HDD space. I looked through SO and other resources but none of the suggestions work for me.
I took the full DB backup and the Log backup. I set the recovery mode to simple. There's no mirroring set up. Yet the command DBCC SHRINKFILE does not shrink the file, but also does not show any errors. The same command works perfectly well on other DBs in the same server. I also tried right click -> tasks -> shrink -> files -> shrink file to, and got the same result, i.e. no errors but the file size remains unchanged.
What else can I try?
This can happen, even if you've followed the proper instructions of setting the database into SIMPLE recovery mode. Usually this happens because there is a virtual log still being used.
If you run:
DBCC LOGINFO;
You'll see if any virtual logs are in use (Status is 2). When shrinking files, empty virtual logs are physically removed starting at the end of the file until it hits the first used status. This is why shrinking a transaction log file sometimes shrinks it part way, but does remove all free virtual logs which you may expect.
This can happen if there is any active transactions still running, which you can debug by querying sys.dm_tran_active_transactions.
Currently my db logs for my production SQL Server 2008 R2 server is growing out of control:
DATA file: D:\Data...\MyDB.mdf = 278859 MB on disk
LOG file: L:\Logs...\MyDB_1.ldf = 394542 MB on disk
The server mentioned above has daily backups scheduled #1am & translog backups every 15 min.
The database is replicated in full recovery model to a subscriber. Replciation is pushed from the node above (publisher). That same db log file on the subscriber is ~< 100 GB on disk.
What I did to try and fix:
Run a full backup of the db (takes 1h:47m)
Run the translog backup job which runs every 15 min. (takes 1m:20s)
Run another full backup of the db
Nothing above has worked so I then attempt to shrink the log files which doesn't work either using DBCC SHRINKFILE. The size doesn't ever change.
Can anyone please tell me what is wrong or what I need to do as a SQL Server DBA to resolve the above issue?
Possible things that may stop you from shrinking the translog file:
Long running transaction is occurring on your database
Your replication distribution agent runs quite frequent
Looking at the size of your translog file size, most likely it was caused by the 2nd possibility.
Your replication distribution agent runs quite frequent
SQL Server log reader agent marks the translog file as being used and prevent them from being shrunk, which is what SQL Server does after the translog file is backed up. If this process happens frequent and long enough, this could prevent your translog file from being shrunk on translog scheduled back up.
Look at this MSDN transactional explaination and how to modify log reader agent.
And a thread in MSDN forum that describe similar problem, there is DBCC query here that helps you identify running transaction that may be blocking the translog file (DBCC OPENTRAN).
Long running transaction is occurring on your database
You can check wheter any long running transaction is happening by using DBCC OPENTRAN and what process is running then decide what to do with it. As soon as the long running transaction is finished you should be able to shrink the log file.
After running sp_who2, I noticed a long running transaction on the log that was growing uncontrollably. I used kill on that SPID and not I'm proceeding to shrink the log file.
You should make blank database with same table and migrate your old database data to blank database from migration script.
for eg:
INSERT INTO customers(cust_id, Name, Address)
SELECT cust_id, Name, Address
FROM olddb.customers
--this script should run in new blank database
You can manually shrink you log file
1.right click your database > task > shrink > file > file type=log
than ok
I have a database that has a 28gig transaction log file. Recovery mode is simple. I just took a full backup of the database, and then ran both:
backup log dbmcms with truncate_only
DBCC SHRINKFILE ('Wxlog0', TRUNCATEONLY)
The name of the db is db_mcms and the name of the transaction log file is Wxlog0.
Neither has helped. I'm not sure what to do next.
Thank you to everyone for answering.
We finally found the issue. In sys.databases, log_reuse_wait_desc was equal to 'replication'. Apparently this means something to the effect of SQL Server waiting for a replication task to finish before it can reuse the log space.
Replication has never been used on this DB or this server was toyed with once upon a time on this db. We cleared the incorrect state by running sp_removedbreplication. After we ran this, backup log and dbcc shrinkfile worked just fine.
Definitely one for the bag-of-tricks.
Sources:
http://social.technet.microsoft.com/Forums/pt-BR/sqlreplication/thread/34ab68ad-706d-43c4-8def-38c09e3bfc3b
http://www.eggheadcafe.com/conversation.aspx?messageid=34020486&threadid=33890705
You may run into this problem if your database is set to autogrow the log & you end up with lots of virtual log files.
Run DBCC LOGINFO('databasename') & look at the last entry, if this is a 2 then your log file wont shrink. Unlike data files virtual log files cannot be moved around inside the log file.
You will need to run BACKUP LOG and DBCC SHRINKFILE several times to get the log file to shrink.
For extra bonus points run DBBC LOGINFO in between log & shirks
'sp_removedbreplication' didn't solve the issue for me as SQL just returned saying that the Database wasn't part of a replication...
I found my answer here:
http://www.sql-server-performance.com/forum/threads/log-file-fails-to-truncate.25410/
http://blogs.msdn.com/b/sqlserverfaq/archive/2009/06/01/size-of-the-transaction-log-increasing-and-cannot-be-truncated-or-shrinked-due-to-snapshot-replication.aspx
Basically I had to create a replication, reset all of the replication pointers to Zero; then delete the replication I had just made.
i.e.
Execute SP_ReplicationDbOption {DBName},Publish,true,1
GO
Execute sp_repldone #xactid = NULL, #xact_segno = NULL, #numtrans = 0, #time = 0, #reset = 1
GO
DBCC ShrinkFile({LogFileName},0)
GO
Execute SP_ReplicationDbOption {DBName},Publish,false,1
GO
Don't you need this
DBCC SHRINKFILE ('Wxlog0', 0)
Just be sure that you are aware of the dangers: see here: Do not truncate your ldf files!
And here Backup Log with Truncate_Only: Like a Bear Trap
This answer has been lifted from here and is posted here in case the other thread gets deleted:
The fact that you have non-distributed LSN in the log is the problem.
I have seen this once before not sure why we dont unmark the
transaction as replicated. We will investigate this internally. You
can execute the following command to unmark the transaction as
replicated
EXEC sp_repldone #xactid = NULL, #xact_segno = NULL, #numtrans = 0, #time = 0, #reset = 1
At this point you should be able to truncate the log.
I've had the same issue in the past. Normally a shrink and a trn backup need to occur multiple times. In extreme cases I set the DB to "Simple" recovery and then run a shrink operation on the log file. That always works for me. However recently I had a situation where that would not work. The issue was caused by a long running query that did not complete, so any attempts to shrink were useless until I could kill that process then run my shrink operations. We are talking a log file that grew to 60 GB and is now shrunk to 500 MB.
Remember, as soon as you change from FULL to Simple recovery mode and do the shrink, dont forget to set it back to FULL. Then immediately afterward you must do a FULL DB backup.
If you set the recovery mode on the database in 2005 (don't know for pre-2005) it will drop the log file all together and then you can put it back in full recovery mode to restart/recreate the logfile. We ran into this with SQL 2005 express in that we couldn't get near the 4GB limit with data until we changed the recovery mode.
I know this is a few years old, but wanted to add some info.
I found on very large logs, specifically when the DB was not set to backup transaction logs (logs were very big), the first backup of the logs would not set log_reuse_wait_desc to nothing but leave the status as still backing up. This would block the shrink. Running the backup a second time properly reset the log_reuse_wait_desc to NOTHING, allowing the shrink to process.
Have you tried from within SQL Server management studio with the GUI. Right click on the database, tasks, shrink, files. Select filetype=Log.
I worked for me a week ago.
Try creating another full backup after you backup the log w/ truncate_only (IIRC you should do this anyway to maintain the log chain). In simple recovery mode, your log shouldn't grow much anyway since it's effectively truncated after every transaction. Then try specifying the size you want the logfile to be, e.g.
-- shrink log file to c. 1 GB
DBCC SHRINKFILE (Wxlog0, 1000);
The TRUNCATEONLY option doesn't rearrange the pages inside the log file, so you might have an active page at the "end" of your file, which could prevent it from being shrunk.
You can also use DBCC SQLPERF(LOGSPACE) to make sure that there really is space in the log file to be freed.
Try to use target size you need insted of TRUNCATEONLY in DBCC:
DBCC SHRINKFILE ('Wxlog0', 1)
And check this to articles:
http://msdn.microsoft.com/en-us/library/ms189493(SQL.90).aspx
http://support.microsoft.com/kb/907511
Edit:
You can try to move allocated pages to the beginning of the log file first with
DBCC SHRINKFILE ('Wxlog0', NOTRUNCATE)
and after that
DBCC SHRINKFILE ('Wxlog0', 1)
Put the DB back into Full mode, run the transaction log backup (not just a full backup) and then the shrink.
After it's shrunk, you can put the DB back into simple mode and it txn log will stay the same size.
I had the same problem. I ran an index defrag process but the transaction log became full and the defrag process errored out. The transaction log remained large.
I backed up the transaction log then proceeded to shrink the transaction log .ldf file. However the transaction log did not shrink at all.
I then issued a "CHECKPOINT" followed by "DBCC DROPCLEANBUFFER" and was able to shrink the transaction log .ldf file thereafter
You cannot shrink a transaction log smaller than its initially created size.
I tried all the solutions listed and none of them worked. I ended up having to do a sp_detach_db, then deleting the ldf file and re-attaching the database forcing it to create a new ldf file. That worked.