Commit Active problem solved (db2rhist.asc)

[m.gelosa]

Dear all,
I wrote some weeks ago about a problem with all the committing
transactions blocked for many seconds in a Commit Active state. Well,
finally I solved it and I just would like to share this information.

As I suspected there was a lock. I suspected log writing due to the
commit active state and I was right. Using truss
on the db2loggw process I found that when the db2 was blocked it was
waiting on a Unix semaphore. I didn't
find a way to find on AIX a command that gives you the pid of the
semaphore locking process (you have the
last operation process pid, that was the db2loggw itself). This
semaphore lock appear just after a statx on
the db2rhist.asc file, so I tried to understand what was happening
with that file.

Oh well, the file was pretty big: 600MB. I suspected the db2logmgr and
infact it was accessing the file during
the lock. Once again, truss helped me. It was reading/seeking into the
file... when it finished it did a semop on
the same semaphore (an unlock obviously) and the db2loggw started to
write again and everything was unblocked
and working correctly.

I removed the db2rhist.asc and the db2rhist.bak and reduced the
REC_HIS_RETENTN variable to 7 days (we
keep backup for less than a week) while the default is 366...

Anyway I have some questions for any DB2 folk around here. First of
all anything happened just when there
was an asnapply or asncap committing transaction on the database (the
replication processes). Second is that I do
not understand while the db2logmgr must read so many data from the
db2rhist.asc: is it responsible of the history
rotation process or whatever?

Thanks a lot to everybody and bye.

Matteo Gelosa
I.NET S.p.A.