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

This sounds like it would be more suitable for IBM Service. Have you
tried opening up a PMR?

Larry Edelstein

andy.standley@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
>

<andy.standley@ecngroup.co.nz> wrote in message
news:1128061078.124020.110880@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).

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