Example 1
The following example restores the mf_personnel database from
the backup file pers_bu.rbf and requests a new version of the
database file. Because the After_Journal qualifier has been
specified, automatic recovery will not be attempted.
$ RMU/RESTORE/NEW_VERSION/AFTER_JOURNAL=AIJ_DISK:[AIJS]PERSAIJ -
_$ /NOCDD_INTEGRATE/LOG PERS_BU -
_$ EMP_INFO /THRESHOLDS=(65,75,80)/BLOCKS_PER_PAGE=3
The command changes the .aij file location and name to
AIJ_DISK:[AIJS]PERSAIJ.AIJ, prevents integration with the data
dictionary, and displays the progress of the restore operation.
For the storage area, EMP_INFO, the command changes the SPAM
threshold values to 65%, 75%, and 80%, and increases the number
of blocks per page to 3 blocks.
Example 2
Assume that at 10 A.M., Wednesday, October 25, 2005, a disk
device hardware failure corrupted all the files on the device,
including the mf_personnel.rdb file. The following command
restores the full database backup file (pers_full_oct22.rbf)
created on the previous Sunday and then restores the incremental
backup file made on Tuesday. Note that an incremental database
backup file was created on Monday, but each new incremental
backup file made since the latest full backup file replaces
previous incremental backup files made since the last full backup
operation.
$ RMU/RESTORE/LOG/NORECOVERY MUA1:PERS_FULL_OCT22.RBF
$ RMU/RESTORE/INCREMENTAL/CONFIRM/LOG/NORECOVERY -
_$ PERS_INCR_OCT24.RBF
At this point, the database is current up until 11:30 P.M.,
Tuesday, when the last incremental backup file was made of mf_
personnel. Because after-image journaling is enabled for this
database, automatic recovery of the .aij file could have been
employed. However, if the recovery process should fail for
some reason or, as in this case, the Norecovery qualifier is
specified, you can still use the RMU Recover command to apply
the .aij file that contains changes made to the database from
11:30 P.M., Tuesday, until just before the hardware failure to
the restored mf_personnel.rdb file and its storage area files.
For example:
$ RMU/RECOVER/UNTIL = "25-OCT-2005 09:55:00.00" -
_$ AIJ_DISK:[AIJS]PERSAIJ.AIJ;1
Example 3
If a storage area is on a disk that fails, you might want to
move that storage area to another disk by using the RMU Restore
command. The following RMU Restore command restores only the
EMPIDS_OVER storage area from the full backup file of mf_
personnel, and moves the EMPIDS_OVER storage area and snapshot
(.snp) file to a new location on the 333$DUA11 disk. The recovery
operation is only required if the required .aij file has been
backed up and is no longer in the current aij state.
$ RMU/RESTORE/AREA 222$DUA20:[BACKUPS]MF_PERS_BU.RBF -
_$ EMPIDS_OVER /FILE=333$DUA11:[DBS]EMPIDS_OVER.RDA -
_$ /SNAPSHOT=(FILE=333$DUA11:[DBS]EMPIDS_OVER.SNP)
$ !
$ ! Recovery from the after-image journal is automatic. If
$ ! automatic recovery is not possible, or if the Norecovery
$ ! qualifier had been specified, perform the following:
$ !
$ RMU/RECOVER/AREA AIJ_DISK:PERS.AIJ
Example 4
The following example demonstrates how you can use by-area backup
and restore operations for a single storage area in the mf_
personnel database. In addition, it demonstrates the use of the
automatic recovery feature of the RMU Restore command.
$ !
$ ! Create an .aij file for the database. Because three
$ ! .aij files are created, fixed-size .aij
$ ! journaling will be used.
$ !
$ RMU/SET AFTER_JOURNAL/ENABLE/RESERVE=4 -
_$ /ADD=(name=AIJ1, FILE=DISK2:[CORP]AIJ_ONE) -
_$ /ADD=(name=AIJ2, FILE=DISK2:[CORP]AIJ_TWO) -
_$ /ADD=(NAME=AIJ3, FILE=DISK2:[CORP]AIJ_THREE) -
_$ MF_PERSONNEL.RDB
%RMU-W-DOFULLBCK, full database backup should be done to
ensure future recovery
$ RMU/BACKUP MF_PERSONNEL DISK3:[BACKUP]MF_PERS.RBF
$ SQL
SQL> ATTACH 'FILENAME MF_PERSONNEL';
SQL> --
SQL> -- On Monday, define a new row in the DEPARTMENTS table. The
SQL> -- new row is stored in the DEPARTMENTS storage area.
SQL> --
SQL> INSERT INTO DEPARTMENTS
cont> (DEPARTMENT_CODE, DEPARTMENT_NAME, MANAGER_ID,
cont> BUDGET_PROJECTED, BUDGET_ACTUAL)
cont> VALUES ('WLNS', 'Wellness Center', '00188', 0, 0);
1 row inserted
SQL>
SQL> COMMIT;
SQL> EXIT;
$ !
$ ! Assume that you know that the only storage area ever updated in
$ ! the mf_personnel database on Tuesdays is the SALARY_HISTORY
$ ! storage area, and you decide that you will create an incremental
$ ! backup file of just the SALARY_HISTORY storage area on Tuesday.
$ ! Before you perform the by-area backup operation on the
$ ! SALARY_HISTORY storage area on Tuesday, you must perform a full
$ ! and complete backup operation on the mf_personnel database when
$ ! it is in a known and working state.
$ !
$ RMU/BACKUP MF_PERSONNEL.RDB -
_$ DISK3:[BACKUP]MF_MONDAY_FULL.RBF
$ !
SQL> --
SQL> -- On Tuesday, two rows are updated in
SQL> -- the SALARY_HISTORY storage area.
SQL> --
SQL> UPDATE SALARY_HISTORY
cont> SET SALARY_END ='20-JUL-2003 00:00:00.00'
cont> WHERE SALARY_START='14-JAN-1993 00:00:00.00'
cont> AND EMPLOYEE_ID = '00164';
1 row updated
SQL> UPDATE SALARY_HISTORY
cont> SET SALARY_START ='5-JUL-2000 00:00:00.00'
cont> WHERE SALARY_START='5-JUL-1990 00:00:00.00'
cont> AND EMPLOYEE_ID = '00164';
1 row updated
SQL> COMMIT;
SQL> EXIT;
$ !
$ ! On Tuesday, you create an incremental backup file of the
$ ! SALARY_HISTORY storage area only. Only the SALARY_HISTORY
$ ! storage area is included in the by-area backup file.
$ ! Oracle RMU provides an informational message telling
$ ! you that not all storage areas in the database are included
$ ! in the mf_tuesday_partial.rbf backup file.
$ RMU/BACKUP/INCLUDE=(SALARY_HISTORY) -
_$ /INCREMENTAL/LOG DISK1:[USER]MF_PERSONNEL.RDB -
_$ DISK3:[BACKUPS]MF_TUESDAY_PARTIAL.RBF
%RMU-I-NOTALLARE, Not all areas will be included in
this backup file
%RMU-I-LOGLASCOM, Last full and complete backup was dated
18-JAN-2006 11:19:46.31
%RMU-I-BCKTXT_00, Backed up root file
DISK1:[DB]MF_PERSONNEL.RDB;1
%RMU-I-BCKTXT_03, Starting incremental backup of
storage area DISK3:[SA}SALARY_HISTORY.RDA;1 at
18-JAN-2006 11:20:49.29
%RMU-I-BCKTXT_13, Completed incremental backup of
storage area DISK3:[SA]SALARY_HISTORY.RDA;1 at
18-JAN-2006 11:20:49.40
%RMU-I-COMPLETED, BACKUP operation completed at
18-JSN-2006 11:20:49.59
.
.
.
$ !
SQL> -- Update another row in the SALARY_HISTORY table:
SQL> UPDATE SALARY_HISTORY
cont> SET SALARY_START ='23-SEP-1991 00:00:00.00'
cont> WHERE SALARY_START='21-SEP-1981 00:00:00.00'
cont> AND EMPLOYEE_ID = '00164';
1 row updated
SQL> COMMIT;
SQL> EXIT;
$ ! Assume that a disk device hardware error occurs here
$ ! and only the SALARY_HISTORY storage area and snapshot
$ ! file is lost. Also assume that the database root (.rdb)
$ ! file and other storage areas in the database are still
$ ! fine and do not need to be restored or recovered.
$ ! Therefore, you do not need to restore the .rdb file or
$ ! other storage areas from the full and complete backup
$ ! file. Because only the SALARY_HISTORY storage area was
$ ! lost, you must do the following:
$ ! 1) Restore the SALARY_HISTORY storage area and snapshot
$ ! file from the last full and complete backup file. Note
$ ! this operation can be done on line. Specify the Norecovery
$ ! qualifier because you still have an incremental restore
$ ! operation to perform.
$ ! 2) Restore the SALARY_HISTORY storage area from the last
$ ! incremental backup file. Note this operation can be
$ ! done on line. This time do not specify the Norecovery
$ ! qualifier so that the automatic recovery provided by
$ ! Oracle RMU will be implemented.
$ !
$ RMU/RESTORE/NOCDD_INTEGRATE/ONLINE/LOG/NORECOVERY -
_$ /AREA DISK3:[BACKUP]MF_MONDAY_FULL.RBF SALARY_HISTORY
%RMU-I-RESTXT_21, Starting full restore of storage area
DISK1:[USER]SALARY_HISTORY.RDA;1 at 18-JAN-2006 11:25:13.17
%RMU-I-RESTXT_24, Completed full restore of storage area
DISK1:[USER]SALARY_HISTORY.RDA;1 at 18-JAN-2006 11:25:13.86
%RMU-I-RESTXT_01, Initialized snapshot file
DISK1:[USER]SALARY_HISTORY.SNP;1
%RMU-I-LOGINIFIL, contains 100 pages, each page is 2
blocks long
%RMU-I-AIJWASON, AIJ journaling was active when the database
was backed up
%RMU-I-AIJRECFUL, Recovery of the entire database starts with
AIJ file sequence 0
%RMU-I-AIJRECARE, Recovery of area SALARY_HISTORY starts with
AIJ file sequence 0
%RMU-I-COMPLETED, RESTORE operation completed at 18-JAN-2006 11:25:14.51
$ RMU/RESTORE/NOCDD_INTEGRATE/INCREMENTAL/ONLINE/LOG -
_$ /AREA DISK3:[BACKUPS]MF_TUESDAY_PARTIAL.RBF SALARY_HISTORY
DISK1:[USER]MF_PERSONNEL.RDB;1, restore incrementally? [N]:Y
%RMU-I-RESTXT_22, Starting incremental restore of storage area
DISK1:[USER]SALARY_HISTORY.RDA;1 at 18-JAN-2006 11:29:35.54
%RMU-I-RESTXT_25, Completed incremental restore of storage area
DISK1:[USER]SALARY_HISTORY.RDA;1 at 18-JAN-2006 11:29:35.64
%RMU-I-RESTXT_01, Initialized snapshot file
DISK1:[USER]SALARY_HISTORY.SNP;1
%RMU-I-LOGINIFIL, contains 100 pages, each page is 2
blocks long
%RMU-I-AIJWASON, AIJ journaling was active when the database
was backed up
%RMU-I-AIJRECFUL, Recovery of the entire database starts with
AIJ file sequence 0
%RMU-I-AIJRECARE, Recovery of area SALARY_HISTORY starts with
AIJ file sequence 0
%RMU-I-AIJBADAREA, inconsistent storage area
DISK1:[USER]SALARY_HISTORY.RDA;1 needs AIJ sequence number 0
%RMU-I-LOGRECDB, recovering database file
DISK1:[USER]MF_PERSONNEL.RDB;1
%RMU-I-AIJAUTOREC, starting automatic after-image journal recovery
%RMU-I-LOGOPNAIJ, opened journal file DISK2:[CORP]AIJ_ONE.AIJ;17
%RMU-I-AIJONEDONE, AIJ file sequence 0 roll-forward operations completed
%RMU-I-LOGRECOVR, 1 transaction committed
%RMU-I-LOGRECOVR, 0 transactions rolled back
%RMU-I-LOGRECOVR, 3 transactions ignored
%RMU-I-AIJNOACTIVE, there are no active transactions
%RMU-I-AIJSUCCES, database recovery completed successfully
%RMU-I-AIJALLDONE, after-image journal roll-forward operations completed
%RMU-I-LOGSUMMARY, total 1 transaction committed
%RMU-I-LOGSUMMARY, total 0 transactions rolled back
%RMU-I-LOGSUMMARY, total 3 transactions ignored
%RMU-I-AIJSUCCES, database recovery completed successfully
Example 5
In the following example, the options file specifies that the
storage area (.rda) files are to be restored to different disks.
Note that storage area snapshot (.snp) files are restored to
different disks from one another and from their associated
storage area (.rda) files; this is recommended for optimal
performance. (This example assumes that the disks specified for
each storage area file in options_file.opt are different from
those where the storage area files currently reside.)
$ RMU/RESTORE/NOCDD_INTEGRATE/OPTIONS=OPTIONS_FILE.OPT -
_$ MF_PERS_BCK.RBF
$ TYPE OPTIONS_FILE.OPT
EMPIDS_LOW /FILE=DISK1:[CORPORATE.PERSONNEL]EMPIDS_LOW.RDA -
/SNAPSHOT=(FILE=DISK2:[CORPORATE.PERSONNEL]EMPIDS_LOW.SNP )
EMPIDS_MID /FILE=DISK3:[CORPORATE.PERSONNEL]EMPIDS_MID.RDA -
/SNAPSHOT=(FILE=DISK4:[CORPORATE.PERSONNEL]EMPIDS_MID.SNP )
EMPIDS_OVER /FILE=DISK5:[CORPORATE.PERSONNEL]EMPIDS_OVER.RDA -
/SNAPSHOT=(FILE=DISK6:[CORPORATE.PERSONNEL]EMPIDS_OVER.SNP )
DEPARTMENTS /FILE=DISK7:[CORPORATE.PERSONNEL]DEPARTMENTS.RDA -
/SNAPSHOT=(FILE=DISK8:[CORPORATE.PERSONNEL]DEPARTMENTS.SNP )
SALARY_HISTORY /FILE=DISK9:[CORPORATE.PERSONNEL]SALARY_HISTORY.RDA -
/SNAPSHOT=(FILE=DISK10:[CORPORATE.PERSONNEL]SALARY_HISTORY.SNP )
JOBS /FILE=DISK7:[CORPORATE.PERSONNEL]JOBS.RDA -
/SNAPSHOT=(FILE=DISK8:[CORPORATE.PERSONNEL]JOBS.SNP )
EMP_INFO /FILE=DISK9:[CORPORATE.PERSONNEL]EMP_INFO.RDA -
/SNAPSHOT=(FILE=DISK10:[CORPORATE.PERSONNEL]EMP_INFO.SNP )
RESUME_LISTS /FILE=DISK11:[CORPORATE.PERSONNEL]RESUME_LISTS.RDA -
/SNAPSHOT=(FILE=DISK12:[CORPORATE.PERSONNEL]RESUME_LISTS.SNP )
RESUMES /FILE=DISK9:[CORPORATE.PERSONNEL]RESUMES.RDA -
/SNAPSHOT=(FILE=DISK10:[CORPORATE.PERSONNEL]RESUMES.SNP )
Example 6
The following example shows what .aij file sequence to use
following an RMU Restore command with the Area qualifier if
automatic recovery fails:
$ RMU/RESTORE/AREA MFPERS_62691.RBF -
DEPARTMENTS, JOBS
.
.
.
%RMU-I-AIJWASON, AIJ journaling was active when the
database was backed up
%RMU-I-AIJRECFUL, Recovery of the entire database
starts with AIJ file sequence 0
Example 7
The following example shows how to move a single-file database to
a new directory, using the RMU Backup and RMU Restore commands:
$ RMU/BACKUP PERSONNEL PERS
$!
$ RMU/RESTORE/NOCDD/NOAFTER_JOURNAL -
_$ /DIRECTORY=DISK4:[USER2] PERS
Example 8
The following example shows how to rename a single-file database
when you move the database by using the RMU Backup and RMU
Restore commands:
$ RMU/BACKUP PERSONNEL PERS
$!
$ RMU/RESTORE/NOCDD/NOAFTER_JOURNAL -
_$ /DIRECTORY=DISK4:[USER2]TEST_PERSONNEL PERS
Example 9
The following example causes the database being restored from
the mf_pers_bck.rbf backup file to have 60 global buffers, with
a limit of 2 buffers for each database user. Because the Enabled
option is used, global buffering is in effect for the database
immediately after it is restored:
$ RMU/RESTORE/NOCDD/GLOBAL_BUFFERS=(ENABLED,TOTAL=60,USER_LIMIT=2) -
_$ MF_PERS_BCK.RBF
Example 10
The following command causes the SALARY_HISTORY storage area
from the database being restored from the mf_pers_bu.rbf backup
file to be restored as a read-only storage area. None of the
other database storage areas are modified as part of this restore
operation.
$ RMU/RESTORE/NOCDD MF_PERS_BU.RBF SALARY_HISTORY /READ_ONLY
Example 11
The following example assumes that you are using multiple tape
drives to perform a large restore operation. By specifying the
Loader_Synchronization and Volumes qualifiers, this command does
not require you to load tapes as each completes. Instead, you
can load tapes on a loader or stacker and the RMU restore process
will wait until all concurrent tape operations have concluded
for one set of tape volumes before assigning the next set of tape
volumes. This example assumes that the backup operation used two
tape output threads and each thread wrote four tapes.
This example uses Master qualifiers to indicate that you want the
$111$MUA0: and $444$MUA2: drives to be master drives.
Using this example, you would:
1. Allocate each tape drive.
2. Manually place tapes BACK01 and BACK05 on the $111$MUA0:
master drive.
3. Manually place tapes BACK02 and BACK06 on the $333$MUA2:
master drive.
4. Manually place tapes BACK03 and BACK07 on the $222$MUA1: slave
drive.
5. Manually place tapes BACK04 and BACK08 on the $444$MUA3: slave
drive.
6. Mount the first volume (BACK01).
7. Perform the restore operation.
8. Dismount the last tape mounted.
9. Deallocate each tape drive.
$ ALLOCATE $111$MUA0:
$ ALLOCATE $222$MUA1:
$ ALLOCATE $333$MUA2:
$ ALLOCATE $444$MUA3:
$
$ MOUNT/FOREIGN $111$MUA0:
$
$ RMU/RESTORE/LOG/REWIND/LOADER_SYNCHRONIZATION -
_$ /LABEL=(BACK01, BACK02, BACK03, BACK04, BACK05, -
_$ BACK06, BACK07, BACK08) -
_$ /VOLUMES=8 -
_$ $111$MUA0:PERS_FULL_MAR30.RBF/MASTER, $222$MUA1: -
_$ $333$MUA2:/MASTER, $444$MUA3
$
$ DISMOUNT $222$MUA3:
$
$ DEALLOCATE $111$MUA0:
$ DEALLOCATE $222$MUA1:
$ DEALLOCATE $333$MUA2:
$ DEALLOCATE $444$MUA3:
Example 12
The following example demonstrates the automatic .aij recovery
mechanism in the RMU Restore command. The example does the
following:
o Uses the RMU Set After_Journal command to reserve space for
four .aij files, adds three .aij files, and enables after-
image journaling
o Performs a backup operation on the database
o Performs database update activity, which will be written to an
.aij file
o Determines the database root file is lost
o Restores and recovers the database in one RMU Restore command
$ SET DEFAULT DISK1:[USER]
$ !
$ RMU/SET AFTER_JOURNAL/ENABLE/RESERVE=4 -
_$ /ADD=(name=AIJ1, FILE=DISK2:[CORP]AIJ_ONE) -
_$ /ADD=(name=AIJ2, FILE=DISK2:[CORP]AIJ_TWO) -
_$ /ADD=(NAME=AIJ3, FILE=DISK2:[CORP]AIJ_THREE) -
_$ MF_PERSONNEL
%RMU-W-DOFULLBCK, full database backup should be done
to ensure future recovery
$ !
$ ! Back up database, as instructed.
$ !
$ RMU/BACKUP MF_PERSONNEL DISK3:[BACKUPS]MF_PERS.RBF
$ !
$ ! Database update activity occurs.
$ !
$!
$! Database is lost. Issue the RMU Restore command to
$! restore and recover the database. Because the Norecovery
$! qualifier is not specified, Oracle RMU will
$! automatically attempt to recover the database.
$!
$ RMU/RESTORE DISK3:[BACKUPS]MF_PERS.RBF/NOCDD_INTEGRATE
%RMU-I-AIJRSTAVL, 3 after-image journals available for use
%RMU-I-AIJRSTMOD, 1 after-image journal marked as "modified"
%RMU-I-AIJISON, after-image journaling has been enabled
%RMU-W-DOFULLBCK, full database backup should be done
to ensure future recovery
%RMU-I-LOGRECDB, recovering database file
DISK1:[USER]MF_PERSONNEL.RDB;1
%RMU-I-AIJAUTOREC, starting automatic after-image
journal recovery
%RMU-I-AIJONEDONE, AIJ file sequence 0 roll-forward
operations completed
%RMU-I-AIJONEDONE, AIJ file sequence 1 roll-forward
operations completed
%RMU-W-NOTRANAPP, no transactions in this journal
were applied
%RMU-I-AIJALLDONE, after-image journal roll-forward
operations completed
%RMU-I-AIJSUCCES, database recovery completed successfully
%RMU-I-AIJFNLSEQ, to start another AIJ file recovery,
the sequence number needed will be 1
Example 13
The following example demonstrates how to restore and recover all
the corrupt pages and areas in the mf_personnel database. Assume
that the RMU Show Corrupt_Pages command shows that the JOBS
storage area is corrupt and that only page 3 in the DEPARTMENTS
storage area is corrupt. All the other storage areas are neither
corrupt nor inconsistent. Because the Just_Corrupt qualifier is
specified in the global position, and mf_personnel.rbf is a full
backup file, the RMU restore process restores all of the JOBS
storage area and just page 3 in the DEPARTMENTS storage area.
If after-image journaling is enabled, automatic recovery will be
attempted.
$ RMU/RESTORE/AREA/JUST_CORRUPT MF_PERSONNEL.RBF
Example 14
The following example demonstrates how to restore and recover
specific corruptions in the mf_personnel database. Like example
12, assume that the RMU Show Corrupt_Pages command shows that
the JOBS storage area is corrupt and that only page 3 in the
DEPARTMENTS storage area is corrupt. All the other storage
areas are neither corrupt nor inconsistent. The backup file,
mf_partial.rbf, is a by-area backup file containing backups of
the JOBS, DEPARTMENTS, and SALARY_HISTORY storage areas. In this
example, the JOBS, DEPARTMENTS, and SALARY_HISTORY areas are
specified for restoring. Because the SALARY_HISTORY area contains
no corruptions, an informational message is returned. The RMU
restore process restores all of the JOBS storage area and just
page 3 in the DEPARTMENTS storage area. If after-image journaling
is enabled, automatic recovery will be attempted.
$ RMU/RESTORE/JUST_CORRUPT/AREA MF_PARTIAL.RBF JOBS, -
_$ DEPARTMENTS,SALARY_HISTORY
%RMU-I-RESTXT_20, Storage area DISK1:[AREA]SALARY_HISTORY.RDA;1 is not
corrupt and will not be restored
Example 15
The following example demonstrates how to restore and recover
specific corruptions in the mf_personnel database along with
restoring an area that is not corrupt. Like example 13, assume
that the RMU Show Corrupt_Pages command shows that the JOBS
storage area is corrupt and that only page 3 in the DEPARTMENTS
storage area is corrupt. All the other storage areas are neither
corrupt nor inconsistent. The backup file, mf_personnel.rbf, is a
full backup file. In this example, the Just_Corrupt qualifier is
used locally with the DEPARTMENTS storage area.
The JOBS, DEPARTMENTS, and SALARY_HISTORY areas are specified
for restoring. Although the SALARY_HISTORY area contains no
corruptions, an informational message is not returned in this
case because by specifying the Just_Corrupt qualifier locally
with DEPARTMENTS, the Restore command is requesting that the RMU
restore process restore the JOBS and SALARY_HISTORY storage areas
regardless of corruptions, and the DEPARTMENTS storage area be
restored to fix corruptions. The RMU restore process restores
all of the JOBS and SALARY_HISTORY storage areas and just page
3 in the DEPARTMENTS storage area. If after-image journaling is
enabled, automatic recovery will be attempted.
$ RMU/RESTORE/AREA MF_PERSONNEL.RBF JOBS, SALARY_HISTORY, -
_$ DEPARTMENTS/JUST_CORRUPT
Example 16
The following example is the same as example 15, except the Just_
Corrupt qualifier is specified locally with the SALARY_HISTORY
storage area. Because the SALARY_HISTORY qualifier contains no
corruptions, an error message is returned:
$ RMU/RESTORE/AREA MF_PERSONNEL.RBF JOBS,SALARY_HISTORY/JUST_CORRUPT, -
_$ DEPARTMENTS/JUST_CORRUPT
%RMU-I-RESTXT_20, Storage area DISK1:[AREA]SALARY_HISTORY.RDA;1 is
not corrupt and will not be restored
Example 17
The following example demonstrates the behavior of the RMU
Restore command when the Just_Corrupt qualifier is used both
globally and locally. The global use of the Just_Corrupt
qualifier overrides an local use of the qualifier. In this case,
the RMU restore process restores the JOBS, SALARY_HISTORY, and
DEPARTMENTS storage areas only if they contain corruptions;
otherwise an error is returned. Assume, like the previous
examples, that only the JOBS and DEPARTMENTS storage areas
contain corruptions:
$ RMU/RESTORE/JUST_CORRUPT/AREA MF_PERSONNEL.RBF SALARY_HISTORY, -
_$ JOBS/JUST_CORRUPT, DEPARTMENTS/JUST_CORRUPT
%RMU-I-RESTXT_20, Storage area DISK1:[AREA]SALARY_HISTORY.RDA;1 is
not corrupt and will not be restored