I
1. Invoke the RdbAlter utility from a suitably G privileged username, specifying the name of the target database file.J
2. Display all "users", numbered from E 0 to n, and display any RUJ files that Rdb believes are needed for  recovery.J
3. Specify the user number with the missing RUJ F file in the # position. No spaces or characters should be specified  between the double-quotes.I
4. COMMIT the transaction. The database is J now accessable, but is likely corrupt. Recovery from Rdb BACKUP is preferable.I
5. Unload the contents of the database, verify  the contents, and re-import.K
6. Use a minimum of RMU/VERIFY/ALL to verify the J data structures of the reloaded database. Even with proper verification D of the structures, the information in the database may be corrupt.

&Section under construction...

;After establishing your VDE library, you should set up the Fbackup and recovery procedures that allow you to recover the contents 8of your VDE library in case the library is destroyed or =damaged. A disk failure, for example, could destroy your VDE Edatabase or any of the associated delta files (CMS libraries). To be Hable to recover from such failures, you must establish several separate ;backup procedures. This section describes those procedures.Q

7.4.1 Overview of Backup Procedures

:To establish the necessary backup procedures for your VDE 0library, you need to take the following actions:

?
• Place the directories and files associated with your VDE H library on two or more disks. In order to recover from the failure of > any one disk, you must have VDE backup and journal files on E a different disk than the disk or disks that hold the rest of your  VDE library.<
• Enable after-image journalling for your VDE database. > After-image journalling causes Rdb to record all changes to 9 your VDE database in a journal file. If you later must G restore your database from a backup, you can use the journal file to G "roll" the restored database forward until it contains all > changes that your lost database had just before the failure.I
• Edit the database backup and restore procedures that come with the 2 VDE kit to make them refer to your VDE library. D Place these procedures in a backup directory associated with your ? VDE library. Configure the site-specific backup procedure to  execute periodically.F
• Make sure that someone performs regular backups of all files in 5 your VDE library using the OpenVMS BACKUP utility. D These backup are normally written to tape and backup tapes should C periodically be moved to fire storage. If your system manager or H operations staff performs this function for you, you need only ensure G that the appropriate staff knows to back up the disks that hold your ? VDE library. Otherwise, you may have to perform such backups | yourself.
  See Section 7.4.4 for information specific to the B synchronization problems that are likely when attempting to use 3 OpenVMS BACKUP utility to perform backups of Rdb + database files such as those used by VDE.I
• For additional protection against disk or other hardware failures, @ you can consider using OpenVMS shadow sets for the disks that = hold your VDE library and its backup files. Disk shadowing 5 is appropriate when your VDE library requires high J availability and when the cost of an unavailable library is high. Using 6 disk shadowing doubles the number of disks you need.

DThe sections that follow describe how you perform these steps. They :also describe how you restore your VDE database and other 9files in your VDE library in case of a failure. However, =this manual does not further describe how to use the OpenVMS EBACKUP utility to back up files and directory trees. Neither does it Gdescribe how to set up disk shadowing. For a full description of these >topics, see the appropriate OpenVMS documentation or see your system manager.]

7.4.2 Placement of Backup Files and Directories

&Section under construction...I

7.4.3 After-Image Journalling

&Section under construction...\

7.4.4 Creating the Database Backup Procedure

%Section under destruction...



4The database for your VDE library is an Oracle Rdb7 5database. (Rdb is a relational database package.) An :Rdb database must be backed up periodically using the RMU Kutility described in the Oracle Rdb7 RMU Reference Manual and the 3Oracle Rdb7 Guide to Database Maintenance.

>The OpenVMS BACKUP command can potentially take a snapshot of Gyour database as it looks in the middle of an update transaction. This <results in an invalid backup file because Rdb must preserve Htransaction semantics, meaning that an update transaction must complete fully or not at all.

9The RMU utility, a component of the Rdb product, ensures Bthat the backed-up database is internally consistent and observes ?transaction semantics, which the OpenVMS BACKUP utility cannot >do. Unlike OpenVMS BACKUP, the RMU utility takes a consistent Asnapshot of the database as it is synchronized with any database Gtransactions that might potentially be active. The RMU utility is also <be used to back up and maintain the Rdb after-image journal 9files. These journal files allow Rdb to recover database 7transactions performed after the last backup operation.

=The VDE kit contains a command procedure that you can modify 2to back up the Rdb database for your VDE library. CThis command procedure performs the appropriate RMU operations. To ;create the database backup procedure for your VDE library, perform the following step:

