469,327 Members | 1,242 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,327 developers. It's quick & easy.

DB2 DAS causes transaction log to fill up

Hi,
We have DB2 SDK V8.2.1 running under redhat ES 3 (taroon update 5)
kernel 2.4.21

We have an instance that also contains the tools database for the admin
server. We tools have been used to set up some tasks that have run well
for a few months. I addes some more tasks and then a week or two later
went to use the task center to see what had taken place with those
scheduled tasks. The task center would not respond and responded with
some deadlock errors. When I tried to look again the next day the same
happended so I tried to restart DAS and the problem got worse - the
instance showed slow down and the db.log_util value increased to 100%
meaning the transaction log was full (our set up is not huge). We
managed to salvage the system by stopping DAS (and I think also killing
off a db2dasstm process)

Today I had permission to restart DAS which I did and we had the same
result. I could not identify what was going on - what was causing the
transaction log to fill - but we ended up with 100% again and a crap
state of affairs. The db2diag does not hint at anything and I could not
isolate any application that might be causing this - and I won't get
permission to do it again as it causes major clean up tasks.

How could DAS be chewing up the log - I think I should drop the tools
catalog and drop DAS and start again, but to drop the catalog I need to
start DAS and I am now sure how to drp DAS most cleanly.

Any body seen similar issues - I see that db2dassstm has a history of
100% CPU issues but not transaction log issues. Even when I did a
db2admin stop db2dasstm re-appeared again and I had to kill it off

many thanks

andy

Nov 12 '05 #1
3 4587
This sounds like it would be more suitable for IBM Service. Have you
tried opening up a PMR?

Larry Edelstein

an***********@ecngroup.co.nz wrote:
Hi,
We have DB2 SDK V8.2.1 running under redhat ES 3 (taroon update 5)
kernel 2.4.21

We have an instance that also contains the tools database for the admin
server. We tools have been used to set up some tasks that have run well
for a few months. I addes some more tasks and then a week or two later
went to use the task center to see what had taken place with those
scheduled tasks. The task center would not respond and responded with
some deadlock errors. When I tried to look again the next day the same
happended so I tried to restart DAS and the problem got worse - the
instance showed slow down and the db.log_util value increased to 100%
meaning the transaction log was full (our set up is not huge). We
managed to salvage the system by stopping DAS (and I think also killing
off a db2dasstm process)

Today I had permission to restart DAS which I did and we had the same
result. I could not identify what was going on - what was causing the
transaction log to fill - but we ended up with 100% again and a crap
state of affairs. The db2diag does not hint at anything and I could not
isolate any application that might be causing this - and I won't get
permission to do it again as it causes major clean up tasks.

How could DAS be chewing up the log - I think I should drop the tools
catalog and drop DAS and start again, but to drop the catalog I need to
start DAS and I am now sure how to drp DAS most cleanly.

Any body seen similar issues - I see that db2dassstm has a history of
100% CPU issues but not transaction log issues. Even when I did a
db2admin stop db2dasstm re-appeared again and I had to kill it off

many thanks

andy

Nov 12 '05 #2
<an***********@ecngroup.co.nz> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
Hi,
We have DB2 SDK V8.2.1 running under redhat ES 3 (taroon update 5)
kernel 2.4.21

We have an instance that also contains the tools database for the admin
server. We tools have been used to set up some tasks that have run well
for a few months. I addes some more tasks and then a week or two later
went to use the task center to see what had taken place with those
scheduled tasks. The task center would not respond and responded with
some deadlock errors. When I tried to look again the next day the same
happended so I tried to restart DAS and the problem got worse - the
instance showed slow down and the db.log_util value increased to 100%
meaning the transaction log was full (our set up is not huge). We
managed to salvage the system by stopping DAS (and I think also killing
off a db2dasstm process)

Today I had permission to restart DAS which I did and we had the same
result. I could not identify what was going on - what was causing the
transaction log to fill - but we ended up with 100% again and a crap
state of affairs. The db2diag does not hint at anything and I could not
isolate any application that might be causing this - and I won't get
permission to do it again as it causes major clean up tasks.

How could DAS be chewing up the log - I think I should drop the tools
catalog and drop DAS and start again, but to drop the catalog I need to
start DAS and I am now sure how to drp DAS most cleanly.

Any body seen similar issues - I see that db2dassstm has a history of
100% CPU issues but not transaction log issues. Even when I did a
db2admin stop db2dasstm re-appeared again and I had to kill it off

many thanks

andy

1. Install the latest IBM JDK (1.4.2 or later). You can get that here:
http://www-128.ibm.com/developerwork.../download.html

2. Install DB2 FP10 on your database server and update all your db2
isntances. In the dbm cfg for each instance, change the java path to the one
defined after the install for step 1 above. Do not update your das instance
(see step 4 below).

3. Update all your databases per FP10 installation instructions.

4. Drop the das instance and then recreate it.

5. Install FP10 on your client (if using a remote client).
Nov 12 '05 #3
Thanks

we have

Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1)
Classic VM (build 1.4.1, J2RE 1.4.1 IBM build cxia321411-20031011 (JIT
enabled: jitc))

so maybe your suggestion will solve it!

andy

Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Deepak Mehta | last post: by
2 posts views Thread by Iwan Petrow | last post: by
11 posts views Thread by Jialiang Ge [MSFT] | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
reply views Thread by haryvincent176 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.