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.
Related
I am having an issue with DB Log Full and going through all the things trying to figure out why this is happening. I have of course implemented the backup here.
I run the backup commands for the shrink of the database log, the odd thing is that sometimes the script runs and at other times I get an error.
USE [MYDB];
BACKUP DATABASE [MYDB] TO DISK = 'L:\Backup\MYDB_DB_2023_01_05__T08_10_21.bak' ;
BACKUP LOG [MYDB] TO DISK = 'L:\Backup\MYDB_log_2023_01_05__T08_10_21.bak' WITH INIT;
ALTER DATABASE [MYDB]
SET RECOVERY SIMPLE;
DBCC SHRINKFILE(MY_Log, 3000);
ALTER DATABASE [MYDB]
SET RECOVERY FULL;
I have no idea why I am seeing the error message below since I am running this to backup / truncate the Log.
My DB Log size is set to 3GB & Autogrow with Limit 7GB, SQL Express version is 2017
Msg 3013, Level 16, State 1, Line 4
BACKUP DATABASE is terminating abnormally. [I don't know why this occurs]
Processed 894794 pages for database 'MYDB', file 'MY_Log' on file 1.
BACKUP LOG successfully processed 894794 pages in 97.732 seconds (71.528 MB/sec).
(1 row affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
(1 row affected)
Msg 9002, Level 17, State 2, Line 4
The transaction log for database 'MYDB' is full due to 'LOG_BACKUP'.
/ Yes I know the Log is full that is why I am running this script! //
EDIT: Comment Requested Info.
Storing SQL Server database files on new Azure Files share. Cannot run full / comprehensive CHECKDB against these databases - I think this has something to do with user account not having permissions to create snapshots. As a result, I offloaded these checks to an alternate server where I can also test .baks. Everything works fine except for the master db, which registers corruption when you restore it as a user db and run CHECKDB against it (https://www.itprotoday.com/my-master-database-really-corrupt), even though it's not corrupt.
Questions:
1) Has anyone run into the same problem running CHECKDB on SQL db files stored on an Azure Files share? Is there a workaround?
2) What's an alternative to running CHECKDB on master if I cannot run it in PROD? Can I somehow restore master to another SQL instance and check it there?
Error when I execute DBCC CHECKDB (master) in PROD:
Msg 5030, Level 16, State 12, Line 4
The database could not be exclusively locked to perform the operation.
Msg 7926, Level 16, State 1, Line 4
Check statement aborted. The database could not be checked as a database snapshot could not be created and the database or table could not be locked. See Books Online for details of when this behavior is expected and what workarounds exist. Also see previous errors for more details.
Message when I run DBCC CHECKDB on user db in PROD:
DBCC CHECKDB will not check SQL Server catalog or Service Broker consistency because a database snapshot could not be created or because WITH TABLOCK was specified.
Please reference this Azure Support document: Error message when you run any of the DBCC CHECK commands in SQL Server: "The database could not be exclusively locked to perform the operation"
In Microsoft SQL Server, you may receive an error message when you run any of the following DBCC commands:
DBCC CHECKDB
DBCC CHECKTABLE
DBCC CHECKALLOC
DBCC CHECKCATALOG
DBCC CHECKFILEGROUP
The error message contains the following text:
Msg 5030, Level 16, State 12, Line 1 The database could not be exclusively locked to perform the operation.
Msg 7926, Level 16, State 1, Line 1
Check statement aborted. The database could not be checked as a database snapshot could not be created and the database or table could not be locked. See Books Online for details of when this behavior is expected and what workarounds exist. Also see previous errors for more details.
Cause:
This problem occurs if the following conditions are true:
At least one other connection is using the database against which you
run the DBCC CHECK command.
The database contains at least one file group that is marked as
read-only.
Starting with SQL Server 2005, DBCC CHECK commands create and use an internal database snapshot for consistency purposes when the command performs any checks. If a read-only file group exists in the database, the internal database snapshot is not created. To continue to perform the checks, the DBCC CHECK command tries to acquire an EX database lock. If other users are connected to this database, this attempt to acquire an EX lock fails. Therefore, you receive an error message.
Resolution
To resolve this problem, follow these steps instead of running the DBCC CHECK command against the database:
Create a database snapshot of the database for which you want to
perform the checks. For more information about how to create a
database snapshot, see the "Create a Database Snapshot
(Transact-SQL)" topic in SQL Server Books Online.
Run the DBCC CHECK command against the database snapshot.
Drop the database snapshot after the DBCC CHECK command is
completed.
This document can give more helps to solve the problem.
Updates:
For the system databases it does not use database snapshots, but it will hold table locks.
You also an reference this blog: Checkdb giving error for master database:
Mike Walsh gives us more things about the error.
Hope this helps.
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
I have a database whose log file size is 527GB, showing almost 100% use. The DB is in AO Asynchronous replication with another SQL server. DB is in Full backup mode, and Log backup is happening every hour. I tried to shrink log file, it didn't work, gave me following message.
Msg 1468, Level 16, State 2, Line 2
The operation cannot be performed on database "MYDB" because it is involved in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or in an availability group.
Msg 5069, Level 16, State 1, Line 2
ALTER DATABASE statement failed.
The log for database 'MYDB' cannot be shrunk until all secondaries have moved past the point where the log was added..
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
I think its not doing it because of replication all logs are not transferred and its been all the time. How do solve the issue without taking Database out of AO replication group? I can move it to Synchronous mode, but I do not want it to move out of AO.
To check out the cause of your problem have a look at results of the query below (log_truncation_holdup_reason field):
select * from sys.dm_db_log_stats(db_id('YourDatabaseName'))
UPD: For versions lower than 2016 SP2 you can get the same using a query:
SELECT log_reuse_wait_desc
FROM sys.databases
WHERE name = 'YourDatabaseName'
If it is AVAILABILITY_REPLICA then check active transactions to understand which one could cause it.
dbcc opentran
Depending on results you will be able to decide what you should do.
I am having issue with SQL Server where I Can't execute any queried because the Hard Drive that hosts the databases is full.
I tried to shrink the database using the "Shrink" function in MS SMS but that did not work because the disk space is full.
How can I truncate the logs without crashing the database but also shrink the size?
I tried the following also
USE myDatabaseName;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE myDatabaseName
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (myDatabaseName_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE myDatabaseName
SET RECOVERY FULL;
GO
but got the following error
Msg 3023, Level 16, State 3, Line 2
Backup and file manipulation operations (such as ALTER DATABASE ADD FILE) on a database must be serialized. Reissue the statement after the current backup or file manipulation operation is completed.
Msg 5069, Level 16, State 1, Line 2
ALTER DATABASE statement failed.
Thanks
SQL Server Pre 2012
BACKUP LOG LogName
WITH TRUNCATE_ONLY;
SQL Server 2012 onwards
The WITH_TRUNCATEONLY has been removed so you should switch the recovery model to Simple and revert to perform the same action.
ALTER DATABASE DatabaseName
SET RECOVERY SIMPLE;
After which, don't forget to re-instate your original recovery model!
Shrinking the log
Just because you've truncated the log this does not mean that the file size on disk has changed.
To reduce the file size of the log you need to issue the following command
DBCC SHRINKFILE (DatabaseLogLogicalName, 1);
Short answer:
BACKUP LOG WITH TRUNCATE_ONLY
Long answer: Backup your DB and read this first:
Managing Transaction Logs