Solved

Delete old backups in RMAN

Posted on 2000-03-31
5
1,043 Views
Last Modified: 2008-02-01
What determines which backup set gets reported in the command "report obsolete" in RMAN? Is it the parameter CONTROL_FILE_RECORD_KEEP_TIME  in the init.ora file? Can anyone help with this?

Thanks in advance.
0
Comment
Question by:rsolomon
  • 3
  • 2
5 Comments
 
LVL 5

Accepted Solution

by:
sbenyo earned 100 total points
ID: 2674125
Hi,

The REPORT OBSOLETE command determines its obsolete backup sets from the recovery catalog, which means from its own tables/views.

The recovery catalog is a set of tables/views that keep all the information about backup sets / backup pieces of RMAN.

For example, all the backup sets information is kept in the view RC_BACKUP_SET (under the recovery catalog user).

When issuing backups, the controlfile is updated with the backup information.

The controlfile also keeps records about backup sets and backup pieces of RMAN.
The controlfile keeps two types of records: permanent records and reusable records.
The parameter CONTROL_FILE_RECORD_KEEP_TIME determines the minimum time after which the reusable records in the controlfile will be reused.
The default is 7 days and this is done to control the growth of the controlfile.
To see information about the records in the controlfile look at the view:
V$CONTROLFILE_RECORD_SECTION

RMAN resyncs its data from the controlfile, so it is important that resyncs in RMAN will occur in a frequency less than the CONTROL_FILE_RECORD_KEEP_TIME else RMAN may lose records that were overriden in the controlfile.
0
 

Author Comment

by:rsolomon
ID: 2674237
So what you are telling me is that CONTROL_FILE_RECORD_KEEP_TIME controls what is obsolete or not?
0
 
LVL 5

Expert Comment

by:sbenyo
ID: 2677460
The CONTROL_FILE_RECORD_KEEP_TIME is NOT controling what is obsoelete.

Obsolete which means what backup sets are no longer needed for recovery, is determined from RMAN's catalog by checking the backup sets SCNs that are needed for recovery.

RMAN's catalog gets its data from the controlfile, and the catalog is updated whenever a resynch occurs.

The controlfile itself gathers backup set data and keeps it in records.
A new record is added for each new backup set.
The CONTROL_FILE_RECORD_KEEP_TIME controls only the records in the controlfile, and it means how long the records will be kept (added) to the controlfile without being runover again.

Let's take an example.
You perform a backup which adds 3 new backupsets.
The controlfile adds these 3 backupsets to itself and grows.
When you issue a recovery, or a new backup (or manual resync) RMAN reads the controlfile records and adds the information to its own CATALOG.

lets say 7 days passed. (The time in CONTROL_FILE_RECORD_KEEP_TIME)
Now you backup again and add 3 new backup sets.
The new backup sets records will be added to the controlfile over the first backupsets!

If RMAN's catalog did not read the first 3 backup set records from the controlfile they are now lost forever.

To summerize it simply:

1) RMAN determines Obsolete backup sets by comparing SCNs according to its CATALOG data

2) RMAN updates its CATALOG data by reading the controlfile records

3) The controlfile adds record with each new backup set

4) The controlfile will runover records if it reached the time specified in the CONTROL_FILE_RECORD_KEEP_TIME.

5) Because of what's written above, always resync the CATALOG before the time in the CONTROL_FILE_RECORD_KEEP_TIME, so the CATALOG will not lose records.

Is it clear now ?

0
 
LVL 5

Expert Comment

by:sbenyo
ID: 2677532
The CONTROL_FILE_RECORD_KEEP_TIME is NOT controling what is obsoelete.

Obsolete which means what backup sets are no longer needed for recovery, is determined from RMAN's catalog by checking the backup sets SCNs that are needed for recovery.

RMAN's catalog gets its data from the controlfile, and the catalog is updated whenever a resynch occurs.

The controlfile itself gathers backup set data and keeps it in records.
A new record is added for each new backup set.
The CONTROL_FILE_RECORD_KEEP_TIME controls only the records in the controlfile, and it means how long the records will be kept (added) to the controlfile without being runover again.

Let's take an example.
You perform a backup which adds 3 new backupsets.
The controlfile adds these 3 backupsets to itself and grows.
When you issue a recovery, or a new backup (or manual resync) RMAN reads the controlfile records and adds the information to its own CATALOG.

lets say 7 days passed. (The time in CONTROL_FILE_RECORD_KEEP_TIME)
Now you backup again and add 3 new backup sets.
The new backup sets records will be added to the controlfile over the first backupsets!

If RMAN's catalog did not read the first 3 backup set records from the controlfile they are now lost forever.

To summerize it simply:

1) RMAN determines Obsolete backup sets by comparing SCNs according to its CATALOG data

2) RMAN updates its CATALOG data by reading the controlfile records

3) The controlfile adds record with each new backup set

4) The controlfile will runover records if it reached the time specified in the CONTROL_FILE_RECORD_KEEP_TIME.

5) Because of what's written above, always resync the CATALOG before the time in the CONTROL_FILE_RECORD_KEEP_TIME, so the CATALOG will not lose records.

Is it clear now ?

0
 

Author Comment

by:rsolomon
ID: 2680543
Yes
0

Featured Post

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Join & Write a Comment

Introduction A previously published article on Experts Exchange ("Joins in Oracle", http://www.experts-exchange.com/Database/Oracle/A_8249-Joins-in-Oracle.html) makes a statement about "Oracle proprietary" joins and mixes the join syntax with gen…
Background In several of the companies I have worked for, I noticed that corporate reporting is off loaded from the production database and done mainly on a clone database which needs to be kept up to date daily by various means, be it a logical…
This video explains at a high level with the mandatory Oracle Memory processes are as well as touching on some of the more common optional ones.
This video shows setup options and the basic steps and syntax for duplicating (cloning) a database from one instance to another. Examples are given for duplicating to the same machine and to different machines

707 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now