By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,756 Members | 1,721 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,756 IT Pros & Developers. It's quick & easy.

DB2 DAS causes transaction log to fill up

P: n/a
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
Share this Question
Share on Google+
3 Replies


P: n/a
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

P: n/a
<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

P: n/a
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.