In our system, we are dropping some DML statements in Flat File and with the help of executing SQL task i am hitting it to Sybase DB, sometime select statement get hang. Don't know how can i resolve, i am updating the statistics also but still facing problem, there are 1000(Approx) of DML hit every 2-5 mins to sybase.
Please let me know the resolution
Related
I have Powershell script which runs the below SQL query. This script is scheduled to run every 5 minutes. Could you please tell me whether querying database every 5 minutes will cause database deadlock. Could someone please throw light on how deadlock works in SQL.
SELECT TOP 1000 * FROM TABLE1
I am not concerned about the data which I get from select query. I am pulling this data to check the response time. Does the parameter WITH(NOLOCK) prevent deadlock?
This script alone will never deadlock your table because it is just a SELECT.
Check your SQL Activity Monitor in SSMS to if any other processes are updating the table, because a deadlock happens when you select and update the record at the same time.
I ran into an issue where no queries could be executed at all against a single table in our database. The table was in a complete deadlock. I checked sp_whoisactive for answers and found the following.
A simple SELECT on this table with session id 172, was waiting for a DELETE query on this table with session id 478, which was waiting for an INDEX REORGANIZE on this table with session id 207, which was waiting for a simple SELECT on this table with session id 598.
After killing session 598 everything completed immediately. Afterwards, executing that same query that was keeping the table in a deadlock in a separate window in SSMS only took 2 seconds. I asked around and this query is executed by an Excel file. Apparently we have lots of Excel files floating around which run queries against our SQL database. Obviously this is extremely bad practice as the connection string can be found inside, but as with everything legacy that's just the way it is now until it is fixed.
When googling I'm finding a lot of resources about Excel actually locking tables. Now as far as my limited understanding of locks goes if the query executed by session id 598 would actually lock the table it should only do so for the duration of the query. And since running the query separately only took a few seconds I don't understand how it was running for over 12 hours. If I can trust the results of sp_whoisactive it wasn't waiting on anything else. So why didn't it complete?
Before I suggest something like adding WITH(NOLOCK) to every query in Excel files, which is just a patch and not a solution I'd like to find out why this happened so that we can avoid this in the future. What causes a deadlock like this and how can it be avoided?
Excel will do a page lock for the duration of the query and until the query is released, which is basically when the spreadsheet is closed. So, if the spreadsheet was left open by a user overnight or for an entire day, then the table would be locked. We have the same issue and we are trying to get the offending spreadsheets replaced with SSRS reports but not having much luck with the take up from staff because the Excel files do a lot of other things that SSRS doesn't.
I used to run very 'SELECT' query against a production database which are being actively updated every 5 minutes. Whenever I ran the 'SELECT' query, the database got deadlocks and connection-timeout.
What I am wondering is why even simple 'SELECT' query can cause those deadlocks; the execution time of the 'SELECT' query was just less than a second, and the number of result set was just one.
Often I didn't commit, after I ran the query and got result set in SQL management studio in 'autocommit' off mode. Can it cause deadlocks?
Your answers or explanations will be most appreciated.
Thank you folks in advance!
See this Technet article on deadlocking - it uses the case of a single table with only 2 rows to discuss how a deadlock can be created. Once you get into real-world systems with far more tables, connections and code-paths predicting and preventing deadlocks becomes much harder.
If you are 'just' executing a SELECT then why would you have autocommit mode off? This will hold any locks and block other connections until you commit/rollback.
Accidentally the same stored procedure was run twice at one time on our MS SQL Server 2008 R2. They were run from the same SQL Server Management Studio client and I tried to cancel them both. After 45 minutes neither process has cancelled. I read somewhere that it would help to close the query windows in SSMS so I did. However the tables the stored procedure should be writing to is still locked even though almost 20 hours has passed. I guess there is a deadlock. I hit cancel seconds after the stored procedure was initiated.
The table the stored procedure is reading from is not locked. The stored procedure is in CLR. It reads from a table, manipulate data and then use SqlBulkCopy to insert into three other tables.
The data in the tables the SP writes to can very easily be recreated. However I can neither drop nor truncate them due to the lock. I also tried KILL SPID with no result.
I have been thinking about restarting the server, but I guess it would not help because of SQL Servers data integrity.
I would really like some input on how release the lock. Several websites with lots of users depend on the database server so solutions that do not involve restarting would be much appreciated.
I have SQL Server 2008. I run a query in a table on a database. The weirdest thing keeps happening. I run a simple select statement on the table. I know there are 62 rows in the table but it gets stuck at row 48 and goes on "querying...". Waited already for hours and it didn't move on from there. I only know of two programs, and one reporting service connecting to that particular table and one other user. Does anyone have any idea on what could be causing this and how I could trace the source of the lock on that table?
As a side note, I noted that the logs only had a notice that Autogrow failed the day before I checked. Could this have something to do with it?
What if you do a
SELECT * FROM YourTable WITH(NOLOCK)
Does it still hang?
Additionally when it does appear to be blocked you can try running
exec sp_who2
And looking in the BlkBy column to see what process is blocking you.
If that doesn't shed any light this article gives some info on some DMVs that might help get some insight into reasons for waits.