HP 3000 Manuals HP 3000 Manuals
Logging Maintenance
You should determine a log maintenance cycle for the database. For
example, suppose the database is maintained on a daily cycle. This means
that, at the beginning of each day, the log process is initiated from the
console with the LOG command and the flags are set (see the following
discussion). At the end of the day, the log process is stopped from the
console and the flags are reset for storage of the database backup copy.
Note that the duration of this maintenance cycle depends on at least two
considerations:
* The amount of time needed to store the database periodically, and
* The amount of time required to recover the database from the log
file using DBRECOV if the system fails.
The more often the database backup copy is stored, the smaller the log
file and the shorter recovery time will be. Regular backup of the
database is recommended, though not required when using roll-back
recovery. Refer to appendix G for a brief overview of the disadvantages
and benefits of logging to disk and logging to tape. This appendix also
includes sample job streams for the logging cycle.
Starting the Logging Process
After a database backup copy has been stored as described earlier in
"Logging Preparation," a logging process must be allocated to the log
identifier so that it can be activated. A log process is an MPE/iX
system process responsible for buffering log records in memory. If the
log file is on tape, the log process also buffers the log records on disk
before writing them to the log file. This process is initiated from the
console using the MPE/iX LOG command. To issue the LOG command, you must
have logging (LG) or operator (OP) capability. The ALLOW command can be
used to transfer permission to enter this console command.
Syntax
{START }
:LOG logid,{RESTART}
{STOP }
Parameters
logid is the name of the logid to be activated; the logid
must have been set previously into the database
root file.
START initiates a log process for the first time.
RESTART initiates a log process when appending new log
records to an old log file.
STOP terminates a log process. Termination does not
take effect until all current users have closed the
log file by calling the CLOSELOG intrinsic.
Example
LOG ORDERLOG, START
If the log process is stopped using the LOG command, but a database
backup copy is not generated at that time, the RESTART option must be
used to resume logging to the same log file.
To determine whether or not a log process is running, use the MPE/iX
SHOWLOGSTATUS command to determine the log identifiers of active log
processes. SHOWLOGSTATUS displays the percentage of records in the log
file if the logid output is to disk. This information may be helpful in
determining when to perform a CHANGELOG command (see "CHANGELOG
Capability" in this section). The following sample listing was produced
by a SHOWLOGSTATUS command:
:SHOWLOGSTATUS
LOGID CHANGE AUTO USERS STATE CUR-RECS MAX-REC %USED CUR-SET
MYLOG NO NO 4 INACTIVE 100 1000 10% 1
TAPELOG YES 1 INACTIVE 5738 1
ORDERLOG YES YES 2 INACTIVE 500 1000 50% 2
Re-enabling Logging.
In the event that logging for roll-forward recovery is disabled and needs
to be re-enabled, the database should be stored with DBSTORE before
logging is re-enabled. This ensures that the DBSTORE flag and time stamp
set when logging was first enabled are not reset when logging is
re-enabled.
Setting Database Flags
After logging is initiated, you can allow users to modify the database by
running DBUTIL and enabling the database for access. You should also
disable recovery at this time. This provides a safeguard against
unintended recovery if DBRECOV is executed from a stream file against
several databases simultaneously. For example:
:RUN DBUTIL.PUB.SYS
:
>>ENABLE ORDERS FOR ACCESS
Access is Enabled
>>DISABLE ORDERS FOR RECOVERY
Recovery is Disabled
CHANGELOG Capability
The MPE/iX CHANGELOG feature provides a continuous MPE/iX user logging
process, with the ability to change tape or disk log files when they
reach capacity without stopping the user logging process. User logging
also keeps track of the order of the files in the log file set. Parts of
the CHANGELOG record contain the file set number (001-999) and the device
type of the file names in the record. In addition, there are records for
the previous file in a set, first file in a set, and current file in a
set. This format allows recovery to always start at the beginning of the
file set (or at any point within the file set if the sequence number is
used), and reopen the log files on the same device type that they were
created.
The user issuing the CHANGELOG command must be the creator of the logid.
If the user issuing CHANGELOG is not the creator of the logid, either LG
or OP capability is required. If the mirror database method (DBRECOV
STOP/RESTART) is being used, CHANGELOG makes logging without interruption
on the primary system possible.
NOTE If the database needs to be recovered when you are using the MPE/iX
CHANGELOG feature, the DBRECOV recovery facility starts at the
first log file in the logging cycle (for example, LOGF001) even if
you wish to start recovery at a different point (for example,
LOGF013). Keep this in mind when determining the length of your
logging cycle. See "Recovering the Database" later in this section
for a sample scenario.
Syntax
:CHANGELOG logid [;DEV=device]
Parameters
logid is the name of the currently active logging
process.
device is the class of the device of the new log file
(DISC, TAPE). If the device class specified is
DISC, the file is created in the logid creator's
logon group and account.
Example
:CHANGELOG ORDERLOG; DEV=DISC
Note that the logid specified must be that of the currently active
logging process. If the log file is changed using ALTLOG, no linkage of
the log file set is provided. A CHANGELOG command can only be used on a
logid set up with the GETLOG command. The CHANGELOG command terminates
if the logging process state is INACTIVE, INITIALIZING, or RECOVERING.
The command will also terminate if a CHANGELOG command is already
pending. The following message is displayed on $STDLIST:
INVALID STATE OF PROCESS
After issuing the CHANGELOG command, if the logid is valid, CHANGELOG
records are posted to the current log file. The current log file is
closed and the new log file is opened. A message similar to the
following message is displayed on $STDLIST and the console to confirm the
change:
Log file for !!logid!! ORDERLOG has been changed from ORDER001 to ORDER002
If the new log file is a serial file on tape, the following message
appears on the console requesting the mounting of a new log file (in this
case the logid is ORDERLOG):
Mount new tape for !!logid!! ORDERLOG
If a LISTLOG command is executed while the logging process is performing
a CHANGELOG command, the file name displayed is that of the current log
file. The log file name is not updated until the CHANGELOG sequence
successfully completes. The SHOWLOGSTATUS command may be used to display
the current status of a logging process to determine if a CHANGELOG is
taking place.
The following example shows a LISTLOG display. A CHANGELOG is currently
taking place on log file ORDER001; and, because the CHANGELOG to ORDER002
is not yet successfully completed, ORDER001 is displayed:
:LISTLOG
LOGID CREATOR CHANGE AUTO CURRENT LOG FILE
MYLOG DATA.SYS NO NO MY.PUB.SYS
TAPELOG DATA.SYS YES TAPE001
ORDERLOG TST.MKTG YES YES ORDER001.MKTG.SYS
Recovering the Database.
When a database needs to be recovered, DBRECOV starts with the first log
file written to in a given logging cycle. To illustrate this concept,
consider the following scenario.
The MPE/iX CHANGELOG command or the GETLOG AUTO feature is being used to
log transactions to a log file called LOGF001. When LOGF001 fills up,
user logging automatically appends LOGF001 with a CHANGELOG record
indicating that TurboIMAGE/XL is now logging to file LOGF002. This
process continues until either LOGF999 is reached or another file is
encountered that has the same name as the one being created by user
logging.
If a database needs to be recovered and the logging cycle is currently
writing to LOGF020, note that DBRECOV begins recovery at LOGF001, even if
you know or want to recover only the transactions from, for example, log
file LOGF013. The resulting impact on recovery time is why serious
consideration should be given to the logging cycle. The shorter the
logging cycle is, the shorter the recovery time.
Ending the Logging Maintenance Cycle
At the end of the specified maintenance cycle (for example, the end of
day) do the following:
1. Stop the logging process at the console with the LOG command.
2. Run DBUTIL and do the following tasks:
* Disable access to the database.
* Enable recovery of the database.
3. Store a database backup copy (required for roll-forward recovery)
with DBSTORE.
Example
:LOG ORDERLOG,STOP
:RUN DBUTIL.PUB.SYS
:
>>DISABLE ORDERS FOR ACCESS
Access is Disabled
>>ENABLE ORDERS FOR RECOVERY
Recovery is Enabled
>>EXIT
END OF PROGRAM
:RUN DBSTORE.PUB.SYS
WHICH DATA BASE? ORDERS
DATA BASE STORED
END OF PROGRAM
Logging Results
All database modifications (DBPUTs, DBUPDATEs, and DBDELETEs) are logged;
and in modes 1 through 4 calls to DBOPEN, DBCLOSE, DBBEGIN, DBXBEGIN,
DBEND, DBXEND, and DBMEMO are logged to the log file. Each DBBEGIN,
DBXBEGIN, DBEND, and DBXEND causes a log record to be written to the log
file that includes such information as time, date, and user buffer.
These log records are used by DBRECOV to identify logical transactions.
Log Records.
DBOPEN log records contain a time stamp in the database root file,
indicating the date and the time of the last DBSTORE (this time stamp is
referenced by DBRECOV roll-forward recovery). DBOPEN log records also
include the user identifier, log identifier, and the name, group, and
account of the user, database, and program.
DBUPDATE log records include both the new and the old data (before and
after images); DBDELETE includes a copy of the deleted data (before
image); DBPUT includes the record being added (after image).
Log File Time Stamps.
The two log file time stamps are as follows:
* The DBSTORE time stamp set at the time the last database backup
copy was made (used by roll-forward recovery). The DBSTORE time
stamp is fixed and does not change once the database backup copy
has been made.
* The roll-back time stamp created at the time the first DBOPEN is
executed against the database. The roll-back time stamp is
updated to the real time of the first DBOPEN following each close
of the database, providing a roll-back termination point should a
roll-back recovery be required.