I have a SQL Server 2008 R2 Enterprise database with a view on it called vw_Users.
-Running (Select * from vw_users) takes less than a second to complete.
-Running the SQL inside of the view takes less than a second to complete.
-Running (drop view vw_Users) just hangs and never actually completes. I let it run for about 10 minutes before I cancelled it.
I restarted the SQL Server Agent, then tried again, but it's still occurring.
This is a brand new issue, this server and this database have been running fine for over a year.
There are no indices on the view. I'm not sure what the problem is, but any help would be very appreciated.
Thanks
Someone or something has an open connection accessing that view and you are being blocked.
You can check this by starting your DROP, then in another window in SSMS running:
sp_who2 active
You should see a row with your spid, and the blocked_by field will have another spid number in it. Find that spid to see what is blocking you.
If it can be safely terminated, either close the process manually or from within SSMS run:
kill x
...where x is the spid of the blocking process.
Related
I have a large table without any indexes on it, about 27.5m rows.
I tried to delete about half of those using using BEGIN TRAN.
I then tried canceling the querie, but because it was taking long I decided to just close the Management Studio.
Now when I try to look into that table, it does not return anything, just keeps running.
When I run SELECT TOP 10 * FROM Tbl it just executes without returning anything.
But when I run SELECT TOP 10 * FROM Tbl(NOLOCK) it return 10 rows.
This tells me that it is waiting on a Rollback/Commit from my BEGIN TRAN.
I thought it would rollback automatically after closing the session and Management Studio.
How do I fix this issue?
Thanks.
Execute SP: SP_LOCK
In Results you will get SPID, DBID, OBJID, INDID, TYPE, RESOURCE,
MODE, STATUS
Now check the status column, if it is showing wait then
kill that SPID. To kill a particular SPID Execute SP: Kill 65 (Where
65 is SPID)
MSDN Forum
Apparently, this worked:
Terminate/Close connection to the database would solve this. To close connection you can try terminating sqlserver.exe from Task Manager or Activity Monitor if you have a Mac.
I've been experiencing a strange situation with a specific SELECT on SQL Server 2008 Standard.
I have a proc that executes a bunch of commands.
One of the last tasks is to insert the result of a select statement into a table. This proc is executed for each step of a job (with 20 steps) just changing one parameter, store code (the company has 20 stores).
This insert-select command normally executes in 2 minutes, but sometimes, it gets stuck with an SOS_SCHEDULER_YIELD lastwaittype and hangs forever... until I kill the process. After that, if I execute the same command, it executes in the normal 2 minutes.
I noticed that it doesn't matter if the CPU has 99% usage or 1%, or if there are other processes executing at the same time. I didn't find any pattern with these events. It just happens sometimes (almost every day with one or two steps).
Has anyone experienced this? I don't know what to do; I made a job to kill the process and execute it again if it hangs in SOS_SCHEDULER_YIELD for a long time, but I'd like to have a solution.
Thanks.
i got this error
timeout value expired. The timeout period elapsed prior to completion
of the operation or the server is not responding
i have a process, which do inserts and update at night, another process
which does query at nights too, (etl or dts) at sql server 2005 so, now we need to do a query to this table, and this doesn't work, i want to run my process again, and this never finish, and noneone can do a query to this table, (another tables could do) users commented me, yesterday they could do, but today, they coulden't is it posible, my process is execute at night has never finished, and it let a begin transaccion open?
how can i to be sure of this? and close it from ssms ?
this is not a problem of permissions we could do queries and inserts/updates yesterday.
it happens only with one table.
Try this:
SELECT TOP 1 * FROM Table (nolock)
Does that return results? If so, sounds like a locking issue..
I have a SQL Server 2008 database and I have a problem with this database that I don't understand.
The steps that caused the problems are:
I ran a SQL query to update a table called authors from another table called authorAff
The authors table is 123,385,300 records and the authorsAff table is 139,036,077
The query took about 7 days executing but it didn't finish
I decided to cancel the query to do it another way.
The connection on which I was running the query disconnected suddenly so the database became in recovery until the query cancels
The server was shut down many times afterwards because of some electricity problems
The database took about two days and then recovered.
Now when I run this query
SELECT TOP 1000 *
FROM AUTHORS WITH(READUNCOMMITTED)
It executes and returns the results but when I remove WITH(READUNCOMMITTED) hint it gets locked by a process running on the master database that appears only on the Activity Monitor with Command [DB STARTUP] and no results show up.
so what is the DB STARTUP command and if it's a problem, how can I solve it?
Thank you in advance.
I suspect that your user database is still trying to rollback the transaction that you canceled. A general rule of thumb indicates that it will take about the same amount of time, or more, for an aborted transaction to rollback as it has taken to run.
The rollback can't be avoided even with the SQL Server stops and starts you had.
The reason you can run a query WITH(READUNCOMMITTED) is because it's ignoring the locks associated with transaction that is rolling back. Your query results are considered unreliable, but ironically, the results are probably what you want to see since the blocking process is a rollback.
The best solution is to wait it out, if you can afford to do so. You may be able to find ways to kill the blocking process, but then you should be concerned with database integrity.
I have 2 SQL 2005 servers SRV1 and SRV2. SRV2 is the linked server on SRV1. I run a storep proc with params on SRV2 and it is completed immediately. But when I run the same proc through the linked server on SRV1, for example EXEC [SRV1].DB_TEST.dbo.p_sample_proc it takes about 8-10 minutes to complete. After restarting SRV2 the problem is gone. But some time later it returns. Does anyone have any ideas what it could be?
Might need more rights on SRV2, says Linchi Shea in this article
The login used need to run DBCC SHOW_STATISTICS
Edit: After andomar's comment: what does this do?
SELECT * FROM OPENQUERY ('SRV1', 'EXEC DB_TEST.dbo.p_sample_proc')
In SQL Server Management Studio, check Management -> Activity Monitor on SRV2. That should show you the state of the process that's running p_sample_proc. Maybe it is blocking on a lock from some other process.
It's safe to say that resetting a server removes all locks, and maybe the blocking application takes a while to reconnect to SRV2.