I seem to remember reading in an old tsm manual that there was a limit on the number of incrementals before a full was forced. It sticks in my mind that that number was twelve or thirteen. If I get a chance, I'll look through my old docs and try to find the reference.
Gary Lee Senior System Programmer Ball State University -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Wednesday, January 17, 2007 9:04 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Criteria for full dbbackup On Jan 17, 2007, at 8:35 AM, [EMAIL PROTECTED] wrote: > Hello Richard, > > thanks for the hint, the incremental dbbackups have run daily, adding > up to > 13 incrementals in the series in question. Could backup_chg_pct equal > or greater than 100 lead to a full dbbackup being requested? I did´nt > find anything in the docs... Hello, Markus - ANR2361E is one of those messages with a terse Explanation which fails to help the customer understand what might be at issue. I would not expect the backup_chg_pct value to precipitate a full backup; and, as you found, there is no knowledge base to say that it might. I would expect a Full to be required only if the previous Full in the current Backup Series went away (as via DELete VOLHistory) - and, possibly, if one of the Incrementals in the midst of the series mysteriously disappeared. A Full, alone, should not go away if using DRM: the whole series should expire, per the timestamp of the last volume in it, in conjunction with the DRMDBBackupexpiredays value. If using File type volumes, you have other exposures. Whatever the cause, I would caution against employing any appreciable number of Incrementals between Fulls: "tape is tape", and it takes just one defect to ruin the ability to recover your database to currency. Richard Sims http://people.bu.edu/rbs/
