Tag Info

New answers tagged

2

It sounds like the code might be using SAVEPOINTs to handle errors, and not releasing the savepoints before proceeding. That would explain the large number of virtual xid locks. RELEASE SAVEPOINT after you're done with a step. You might also want to consider batching the work into smaller chunks, as the: SAVEPOINT Try it ROLLBACK TO SAVEPOINT if it ...


1

It is difficult to explain your precise case without explain plans and engine profiling information. You may use pg_stat_statements module or PostgreSQL perf for tracing, but I am convinced your issue is the transaction size. It is known that the pattern of one transaction per row must be avoided for performance reason as commit overhead will slow down the ...


5

That SPID is already killed and you will have to wait for the rollback process to finish. The estimated time is usually wildly inaccurate: don't worry about it. It will probably take from 1 to 2 times the execution time of the INSERT until the stage when it was killed. If this happened in production, the answer would not be any different: wait for the ...


0

sorry for that late answer and my bad english :) currently i am working on a session-hybrid with ZebraSession and my own ClientCookie-Session Class. I nerver heard about GET_LOCK so i started to search for its usage. Now i am stumbled into your post. Maybe your (or all ZebraSession Users) Problem a) depends on the MySql Version you are running. b) You ...


0

The Blocked process report (which you have) can be a little confusing at first. There are a few important sections Blocking-Process This is the process(SP, query etc) that is causing the blocking. The process is using a resource that is required by the Blocked-Process Blocked-Process This is the process(SP, query etc) that is blocked and is waiting on a a ...


-1

If you have access to the db itself, you can run your application and take a look in the running requests (sys.dm_exec_request). There you'll find what query currently runs. You can also take a look at sys.dm_tran_locks which will give you a good overview of the requested locks on which ressource. Another idea is to run a profiler using the tsql replay ...


1

I you try to find out which lock is currently been taking. Just take a short look in the tran_locks. There you find all current locks. SELECT * FROM sys.dm_tran_locks WHERE resource_database_id = DB_ID() and request_session_id = [YOURSESSION] Hope this helps you. Another way could be the usage of WITH(HOLDLOCK) on your statement and append this code to ...


0

If you see below segment of the code CREATE DATABASE [TestTom] CONTAINMENT = NONE ON PRIMARY ( NAME = N'TestTom', FILENAME = N'G:\MSSQL11.MSSQLSERVER\MSSQL\DATA\TestTom.mdf' , SIZE = 1048576KB , FILEGROWTH = 1048576KB ) LOG ON ( NAME = N'TestTom_log', FILENAME = N'F:\MSSQL11.MSSQLSERVER\MSSQL\Data\TestTom_log.ldf' , SIZE = 1048576KB , FILEGROWTH = ...



Top 50 recent answers are included