I have a SQL Server 2005 database that keeps locking and won't release. My application cannot commit updates to the database because there are tasks that are waiting to be processed and my app keeps crashing. If I look on activity monitor, waiting tasks just keeps going up and up until I kill the process. The problem is I can see what is in activity monitor that is causing the lock but I do not have enough information it just says blocked by session ID.
Is there any way by using TSQL to find out what that process is exactly and what is it doing? i.e. query for locks on database with long wait time and how to force them to release, or prevent them?
Try sp_lock #ProcessID then pick out the exclusive locks (mode = X or IX). You can then find out the offending objects using SELECT object_name(id). The ID is obtained from the ObjId column.
Use the Deadlock Graph event in Profiler: See Track Down Deadlocks Using SQL Server 2005 Profiler
Related
I am doing a concurrency test in sql server 2019, I have SQLTest tool that runs concurrent queries, in my test I am using one single SELECT query (star schema) and on SSMS I have while loop that updates fact table records. while running both process I am seeing some of the threads/queries cancelled because of deadlock, which is expected but the option that I am looking or is there a possibility to add a wait time on my select before deadlock? in other words how much time SQL server waits before it creates deadlock error.
In this case I know constant updates are happening but we know that updates are for a fewer seconds so if SQL server can wait for some seconds before creating deadlock.
any suggestions or thoughts ?
I would suggest changing up your testing strategy a little.
Within your test harness, I would SET DEADLOCK_PRIORITY LOW;, so that when a deadlock is detected, your testing process voluntarily takes one for the team, allows itself to become the deadlock victim, and allows the conflicting process to continue.
Then, wrap the testing script in a TRY...CATCH. In the CATCH clause, check to see if the cause of the error is a deadlock (error code 1205), and if it is, retry your test. It's probably a good idea to also build a incremental counter into that so that you don't end up in an infinite deadlock loop.
is there a possibility to add a wait time on my select before deadlock?
No. It would make no sense.
A deadlock is defined as a dead end of locking, which will not, under no circumstrances, be fixed by simply waiting. One of the sides has to cancel.
I.e.
Tx1 has lock on table a, waits for lock on table b
Tx2 has lock on table b, waitf for lock on table a
Normally SQL Server waits (timeout) and cancels. In this case the deadlock detection steps up and realizes that no, unless a side is thrown out there is no way this gets resolved, so - it cancels one side. There is no waiting, because this is actually a programming bug. No joke.
Up there, Tx2 should FIRST ask for a lock on table a. It is good practice to get locks in a transaction in a defined order so this does not happen.
I have an application that is connecting to a SQL server to run some inserts/updates. We've been getting deadlocks, But I’ve noticed that in addition to reporting the deadlock, the connection to the database is dropped and the client has to reconnect.
Is this normal? Even if it's not normal behaviour, is it possible that SQL server is not only deciding that my client will be the deadlock victim, but it is also terminating the connection?
Is there a way to stop the connection being dropped?
By definition a deadlock means two connections are stuck where SPID 1 has something locked that SPID 2 needs and SPID 2 has something locked that SPID 1 needs. Neither can complete their transaction because they need something the other has locked. In cases like this the server will choose a victim SPID and kill it so the other can complete its transaction.
The only way to stop it is to figure out why the deadlocks are occurring in the first place. You can run a trace to monitor deadlocks and capture the information relating to them into a diagram and then view the diagram in SSMS.
More information available here: http://www.simple-talk.com/sql/learn-sql-server/how-to-track-down-deadlocks-using-sql-server-2005-profiler/
This sounds pretty strange, but there is ocurring in a databases of a bunch we've got in a server, we can tell by the output on the log, but this seems to be affecting another databases, since the systems hungs when the deadlock occur.
We've identified the objects involved in the deadlock event, but none lives in the databases from the system we are using.
I still need to look at the procedure bodies, but is this possible? processes from other databases entering in deadlock and hunging the entire server or other databases?
A deadlock is not a fatal event in MS Sql Server (unlike, eg., in code). This is because Sql Server will periodically scan for deadlocks, and then pick one of the of the processes to kill. That's when you get the log messages.
Absent a Sql Server bug (which I've never encountered), I'd think it's more likely that the order is reversed - the hung server/database prevents normal execution of queries, resulting in deadlocks as procedures take longer to execute.
I have seen this happen when two processes that are in a deadlock also have objects locked in TempDB.
The locked objects in tempdb then stop other processes from being able to create objects and thus hang.
This was an issue on older versions of SQL Server (2000), but I can't recall seeing it on more recent version.
it is possible. if your server can't react to any interupt it can't execute other requests (correctly).
I have a table with ~800k rows. I ran an update users set hash = SHA1(CONCAT({about eight fields})) where 1;
Now I have a hung Sequel Pro process and I'm not sure about the mysqld process.
This is two questions:
What harm can possibly come from killing these programs? I'm working on a separate database, so no damage should come to other databases on the system, right?
Assume you had to update a table like this. What would be a quicker / more reliable method of updating without writing a separate script.
I just checked with phpMyAdmin and it appears as though the query is complete. I still have Sequel Pro using 100% of both my cores though...
If you're using InnoDB, which is backed by a transaction log for recovery and rollback purposes, then you can get away with a lot, especially in a non-production environment.
The easiest way to terminate a renegade query is to use the MySQL shell as the root user:
SHOW PROCESSLIST;
This will give you a list of the current connections and a process ID for each one. To terminate any given query, such as number 19, use:
KILL 19;
Usually this will undo and roll back the query. In some cases this is not sufficient and you may have to force-quit the MySQL server process with kill -9. Under most circumstances you should be able to restart the server right away, and the DB will be in the last fully committed state.
To get the thread IDs (it'll show the query alongside):
mysqladmin proc
To safely kill the query thread:
mysqladmin kill [id]
You'll end up with a partially updated table unless you use innodb, but you should be fine. Details:
During UPDATE or DELETE operations,
the kill flag is checked after each
block read and after each updated or
deleted row. If the kill flag is set,
the statement is aborted. Note that if
you are not using transactions, the
changes are not rolled back.
As for your second question, there is no better way to update a table if one is not allowed to write a separate script (to, say, throttle the updates).
If i have a stored procedure or a trigger in Sql Server 2008, can it do some sql calculations 'in another non-blocking thread'? ie. something in the background
also, can two sql code blocks be ran in parallel? or two stored procs be ran in parallel?
for example. Imagine we are given the job calculating the scores for each Stack Overflow user (and please leave all 'do that elsehwere/service/batch/overnight/etc, elswhere) after a user does some 'action'.
so we have a trigger on the Post table, so when a new post is INSERTED, the trigger fires off and part of that logic, it calculates the user's latest score. Instead of waiting for the stored proc to finish and block the current sql thread / executire, can we ask it to calc the score in the background OR parallel.
cheers!
SQL Server does not have parallel or deferred execution: each block of running code in a connection is serial, one line after the other.
To decouple processing, you usually have to use SQL Server Agent jobs or use Service broker. These start executing in a new connection, new session etc
This makes sense:
What if you want to rollback your changes? What does the background thread do and how does it know?
What data does it use? New, Old, lock wait, snapshot?
What if it gets ahead of the main thread and uses stale data?
No, but you could write the request to a queue. Service Broker, a SQL Server component, provides support for this kind of thing. It's probably the best option available for asynchronous processing.