View previous topic :: View next topic
|
Author |
Message |
DB2 Guy
New User
Joined: 28 Oct 2008 Posts: 98 Location: Cubicle
|
|
|
|
I'm at a shop where in first step - they stop TABLESPACE/INDEXSPACE, in second step they will DELETE & DEFINE underlying LDS, the VSAM for TABLE & INDEX(S), in third step they'll start ACCESS(UT) TABLE and INDEXSPACE, in fourth step will load the table using DSNUPROC.
I'm bit confused, why would you do this every day:
1. first, data in-flow for these tables, on daily basis, is not too high.
2. no RUNSTAT, I've observed.
3. These are daily jobs - and do this daily.
The questions which come to mind:
1. Why not first determine if REORG is needed - run a RUNSTAT first.
2. Is IDCAMS delete/define is way better than DB2 REORG. Ofcourse, after every IDCAMS delete/define you've a brand new sapce to work on but at what cost?
When I asked some "senior" around -- "we do it this way", was the answer.
I eagerly look forward to Your thoughts, Thanks. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
have no idea if i am right or wrong,
but,
using idcams to delete/define the underlying VSAM LDS,
would preclude any changes to the db2 catalog tables. |
|
Back to top |
|
|
sushanth bobby
Senior Member
Joined: 29 Jul 2008 Posts: 1020 Location: India
|
|
|
|
Hi,
That tablespace/indexspace is using user-managed storage, old style.
These jobs may be designed long time back when DB2 version was less than 7 or 6. I would guess, they have kept it that way because, it works and it haven't failed so far and "Why to fix something, that is not broken", because changing them it would cost. May be its simple and quiet system, that doesn't require lots of tuning.
Some/Most of the shops have CPU and definately storage constraints, in my previous organization we never ran RUNSTATS separately, statistics was collected inline.
Thanks,
Sushanth |
|
Back to top |
|
|
DB2 Guy
New User
Joined: 28 Oct 2008 Posts: 98 Location: Cubicle
|
|
|
|
I agree with you Dick and that makes me believe if I need to rely on RUNSTATs that would cal for a good change in current infrastructure, no? |
|
Back to top |
|
|
DB2 Guy
New User
Joined: 28 Oct 2008 Posts: 98 Location: Cubicle
|
|
|
|
You're correct Sushanth - actually, it has its own positive and negative. There are some user-written programs which use these tables and they get abend as the underlying tables are not available when these table space are being deleted/defined. Well, that's a scheduling problem also however, if REORG is a weekly activity it might give some relief.
Having said that, I'd like to know - how it goes on different shops, please share.
Thanks for stopping by. |
|
Back to top |
|
|
sushanth bobby
Senior Member
Joined: 29 Jul 2008 Posts: 1020 Location: India
|
|
|
|
RTS is the way to go. |
|
Back to top |
|
|
DB2 Guy
New User
Joined: 28 Oct 2008 Posts: 98 Location: Cubicle
|
|
|
|
I know I'm late on this but was on a different project.
RTS? You meant Run-stats - sushanth? |
|
Back to top |
|
|
GuyC
Senior Member
Joined: 11 Aug 2009 Posts: 1281 Location: Belgium
|
|
|
|
Real-time Statistics. and running DSNACCOX to determine which tablespace really needs runstats/reorg.
If you really want to review the maintenance jobs of your DB2 : that's the way to go |
|
Back to top |
|
|
DB2 Guy
New User
Joined: 28 Oct 2008 Posts: 98 Location: Cubicle
|
|
|
|
Thanks GuyC.
One is never too late for a thank you, I believe. |
|
Back to top |
|
|
|