ADSM-L

Re: Database defragmentation (was Expiration)

2001-04-19 09:05:59
Subject: Re: Database defragmentation (was Expiration)
From: "Chibois, Herve" <Chibois_H AT ADMIRAL DOT FR>
Date: Thu, 19 Apr 2001 15:07:33 +0200
Hi Mavis,

defining "old" is not so simple. Let me give you some example where you DB
can be considered as "old" or "fragmented"

you server was born in ADSM 3.1 and you upgraded to 4.1.3 after following
all the latest patches / ptf 3.1.2.90... 3.7.2 3.7.4 ...  ==> then you need
to unload/load you DB

some years ago you defined an archiving policy and start storing archive
files in you TSM box (or ADSM box). One day, your boss told you to separate
your backup and archive into 2 tsm servers. So you did and moves all your
archives files onto your second server. ==> here again you need to
unload/load
your DB

at the begginig, ADSM was running on a nice E20 with fast 4.5 GB hdd. By
the
years, you added disk for DB / STG and your system has plenty of different
disks,
small, huge, slow, fast... You decided to move onto a new H80 or pSeries
server
with a SAN storage or SSA disk unit. ==> One again, you will have better
perf if
you unload/load you DB.

Generally speaking, on my customers'  "big" tsm sites, I do this once a year
if the production can be stopped. It  *really* depends on how long you can
stop
your backup services and how much resources (CPU, disks, tapes) you have.

Last point, says your DB is accros 2 big 9 Gig volumes, but only 51% filled.
You want to change 2*9 gig by 4*4.5 gig for better perf. if tsm can not move
you data (or remove a 9 gig vol), you can try to unload/load the db and it
will be much easier for tsm to remove the big vols after the unload/load
operations.

Very last point. Daily, I log to an external DB (mysql), some stats about
DB/LOG
comsuption, node occupancy and schedule stats. It allows me to have an
historic
graph of some KEY values in tsm such as DB/LOG % and node occupancy. several
months after the Y2K big jump, my DB lost 20 % (9 gig). This was a good
occasion
to degrad it.

Hope this "best practises" will help you

rv





> -----Message d'origine-----
> De : M Jenkins [mailto:Mavis.Jenkins AT IPAUSTRALIA.GOV DOT AU]
> Envoyé : jeudi 19 avril 2001 05:11
> À : ADSM-L AT VM.MARIST DOT EDU
> Objet : Database defragmentation (was Expiration)
> 
> 
> OK, I'm curious.
> How do you define 'old' ?
> How often do you need to defrag the ADSM database (or is this 
> like 'how
> long is a piece of string').  How can you tell it needs 
> defragging ?  I
> know where to get this information from ADABAS but not ADSM
> 
> Mavis
> IP Australia
> 
> ------------------------------
> 
> >Date:    Tue, 17 Apr 2001 15:51:03 +0200
> >From:    "Chibois, Herve" <Chibois_H AT ADMIRAL DOT FR>
> >Subject: Re: Expiration
> >
> >Hi  Bert,
> >
> >Your TSM server creeps !
> >
> >what is your BUFPOOLSIZE (dsmserv.opt)
> >
> >you should not go below 99.5 % for PCT CACHE
> >
> >change BUFPOOLSIZE to 256 Mo at least and restart your tsm server,
> >the expiration process should fill the DB cache and it 
> should speed up
> >your process.
> >
> >What kind of disks are you using ? SSA or SCSI ? are the DBVOL files
> >on the same disks as AIX ?
> >
> >If your DB is "old" you should do an unload/load db operation to
> >defrag. your DB pages.
> >
> >rv
> 
<Prev in Thread] Current Thread [Next in Thread>