I'm late to the party as usual, but just hit this issue for the first time. We handle -2 blocking with a process that alerts us when it happens and generates the KILL 'UOW' line... but this must be the first "prepare state" condition we've hit...
Trace the UOW back to the originiating host via sys.dm_exec_requests and terminate the DTC transaction from the source, that should resolve the issue.
Can you elaborate on this a bit? The "normal" KILL 'UOW' fails and prompts to use the COMMIT/ABORT syntax. ABORT gets another error and COMMIT appeared to work but the UOW was still there.
I'm trying to figure out what row(s) in sys.dm_exec_requests are related to the -2 rows in syslockinfo but I'm not seeing it; transaction_id is CLOSE to req_trasactionID but doesn't match...
Once I have the right row(s)... what breadcrumbs do I follow to find the source of the bad transaction?
Thanks in advance for your time
EDIT: uhhh... oops... "nevermind" :pinch:
... I'd already scanned through the other posts... I tried Wayne's link but due to the "//[u" at the END of the link-- it sent me instead to his piece about understanding-rebinds-and-rewinds... yikes... THEN I noticed the URL didn't LOOK like that's where it was s'posed to go...ooooOOOOooooo :Whistling:
But I am still kinda curious how I could'a used sys.dm_exec_requests to get to the source.