HP 3000 Manuals HP 3000 Manuals
Utility Program Operation (contd) Error Messages (contd) >PRINT Prints the names of databases specified for recovery (DBTABLE option) or recovery files specified (FILETABLE option). Can be used as a check before actually initiating recovery with the >RUN command.
NOTE The >PRINT DBTABLE command produces the DATABASE STATISTICS table, but does not include statistics. The table, along with statistics, is automatically displayed by every execution of the recovery system. If you need this table, along with statistics, without actually performing the recovery, use the >CONTROL STATS command instead.
Syntax >PRINT {DBTABLE } {FILETABLE} Parameters DBTABLE displays names of databases specified for recovery FILETABLE displays file references, user references, rmodes and fmodes specified in >FILE commands. Example >PRINT DBTABLE **************************************************************** * DATABASE STATISTICS * * * * NAME GROUP ACCOUNT OPENS TRANS PUTS DELETES UPDATES * * ---- ----- ------- ----- ----- ---- ------- ------- * * ORDERS TST MKG 0 0 0 0 0 * **************************************************************** Text Reference Chapter 7 >RECOVER Used to designate the name of a database to be roll-forward recovered; opens database root file, validates logid and password with MPE/iX, and checks the DBSTORE flag. Multiple databases can be roll-forward recovered concurrently if they have all logged to the same log file by entering the >RECOVER command once for each database or as follows: >RECOVER database name, database name Syntax >RECOVER database name[/maint word][.group[.account]] Parameters database name is the name of the TurboIMAGE/XL database to be recovered. maint word is the maintenance word defined by the database creator. This word must be supplied by anyone other than the database creator. group is the group where the database(s) resides. account is the account where the database(s) resides. Discussion If the >RECOVER command is accepted, the following message is returned: DATABASE database name LAST DBSTORED day, date, time The following conditions must be satisfied before the >RECOVER command is accepted: 1. The database must be accessible to the user (database administrator) running DBRECOV. This user must either be the creator of the database or know the maintenance word. If the database resides in a group or account different from the user's logon, the MPE/iX file security must permit the user read and write access to the database files. 2. The database must be enabled for recovery. 3. The log identifier characteristics (name, password, log file name and device type) must not have been altered since the log file was generated. This restriction applies to MPE/iX log commands as well as those provided for TurboIMAGE/XL by DBUTIL. This is necessary because the MPE/iX log identifier is used by TurboIMAGE/XL to obtain the name and device type of the log file. The >RECOVER command will not be accepted if the logid is unknown to MPE/iX. However, if the logid is known to MPE/iX but specifies the wrong log file, this condition is not detected at this time and >RECOVER will be accepted. DBRECOV will generate erroneous data in the database if the database is recovered with the wrong log file. 4. The DBSTORE flag must be set, indicating that the database has not been modified between restoration and roll-forward recovery. This check can be overridden by the NOSTORE option of the >CONTROL command. 5. No other users can be accessing the database when >RECOVER is called. Exception: When the MODE4 option of the >CONTROL command is specified, the database can be concurrently accessed in mode 6 (read only). The >RECOVER command itself does not initiate recovery, but makes several preparatory checks. The recovery system is actually initiated by the >RUN command. Example >RECOVER ORDERS, RETAIL DATABASE ORDERS LAST DBSTORED THURS, SEP 7, 1989, 6:30 PM DATABASE RETAIL LAST DBSTORED MON, SEP 11, 1989, 10:00 PM ORDERS and RETAIL are database names. Text Reference Chapter 7 >ROLLBACK Rolls out any incomplete transactions following a system crash. Multiple databases can be roll-back recovered concurrently by entering the command as follows: >ROLLBACK dbname, dbname Syntax >ROLLBACK dbname[/maint word][.group[.account]] Parameters database name is the name of individual database(s) to be rolled-back. maint word is the maintenance word defined by the database creator. This word must be supplied by anyone other than the database creator. group is the group where the database(s) resides. account is the account where the database(s) resides. Discussion If the >ROLLBACK command is accepted, the following message is returned: DATABASE database name LAST USED day, date, time The following conditions must be satisfied before the >ROLLBACK command is accepted: 1. The database must be accessible to the user (database administrator) running DBRECOV. This user must either be the creator of the database or know the maintenance word. If the database resides in a group or account different from the user's on, the MPE/iX file security must permit the user read and write access to the database files. 2. The database must have been enabled for roll-back recovery. 3. The log identifier characteristics (name, password, log file name and device type) must not have been altered since the log file was generated. This restriction applies to MPE/iX log commands as well as those provided by TurboIMAGE/XL by DBUTIL. This is necessary because the MPE/iX log identifier is used by TurboIMAGE/XL to obtain the name and device of the log file. 4. When roll-back is enabled, DBUTIL sets a roll-back flag to indicate that roll-back is enabled for the database. The roll-back time stamp is updated when the database is first opened and is logged to the log file. Roll-back recovery then uses the time stamp during recovery to verify the correct log file for each database. 5. No other users can be accessing the database when >ROLLBACK is called. The database can be concurrently accessed by users when the >CONTROL command is specified with the MODE4 option. The >ROLLBACK command itself does not initiate recovery, but makes several preparatory checks. The recovery system is actually initiated by the >RUN command. The following commands are used with >ROLLBACK: >FILE >PRINT >CONTROL The >FILE command optional parameter rmode is not used with >ROLLBACK. The following >CONTROL options are not applicable with >ROLLBACK: STAMP, NOSTAMP, STORE, NOSTORE, STOPTIME Example >CONTROL NOSTATS >ROLLBACK ORDERS DATABASE ORDERS LAST USED THURS, SEP 7, 1989, 6:00 PM >RUN ORDERS is the database name. Text Reference Chapter 7 >RUN Initiates recovery-process. The recovery system opens the log file and validates the log identifier before roll-forward recovery or roll-back recovery begins. Syntax >RUN Discussion For recovery to succeed, the log file must be accessible to the database administrator. This means that the database administrator must either be the creator of the log identifier used to create the log file, or know the maintenance word and have system manager (SM) or operator (OP) capability. If the database administrator does not have system manager capability, and if the log file resides on disk in a group and account different from logon, then the administrator must have read access to the log file according to MPE/iX file security. File equations are permitted. However, the fully qualified file name of the expected log file must be specified. If the log file resides on tape, the database administrator must know the volume identifier, so that the operator can respond to the log file tape mount request. If recovery succeeds, tabulated information is displayed and the program is terminated. A table of process statistics includes the number of DBPUT, DBDELETE, and DBUPDATE log records processed and the total transactions for each process. When using roll-forward recovery, an asterisk (*) may appear next to any process indicating that either a DBCLOSE record is missing or some transactions may not have been recovered. Therefore, no asterisk for a process in the table of process statistics indicates that all transactions were recovered. The same table information is displayed when using roll-back recovery; however, there is a slight difference. The database table will list all incomplete transactions or DBPUT, DBDELETE, and DBUPDATE log records that were "rolled-out." An asterisk (*) will appear next to these processes. A table of database statistics includes the same information totaled for each database. A logging system table includes the log identifier, log file information, and recovery file information if this facility is used. Refer to "Recovery Tables" in chapter 7 for more information on Process, Database, Logging and Recovery Tables. Example 1 Roll-forward recovery of database ORDERS. :RUN DBRECOV.PUB.SYS >RECOVER ORDERS DATABASE ORDERS LAST DBSTORED FRI, SEP 22, 1989, 4:00 PM >RUN Example 2 Roll-back recovery of database ORDERS. :RUN DBRECOV.PUB.SYS >ROLLBACK ORDERS DATABASE ORDERS LAST USED THURS, SEP 21, 1989, 6:00 PM >RUN DBRESTOR Copies a database to disk from the backup volume(s) created by the DBSTORE program or by the MPE/iX STORE command. Operation 1 [:FILE DBRESTOR [=filename][;DEV=device]] [[;REC=recsize][; {BUFNOBUF}] ] 2 :RUN DBRESTOR.PUB.SYS : 3 WHICH DATABASE? database name [/maint word] 4 DATABASE RESTORED END OF PROGRAM Parameters filename is a name (up to 8 characters) that replaces DBRESTOR in the mount prompt at the operator's console. device is the device class name of the device from which the database is to be recorded. recsize is the record size of the record to be restored. recsize must be at least as large as the record written to the device to avoid losing data. database name is the name of a TurboIMAGE/XL database root file to be restored. maint word is the maintenance word defined by the database creator. This word must be supplied by anyone other than the database creator. Operation Discussion 1 An optional file equation that specifies the device class name for the device from which the database is to be restored, the record size of the records to be restored, and whether the records are buffered or not. The default device class is TAPE. 2 Initiates execution of the DBRESTOR program in the PUB group of the SYS account. 3 In session mode, DBRESTOR prompts for the database name and maintenance word. In job mode, the database name and maintenance word, if any, must be in the record immediately following the RUN command. 4 After DBRESTOR has created the root file and data sets and restored the data to these files, it prints a confirmation message. Console Messages After you supply the database name and DBRESTOR opens the file specified by filename, a message is displayed on the system console. A tape must be mounted on the appropriate unit and identified through an operator reply. Refer to Volume Management Reference Manual for instructions about console interaction. If the database is on more than one volume, another message is displayed on the system console. The operator must mount the next volume in the sequence. If the volume that is mounted is not the correct format, the operator is notified through a console message. If the correct volume is available, the incorrect one should be removed and the correct one mounted. The operator must enter a reply on the console. Example :JOB MRG.ACCOUNTA Initiate job. :RUN DBRESTOR.PUB.SYS Initiate DBRESTOR. ORDERS/SELL Specify database name and maintenance word. :EOJ Terminate job. After creating the files and restoring the file contents, DBRESTOR prints the following message on $STDLIST: DATABASE RESTORED [REV BEG]
NOTE If there is already a copy of the database on disc, it must be purged using DBUTIL before running DBRESTOR.
[REV END] DBSTORE Stores the database root file and all data sets to a tape in a format compatible with backup files created by the MPE STORE and SYSGEN commands. DBSTORE differs from these commands in that it handles only TurboIMAGE/XL databases. Operation 1 [:FILE DBSTORE[=filename] [;DEV=device][;REC=recsize] [;{BUF }]] [ [ {NOBUF}]] 2 :RUN DBSTORE.PUB.SYS [;INFO="MPE STORE options"] : 3 WHICH DATABASE? database name [/maint word] 4 DATABASE STORED END OF PROGRAM If you try to store a database that needs recovery, DBSTORE will do the recovery before storing the database. Before copying the files, DBSTORE gains semiexclusive access to the referenced database; that is, DBSTORE determines that the only other database activity consists of other users executing DBSTORE or application programs that open the database in mode 6 or 8. If DBSTORE cannot gain semiexclusive access, it terminates and prints the following message: DATABASE IN USE You must be the database creator or provide the maintenance word to use DBSTORE. Parameters filename is the name (up to 8 characters) that replaces DBSTORE in the mount request at the operator's console. device is the device class name of the device on which the data entries are to be stored. recsize is the record size of the record to be written to the device; must be a multiple of 512 bytes and less than the configured record size for the device. database name is the name of a TurboIMAGE/XL database to be stored. maint word is the maintenance word defined by the database creator. This word must be supplied by anyone other than the database creator. INFO= is used for the parameters that can be passed to the MPE STORE/RESTORE process. For example, the TRANSPORT parameter (INFO="TRANSPORT") allows you to migrate files from MPE/iX to MPE V with the MPE/iX STORE command. Operation Discussion 1 The optional file equation that specifies the device class name for the device on which the database is to be stored, the record size of the records written to the device, and whether records are to be buffered. The default device class is TAPE. 2 Initiates execution of the DBSTORE program in the PUB group of the SYS account. The MPE STORE options are parameters that can be passed to the STORE/RESTORE process. For example, the TRANSPORT option is used when moving a TurboIMAGE/XL database to MPE V. ____________________________________________________________________ NOTE The database may be too large to move to MPE V because, with the expanded file size available on MPE/iX, data sets can exceed the MPE V file size limit. If the database contains a data set larger than the MPE V limit, an MPE error is displayed. ____________________________________________________________________ 3 In session mode, DBSTORE prompts for the database name and maintenance word. In job mode, the database name and maintenance word, if any, must be in the record immediately following the RUN command. 4 After DBSTORE has copied the root file and all data sets, it prints a message to signal completion. Logging DBSTORE updates a time stamp and store flag in the database root file before storing the database. The time stamp designates the date and time of the DBSTORE operation, and is used by DBRECOV to help identify the correspondence between log files and backup databases. The store flag is set by DBSTORE to indicate that the database has been stored; this flag is cleared (reset) when the first modification to the database occurs by a call to DBPUT, DBUPDATE, or DBDELETE. Both DBRECOV and DBUTIL interrogate the status of the DBSTORE flag. DBRECOV (roll-forward) checks this flag to ensure that no one has modified the backup database prior to recovery. DBUTIL checks this flag whenever logging and recovery is enabled, because a valid database backup copy must exist for roll-forward recovery to be possible. If the store flag is not set when a DBUTIL user enables the logging option a warning is printed: WARNING: database modified and not DBSTORED This warning does not necessarily indicate that a valid backup does not exist, because either an MPE SYSGEN or STORE command could have been used instead of DBSTORE. Because neither SYSGEN or STORE update the database time stamp and store flag, the protection afforded by these mechanisms is not available if this form of backup is selected. For this reason, it is highly recommended to use DBSTORE as the backup facility when logging. See chapter 7 for further discussion of logging and recovery. If the mirror database maintenance method is being used, storing the database on the secondary system can be done differently than using the DBSTORE process. When using DBRECOV STOP-RESTART recovery on the database, storing the database, RESTART file, and the log files that were processed since the last successful RESTART can be done with an MPE STORE command. DBRECOV STOP-RESTART places a time stamp in the RESTART file and in the database to identify which RESTART file to apply to which database. If naming conventions have been followed, an MPE STORE @ command can be used to store all the necessary files and database(s). If DBSTORE is used, the user must remember to use an MPE STORE command to store the RESTART file and the log files. For more information on DBRECOV STOP-RESTART, refer to chapter 7 "The Mirror Database" and "Storing the Databases." Console Messages After you supply the database name and DBSTORE opens the output file, a message is displayed on the system console. A tape must be mounted on the appropriate unit and identified through an operator reply. Refer to the Volume Management Reference Manual for instructions about console interaction. If more than one volume is required to store the database, a request is displayed on the console for the next one. The next tape must be mounted and the unit readied. The volume that has been removed should be properly labeled with the database name and volume number. Example :JOB MGR.ACCOUNTA Initiate job. :RUN DBSTORE.PUB.SYS Initiate DBSTORE program. ORDERS/SELL Supply database name and maintenance word. :EOJ Terminate job. After copying the ORDERS root file and all data sets, DBSTORE prints the following message on $STDLIST: DATABASE STORED [REV BEG]
CAUTION If you need to cancel a DBSTORE, reply zero to the tape request: :REPLY pin#,0 Do not use Break and "ABORT" to abort the process when the tape mount is requested. When DBSTORE is aborted by using Break and "ABORT," the date-time stamp and store flag in the root file are updated even though the database was not stored.
[REV END] DBUNLOAD Copies the data entries from each data set to specially formatted tape volumes. Operation 1 [:FILE DBUNLOAD[=filename] [;DEV=device] ] 2 :RUN DBUNLOAD.PUB.SYS [,CHAINED] [,SERIAL ] : 3 WHICH DATA BASE? database name [/maint word] : 4 DATA SET m: x ENTRIES EXPECTED, x ENTRIES PROCESSED 5 END OF VOLUME n, y WRITE ERRORS RECOVERED SAVE VOLUME ON LOGICAL DEVICE z AS n 6 DATABASE UNLOADED END OF PROGRAM (Refer to "Operation Discussion" later in this section.) Parameters filename is the name (up to 8 characters) that replaces DBUNLOAD in the mount prompt at the operator's console. If you want information about your data set chains without actually performing a DBUNLOAD, supply $NULL as the filename. This causes a simulated unloading of the database, preventing the need to mount a tape. device is the device class name of the device to which the data entries are to be copied. database name is the name of the TurboIMAGE/XL database to be unloaded. maint word is the maintenance word defined by the database creator. This word must be supplied by anyone other than the database creator. Message Variables m is the number of data sets in the database. x is the number of entries (expected) and the number of entries processed or copied from the specified data set. n is the number of the volume. y is the number of write errors from which DBUNLOAD has successfully recovered. z is the logical device number of the unit. DBUNLOAD is necessary if you want to modify the database structure to, for example, increase the capacity of a data set. To increase a capacity, 1. Unload the entries. 2. Purge the database. 3. Change the schema and create a new root file. 4. Execute the DBUTIL >>CREATE command. 5. Reload the data entries from the volumes created by DBUNLOAD. The data sets are unloaded in the order that they were defined in the original schema. No data set names are recorded on the backup volume(s); entries are merely associated with the corresponding data set from which they are read. DBUNLOAD calls the DBGET procedure to read each entry from each set of the database and, to read the complete entry, uses a list parameter of an at-sign followed by a semicolon (@;). Values for data items appear in each entry in the same order as the items were mentioned in the data set definition in the schema. The language ID is copied along with the data of the database. DBUNLOAD requires exclusive access to the database. If the database is already open by any other process, DBUNLOAD prints the message: DATABASE IN USE and prompts again for a database name. DBUNLOAD operates in either serial or chained mode as explained below. The mode is determined by the entry point specified with the RUN command; for example: :RUN DBUNLOAD.PUB.SYS,CHAINED The default entry, if none is specified, is chained. * In serial mode, DBUNLOAD copies the data entries serially in record number order. "Stand-alone" detail data sets, those which are not tied to any master data sets through specified search item paths, are always unloaded serially. * In chained mode, DBUNLOAD copies all of the detail entries with the same primary path search item value to contiguous locations on the backup file. The ordering of the search item values from the primary path is based on the physical order of the matching value in the associated master data set. Figure 8-1 (shown at the end of this section on DBUNLOAD) illustrates the method for unloading a data set in chained mode. After the database is reloaded, chained access along the primary path is more efficient. Broken Chains If a chained DBUNLOAD encounters a broken chain, it will unload all entries in the chain down to, but not including the break. It will then go to the end of the chain and follow the chain backward to the break, then unload the remaining records of the chain. In some instances, this will save all entries in the chain. In any case, the order of the entries is preserved. Information about each broken chain in a data set is printed before the end-of-the-data-set summary (see statement 4 under "Operation Discussion" in this section).