|
Dave - You ran some tests and found this procedure to be faster than SAV/RST using tape and specifying ACCPTH(*YES) ??? I'd be surprised if it was.... Kenneth -----Original Message----- From: Dave Miller [mailto:dlmiller@jquint.com] Sent: Wednesday, June 28, 2000 9:39 AM To: MIDRANGE-L@midrange.com Subject: RE: Duplicating a library. I researched a way to do this with large JDE history files (10,000,000 records per file) at a client I worked for. They needed to be able to update a research environment with current data. We did this weekly and needed the fastest way possible to do it. (There was a total of 25,000,000 records copied into 8 physical files with 65 logicals) We wrote a CL to cpyf the records from production into a hold library first. It is important to note that when you use cpyf over an indexed physical file it will read the file by the index unless you put a 1 in the FROMRCD parameter. This is real important as it allows the copy to read the file sequentially (in arrival sequence) and use look ahead logic in the copy. This will improve performance a lot. Also, submit the job to a batch subsystem with a lot of memory. Save / Restore and any process that manipulates large volumes of data will run many times faster with more memory to work with. In fact when we did this, we submitted the job to batch at night after increasing the memory in the subsystem. We then moved the data by tape to the development system and cpyf the records into the test database. Prior to the copyfile's running we executed a CL to remove all the members from all the logicals. This prevents DB/2 from building the access paths as the records are added. After the data was put back we ran another CL that submitted 1 job for every one of the logicals to put the members back. By submitting 1 job per logical we were able to multi thread the rebuild and take advantage of the ability of OS/400 to create multiple access paths concurrently. > -----Original Message----- > From: owner-midrange-l@midrange.com > [mailto:owner-midrange-l@midrange.com]On Behalf Of Denis Robitaille > Sent: Wednesday, June 28, 2000 6:48 AM > To: MIDRANGE-L@midrange.com > Subject: RE: Duplicating a library. > > > Assuming that the library is stable (the sources of the PF and LF > do not change much), you could do the following: > > Instead of the save/restore, create a CL that do a CPYF of all > the PF form the production to the test library. This way, you > avoid all the file creation and all the access path rebuild. > > > Denis Robitaille > Directeur services techniques > Cascades Inc > 819 363 5187 > fax 819 363 5177 > > > >>> barsa2@ibm.net 06/28/00 09:25am >>> > At 11:05 PM 06/27/2000 +0100, you wrote: > > Save/restore if preferable, because the objects will have the original > "create date". If you have the disk space, save/restore to a > save file is > the best. If you don't, then use tape. > > Al > > > > >I ve been involved in copying libraries from one environment to another > >before. > > > > From what I see, there are three methods. > > > >CPYLIB etc.. > > > >SAVRST to save file > > > >SAVRST to tape. > > > > > > > >Of the saves, you should do performance testing to see which one is > >quickest. In my experience, using 3590 s, tape is by far the > quickest method. > > > >I probably would not use CPYLIB as the access paths for each > file will be > >rebuilt on the fly. This will seriously hamper your system and may take > >many hours to complete (if not days) > > > > > > > >Another method you might consider is to use a replication > package such as > >DataMirror. > > > > > > > >Hope this Helps > > > >Adam > > > >adam@slic-systems.com > > > ><http://www.slic-ssytems.com/>www.slic-ssytems.com > > > > > > > > > > > >-----Original Message----- > >From: owner-midrange-l@midrange.com > >[mailto:owner-midrange-l@midrange.com]On Behalf Of Quazy > >Sent: 27 June 2000 19:41 > >To: MIDRANGE-L@midrange.com > >Subject: Duplicating a library. > > > > > > > >Nightly we need to take a copy of our production library and > duplicate it > >to a Test environment for our support people so they can play > with almost > >current data. > > > > > > > >I have been accomplishing this by backing up the library with a > save while > >active to a save file, then restoring the save file to the test > >environment, then backing the save file up to tape, and deleting it. > > > > > > > >I would like to eliminate going to a save file and just save to tape and > >duplicate the library. I don't want to restore from tape to the test > >environment. > > > > > > > >This is a 10 Gig library with 200 Physical and logical files. > > > >This library is used 27 X 7. > > > > > > > >Can you do a crtdupobj on active files? will it have to rebuild access > >paths? > > > > > > > > > > > >I would appreciate anyone's thoughts on a good solution. > > > > > > > > > > > >Thanks Chris. > > > > > > > > +--------------------------------------------------+ > | Please do not send private mail to this address. | > | Private mail should go to barsa@ibm.net. | > +--------------------------------------------------+ > > Al Barsa, Jr. - Account for Midrange-L > Barsa Consulting, LLC. > 400 > 390 > > Phone: 914-251-1234 > Fax: 914-251-9406 > http://www.barsaconsulting.com > http://www.taatool.com > > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to > MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: > david@midrange.com > +--- > +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.