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 ===============================================================================