ROLLFORWARD DATABASE command
The ROLLFORWARD DATABASE command recovers a database by applying transactions that are recorded in the database log files. The ROLLFORWARD DATABASE command can be run after a database or a table space backup image was restored, or if any table spaces were taken offline by the database due to a media error.
Scope
In a partitioned database environment, this command can be started only from the catalog partition but each partition participates in the rollforward operation. A database or table space rollforward operation to a specified point in time affects all database partitions that are listed in the db2nodes.cfg file. A database or table space rollforward operation to the end of logs affects the database partitions that are specified. If no database partitions are specified, it affects all database partitions that are listed in the db2nodes.cfg file; if rollforward recovery is not needed on a particular partition, that partition is ignored.
In a Db2® pureScale® environment, this command can be issued from any member, and online table space-level rollforward operation can be completed while other members are online. Unlike in partitioned database environments in which users can choose to roll forward through a subset of the database partitions, in a Db2 pureScale environment the logs from all members are automatically applied.
If a rollforward operation is in progress on a member when it fails, the ROLLFORWARD command can be reissued from any member. The rollforward resumes from where it was left off when the original member failed.
For partitioned tables, you must also roll forward related table spaces to the same point in time. This requirement applies to table spaces that contain data partitions of a table. If a single table space contains a portion of a partitioned table, rolling forward to the end of the logs is still allowed.
It is not possible to roll forward through log files created on a different Db2 release version. This restriction is an important consideration when you are upgrading to a new Db2 database release version.
Authorization
- SYSADM
- SYSCTRL
- SYSMAINT
Required connection
None. This command establishes an exclusive database connection.
Command syntax
Command parameters
- DATABASE database-alias
- The alias of the database that is to be rollforward recovered.
- USER username
- The username under which the database is to be rollforward recovered.
- USING password
- The password used to authenticate the username. If the password is omitted, you are going to be prompted to enter it.
- TO
-
- isotime
- The point in time to which all committed transactions are to be rolled forward (including the
transaction committed precisely at that moment, as well as all transactions committed previously).
A rollforward operation to a point in time returns a success
message only if there exists a transaction with a larger timestamp value in the log files. Even if
there is no transaction with a larger timestamp, you can still issue a rollforward operation with
the COMPLETE option.
This value is specified as a timestamp, a 7-part character string that identifies a combined date and time. The format is
yyyy-mm-dd-hh.mm.ss
(year, month, day, hour, minutes, seconds), expressed in Coordinated Universal Time (UTC, formerly known as GMT). UTC helps to ensure that the same timestamp is not associated with different logs (because of a change in time that is associated with Daylight Saving Time, for example). The timestamp in a backup image is based on the local time at which the backup operation started. The CURRENT time zone special register specifies the difference between UTC and local time at the application server. The difference is represented by a time duration (a decimal number in which the first two digits represent the number of hours, the next two digits represent the number of minutes, and the last two digits represent the number of seconds). Subtracting CURRENT TIMEZONE from a local time converts that local time to UTC. - USING UTC TIME
- Allows you to roll forward to a point in time that is specified as UTC time. This parameter is the default option.
- USING LOCAL TIME
- Allows you to roll forward to a point in time that is the server's local time rather than UTC
time. Note:
- If you specify a local time for a rollforward operation, all messages that are returned to you are also in local time. All times are converted on the server, and in partitioned database environments, on the catalog database partition.
- The timestamp string is converted to UTC on the server, so the time is local to the server's time zone, not the client's. If the client is in one time zone and the server in another, the server's local time should be used.
- If the timestamp string is close to the time change of the clock due to daylight savings, it is important to know whether the stop time is before or after the clock change, and specify it correctly.
- Subsequent ROLLFORWARD commands that cannot specify the USING LOCAL TIME clause has all messages that are returned to you in local time if this option is specified.
- It is important to choose the USING LOCAL TIME or the USING UTC TIME (formerly known as GMT time) correctly. If not specified, the default is USING UTC TIME. Any mistake in the selection might cause a rollforward operation to reach a different point in time than expected and truncate the logs after that point in time. Mistaking a local timestamp as a UTC timestamp might cause the required logs to be truncated undesirably and prevent further rollforward operations to a point later than the mistaken time.
- Specify a valid timestamp when recovering a database. A valid timestamp would be the time that the last backup in the partitioned database system was completed.
- When issuing multiple ROLLFORWARD DATABASE commands, the timestamp you specify for each subsequent command must be greater than the timestamp you specified in the previous command.
- END OF LOGS
- Specifies that all committed transactions from all online archive log files listed in the
database configuration parameter logpath are to be applied.
If an END OF LOGS rollforward operation is attempted, you cannot switch to a point-in-time (PIT) rollforward operation. To roll forward to a PIT when a previous END OF LOGS rollforward operation is in progress, you must redo the restore and then run the rollforward command.
- END OF BACKUP
- Specifies that all partitions in the partitioned database, or all members in the Db2 pureScale environment, should be rolled forward to the minimum recovery time. See here for an example.
- ALL DBPARTITIONNUMS | ON ALL DBPARTITIONNUMS
- Specifies that transactions are to be rolled forward on all database partitions specified in the db2nodes.cfg file. This is the default if a database partition clause is not specified.
- EXCEPT
- Specifies that transactions are to be rolled forward on all database partitions specified in the db2nodes.cfg file, except those specified in the database partition list.
- ON DBPARTITIONNUM | ON DBPARTITIONNUMS
- Roll the database forward on a set of database partitions.
- db-partition-number1
- Specifies a database partition number in the database partition list.
- db-partition-number2
- Specifies the second database partition number, so that all database partitions from db-partition-number1 up to and including db-partition-number2 are included in the database partition list.
- COMPLETE | STOP
- Stops the rolling forward of log records, and completes the rollforward recovery process by
rolling back any incomplete transactions and turning off the rollforward pending state of the
database. This allows access to the database or table spaces that are being rolled forward. These
keywords are equivalent; specify one or the other, but not both. The keyword
AND permits specification of multiple operations at once; for example,
db2 rollforward db sample to end of logs and complete
. When rolling table spaces forward to a point in time, the table spaces are placed in backup pending state. - CANCEL
- Cancels the rollforward recovery operation. This puts the database or one or more table spaces
on all database partitions on which forward recovery has been started in restore pending state:
- If a database rollforward operation is not in progress (that is, the database is in rollforward pending state), this option puts the database in restore pending state.
- If a table space rollforward operation is not in progress (that is, the table spaces are in rollforward pending state), a table space list must be specified. All table spaces in the list are put in restore pending state.
- If a table space rollforward operation is in progress (that is, at least one table space is in rollforward in progress state), all table spaces that are in rollforward in progress state are put in restore pending state. If a table space list is specified, it must include all table spaces that are in rollforward in progress state. All table spaces on the list are put in restore pending state.
- If rolling forward to a point in time, any table space name that is passed in is ignored, and all table spaces that are in rollforward in progress state are put in restore pending state.
- If rolling forward to the end of the logs with a table space list, only the table spaces listed are put in restore pending state.
This option cannot be used to cancel a rollforward operation that is actually running. It can only be used to cancel a rollforward operation that is in progress but not actually running at the time. A rollforward operation can be in progress but not running if:- It terminated abnormally.
- The STOP option was not specified.
- An error caused it to fail. Some errors, such as rolling forward through a non-recoverable load operation, can put a table space into restore pending state.
Use this option with caution, and only if the rollforward operation that is in progress cannot be completed because some of the table spaces have been put in rollforward pending state or in restore pending state. When in doubt, use the LIST TABLESPACES command to identify the table spaces that are in rollforward in progress state, or in rollforward pending state.
- QUERY STATUS
- Lists the log files that the database manager has
processed, the next archive file required, and the time stamp (in UTC) of the last committed
transaction since rollforward processing began. In a partitioned database environment and a
Db2
pureScale environment, this status information
is returned for each database partition or member. The information returned
contains the following fields:
- Member number
- The member number or database partition number. In a single-partition environment, this is always 0.
- Rollforward status
- Status can be: database or table space rollforward pending, database or table space rollforward in progress, database or table space rollforward processing STOP, or not pending.
- Next log file to be read
- A string containing the name of the next required log file. In a partitioned database environment, use this information if the rollforward utility fails with a return code indicating that a log file is missing or that a log information mismatch has occurred.
- Log files processed
- A string containing the names of processed log files that are no longer needed for recovery. It
means these log files can be removed from log path, if additional log files need to be provided to
continue the rollforward recovery operation. This field is not updated in case of a table space
rollforward recovery operation.Note: There might be a gap between Log files processed and Next log file to be read. This reflects the existence of inflight transactions, so the log files starting from the oldest inflight transaction are still required to be processed in the next round of rollforward, and these log files should not be removed from the log path.
- Last committed transaction
- A string containing a time stamp in ISO format
(
yyyy-mm-dd-hh.mm.ss
) suffixed by either "UTC" or "Local" (see USING LOCAL TIME). This time stamp marks the last transaction committed after the completion of rollforward recovery. The time stamp applies to the database. For table space rollforward recovery, it is the time stamp of the last transaction committed to the database.
QUERY STATUS is the default value if the TO, STOP, COMPLETE, or CANCEL clauses are omitted. If TO, STOP, or COMPLETE was specified, status information is displayed if the command has completed successfully. If individual table spaces are specified, they are ignored; the status request does not apply only to specified table spaces.
- TABLESPACE
- This keyword is specified for table space-level rollforward recovery.
- tablespace-name
- Mandatory for table space-level rollforward recovery to a point in time. Allows a subset of
table spaces to be specified for rollforward recovery to the end of the logs. In a partitioned
database environment, each table space in the list does not have to exist at each database partition
that is rolling forward. If it does exist, it must be in the correct state.
For partitioned tables, point in time roll forward of a table space containing any piece of a partitioned table must also roll forward all of the other table spaces in which that table resides to the same point in time. The table spaces containing the index partitions are included in the list of pieces of a partitioned table. Roll forward to the end of the logs for a single table space containing a piece of a partitioned table is still allowed.
If a partitioned table has any attached or detached data partitions, then PIT rollforward operation must include all table spaces for these data partitions as well. To determine if a partitioned table has any attached, detached, or dropped data partitions, query the Status field of the SYSDATAPARTITIONS catalog table.
Because a partitioned table can reside in multiple table spaces, it will generally be necessary to roll forward multiple table spaces. Data that is recovered via dropped table recovery is written to the export directory specified in the ROLLFORWARD DATABASE command. It is possible to roll forward all table spaces in one command, or do repeated roll forward operations for subsets of the table spaces involved. If the ROLLFORWARD DATABASE command is done for one or a few table spaces, then all data from the table that resided in those table spaces will be recovered. A warning will be written to the notify log if the ROLLFORWARD DATABASE command did not specify the full set of the table spaces necessary to recover all the data for the table. Allowing roll forward of a subset of the table spaces makes it easier to deal with cases where there is more data to be recovered than can fit into a single export directory.
- ONLINE
- This keyword is specified to allow table space-level rollforward recovery to be done online. This means that other agents are allowed to connect while rollforward recovery is in progress. To support concurrency with other applications in a Db2 pureScale environment, the table space-level rollforward operation might need to test for certain internal locks. A rollforward operation in this environment might fail with lock timeout even if locktimeout is set to -1.
- OVERFLOW LOG PATH log-directory
- Specifies an alternate log path to be searched for archived logs during recovery. Use this parameter if log files were moved to a location other than that specified by the logpath database configuration parameter. The specified log path must be a fully qualified path. The OVERFLOW LOG PATH command parameter will override the value (if any) of the database configuration parameter overflowlogpath.
- log-directory ON DBPARTITIONNUM
- In a partitioned database environment, allows a different log path to override the default overflow log path for a specific database partition.
- NORETRIEVE
- Allows you to control which log files are to be rolled forward by disabling the retrieval of archived logs.
- RECOVER DROPPED TABLE drop-table-id
- Recovers a dropped table during the rollforward operation. The table ID can be obtained using the LIST HISTORY command, in the Backup ID column of the output listing. For partitioned tables, the drop-table-id identifies the table as a whole, so that all data partitions of the table can be recovered in a single rollforward command.
- TO export-directory
- Specifies a directory to which files containing the table data are to be written. The directory must be accessible to all database partitions.
Examples
- The ROLLFORWARD DATABASE command permits specification of
multiple operations at once, each being separated with the AND parameter. For
example, to roll forward to the end of logs and complete, you can issue the following two commands:
Alternatively, you can use the AND parameter to combine the two operations, as follows:db2 rollforward db sample to end of logs db2 rollforward db sample complete
However, you should perform the operations in two steps. Before you stop the rollfoward operation, it is important to verify that it progressed as you expected and that no logs are missing. This is especially important if a bad log is found during rollforward recovery, and the bad log is interpreted to mean thedb2 rollforward db sample to end of logs and complete
end of logs
. In such cases, an undamaged backup copy of that log might be used to continue the rollforward operation through more logs. However, if the rollforward AND STOP option is used, and the rollforward operation encounters an error, the error is returned to you. In this case, the only way to force the rollforward operation to stop and come online despite the error (that is, to come online at that point in the logs before the error) is to issue the ROLLFORWARD STOP command. - Example 2: Roll forward to the end of the logs (two table spaces have been restored):
These two statements are equivalent. Neither AND STOP or AND COMPLETE is needed for table space rollforward recovery to the end of the logs. Table space names are not required. If not specified, all table spaces requiring rollforward recovery will be included. If only a subset of these table spaces is to be rolled forward, their names must be specified.db2 rollforward db sample to end of logs db2 rollforward db sample to end of logs and stop
- Example 3: After three table spaces have been restored, roll one forward to the end of
the logs, and the other two to a point in time, both to be done online:
Two rollforward operations cannot be run concurrently. The second command can only be invoked after the first rollforward operation completes successfully.db2 rollforward db sample to end of logs tablespace(TBS1) online db2 rollforward db sample to 1998-04-03-14.21.56 and stop tablespace(TBS2, TBS3) online
- Example 4: A database is restored. Next, a roll forward to a point in time
is done, using the OVERFLOW LOG PATH parameter to specify the directory where
the user exit saves archived logs:
db2 rollforward db sample to 1998-04-03-14.21.56 and stop overflow log path (/logs)
- Example 5 (partitioned database environments): There are three database partitions: 0, 1,
and 2. Table space TBS1 is defined on all database partitions, and table space TBS2 is defined on
database partitions 0 and 2. After restoring the database on database partition 1, and TBS1 on
database partitions 0 and 2, roll the database forward on database partition 1:
This returns warning SQL1271 (db2 rollforward db sample to end of logs and stop
Database is recovered but one or more table spaces are offline on database partition(s) 0 and 2.
).
This rolls TBS1 forward on database partitions 0 and 2. The clause TABLESPACE(TBS1) is optional in this case.db2 rollforward db sample to end of logs
- Example 6 (partitioned database environments): Table space TBS1 is restored
on database partitions 0 and 2 only. Next, TBS1 is rolled forward on database partitions 0 and 2:
Database partition 1 is ignored.db2 rollforward db sample to end of logs
db2 rollforward db sample to end of logs tablespace(TBS1)
The following command fails because TBS1 is not ready for rollforward recovery on database partition 1. SQL4906N is issued.
db2 rollforward db sample to end of logs on dbpartitionnums (0, 2) tablespace(TBS1)
The following command runs successfully:
db2 rollforward db sample to 1998-04-03-14.21.56 and stop tablespace(TBS1)
The following command fails because TBS1 is not ready for rollforward recovery on database partition 1; all pieces must be rolled forward together. With table space rollforward recovery to a point in time, the database partition parameter is not accepted. The rollforward operation must take place on all the database partitions on which the table space is located.
This completes successfully.db2 rollforward db sample to 1998-04-03-14.21.56 and stop tablespace(TBS1)
- Example 7 (partitioned database environment): After restoring a table space on all
database partitions, roll forward to point in time 2, but do not specify AND
STOP. The rollforward operation is still in progress. Cancel and roll forward to point in
time 1:
db2 rollforward db sample to pit2 tablespace(TBS1) db2 rollforward db sample cancel tablespace(TBS1) ** restore TBS1 on all database partitions ** db2 rollforward db sample to pit1 tablespace(TBS1) db2 rollforward db sample stop tablespace(TBS1)
- Example 8 (partitioned database environments): A table space is located on
multiple database partitions. The following command rolls forward the table space to the end of
logs. The database partitions on which the table space is located do not have to be specified. By
default, the command uses the db2nodes.cfg file.
db2 rollforward database dwtest to end of logs tablespace (tssprodt)
This operation to the end of logs (not point in time) completes successfully. The database partitions on which the table space resides do not have to be specified. The utility defaults to the db2nodes.cfg file.
- Example 9 (partitioned database environment): Rollforward recover six small table spaces
that reside on a single-partition database partition group (on database partition 6):
db2 rollforward database dwtest to end of logs on dbpartitionnum (6) tablespace(tsstore, tssbuyer, tsstime, tsswhse, tsslscat, tssvendor)
This operation to the end of logs (not point in time) completes successfully.
- Example 10 (partitioned database environment or Db2
pureScale environment): You can use the
TO END OF BACKUP clause with the ROLLFORWARD command to roll
forward all database partitions or members to the minimum recovery time. The
minimum recovery time is the earliest point in time during a rollforward operation when a database
is consistent (when the objects listed in the database catalogs match the objects that exist on
disk). Manually determining the correct point in time to roll forward a database is difficult,
particularly for a partitioned database or in a Db2
pureScale instance. The END OF
BACKUP option makes it
easy.
db2 rollforward db sample to end of backup and complete
- Example
11: Recovery using logs from an online database backup imageThe following command restores a database from an online database backup image that includes logs that are restored to the /backup_logs directory:
db2 restore database sample... logtarget /backup_logs
In all environments, use the following command to roll forward the database to the end of the backup image using the logs restored from the online backup image:
db2 rollforward database sample to end of backup and stop overflow log path (/backup_logs)
- Example
12: Roll forward using logs found in the archive log path directly to improve performance
The archive log path (specified by LOGARCHMETH1 or LOGARCHMETH2) is configured to use DISK method, such as DISK:/some_logarch_path/.
In all environments, use the following command to roll forward the database using logs from the archive log path directly.
db2 rollforward database sample to end of logs and stop overflow log path (/some_logarch_path/<instance name>/<db name>)
This prevents Db2 from retrieving log files and placing them in the local retrieve location. This improves performance by avoiding the cost of additional I/O copy operations.
- Example
13: Roll forward using log shipping
An alternative set of logs can be supplied to the ROLLFORWARD command using the OVERFLOW LOG PATH parameter. To provide log files, you must create the necessary set of paths based on the database environment and populate these paths with the log files required for the ROLLFORWARD command.
Environment-specific commands are used to roll forward a database:- Rolling forward a database in a single partition database environmentTo provide an alternate set of logs, you can either create a base overflow path or create a base overflow path with a database partition number and log stream ID appended:
ormkdir -p /overflow
With the path created and populated, use the following command to roll forward the database using the logs in the overflow log path:mkdir -p /overflow/NODE0000/LOGSTREAM0000
After verifying that the ROLLFORWARD command was sufficiently completed, use the following command to complete the rollforward operation:db2 rollforward database sample to end of logs overflow log path (/overflow)
db2 rollforward database sample to end of logs and stop overflow log path (/overflow)
- Rolling forward a database in a multi-partition database environment
To provide an alternate set of logs and use the default overflow log path for multiple partitions, you can create paths under the default overflow log path for each partition. You also need to append a corresponding database partition number and log stream ID to each path.
Assuming that there are four partitions numbered 0, 1, 2, and 3, create the following paths:mkdir -p /overflow/NODE0000/LOGSTREAM0000 mkdir -p /overflow/NODE0001/LOGSTREAM0001 mkdir -p /overflow/NODE0002/LOGSTREAM0002 mkdir -p /overflow/NODE0003/LOGSTREAM0003
With the paths created and populated, use the following command to roll forward the database using the logs in the default overflow log path:db2 rollforward database sample to end of logs overflow log path (/overflow)
After verifying that the ROLLFORWARD command was sufficiently completed, use the following command to complete the rollforward operation:db2 rollforward database sample to end of logs and stop overflow log path (/overflow)
You might not able to use the default overflow log path for any database partition. You can provide an alternate set of logs and override the default overflow log path.
To override the default overflow log path, each partition is treated as a single partition environment. Create an override path, with or without a database partition number and log stream ID appended.
Assume there are four partitions numbered 0, 1, 2, and 3. To override the default overflow log path for partition 1 with /node1, and to override the default overflow log path for partition 3 with /node3, create the following paths:
- Partition 0:
mkdir -p /overflow/NODE0000/LOGSTREAM0000
- Partition 1:
mkdir -p /node1 OR mkdir -p /node1/NODE0001/LOGSTREAM0001
- Partition 2:
mkdir -p /overflow/NODE0002/LOGSTREAM0002
- Partition 3:
mkdir -p /node3 OR mkdir -p /node3/NODE0003/LOGSTREAM0003
With the paths created and populated, use the following command to roll forward the database using the logs in the default overflow log path and override log paths:db2 rollforward database sample to end of logs on all dbpartitionnums overflow log path (/overflow, /node1 on dbpartitionnum 1, /node3 on dbpartitionnum 3)
After verifying that the ROLLFORWARD command was sufficiently completed, use the following command to complete the rollforward operation:db2 rollforward database sample to end of logs on all dbpartitionnums and stop overflow log path (/overflow, /node1 on dbpartitionnum 1, /node3 on dbpartitionnum 3)
- Partition 0:
- Rolling forward a database in a pureScale database environment
To provide an alternate set of logs, create paths with a corresponding database partition number and log stream ID appended.
Assuming that there exist three members (log streams) numbered 0, 1, and 2, create the following paths:
With the paths created and populated, use the following command to roll forward the database that uses the logs in the default overflow log path:mkdir -p /overflow/NODE0000/LOGSTREAM0000 mkdir -p /overflow/NODE0000/LOGSTREAM0001 mkdir -p /overflow/NODE0000/LOGSTREAM0002
After verifying that the ROLLFORWARD command was sufficiently completed, use the following command to complete the rollforward:db2 rollforward database sample to end of logs overflow log path (/overflow)
db2 rollforward database sample to end of logs and stop overflow log path (/overflow)
Note: When a log file is present in both the overflow log path and the active log path, the log file in the active log path is used.
- Rolling forward a database in a single partition database environment
Usage notes
If restoring from an image that was created during an online backup operation, the specified point in time for the rollforward operation must be later than the time at which the online backup operation completed. If the rollforward operation is stopped before it passes this point, the database is left in rollforward pending state. If a table space is in bieng rolled forward, it is left in rollforward in progress state.
If one or more table spaces are being rolled forward to a point in time,
the rollforward operation must continue at least to the minimum recovery time, which is the last
update to the system catalogs for this table space or its tables. The minimum recovery time (in
Coordinated Universal Time, or UTC) for a table space can be retrieved by using the LIST
TABLESPACES SHOW DETAIL command. In a Db2
pureScale environment, the LIST
TABLESPACES command is deprecated; use the following monitoring UDF: SELECT * FROM
TABLE( SYSPROC.MON_GET_TABLESPACE('TBSPACE_1,0) )
In a Db2
pureScale environment, ensure that there
exists adequate available disk space in the retrieval path before starting a rollforward operation.
This precaution allows the operation to retrieve the larger number of files from the archive, as
required in a Db2
pureScale environment, without affecting
performance. Use the following formula to calculate how much space you need to retrieve the value of
the active log space for all members: (logprimary +
logsecond) * number of members
.
If you want to roll, forward a table space that contains a system-period temporal table or bitemporal table to a point in time, the ROLLFORWARD DATABASE command must include the name of the table space that contains the associated history table. You can roll forward the table space for the temporal table or the table space for the history table individually, but only to the end of logs.
- c
- Continue. Continue to use the device that generated the warning message (for example, when a new tape was mounted. )
- d
- Device terminates. Stop using the device that generated the warning message (for example, when no more tapes exist. )
- t
- Terminate. Take all affected table spaces offline, but continue rollforward processing.
If the ROLLFORWARD DATABASE command cannot find the next log that it needs, the log name is returned in the SQLCA, and rollforward recovery stops. If no more logs are available, use the STOP parameter to stop rollforward recovery. Incomplete transactions are rolled back to ensure that the database or table space is left in a consistent state.
If a database rollforward operation detects a log record for a table space schema transport, the corresponding transported table space is taken offline and moved into drop-pending state. This behavior occurs because of the absence of the complete logs of transported table spaces to rebuild transported table spaces and their contents. You can take a full backup of the target database after the transport is complete. Doing so ensures that a subsequent rollforward operation does not pass the point of schema transport in the log stream.
REDISTRIBUTE DATABASE PARTITION GROUP command.
If you extracted log files from a database backup, and you plan to run the ROLLFORWARD command with the TO END OF BACKUP clause for that database, use the NORETRIEVE option. The NORETRIEVE option is needed because all the necessary log files are available and no files need to be retrieved from the archive location. Without using the NORETRIEVE option, some archived log files can be retrieved that are not needed for this rollforward operation. If the archive locations contain log files from other log chains, the ROLLFORWARD results in SQLCODE -1265.