![]() |
![]() |
|
|
![]() |
![]() |
ALLBASE/SQL Database Administration Guide: HP 9000 Computer Systems > Chapter 6 Backup and Recovery![]() Setting up a Wrapper DBEnvironment |
|
Wrapper DBEnvironment functionality is used to recover the audit information in the log files orphaned when you cannot connect to a DBEnvironment. Wrapping log files means associating the files with a DBEnvironment. After a DBEnvironment becomes inaccessible, its log files are not associated with any DBEnvironment. These orphaned log files are then also inaccessible. You can try to recover the audit information in the log files with the Audit Tool (the Audit Tool is described later in this manual). Audit information allows you to group database information into partitions for processing analyses. Access to wrapped log files avoids having a gap in the ongoing record of audit information. The use of archive logging facilitates wrapper DBEnvironment use, but nonarchive logging does not prevent use of wrapper DBEnvironments.
The following list summarizes the tasks that must be performed to create a wrapper DBEnvironment:
These tasks are described in the following sections. The first step in setting up a wrapper DBEnvironment is to select the names of log files marked Useable. Only the log files themselves will be wrapped, not the DBECon file. However, log file status information is contained in the DBECon file, not in the log files. Because the DBECon file will not be wrapped, you must manually determine which log files are valid and usable and enter this information when prompted by the SQLUtil WRAPDBE command in the last step. If the DBECon file still exists, the SQLUtil SHOWLOG command can be used to display the log files associated with the inaccessible DBEnvironment. (Refer to the section "Selecting Log Files when the DBECon File is Inaccessible" for guidelines on selecting log files when the DBECon file is unavailable.) The SHOWLOG command has two modes: one that connects to the DBEnvironment and one that does not. Use the mode that does not connect to the DBEnvironment because connecting to the DBEnvironment may fail. No authority is needed for the SHOWLOG command. For single logging, all log file names are selected. Suppose that the names for PartsLog1a, PartsLog 2A, and PartsLog3A are as follows:
The sequence that the log files are entered is not important to the SQLUtil WRAPDBE command. When all log files have been entered, the WRAPDBE command issues a warning if a log file is missing in the sequence even though WRAPDBE still allows the DBEnvironment to be converted to a wrapper DBEnvironment. If a log file in the sequence has been purged, you will only be able to retrieve audit log records as far back in history as the beginning of a log file with a log sequence number greater than the purged log file. For example, if PartsLog2a was missing, you would only be able to retrieve audit log records from PartsLog3a. You would not be able to retrieve PartsLog1a. Assume that a DBEnvironment using dual logs has a log file configuration shown in Table 6-2 “Example Log File Names and Sequence Numbers” below: Table 6-2 Example Log File Names and Sequence Numbers
During processing, an error occurred on PartsLog2a and the log file was marked Not Useable. Since PartsLog2b was still available and considered to be a valid log file, ALLBASE/SQL logging to PartsLog2a was discontinued and PartsLog2b became the only log. Therefore, you would want to select PartsLog2b. A message appears on the console when the switch takes place. The message is also written to the console file which an operator can read later. This switch allows users to continue accessing the DBEnvironment. The following example shows a sample SHOWLOG command display for a DBEnvironment with dual logging:
As shown, PRTSLG2A has a log file status of Not Useable, indicating that the log file should not be used in the wrapper DBEnvironment. PRTSLG2B should be used instead. If single logs are being used, you are safe in using the list of log files defined when the inaccessible DBEnvironment was defined. (Such a list should be made at the time of DBEnvironment creation.) This is considered safe because when a log file becomes unusable with no backup (or dual log) to switch to, work is not allowed on the DBEnvironment and the DBEnvironment will stop processing (but will not have become inaccessible). However, if dual logs were used, check the console file to see which log files have been marked Not Useable. The safest log files to use are those named for Second Log File. One criterion for making a decision is to check the modification timestamp for the two files with the operating system ls -l command (HP-UX) or listf, logfilename, 3 command for MPE/iX. If one of the files has a considerably earlier timestamp, the system may have automatically switched to the Second Log File in the past. Therefore, the First Log File would be incomplete and logging would have continued on the Second Log File. (To avoid this uncertainty in the future, you can issue an occasional SHOWLOG command while the DBEnvironment is running to see whether a log file has a Not Useable status. A console message is also issued and written to the console file when a log file becomes unusable; you can go back and check the console file later. This at least provides a reference point for later decisions as to which files are usable in the event of a hard crash.) The next step is to create a DBEnvironment that will be converted to a wrapper DBEnvironment. Creating this new DBEnvironment is accomplished with the START DBE NEW statement. The DBEnvironment should be created in the subdirectory (HP-UX) or group (MPE/iX) where the log files reside. The maximum number of transactions should be set to the same value that was allowed on the original DBEnvironment. If unknown, this value can be obtained from the DBECon File with the SQLUtil SHOWDBE command if the DBECon file still exists. Otherwise, you must restore the database before issuing the SHOWDBE command. Any file names specified in the START DBE NEW command should not be the same as the log file names to be wrapped. Since no updates will be allowed on the wrapper DBEnvironment after it has been converted, options such as the number of data buffer pages and log buffer pages are irrelevant; you can use the default values for these options. However, the DBEnvironment must be created with the AUDIT NAME, DEFAULT PARTITION, MAXPARTITIONS, and DATA AUDIT ELEMENTS (and COMMENT PARTITION, if present) the same as in the inaccessible DBEnvironment. Audit parameters are shaded in the example below. Since this database is used only to retrieve audit log records with the Audit Tool, most DDL statements are also not needed. Therefore, a DBEFile0 larger than the default size is not required. The following example shows such a DBEnvironment:
The final step actually converts the created DBEnvironment to a wrapper DBEnvironment, thus associating it with the set of log files from the inaccessible DBEnvironment. The SQLUtil WRAPDBE command is used to perform the conversion. The SQLUtil WRAPDBE command must be used on log files that are inactive. If the WRAPDBE command is used on log files still associated with a DBEnvironment, it is possible that another user may be able to connect to the database (even though it had been thought to be inaccessible) and do work that would generate log records while the log files are associated with the wrapper DBEnvironment. You must be a superuser (HP-UX) or system administrator (MPE/iX) or DBECreator of the original inaccessible DBEnvironment to wrap the created DBEnvironment around the log files. An example of using this command is shown below:
The Maintenance Word should also be that of the DBEnvironment created in the third step. The Wrapper Mode has only one option, log, at this time. If a carriage return is entered, Wrapper Mode defaults to log. When entering log file names, SQLUtil continues prompting for the next log file name until you enter a carriage return. The maximum number of log file names that can be entered is 34. Though the log file names can be entered in any order, the complete list should constitute a correct sequence. The final prompt, Convert to Wrapper DBEnvironment (y/n), allows you to verify that the DBEnvironment should be converted into a wrapper DBEnvironment. Entering two slashes (//) at any time returns you to the SQLUtil prompt. The WRAPDBE command opens the new DBEnvironment in single user mode to ensure that no one else is currently accessing the DBEnvironment. No updates can be made to the DBEnvironment after it has been converted to a wrapper DBEnvironment but updates can be made before the WRAPDBE command is issued. The WRAPDBE command removes any log files associated with the DBEnvironment before being converted. Only the wrapped log files are associated with the DBEnvironment after it is wrapped around them. After converting the DBEnvironment, the SQLUtil command SHOWDBE displays an additional line as follows to indicate that the DBEnvironment is a wrapper DBEnvironment:
The full display of the SHOWDBE command for a wrapper DBEnvironment is shown at the end of the next section. Assume that the inaccessible DBEnvironment had the following structural information displayed for the SQLUtil SHOWDBE command:
Assume that the following information is displayed by SHOWLOG:
|
![]() |
||
![]() |
![]() |
![]() |
|||||||||
|