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

Section under construction...

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

7.4.1 Overview of Backup Procedures

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

• Place the directories and files associated with your VDE 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 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 your VDE database in a journal file. If you later must restore your database from a backup, you can use the journal file to "roll" the restored database forward until it contains all changes that your lost database had just before the failure.
• Edit the database backup and restore procedures that come with the VDE kit to make them refer to your VDE library. Place these procedures in a backup directory associated with your VDE library. Configure the site-specific backup procedure to execute periodically.
• Make sure that someone performs regular backups of all files in your VDE library using the OpenVMS BACKUP utility. These backup are normally written to tape and backup tapes should periodically be moved to fire storage. If your system manager or operations staff performs this function for you, you need only ensure 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 synchronization problems that are likely when attempting to use OpenVMS BACKUP utility to perform backups of Rdb database files such as those used by VDE.
• 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 is appropriate when your VDE library requires high availability and when the cost of an unavailable library is high. Using disk shadowing doubles the number of disks you need.

The sections that follow describe how you perform these steps. They also describe how you restore your VDE database and other files in your VDE library in case of a failure. However, this manual does not further describe how to use the OpenVMS BACKUP utility to back up files and directory trees. Neither does it describe 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...

7.4.3 After-Image Journalling

Section under construction...

7.4.4 Creating the Database Backup Procedure

Section under destruction...

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

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

The RMU utility, a component of the Rdb product, ensures that 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 snapshot of the database as it is synchronized with any database transactions that might potentially be active. The RMU utility is also be used to back up and maintain the Rdb after-image journal files. These journal files allow Rdb to recover database transactions performed after the last backup operation.

The VDE kit contains a command procedure that you can modify to back up the Rdb database for your VDE library. This 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...

7.4.6 Backing up the VDE Database

Section under destruction...

To back up your VDE database, you must first set up a database backup procedure as described in Section 7.4.4. In the present section, we will assume that this procedure is called VDE_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 subdirectories [PROJ.BACKUP], [PROJ.BACKUP_OLD], and [PROJ.AIJ] as outlined in Section 7.4.2.

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

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

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

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

The backup procedure performs the following steps for a full backup. It deletes all files in the JNLDEV$:[PROJ.OLD_BACKUP] directory and then renames all files in the JNLDEV$:[PROJ.BACKUP] directory to the OLD_BACKUP directory. The previous backup files are thus preserved in the OLD_BACKUP directory so they cannot be lost in case the current backup 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 VDE database while it is being backed up. Finally, the active after-image journal file is backed up to the BACKUP directory under the name VDE$DATABASE_FULL.AIJ, after which the active journal file is set to be empty. After all this is done, the BACKUP directory, along with the active journal file in directory JNLDEV$:[PROJ.AIJ], contains all files needed to fully recover the VDE database.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The database backup operations must produce backup and journal files on a disk (JNLDEV$: in these examples) different from the disk or disks containing the VDE library and the VDE database. Because 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.

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

$ @JNLDEV$:[PROJ.TOOL]VDE_DATABASE_BACKUP FULL_NOVERIFY The backup operation will be performed using the following device and directory specifications: The location of the database to back up is LIBDEV$:[PROJROOT] The database will be backed up to JNLDEV$:[PROJ.BACKUP] Existing backup files on JNLDEV$:[PROJ.BACKUP] will be renamed to JNLDEV$:[PROJ.BACKUP_OLD] before the backup starts The definition of VDE$JOURNAL is JNLDEV$:[PROJ.AIJ] Do you want to continue with the database backup? (Y or N) : Y Full backup of database without verification being performed. Renaming database files from the backup area JNLDEV$:[PROJ.BACKUP] to JNLDEV$:[PROJ.BACKUP_OLD] Full database backup starting for LIBDEV$:[PROJROOT]VDE$DATABASE.RDB Backing database up to JNLDEV$:[PROJ.BACKUP]VDE$DATABASE_FULL.RBF %RMU-I-QUIETPT, waiting for database quiet point %RMU-I-BCKTXT_01, Thread 1 uses devices LIBDEV$: %RMU-I-BCKTXT_08, Thread 1 was assigned file LIBDEV$:[PROJROOT]VDE$DATABASE.RDA;1 %RMU-I-BCKTXT_00, Backed up root file LIBDEV$:[PROJROOT]VDE$DATABASE.RDB;1 %RMU-I-BCKTXT_02, Full backup of storage area LIBDEV$:[PROJROOT]VDE$DATABASE.RDA;1 %RMU-I-BCKTXT_02, Full backup of storage area LIBDEV$:[PROJROOT]VDE$DATABASE.RDA;1 %RMU-I-BCKTXT_04, ignored 2 space management pages %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 Backup of journal file starting for LIBDEV$:[PROJROOT]VDE$DATABASE.RDB Backing journal file up to JNLDEV$:[PROJ.BACKUP]VDE$DATABASE_FULL.AIJ %RMU-I-LOGCREBCK, created backup file JNLDEV$:[PROJ.BACKUP]VDE$DATABASE_FULL.AIJ;1 %RMU-I-LOGBCKAIJ, backing up AIJ file JNLDEV$:[PROJ.AIJ]VDE$DATABASE.AIJ;1 %RMU-I-LOGAIJBCK, backed up 2 committed transactions at 11:14:14.93 Backup of journal file completed

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 transactions since the last backup is found in the JNLDEV$:[PROJ.AIJ] directory. The present section also assumes that you have set up the command procedure VDE_DATABASE_RESTORE.COM in directory JNLDEV$:[PROJ.TOOL] as described in Section 7.4.5. Given that, you can restore the VDE database and recover all journalled transactions by entering the following DCL command:

$ @JNLDEV$:[PROJ.TOOL]VDE_DATABASE_RESTORE

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

If this procedure cannot restore the database, you should determine why. If the reason is that the BACKUP directory is not correctly set up, you may have to restore the BACKUP directory from the OLD_BACKUP directory or from a backup tape. If you do so, you must be sure that you do not lose any after-image journal files. You need all journal files used to log transactions since the backup files you are using were created and these journal files must be applied to the database in order by date to avoid loss of transactions. After setting up the BACKUP directory, you should be able to rerun the command procedure. If all 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.

By default, the VDE_DATABASE_RESTORE procedure displays the inputs and outputs of the restore operation and asks you to confirm that those are the right inputs and outputs. You must then answer YES if you want the restore 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: The location of the backup area to restore from is JNLDEV$:[PROJ.BACKUP] The database root file will be restored to LIBDEV$:[PROJROOT] The database storage area file will be restored to LIBDEV$:[PROJROOT] The database snapshot file will be restored to LIBDEV$:[PROJROOT] The definition of VDE$JOURNAL is JNLDEV$:[PROJ.AIJ] The current version of the database is undefined. 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

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

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

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

The 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: The location of the backup area to restore from is JNLDEV$:[PROJ.BACKUP] The database root file will be restored to LIBDEV$:[PROJROOT] The database storage area file will be restored to LIBDEV$:[PROJROOT] The database snapshot file will be restored to LIBDEV$:[PROJROOT] The definition of VDE$JOURNAL is JNLDEV$:[PROJ.AIJ] The current version of the database is undefined. 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 Deleting database header files in LIBDEV$:[PROJROOT] Deleting database storage area files in LIBDEV$:[PROJROOT] Deleting database snapshot files in LIBDEV$:[PROJROOT] Deleting database after image journal files in JNLDEV$:[PROJ.AIJ] Full restore starting for JNLDEV$:[PROJ.BACKUP]VDE$DATABASE_FULL.RBF root file LIBDEV$:[PROJROOT]VDE$DATABASE.RDB storage file LIBDEV$:[PROJROOT]VDE$DATABASE.RDA snapshot file LIBDEV$:[PROJROOT]VDE$DATABASE.SNP %RMU-I-RESTXT_04, Thread 1 uses devices LIBDEV$: %RMU-I-RESTXT_00, Restored root file LIBDEV$:[PROJROOT]VDE$DATABASE.RDB;1 %RMU-I-LOGRESSST, restored storage area LIBDEV$:[PROJROOT]VDE$DATABASE.RDA;1 %RMU-I-LOGRESSST, restored storage area LIBDEV$:[PROJROOT]VDE$DATABASE.RDA;1 %RMU-I-RESTXT_05, rebuilt 2 space management pages %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 pages %RMU-I-RESTXT_01, Initialized snapshot file LIBDEV$:[PROJROOT]VDE$DATABASE.SNP;1 %RMU-I-LOGINIFIL, contains 1000 pages, each page is 2 blocks long Full restore completed Recover starting for LIBDEV$:[PROJROOT]VDE$DATABASE.RDB using JNLDEV$:[PROJ.BACKUP]VDE$DATABASE_FULL.AIJ %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

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

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

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

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

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

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

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

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

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