rollforwarddb Command--Recover a Database
Permission required: DBA or a system administrator running rollforwarddb with the –u flag. On VMS, if using this command against a database in a group level installation, you must have the VMS CMKRNL privilege.
The rollforwarddb command recovers a database or table from the last checkpoint and the current journal and dump files. When executing table level recovery, you can optionally move the table to a new location.
If the target checkpoint was performed online (while the database was in use), then rollforwarddb does the following:
1. Restores the database from the checkpoint location to the database location
2. Applies the log records in the dump location to the database, which returns the database to its state when the checkpoint began
3. Applies the journal records to the database
If the target checkpoint was executed offline, then the second step is omitted.
By default, rollforwarddb sequentially restores data locations one at a time. A database with more than one data location can be restored in parallel.
For detailed procedures on performing backup and recovery of the database, see the Database Administrator Guide.
The rollforwarddb command has the following format:
rollforwarddb dbname[/server_class] [+c|-c] [#c[n]] [+j|-j]
[-mdevice{, device}] [-uusername] [#m[n]] [-v] [+w|-w]
[-bdd-mmm-yyyy:hh:mm:ss[.cc]] [-edd-mmm-yyyy:hh:mm:ss[.cc]]
[-incremental_start] [‑incremental_continue] [‑incremental_finish]
[-table=tablename{, tablename} [-nosecondary_index]
[#f] [-statistics] [-ignore] [-on_error_continue] [-on_error_prompt]
[-relocate -location=locationname {, locationname}
-new_location=locationname{, locationname}]]
[-dmf_cache_size= x] [-dmf_cache_size_4k|8k|16k|32k|64k= x] [-help]
[-mdevice{, device}] [-uusername] [#m[n]] [-v] [+w|-w]
[-bdd-mmm-yyyy:hh:mm:ss[.cc]] [-edd-mmm-yyyy:hh:mm:ss[.cc]]
[-incremental_start] [‑incremental_continue] [‑incremental_finish]
[-table=tablename{, tablename} [-nosecondary_index]
[#f] [-statistics] [-ignore] [-on_error_continue] [-on_error_prompt]
[-relocate -location=locationname {, locationname}
-new_location=locationname{, locationname}]]
[-dmf_cache_size= x] [-dmf_cache_size_4k|8k|16k|32k|64k= x] [-help]
dbname
Identifies the database (one database name only) to be recovered, and if required, the server_class, as described in Standard Flags and Parameters on page 14.
+c|-c
Recovers (+c) or does not recover (-c) the database from the checkpoint file. The default is +c.
#c[n]
Recovers from an older checkpoint. The checkpoint number n must be a valid checkpoint number (as shown by the infodb command). This flag can be used to recover the database when the current checkpoint is unfinished. If n is omitted, the most recent usable finished checkpoint is used for the recovery.
UNIX: In bash shell, place this option in quotes; otherwise characters after the # are treated as a comment. For example:
rollforwarddb empdata "#c1" 
For more information, including limitations and cautions, see Recover a Database from an Old Checkpoint in the Database Administrator Guide.
+j|-j
Recovers (+j) or does not recover (-j) the database from the journal. The default is +j.
-mdevice {, device}
Recovers the checkpoint from the specified tape device. If a list of tape devices is supplied, parallel recovery will be used for a multi-location database.
If the database was checkpointed to a tape, you can use the –m flag to restore the database from the tape.
VMS: Before executing rollforwarddb from a tape device, the tape must be inserted into the tape drive.
-uusername
Specifies the effective user for the session, as described in Standard Flags and Parameters on page 14.
#m[n]
Recovers n locations at a time from disk, for a multi-location database.
UNIX: In bash shell, place this option in quotes; otherwise characters after the # are treated as a comment.
-v
Recovers the database from the journal in verbose mode, which provides diagnostic information about all operations executed during the recovery process.
+w|-w
Waits (+w) or does not wait (-w) for the database to be free (not in use). The default is -w.
VMS: The +w|-w flag directs rollforwarddb to wait (+w) or not wait (-w) for the database to be free before recovering the database. Since rollforwarddb requires the database to be locked, this flag allows you to decide whether to wait for the database to be free if it is in use. If you specify +w, rollforwarddb will wait as long as necessary for the database to become free for locking and recovery. If you specify –w, an error is returned if the database is busy. The default is –w.
This flag can be used only in interactive sessions and not in batch mode.
-bdd-mmm-yyyy[:hh:mm:ss[.cc]]
Recovers transactions that were completed after the specified date and time only. Fractional seconds are optional and assumed to be ".00" if not specified.
-edd-mmm-yyyy[:hh:mm:ss[.cc]]
Recovers transactions that were completed before the specified date and time only. Fractional seconds are optional and assumed to be ".00" if not specified.
Note: The -e and -b flags are fully supported when used against an entire database.
Note: If the database has X100 tables, then using the -e option can only restore to a time associated with an archive cycle last commit ID. The frequency of archive cycles can be configured with the Recovery Server configuration parameter acp_timer in config.dat.
Caution! Using the -b or -e options with the -table flag will result in the table being logically inconsistent. Using these parameters to skip recovery of a segment of the journal file is not supported.
‑incremental_start
Starts the incremental rollforwarddb.
When –incremental_start +c -j is specified, the checkpoint is restored and rollforwarddb marks the database INCONSISTENT with inconsistency code INCR_RFP. While the database is inconsistent (INCR_RFP), you can still connect and perform read only operations.
Note: Incremental rollforward is not supported for a database that includes X100 tables.
‑incremental_continue
Discovers and applies new journals.
When –incremental_continue –c + j is specified, rollfowarddb applies all new journals that have been moved into the checkpoint directory, such that no transactions are left open.
‑incremental_finish
Finishes the incremental rollforwarddb and marks the database updatable.
When –incremental_finish –c +j is specified, rollforwarddb applies all new journals, rolls back any open transactions and marks the database updatable.
Note: Incremental rollforwarddb requires that all journals since the last checkpoint be present. For example, if you apply a batch of journal files, and then delete the previous batch of journal files, rollforwarddb ‑incremental_finish may fail.
-incremental
Note: This option is deprecated. Instead, use options –incremental_start, -incremental_continue and –incremental_finish.
Indicates an incremental rollforwarddb.
When -incremental +c -j is specified, the checkpoint is restored and rollforwarddb marks the database INCONSISTENT with inconsistency code INCR_RFP. While the database is inconsistent (INCR_RFP), you can still connect and perform read only operations.
When -incremental -c +j is specified:
• Rollfowarddb applies all new journal files that have been moved into the journal directory.
• If -norollback has also been specified, any open transaction context is written at the end of the last journal file processed.
• Before processing new journals, open transaction context is restored from the previous incremental roll forward.
If -rollback is specified, after journal processing has finished, any open transactions are rolled back. The database will be marked consistent and updatable. This option should be specified when you have finished the incremental rollforwarddb.
Note: Incremental rollforwarddb requires that all journals since the last checkpoint be present. For example, if you apply a batch of journal files, and then delete the previous batch of journal files, rollforwarddb ‑incremental ‑rollback may fail.
Note: Incremental rollforward is not supported for a database that contains X100 tables.
-norollback
Note: This option is deprecated. Instead, use options –incremental_start, -incremental_continue and –incremental_finish.
Bypasses the rollback phase of rollforward and leaves the database in the exact state described by the journal files. If used with the -e flag, then the database is left in the state described by the journal files up to the time specified. Any incomplete transactions are left incomplete. If transactions are left incomplete, the database will be in an inconsistent state after the rollforwarddb.
Note: The default is -rollback, which does not need to be explicitly specified.
-table=tablename{, tablename}
Specifies a list of tables to be recovered from the target checkpoint. If multiple tables are specified, no space is allowed between the tables listed. Table recovery is not allowed for views, system catalogs, or Enterprise Access tables.
If recovering a base table, blob columns (long byte and long varchar columns) will be recovered, and secondary indexes will be recovered, unless –nosecondary_index is specified.
-nosecondary_index
Inhibits automatic recovery of secondary indexes.
Note: All secondary indexes will be marked inconsistent. The base table cannot be accessed until the secondary indexes are rebuilt or dropped.
This option is invalid for database level recovery.
#f
Forces journaling enablement, if rollforwarddb with journaling is attempted on a database that has journaling disabled.
UNIX: In bash shell, place this option in quotes; otherwise characters after the # are treated as a comment.
-statistics
Prints statistics about the rollforwarddb operation.
-ignore
Ignores any errors that occur during the processing of journal records, and applies subsequent records for the table. The table will be marked inconsistent at the end of rollforwarddb. The database will also be marked inconsistent to bring to your attention the errors that occurred during rollforwarddb. Choose this action when the table cannot be rebuilt from another source and you want to try to recover as much data as possible.
-on_error_continue
Continues processing journal records if an error occurs, but does not apply subsequent records for the table. The table is removed from the table list and processing continues. The table or index will be marked inconsistent at the end of rollforwarddb. The database will also be marked inconsistent to bring to your attention the errors that occurred during rollforwarddb. Choose this action for secondary indexes (which can be rebuilt) or if the table can be rebuilt from another source.
If this option is not specified and an error is encountered, all tables being recovered are marked inconsistent and rollforwarddb terminates.
Note: This option does not force continuation of an invalid rollforwarddb command. The rollforwarddb process is terminated immediately if an invalid table—for example, a view, system catalog, Enterprise Access table, nonexistent table, or a table for which recovery is disallowed—is specified.
This option is invalid for database level recovery.
-on_error_prompt
Prompts “Error during recovery of table (tablename, tableowner)” if an error occurs when applying dump or journal records. The on_error_prompt option provides the ability to handle errors for various tables differently.
You can respond with one of these actions:
CONTINUE_IGNORE_TABLE
Continues journal processing, but ignores subsequent journal records for this table or index. This action is equivalent to the on_error_continue flag.
CONTINUE_IGNORE_ERROR
Continues journal processing and applies subsequent records for this table. This action is equivalent to the –ignore flag.
ROLLBACK_TRANSACTIONS
(Default) Stops processing the journals and rolls back open transactions. The database is left at a consistent state, but not all updates have been reapplied and the database is inconsistent with the journals.
-relocate
Indicates that a table is to be relocated to a new location during recovery. When using this option, –location and –new_location must also be specified.
This option is invalid for database-level recovery.
-location=locationname{, locationname}
Specifies a data location or list of locations (locationname).
When –relocate and –new_location are also specified, the data in each area in the location list is moved to the corresponding area in the new location list. Only tables being recovered are relocated.
This option is invalid for database level recovery.
-new_location=locationname{, locationname}
Specifies a new data location or list of new data locations (locationname).
When ‑relocate and ‑location are also specified, the data in each area in the location list is moved to the corresponding area in the new location list. Only tables being recovered are relocated.
When this option is specified, –relocate and ‑location must also be specified, and the number of locations in the location list must equal the number of locations in the new location list. (The number of location names associated with a table cannot be changed using rollforwarddb.)
This option is invalid for database level recovery.
[‑dmf_cache_size= x] [‑dmf_cache_size_4k|8k|16k|32k|64k= x]
Specifies the size of the local cache that rollforwarddb allocates, in number of buffers.
Default values are:
-dmf_cache_size=256, which indicates 256 2 KB buffers.
-dmf_cache_size_xk=200, where x is the buffer size indicated in the keyword. For example, ‑dmf_cache_size_64k=200 indicates 200 64 KB buffers.
If you specify 0 for the 4k, 8k, 16k, 32k, or 64k buffers, 256 buffers are allocated.
-help
Displays command syntax online.
Last modified date: 01/30/2023