Shrinking Unreasonably Large Transaction Log File.
Oct 12, 2002
Gurus,
I have inherited a SQL 2000 database ( (I am new to SQL DBA) and I found this when I was checking the db properites . The transaction log has grown bigger than the actual data file, I thought transaction log backups would truncate the inactive portion of the log file and shrink the transaction log, but it was not the case it seems, may be it was truncating the inactive portion of the log, but not shrinking it. This site does not have a job for truncating the data/log files periodically. What is the best method to deal this situation, how can I shrink the Transaction log quickly?,
Currently we has a database of size about 300G. Because our backup system failed some time past we were left with a transaction log file which grew to about 160G. However our backups are working again and everything is working fine. My understanding is that now the transaction log file is practically empty but the capacity remains at 160G.
When you delete records the deleted transactions are going to get logged to the transaction file. My understanding is when a backup is done these transactions get discarded out of the transaction file.
could I make use of this relatively large transaction file and start deleting transactions without out actually adding to the transaction file size.
The plan is to delete records from logging tables that are not referenced to by any other table without this increasing the transaction log file.For example over a period of a few weeks we can delete a chunk of records from a table. Then after it has completed a backup we can delete another chunk of records out of this table until we have got the table down to the records that we now need.Will this work?
I have a webhost where it seems my control of my database is fairly restricted. I cannot backup the database because I don't have the necessary permissions. I cannot perform a DBCC SHRINKFILE (permissions) - and many other DBCC commands. I ran into a problem where my log file filled up during the middle of the day and impacted my operations - data was lost.
I found some TSQL for shrinking the log file, but the statement: SET @TruncLog = 'BACKUP LOG [' + db_name() + '] WITH TRUNCATE_ONLY'; EXEC (@TruncLog)
will not execute because I cannot execute the BACKUP LOG command (permissions)...
Is there anything else I can do, or am I to far up the creek (w/o my paddle)??
I've been trying to shrink my SQL 7 Transaction log after it had grown to 30+GB's. After running the command dbcc shrinkfile 'filename' and the new size, I'm getting a result set of:
I'm having a problem shrinking my transaction log. I have a 1GB database with a 500MB transaction log. The transaction logs are backed up every 10 minutes but it has grown to 2.2GB. I've tried backing the transaction log with TRUNCATE_ONLY and then tried doing a DBCC SHRINKFILE but it doesn't seem to work. I've checked if there were any old, long running queries but there is none. What else can I do to reduce the transaction log size?
I've had a thought to create a secondary log file and then delete the primary but that isn't allowed. Is there anyway I can make the secondary log file the primary and vice-versa? This way I should be able to delete the secondary log file to reclaim space.
We have a database that was created with a 50 MB transaction log, that is set to autogrow. Due to activity the log periodically grows to over 200 MB. So we expanded it to 200 MB. But everytime the log is backed up, it shrinks to it's original size of 50 MB. The autoshrink option is not set, and no one is manually shrinking the log. Any idea what could be causing this? We are using SQL 7, SP 3.
I am having a problem truncating a transaction log. The truncate and database shrink commands execute successfully, but do not reduce the size of the transaction log.
I have steps that I take to shrink transaction log. One of the steps is to delete the transaction log after I detach the database. Am I losing any data by doing that?
I have a transaction log with 22mb of used space and 2,632.50MB of free space. I tried using the following statement to shrink the log and it did not do anything: USE DB GO DBCC SHRINKFILE (DB_log, 50) GO CHECKPOINT
Can anybody help me understand what is going on here?
My transaction log blows out to more than 55 GB when I run an index rebuild on a fairly large table. It’s ok for the transaction log to get that big but I want to shrink it back down ASAP while maintaining the integrity of my transactional backups. I’m thinking of a process something like the following: 1.Full database backup 2a.BACKUP LOG database-name WITH TRUNCATE_ONLY 2b.dbcc shrinkfile(2,20,TRUNCATEONLY ) 3.Full database backup
Is this the best way to shrink the T-Log while maintaining the integrity of my transactional backups? My database is MSSQL 2000 sp4 in full recovery mode.
Gurus My logfile for a DB grows very rapidly and grows to more than 10gb every night,i have scheduled a job to shrink this file. Now in job activity monitor it is showing me a yellow triangle in front of the job and status as successfull and it has ran only for 1 second It is not shrinking the logs I have transactional replication implemented My point is when the logfile grows more than 10 gb the job does not shrink the logs I have got around 8 steps in thos job and this is the 7th step
Hi All,My SQL server transaction log is getting bigger every day and my HDD ifrunning out of space.So i follow the MS KB about how to Shrinking the Transaction Log.After doing so the log is much much smaller as i can see the size of itunder enterprise manager.The problem is that the HDD still shows the same size.If i shrink the DB why the and reduce its size why the HDD does notshows it?Is there a way to clear the size from the HDD?Thanks All
Hi!I'm studying to have my MCSE 70-228 certification and I'm trying somethings with backing up transaction logs and shrinking it.Here's what I do:There is no activity in the database by the way.I have a transaction log of 1792 kb...I do the following command:BACKUP LOG TestDB TO TestDBBackupDBCC SHRINKFILE ('TestDB_Log',0)The transaction log is now 1280 kbI do the same command and finally my transaction log is now 1024kb...Any idea why it didn't shrink it at 1024 kb the first time?Thanks!Jeff
I am currently having a rather pestering issue with my full/transaction log backups. It seems that after running either, my logs do not truncate and the file continues to stay @ the current size and eventually fill to the brim. This issue only began after mirroring was setup. Is there any differences in log file maintainence when dealing with Mirrored databases ? I made my last attempt to run backups and waited over the weekend for some hope that a checkpoint would occur and my file would be shrunk once again for normal use.
I am working on deploying my production DB's to a new server and am looking for some advice. The new server is running RAID-5 (the old one is RAID-0) but it only has one controller therefore I can not create another array group. So I was wondering since the disk setup is C: and D: (Virtual Drive) if I would see any benefits from placing my log files on C: and my Data files on D:?
The other question is related to the size of my log files. Some of the DB's were not created by me and there are no constraints in log file growth causing some very large TRANS logs. For example, there is a 100 MB DB with a 1 GB trans log. I restored the DB on my new server and truncated the log file (manually, the Ent Mgr Shrink DB tool doesn't work worth a hoot) to half the size of the DB and it functions properly. I was just wondering if this would cause any problems down the road if I did all of my DB's like this?
I am restricting log file growth to approximately half the size of the DB.
There is one DB that is 1.5 GB and the log file was set restricted to 2mb and it works fine, but I feel that I should bump this up a bit.
I have a 13 Gig Log File with only 121 Mgs of space used. I have run the DBCCSHRINKFILE command and it has shrunk it by about 100 Mgs. Why can't I get it to shrink to a reasonable size.
Hi, is there any other way to shrink the log file other than truncating every time it gets bigger... I have a 800MGs database and the log is getting as big as 11Gigs... any suggestions other than truncating it? Is there a way to set it off?
DECLARE @i int SELECT @i = 0 WHILE (@i < 300) begin INSERT t2 values ('a') SELECT @i = @i +1 END DROP TABLE t2
BACKUP LOG PBDSSTEST TO PBDSSTESTLOGBACKUP
Before I ran this the used portion of the log was 1795.12 MB, the free was 1570.50 MB for a total of 3365.62 MB.
After completing this the used portion was 25.62 MB, the free space was 3263.50 for a total of 3289.12 MB. It only srhunk about 26 MB. Why won't it shrink it anymore. There was plenty of data in the used at the time of the shrinkfile command so I would have thought it would have shrunk it a lot more. Please help. I don't understand why it won't shrink it anymore than it did.
I have a problem with shrinking a log file on SQL 2000. The log file has grown to 25gb (the db is 30gb) . The DB was in simple recover mode but I have changed it to full so that the log file can be backed up. I have run the dbcc shrinkfile on the log file several times (plus log file backups) and it has increased the logfile size. Each time I have run shrinkfile I get €˜Cannot shrink log file 2 (db_Log) because all logical log files are in use€™ message. I have used the dbcc loginfo command and this shows that all the virtual log files are in use. The db also publishes 4 snapshot replications. Any suggestion for how I can easily shrink the log file?
I have a database that was loaded with large amounts of data before today. I backup up the db and trans log. presently the DB file is 328 while the trans log show 428 meg with only 28 meg being used. If I try to shrink either the database or the log files, the log file wil not shrink.. It tells me to set it to a minimum of 28 meg but still not shirnk. I realize this was a problem in 7, any quick fixes, in a hurry. Running SQL 2000 SP1
I'd like to create a stored procedure to automatically shrink the transaction log file on a certain database monthly. As I am not the DB admin (it's a web-based db on a remote server), I'd like to put together a script to create the procedure so I can just send it to the DB admin to run. It seems like it should be pretty easy, but I'm still pretty new to SQL server. Is anyone able to give me some pointers?
I have a relatively high usage 2005 database whose transaction log grows every day.
Untill now I have been manually shrinking the log files .. but I would like to automate this process.
In the maintenance schedule that runs every night
1 Do a full backup to disk 2. Do a transaction log backup to disk 3. run the following TSQL
USE [MyDB]; GO ALTER DATABASE MyDB SET RECOVERY SIMPLE; GO DBCC SHRINKFILE (MyDB_log, 3000) GO ALTER DATABASE MyDB SET RECOVERY FULL; GO
4. Backup disk files to tape.
however it doesn't work !! the TLOG file does not shrink, even though its the same as the manual job that I run?
There is nothing in the SQL logs .. but in the event log I get
Event Type: Error Event Source: SQLISPackage Event Category: None Event ID: 12291 Date: 13/12/2007 Time: 00:50:10 User: NT AUTHORITYSYSTEM Computer: ALGSQL1 Description: Package "MyDB_FULL_BACKUP" failed. For more information, see Help and Support Center
please advice me what does .ldf file consist of and can i shrink the .ldf , is it adviceble to shrink after the backup and how frequently it can be done on a production db
please advice me ,can i shrink the .mdf , it is adviceble to shrink after the backup and how frequently it can be done on a production db
(SQL 2005) I have a few databases that are currently hovering at around 150GB. (The following only concerns the .mdf) Of this total size, only about 90GB is real data. The other 60-70 is data from unecessary audit tables. Recently, we've been having some space issues on a 1.7TB server. We've decided that deleting these audit tables and reclaiming the 60-70GB per database is the route we're going to take.
What we did: DELETE <table> (per audit table). Now, it shows that the database size is ~90GB and there is the 60-70GB of unallocated space.
Then, we ran a DBCC SHRINKDATABASE (db_name) overnight. Checked space the next morning and only about 10GB had been reclaimed. We've tried a number of other alternatives of which, none have been successful.
(DBCC SHRINKFILE(file, space), drop and recreate tables, etc.)
Can anyone think of any reason why these commands would not be working? If I can provide any additional information, please let me know.
I have an interesting problem here. I am running SQL Server 2005 and have a large database. After running some scalability tests over the weekend my MDF file size went up to 25GB and LDF file size went up to 27GB filling up all available disk space. I didn't do any backups, so it is understandable why the LDF file size is so large.
Now I am trying to shrink the LDF file. However, DBCC LOGINFO indicated that all LVFs within the LDF are active (Status = 2). I detached the database to make sure no active connections exist and ran CHECKPOINT, but still DBCC LOGINFO lists all LVFs with status 2. Since all LVFs are up to date I can't shrink my LDF file.
Why are all LVFs still active after detach/attach and checkpoint? How can I shrink the LDF file?
Is there a fairly quick and dirty way to shrink the file size allowedfor a DB on SQL server after the DB is in use?Our old DBA allowed 3 gb for log files and we don't need nearly thatmuch. However, the space is still being used and reserved. Can Ishrink that "maximum" and clear up the space?I don't want to just copy all the tables and primary keys and open anew one with the new data, though that is plan A right now.I cant just change sysfiles, it yells at me.
I've been searching and reading for best practices on how to maintain a reasonable log file size while engaging in Log Shipping. I have found plenty of information on these subjects on their own, but not on how best to shrink your log size without breaking your log shipping integrity.
