RE: BRMS recovery

Chuck,

Below is final IFS SWA summary from IBM support/development.
BRMS missed object reporting, currently not working, recent BRMS PTFs have caused this to fail, APAR will be out shortly.
Also, for SWA detailed lock documentation, you need to look back to SC41-5304-03 chapter 7. (V4R4 Backup and Recovery).pdf)
In my IFS environment, *LINK SWA has no benefit, but does double the time for IFS save.
At this point, I'm rethinking my IFS save strategy.
Two subsystems, QHTTPSVR and ZENDSVR are the source for all IFS locked objects, can end these on R&D LPAR, but not Production LPAR.
My goal is to have an IFS save with 0 objects excluded.
One option is *LINK SWA *NO, set the IFS save attribute from *YES to *No for any log folder, this will rid majority of locked objects, adjust others as needed..
Restricted state system save ignores this.
Once I can implement all of the above, my next BRMS test recovery should be faster and more successful.

"The key response from development is that the design for Save-While-Active is that objects can be "active" after checkpointed, when the save function changes it's lock on the object. To "Shared with readers and writers" in the case of objects in directories. Prior to that, the save function uses the same lock on the object regardless if SWA = *YES or *NO. This is true for both library and IFS saves. There are two reasons the IFS gets more skipped objects; 1. SAV SWA has no wait timer 2. Applications lock objects in the IFS more persistently.

A secondary response from development is that BRMS has built-in tracking and reporting for missed objects. There is no tracking on omitted objects. The implication is that the omit process is only for objects that have no value and are never expected to be recovered. Backup procedures should be designed to capture all objects that are required; for instance end applications that are holding persistent locks on required objects. It is understood that in some environments this can not be part of a daily process. If the object is required to be restored, a method must be employed to back it up. This may require more aggressive solutions, like High Availability, if production must be maintained 24/7.

The BRMS developers are open to a request for design change on a future version/release that would provide two new parameters for the STRRCYBRM report; KEEPOBJL(name) and KEEPLNKL(name2) to ensure the report lists omitted objects so that the end user can make decisions on how to recover them, if needed."

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, May 21, 2013 2:33 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: BRMS recovery

On 20 May 2013 21:10, Steinmetz, Paul wrote:

My previous testing has confirmed that SWA does nothing for IFS
objects, only lengthens the SAV time. The wait time you refer to only
applies to objects in libraries, not IFS objects. IFS objects do not
have a wait time with SWA, it is immediate. If the IFS SWA hits a
locked object, it simply skips it and moves on.

I am skeptical of a no-wait lock, if the SWA is also skipping those objects but taking significantly longer than a non-SWA.... but I accept your conclusion, because I have too little knowledge or practical experience outside of database objects. But I do know about the implementation of the stream file, which is effectively the same as a database member and a dataspace; i.e. same object types but different subtypes, so many implementations are very similar between the database and the stream file.

But AFaIK my comments about the initial lock required for SWA to get the snapshot and then dropping its lock so that then any other jobs can do whatever to the non-/QSYS.LIB objects including obtaining and holding locks is accurate; i.e. the SWA is functional for stream files just as for database files. As I recall, database files have the same requirement that the member.data not be exclusively locked in order for the SWA to get its lock and the snapshot. I just make a quick cursory glance at an IBM Redpaper document and the implication seems exactly as I described.... and I found no indication that "SWA does nothing for"
stream file objects.

A link to the document:
http://iprodeveloper.com/development/redpaper-explains-ragged-save-while-active-0
"A new Redpaper, Improve Whole System Backups with the New Save-While-Active Function (REDP-7200-00), explains V5R3's new "ragged"
Save-While-Active capability in comparison to the previous Save-While-Active feature available in earlier versions of OS/400.
http://www.redbooks.ibm.com/redpapers/pdfs/redp7200.pdf
"

The search that led me there:
http://www.google.com/search?q="save+while+active"+"stream+files";

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.