4. Operation › 4.3 Operations Reference › 4.3.3 Operational Processes, Jobs, and Steps › 4.3.3.2 Operational Jobs › 4.3.3.2.7 RESTORE Operational Job
4.3.3.2.7 RESTORE Operational Job
+-----------------------------------------------------------+
| |
| Backup |
| Data |
| Files |
| | |
| | |
| | |
| V |
| Checkpoint +---------+ Operational |
| File<--------->| RESTORE |--------->Status and |
| +---------+ Tracking |
| | |
| | |
| +----------+-----------+ |
| | | |
| V V |
| Online Checkpoint |
| Database File |
| |
+-----------------------------------------------------------+
Run the RESTORE job to recover the Database.
The JCL for the RESTORE job is in prefix.MICS.CNTL(RESTORE).
It is tailored to the components in the unit, and if
compression was active for the files when they were
compressed, the data is restored in compressed format.
The RESTORE job defaults to the current (0) generation
backup. You can also restore from another daily backup
generation or from a monthly backup.
Recovery to the day level (from a standard daily backup
generation) places the CA MICS Database in the status it was
in when the specified Daily backup was executed.
Recovery to the month level (from a monthly backup
generation) protects the CA MICS Database from the
vulnerability of bad data being processed for a period of
time greater than the number of generations of daily backup
tapes. The monthly backup also provides an alternative to
restoring from a daily backup prior to the last monthly and
having to rerun a monthly process.
If you have activated incremental update for any product in
the unit database, the RESTORE job may issue messages warning
that you may need to re-initialize the incremental update
database files. If one or more INCRccc jobs completed prior
to running the RESTORE job, then the incremental update
database files contain information based on the unit database
state prior to the RESTORE. Since the unit database contents
have changed, the "today to-date" files in the incremental
update database are invalid. Execute the IUDBINIT
operational job to re-initialize the incremental update
database files and position your unit database for correctly
recovering the data processed since the last backup was
taken.
If CA MICS Accounting and Chargeback is installed in the unit
database, you will need to run the ACTDAY1R job after
completing RESTORE processing. See the CA MICS Accounting
and Chargeback User Guide for special considerations relating
to accounting files.
After RESTORE completes, and after you have run the IUDBINIT
and/or ACTDAY1R jobs (if required), rerun ALL database update
processing performed since the backup was taken.
RESTORING THE DATABASE
Use the Operational Status and Tracking RESTORE command. You
can select the current daily backup generation, another daily
backup generation, or a monthly backup.
You can manually restore the Database using the job in
prefix.MICS.CNTL(RESTORE). RESTORE defaults to the current
(0) daily backup generation. You can restore from another
backup generation or monthly backup by changing RESTORE job
symbolic parameters. DO NOT SAVE THE MODIFIED RESTORE JCL.
The RESTORE parameters are:
o DSNPREF - Backup prefix. Defaults to daily backup DSN.
o GDG - Backup cycle. Defaults to 0 (current).
The RESTORE job prints a copy of the checkpoint file for the
online database and the checkpoint file for the tape backup
database before beginning the restore process. This serves
two purposes. First, it allows comparison of the state of
the database at the time it was damaged with the backup
version used in the RESTORE. Second, it ensures that the
backup tape does indeed exist and that at least one file of
it can be read. If the backup checkpoint file cannot be
printed, the RESTORE job will stop and the damaged database
will not be deleted.
If you specified RESTORE BACKUP YES in
prefix.MICS.PARMS(JCLDEF), the RESTORE job attempts to
execute a database BACKUP before the RESTORE. If the
RESTORE job fails because the BACKUP is unsuccessful, the
RESTORE can be completed by
o replying NO to the Operational Status and Tracking
RESTORE command pre-restore backup prompt
or
o manually restarting the RESTORE job in the RSTR900
step
The data sets produced by the pre-restore backup are written
to the same generation data groups that are used for normal
backups, but are not catalogued. This means that if the
RESTORE job fails, you must ensure that the tapes are kept
and catalogued before they are scratched. If the restore is
successful, then you may elect to let the tapes be scratched
so that they will not affect the normal sequence of your
CA MICS backup generations.
DEPENDENCIES
If the RESTORE job malfunctions, no other update functions
will be able to execute. The RESTORE job must successfully
complete before other functions can start.
The RESTORE job is allowed to execute even if any of the
latest DAILY, WEEKLY, MONTHLY, YEARLY, or BACKUP jobs failed.
In this case, recognize that any processing that may have
taken place since the date of the backup that is being
restored will have to be repeated again.
Remember that the RESTORE job does not touch the incremental
update database files. If any INCRccc jobs have run in this
unit for the current day's data, you will need to run the
IUDBINIT job to re-initialize the incremental update database
files.