,
• Section under construction...,
• Section under construction...

&Section under construction...]

7.4.5 Creating the Database Restore Procedure

&Section under construction...P

7.4.6 Backing up the VDE Database

%Section under destruction...

6To back up your VDE database, you must first set up a zdatabase backup procedure as described in Section 7.4.4. In the >present section, we will assume that this procedure is called FVDE_DATABASE_BACKUP.COM and is found in directory JNLDEV$:[PROJ.TOOL] }as suggested in Section 7.4.2. We will also assume that disk JNLDEV$ ;is your journal and backup device and that you have set up Csubdirectories [PROJ.BACKUP], [PROJ.BACKUP_OLD], and [PROJ.AIJ] as Routlined in Section 7.4.2.

COnce your database backup procedure is in place, you can run it to Fperform full backups with database verification, full backups without Fdatabase verification, or incremental database backups. A full backup Gsaves all database information in a backup file. An incremental backup Dsaves all database information that has changed since the last full Gbackup in an incremental backup file. Database verification causes the 7RMU utility to check the internal structure of the Rdb &database for consistency and validity.

HTo perform a full database backup without verification, you invoke your +edited backup command procedure as follows:

 

" 7$ @JNLDEV$:[PROJ.TOOL]VDE_DATABASE_BACKUP FULL_NOVERIFY 

FThis invocation of the procedure performs a full backup of the source =control database. It does not attempt to verify the database.

HThe backup procedure performs the following steps for a full backup. It Fdeletes all files in the JNLDEV$:[PROJ.OLD_BACKUP] directory and then @renames all files in the JNLDEV$:[PROJ.BACKUP] directory to the FOLD_BACKUP directory. The previous backup files are thus preserved in Dthe OLD_BACKUP directory so they cannot be lost in case the current Ebackup operation fails. Next, the RMU/BACKUP command performs a full /database backup, producing the Rdb backup file ?VDE$DATABASE_FULL.RBF in the BACKUP directory. An "online ;backup" is used, meaning that other users can use the 7VDE database while it is being backed up. Finally, the Eactive after-image journal file is backed up to the BACKUP directory Eunder the name VDE$DATABASE_FULL.AIJ, after which the active journal Gfile is set to be empty. After all this is done, the BACKUP directory, Dalong with the active journal file in directory JNLDEV$:[PROJ.AIJ], <contains all files needed to fully recover the VDE database.

BIf you want to perform a full backup and also verify the database G(using the RMU/VERIFY command), invoke the backup procedure as follows:

 

" .$ @JNLDEV$:[PROJ.TOOL]VDE_DATABASE_BACKUP FULL 

CFor a large database, verification can be very time-consuming. You Eshould nevertheless verify the database periodically, such as weekly.

CIf you omit the FULL parameter on the command line, you get a FULL database backup by default.

HAn incremental backup saves all changes to your database since the last Efull backup in an incremental backup file. To perform an incremental 4backup of the database, enter the following command:

 

" 5$ @JNLDEV$:[PROJ.TOOL]VDE_DATABASE_BACKUP INCREMENTAL 

GFor an incremental backup, the backup procedure invokes RMU to perform Fan online incremental backup of the database. The output file is file FVDE$DATABASE_INCR.RBF in the BACKUP directory. This file contains all Cchanges since the last full backup. An incremental backup normally Htakes substantially less time than a full backup. How much less depends Fon how much your database has been changed since the last full backup.

FBy default, the VDE_DATABASE_BACKUP procedure displays the inputs and Goutputs of the backup operation and asks you to confirm that those are Gthe right inputs and outputs. You must then answer YES if you want the 0backup operation to proceed. This is an example:

 

" 7$ @JNLDEV$:[PROJ.TOOL]VDE_DATABASE_BACKUP FULL_NOVERIFY> The backup operation will be performed using the following( device and directory specifications: A The location of the database to back up is LIBDEV$:[PROJROOT]; The database will be backed up to JNLDEV$:[PROJ.BACKUP]B Existing backup files on JNLDEV$:[PROJ.BACKUP] will be renamed= to JNLDEV$:[PROJ.BACKUP_OLD] before the backup starts7 The definition of VDE$JOURNAL is JNLDEV$:[PROJ.AIJ] >Do you want to continue with the database backup? (Y or N) : Y 

