Hi I'm having a production database and its replicated report database. How to shrink the transaction log files in the production database as the log file size is increasing. I had tried DBCC SHRINKFILE and SHRINKDATABASE commands but it does not work for me. I can't detach and shrink and attach back as the db in replication. Please help me in this issue.
First check what is causing your database to not shrink by running:
SELECT name, log_reuse_wait_desc FROM sys.DATABASES
If you are blocked by a transaction, find which one with:
DBCC OPENTRAN
Kill the transaction and shrink your db.
If the cause of the blocking is 'REPLICATION' and you are sure that your replicas are in sync, you might need to reset the status of replicated transactions. To see the status of what the database still think needs to be replicated use:
DBCC loginfo
You can reset this by first turning the Reader agent off (I usually just turn the whole SQL Server Agent off), and then run that query on the database for which you want to fix the replication issue:
EXEC sp_repldone #xactid = NULL, #xact_segno = NULL, #numtrans = 0, #time= 0, #reset = 1
Close the connection where you executed that query and restart SQL Server Agent (or just the Reader Agent). You should be all set to shrink your db now.
The database won't let you remove transaction data that isn't backed up. First you have to back up the transaction log, then you can shrink it.
Do you have a regular backup schedule in place?
If not, I suggest you read this excellent article: 8 Steps to better Transaction Log throughput
Shrink the logfile with dbcc shrinkfile
Then truncate the log file using
Backup databaseName with truncate_only
Then shrink the logfile again
I used Red-Gate's SQL Backup tool to take care of the backing up. Then I just use the management console to issue a shrink command on the log file (telling it to rearrange the pages before releasing unused space).
Works like a charm.
Related
I have a SQL2012 DB that has a log file growing very rapidly. I have a 3rd party program doing full database backups so I'm not worried about that.
I have the command to run in the SQL manager to shrink the log file and that is working but it's a very manual task.
I'm trying to create a script that I can schedule to run every 2 weeks but a BAT file won't work it seems as after the sqlcmd -S servername\instancename -E command is run it just goes to 1> and stops. I need to run the USE and DBCC commands but not sure how to achieve this.
I have tried looking online but nowhere can I find a way to make a double click script to run this DBCC SHRINKFILE task.
So using sqlcmd, I can do this:
USE DBNAME
GO
DBCC SHRINKFILE (DBNAME_20070302091322_Log, 1);
GO
Running manually the file shrinks to below 10mb and that is correct. I need to just automate this task.
I have a SQL2012 DB that has a log file growing very rapidly
In this case you must verify the database recovery model and log_reuse_wait_desc which you can identity with following command:
Select name, recovery_model_desc, log_reuse_wait_desc
from sys.databases
If Recovery model set to FULL:
As mentioned in the comments, you must schedule LOG BACKUP at the backup tool that you are using for Full Backups, even you perform DBCC SHRINKFILE it would't shrink the size due to active portion in the log file, you must perform appropriate action bases on log_reuse_wait_desc status before running DBCC SHRINKFILE command. You can verify it
looking at message section once DBCC command you executed.
For more details on LOG FILE/CHECKPOINTS/log_reuse_wait..
If Recovery model set to Simple:
Once you decided to go with Simple recovery model, shrink the file manually, but keep enough room for SQL Engine to perform log operations depending on transaction workload. Shrinking the log file to lower size means putting unnecessary overload on the server as the SQL Engine try to increase it again when there is no enough space available for the transaction workload/throughput.
You do not have schedule LOG backup in simple recovery model, as the log file checkpoints would be automatically added and based on checkpoint log would be truncated.
So looks like with your help i managed to get it working.
I have a BAT with the -i option where the DBCC command is.
here is that bat
sqlcmd -S sqlserver\instance -E -d databasename -i c:\test.sql -o c:\out.txt
here is hte test.sql
USE databasename
GO
DBCC SHRINKFILE (DBLOGFILENAME_Log, 1);
GO
tested and its working.
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 been created new database and the log file groth very past, and I get error mesaage that the log is full due to 'BACKUP'.
I looked in the differences between this Database and other databases in the SERVER, and I seen that in all databases log_reuse_wait is 0 and log_reuse_wait_desc is NOTHING and in my database log_reuse_wait is 0 and log_reuse_wait_desc is LOG_BACKUP.
I want to change this property in my database to 0 and NOTHING.
How can I do that?
This is a read-only status variable. It tells you why the log cannot be truncated at this point.
You have to remove the cause of that condition instead of just changing the value (which isn't even possible).
Either backup the database log or switch to SIMPLE recovery mode. You should probably read a little on both just to understand the implications.
David W.'s script did not quite work for me. (SQL Server 2008 r2)
I needed to modify it slightly. Using the script as is I got the message that there was no such file for database [master]. Alter the DATABASE as David W. recommends and then switch to the target database and run the DBCC SHRINKFILE() command.
Also the first argument to DBCC SHRINKFILE() must be the logical name of the database log file, which is represented in the following script as logical_file_name_for_LOG
USE [master]
GO
ALTER DATABASE <db name> SET RECOVERY full
GO
ALTER DATABASE <db name> SET RECOVERY SIMPLE WITH NO_WAIT;
GO
USE [db name]
GO
DBCC SHRINKFILE('<logical_file_name_for_LOG>', 0, TRUNCATEONLY)
i found the solution.
even the database is in SIMPLE mode is wait to BACKUP_LOG, so you need to change the recovery mode to FULL and then back to SIMPLE with no wait
USE [master]
GO
ALTER DATABASE <db name> SET RECOVERY full
GO
ALTER DATABASE <db name> SET RECOVERY SIMPLE WITH NO_WAIT;
GO
USE [db name]
GO
DBCC SHRINKFILE('<log file name>', 0, TRUNCATEONLY)
I know this is old, but the answers are wrong.
If the database has recovery mode FULL and that is intended, then do not change it to simple.
The log_reuse_wait_desc says what the state is before the log can be reused or shrinked. In this case it is LOG_BACKUP, meaning that, to shrink the transaction log, you need to backup the transaction log first and shrink it or backup the log and let the SQLServer reuse the log space.
A description of the log_reuse_wait_desc states can be found here
Suddenly I saw my SQL Server is in suspect/OFF Line mode. That's why I am not able to do any any operation in my db. For this reason I restarted my server (Windows Server 2003) .
But when I get ready I found that some of my data has been lost. I have no any back up of my db.
Is there any way to get back the data that I have lost.
the error log:
Could not redo log record (5108:10151:5), for transaction ID
(0:1552370), on page (1:3679), database '??'
The database may go in suspected/offline mode if the location of datafile and the log file have been misplaced accidentally or intentionally, and so after restart the database is unable to find its datafiles and goes in suspect or offline mode. This can be resolved by bringing the datafile and the log file back to the original path that has been configured for the database. After that, the database can be restored with no loss using the command 'Restore with recovery'. The original path for the datafile and the log file can be found in the error log of the server that contains the database.
Try the solution, hope it will help as it did for me.
In another case, the database may go in suspected/offline mode due to off and restart of the server in middle of a transaction and after the restart the transactions may not be committed or rolled back to a consistent state thus leaving database in an inconsistent state turning it suspected or offline. The solution for this is:
alter database <database name> set emergency dbcc checkdb (repair_allow_data_loss)
As the commnand itself states allow data loss, this command may result in loss of some data from the transaction log and hence we may face a data loss, so it is not recommended for a frequent or unapproved use.
In this case, I suggest you check your log file (LDF). In SQL, this log file records all the INSERT, UPDATE, and DELETE query operations performed on a database.
Suppose you have an LDF file. You can work with Restore and recovery process. I used this process for one of my existing clients & It worked.
https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/restore-and-recovery-overview-sql-server?view=sql-server-ver16
If you do not have a log file, you can use stellar repair for SQL this process helps me to recover my data many times.
Thanks
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.