Hello,
I need help one more time.

Our database run automatic db2stop, but no one know what happend.

the db2diag.log say a warning like this:

2010-10-16-06.08.41.031586+360 E18384159A1517 LEVEL: Error
PID : 1971 TID : 4 PROC : db2acd
INSTANCE: db2inst1 NODE : 000
EDUID : 4 EDUNAME: db2acd
FUNCTION: DB2 UDB, Health Monitor, HealthIndicator::update, probe:500
MESSAGE : ADM10500E Health indicator "Table Space Container Utilization"

this warning could down the database?

thanks.

What else do you see in the db2diag.log?

2010-10-16-02.58.37.224637+360 E18287511A1518 LEVEL: Warning
PID : 1971 TID : 4 PROC : db2acd
INSTANCE: db2inst1 NODE : 000
EDUID : 4 EDUNAME: db2acd
FUNCTION: DB2 UDB, Health Monitor, HealthIndicator::update, probe:500
MESSAGE : ADM10501W Health indicator "Table Space Container Utilization"
("tsc.tscont_util") breached the "upper" warning threshold of "80 %"
with value "81 %" on "table space container" "db2inst1.BD


2010-10-16-08.00.21.933130+360 E18405213A637 LEVEL: Error (OS)
PID : 4769 TID : 1 PROC : db2bp
INSTANCE: db2inst1 NODE : 000
EDUID : 1
FUNCTION: DB2 UDB, oper system services, sqlowqueInternal, probe:40
MESSAGE : ZRC=0x870F003E=-2029060034=SQLO_QUE_BAD_HANDLE "Bad Queue Handle"
DIA8555C An invalid message queue handle was encountered.
CALLED : OS, -, write
OSERR : EINVAL (22) "Invalid argument"
DATA #1 : system V message queue identifier., PD_TYPE_SYSV_QUEUE_ID, 4 bytes
0x0040B009
DATA #2 : Pointer, 8 bytes
0xffffffff78600080
DATA #3 : unsigned integer, 8 bytes
65527



2010-10-16-01.10.05.542988+360 E18282896A541 LEVEL: Warning
PID : 1967 TID : 80 PROC : db2sysc
INSTANCE: db2inst1 NODE : 000 DB : PREPAGO
APPHDL : 0-16343 APPID: *LOCAL.db2inst1.101015191007
AUTHID : DB2INST1
EDUID : 80 EDUNAME: db2agent (PREPAGO)
FUNCTION: DB2 UDB, data management, sqldEscalateLocks, probe:3
MESSAGE : ADM5502W The escalation of "813" locks on table "esquema.tabla" to lock intent "X" was successful.

None of the errors is severe enough to crash the database/instance. If you like, attach db2diag.log from Oct 16th and I'll take a look.

in your db2dump directory, were there any dump or trap file created during the same duration when your db2 went down ? yes, getting the diag.log enclosed here will help.

Thank you very much for your help, it's nice to find people willing to help.

I found the problem and had nothing to do with the database was network problem and conflict with the cluster but your answers help me to find the problem faster in future events