db2 stored procedure performance issue caused by table locks

Question

I have written a suite of stored procedures that insert records from staging tables to the main database tables. We have found performance issues recently and db2top shows that it has a high number of locks on the tables and we think this is the main cause of the poor performance.

The suite has a control stored procedure which calls each procedure that writes different groups of records to the database. One of the requirements was that the system processes all the records and report out the errors and depending on the errors that have been raised the controlled procedure decides whether to commit or rollback the whole batch at the end of each batch.

My understanding of locking is that to release the locks I would have to perform a commit or rollback to release the locks but this would cause records to be commited to the database before we know if we want to commit the batch.

Does anyone have any suggestions on how I could stop the high amount of locks without having to commit before the batch has completed?

Thanks for any help

Answer 1

Locks by themselves do not cause performance degradation. It is lock contention, that is, a competition between different applications for locked rows, that may cause poor performance. From your description it does not follow at all that locks are the culprit.

Now to answer your question, "how I could stop the high amount of locks": you need to choose the least strict isolation level that is still appropriate for your business logic and/or reduce the transaction size by limiting the number of rows in a single transaction. Another way to reduce the number of locks is to lock entire tables instead of individual locks, as @AngocA suggested, however, this usually increases contention thus hurting performance even more.

Answer 2

Depending on your design, you can use a temporary table where you will put all the rows to insert. Once you have decided which rows are going to be inserted in the main database table, you just insert them there. Probably, you are creating locks in the main tables, because you are inserting on them, and then, if a rollback is performed, those rows are still locked until the end of the rollback; something similar for the commit should happen.

You can use automatic lock list size, and eventually the maxlocks also automatic.

Finally, you can also lock the tables with a table lock instead of many row locks and an intent lock at table level, however the concurrence will be highly impacted.

Those are some recommendations, but all of them depends on your design.