MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » January 2013

Re: How the SQL Server World Lives



fixed

On 29 Jan 2013 14:33, Jim Oberholtzer wrote:
It can because the save is operating on both the object header and
the data portion of the object. In the cases I have run into either
the save was canceled manually with an *IMMED option, or save while
active checkpoints were in limbo, and a couple of cases were the
object was locked. Remember a save is more than just reading the data
portion of the object, it updates the object header and other
internal structures while it's operating.

What updates would be made to the objects being saved? I am aware of none. Of course, actual changes should be reflected in the Last Change Date\Time which is stored in the object header. I do not expect many objects [types] saved will show their change date to match when they were just saved.

A save must navigate an object, but the OS save [and LIC dump] feature should not update the object being saved. I accept there may be some rare circumstances; e.g. I was flummoxed when Database Save chose to write a corrective object change to an index space during saves [mostly because of the negative impacts on restores and for the differences between that and a the next save], but that was the first ever I was aware of a write to an object being saved object by DB Save. Even the /update history/ which, if included, is written in a separate location from the object; i.e. in the OIR, and after the object is saved. Even the post-IPL LIC CF /first touch/ update is not done during saves; for sure not to the DB portion, well... since that issue was corrected after being broken for awhile, because that feature adds to storage taken during the save and is not returned until the next IPL.

All of the errors I have encountered have been on data objects
(tables, indexes, etc) I have yet to see it on V7, rarely on V6,
and often enough on V5R4 to be concerning.

Specifically what errors transpired may help to clarify.

On 1/29/2013 4:16 PM, Glenn Gundermann wrote:
I understood it that a save could detect a corrupt file, not that
it would be the one corrupting it.

Assuming "corrupt" means "damage" in the DB2 for i vernacular, then that is an essentially correct understanding. A terminated save might however, leave a database file object "logically damaged"; so it is not the save that damaged the object, but the termination of that save. As noted in a prior reply, that is unexpected in but a very few scenarios.

The Save feature might do any of: (1) See that an object is already marked "full damaged" or "soft damaged" and implicitly omit the object from the save; i.e. detect the object is already damaged (2) Perform some navigation of the object\data for which damage is set [for the object or data] by a LIC feature; i.e. detect that the object is damaged and needs to be indicated as such, and then that save would be terminated by the OS due to a "damage set" condition (3) Start save of a composite that requires a Database Recovery Object and then the save terminated [by external action; power loss, EndJob, storage full] in a way that the Database Recovery remains pending, thus leaving the file "logically damaged"; for storage full the locks remain held until the Save process is signed off\ends (4) anything for which any other [non-DB] object handler might detect or leave an object "logically damaged"






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact