SQL Server 2008 Enterprise (I know! #wink. I am working on a migration plan) production server, in FULL recovery mode. I have a database that is used as a source for SQL replication. Daily Full backups and 2-hours incrementals.
I have a log file that has grown a lot (123Go) due to a one-time operation, and that I can't seem to shrink back down to a more normal level.
log_reuse_wait_desc = 'NOTHING'
DBCC Loginfo show a single line with the status = 2
DBCC SQLPERF(LOGSPACE) shows 0.9% used space
sys.sysprocesses WHERE open_tran = 1 shows the SLEEPING reader agents
DBCC OPENTRAN shows the oldest non-distributed as (0:0:0)
When I try to run a small increment shrink, DBCC SHRINKFILE (N'X_log', 120360)
I get:
Cannot shrink log file 2 (X_log) because requested size is larger than the start of the last logical log file.
What else can I try to get what transaction is blocked in the LOG? I will not switch to SIMPLE, I will not backup to NUL, or truncate the LOG, or break my backup chain unless there are clearly no other solution. All suggestions I found seem to somehow assume it is a viable method to break the chain or reboot the server.
What diagnostic command can I still try at this point? I would very much like to debug that one without resorting to Kill-the-spider-with-a-flamethrower actions.
Thanks
Related
I have a SQL Server database that keeps giving me the following error:
Msg 9002, Level 17, State 4, Line 30
The transaction log for database 'DSC_DW_Summary' is full due to 'ACTIVE_TRANSACTION'.
I can see that the log file is at 100% of "Log Space Used" despite my using Simple Recovery and 1 minute recovery time. When I try do any of the following (suggested online as potential solutions) I get the error listed above.
Increase the MaxSize of the log file
Backup the database
Shrink the database
I also don't see any running transactions when I run:
SELECT * FROM sys.dm_tran_database_transactions
or:
DBCC OPENTRAN
Which gives me the result:
No active open transactions.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
So I'm baffled. Somehow I'm being prevented from resolving the issue because of an "Active Transaction" but I can't find any active transactions.
Start with checking what is preventing your log reuse:
SELECT [name], [log_reuse_wait_desc]
FROM [sys].[databases];
Then also issue a CHECKPOINT to try and flush the log
Scenario:
I have an application attempting to write to a SQL Server DB, and I'm getting the message:
The transaction log for database 'DB_NAME' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
However, I see that there is plenty of space on the drive for the transaction log to be written and autogrowth is on. So from SQL Management Studio, I issue:
select name,
log_reuse_wait,
log_reuse_wait_desc
from sys.databases
where name = 'DB_NAME'
and can see that the log_reuse_wait is '3'.
Question:
Do SQL Server transaction logs get 'locked' in any way when this wait is in place?
Note that this is set to 'Simple' recover model. Please let me know if there is more information I need to provide to make this a complete question.
This article may be of help.
https://msdn.microsoft.com/en-us/library/ms190925.aspx
The log reuse wait you are encountering indicates that there is a backup in progress.
Even in simple recovery, a full database backup has to include part of the transaction log.
I am trying to run
DBCC CHECKTABLE
(or CHECKDB, same result), but I keep getting this error:
Check statement aborted. Database contains deferred transactions.
I've made some researches and found that it's some process with SPID 5 and command DB STARTUP blocks everything. This process is running for a few days already but neither dbcc opentran nor dbcc inputbuffer(5) show anything.
Looks like it just sits there and does nothing.
I've checked the logs for that database and it seems that recovery process went fine (last records are about step 3 of 3 running and that over 500K transactions were rolled back so I assume it's done)
I've tried some advice from Google but none of them helped. Setting database to SINGLE_USER, EMERGENCY and even OFFLINE changed nothing - actually, all of them were blocked in one way or another. I can't restore it from earlier backup for some reasons, and there is no more good advice in Google.
Please help.
I have SQL Server 2008 R2 Standard edition with 3 tb data. My disc is full. I want to shrink the .mdf file. I've deleted many rows from my db. And I launch
DBCC SHRINKDATABASE(my_db, TRUNCATEONLY)
I got error
Msg 0, Level 11, State 0, Line 0
A severe error occurred on the current command. The results, if any, should be discarded.
I tried to do it in single user mode result is same. We have increased disk size to 4.5 tb and retried shrinking, result is same.
dbcc checkdb command shows no error on db.
Does anyone know what is problem?
Please help
Have you tried specifying both the file name and the target size in MB, e.g.
DBCC SHRINKFILE('filename', 20);
Or the TRUNCATEONLY option, which doesn't try any of the nasty stuff like reorganizing all of your physical data:
DBCC SHRINKFILE('filename', TRUNCATEONLY);
Also you could try making sure the database is in single user mode first:
ALTER DATABASE db SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
...and turn off any backup / log backup or other maintenance jobs that may be conflicting with your shrink operation.
Is there any way that we can do DML operation with out logging it into log file?
For example, when I am inserting a row in database, this operation will be logged in log file irrespective of using transaction or not. But I don't want to log this operation in the log file.
No. Never. Not possible.
Every operation is logged for a reason: what if it fails halfways through? Server crashes? etc etc
In summary: the A, C and D in ACID
If you don't want this, then using I would really consider using non-ACID NoSQL alternatives.
SQL Server will always write an insert to the log file. It needs that information to recover a database in a consistent state when the server resets.
You can change to impact logging has by choosing the recovery model:
alter database YourDb set recovery { FULL | BULK_LOGGED | SIMPLE }
In simple mode, SQL Server logs just running transactions, and starts reusing parts of the log that are no longer needed. In simple mode, the log file typically remains small.
If you want to get rid of logs after an insert operation, you can use:
alter database YourDb set recovery simple with no_wait
dbcc shrinkfile(YourDbLog, 1)
alter database YourDb set recovery <<old model here>>
Note that this gets rid of all logs. You can only use the restore the last full backup after running this command.