ADSM-L

Re: DB Volume "Reorg" using Delete DBVOLUME

2002-09-20 11:52:09
Subject: Re: DB Volume "Reorg" using Delete DBVOLUME
From: "Mark D. Rodriguez" <mark AT MDRCONSULT DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 20 Sep 2002 10:38:04 -0500
Seay, Paul wrote:

One of our TSM Support Staff members went to the advanced class and was led
to believe you could get some reorg benefits doing the following

       Define New DB Volumes whereever you want them.
       Perform DELETE DBVOLUME commands on each of the existing DBVOLUMEs
one at a time which causes the data to be moved.

Our DBVOLUMES are on ESS disk so they are not mirrored.  Thus, the delete
causes a move of all the current data to other volumes.

Has anyone ever heard of doing this to get some reorganization benefits?
If so, were the benefits, mild or significant?

I would not be surprised if massive filespace deletes could be recaptured by
doing this.

Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180


Paul,

I have no inside information in order to answer this question, but I can
give you my observations from many different customers who have done
similar things in the past. My experience shows that the more frequently
a customer adds, deletes, or moves (move data from DB Vol to DB Vol) DB
volumes the more fragmented the DB becomes.  In order to quantify "DB
fragmentation" I look at general performance of the DB(in particular DB
backups) as well as what happens after you do the unload/load DB, the
greater the percentage that the DB was reduced the more fragmented I say
it was.

The way I understand the DB is structured is a "B Tree" like format.
The reason the DB get bloat and poorer performance over time is due to
the way the "B Tree" structure is maintained, i.e. just because I delete
entries on the tree I do not delete a branch until all enttries down to
the leaf are invalid.  My understanding is that the only process that
rebuilds the "B Tree" is the unload/load of the DB.  Furthermore, the
operation you are suggesting would simply  move branches from location
to location which may cause additional fragmentation.  In addition, it
may set the stage for more severe fragmentation if in fact fewer but
longer branches were created.

I would really like to hear from the developers on this.  The key here
would be what is ITSM doing when the "del dbv" command moves the data
from the old vol to the new vol.  I would love to hear that it would in
fact solve the problem because as you know unload/load of the DB is
quite time consuming and I beleive the above process would be much faster.

--
Regards,
Mark D. Rodriguez
President MDR Consulting, Inc.

===============================================================================
MDR Consulting
The very best in Technical Training and Consulting.
IBM Advanced Business Partner
SAIR Linux and GNU Authorized Center for Education
IBM Certified Advanced Technical Expert, CATE
AIX Support and Performance Tuning, RS6000 SP, TSM/ADSM and Linux
Red Hat Certified Engineer, RHCE
===============================================================================

<Prev in Thread] Current Thread [Next in Thread>