× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 03-Mar-2016 08:17 -0600, DrFranken wrote:
Have a customer with SSD and Spinny. Many files in production DB
tagged UNIT(*SSD). Monthly they restore production backup (about 1TB)
to training library and you guessed it all those files pile on the
SSDs overfilling them. Any idea how to make the Restore override the
UNIT(*SSD) and put them on spinny disk?

IBM i 7.1 in play. Three cores, 128GB, about 60 total arms.

Thoughts so far:

a) There are no parms on RSTLIB or RSTOBJ to override the Unit, only
the ASP and Library. The Library is overridden of course in this
restore.

b) Customer has restored, then changed the PFs to *ANY, then RGZPFM
on the things and this seems to move them to Spinny but takes days.

c) Customer is entertaining an iASP or user ASP. However this means
adding more disks and enough of them that the Restore doesn't take
forever and that training performance isn't pathetic.

d) Would it Work to instead of clearing the library clear the members
in the training library. Then change those PFs to UNIT(*ANY) and
restore into them. The question is would RSTLIB in this case restore
the attributes of the PFs anyway thus changing the UNIT parm back to
*SSD. We're going to try this with a small sample library but if
anyone has tried this...

Engage Discussion. :-)


Apologies again for necro-posting; original thread: [http://archive.midrange.com/midrange-l/201603/threads.html#00101]

Re "d)", a restore-over should not modify [most of] the attributes of a database *FILE that remains on disk. Thus having previously changed the file on disk to have UNIT(*ANY), that attribute should remain, despite being restored-over; such restores are effectively a request to restore either the members with data or just the data. But as followup discussion noted, changes to the files [layouts, removed members, etc.] on the saved-from system can be problematic, because seemingly those changes should be reflected on the restored-to system for the described scenario. Additionally...

AFaIK the UNIT information for the /create member/ phase of database file restore processing, i.e. the added-for-restore action, will adopt the attribute from the [existing or created-for-restore] database *FILE object, rather than use a saved value. That is because, I expect [per lack of UNIT() on ADDPFM commands], that the UNIT information is not being saved for each member. That is verified on v7r1; similar to what Mark W showed. Unfortunately that particular two-pass restore method in [http://archive.midrange.com/midrange-l/201603/msg00112.html] effects a data-load-for-restore that is unnecessary and the alluded change-without-clear may start data migration [as someone else alluded, that at one time some additional action like Reorganize was required to actually cause the data to move, but I think the OS changed at some point to make the migration start asynchronously since the completion of either the CHGPF or CHGPFM request?]. And while indeed the load-over the existing data effectively clears the members, the prior change requests may have started the migration of the data [and access paths] to other disks, plus all of the data gets loaded from the media a second time; both a known and a potential for much extraneous I\O activity.

Thus the following scripted method could be possibly an even lower-cost means to effect what is desired; the library would continue to be cleared, thus ensuring changes on the saved-from system are properly reflected. In a first-pass restore, no actual member-data would be restored, thus per no members existing, there would be: no need for any CLRPFM requests after restore, no RGZPFM requests needed after CHGPF UNIT(*ANY), and no data movement could occur across disk types as the effect of the CHGPF UNIT(*ANY) and CHGLF UNIT(*ANY) because no members nor data were ever loaded.

clrlib the_lib

rstobj *all the_lib ... objtype(*all) filembr((*all *none)) pvtaut(*yes) option(*all) mbropt(*all) /* first pass, no DBF data */

call setdbfsunit (the_lib '*ANY') /* chgpf & chglf to UNIT(*ANY) */

rstobj the_lib ... objtype(*file) filembr((*all *all)) pvtaut(*no) option(*old) mbropt(*new) /* or mbropt(*all) */ /* 2nd pass for data */


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.