I have executed the following query
dbcc UPDATEUSAGE (dbname) with NO_INFOMSGS
It has been running for over an hour with no return yet. What could this mean?
I tried executing the similar code
dbcc UPDATEUSAGE (dbname, 'dbo.tablename) with NO_INFOMSGS
on all 120 something tables individually, and each completed successfully in seconds.
The full query is actually
dbcc checkcatalog (dbname) with NO_INFOMSGS
dbcc checkDB (dbname) with NO_INFOMSGS
dbcc UPDATEUSAGE (dbname) with NO_INFOMSGS
dbcc checkalloc (dbname) with NO_INFOMSGS
I also ran this 5 other databases and they all completed successfully.
When I run this on this one database, it hangs up. I cancelled the query and tried one line at a time. The other 3 lines all complete successfully in seconds, it's just the UPDATEUSAGE line that seems to get hung up.
I also ran this against all of databases on a different computer with the same software and it completed in successfully almost instantly. Clearly, something is wrong with this one database on this computer. I was told that this database is for the GUI.
Related
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.
In SQL Server can we get the time when the SQL Server service was last restarted?
And how to get the date when the DBCC DROPCLEANBUFFERS and FREEPROCCACHE last executed?
I have ran dbcc freeproccache and below is captured in my error log..
SQL Server has encountered 1 occurrence(s) of cachestore flush for the 'Object Plans' cachestore (part of plan cache) due to 'DBCC FREEPROCCACHE' or 'DBCC FREESYSTEMCACHE' operations.
SQL Server has encountered 1 occurrence(s) of cachestore flush for the 'SQL Plans' cachestore (part of plan cache) due to 'DBCC FREEPROCCACHE' or 'DBCC FREESYSTEMCACHE' operations.
SQL Server has encountered 1 occurrence(s) of cachestore flush for the 'Bound Trees' cachestore (part of plan cache) due to 'DBCC FREEPROCCACHE' or 'DBCC FREESYSTEMCACHE' operations.
But the same can't be said for all DBCC commands.Most of them log details into errorlog/eventvwr.For Example DBCC DROPCLEANBUFFERS won't write any info ..
The only way to get know which commands are run is through auditing or extended events..
As far as I know there is no easy way to get that information. However, you can use Extended Events and capture all queries with %DBCC DROPCLEANBUFFERS% in sql_text.
Steps to reproduce (SQL Server 2008R2):
We restore a .bak file
We run the query (no other activity)
It times out
We restart sql server
We run the query
It runs really fast.
Reproduction rate 100%.
I've tried combinations of
DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS
DBCC FREESESSIONCACHE
DBCC FREESYSTEMCACHE ('ALL')
DBCC UPDATEUSAGE (dbname)
EXEC sp_updatestats
select * from master..sysprocesses where blocked <> 0
Nothing works, only restarting SQL Server.
I thought it would be just a bad plan, but expected FREEPROCCACHE to fix it, without restarting SQL Server. Is there some other cache I need to clear?
The query is not a transactional/blocking/locking style, mostly selects into and out of temporary tables it has created, and no other activities on the server.
I believe it must be a bad plan, but DBCC FREEPROCCACHE didn't do the job.
Does anyone have a clue?
Looks to me like you have an open connection to the database, yould be that you are "standing on your own feet". when you restore a database you need exclusive access so drop who is in the database und rollback any transaction that's going on (you restore is going to whype any thing that was dony anyway). Then you can restore your database.
Now a restart of SQL server will close all active connections however there is an easier way ;-)
USE MASTER;
GO;
ALTER DATABASE [YourDbName]-->change this to your database name
SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
After that you can run your restore.
Have a nice day
Walter
I'm maintaining an application that uses SQL Server Express 2005 as the back end. The application allows users to create new databases and provide the name for the new database.
When the app is loading the default data I make the following SQL call:
DBCC CHECKIDENT('[myDB].[CsSchema].[CsMyDataType]', RESEED) WITH NO_INFOMSGS
The code works fine as long as everything is in English.
But if the user specifies Chinese characters in the database name the call look like this:
DBCC CHECKIDENT('[e安丞北e].[CsSchema].[CsMyDataType]', RESEED) WITH NO_INFOMSGS
This call fails with this error message:
"Could not find database 'e???'. The database either does not exist, or was dropped before a statement tried to use it."
I make many other calls with the database name that work properly. For example, this statement executes without an issue.
SET IDENTITY_INSERT [e安丞北e].[CsSchema].[CsMyDataType] OFF
The error seems to be specific to the DBCC CHECKIDENT call. Any ideas?
Note: I'm running on Chinese version of Windows XP.
Try passing the string as unicode (see KB):
DBCC CHECKIDENT(N'[e安丞北e].[CsSchema].[CsMyDataType]', RESEED) WITH NO_INFOMSGS
This is a problem I have seen other people besides myself having, and I haven't found a good explanation.
Let's say you have a maintenance plan with a task to check the database, something like this:
USE [MyDb]
GO
DBCC CHECKDB with no_infomsgs, all_errormsgs
If you go look in your logs after the task executes, you might see something like this:
08/15/2008 06:00:22,spid55,Unknown,DBCC CHECKDB (mssqlsystemresource) executed by NT AUTHORITY\SYSTEM found 0 errors and repaired 0 errors. Elapsed time: 0 hours 0 minutes 0 seconds.
08/15/2008 06:00:21,spid55,Unknown,DBCC CHECKDB (master) executed by NT AUTHORITY\SYSTEM found 0 errors and repaired 0 errors. Elapsed time: 0 hours 0 minutes 0 seconds.
Instead of checking MyDb, it checked master and msssqlsystemresource.
Why?
My workaround is to create a Sql Server Agent Job with this:
dbcc checkdb ('MyDb') with no_infomsgs, all_errormsgs;
That always works fine.
08/15/2008 04:26:04,spid54,Unknown,DBCC CHECKDB (MyDb) WITH all_errormsgs<c/> no_infomsgs executed by NT AUTHORITY\SYSTEM found 0 errors and repaired 0 errors. Elapsed time: 0 hours 26 minutes 3 seconds.
If you are using a maintenance plan you'd probably be better off use the check database integrity task. If you really want to run you own maintenance written in t-sql then run it using a step in a job, not in a maintenance plan and the code above will work ok. Like Stu said the GO statement is client directive not a sql keyword and only seems to be respected by isql, wsql, osql, etc, clients and the sql agent. I think it works in DTS packages. Obviously, not in DTSX, though.
For starters, always remember that GO is not a SQL keyword; it is merely a batch separator that is (generally) implemented/recognized by the client, not the server. So, depending on context and client, there really is no guarantee that the current database is preserved between batches.
You have a check datasbase integrity task and you double-clicked it choose MyDb and when the plan runs it only checks master?? weird. Are you sure you don't another plan running?