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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Richard Sims
Sent: Wednesday, January 17, 2007 9:04 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Criteria for full dbbackup

On Jan 17, 2007, at 8:35 AM, Markus.Engelhard AT bundesbank DOT de 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/