Hi,
We are on Version 3, Release 7, Level 20.0 of TSM on OS390
No you do not use idcams.
TSM has its own unload/load process for achieve a database defragmentation
This will also compress your database at the same time.
My advice is that if you can, test this process on a development partition
first.
If you have the a development TSM and the spare dasd you can achieve this by
restoring a dump of your production TSM, and then use that to test the
unload/load process.
This is what I did and has the advantages of giving you familiarity with the
process and
also how long it takes.
Be aware this is a long running process, hence the test, but if you cannot test
in advance,
I suggest you allow for 1 to 2 days of TSM unavailability.
You will find that you database will compress pretty well possibly by 50%, but
you may be
less impressed by any efficiency improvements.
There will be some, but when I tested the improvements I saw were in the 10%
area
Because my test proved that TSM would be unavailable too long to accept, and
because I
was not confident that the improvement would be long lasting I did not implement
in production
However see below the checklist I drew up at the time which may be useful
THIS A RUN THROUGH OF THE DBUNLOAD REQUIREMENTS FOR COMPRESSING THE
DATABASE
1) PRE-ALLOCATE AND FORMAT NEW LOGICAL DATABASE VOLS
THIS CAN BE DONE WELL IN ADVANCE OF THE OTHER STEPS (IF YOU HAVE
THE SPARE DASD) I PREPARED THE SAME NUMBER OF NEW LOGICAL VOLUMES AS
ALREADY EXISTED, BUT YOU COULD NORMALLY GET AWAY WITH LESS AS THE
DATABASE AFTER THE UNLOAD/RELOAD WILL OCCUPY LESS SPACE THAN BEFORE.
2) STOP ANY PROCESSES AND DISABLE SESSIONS
3) WRITE TO A DATA SET FOR LATER COMPARISON SOME QUERIES FROM THE DB
4)TAKE COPIES OF DISKLOG, DEVICE CONFIG & VOLHIST FILES (BELT & BRACES)
& TAKE SOME QUERIES AGAINST DATABASE FOR COMPARE AFTER LOAD (SEE 12)
5) PERFORM FULL ONLINE BACKUP OF THE DATABASE
6) ISSUE HALT QUIESCE OF THE DATABASE.
7)AFTER DATABASE HALTED, PERFORM THE UNLOAD
8)IF YOU WANT TO USE THE SAME NAMES AS YOUR EXISTING DATABASE VOLS THEN
RENAME THE OLD DATA SETS, AND RENAME THE ONES YOU HAVE PRE-FORMATTED TO
YOUR OLD NAMES. THIS IS OPTIONAL.
9) RUN THE DBFORMAT JOB. THIS WILL FORMAT THE RECOVERY LOG BUT NOT THE
DATABASE, BUT WILL UPDATE THE DISKLOG TO THE CLUSTER NAMES OF THE PRE-
FORMATTED DATABASE VOLUMES.
10) LOAD THE DATABASE SPECIFYING THE TAPE THAT WAS USED IN THE UNLOAD
JOB
11) START THE DATABASE
12) COMPARE OUTPUT OF QUERIES WITH THOSE TAKEN PRIOR TO THE HALT TSM
(Q OCC & Q VOL COULD BE USED, Q DB SHOULD HAVE BEEN TAKEN ANYWAY SO YOU
CAN SEE HOW MUCH THE DATABASE HAS BEEN COMPRESSED)
13) IF SATISFIED WITH ALL THE ABOVE ENABLE SESSIONS.
Hope this helps
Ehland Ann J <[EMAIL PROTECTED]> on 01/09/2001 04:11:35 PM
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:(bcc: John Naylor/HAV/SSE)
Subject: Commits to fragmented DB
Hi *SMers!
We are running TSM Version 3, Release 7, Level 4.0 on OS/390.
Recently we have been encountering problems with our recovery log filling up
quickly. Our DB is 38 gb and the recovery log is at the maximum amount of 5
gb. We've been told that our problem with the recovery log is due to our
database being so fragmented, therefore it takes a long time to complete the
commits. Support was then surprised to hear that this is the same database
that we've been using since ADSM Version 2.
Is this so unusual???
I've tried searching the Redbooks for upkeep procedures like they used to
have for DFSMShsm, but can't find anything. I'm particularly interested in
reorganizing/defragging the database. Is there some TSM utility to do this
or will we need to use IDCAMS as we do for other VSAM files?
Thanks!
Ann Ehland
Enterprise Fixed Media Storage Services
MELLON FINANCIAL CORPORATION
*
DISCLAIMER: The information contained in this e-mail may be confidential
and is intended solely for the use of the named addressee. Access, copying
or re-use of the e-mail or any information contained therein by any other
person is not authorized. If you are not the intended recipient please
notify us immediately by returning the e-mail to the originator.
**
The information in this E-Mail is confidential and may be legally
privileged. It may not represent the views of Scottish and Southern
Energy plc.
It is intended solely for the addressees. Access to this E-Mail by
anyone else is unauthorised. If you are not the intended recipient,
any disclosure, copying, distribution or any action taken or omitted
to be taken in reliance on it, is prohibited and may be unlawful.
Any unauthorised recipient should advise the sender immediately of
the error in transmission.
Scottish Hydro-Electric and Southern Electric are trading names of
Scottish and Southern Energy Group.
**
