Re: How the SQL Server World Lives

Well "damage" can be either logical damage or [for lack of a better term] physical damage. The latter is further classified as either hard\full or partial\soft. The physical damage is logged [I think by Storage Management (SM)] as VLog major code prefix 03. Logical damage is the domain of the object handler and is diagnosed according to the owning component.

FWiW: Like I replied earlier, the use of a specific type of incident for "damage" may be entirely different from what is diagnosed by "Database is Corrupt"; the SQL Server could have its own "damage" and still not have whatever it calls "Database is Corrupt".?

The Save feature will not save a physically damaged object. Previously damaged objects will be skipped, and objects that are detected and marked damaged during the save will terminate the save request And depending both on how the object owner defines the logical damage and if the Save feature calls the object owner as an object handler, the Save feature may or may not be able to save an object with logical damage. A Save may "detect" physical damage due to the LIC object handler [or actions by another LIC component such as SM], and that detection will actually terminate the Save; re-attempting the save will skip the object which is since known to be /previously damaged/ FWiW for the database *FILE objects owned by component DB, notification of most logical damage due to pending recovery is by CPF3245 [and sometimes other types of logical damage, even if inappropriately, are notified by CPF3285].

The Database Save feature often creates "recovery objects" for save requests. If any Database Recovery Object is left for an object, the recovery is "pending" and the database *FILE object is considered logically damaged. There are only a few ways that I recall whereby these recovery objects could survive a save, because the Save will call the object handler to perform cleanup in almost every other typical save scenario:

. the system storage limit [or the user storage limit?] is exceeded; the save process remains active to allow cleanup, but the backout procedures are not called because they require more storage which is a catch-22. For pending database work the resolution after cleanup [that must start with non-database objects], IIRC, is to issue DSPFD against the libraries that failed to save. One would hope saves are not performed either by limited MAXSTG users or when the system is teetering on the edge of termination due to DASD overflow.

. the save job ending in a way that the Save or handlers were unable to perform their backout handlers for process termination; *IMMED end is undesirable here, just as for other operations, although I thought the default end limits would normally let even large saves call and perform all exit activity

. as with anything, defects; any defect whereby the Database Recovery Objects were left [whether the Save called to ask is of course irrelevant], for example.

Regards, Chuck

On 29 Jan 2013 14:12, Charles Wilt wrote:

I'm a bit surprised at that...I'd expect a SAVE operation to be
99.9% read only. I don't see how a read operation could corrupt
an object.

Save-while-active, maybe...

Anybody, looking at you Chuck ;) , know the details?

On Tue, Jan 29, 2013 at 5:01 PM, Jim Oberholtzer wrote:

To the contrary; Save operations that are killed in the middle, or
fail for a multitude of reasons will cause a damaged object. I've
probably called in 15 - 20 PMRs over the years and had one critsit
over that very topic. The critsit was while I was VP IT and we were
down for several days. It happened while I as at COMMON in
Nashville, I remember it vividly. Ask Larry what my mood was like
that week! The only thing that made that week worse was Al Barsa
passing.

You are correct that a damaged object will not be saved properly,
but a save operation that fails/or is killed (end immediate) can
cause a damaged object as well.