BTo suppress the request for confirmation, you can add the keyword CNOQUERY to the end of the command line invoking the procedure. For example:

 

" 6$ @JNLDEV$:[PROJ.TOOL]VDE_DATABASE_BACKUP FULL NOQUERY 

FYou always need the NOQUERY keyword when you run the backup procedure in a batch job.

GBecause database backups should be performed regularly, the normal way Gto perform them is to submit a command procedure that runs every night Gto perform a full backup once a week and incremental backups the other Anights. To start this command procedure, enter the following DCL command:

 

" 8$ SUBMIT /LOG=JNLDEV$:[PROJ.LOG]NIGHTLY_VDE_BACKUP.LOG -6_$ /NOPRINT/KEEP/RESTART/AFTER="TOMORROW+1:00" -2_$ JNLDEV$:[PROJ.TOOL]NIGHTLY_VDE_BACKUP.COM 

FThis command procedure resubmits itself each time it runs. You should Htherefore not need to restart it manually unless batch queues have been Blost due to a system failure. In this example, the SUBMIT command Dcauses the procedure to run at 1:00 am the following night. That is Falso the time that the procedure restarts itself on subsequent nights.

HThe database backup operations must produce backup and journal files on Ea disk (JNLDEV$: in these examples) different from the disk or disks 1containing the VDE library and the VDE database. EBecause the backup files are on disk, they are immediately available =for restoring the VDE database after a failure. However, the @backup disk must itself be backed up to tape (using the OpenVMS #BACKUP utility) on a regular basis.

HThe following example illustrates the output that you will get when you back up your database:

 

" 7$ @JNLDEV$:[PROJ.TOOL]VDE_DATABASE_BACKUP FULL_NOVERIFY> The backup operation will be performed using the following( device and directory specifications: A The location of the database to back up is LIBDEV$:[PROJROOT]; The database will be backed up to JNLDEV$:[PROJ.BACKUP]B Existing backup files on JNLDEV$:[PROJ.BACKUP] will be renamed= to JNLDEV$:[PROJ.BACKUP_OLD] before the backup starts7 The definition of VDE$JOURNAL is JNLDEV$:[PROJ.AIJ] >Do you want to continue with the database backup? (Y or N) : Y A Full backup of database without verification being performed. F Renaming database files from the backup area JNLDEV$:[PROJ.BACKUP]' to JNLDEV$:[PROJ.BACKUP_OLD] H Full database backup starting for LIBDEV$:[PROJROOT]VDE$DATABASE.RDBI Backing database up to JNLDEV$:[PROJ.BACKUP]VDE$DATABASE_FULL.RBF 0%RMU-I-QUIETPT, waiting for database quiet point0%RMU-I-BCKTXT_01, Thread 1 uses devices LIBDEV$:Q%RMU-I-BCKTXT_08, Thread 1 was assigned file LIBDEV$:[PROJROOT]VDE$DATABASE.RDA;1J%RMU-I-BCKTXT_00, Backed up root file LIBDEV$:[PROJROOT]VDE$DATABASE.RDB;1R%RMU-I-BCKTXT_02, Full backup of storage area LIBDEV$:[PROJROOT]VDE$DATABASE.RDA;1R%RMU-I-BCKTXT_02, Full backup of storage area LIBDEV$:[PROJROOT]VDE$DATABASE.RDA;16%RMU-I-BCKTXT_04, ignored 2 space management pages2%RMU-I-BCKTXT_05, backed up 10 inventory pages=%RMU-I-BCKTXT_06, backed up 520 logical area bitmap pages/%RMU-I-BCKTXT_07, backed up 1270 data pages " Full database backup completed J Backup of journal file starting for LIBDEV$:[PROJROOT]VDE$DATABASE.RDBM Backing journal file up to JNLDEV$:[PROJ.BACKUP]VDE$DATABASE_FULL.AIJ &%RMU-I-LOGCREBCK, created backup file D JNLDEV$:[PROJ.BACKUP]VDE$DATABASE_FULL.AIJ;1&%RMU-I-LOGBCKAIJ, backing up AIJ file < JNLDEV$:[PROJ.AIJ]VDE$DATABASE.AIJ;1C%RMU-I-LOGAIJBCK, backed up 2 committed transactions at 11:14:14.93 $ Backup of journal file completed  

P

7.4.7 Restoring the VDE Database

=If a failure has corrupted or damaged your VDE database, you :must restore the database before your VDE library becomes }usable again. As described in Section 7.4.2, the backup files needed ?to restore the database are found in the JNLDEV$:[PROJ.BACKUP] <directory and the after-image journal file that records all Ftransactions since the last backup is found in the JNLDEV$:[PROJ.AIJ] Edirectory. The present section also assumes that you have set up the 8command procedure VDE_DATABASE_RESTORE.COM in directory üJNLDEV$:[PROJ.TOOL] as described in Section 7.4.5. Given that, you can 4restore the VDE database and recover all journalled 3transactions by entering the following DCL command:

 

