Transaction Log Still Growing When In SIMPLE Recovery Mode
Dec 3, 2007
hi,
we have a SQL Server 2000 database which we set to 'SIMPLE' recovery mode at 6pm (due to nightly large data loads). We revert back to 'FULL' recovery mode at 6am.
My understanding was that in 'SIMPLE' recovery mode, the transaction log would not grow because it would automatically be truncated after a checkpoint. However this is not the case. I thought perhaps it could be due to a long running uncomitted transaction, but when I ran 'dbcc opentran', the oldest running transactions doesn't last for more than a couple minutes. I manually run a 'checkpoint' command as well in the hope of forcing the transaction log truncation. I repeat this a couple of times to no avail. When I run 'dbcc sqlperf(logspace)' , I can still see the transaction log growing.
It is not until I run 'backup log db with truncate_only' that the transaction log gets truncated.
I do not understand, why the transaction log does not get automatically truncated in SIMPLE recovery mode?
Something strange is happening to our SQL Server DB (2000). Thetempdb transaction log file continues to grow (quite slowly) for noapparent reason. We have it in simple mode, and I have tried a manualcheckpoint command and manual shrink (of the log file only). Thereare no unusual SQL's (large or small) going on. A "heavy hitter" wouldmake it grow fast, not 10 MB every 30 minutes or so. This server hasbeen in production for over a year with no similar issues to this.Anyone encounter a similar situation? This started (as far as we cantell) sometime yesterday. It is growing about 200 MB a day, and is upto 600 MB now, with all but 8 MB "used". For now we added space, butof course that is not a long term solution. The two "data" files(each had a 200 MB initial allocation) have never gone much above 100MB each used (they are each about 100 MB now and have been that wayfor several days, but have shrank and grown). There are about 30small to medium sized "regular" databases on this instance.Any help would be appreciated, especially if there is a way we can fixthis without bouncing the engine (I know, wishful thinking...). The OSis Win 2000, SP3. SQL Server is at 2000, SP 3a.THANKS IN ADVANCE!
On SQL 2000, if I have a large transaction log for my database and I manage to fill it with a single large transaction but it is not set to autogrow, what happens?
I have several databases that perform daily backups. Ever since I installed SP2, the backup jobs are failing. The logs state that it's because the database recovery mode cannot be SIMPLE, but need to be either FULL or Bulk-Logged.
Can anyone tell me if this is true, and that I do have to change my recovery mode?
Here's the error:
NEW COMPONENT OUTPUT Microsoft(R) Server Maintenance Utility (Unicode) Version 9.0.3042 Report was generated on "ICIS-SQL-SERVER". Maintenance Plan: DB Backup Duration: 00:08:05 Status: Warning: One or more tasks failed.. Details: Back Up Database (Transaction Log) (ICIS-SQL-SERVER) Backup Database on Target server connection Databases that have a compatibility level of 70 (SQL Server version 7.0) will be skipped. Databases: All user databases Type: Transaction Log Append existing Task start: 2007-03-10T05:08:09. Task end: 2007-03-10T05:08:09. Failed:(-1073548784) Executing the query "BACKUP LOG [hl7 db_SamirTesting] TO DISK = N'D:\mssql\backup\hl7 db_SamirTesting\hl7 db_SamirTesting_backup_200703100508.trn' WITH NOFORMAT, NOINIT, NAME = N'hl7 db_SamirTesting_backup_20070310050809', SKIP, REWIND, NOUNLOAD, STATS = 10 " failed with the following error: "The statement BACKUP LOG is not allowed while the recovery model is SIMPLE. Use BACKUP DATABASE or change the recovery model using ALTER DATABASE. BACKUP LOG is terminating abnormally.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
Command:BACKUP LOG [hl7 db_SamirTesting] TO DISK = N''D:mssqlackuphl7 db_SamirTestinghl7 db_SamirTesting_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''hl7 db_SamirTesting_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP LOG [dg_efilm_153] TO DISK = N''D:mssqlackupdg_efilm_153dg_efilm_153_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''dg_efilm_153_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP LOG [hl7 db] TO DISK = N''D:mssqlackuphl7 dbhl7 db_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''hl7 db_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10
Back Up Database (Transaction Log) (ICIS-SQL-SERVER) Backup Database on Target server connection Databases that have a compatibility level of 70 (SQL Server version 7.0) will be skipped. Databases: All user databases Type: Transaction Log Append existing Task start: 2007-03-10T05:08:09. Task end: 2007-03-10T05:08:09. Failed:(-1073548784) Executing the query "BACKUP LOG [dg_efilm_153] TO DISK = N'D:\mssql\backup\dg_efilm_153\dg_efilm_153_backup_200703100508.trn' WITH NOFORMAT, NOINIT, NAME = N'dg_efilm_153_backup_20070310050809', SKIP, REWIND, NOUNLOAD, STATS = 10 " failed with the following error: "The statement BACKUP LOG is not allowed while the recovery model is SIMPLE. Use BACKUP DATABASE or change the recovery model using ALTER DATABASE. BACKUP LOG is terminating abnormally.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
Command:BACKUP LOG [hl7 db_SamirTesting] TO DISK = N''D:mssqlackuphl7 db_SamirTestinghl7 db_SamirTesting_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''hl7 db_SamirTesting_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP LOG [dg_efilm_153] TO DISK = N''D:mssqlackupdg_efilm_153dg_efilm_153_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''dg_efilm_153_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP LOG [hl7 db] TO DISK = N''D:mssqlackuphl7 dbhl7 db_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''hl7 db_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10
Back Up Database (Transaction Log) (ICIS-SQL-SERVER) Backup Database on Target server connection Databases that have a compatibility level of 70 (SQL Server version 7.0) will be skipped. Databases: All user databases Type: Transaction Log Append existing Task start: 2007-03-10T05:08:09. Task end: 2007-03-10T05:08:09. Failed:(-1073548784) Executing the query "BACKUP LOG [hl7 db] TO DISK = N'D:\mssql\backup\hl7 db\hl7 db_backup_200703100508.trn' WITH NOFORMAT, NOINIT, NAME = N'hl7 db_backup_20070310050809', SKIP, REWIND, NOUNLOAD, STATS = 10 " failed with the following error: "The statement BACKUP LOG is not allowed while the recovery model is SIMPLE. Use BACKUP DATABASE or change the recovery model using ALTER DATABASE. BACKUP LOG is terminating abnormally.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
Command:BACKUP LOG [hl7 db_SamirTesting] TO DISK = N''D:mssqlackuphl7 db_SamirTestinghl7 db_SamirTesting_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''hl7 db_SamirTesting_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP LOG [dg_efilm_153] TO DISK = N''D:mssqlackupdg_efilm_153dg_efilm_153_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''dg_efilm_153_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP LOG [hl7 db] TO DISK = N''D:mssqlackuphl7 dbhl7 db_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''hl7 db_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10
Back Up Database (Transaction Log) (ICIS-SQL-SERVER) Backup Database on Target server connection Databases that have a compatibility level of 70 (SQL Server version 7.0) will be skipped. Databases: All user databases Type: Transaction Log Append existing Task start: 2007-03-10T05:08:08. Task end: 2007-03-10T05:08:09. Failed:(0) Database 'hl7 db_SamirTesting' will not be backed up because it does not have its recovery model set to Full or BulkLogged.
Back Up Database (Transaction Log) (ICIS-SQL-SERVER) Backup Database on Target server connection Databases that have a compatibility level of 70 (SQL Server version 7.0) will be skipped. Databases: All user databases Type: Transaction Log Append existing Task start: 2007-03-10T05:08:08. Task end: 2007-03-10T05:08:09. Failed:(0) Database 'dg_efilm_153' will not be backed up because it does not have its recovery model set to Full or BulkLogged.
Back Up Database (Transaction Log) (ICIS-SQL-SERVER) Backup Database on Target server connection Databases that have a compatibility level of 70 (SQL Server version 7.0) will be skipped. Databases: All user databases Type: Transaction Log Append existing Task start: 2007-03-10T05:08:08. Task end: 2007-03-10T05:08:09. Failed:(0) Database 'hl7 db' will not be backed up because it does not have its recovery model set to Full or BulkLogged.
Back Up Database (Full) (ICIS-SQL-SERVER) Backup Database on Target server connection Databases that have a compatibility level of 70 (SQL Server version 7.0) will be skipped. Databases: All databases Type: Full Append existing Task start: 2007-03-10T05:00:06. Task end: 2007-03-10T05:08:08. Success Command:EXECUTE master.dbo.xp_create_subdir N''D:mssqlackupmaster'' GO EXECUTE master.dbo.xp_create_subdir N''D:mssqlackupmodel'' GO EXECUTE master.dbo.xp_create_subdir N''D:mssqlackupmsdb'' GO EXECUTE master.dbo.xp_create_subdir N''D:mssqlackuphl7 db_SamirTesting'' GO EXECUTE master.dbo.xp_create_subdir N''D:mssqlackupdg_efilm_153'' GO EXECUTE master.dbo.xp_create_subdir N''D:mssqlackuphl7 db'' GO BACKUP DATABASE [master] TO DISK = N''D:mssqlackupmastermaster_backup_200703100500.bak'' WITH NOFORMAT, NOINIT, NAME = N''master_backup_20070310050006'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP DATABASE [model] TO DISK = N''D:mssqlackupmodelmodel_backup_200703100500.bak'' WITH NOFORMAT, NOINIT, NAME = N''model_backup_20070310050006'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP DATABASE [msdb] TO DISK = N''D:mssqlackupmsdbmsdb_backup_200703100500.bak'' WITH NOFORMAT, NOINIT, NAME = N''msdb_backup_20070310050006'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP DATABASE [hl7 db_SamirTesting] TO DISK = N''D:mssqlackuphl7 db_SamirTestinghl7 db_SamirTesting_backup_200703100500.bak'' WITH NOFORMAT, NOINIT, NAME = N''hl7 db_SamirTesting_backup_20070310050006'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP DATABASE [dg_efilm_153] TO DISK = N''D:mssqlackupdg_efilm_153dg_efilm_153_backup_200703100500.bak'' WITH NOFORMAT, NOINIT, NAME = N''dg_efilm_153_backup_20070310050006'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP DATABASE [hl7 db] TO DISK = N''D:mssqlackuphl7 dbhl7 db_backup_200703100500.bak'' WITH NOFORMAT, NOINIT, NAME = N''hl7 db_backup_20070310050006'', SKIP, REWIND, NOUNLOAD, STATS = 10
What is the impact of changing the recovery mode of a database from Full to simple? The client I am at has set their database to full recovery mode, set their log files to grow automatically. But I don't think they have ever done a backup of their transaction log (it has grown to over 19Gig, where the data portion of the database is only around 400M).
What is the impact of truncating the transaction log now? After truncating it, i would like to shrink the file to a managable number and change the recovery mode to simple (they don't need transaction log backups)
When we do a full database backup manually, we are seeing the trn file reflect the current date/time, but we are not seeing the mdf reflect the new date/time. And we are not seeing the transaction log file decrease in size. the recovery mode is set to full, do we need to change to simple to see both the mdf being backup'ed?
My understanding is that the log file is not supposed to grow if the database is under simple recovery mode.I am in a situation where the log grows if do any inserts that involve millions of rows.How do i make sure that it does not grow?
I have a small, ~10GB SQL 2008 R2 database, that was setup with simple recovery. We do full backup each night at midnight when no one is using the database. Is there any problems with doing differential backups during the day when users may be writing to the database? Could I even do hourly differential backups while users are using the database? I'm conflicted about switching over to full recovery mode and using transaction logs to have the ability restore data between backups. If I can do a couple daily differential backups while users are using the database during the day, in addition to our nightly full backups, than I live with simple recovery mode.
Wondering whether I can have following included in a script file:
1. set the current single user db from Full to Simple recovery mode. 2. Checkpoint and shrink the transaction log file (release all unused space) 3. set the current single user db from Simple recovery to Full recover mode.
The DB is in simple recovery mode. There are no open transactions (used dbcc opentran).
The server is running SQL Server 2014 and the DB is in compatibility mode SQL Server 2008 (100). It was upgraded to 2014 a month or two ago.
I have tried to re-size the log to 100mb, but any way I have tried (none gave errors), the log file remains the same size. I have tied to shrink the log file (through the UI and via DBCC commands) without success; no errors, but also no change in file size.
I have checked Log Reuse Waits, just in case, and as expected it showed “NOTHING” (select log_reuse_wait_desc, name from sys.databases)
I tried running a checkpoint, but that did not allow any resize or shrink to work.
I have tied creating large transactions to move the used point in the log file, in case this was the issue. I did this by creating tables that I drop after large inserts. While it shows me that the log space % used increased, the log file still does not allow the space to be reduced.
The following is what I was using for the transactions to get the log used.
BEGIN TRAN select a.* into testtable from sysobjects a, sysobjects b, sysobjects c ROLLBACK TRAN
Do I just need to continue running large transactions until the log space used gets high enough to get the “end point” in the log to really move? Is there an easier way to accomplish this (I have several DBs that have the almost identical problem), what I am using moves the Log Space Percent Used about a percent on each execution.
My trancaction log is 25GB and my database file is 39GB. I justswitched to the 'Simple' recovery model from the 'Full' recovery model.When if ever can I expect the size of the transaction log to reduce insize? Is there anything else that I should do to aide with thereduction?Thanks,Peter
Hi there - can anyone advise on the following issue. We have recently performed some server side tracing on a particular SQL instance over 24hr period. We are now attempting to load these into a database for analysis. Here lies the problem.
When we are loading the profiler trace files (one at a time) into the database the transaction log is growing at an excessive rate. Even though the database is in SIMPLE mode.
We are loading the traces using the command:
INSERT INTO sqlTableToLoad SELECT * FROM ::fn_trace_gettable('MytraceFileName', DEFAULT)
Can anyone advise how we could possibly get round this issue as we're running out of space due to the transaction log.
I upgraded from SQL 6.5 to SQL 7 last month, and so far, everything's been going fine.
However, I'm not using my old SQL 6.5 backup scripts, which, when the backup was done, would dump the transaction log with TRUNCATE_ONLY, shrinking the log size.
My SQL 7 server is set up with a Maintenance Plan which does everything, including backup, but the log file seems to be growing and growing. I'm up to 4.5 gigs now, for a database with a data file of 3.5 gigs.
How do I "dump transaction with TRUNCATE_ONLY" on a SQL 7 database?
I want to truncate my sharepoint config database and WSS_Logging database logs the size of sharepoint_config database is growing at a pace of ~10GB every week. I have scheduled a weekly full backup. Current .ldf file size is 113GB.
I am using SQL server 2012 with Always On High Availability feature. I am not able to set the recovery mode from Full to Simple as it gives me message that mirroring is running on both server.
In my case to reduce the log file what I need to do.
I wonder if anyone could explain why when monitoring the transaction log size it doesn't appear to be growing! I'm using the following code to test image data types with logging.. I've got 'Truncate log on Checkpoint' switched off and 'Select into Bulk copy' also switched off.
Running the following code I would expect to see the transaction log grow and grow and grow... Monitoring it using perfmon indicates that it isn't in fact logging...
DECLARE @ptrval varbinary(16)
SELECT @ptrval = TEXTPTR(pr_info) FROM pub_info pr INNER JOIN publishers p ON p.pub_id = pr.pub_id AND p.pub_name = 'New Moon Books'
declare @Loop int select @Loop = 0
While @Loop <= 10000 BEGIN
WRITETEXT pub_info.pr_info @ptrval with log 'New Moon Books (NMB) '
My database has a situation where my transaction log is growing out of control. However I have not been able to figure out where any memory leaks are occuring.
Is there a way to monitor the database in order to find out at when the tlog is growing. Or even better, what sql is being executed that is causing this unreasonable tlog growth?
The log file for database 'P5_Nextel' is full. Back up the transaction log for the database to free up some log space
What i'm doing is, i just resizing the space allocated, but the problem is my disk is now out of space. How can i prevent this kind of problem without adding a new disk? Is there any other way?
I am having problems with the transaction log growing. I set up a maintenance plan to backup every 15 minutes. The recovery model is set to full. It is set to auto grow by 10 percent with unrestricted file growth. The space allocated is 2mb. Should this be set higher? It seems whenever I unchecked the auto shrink, the log is growing larger. The command I use to check is:
SELECT * FROM sysfiles WHERE name LIKE '%LOG%' GO
This is the log size and the log space used.
1.492187538.02356
This has grown 4 percent since yesterday. Are there any good practices to maintain these log files?Any help would be appreciated.
Hi,We have created a SQL server 2000 database. We observe that thetransaction log keeps growing over time. We are now about to run out ofspace. We have been periodically shrinking the database. Neverthelessthe size has increased. I would imagine that a transaction log can beeliminated if we stop the database. Can that be done? Is there a way tocompletely wipe off the transaction log?Thanks,Yash
in the process of migrating a big db from server 1 to server 2, we had to roll back the change. I started with taking a full db backup and restoring it on server 2 with norecovery, and then a couple logs with norecovery, and then the last log with recovery.
Is there some way to continue this chain now, I mean to change the db to norecovery, or other way to restore logs.
I dont want to do a new full backup.
If I try to do a log restore now i get the message:
Msg 3117, Level 16, State 4, Line 1
The log or differential backup cannot be restored because no files are ready to rollforward.
I have to admit, I'm usually using the MySql database, but in this particular case I have to use MSSQL 2000.
Over to my problem.
I'm building a web-based system (who isn't these days) in which the user types arbitrary information that is published when the user pushes the save button. Nothing new about that.
Here comes the tricky part, when the user wants to edit an existing item I copy all information in the database and sets the id of the 'edit-copy' to the negative value ( id 45 becomes id -45 for the edit-copy). This is also done on all items in other tables that is connected to the main item.
This way I get a copy that the user may edit without messing up the published information. When the user is done I either delete all the negative items (cancel) or delete the positive items and update the negative to become positive (save).
So far so good, allmost... my problem is that the transaction log grows tremendously.
Is there any other way to accomplish a safe edit that doesn't affect the transaction log as much as my current solution?
Could I be doing something wrong when updateing or deleteing my items?
The transaction log of a database grows until it runs out of disk space. If disk space is full, all databases on instance may get problems. Because of this i have set a limitation on how much it may grow, up to 40 GB. It grows in steps of 100 MB. It reaches its limit a couple of times a week, causing the application to hang.
The database file itself is about 2,3 GB large.
The SQL version is 10.50.4276, SQL2008R2 SP2.
The recovery model is FULL.
I have a backupjob that runs a FULL Backup at midnight.And a backupjob that runs a LOG backup every 30 minutes.Both finishes with success. However, the transaction log is never truncated, the unused space is never released.
I have checked for "long running jobs", it sometimes sys "backup_log", sometimes "active_transaction".
Could a workaround be to set the recovery mode to simple, and create a full-backup job that runs every 30 minutes for this database? It is a critical database....
We have a Principle, Mirror and Witness set-up and all is working fine, however, the transaction logs for a few large databases just keep growing over a the course of the month until the disk is full. As I understand it, and having tried you can't dump the transaction logs while mirroring is configured, is there any way at all to commit and truncate the logs while mirroring is running or do I have to manually remove the mirroring each month, dump the transaction logs and then re-enable it again after doing the backup/restore?
The databases in question are about 6GB in data size and the transaction logs can grow to be about 60GB in a month.
Would a normal SQL Server 2005 backup truncate the logs if I configured this? At the moment we use Litespeed for SQL server for nightly backups.
I know this question has been posted before but after reading some other post I'm still a bit confuse of what to do?
In my database, I have a 3Mb data file and the transaction log file has growed to 500Mb and keep growing... Can you please advise what I should do to reduce it size and/or stop it from continue growing?
Hi there - I have an sms server which uses a sql 7 database. The transaction log on it keeps growing at an incredible rate (about 1gb p/w). The database was successfully backed up yesterday, and I thought that should delete the inactive entries in the log. Can someone tell me some steps to do reduce it to a regular size?
We have configured the following in the Publisher server..
1) Merge Replication - Synchronisation to be running in the continuous mode.
2) Merge Replication - Synchronisation in Scheduled mode.
The issue that we are facing here is the transaction log file of the databases which are in replication are growing very largely. And we get this error message in the Subscriber :
Error messages:
The Merge Agent failed to retrieve article information for publication 'MCC_Pos_CashlessPub'. Increase the -QueryTimeOut parameter and restart the synchronization. When troubleshooting, use SQL Profiler or restart the agent with a higher value for -HistoryVerboseLevel and check the output log file for errors. Correct any database engine conditions that may be causing internal replication stored procedures to fail. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201017) Get help: http://help/MSSQL_REPL-2147201017
The transaction log for database 'tempdb' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases (Source: MSSQLServer, Error number: 9002) Get help: http://help/9002
In fact for the past two days there are no data movement or any changes to the table, still we are able to see the growth in the transaction log file.
As mentioned in the error description when checked the log_reuse_wait_desc column of the sys.databases table, it showed the value "LOG_BACKUP". So took database backup 3 times. and took transaction log backup 2 times from the subscriber server in which the error was thrown. Still the issue persists. There is no change in the transaction log size.
What is the reason behind the growth of LDF?? Is it because of Merge Replication Configured in the server??
Kindly check and let as know regarding this issue. We are facing lot of problems because of this issue. Thanks in advance.
We have 300+ databases on one sinlge server (SQL 2005). If I need to change recovery mode from full to simple for all of them, is there any way to do so? Please advice.
