ADSM-L

Re: Excessive amount of database backups triggered

1999-03-22 10:34:10
Subject: Re: Excessive amount of database backups triggered
From: "Prather, Wanda" <PrathW1 AT CENTRAL.SSD.JHUAPL DOT EDU>
Date: Mon, 22 Mar 1999 10:34:10 -0500
I have had this happen at earlier releases, although I haven't seen it
recently.
Can happen if your log isn't big enough to support the activity in progress.

When using ROLLFORWARD mode, a data base backup doesn't delete from the log
any activity that is still in progress.
So the DB backup doesn't clear the log completely when it runs, and another
one gets triggered.

I started having the problem when we switched from low capacity to high
capacity tapes, so that reclaims take a lot longer to complete.  I just made
the log a lot bigger, and the problem stopped.

Check your activity log to see if some long-running process with a lot of DB
activity was in progress when this occurred, and check the size of your
recovery log.

************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu

"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************







> -----Original Message-----
> From: Grendelman M. (Martijn) [SMTP:Martijn.Grendelman AT NL.FORTIS DOT COM]
> Sent: Monday, March 22, 1999 9:33 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Excessive amount of database backups triggered
>
> Hi,
>
> Last weekend we experienced the following:
>
> 03/20/1999 00:15:36 ANR4552I Full database backup triggered; started as
> process 63.
> 03/20/1999 01:28:36 ANR0985I Process 63 for DATABASE BACKUP running in the
> BACKGROUND completed with completion state SUCCESS at 01:28:36.
> 03/20/1999 01:28:44 ANR4552I Full database backup triggered; started as
> process 66.
> 03/20/1999 02:31:24 ANR0985I Process 66 for DATABASE BACKUP running in the
> BACKGROUND completed with completion state SUCCESS at 02:31:24.
> 03/20/1999 02:31:28 ANR4552I Full database backup triggered; started as
> process 67.
> 03/20/1999 03:15:40 ANR0985I Process 67 for DATABASE BACKUP running in the
> BACKGROUND completed with completion state SUCCESS at 03:15:40.
> 03/20/1999 03:16:05 ANR4552I Full database backup triggered; started as
> process 68.
> 03/20/1999 03:47:37 ANR0985I Process 68 for DATABASE BACKUP running in the
> BACKGROUND completed with completion state SUCCESS at 03:47:37.
> 03/20/1999 03:49:36 ANR4552I Full database backup triggered; started as
> process 69.
> ...
> ...
>
> Time after time, a database backup was triggered almost immediately after
> the last one completed. This happened 12 times before the system
> (probably)
> ran out of scratch tapes:
>
> 03/20/1999 09:23:20 ANR4552I Full database backup triggered; started as
> process 91.
> 03/20/1999 09:25:35 ANR8779E Unable to open drive /dev/rmt2, error
> number=47.
>
> 03/20/1999 09:25:44 ANR1404W Scratch volume mount request denied - mount
> failed.
>
> 03/20/1999 09:25:44 ANR4578E Database backup/restore terminated - required
> volume was not mounted.
>
> 03/20/1999 09:25:44 ANR0985I Process 91 for DATABASE BACKUP running in the
> BACKGROUND completed with completion state FAILURE at 09:25:44.
>
> 03/20/1999 09:25:46 ANR4560I Triggered database backup will be retried in
> 60
> seconds.
>
> After two more retries, the server went into some kind of coma, that could
> only be resolved by expanding the recovery log before restarting the
> server
> (killing and restarting the server without doing this didn't even produce
> any messages in the activity log).
>
> Why does this happen? It looks to me like the recovery log isn't emptied
> after the database backup. Some additional info:
>
> *       ADSM 3.1.1.5 on AIX 4.2.1 (or rather: a 3466 model C20 Network
> Storage Manager with currently installed 3466 Software Level EC: 3.1.1.5)
> with a 3575 tape library
> *       Log mode is set to roll-forward
> *       Full database backup schedules twice a day
> *       Unscheduled database backups hardly ever happen
>
> Any help would be greatly appreciated.
>
> Martijn Grendelman.