Each release Oracle brought up new features and enhancements to RMAN improving its ease of use and functionality. Using the updateable persistent configuration options (CONFIGURE ….), backup up the database is easier then in the first version of RMAN introduced in 8i. It is help to list the Synonyms containing the word RMAN and BACKUP in them.
Here’s a list from an Oracle 11g database for those with BACKUP in the name:
39 rows selected.
Here’s a list from the same Oracle 11g database with RMAN in the name:
13 rows selected.
Controlfile views to reference are:
62 rows selected.
That is a lot of objects and views. To view the default RMAN configuration and then check the V$ view to see what is stored you can accomplish this with a query like this:
set linesize 132
select * from v$rman_configuration
CONF# NAME VALUE
5 DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1
8 MAXSETSIZE TO UNLIMITED
9 rows selected.
If you aren’t using a recovery catalog you can look at the controlfile since this is were backup information is maintained if you aren’t using a recovery catalog:
select type, records_total, records_used
TYPE RECORDS_TOTAL RECORDS_USED
6 rows selected.
The records used column isn’t zero because I’ve taken numerous backups, however, if you haven’t completed a backup yet this column will be zero. When RMAN reads the files to determine the files that will be backed up, if any corruption is detected then the corruption views are populated with that information such as file#, block# and contiguous blocks after the initial corrupt block.
RMAN will continue to use the persistent backup configuration settings once they are set unless they are overridden. The RMAN “SHOW” command displays those settings:
SHOW option [,parameter, ...]
RMAN> show all;
Recovery Manager: Release 184.108.40.206.0 – Production on Sat Nov 1 21:32:38 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
show all;connected to target database: PS90HRDV (DBID=2173713801)
You can script the configuration parameters you want to use within a run block to change one or more parameters or just change a single parameter at a time from the RMAN prompt and not use the run block option.
CONNECT catalog rman/rman
Enabling and Disabling Change Tracking
You can enable or disable change tracking when the database is either open or mounted. To alter the change tracking setting, you must use SQL*Plus to connect to the target database with administrator privileges.
To store the change tracking file in the database area, set DB_CREATE_FILE_DEST in the target database. Then issue the following SQL statement to enable change tracking: SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
You can also create the change tracking file in a location you choose yourself, using the following SQL statement: SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '/mydir/rman_change_track.f' REUSE;
The REUSE option tells Oracle to overwrite any existing file with the specified name.
To disable change tracking, use this SQL statement: SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
If the change tracking file was stored in the database area, then it is deleted when you disable change tracking.
Checking Whether Change Tracking is Enabled
From SQL*Plus, you can query V$BLOCK_CHANGE_TRACKING.STATUS to determine whether change tracking is enabled, and if it is, query V$BLOCK_CHANGE_TRACKING.FILENAME to display the filename.
Moving the Change Tracking File
If you need to move the change tracking file, the ALTER DATABASE RENAME FILE command updates the control file to refer to the new location. The process outlined in this section describes how to change the location of the change tracking file while preserving its contents.
To relocate the change tracking file:
If necessary, determine the current name of the change tracking file: SELECT filename
Shut down the database. For example: SHUTDOWN IMMEDIATE
Using host operating system commands, move the change tracking file to its new location.
Mount the database and move the change tracking file to a location that has more space. For example: ALTER DATABASE RENAME FILE 'ora_home/dbs/change_trk.f' TO '/new_disk/change_trk.f';
Open the database: ALTER DATABASE OPEN;
If you cannot shut down the database, then you must disable change tracking and re-enable it at the new location, as in the following example: ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE 'new_location';
If you choose this method, you will lose the contents of the change tracking file. Until the next time you complete a level 0 incremental backup, RMAN will have to scan the entire file.
Estimating Size of the Change Tracking File on Disk
The size of the change tracking file is proportional to the size of the database and the number of enabled threads of redo. The size is not related to the frequency of updates to the database. Typically, the space required for block change tracking is approximately 1/30,000 the size of the data blocks to be tracked. Note, however, the following two factors that may cause the file to be larger than this estimate suggests:
To avoid overhead of allocating space as your database grows, the change tracking file size starts at 10MB, and new space is allocated in 10MB incremenents. Thus, for any database up to approximately 300GB the file size is no smaller than 10MB, for up to approximately 600GB the file size is no smaller than 20MB, and so on.
For each datafile, a minimum of 320K of space is allocated in the change tracking file, regardless of the size of the file. Thus, if you have a large number of relatively small datafiles, the change tracking file is larger than for databases with a smaller number of larger datafiles containing the same data.
RMAN Quick Ref >