Archives of the TeradataForum

Message Posted: Mon, 15 Jun 2009 @ 09:19:40 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

You don't mention which tool you are using. I'll assume this is your own program.

If you are doing row at a time inserts, then you are correct each insert is a row at a time. If you are doing an insert select, then you are in table lock territory (but shouldn't see a deadlock - just serialisation of your requests).

However, I've experienced a situation where my inserts were being performed within a transaction. I wasn't aware that I'd asked for a transaction - the code was the same as another routine that didn't suffer this problem.

Since I wasn't aware of the transaction, I wasn't committing each query. As a result I was accumulating row hash locks. If another user was performing a similar save, the result was a transaction being aborted due to deadlock.

I identified what was going on using the utility program lokdisp (you will need administrator privileges to run it). You should note that this problem was very easy to replicate with 2 users.

Another possible cause might be if you are doing multi-statement inserts. It is conceivable that if you are doing this that you may encounter a deadlock because by random chance your two requests for locks are for the same two row hashes but in different orders. However, I think this is a very low probability of occurring.

I hope this gives you some ideas.

Teradata Corporation
Glenn McCall
Canberra Australia

	<Prev	Next>		<<First	<Prev	Next>	Last>>