Simple Query Hangs
SQL Server 2005..
I have a database procedure that has always worked quickly, recently it is hanging. I narrowed it down to one query with multiple joins, then dissected it to a single table and a simple where clause.
When entered directly into SQL Management Studio, this query hangs...
select * from myTable where Fkey = 123
Yet this query returns immediately..
select * from myTable
The column "Fkey" is a foreign key to a parent table. There is a foreign key constraint defined on it.
The database is in use, after a reboot, I can fetch from the table OK for a few minutes, then it just hangs. My last run (which I let go on and on) took 11 minutes to complete. There are only 100 records in this table !
After 11 minutes, this message was returned..
[Macromedia][SQLServer JDBC Driver][SQLServer]Transact
So if its a deadlock and all I'm doing is a select.. how do I figure out why its deadlocking and how do I keep it from happening?
Thanks!
I have a database procedure that has always worked quickly, recently it is hanging. I narrowed it down to one query with multiple joins, then dissected it to a single table and a simple where clause.
When entered directly into SQL Management Studio, this query hangs...
select * from myTable where Fkey = 123
Yet this query returns immediately..
select * from myTable
The column "Fkey" is a foreign key to a parent table. There is a foreign key constraint defined on it.
The database is in use, after a reboot, I can fetch from the table OK for a few minutes, then it just hangs. My last run (which I let go on and on) took 11 minutes to complete. There are only 100 records in this table !
After 11 minutes, this message was returned..
[Macromedia][SQLServer JDBC Driver][SQLServer]Transact
So if its a deadlock and all I'm doing is a select.. how do I figure out why its deadlocking and how do I keep it from happening?
Thanks!
ASKER
Thanks cs. But I have tried "with (NOLOCK)" and it doesn't help.
Any idea how I can track down the code that is involved in the lock?
Any idea how I can track down the code that is involved in the lock?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
start a sql profiler and you will be able to capture rpc starting and sql starting and rpc completed and sql st completed and deadlock and lock... (analyse the trace and u can find out which transaction were blocking and deadlocked)
Also doing a sp_who2 or trying the procedure above will help too.
also have u a index on the Fkey column of your table. Have they been rebuilt lately. This will speed up your query.
Also doing a sp_who2 or trying the procedure above will help too.
also have u a index on the Fkey column of your table. Have they been rebuilt lately. This will speed up your query.
ASKER
surprisingly, the script doesn't indicate any deadlocks.
I know I had deadlocks sometimes when run, other times the query just goes on for 4+ minutes. I used to run this query along with dozens of others in db procedures in less then 4 seconds, now this one query takes 4 minutes with very small tables (less than a couple hundred records in most). So its hard to see if its temporary deadlock or what..
I will try to get sql profiler installed, thanks for that wiz..
I know I had deadlocks sometimes when run, other times the query just goes on for 4+ minutes. I used to run this query along with dozens of others in db procedures in less then 4 seconds, now this one query takes 4 minutes with very small tables (less than a couple hundred records in most). So its hard to see if its temporary deadlock or what..
I will try to get sql profiler installed, thanks for that wiz..
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Wiz, could you explain what that would do ?
Would I place it at the top of each procedure that I run?
thanks!
Would I place it at the top of each procedure that I run?
thanks!
Run a check on the table, just to be sure there isn't some corruption that is causing this problem.
USE yourDbName
DBCC CHECKTABLE ('tableName')
Also, a full scan won't use an index, the = single value should. So rebuild the indexes on the table.
CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX index_name
ON tableName ( column1, ...)
WITH DROP_EXISTING
NOTE: Dropping and recreating the index(es) will make the table unavailable during that time.
USE yourDbName
DBCC CHECKTABLE ('tableName')
Also, a full scan won't use an index, the = single value should. So rebuild the indexes on the table.
CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX index_name
ON tableName ( column1, ...)
WITH DROP_EXISTING
NOTE: Dropping and recreating the index(es) will make the table unavailable during that time.
From BooksOnLine
READ UNCOMMITTED.
Specifies that statements can read rows that have been modified by other transactions but not yet committed.
Transactions running at the READ UNCOMMITTED level do not issue shared locks to prevent other transactions from modifying data read by the current transaction. READ UNCOMMITTED transactions are also not blocked by exclusive locks that would prevent the current transaction from reading rows that have been modified but not committed by other transactions. When this option is set, it is possible to read uncommitted modifications, which are called dirty reads. Values in the data can be changed and rows can appear or disappear in the data set before the end of the transaction. This option has the same effect as setting NOLOCK on all tables in all SELECT statements in a transaction. This is the least restrictive of the isolation levels.
READ UNCOMMITTED.
Specifies that statements can read rows that have been modified by other transactions but not yet committed.
Transactions running at the READ UNCOMMITTED level do not issue shared locks to prevent other transactions from modifying data read by the current transaction. READ UNCOMMITTED transactions are also not blocked by exclusive locks that would prevent the current transaction from reading rows that have been modified but not committed by other transactions. When this option is set, it is possible to read uncommitted modifications, which are called dirty reads. Values in the data can be changed and rows can appear or disappear in the data set before the end of the transaction. This option has the same effect as setting NOLOCK on all tables in all SELECT statements in a transaction. This is the least restrictive of the isolation levels.
ASKER
Thanks for your help. We had to put the project on hold because of this issue. Sorry to have disappeared. Your help was greatly appreciated! Although the issue still exists and is still a mystery. I will post new questions though..
hi, author, did you solve the problem ?, I have the same problem with a sql7 database, allways worked but since a few days ago, the same select, simply does not work,
ASKER
My problem may be different from yours, this resolution was rather unique..
Our dual nic cards where not correctly set to auto detect causing packets to be dropped and the queries to get deadlocked or hung. Other symptoms of the network card issue were slow copy times between folders on networked computers.
http://articles.techrepublic.com.com/5100-6329_11-5181472.html