DBCC CHECKDB shows following error message in my sql server 2008 R2 database
Msg 8921, Level 16, State 1, Line 2
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
What is the solution?
Given that DBCC CHECKALLOC fails too, with no corruption messages, your database has corrupt metadata and you need to restore from your backups (the first thing it does is run some basic checks on the three critical system tables it needs, and if they're badly broken, it will fail with message 8921). You have no other choice here - you can't run repair as you can't get DBCC CHECKDB to run.
It's possible you could narrow down which system table is corrupt using DBCC CHECKTABLE on successive object IDs from sys.objects, and then manually edit around the corruption, but that's very advanced and has a very low chance of success.
If you don't have any backups, you're going to have to create a new database and then export all the schemas and data into the new database.
I am trying to deploy one of our server via teamcity (db project in VS 2012), i am getting an error on Staging server
Error SQL72014: .Net SqlClient Data Provider:
Msg 5069, Level 16, State 1, Line 5
ALTER DATABASE statement failed.
Error SQL72045: Script execution error.
The executed script:
IF EXISTS (SELECT 1
FROM [master].[dbo].[sysdatabases]
WHERE [name] = N'$(DatabaseName)')
BEGIN
ALTER DATABASE [$(DatabaseName)]
SET RECOVERY SIMPLE
WITH ROLLBACK IMMEDIATE;
END
Any ideas are appreciated.
Don't just gloss over the problem: understand it.
It's because you have some sort of HA (you said mirroring in the comment above, but availability groups (for sure) or log shipping (I think) would also cause this) that requires that the database be in full recovery. When you try to set it to simple recovery, it fails because you can't set the recovery model to anything but full for such a database. You could guard against this by checking what environment you're deploying to from VS and act accordingly.
I need to restart a database because some processes are not working. My plan is to take it offline and back online again.
I am trying to do this in Sql Server Management Studio 2008:
use master;
go
alter database qcvalues
set single_user
with rollback immediate;
alter database qcvalues
set multi_user;
go
I am getting these errors:
Msg 5061, Level 16, State 1, Line 1
ALTER DATABASE failed because a lock could not be placed on database 'qcvalues'. Try again later.
Msg 5069, Level 16, State 1, Line 1
ALTER DATABASE statement failed.
Msg 5061, Level 16, State 1, Line 4
ALTER DATABASE failed because a lock could not be placed on database 'qcvalues'. Try again later.
Msg 5069, Level 16, State 1, Line 4
ALTER DATABASE statement failed.
What am I doing wrong?
After you get the error, run
EXEC sp_who2
Look for the database in the list. It's possible that a connection was not terminated. If you find any connections to the database, run
KILL <SPID>
where <SPID> is the SPID for the sessions that are connected to the database.
Try your script after all connections to the database are removed.
Unfortunately, I don't have a reason why you're seeing the problem, but here is a link that shows that the problem has occurred elsewhere.
http://www.geakeit.co.uk/2010/12/11/sql-take-offline-fails-alter-database-failed-because-a-lock-could-not-error-5061/
I managed to reproduce this error by doing the following.
Connection 1 (leave running for a couple of minutes)
CREATE DATABASE TESTING123
GO
USE TESTING123;
SELECT NEWID() AS X INTO FOO
FROM sys.objects s1,sys.objects s2,sys.objects s3,sys.objects s4 ,sys.objects s5 ,sys.objects s6
Connections 2 and 3
set lock_timeout 5;
ALTER DATABASE TESTING123 SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
Try this if it is "in transition" ...
http://learnmysql.blogspot.com/2012/05/database-is-in-transition-try-statement.html
USE master
GO
ALTER DATABASE <db_name>
SET OFFLINE WITH ROLLBACK IMMEDIATE
...
...
ALTER DATABASE <db_name> SET ONLINE
Just to add my two cents. I've put myself into the same situation, while searching the minimum required privileges of a db login to run successfully the statement:
ALTER DATABASE ... SET SINGLE_USER WITH ROLLBACK IMMEDIATE
It seems that the ALTER statement completes successfully, when executed with a sysadmin login, but it requires the connections cleanup part, when executed under a login which has "only" limited permissions like:
ALTER ANY DATABASE
P.S. I've spent hours trying to figure out why the "ALTER DATABASE.." does not work when executed under a login that has dbcreator role + ALTER ANY DATABASE privileges. Here's my MSDN thread!
I will add this here in case someone will be as lucky as me.
When reviewing the sp_who2 list of processes note the processes that run not only for the effected database but also for master. In my case the issue that was blocking the database was related to a stored procedure that started a xp_cmdshell.
Check if you have any processes in KILL/RollBack state for master database
SELECT *
FROM sys.sysprocesses
WHERE cmd = 'KILLED/ROLLBACK'
If you have the same issue, just the KILL command will probably not help.
You can restarted the SQL server, or better way is to find the cmd.exe under windows processes on SQL server OS and kill it.
In SQL Management Studio, go to Security -> Logins and double click your Login. Choose Server Roles from the left column, and verify that sysadmin is checked.
In my case, I was logged in on an account without that privilege.
HTH!
Killing the process ID worked nicely for me.
When running "EXEC sp_who2" Command over a new query window... and filter the results for the "busy" database , Killing the processes with "KILL " command managed to do the trick. After that all worked again.
I know this is an old post but I recently ran into a very similar problem. Unfortunately I wasn't able to use any of the alter database commands because an exclusive lock couldn't be placed. But I was never able to find an open connection to the db. I eventually had to forcefully delete the health state of the database to force it into a restoring state instead of in recovery.
In rare cases (e.g., after a heavy transaction is commited) a running CHECKPOINT system process holding a FILE lock on the database file prevents transition to MULTI_USER mode.
In my scenario, there was no process blocking the database under sp_who2. However, we discovered because the database is much larger than our other databases that pending processes were still running which is why the database under the availability group still displayed as red/offline after we tried to 'resume data'by right clicking the paused database.
To check if you still have processes running just execute this command:
select percent complete from sys.dm_exec_requests
where percent_complete > 0
I have a table (Cycle) and I created a trigger
alter trigger AnyName on Cycles
for insert,update,delete
AS
BACKUP DATABASE medrepcrm TO DISK = N'C:\medrepcrm.bak' WITH NOFORMAT, INIT, NAME = N'pcrm-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO
But when I insert, update, or delete in the Cycle table that leads to an error.
Msg 3021, Level 16, State 0, Procedure AnyName, Line 8
Cannot perform a backup or restore operation within a transaction.
Msg 3013, Level 16, State 1, Procedure AnyName, Line 8
BACKUP DATABASE is terminating abnormally.
The statement has been terminated.
What can I do to fix this error?
BACKUP DATABASE on MSDN says
The BACKUP statement is not allowed in an explicit or implicit transaction.
A trigger is always in a transactions
If you work it through, a backup which is transactionally consistent snapshot of a database: it doesn't make sense for it to be in it's own transaction.
Not least, on RESTORE the roll forward/roll back mechanism would have to rollback the transaction containing the backup... which defeats the purpose of the backup in the first place...
You could start a job sp_start_job. Within the job you execute a stored procedure where you execute the backup statement. I've done this already with a server trigger which is fired when a new database is created.
I've read other posts and have done hours of research but am still none the wiser.
I have a database that is 65 gig in the data file, and currently 230 gig in the log file. I'm trying to redesign the database so it is more efficient but when making schema changes, the log file tries to grow too large and the windows whinges that it's out of disk space.
I've tried to shrink the file and the lowest it goes is ~220 gig. using DBCC OPENTRAN I can see there are no active transactions. using select * FROM sys.dm_tran_database_transactions I can see that there is nothing interesting going on.
My interpretation of what I have read is that the log file should only be large if there is an active transaction and once all transactions are committed, the file should be able to be shrunk to theoretically something very small. correct?
I've tried backup log with truncate_only followed by dbcc shrinkfile (dbname, 2)
What can I do to shrink this file to something more manageable?
Have you read Kimberly Tripp's article? (Pretty much the canonical reference on the subject): 8 Steps to better Transaction Log throughput.
You might be experiencing VLF fragmentation: Transaction Log VLFs - too many or too few?. Run this command to find out:
DBCC LOGINFO;
Have you followed this standard procedure to shrink the Log:
1) Backup your transaction log (even if you are in simple mode) to clear all activity.
BACKUP LOG [MyDB]
TO DISK = N'E:\db.bak'
GO
2) Shrink the transaction log.
USE [MyDB]
GO
DBCC SHRINKFILE ('MyDB_Log', TRUNCATEONLY)
GO
3) Modify the size of the transaction log and configure your autogrowth:
USE [MyDB]
GO
ALTER DATABASE [MyDB]
MODIFY FILE ( NAME = N'MyDB_Log', SIZE = 1024000KB, FILEGROWTH = 1024000KB)
GO