Unload /Reload timings and efficacy
Hi, I have been recommended a compress of the database ie. unload/reload as a cure for slow restores with large Novell data servers. Has anybody been through this, and can confirm my estimate of 6 hours approx for the unload reload part of thr process. We are OS390, TSM 3.7.20.0 The database is 84.5% occupied of 18.1gb 8 logical volumes ie : Total Usable Pages: 4,764,672 Used Pages: 4,027,026 Also any feelings on whether this is likely to make a real impact on the database access element of the restores. Thanks, John Has anybody been there, done it, got the figures. I am looking for a nice warm feeling. I cannot have TSM unavailable for more than 12 hours max. Thanks ** 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. **
Re: Unload /Reload timings and efficacy
John, from my experience with ADSM 3.1.2 on AIX, I do not think that it can be done within 12 hours. The DUMPDB is quite fast, but the LOADDB takes a lot of time (more in the order of days than hours). And it may require much more space than the original 18 GB. But again, this is my ADSM 3.1.2 experience. Perhaps things are totally different with TSM 3.7. I would love to hear that they are, but nobody could assure me so far. Even more, I tend to doubt the wisdom of that recommendation. I never heard, that performance problems could be resolved by a DB reorganization. Reinhard John Naylor writes: Hi, I have been recommended a compress of the database ie. unload/reload as a cure for slow restores with large Novell data servers. Has anybody been through this, and can confirm my estimate of 6 hours approx for the unload reload part of thr process. We are OS390, TSM 3.7.20.0 The database is 84.5% occupied of 18.1gb 8 logical volumes ie : Total Usable Pages: 4,764,672 Used Pages: 4,027,026 Also any feelings on whether this is likely to make a real impact on the database access element of the restores. Thanks, John Has anybody been there, done it, got the figures. I am looking for a nice warm feeling. I cannot have TSM unavailable for more than 12 hours max. Thanks ** 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. ** -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Unload /Reload timings and efficacy
Reinhard, I think the process may be different or improved under 3.7 I have tried it on our much smaller development TSM database where I saw :- Before, the load/reload Total Usable Pages: 607,232 Used Pages: 304,812 After, the load/reload Total Usable Pages: 608,256Used Pages: 177,578 So the compress was significant and in this case the unload took 9 minutes and the load 15 minutes, and that is what I based my 6 hour estimate on, but it is a lot smaller than my production TSM and I was not sure how safe it was to extrapolate from such a small database. As far as the performance gain, I must admit I tend to agree with you, certainly for backups and the normal small restores. I am not a database expert, but I suppose it may be different for large restores. Any database or os390 gurus out there ? John Reinhard Mersch [EMAIL PROTECTED] on 11/08/2000 01:32:46 PM Please respond to "ADSM: Dist Stor Manager" [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: John Naylor/HAV/SSE) Subject: Re: Unload /Reload timings and efficacy John, from my experience with ADSM 3.1.2 on AIX, I do not think that it can be done within 12 hours. The DUMPDB is quite fast, but the LOADDB takes a lot of time (more in the order of days than hours). And it may require much more space than the original 18 GB. But again, this is my ADSM 3.1.2 experience. Perhaps things are totally different with TSM 3.7. I would love to hear that they are, but nobody could assure me so far. Even more, I tend to doubt the wisdom of that recommendation. I never heard, that performance problems could be resolved by a DB reorganization. Reinhard John Naylor writes: Hi, I have been recommended a compress of the database ie. unload/reload as a cure for slow restores with large Novell data servers. Has anybody been through this, and can confirm my estimate of 6 hours approx for the unload reload part of thr process. We are OS390, TSM 3.7.20.0 The database is 84.5% occupied of 18.1gb 8 logical volumes ie : Total Usable Pages: 4,764,672 Used Pages: 4,027,026 Also any feelings on whether this is likely to make a real impact on the database access element of the restores. Thanks, John Has anybody been there, done it, got the figures. I am looking for a nice warm feeling. I cannot have TSM unavailable for more than 12 hours max. Thanks ** 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. ** -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653 ** 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. **
Re: Unload /Reload timings and efficacy
John, I would be very reticent to use UNLOADDB/LOADDB (note : not DUMPDB, UNLOADDB was new at 3.7) in order to resolve a performance problem. This is a non-trivial undertaking. I did it on two databases last year after having split the service into two. I was left with many GBs of database I could not utilise in one DB and I wanted to regain space : that was very successful. The other reason was to tidy up the larger DB after many years of service and although the initial gain was impressive (about 30-40%) the algorithm for space utilisation afterwards meant that it rapidly expanded (and I don't believe that has been changed?). I did some DB performance measurements (my own crude metrics : EXPIRE INVENTORY performance was one) and could discern no measurable improvement. The platform base I did this on was AIX and the original DBs were about 60GB. The one that was really only 4GB after the split took about 8 hours (on an RS6000/R40) and reduced to the 4GB. The other (really 60GB) took about 2 days (reducing to 40GB). I think the likelyhood of it impacting on Netware restore performance would be almost nil (my own honest opinion). I'd be interested in who advised you to do this? I hope this helps ... Sheelagh -- Sheelagh Treweek Oxford University Computing Services Email: [EMAIL PROTECTED] Phone: +44 (0)1865 273205 Fax:-273275