" *$ @JNLDEV$:[PROJ.TOOL]VDE_DATABASE_RESTORE 

AThis command procedure runs the RMU utility to first restore the 0VDE database and to then recover all journalled Dtransactions. After this procedure has run, you should have a fully <functional and completely up-to-date VDE database. You must 9have the OpenVMS SYSPRV privilege to perform these steps.

DIf this procedure cannot restore the database, you should determine Ewhy. If the reason is that the BACKUP directory is not correctly set Eup, you may have to restore the BACKUP directory from the OLD_BACKUP Edirectory or from a backup tape. If you do so, you must be sure that Dyou do not lose any after-image journal files. You need all journal Dfiles used to log transactions since the backup files you are using Hwere created and these journal files must be applied to the database in Border by date to avoid loss of transactions. After setting up the HBACKUP directory, you should be able to rerun the command procedure. If Call else fails, you may have to restore the database using the RMU @utility directly. See the VAX Rdb/VMS RDO and RMU Reference =Manual for detailed descriptions of the RMU/RESTORE and RMU/RECOVER commands.

GBy default, the VDE_DATABASE_RESTORE procedure displays the inputs and Houtputs of the restore operation and asks you to confirm that those are Gthe right inputs and outputs. You must then answer YES if you want the Erestore operation to proceed. This example illustrates this behavior:

 

" *$ @JNLDEV$:[PROJ.TOOL]VDE_DATABASE_RESTORE? The restore operation will be performed using the following( device and directory specifications: L The location of the backup area to restore from is JNLDEV$:[PROJ.BACKUP]A The database root file will be restored to LIBDEV$:[PROJROOT]I The database storage area file will be restored to LIBDEV$:[PROJROOT]E The database snapshot file will be restored to LIBDEV$:[PROJROOT]7 The definition of VDE$JOURNAL is JNLDEV$:[PROJ.AIJ]5 The current version of the database is undefined.6 An after image journal file will not be copied+ before the database restore begins. ?Do you want to continue with the database restore? (Y or N) : Y 

BTo suppress the request for confirmation, you can add the keyword CNOQUERY to the end of the command line invoking the procedure. For example:

 

" 2$ @JNLDEV$:[PROJ.TOOL]VDE_DATABASE_RESTORE NOQUERY 

GYou always need the NOQUERY keyword when you run the restore procedure in a batch job.

HThe following example illustrates the output that you will get when you restore your database:

 

" *$ @JNLDEV$:[PROJ.TOOL]VDE_DATABASE_RESTORE? The restore operation will be performed using the following( device and directory specifications: L The location of the backup area to restore from is JNLDEV$:[PROJ.BACKUP]A The database root file will be restored to LIBDEV$:[PROJROOT]I The database storage area file will be restored to LIBDEV$:[PROJROOT]E The database snapshot file will be restored to LIBDEV$:[PROJROOT]7 The definition of VDE$JOURNAL is JNLDEV$:[PROJ.AIJ]5 The current version of the database is undefined.6 An after image journal file will not be copied+ before the database restore begins. ?Do you want to continue with the database restore? (Y or N) : Y 8 Deleting database header files in LIBDEV$:[PROJROOT] > Deleting database storage area files in LIBDEV$:[PROJROOT] : Deleting database snapshot files in LIBDEV$:[PROJROOT] E Deleting database after image journal files in JNLDEV$:[PROJ.AIJ] H Full restore starting for JNLDEV$:[PROJ.BACKUP]VDE$DATABASE_FULL.RBF4 root file LIBDEV$:[PROJROOT]VDE$DATABASE.RDB7 storage file LIBDEV$:[PROJROOT]VDE$DATABASE.RDA8 snapshot file LIBDEV$:[PROJROOT]VDE$DATABASE.SNP 0%RMU-I-RESTXT_04, Thread 1 uses devices LIBDEV$:I%RMU-I-RESTXT_00, Restored root file LIBDEV$:[PROJROOT]VDE$DATABASE.RDB;1L%RMU-I-LOGRESSST, restored storage area LIBDEV$:[PROJROOT]VDE$DATABASE.RDA;1L%RMU-I-LOGRESSST, restored storage area LIBDEV$:[PROJROOT]VDE$DATABASE.RDA;16%RMU-I-RESTXT_05, rebuilt 2 space management pages1%RMU-I-RESTXT_06, restored 10 inventory pages;%RMU-I-RESTXT_07, rebuilt 520 logical area bitmap pages.%RMU-I-RESTXT_08, restored 1270 data pagesP%RMU-I-RESTXT_01, Initialized snapshot file LIBDEV$:[PROJROOT]VDE$DATABASE.SNP;1E%RMU-I-LOGINIFIL, contains 1000 pages, each page is 2 blocks long  Full restore completed : Recover starting for LIBDEV$:[PROJROOT]VDE$DATABASE.RDB8 using JNLDEV$:[PROJ.BACKUP]VDE$DATABASE_FULL.AIJ N%RMU-I-LOGRECDB, recovering database file LIBDEV$:[PROJROOT]VDE$DATABASE.RDB;1>%RMU-W-NOTRANAPP, no transactions in this journal were applied  Recover completed  

