Hi Desigan,
20% for a trigger seems pretty low to me. We run ours at 70%. If you are
setting it that low to ensure that you get a backup 'about every 24 hours',
I would think that you would be better off setting up an admin schedule to
run the backup every 24 hours, at a time of your choosing. We do that, and
have the backups that are triggered do incrementals, rather than fulls.
Having said all of that, I have seen behaviour similar to what you are
reporting under earlier versions of the server (ours is AIX). I never really
got to the bottom of it but it went away after installing a newer version of
the server (I don't remember which one). Our record was about 20 incremental
backups done in a very short period of time.
Trevor
> -----Original Message-----
> From: Moodley Desigan * Datavia [SMTP:DesiganM AT TRANSNET.CO DOT ZA]
> Sent: Monday, November 30, 1998 7:42 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Roll forward recovery
>
> Hello list members,
>
> We're running ADSM server version 3.1.2.0 on MVS OS 390. We recently
> changed
> our recovery log mode from normal to roll forward. We set a database
> backup
> trigger of 20%. When the log reached 20%, a full database backup is
> triggered. This usually happens about every 24 hours. After the backup,
> the
> recovery log percentage dropped to about 1%. This continued for about 4
> days. However, during the weekend, the recovery log percentage did not
> drop
> after a database backup causing database backups to be triggered
> immediately
> after a successful backup. Here is an extract of the job log:
>
> ANR4550I Full database backup (process 530) complete, 2666266 pages
> copied.
>
> ANR0985I Process 530 for DATABASE BACKUP running in the BACKGROUND
> completed
>
> ANR0985I with completion state SUCCESS at 07:51:23.
>
> ANR4556W Warning: the database backup operation did not free sufficient
>
> ANR4556W recovery log space to lower utilization below the database backup
>
> ANR4556W trigger. The recovery log size may need to be increased.
>
> We were eventually forced to bounce ADSM to get the recovery log back down
> to 0.1 %. Here is the recovery log status:
>
> Available Space (MB): 3,520
> Assigned Capacity (MB): 3,520
> Maximum Extension (MB): 0
> Maximum Reduction (MB): 3,484
> Page Size (bytes): 4,096
> Total Usable Pages: 900,608
> Used Pages: 8,420
> Pct Util: 0.9
> Max. Pct Util: 0.9
> Physical Volumes: 4
> Log Pool Pages: 512
> Log Pool Pct. Util: 0.11
> Log Pool Pct. Wait: 0.00
> Cumulative Consumption (MB): 125,835.95
> Consumption Reset Date/Time: 04/16/1998 09:07:19
>
> Here is our database status:
>
> Available Space (MB): 16,044
> Assigned Capacity (MB): 15,004
> Maximum Extension (MB): 1,040
> Maximum Reduction (MB): 4,588
> Page Size (bytes): 4,096
> Total Usable Pages: 3,841,024
> Used Pages: 2,666,346
> Pct Util: 69.4
> Max. Pct Util: 69.4
> Physical Volumes: 11
> Buffer Pool Pages: 8,192
> Total Buffer Requests: 10,998,632
> Cache Hit Pct.: 99.15
> Cache Wait Pct.: 0.00
> Backup in Progress?: No
> Type of Backup In Progress:
> Incrementals Since Last Full: 2
> Changed Since Last Backup (MB): 39.00
> Percentage Changed: 0.37
> Last Complete Backup Date/Time: 11/30/1998 08:34:27
>
> We are still running in roll forward mode. Can someone advise us as to
> whether we should keep going in roll forward mode or revert to normal
> mode.
> Also any advise as to how to manage roll forward mode will be appreciated.
>
> Thanks.
>
> Kind regards,
> Desigan Moodley
> * <mailto:DesiganM AT Transnet.co DOT za> DesiganM AT Transnet.co DOT za
|
