From: Ian on
michael.spoden(a)web.de wrote:
> Thanks Mark, thanks Jayesh.
>
> I've found the following in the manuals about the online option in the
> backup command:
> 'During an online backup, DB2 obtains IN (Intent None) locks on all
> tables existing in SMS table spaces as they are processed and S
> (Share) locks on LOB data in SMS table spaces'
>
> We're using SMS tablespaces and the table which is lockes has a lob
> column. Do you think moving this table to a DMS tablespace can fix the
> problem.
>
> By the way, there no special entries in the db2diag.log file, just the
> starting and finishing of the backup.
>

What are you trying to do in your application that is running in to the
locks?

The point of putting locks on objects in the tablespace is to prevent
changes (DDL) while the backup is active. DML is fine, of course.


From: Mark A on
<michael.spoden(a)web.de> wrote in message
news:2c681b98-04c3-43de-831f-ac11b8d66e8d(a)a70g2000hsh.googlegroups.com...
> Thanks Mark, thanks Jayesh.
>
> I've found the following in the manuals about the online option in the
> backup command:
> 'During an online backup, DB2 obtains IN (Intent None) locks on all
> tables existing in SMS table spaces as they are processed and S
> (Share) locks on LOB data in SMS table spaces'
>
> We're using SMS tablespaces and the table which is lockes has a lob
> column. Do you think moving this table to a DMS tablespace can fix the
> problem.

It is worth a try.


From: michael.spoden on
Hi,

first tests on our test environment are successful. I've moved the
specific table from a SMS to a DMS tablespace. There are no more
shared locks on this table and no more lock-waits on the database.

Regards

Michael