^

7.4.8 Recovering from a Lost Journal File

6If the after-image journal file for your VDE database Fbecomes unavailable due to a disk failure or other cause, nobody will =be able to use the database and VDE operations will fail. To Arecover from this condition, you must close, alter, back up, and Frestore the database. The following sequence of commands will perform the necessary operations:

 

" 3$ RMU/CLOSE/ABORT=DELPRC LIBDEV$:[PROJ]VDE$DATABASE&$ RMU/OPEN LIBDEV$:[PROJ]VDE$DATABASE&$ RMU/CLOSE LIBDEV$:[PROJ]VDE$DATABASE0$ ! RMU/ALTER for versions of Rdb before V6.0...&$ RMU/ALTER LIBDEV$:[PROJ]VDE$DATABASE+RdbALTER> DEPOSIT ROOT AIJ_FILENAME = ""RdbALTER> COMMITRdbALTER> EXIT-$ ! RMU/SET for Rdb version V6.0 and later...:$ RMU/SET AFTER_JOURNAL LIBDEV$:[PROJ]VDE$DATABASE/DISABLE$ ! 7$ @JNLDEV$:[PROJ.TOOL]VDE_DATABASE_BACKUP FULL_NOVERIFY*$ @JNLDEV$:[PROJ.TOOL]VDE_DATABASE_RESTORE 

EThe first RMU/CLOSE command closes the database; it deletes all user Gprocesses attached to the database and denies access to new users. Any Atransactions the deleted processes had in progress are lost. The CRMU/OPEN command rolls back any such transactions, thus making the Fdatabase consistent. The second RMU/CLOSE command closes the database Gso that new users cannot access it. The RMU/ALTER command prepares the Hdatabase to be altered. The DEPOSIT ROOT AIJ_FILENAME = "" command sets Gthe database root file to have after-image journaling turned off. This Hwill permit the database to be backed up. The COMMIT command causes the FDEPOSIT command to be committed. The EXIT command then exits from the RMU/ALTER utility.

CThe next command backs up the database (without verifying it since Gverification can be very time-consuming) and the last command restores Hthe database from the backup file. Restoring the database creates a new Dafter-image journal file, so it should only be done when the failed Ddisk is available again or a new disk is substituted. After this is .done, the database should be fully functional.

FYou must have the SYSPRV privilege to perform this recovery procedure.

FIf you want to place the after-image journal file on a different disk Ethan the original location, you need to specify the new journal file Eimmediately after performing the above recovery procedure. To do so, #use the VDE MODIFY LIBRARY command:

 

" /$ VDE MODIFY LIBRARY/JOURNAL=NEWDEV$:[PROJ.AIJ] 

BThis operation should be done before any operations are done that update the VDE database.

GNote that the after-image journal file becomes unavailable if the disk Eholding it runs out of space. To prevent this situation, the journal Bfile should be placed on a disk with ample space. However, if the Ejournal file still runs out of space, you should close, open, close, Fand alter the database as just described, and then delete the journal Ffile. After that, you can back up and restore the database to make it Efunctional again. The restore operation will create a new, initially empty journal file.