|
Re: [ADSM-L] Will db2sysc ever calm down?
2009-10-19 15:07:37
OK, then my supposition that this related to IC62978 is probably
incorrect then. This was a problem we ran into where database
reorganization was occurring so frequently it would cause database
transactions to timeout. The workaround is to add "ALLOWREORGTABLE NO"
to dsmserv.opt which solved the problem for us, but it looks like you're
running into something different.
Zoltan Forray/AC/VCU wrote:
Nothing in the activity log.
db2diag shows lots of these scattered all throughout. In fact, starting
around 00.15 this morning, it started spewing these, constantly.
2009-10-19-00.15.35.369793-240 I286598373E734 LEVEL: Error
PID : 32708 TID : 47395312232768PROC : db2sysc 0
INSTANCE: tsminst1 NODE : 000 DB : TSMDB1
APPHDL : 0-32235 APPID: *LOCAL.tsminst1.091019020008
AUTHID : ROOT
EDUID : 619 EDUNAME: db2agent (TSMDB1) 0
FUNCTION: DB2 UDB, database utilities, sqluhDiskDelete, probe:949
MESSAGE : SQL0902C A system error (reason code = "") occurred. Subsequent
SQL
statements cannot be processed.
DATA #1 : String, 30 bytes
Error returned by disk delete.
DATA #2 : String, 68 bytes
/tsmarchlog/archmeth1/tsminst1/TSMDB1/NODE0000/C0000000/S0000326.LOG
DATA #3 : ZRC, PD_TYPE_ZRC, 4 bytes
0x870F0011
Then at 2009-10-19-00.31.23 it said:
2009-10-19-00.31.25.095118-240 E287044518E536 LEVEL: Event
PID : 32708 TID : 47395446450496PROC : db2sysc 0
INSTANCE: tsminst1 NODE : 000 DB : TSMDB1
APPHDL : 0-8 APPID: *LOCAL.DB2.091005124801
AUTHID : ROOT
EDUID : 36 EDUNAME: db2stmm (TSMDB1) 0
FUNCTION: DB2 UDB, Self tuning memory manager, stmmLogGetFileStats,
probe:565
DATA #1 : <preformatted>
New STMM log file (/home/tsminst1/sqllib/db2dump/stmmlog/stmm.574.log)
created automatically.
Last log entry before I killed (around 9am today) it was:
2009-10-19-06.16.01.345671-240 E287046096E503 LEVEL: Event
PID : 32708 TID : 47395446450496PROC : db2sysc 0
INSTANCE: tsminst1 NODE : 000 DB : TSMDB1
APPHDL : 0-8 APPID: *LOCAL.DB2.091005124801
AUTHID : ROOT
EDUID : 36 EDUNAME: db2stmm (TSMDB1) 0
FUNCTION: DB2 UDB, Self tuning memory manager, stmmLog, probe:1115
DATA #1 : <preformatted>
STMM log file (570) removed automatically to maintain space constraint.
Then a bunch more messages when I started it back up around 9am
today..........
Next slew of "I can't delete my logs" started at the next DB backup run
around 2pm.
I am not a DBA so I may be missing something. I had to "tail -25000" to
scroll back to the beginning of entries starting with todays date.
From:
Skylar Thompson <skylar2 AT U.WASHINGTON DOT EDU>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
10/19/2009 02:08 PM
Subject:
Re: [ADSM-L] Will db2sysc ever calm down?
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Do you see anything suspicious in your activity log or db2diag.log?
Zoltan Forray/AC/VCU wrote:
Today I found my 6.1.2 Linux server non-responsive.
Had to kill -9 the dsmserv process. Restarted it.
The TSM server was non-usable for more than 2-hours while the db2sysc
flogged the processor and hard-drives.
After I was able to sign-in and things got rolling, I "started" a manual
backup stgpool.
By "starting" I mean I issued the command and have been waiting for over
an hour and still no tape mount or sign of any activity other than
db2sysc
going balisting again, eating most memory (8GB) and CPU!
Any hopes for a 6.1.3 to address some of these issues? I realize a new
beta is starting, but, some of these problems are still preventing me
from
making serious use of V6?
--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S048, (206)-685-7354
-- University of Washington School of Medicine
--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S048, (206)-685-7354
-- University of Washington School of Medicine
|
|
|
