What is this process in Sql Server Activity monitor? - sql

There is a process that seems to be running all the time in SQL Server 2005 activity monitor. Double clicking on it produces the following query:
CREATE TABLE #tmpDBCCinputbuffer ([EVENT TYPE] NVARCHAR(512),
[PARAMETERS] INT, [EVENT Info] NVARCHAR(512))
INSERT INTO #tmpDBCCinputbuffer EXEC ('DBCC INPUTBUFFER(58)')
SELECT [EVENT Info] FROM #tmpDBCCinputbuffer
Any idea what it is? Is it dangerous?

Ironically, its the query you use to see the last query run on a connection, which is what you are doing to see what all the connections' last queries were. Including the connection you use to look at all those connections.
where's the dizzy emoticon when you need it?

http://msdn.microsoft.com/en-us/library/ms187730.aspx
Quote from SQL Server Developer Center
"DBCC INPUTBUFFER permissions default
to members of the sysadmin fixed
server role only, who can see any
SPID. Other users can see any SPID
they own. Permissions are not
transferable."
(http://msdn.microsoft.com/en-us/library/aa258826(SQL.80).aspx)

I just want to share another answer which further explains Neil N's answer.
The DBCC INPUTBUFFER(spid) command will return the text of the most recent batch executed against a specified SPID. When you double-click on a row in Activity Monitor (or right-click and select 'Details') then, under the covers, SQL Server runs the command you quoted in your post above (substituting the SPID of the selected row - 61 in your example) to return the most recent batch issued against the connection. In your example the batch actually happens to be the CREATE TABLE etc... batch that was issued by Activity Monitor to return the most recent batch!
by Chris Howarth https://social.msdn.microsoft.com/Forums/sqlserver/en-US/6bbe405b-b7d8-4f97-9150-cf03c59d4fe3/process-wont-die?forum=sqldatabaseengine
The number 58 is what it will always return because it's its Process ID and it's the last process you run!

Related

SQL - Table waiting for Commit/Rollback after closing session

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.

SQL Drop View Statement Takes Forever to Complete

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.

Creation time of a lock in SQL Server 2008

So I'm trying to monitor the longest living lock in my database. The idea is that if a lock has been held for a certain amount of time, I will receive a warning in my application.
But for the life of I can't find the creation time of the locks.
I have used:
exec msdb..sp_lock
exec msdb..sp_who2
SELECT * FROM sys.dm_tran_locks
select * from sys.syslockinfo
select cmd, * from sys.sysprocesses where blocked > 0
But none of these seem to have the information I need.
Any ideas?
G
A long running transaction makes more sense which you can do by looking at database_transaction_begin_time column in sys.dm_tran_database_transactions
I've never known anyone to try and monitor locks... which is possibly why there is no start date/time information for them...
The Lock:Acquired EventClass in SQL Profiler has StartTime and EndTime. You might want to check that

Simplest SQL query never returns

I have a SQL query that is quite simply select * from tblOrders where customerID = 5000but it never returns. I waited 10 minutes and gave up.
The weirdest thing is that other queries on the same DB, but on another table, works fine. Removing the where-clause doesn't help either, so it seems like the table is somehow not responding. It's about 30000 lines, so it's not the biggest table either.
I'm using MS SQL SMS 2008 Express against a SQL Server 2008 express running on a remote server.
Try this to by-pass any locks on table -
select * from tblOrders(nolock) where customerID = 5000
It sounds like your table is locked
run this query to see what locks are held against it.
USE master;
GO
EXEC sp_lock;
GO
but table locking is a whole mindfield of its own
here is some info in the sp_lock system stored proc
http://msdn.microsoft.com/en-us/library/ms187749.aspx
when you find the lock you can kill it
KILL { session ID | UOW } [ WITH STATUSONLY ]
http://msdn.microsoft.com/en-us/library/ms173730.aspx
I agree with the others that this is most probably a locking issue. By default write access to a table still blocks read (only) access.
Since SQL Server 2005 this can be fixed by using the "row versioning". You need to change the settings of the database to enable this.
See the manual for a more detailed explanation:
http://msdn.microsoft.com/en-us/library/ms345124%28SQL.90%29.aspx

How can a SQL Sever TSQL script tell what security permissions it has?

I have a TSQL script that is used to set up a database as part of my product's installation. It takes a number of steps which all together take five minutes or so. Sometimes this script fails on the last step because the user running the script does not have sufficient rights to the database. In this case I would like the script to fail strait away. To do this I want the script to test what rights it has up front. Can anyone point me at a general purpose way of testing if the script is running with a particular security permission?
Edit: In the particular case I am looking at it is trying to do a backup, but I have had other things go wrong and was hoping for a general purpose solution.
select * from fn_my_permissions(NULL, 'SERVER')
This gives you a list of permissions the current session has on the server
select * from fn_my_permissions(NULL, 'DATABASE')
This gives you a list of permissions for the current session on the current database.
See here for more information.
I assume it is failing on an update or insert after a long series of selects.
Just try a simple update or insert inside a transaction. Hard-code the row id, or whatever to make it simple and fast.
Don't commit the transaction--instead roll it back.
If you don't have rights to do the insert or update, this should fail. If you DO, it will roll back and not cause a permanent change.
try the last insert/update up front with some where condition like
insert/update
where 1=2
if (##error <> 0)
raise error 6666 'no permissions'
this would not cause any harm but would raise a flag upfront about the lack of rights.