I have implemented SQL Server Service Broker with error handling according to this article by Remus Resanu.
When I ran the process and the activation script got kicked off but never stopped processing. According to the SQL Server log file it looks like I have a typo in my error handling and it is now stuck in an infinite loop.
I have tried to kill the process using kill <pid> but I get the message Only user processes can be killed. I have also tried restarting the server but the activation script would start again.
How do I kill the runaway activation process?
I was not able to find a solution through google/bing search. I eventually remembered that we enabled the Service broker through a SQL command, so I tried disabling it and that seems to have worked:
ALTER DATABASE dbname SET DISABLE_BROKER;
It looks like undocumented feature. If activated procedure do not issue END CONVERSATION it keeps restarting in an infinite loop. So, to stop it you need to make it successfully run END CONVERSATION of any dialog. If the queue gets disabled due to poison message detection you need to drop it to stop activation proc - no need to reset broker. I did not found either solution to this problem out there so I played with it a bit and hope this gives you a hint.
Related
I am using SQL Server 2016, and have some Jobs running in the SQL Server Agent. Today I found one of the job is taking too long (10hours!) to run and is still processing, so I try to stop that. I tried right-click and stop the job, it showed a success message. However, when I go to the Job Activity Monitor, it is showing that the job is still running! I also tried the following code:
USE [msdb]
GO
EXEC dbo.sp_stop_job N'Process Reserving MI (except problematic tables)'
GO
It also says the job stopped successfully. But again when I go to the Job Activity Monitor, it is showing that the job is still running!
Can any one please help?
At the end I have to ask the server team to reboot the server in order to solve this problem
My application executes many queries and it is sure that all connections are closed well. PgAdmin shows many queries have gone "Idle in transaction" and finally DB becomes unresponsive. Is there a way to get the query caused to be 'Idle in transaction' ? Or any other tool which can track it ? Postgres 8.1 is used.
Edit: Connection Pool is used. Also, the state ' in transaction' got cleared after couple of minutes. Then, if any connection is opened, how this get cleared ?
If you check information in Postgres documentation regarding this:
idle in transaction (waiting for client inside a BEGIN block), or a
command type name such as SELECT. Also, waiting is attached if the
server process is presently waiting on a lock held by another server
process
I would suggest following things:
enable logging of "long queries" using log_min_duration_statement
and log_lock_waits option in postgresql.conf in Error Reporting and Logging section
check Lock Management parameters of postgresql.conf configuration file,deadlock_timeout option in particular
check Lock Monitoring article on Postgres Wiki and pg_locks view in Postgres
This is clean signal, so some about closing transaction and closing sessions is wrong in your application. The queries works well. Check your application - unexpected exceptions, fails, ... Some applications are pretty buggy - usually it is pretty serious problem. Orphaned transactions block VACUUM and block reusing connections.
I'm trying to setup a NetScaler (version 9.3) monitor to determine which SQL server my database is running on (principal / mirror). The query I'm using is:
select mirroring_role_desc from sys.database_mirroring where database_id = DB_ID('OperationsManager')
The query works fine running under the user credentials that I created. The problem is, whenever the query comes from the NetScaler it's not completing. In the SQL Profiler trace it's showing an abort / rollback and I have no idea why.
I've enabled literally every trace event, including all the errors, to try to see why it's not completing and I've gotten nowhere. There are no Reads and no RowCounts. The connection appears to be aborting, but not from any sort of error.
This is what profiler looks like when it runs from the NetScaler
This is what it looks like when I run the same query, as the same user, from SSMS.
I thought maybe the NS was closing the connection too early so I upped the response timeout from 2s to 30s. That didn't make any difference. I'm completely baffled.
Can you let us know the version of NetScaler code you are running, and paste in the monitor CLI command from the CLI?
Also - you need to add a semi colon at the end of your query.
Add a semi colon to the end of your SQL statement in the monitor string. Otherwise the statement is not executed.
We are running a website on a vps server with sql server 2008 x64 r2. We are being bombarded with 17886 errors - namely:
The server will drop the connection, because the client driver has
sent multiple requests while the session is in single-user mode. This
error occurs when a client sends a request to reset the connection
while there are batches still running in the session, or when the
client sends a request while the session is resetting a connection.
Please contact the client driver vendor.
This causes sql statements to return corrupt results. I have tried pretty much all of the suggestions I have found on the net, including:
with mars, and without.
with pooling and without
with async=true and without
we only have one database and it is absolutely multi-user.
Everything has been installed recently so it is up to date. They may be correlated with high cpu (though not exclusively according to the monitors I have seen). Also correlated with high request rates from search engines. However, high cpu/requests shouldn't cause sql connections to reset - at worst we should have high response times or iis refusing to send response.
Any suggestions? I am only a developer not dba - do i need a dba to solve this problem?
Not sure but some of your queries might cause deadlocks on the server.
At the point you detect this error again
Open Management Studio (on the server, install it if necessary)
Open a new query window
Run sp_who2
Check the blkby column which is short for Blocked By. If there is any data in that column you have a deadlock problem (Normally it should be like the screenshot I attached, completely empty).
If you have a deadlock then we can continue with next steps. But right now please check that.
To fix the error above, ”MultipleActiveResultSets=True” needs to be added to the connection string.
via Event ID 17886 MSSQLServer – The server will drop the connection
I would create an eventlog task to email you whenever 17886 is thrown. Then go immediately to the db and execute the sp_who2, get the blkby spid and run a dbcc inputbuffer. Hopefully the eventinfo will give you something a bit more tangible to go on.
sp_who2
DBCC INPUTBUFFER(62)
GO
Use a "Instance Per Request" strategy in your DI-instantiation code and your problem will be solved
Most probably you are using dependency injection. During web development you have to take into account the possibility of concurrent requests. Therefor you have to make sure every request gets new instances during DI, otherwise you will get into concurrency issues. Don't be cheap by using ".SingleInstance" for services and contexts.
Enabling MARS will probably decrease the number of errors, but the errors that are encountered will be less clear. Enabling MARS is always never the solution, do not use this unless you know what you're doing.
In SQL Server, is it possible to call a long-running stored procedure, close the connection and let it finish? I don't care about the result. Essentially I want to say "Hey SQL, do this work on your own server."
I want to avoid having to make some service to sit with the open connection and wait for it.
You'll want to use BeginExecuteNonQuery(AsyncCallback, Object), and then have a callback method that effectively does nothing. It's worth mentioning that the connection won't actually be closed, however.
MSDN SqlCommand.BeginExecuteNonQuery Method
Alternatively, you could use Service Broker to queue the request to run a stored procedure. There's a fair bit of plumbing to set up, though. It might not be worth it in your situation. Especially if you aren't using Service Broker for anything else. The advantage here is that the connection can be closed immediately after queuing with Service Broker, and placing messages into a queue is a very quick operation.
You could also use a SQL Agent job to run the procedure that has no schedule, then issue a SQL command to start the job with "EXEC msdb.dbo.sp_start_job #job_name = ''" If you have to change the command frequently it may not be ideal, but that can be done through SQL calls if needed.