Every morning we have a process that issues numerous queries (~10000) to DB2 on an AS400/iSeries/i6 (whatever IBM calls it nowadays), in the last 2 months, the operators have been complaining that our query locks a couple of files preventing them from completing their nightly processing. The queries are very simplisitic, e.g
Select [FieldName] from OpenQuery('<LinkedServerName>', 'Select [FieldName] from [LibraryName].[FieldName] where [SomeField]=[SomeParameter]')
I am not an expert on the iSeries side of the house and was wondering if anyone had any insight on lock escalation from an AS400/Db2 perspective. The ID that is causing the lock has been confirmed to be the ID we registered our linked server as and we know its most likely us because the [Library] and [FileName] are consistent with the query we are issuing.
This has just started happening recently. Is it possible that our select statements which are causing the AS400 to escalate locks? The problem is they are not being released without manual intervention.
Try adding "FOR READ ONLY" to the query then it won't lock records as you retrieve them.
Writes to the files on the AS/400 side from an RPG/COBOL/JPL job program will cause a file lock (by default I think). The job will be unable to get this lock when you are reading. The solution we used was ... don't read the files when jobs are running. We created a big schedule sheet in excel and put all the sql servers' and as/400's jobs on it in times slots w/ color coding for importance and server. That way no conflicts or out of date extract files either.
You might have Commitment Control causing a lock for a Repeatable Read. Check the SQL Server ODBC connection associated with <linkedServerName> to change the commitment control.
Related
using MS SQL server 2016, we have sporadic transaction timeouts due to locking issues (once every 2 days).
The statement failing is select ... (nolock) from table where id in (...,...,...,...).
The activity is high and we couldn't find the cause of the issue.
My question: how is it possible, in case of rollback/timeout, to record in a log (event viewer, trace file, text file, anything) the statements run by the sessions causing the issue, so that we can figure out afterward what happened?
Thanks.
We use monitoring software SentryOne and Solarwinds offers the ability to monitor and record activity in the spids involved in blocking/deadlocks. I am not advocating using this software and running SQL profiler or extended events might give you the same results, I am just posting that this is how we do it.
I'm newbie as a SQL Server DBA , everyday at least once I've got a deadlock issue in SQL Server 2012 server which is using Merge statement. There are no clause like NOLOCK, UPDLOCK, HOLDLOCK has been used in the merge statement. It's a multi user environment where the Biztalk reads the xml and save data into SQL Server.
Per minute, Biztalk reads 300 xml messages. Since its a production server I can't implement anything just like that without doing research, but I haven't got any idea on how to resolve this issue. Recently I had an issue with two xml messages trying to update data in a table and trying to use the same index and error-ed out. Could anyone help me how to get away with this issue?
The scan phase of MERGE is performed with a shared lock (S), optimized for the case of a single session running MERGE and concurrent sessions running SELECT. In the case of multiple concurrent MERGE statements, this can lead to deadlocks or failures.
The solution you should add a HOLDLOCK hint on the target table. This is a little bit inconsistent with other read-for-update patters which use UPDLOCK on SELECT.
I am using SQL Server 2012. I am bot able to select rows from a table "Prime.ProductMaster".
When I write query like Select * from Prime.ProductMaster then it continue executing forever.
When I run the same query with Nolock. i.e Select * from Prime.ProductMaster WITH(NOLOCK) it executes.
I have investigated on this and found the problem that after row No 2778 the problem exists. I think table might be locked by some other process.
Could anyone please help me how to overcome from this issue. I cant restart sql server as it is shared by many people.
You can right click on our SQL instance name and view Activity Monitor, alternately, click the icon on the far right of your screen shot.
Underneath Resource Waits you should see a row that indicates any Lock that might be held. If this reads 0 there are no locks, otherwise some other process is creating and holding a Lock on the table or rows.
Underneath Processes, you should be able to see active connections, which you can filter by Database and in your case, perhaps Wait Type, to identify the process that is holding the Lock. Whilst this may indicate the cause and you could simply right click and kill process, depending on the application scenario I would use this information to investigate the issue/code that is causing this Lock.
If it's not clear, you may need to profile your database using SQL Server Profiler to track the root cause of the Lock. I would suggest setting up the profiler to check for Locks and possible Deadlocks to filter out "noise" from the trace.
If you need info on how to profile Locks, take a look at this video.
I'm using SQL Server 2012 and I'm stuck with a strange problem.
I tried to restore a database snapshot to a database. Usually it doesn't take much time to restore, but now it took 5 minutes and is still restoring, so I stopped query execution. It was trying to stop the query execution for more that 5 minutes, so i closed SSMS using task manager.
Then I tried to kill the restore process using KILL.
Now I am able to can connect to that server, but the list of databases is not opening. I mean: whoever is connected to this server, they are not able to get the databases. When I checked the sysprocesses table, it is showing lastwaittype as LCK_M_S.
None of my users can see databases. Looks like I kind of messed up. I cannot restart SQL Server as others are connected to the server.
How do I solve this? Please help.
EDIT:
i tried this approach and when i checked with
select db_name(dbid), * from sysprocesses where blocked <> 0
i got two records,
do you think because of these two rest of the process are getting locked up.
I'm guessing there still is some hidden lock on the sysdatabases table in the master database. This could very well be caused by the KILL of the restore command.
The article here might help you:
http://ellisweb.net/2012/02/clearing-out-a-mysterious-table-lock-lck_m_s-in-sql-server-2008/
It basically advises you to identify where the hidden lock is coming from, and then issuing a KILL on that process ID.
Try restarting the instance. Can't hurt if your users can't see any of the databases anyway.
I have a scheduled job with a SP running on daily basis (SQL Server 2005). Recently I frequently encounter deadlock problem for this SP. Here is the error message:
Message
Executed as user: dbo. Transaction (Process ID 56) was deadlocked on thread |
communication buffer resources with another process and has been chosen as the deadlock
victim. Rerun the transaction. [SQLSTATE 40001] (Error 1205). The step failed.
The SP uses some inter joined views to some tables, one of them is a large size data table with several million rows of data(and keep growing). I am not sure if any job or query against to the table will cause the SP un-accessible to the table? I am going to investigate who is on line by using the query. That may expose some query or person on SQL server during that time.
Not sure if any one have similar issue or this is known SQL 2005 issue? Any additional way I should do in my SP or on SQL server to avoid the deadlock?
Use the SQL Server Profiler to track all the queries that are running. I put the output into SQL Server. This will help you figure out which ones are accessing your particular table / tables. Post your findings, and we can help you with that.
Deadlocks are when two transactions are each holding onto some resources and want a resource that the other one has as well - neither can proceed as they are both waiting for each other. They cannot be completely eliminated, but a lot can be done to mitigate them. Remus and Raj suggest capturing more information about them in Profiler - which I also recommend - generally optimizing your queries (if you know which ones are involved) can also help. Here is an MSDN article that can help get you going: "Minimizing Deadlocks".