HP 3000 Manuals HP 3000 Manuals
Logging Preparation
User logging is required for roll-forward recovery, roll-back recovery,
and to maintain a mirror database. It is not required for dynamic
roll-back recovery, but is recommended to protect against a hard disk
failure. To prepare a database for user logging, you must set a log
identifier (logid) into the database root file. The log identifier can
be associated with an existing log file, in which case you can begin with
step 6 below if you know the log identifier and password. Note that to
recover a database using a log file, you must either be the creator of
the logid, or supply the maintenance word and have system manager (SM) or
operator (OP) capability.
Assuming you intend to create a new log identifier, you should take the
following steps:
1. Check MPE/iX logging configuration.
2. Acquire logging capability.
3. Determine whether the log file will reside on tape or disk.
4. If logging to disk, build the log file.
5. Create the log identifier.
6. Set the log identifier into the database.
7. Set flags for the database backup copy.
8. Make a backup copy of the database. This step is required when
using roll-forward recovery and recommended (for protection in the
event of a hard disk failure), but not required, when using
roll-back recovery.
This is a one-time procedure. The logging maintenance operations are
performed on a regular basis, perhaps daily (refer to "Logging
Maintenance" later in this chapter).
Step 1--Checking MPE/iX Logging Configuration
It is recommended that you check the logging configuration for adequate
capacity before using the MPE/iX LOG command described later in this
section. This precautionary step can prevent the downtime required to
reconfigure the logging capacity. You need to check the number of user
logging processes allowed on the system and the number of users that can
access a single user logging process. For information on setting up
these numbers at system startup time, refer to the System Operation and
Resource Management Reference Manual.
Step 2--Acquiring Logging Capability
You must have MPE/iX logging (LG) or operator (OP) capability to use the
following MPE/iX commands: GETLOG, RELLOG, ALTLOG, CHANGELOG, LISTLOG,
and SHOWLOGSTATUS. You must have LG or OP capability also if you intend
to open a database with logging enabled. Logging capability is acquired
through the MPE/iX system manager and account manager commands.
First, the system manager provides the account logging capability by
using the MPE/iX NEWACCT command for a new account, or the ALTACCT
command for an existing account, as follows:
:NEWACCT acctname,mgrname;CAP=capability list (include LG)
:ALTACCT acctname;CAP=capability list (include LG)
Next, the account manager can provide logging capability to individual
users by using the NEWUSER command for new users, or the ALTUSER command
for an existing user, as follows:
:NEWUSER username;CAP=capability list (include LG)
:ALTUSER username;CAP=capability list (include LG)
For example:
:NEWACCT CAPE,RICK;CAP=LG,AM,AL,GL,SF,ND,IA,BA
:NEWUSER ILSA;CAP=LG,AL,GL,SF,ND,IA,BA
Refer to the MPE/iX Commands Reference Manual for information on other
MPE/iX user logging commands, including these listed here:
RELLOG Removes a log identifier.
ALTLOG Alters an existing log identifier.
LISTLOG Lists the current log identifiers.
Any messages that are followed by (ULOGERR#) or (ULOGMSG#) are MPE/iX
errors or system messages.
Step 3--Logging to Tape or Disk
You must choose whether to log to tape or disk. The overhead required by
the logging operation is comparable on disk or tape. However, other
factors should be considered.
For roll-back recovery when logging to tape, the database must be in the
system volume set. For roll-back recovery when logging to disk, the
database and the log file must be in the same volume set. Logging to
tape is the more secure option, because a log file residing on tape is
less susceptible to damage from possible system failure than a disk log
file. Refer to appendix G for more information on considerations when
logging to disk and tape.
For allocating resources, logging to tape requires that the system be
able to make a tape drive available as long as the database is accessible
for modification. If the decision is made to log to disk, you must use
the MPE/iX BUILD command to create a new file and allocate space on disk,
as described in step 4. This allocation must be generous enough to avoid
any possibility of filling the log file to capacity.
Step 4--Building a Log File for Logging to Disk
This step is required only when logging to disk. You must build the new
file and allocate space for it on disk by using the MPE/iX BUILD command
below.
Syntax
:BUILD
logfile;CODE=LOG;DISC=[numrec][,[numextents][,initial loc]][;DEV=[device]]
Parameters
logfile is the name of the log file being built, as
specified in the MPE/iX GETLOG command. If you
specify the AUTO option with the GETLOG command,
the log file name must end with 001 to designate
the first file in the log file set.
__________________________________________________
NOTE If you are using roll-back recovery, the log
file and the database must be in the same
volume set. To accomplish this, use the
device parameter of the MPE/iX BUILD command
and then create the log file in the
appropriate group and account.
__________________________________________________
numrec is the maximum number of logical records. Maximum
value allowed is 2,147,483,647. Default is 1023.
numextents is the maximum number of disk extents (from 1 to
32, inclusive). Default is 8.
initialloc is the number of extents to be initially allocated
to the file at the time it is opened. Default is
1.
device is the class of the device on which the log file
and database are to reside. This parameter puts
the log file and database in the same volume set.
Required for roll-back recovery; is not used for
roll-forward recovery.
If the default NOAUTO option is used in the GETLOG command, disk log
files must be of sufficient size to prevent the end-of-file from being
reached, because MPE/iX causes the associated log process to terminate
when the log file is filled to capacity. Therefore, subsequent calls to
TurboIMAGE/XL intrinsics that require log records to be written to the
log file will fail. If this occurs in the middle of a transaction, the
database is left in an inconsistent state. It then becomes necessary to
recover transactions with roll-forward or roll-back recovery. Because
reaching the end of a disk log file is similar in effect to a system
failure, disk log files should be built with a total capacity far
exceeding their required size and consisting of as many extents of
contiguous disk sectors as needed to meet the capacity requirements of
the file, subject to the constraints of the MPE/iX file system; of these
extents only enough to satisfy the expected capacity should be allocated
initially.
NOTE When the NOAUTO option is used, the MPE/iX SHOWLOGSTATUS command
can be used to determine the space usage of the existing log file
and when to create a new log file using an MPE/iX CHANGELOG
command.
Example
:BUILD ORDER001;CODE=LOG;DISC=200000,20,7
Step 5--Creating the Log Identifier
You create the log identifier on MPE/iX by using the GETLOG command shown
in this section. A log identifier (logid) is a unique logical name that
identifies a system logging process to which log records are passed.
Before using the GETLOG command, use the MPE/iX LISTLOG command to check
if the logid already exists on MPE/iX. The LISTLOG command lists all
logging identifiers, including creator names, log file names, and whether
or not the AUTO option is used.
If the logid exists and was created by someone else, you must specify a
different logid. If the logid exists and was created by you, check the
parameters to verify that they are the ones you want. If you find, for
example, that you used the default NOAUTO option and you want to change
it to AUTO, you can either change it with the MPE/iX ALTLOG command, or
you can release the logid with the MPE/iX RELLOG command and then
re-create it with the GETLOG command. You can release a logid only if
you are the creator of that logid.
The logid has a maximum of eight characters. Other users can access the
log file and records in the same log file by using the logid you acquire
and its password. To access the logging system directly through MPE/iX,
you must have logging (LG) or operator (OP) capability and supply the
identifier and password on the OPENLOG intrinsic.
Syntax
:GETLOG logid;LOG=logfile,{DISC/TAPE} [;PASS=password] [;{AUTO/NOAUTO}]
Parameters
logid is the logging identifier to be established on the
system. It consists of a string of up to eight
characters that is meaningful to the user
application.
__________________________________________________
NOTE Do not give the logid and the log file the
same name, because the logid is used to name
the RESTART file (used for DBRECOV
STOP/RESTART recovery explained later in this
chapter).
__________________________________________________
logfile is an MPE/iX file reference that identifies the
actual file to which the log records are written.
If the AUTO option is specified, the last three
digits are numeric (001-999). The first log file
specified with the MPE/iX GETLOG command must end
with the last three digits equal to 001 if the AUTO
option is used. (A warning message is issued if
the log file does not end in 001.) When the AUTO
option is used, the next log file will be opened
automatically when the current one is full. The
new log file is numbered consecutively. When the
AUTO option is not used, the next log file needs to
be built manually using the CHANGELOG command, when
the current log file is almost full.
DISC is the class of the device on which the log file is
to reside. For roll-back recovery, the log file
and the database must be in the same volume set.
If the log file specified for the logid is a serial
file, the AUTO/NOAUTO option is ignored.
TAPE is the class of the device on which the log file is
to reside.
password is the password to be associated with the logging
identifier. This parameter protects the log file
from unauthorized access. Up to eight characters
are allowed.
AUTO performs an automatic CHANGELOG command when the
disk log file becomes full. A new log file is
automatically created with the same log file name
incremented by one in the digit portion; for
example, if the current log file is ORDER001, the
next file will be ORDER002. This enables logging
to continue uninterrupted, also creating a sequence
of log files or a log file set.
NOAUTO is the default. No CHANGELOG command is performed
when the disk log file becomes full.
Example
In the following example, the logid is created with the default NOAUTO
option and then changed to specify the AUTO option. The log file name
follows the naming convention required by the CHANGELOG command. The
LISTLOG command is used to check if the logid exists. The ALTLOG command
is used to change the AUTO/NOAUTO option.
:LISTLOG
NO LOGGING IDENTIFIERS ASSIGNED (CIWARN 1231)
:GETLOG ORDERLOG;LOG=ORDER001,DISC;PASS=PASSLOG
:LISTLOG
LOGID CREATOR CHANGE AUTO CURRENT LOG FILE
ORDERLOG BEA.MKTG YES NO ORDER001.MKTG.SYS
:ALTLOG ORDERLOG;AUTO
:LISTLOG
LOGID CREATOR CHANGE AUTO CURRENT LOG FILE
ORDERLOG BEA.MKTG YES YES ORDER001.MKTG.SYS
Because NOAUTO is assumed by default in the GETLOG command, the disk log
file is closed when it becomes full and logging is shut down unless you
manually issue a CHANGELOG command. When the NOAUTO default is used, you
need to verify the capacity of the log file on a regular basis and issue
a CHANGELOG command when necessary. When the AUTO option is specified as
in the ALTLOG command above, logging automatically initiates a CHANGELOG
command when the current log file becomes full.
In the example above, the AUTO option has been specified. Here is what
happens when log file ORDER001 becomes full. Logging initiates a
CHANGELOG command causing the log records to be written to ORDER002, the
next log file in the sequence. As each log file becomes full, logging
initiates additional CHANGELOG commands creating log files automatically
until log file ORDER999 becomes full. At this point, the log file name
is reset to ORDER001 and logging continues automatically.
If you specified the AUTO option as in the preceding example, and you
need to restart logging at logfile001, you can issue an ALTLOG command as
shown in the following example:
:LISTLOG
LOGID CREATOR CHANGE AUTO CURRENT LOG FILE
ORDERLOG BEA.MKTG YES YES ORDER026.MKTG.SYS
:ALTLOG ORDERLOG;LOG=ORDER001,DISC
Step 6--Setting the Log Identifier
The two previous steps were executed using MPE/iX commands. At this
point, you must notify the MPE/iX user logging system of the
TurboIMAGE/XL logging intention by setting the log identifier and logid
password into the database root file, using the DBUTIL >>SET command, as
shown in the example below:
:RUN DBUTIL.PUB.SYS
>>SET ORDERS LOGID = ORDERLOG
PASSWORD:? PASSLOG If no logid password was previously specified
in the GETLOG command, you would press Return
at the prompt.
DBUTIL checks the validity of the logid with MPE/iX, and reports a
warning as follows if the log identifier is not valid or if its password
is incorrect:
WARNING: non-existent LOGID
Once the log identifier has been set into the database, the log
identifier parameters cannot be altered for the logging and recovery
system to function correctly.
Step 7--Setting Flags for the Database Backup Copy
In addition to setting the log identifier, use DBUTIL to set the
following flags in the root file before making the backup copy of the
database:
* Enable Logging Flag. This flag ensures that all database
modifications are logged and available for later use by the
recovery system, if necessary. When you enable the database for
logging, DBUTIL checks whether a database backup copy has been
stored with DBSTORE. If not, DBUTIL issues a warning message.
Because the database is stored after logging has been first
enabled, the DBUTIL warning message can be interpreted as a prompt
to store the database. If you plan to use roll-forward recovery,
use the following command to enable logging (implies roll-forward
logging):
>>ENABLE database name FOR LOGGING
WARNING: database modified and not DBSTOREd
If you plan to use roll-back recovery, enabling the roll-back flag
will automatically enable the logging flag.
Remember that, if logging to disk, the log identifier must be
created before the preceding command can execute successfully
(refer to "Step 5--Creating the Log Identifier").
* Enable Rollback Flag. If you plan to use roll-back recovery, use
the following command to enable roll-back recovery:
>>ENABLE database name FOR ROLLBACK
After the logid is set and the log file has been built, the
>>ENABLE command for roll-back recovery shown above automatically
enables logging for the database. However, the >>DISABLE database
name FOR ROLLBACK command will not automatically disable logging.
* Enable MUSTRECOVER Flag. When the MUSTRECOVER flag is enabled,
only readers can access the database after a system failure until
the database is recovered. This prevents modifications to a
potentially inconsistent database.
>>ENABLE database name FOR MUSTRECOVER
After the logid is set and the log file has been built, logging is
automatically enabled when the ENABLE command is used to enable
MUSTRECOVER. However, the >>DISABLE database name FOR MUSTRECOVER
command will not automatically disable logging.
* Disable Access Flag. By disabling the database for user access,
you ensure that modifications cannot be made to the database. Any
attempt to open the database with a call to DBOPEN returns an
error message. Access to the database should be disabled before
storing the backup copy, so that in the event of a system failure
the database is restored with access disabled. This prevents
users from opening the database and making modifications before
recovery is executed. Disabling access to the database is also
useful as a general security measure to prevent database access at
unauthorized times. The DBUTIL command for disabling access is
shown below:
>>DISABLE database name FOR ACCESS
* Enable Recovery Flag. Enabling the database for recovery allows
the TurboIMAGE/XL recovery system to access the database. The
database is stored with recovery enabled so that when it is
restored, it is ready for recovery. The DBUTIL command for
enabling roll-forward recovery is shown below:
>>ENABLE database name FOR RECOVERY
The database can be stored with DBSTORE after the preceding flags have
been set in the database. Logging status can be checked by referring to
the procedure in "Logging Status" later in this chapter.
Step 8--Making a Database Backup Copy
This step is required for roll-forward recovery. It is recommended (for
protection in the event of a hard disk failure), but not required, for
roll-back recovery.
To make a database backup copy, you use the DBSTORE TurboIMAGE/XL utility
to store a copy of the database with flags (access disabled, recovery
enabled, logging enabled) set as specified in step 7. Because the
correspondence between log files and database backup copies is crucial,
DBSTORE sets a DBSTORE flag in the database root file, along with a time
stamp designating the date and time of the DBSTORE operation, before
storing the database.
NOTE The DBSTORE flag is cleared by the first modification to the
database (DBPUT, DBDELETE, or DBUPDATE) indicating that the
database no longer corresponds to the stored copy.
Before logging is enabled, DBUTIL checks the DBSTORE flag to ensure that
the working database is the same as the database backup copy. For
example, suppose a database is stored and some modifications to the
database are made before logging is enabled. If you then try to enable
logging, DBUTIL, determining that the DBSTORE flag has been cleared,
prints a message indicating that the present state of the (modified)
database does not correspond to the stored version. If the message is
ignored, the resulting log file will not contain all of the transactions
that actually occurred against the working database. Consequently, a
recovery using the stored copy and the incomplete log file may fail or
yield erroneous results.
The following is an example of how to run DBSTORE:
:RUN DBSTORE.PUB.SYS
WHICH DATABASE? ORDERS
DATABASE STORED
END OF PROGRAM
When multiple databases and files are involved, use the MPE/iX STORE
command to collectively copy them to tape and, if necessary, collectively
restore them by using the MPE/iX RESTORE command; you need to have either
SM or OP capability to do this and should have an understanding of the
standard rules and features associated with STORE and RESTORE. Note that
when using the STORE command neither the DBSTORE flag nor the time stamp
(signifying the date and time the backup copy was made) is set in the
database root file. For additional MPE/iX command information, refer to
the MPE/iX Commands Reference Manual.
NOTE If you plan to restore the TurboIMAGE/XL database on an MPE V
system, use the TRANSPORT option of the DBSTORE or STORE command.
Chapter 8 contains detailed information about the DBSTORE command.
Refer to the MPE/iX Commands Reference Manual for more information
about STORE options.