HP NonStop RDF System Management Manual for H-Series RVUs (RDF 1.8) HP Part Number: 529826-004 Published: August 2007 Edition: RDF 1.
© Copyright 2007 Hewlett-Packard Development Company, L.P. Legal Notice Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. The information contained herein is subject to change without notice.
Table of Contents About This Document.......................................................................................................27 Supported Release Version Updates (RVUs)........................................................................................27 Intended Audience................................................................................................................................27 New and Changed Information in This Edition...............................................
Shared Access DDL Operations......................................................................................................60 Fast Takeover...................................................................................................................................60 Configurable Software Location......................................................................................................61 EMS Support......................................................................................
Synchronizing Databases With SQLCI Commands...................................................................76 Synchronizing Databases With BACKUP and RESTORE Utilities............................................77 Synchronizing Databases With FUP..........................................................................................78 Synchronizing Partitioned Files.................................................................................................
Extractor Process...................................................................................................................94 Receiver Process....................................................................................................................95 Purger Process.......................................................................................................................96 Updater Processes.........................................................................................
Responding to Operational Failures...................................................................................................124 Communication Line Failures.......................................................................................................125 Processor Failures..........................................................................................................................125 Extractor Failure................................................................................
Switching Disks on Updater UPDATEVOLUMES.............................................................................145 Online Remirroring of Updater SUBVOLUMES................................................................................145 6 Maintaining the Databases......................................................................................147 Understanding Database States..........................................................................................................
NonStop SQL/MP Tables With Partitions................................................................................165 Requirements for Synchronization of Individual Partitions...............................................166 Key-Sequenced Tables.........................................................................................................166 Relative Tables.....................................................................................................................
RDF State Requirement............................................................................................................186 Usage Guidelines......................................................................................................................186 Examples..................................................................................................................................186 EXIT...............................................................................................
Example....................................................................................................................................203 OBEY..............................................................................................................................................203 Where Issued............................................................................................................................203 Security Restrictions..........................................................
Usage Guidelines......................................................................................................................217 SET RDFNET.................................................................................................................................217 Where Issued............................................................................................................................217 Security Restrictions......................................................................
Usage Guidelines......................................................................................................................231 STATUS RDF Command Output Display................................................................................231 RDF Process..............................................................................................................................232 Name................................................................................................................
9 Entering RDFSCAN Commands...............................................................................245 About the EMS Log.............................................................................................................................245 Elements of RDFSCAN Command Descriptions................................................................................245 RDFSCAN Commands....................................................................................................................
EXCLUDE Clauses..............................................................................................................................261 Wildcard Character (*)........................................................................................................................261 Within Subvolume Names.............................................................................................................261 Within Filenames......................................................................
The Effects of Undoing Network Transactions..............................................................................281 Takeover and the RETAINCOUNT Value.....................................................................................283 Network Configurations and Shared Access NonStop SQL/MP DDL Operations............................283 Network Validation and Considerations............................................................................................
Guardian Filename Is Incorrect for Partition.................................................................................305 Consideration for Creating Backup Tables.........................................................................................305 Restoring to a Specific Location..........................................................................................................306 Example.....................................................................................................
SET NETWORK.............................................................................................................................323 SET PURGER.................................................................................................................................323 SET RDF.........................................................................................................................................323 SET RDFNET.......................................................................
Installation...........................................................................................................................................440 Auto Discovery...................................................................................................................................440 Monitoring Specific RDF Environments.............................................................................................440 Adding and Removing RDF Environments.......................................
List of Figures 1-1 1-2 1-3 1-4 1-5 1-6 6-1 6-2 6-3 6-4 6-5 17-1 17-2 17-3 E-1 Basic RDF Configuration...............................................................................................................37 RDF Topologies.............................................................................................................................42 RDF Tasks to Maintain a Copy of a Database...............................................................................45 RDF Subsystem Processes......
List of Tables 1-1 2-1 2-2 3-1 4-1 4-2 4-3 4-4 5-1 5-2 5-3 8-1 8-2 9-1 16-1 D-1 E-1 Audit Information at the Time of a Primary System Failure .......................................................38 RDF Hardware Requirements.......................................................................................................63 Software Requirements.................................................................................................................
List of Examples 1-1 1-2 Reciprocal Replication...................................................................................................................56 Chain Replication..........................................................................................................................
About This Document The Remote Database Facility (RDF) subsystem enables users at a local (primary) system to maintain a current, online copy of their database on one or more remote (backup) systems, protecting stored information from damage that might occur at the primary system. RDF accomplishes this by sending audit-trail information, generated at the primary system by the NonStop Transaction Management Facility (TMF) product, over the network to the backup system.
Table 16-1 (page 295) Added this table to identify ANSI object types and their ANSI name space identifiers. Appendix C (page 335) • Moved the lockstep gateway event messages here from Chapter 15 (page 289). • Updated messages in “RDF Messages” (page 342) for ANSI-name support. • Added new mapfile and maplog-related messages to “RDF Messages” (page 342) and “RDFCOM Messages” (page 389).
• • • • • • • • Chapter 15 (page 289) describes lockstep operation. Chapter 16 (page 295) describes SQL/MX database setup for RDF. Chapter 17 (page 309) describes the Zero Lost Transactions (ZLT) functional capability. Appendix A (page 319) summarizes the syntax of all RDFCOM and RDFSCAN commands. Appendix B (page 329) provides additional information about RDF, including reserved words, default values for configuration parameters, and system file descriptions.
INT[ERRUPTS] A group of items enclosed in brackets is a list from which you can choose one item or none. The items in the list can be arranged either vertically, with aligned brackets on each side of the list, or horizontally, enclosed in a pair of brackets and separated by vertical lines. For example: FC [ num ] [ -num ] [ text ] K [ X | D ] address { } Braces A group of items enclosed in braces is a list from which you are required to choose one item.
If there is no space between two items, spaces are not permitted. In this example, no spaces are permitted between the period and any other items: $process-name.#su-name Line Spacing If the syntax of a command is too long to fit on a single line, each continuation line is indented three spaces and is separated from the preceding line by a blank line. This spacing distinguishes items in a continuation line from items in a vertical list of selections.
Nonitalic Text Nonitalic letters, numbers, and punctuation indicate text that is displayed or returned exactly as shown. For example: Backup Up. Italic Text Italic text indicates variable items whose values are displayed or returned. For example: p-register process-name [ ] Brackets Brackets enclose items that are sometimes, but not always, displayed.
Related Information This manual belongs to the NonStop data management library of manuals. It is the only manual that fully and directly supports RDF. To use this manual effectively, however, you should be familiar with the information for the TMF product described in the following publications: • • • • TMF Introduction, which provides a general overview of TMF concepts and capabilities for business professionals, application designers and programmers, and system managers and administrators.
HP Encourages Your Comments HP encourages your comments concerning this document. We are committed to providing documentation that meets your needs. Send any errors found, suggestions for improvement, or compliments to: pubs.comments@hp.com Include the document title, part number, and any comment, error found, or suggestion for improvement you have concerning this document.
1 Introducing RDF This manual describes the Remote Database Facility (RDF) subsystem as implemented in version 1, update 8 of the HP NonStop RDF/IMP, IMPX, and ZLT independent products. Customers who install RDF 1.8 can use existing RDF configuration scripts provided the scripts are not making use of new functionality.
Integrity NonStop NS-series servers running RDF 1.8. For information about subsystem interoperability as it relates to your particular version of the RDF subsystem, read the software documentation supplied with your RDF software. Before reading further in this manual, you should be familiar with the concepts, terminology, and functions of the NonStop TMF product. You should know about the objects on which TMF operates, such as transactions, audit trails, and audit volumes.
Figure 1-1 Basic RDF Configuration In Figure 1-1, there are 20 audited volumes on the primary system ($D1 through $D20). Only volumes $D1 through $D15, however, are configured for RDF protection. Audit information for volumes $D1 through $D10 and $D16 through $D20 is sent to the master audit trail (MAT). The RDF master extractor process reads the MAT and sends audit information associated with volumes $D1 through $D10 to the RDF master receiver process on the backup system.
An unplanned outage typically occurs as the result of a sudden disaster that prevents the database on the primary system from being used. The classic purpose of RDF is to make rapid recovery from an unplanned outage possible by maintaining a replicated database on a backup system. When the primary system is unexpectedly affected by a disaster, you can shift operations to the replicated database on the backup system after having the RDF updaters bring the backup database to a consistent state.
101, a single update was logged in the MAT and sent to the backup system, but the primary system was brought down before the transaction was completed. When the command for a takeover is issued, the updater processes treat all transactions whose outcomes are not known as aborted transactions. In this scenario, only the changes related to transactions known with certainty to have been committed on the primary system are left in the backup database.
An alternative, and preferred, approach is to configure a takeover trigger to send a message to the requester routing program. Of course, what makes this method work is ensuring that no work is ever routed to the backup system until the takeover has completed. Planned Outages RDF can be very useful when a planned shutdown of the primary system is necessary. For example, you might need to bring the system down to install new hardware or to perform a system software upgrade.
— your applications to resume, with full RDF protection, within minutes after the loss of your primary system, provided the two backup systems are not too far behind. Loopback configuration—where the primary and backup systems are the same system. This has no value from a disaster protection standpoint, but can be useful for testing purposes. Data from a set of volumes can be replicated to a different set of volumes on the same node.
Figure 1-2 RDF Topologies • • 42 Master and auxiliary audit-trail protection RDF can protect all tables and files that are being audited by TMF, whether they are associated with the Master Audit Trail (MAT) or an auxiliary audit trail. Subvolume and file replication In addition to volume replication, the RDF/IMP and IMPX products support replication of selected subvolumes and files.
• Economical processing RDF conserves resources at both sites. The extractor typically uses 1% of the resources used by the application on the primary and 4% of the Expand resources. On the backup system the cost of an updater process replicating an update operation is typically 15-25% of the original cost to do the operation on the primary system. On the primary system RDF uses just one process (the extractor) per audit trail to read and transmit audit information to the backup system.
You can peruse messages in the EMS log on your terminal screen by using Viewpoint or whatever other tool you normally use for monitoring $0. When you do that, you are dealing with the entire EMS log (not just RDF messages). To isolate RDF messages from the rest of the EMS log, you can use the supplied EMS filter RDFFLTO with an EMS printing distributor to produce an intermediate entry-sequenced file that you then can scan using the RDFSCAN utility.
Figure 1-3 RDF Tasks to Maintain a Copy of a Database RDF Processes To accomplish its four major tasks, RDF runs different processes on the primary system and the backup system. These processes (the monitor and extractor on the primary system and the receiver, updaters, and purger on the backup system) divide these tasks as summarized in the following pages. The relationship of these processes to one another is illustrated in Figure 1-4.
Figure 1-4 RDF Subsystem Processes Primary System Processes On the primary system: • • 46 The monitor process coordinates subsystem starts and stops, some messages, and NonStop SQL/MP and NonStop SQL/MX DDL operations using the WITH SHARED ACCESS option on protected volumes, and monitors the other RDF processes.
Backup System Processes On the backup system: • • • There is one receiver process for each configured extractor process. A receiver accepts the audit records from its extractor, sorts them, and then writes them to the appropriate RDF image trail. There is one updater process for each primary system volume being protected by RDF. Updater processes read image records from their RDF image trails and pass them to the disk process so that the disk process can perform the logical REDO operations.
NOTE: The discussion and figure that follow are both oriented to the extractor associated with the MAT. For information about protecting auxiliary audit trails, see Chapter 13 (page 271).
• • Audit records associated with files protected by RDF For Enscribe files (DDL operations) only, the following file-label modification records: — CREATE — PURGE (if REPICATEPURGE is enabled) — PURGEDATA — ALTER MAXEXTENTS • For NonStop SQL/MP and NonStop SQL/MX files (DDL operations) only, the following file-label modification records: — Stop-RDF-Updater records — TMF shutdown records — File incomplete records — File complete records The extractor filters out all other records and does not send them t
UNPINAUDIT CAUTION: Before deleting an RDF configuration, always issue an UNPINAUDIT command to unpin any audit-trail files that might be pinned by the configuration. If you delete the configuration without first doing so, then you will be unable to unpin the files afterward. If you unpin files, RDF cannot be restarted if the files required by the extractor cannot be made available. When you unpin audit-trail files, be sure that these files are dumped to disk or tape.
Figure 1-6 Receiver Process Operation With sorted image trails, the activity of any one image file typically remains so low that it can be stored on the same disk volumes as the main database with no significant I/O impact.
RDFNET Process The RDFNET process is a process pair that runs only on the primary node of the network master in an RDF network. The RDFNET process creates synchronization information used only during RDF takeover. Updater Processes An updater process is a process pair that runs on the backup system when updating is enabled or during takeover processing. Every volume on the primary system that is protected by RDF has its own updater process on the backup system.
• • • The monitor detects the unexpected termination of any RDF process and sends out abort RDF messages. You perform a NonStop SQL/MP and NonStop SQL/MX DDL operation on the primary system that includes the WITH SHARED ACCESS option. For more information, see “Performing Shared Access DDL Operations” (page 142). A takeover operation completes on the RDF backup system. Audited Database Files All database files on the backup system are audited files.
NOTE: You must be sure that volumes on the primary system containing alternate key files and indexes are protected by RDF. It is not sufficient to protect just the associated data file or table (particularly in the case of alternate keys). Likewise, if primary partitions reside on volumes protected by RDF, you must ensure that the secondary partitions are also configured for protection. File System Errors Involving Data Files File system errors can occur when: • • • A file is created. A file is opened.
No image file in a given image trail can be purged until it is absolutely clear that all updaters configured to the trail will no longer require that file for an UNDO pass during a takeover or stop-update-to-time operation. RDF automatically keeps track of which range of transactions is represented in each image trail file. The purger process can therefore always determine with confidence when a particular image trail file can be purged.
Reciprocal and Chain Replication Example 1-1 Reciprocal Replication System \A System \B RDF Subsystem 1 Primary DB 1 ---------------------------------> Backup DB 1 RDF Subsystem 2 Backup DB 2 <-------------------------------- Primary DB 2 Thus, you have a primary database for RDF subsystem 1 on system \A (primary DB 1) and a primary database for RDF subsystem 2 on system \B (primary DB 2).
when the updater for RDF Subsystem 2 on \A applies this record to Primary DB 1, it thereby backs out the committed update of your application. Additionally, Primary DB 1 and Backup DB 1 are no longer in synch. Even though the updater on \B had its transaction aborted, that updater will re-apply the application update to Backup DB 1. When done, Primary DB no longer has the update, but Backup DB 2 does.
In the preceding examples, each RDF configuration operates entirely independently of the other RDF configuration primaried on the same node; that is, each RDF configuration has its own extractor and monitor process. In this way, line failures affecting one configuration might not necessarily affect the others (depending on the configuration). RDF Control Subvolume The INITIALIZE RDF command includes a control subvolume suffix parameter (SUFFIX char ), where char is an alphanumeric character.
system. To bring the two backup databases into rapid synchronization, you must perform the following steps: 1. 2. 3. Check the EMS event log on both remote systems after the takeover operations have finished, and exam each 735 event. This event lists the MAT position of the last record received by the receiver from its extractor. By comparing this message in each EMS event log, you can easily identify which backup system received the most audit.
Online Database Synchronization With RDF/IMP, IMPX, or ZLT you can synchronize entire databases or selected volumes, files, tables or even partitions while your applications continue to run. For information about this capability, see Chapter 7 (page 155). Online Dumps With RDF/IMP, IMPX, or ZLT, all backup databases are audited by TMF. You can take online dumps of a backup database at any time, thereby minimizing the amount of time necessary to perform any subsequent takeover operation.
Configurable Software Location With RDF, RDF/MP and RDF/MPX, the RDF software always resides in $SYSTEM.RDF. With RDF/IMP or IMPX, however, you can use the following command to designate the volume and subvolume on which you want the RDF software to reside: RDF SOFTWARELOC $volname.subvolname You should place the RDFCOM component on $SYSTEM.SYSTEM, or you must add the new software location to your TACL search-subvolume list. EMS Support RDF/IMP, IMPX, and ZLT all support the Event Management System (EMS).
More specifically, the updates for a transaction on one of the two primary systems might have been successfully transmitted and applied to the associated backup database, but a disaster brought down the other primary system before the updates by the transaction on that system could be sent to its backup database. After executing RDF takeover operations on both backup systems, the data from the network transaction would be present in one backup database but not in the one brought down by the disaster.
2 Preparing the RDF Environment Before RDF can be run on a NonStop system, the system configurations and user applications must meet certain RDF requirements. This chapter explains how to prepare each system for RDF installation and operation, ensuring that all these requirements are met and that you understand the RDF product’s restrictions.
Sizing the RDF configuration is a complex task that is best carried out by HP personnel. Those personnel can assist you in configuring and sizing your RDF environment using tools and utilities designed and developed as part of the RDF Professional Service. Contact your service provider for further details.
1. Enter a FUP INFO command for the current TMF MAT and record the end-of-file (EOF) value; for example: FUP INFO $AUDIT.ZTMFAT.* CODE EOF LAST MODIF OWNER RWEP TYPE REC BLOCK $AUDIT.ZTMFAT AA000003 134 11292672 10:05 -1 GGGG 2. Enter a FUP INFO command for the current MAT 5 minutes later and record the EOF value; for example: FUP INFO $AUDIT.ZTMFAT.* CODE EOF LAST MODIF OWNER RWEP TYPE REC BLOCK $AUDIT.ZTMFAT AA000003 134 11653120 10:10 -1 GGGG 3.
Table 2-2 Software Requirements Software Requirement Files The RDF/IMP, IMPX, and ZLT products protect only files on the primary system that are audited by the TMF subsystem. Auditing The RDF/IMPX and ZLT products support the use of TMF auxiliary audit trails on the primary system (volumes protected by RDF can store audit data in either the MAT or an auxiliary audit trail). The backup database files are audited, and therefore must also reside on TMF data volumes.
TMF Configuration With Dump Process When you configure TMF with audit dump on, that subsystem dumps an audit trail to tape or disk before purging the audit trail. This approach is strongly recommended on the primary system. Audit-trail files are pinned by the RDF extractor and TMF cannot purge pinned files until the extractor has finished processing them. TMF will keep these files pinned on behalf of the RDF extractor even if you stop RDF. Audit-trail pinning is lost if you stop TMF.
and index files, for example). For each audited data file that resides on the primary protected volume, a corresponding audited file must exist on a volume configured for an updater process on the backup system. The volume name on the backup can differ from that on the primary. For example, if volume $B on the backup system corresponds to volume $A on the primary system, then all files protected by RDF on volume $A must be present (and in the same subvolumes) on $B.
protected by RDF. The partitions of a file protected by RDF can reside on separate systems, and all of the systems should be protected by an RDF network. These are not absolute requirements, but if you lose your primary system and must takeover on your backup system, you might not have access to the data that is not protected by RDF.
File-label modifications in Enscribe are similar to DDL operations in NonStop SQL/MP and NonStop SQL/MX in that the modifications do not manipulate the file itself. Instead, file-label modifications alter attributes of the file, such as the file code, the security, the extent size, and the audit setting.
NOTE: A single updater process can only work on 500 files at any time. If you have a virtual disk that has a number of physical disks in its pool, and if the number of files that need to be updated by the updater assigned to that virtual disk exceeds 500, the updater will close some files in order to work on files it does not already have open. If this updater must regularly work on more than 500 files, the performance of the updater will be impacted.
NOTE: A single updater process only works on 500 files at any time. If you have a virtual disk that has many physical disks in its pool, and if the number of files that need to be updated by the updater assigned to that virtual disk exceeds 500, the updater will close some files in order to work on files it does not already have open. If this updater must regularly work on more than 500 files, the performance of the updater is impacted.
3 Installing and Configuring RDF After preparing your system configurations and user applications to meet RDF requirements, you are ready to install and configure RDF. This chapter, which is intended for system managers, system analysts, and database administrators, describes how to do these tasks.
Separating NonStop SQL/MP or NonStop SQL/MX Tables It is recommended that you avoid registering NonStop SQL/MP or NonStop SQL/MX tables protected by RDF in the same catalogs as tables that are not protected by RDF. Separating protected tables from unprotected ones simplifies the comparison of primary system catalogs with backup system catalogs. Compressing Audit Data for Tables and Files Although not required by RDF, using the AUDITCOMPRESS file attribute will enhance RDF performance.
• • All views and indexes dependent on base tables protected by RDF All program files for applications that use any base tables protected by RDF if you want the applications to run at the backup site after an RDF takeover operation The backup system should also have copies of the following files in case an RDF takeover operation is necessary: • • OBEY command files and TACL scripts containing NonStop SQL/MP or NonStop SQL/MX DDL commands that define the database SQLCI or MXCI report definitions To make
1. 2. 3. Place the database creation commands in either an EDIT (command) file or TACL macro or routine. See the TACL Reference Manual for more information. Through the TACL command interpreter, issue an OBEY filename command or run the macro to create the primary database. Copy the command file or TACL macro to the backup system. Now do the following on the backup system: • • Change any system references in the command file or TACL macro from the primary system name to the backup system name.
This command creates an audited table with AUDITCOMPRESS on. 5. Enter CREATE CONSTRAINT commands for any constraints that values in particular columns of the table must satisfy: CREATE CONSTRAINT EMPNUM_CONSTRNT ON =EMPLOYEE CHECK EMPNUM BETWEEN 1 AND 99999; 6. Create the index for the NonStop SQL/MP table on the primary system: CREATE INDEX =EMPLNAME ON =EMPLOYEE( LAST_NAME, FIRST_NAME ); 7.
The next examples of BACKUP and RESTORE commands show how to copy all files from the primary system volumes $DATA01, $DATA02, $DATA03, and $DATA04 to the magnetic tape device named $TAPE and how to restore these files to volumes of the same name on the backup system. You must include the AUDITED parameter in both the BACKUP and RESTORE commands. BACKUP $TAPE,($DATA01.*.*,$DATA02.*.*,$DATA03.*.*, $DATA04.*.*), AUDITED RESTORE $TAPE,($DATA01.*.*,$DATA02.*.*,$DATA03.*.*, $DATA04.*.
Installing RDF The RDF/IMP, IMPX, or ZLT software, and all related documentation, is distributed on three independent product release compact disks (CDs). After loading a CD, double click on the Readme icon for complete instructions on how to install the RDF/IMP, IMPX, or ZLT software. Before installing this product, use NonStop SPR Scout to obtain access to all applicable software product revisions (SPRs).
RDF/ZLT (T0618) Product Components The release CD includes the following components for the RDF/ZLT product: RDF/ZLT The RDF/ZLT enabler module Readme The software documentation file To use the RDF/ZLT product, you must purchase both RDF/IMPX and RDF/ZLT (two separate CDs), install RDF/IMPX, and then install RDF/ZLT.
Table 3-1 RDF Process and Program Security Attributes (continued) Program Name Run Under a Specific Logon ? LICENSE Required for Object File? RDFEXTO YES ++ YES RDFMONO YES ++ YES RDFNETO YES ++ NO RDFPRGO YES ++ YES RDFRCVO YES ++ YES RDFSCAN NO++++ NO RDFSNOOP YES +++ YES RDFUPDO YES ++ YES READLIST NO NO RDIMAGE YES ++ YES + RDFCOM operational commands require super-user group access; however, INFO and STATUS commands can be issued by all users.
• • user ID. RDFSNOOP must be run by a member of the super-user group (user ID 255,nnn) to read the image files. RDFUPDO. RDF updater programs open image files in privileged mode and must be licensed with FUP or by running the RDFINST macro. RDFUPDO also must be able to open database files for protected write access. When querying the backup database files, users should always open the files for shared read access. RDIMAGE.
TMF Subsystem Running Previously If TMF was running on the primary system and you have shut the TMF subsystem down, and if you have started TMF on the backup system and added the RDF updater volumes to the TMF configuration, you need not take any other steps with respect to TMF. Proceed to the next task, described in “Initializing RDF”. Initializing and Configuring RDF After initializing and configuring TMF, you are ready to initialize and configure RDF.
To issue the INITIALIZE RDF command from within an RDFCOM session, enter the following in response to the RDFCOM prompt: ]INITIALIZE RDF, BACKUPSYSTEM \CHICAGO, SUFFIX A, TIMESTAMP 7JAN1999 13:32 If the INITIALIZE RDF commands in this discussion were issued from the primary system \DALLAS, RDF would respond by creating a configuration file in the control subvolume named $SYSTEM.DALLASA.CONFIG.
The NOW clause of the INITTIME parameter causes RDF to be initialized at the current date and time. The NOW clause simplifies initialization and configuration of a reverse RDF environment created in response to a reverse trigger. See the example in “Example” (page 221). Special Considerations When using this form of the INITIALIZE RDF command, there are three special cases which you might encounter.
backup system if your primary system should fail after you stop RDF and delete the previous RDF control files, but before you restart RDF. By using the procedure that follows, you can install and initialize the RDF product without stopping RDF, TMF, or your applications. The procedure is best described by example. Assume that you are running RDF from \RDF04 to \RDF06, and that your control subvolume is RDF04. 1. 2.
You now have parallel sets of extractors shipping audit to parallel sets of receivers for the two operating RDF subsystems, although each subsystem has its own control subvolumes and its own imagetrail subvolumes. 11. When the extractor(s) for RDF04A have caught up, do the following: a. Issue a STOP RDF command for the previous RDF subsystem. b. Issue an UNPINAUDIT command for the previous subsystem. c. Issue a START UPDATE command for the RDF04A subsystem. Wait until all updaters have caught up. d.
After issuing the ADD commands (but before starting RDF), you can change some parameter values in the configuration file by issuing ALTER commands. NOTE: Instead of issuing SET and ADD commands interactively within an RDFCOM session, you can create and execute an RDF configuration command file. The first time you configure RDF, you can either configure it interactively or use the text editor to create a command file.
This parameter should be left at the default value unless you have a very specific reason for lowering it; lowering the UPDATERDELAY value could adversely impact updater performance. UPDATERTXTIME Parameter The UPDATERTXTIME parameter specifies the maximum transaction duration in seconds (from 10 to 300) for all updater processes. The default is 60 seconds. RDF updaters operate in transaction mode.
When set to ON, the particular system is the network master of the RDF network. When this attribute is set to ON, the NETWORK attribute must also be set to ON. UPDATEREXCEPTION Parameter The UPDATEREXCEPTION parameter specifies the manner in which exception files are used. When set to ON (the default value), the updaters log an exception record for each and every audit record they must undo during a takeover.
The userid associated with OWNER must be a valid Guardian userid and must identify an existing user account on the RDF primary and backup systems. The OWNER must also be a member of the super-user group, since that is an existing requirement in RDF for stopping and starting RDF. OWNER is an unalterable value. There is no need to change the value, unless you configured it incorrectly (in which case you must reinitialize RDF with the correct value).
The PROGRAM parameter specifies the name of a Guardian object file that is executed once RDF has reached a particular state, either after a STOP RDF, REVERSE, or TAKEOVER operation. The INFILE parameter specifies the name of an edit file that will be passed as the IN file to the trigger process when it is created. The OUTFILE parameter specifies the name of a file or process that will be passed as the OUT file to the trigger process when it is created.
REMOTECONTROLSUBVOL Parameter The REMOTECONTROLSUBVOL parameter specifies the name of the control subvolume used by the RDF subsystem configured for the specified primary and backup systems. There is no default value. PNETTXVOLUME Parameter The PNETTXVOLUME parameter specifies the name of the volume on the particular primary system where the RDF network master stores an audited network-synchronization file.
process name up to 5 characters, including the $ symbol. However, you cannot specify NonStop SQL/MP reserved process names that are of the form $X*, $Y*, or $Z*, in which * is any alphanumeric string.
]SET EXTRACTOR RTDWARNING 360 ]ADD EXTRACTOR You can issue ADD EXTRACTOR commands only when RDF is stopped. Receiver Process Use SET RECEIVER and ADD RECEIVER commands to configure the following receiver parameters: • • • • • • • ATINDEX CPUS primary-CPU : backup-CPU EXTENTS PRIORITY PROCESS RDFVOLUME SLOWMODE The ATINDEX parameter specifies an integer value identifying a configured TMF audit trail on the primary system. 0 specifies the MAT.
]SET RECEIVER EXTENTS (3000,3000) ]ADD RECEIVER You cannot start RDF until you have configured a master receiver process. You can issue ADD RECEIVER commands only when RDF is stopped. Purger Process Use SET PURGER and ADD PURGER commands to configure the following purger parameters: • • • • • CPUS primary-CPU : backup-CPU PRIORITY PROCESS RETAINCOUNT PURGETIME The CPUS parameter specifies the processors in the backup system in which the purger is to run.
The ATINDEX parameter specifies an integer value from 0 through 15 specifying the audit trail on the primary system to which the data volume being protected is mapped. 0 specifies the MAT. 1 through 15 specifies auxiliary audit trails AUX01 through AUX15, respectively. The default is 0. The CPUS parameter specifies the processors in the backup system in which the updater will run.
1. Redirect the output of the RDFCOM session from your terminal to the configuration command file by issuing an appropriate OUT command. For example, to direct subsequent session output to the configuration command file named RDF.INIT, enter the following command: ]OUT RDF.INIT 2. Issue an INFO * command with the OBEYFORM parameter: ]INFO *,OBEYFORM RDFCOM lists the current parameters in the RDF configuration file to RDF.INIT in OBEY command file format. 3.
]START RDF Notice that to issue this command, you must have an RDFCOM session running on the primary system and meet all of the following requirements: • • • • • You are logged on as a member of the super-user group (or have execution access for an RDFCOM object that has been PROGID'd by the customer). You have the same super ID that was used to initialize RDF (or have execution access an RDFCOM object that has been PROGID'd by the customer).
4 Operating and Monitoring RDF To operate and monitor RDF, you enter commands through two online utilities: the RDFCOM and RDFSCAN interactive command interpreters. Through these utilities, you initiate communication with RDF, request various RDF operations or information displays, and terminate communication with the subsystem.
IN command-file specifies a command file from which RDFCOM commands are to be read. RDFCOM reads 132-byte records from the specified file until it encounters either the end-of-file mark or an EXIT command. If you do not specify the IN option, TACL automatically supplies the name of its current default input file—usually the terminal from which you issued the RDFCOM command. OUT output-file specifies a file to which all output (other than prompts for entering RDFCOM commands) is to be written.
If the suffix character “3” was specified in the INITIALIZE RDF command, then you would enter the following command: >RDFCOM SANFRAN3 When RDFCOM starts, it searches the specified subvolume on $SYSTEM of the local system for the RDF configuration file to open. In other words, the configuration file that RDFCOM expects to open is: \local-system.$SYSTEM.control-subvolume.
• • resume communication with RDFCOM by entering the operating system command PAUSE at the TACL prompt. If you press BREAK when an RDFCOM command that displays information (such as STATUS RDF) is in progress, RDFCOM terminates execution of this command and prompts you for another one. If you press BREAK when an RDFCOM command that changes the RDF configuration or status (such as ALTER RDF) is in progress, RDFCOM continues to execute this command while immediately prompting you for another one.
To run RDFCOM and execute the commands in this file, supply the command file name in the IN option of the command to start RDFCOM: 4> RDFCOM /IN RDFSET/ control-subvolume When it uses a command file in this way, RDFCOM works in batch mode: RDFCOM begins the session, reads and executes each command from the command file, and displays the associated output at your terminal.
Table 4-1 RDFCOM Configuration Commands Command Object Function ADD { RDF } { MONITOR } { EXTRACTOR } { RECEIVER } { IMAGETRAIL } { PURGER } { RDFNET } { NETWORK } { TRIGGER } { VOLUME } Applies option values from the configuration memory table to the RDF configuration file for the specified process, or adds RDF and image trail configuration records to the RDF configuration file.
Table 4-2 RDFCOM Operational Commands (continued) Command Object Function START UPDATE Starts all updater processes on the backup system. STATUS { MONITOR } { RDF } { EXTRACTOR } { RECEIVER } { PURGER } { PROCESS } { VOLUME } { RTDWARNING } { RDFNET } Lists current information about RDF processes. STOP RDF Stops RDF. STOP SYNCH Signals the end of all necessary load and BACKUP operations during online database synchronization. STOP UPDATE Stops all updater processes on the backup system.
Entering Commands The complete syntax of all RDFCOM commands appears in Chapter 8 (page 173). Some general rules that apply to all RDFCOM commands appear in the following list: • • • You can enter commands in either uppercase or lowercase letters or any combination of these.
PURGER | NETWORK | RDFNET | TRIGGER | VOLUME } Operational Commands: COPYAUDIT START STATUS STOP TAKEOVER UNPINAUDIT VALIDATE Utility Commands: EXIT FC HELP HISTORY OBEY OPEN OUT RDF Concepts: Abbreviations RDF error messages: error-number E.g., "help 700" prints an explanation for the RDF error message 700 Help for RDF Error Messages For information about a particular error message (its cause, effect, and recommended recovery steps), enter HELP followed by the message number.
RDFSCAN filename RDFSCAN is an implicit RUN command, instructing the TACL command interpreter to run the RDFSCAN utility program. filename specifies the entry-sequenced file to be opened. Using RDFSCAN When you use RDFSCAN, you conduct an interactive dialog with it through prompts, commands, output displays, and messages. RDFSCAN has two operational restrictions: • • RDFSCAN does not use command files; you must enter all RDFSCAN commands from the terminal. RDFSCAN accepts only one command per prompt.
Table 4-4 RDFSCAN Commands Command Object Function AT [ record-number ] Specifies the record number at which to begin the next RDFSCAN function. DISPLAY [ ON | OFF ] Enables or disables the display of record numbers for the lines listed. EXIT -- Terminates an RDFSCAN session. FILE log-file Opens the specified file as the current EMS log. HELP [ ALL ] [ command ] [ INTRO ] Displays help text for commands and RDFSCAN usage.
Scan will only read count no matter how many are displayed. FILE: \WHICH.$SYSTEM.RDF.RDFLOG, current record: 37501, last record: 37513 Enter the next RDFscan function you want: To obtain a list of all RDFSCAN commands, enter either HELP or HELP ALL. For example: Enter the next RDFscan function you want: HELP ALL In response, RDFSCAN displays: Enter HELP INTRO for an introduction to RDFSCAN.
Performing Routine Operational Tasks Through RDFCOM and RDFSCAN, you can perform many different RDF functions. Among these are the routine operational tasks that system operators do from day-to-day. These routine tasks include: • • • Displaying current configuration parameters and operating statistics Changing configuration parameters Reading RDF messages Other specialized tasks are described throughout the manual.
NOTE: The entry * Monitor Unavailable * can also be displayed when the monitor process does not read any messages. This usually happens when the RDFCOM STOP RDF, DRAIN/REVERSE command is issued, especially when the REVERSE TRIGGER is configured with the WAIT option. This situation is normal and no recovery action is required. The rest of the display provides current information about each RDF process configured.
• Volume and Seqnce together specify a file associated with each process: The monitor entry reflects the name of the MAT file to which TMF is writing ($AUDIT.ZTMFAT.AA000056 in this example). Each extractor entry reflects the name of the TMF audit-trail file from which it is reading ($AUDIT.ZTMFAT.AA000056 for the master extractor and $DATA17.ZTMFAT.BB000004 for the auxiliary extractor in this example).
When the BREAK key is pressed while the STATUS RDF command is executing with the PERIOD option (which requests repeated displays at a specified interval), the break takes effect within one second rather than waiting until the end of the current interval. Using RDF Status Data to Control TMF Audit Dumping You can use the STATUS RDF command to determine when the RDF extractor has finished processing the audit file that TMF wants to dump.
The specified collector must reside on the local system. For example, if you are in an RDFCOM session on the system \SANFRAN, you cannot specify something like \CHICAGO.$EMSC as the log. For more information about the EMS log, see Chapter 1 (page 35), Chapter 3 (page 73), Chapter 8 (page 173), and Chapter 9 (page 245). RETAINCOUNT The RETAINCOUNT purger process configuration parameter specifies how many image trail files must be retained on disk for each image trail.
NOTE: The record numbers reflected by RDFSCAN are approximate and might not exactly match the record numbers that would be displayed by a FUP INFO RDFLOG, STAT command. With RDFSCAN you can specify: • • • A starting point within the message file The number of records to retrieve Text to search for in the message file RDFSCAN displays those RDF messages that meet the criteria you specify. The following is a sample display for a primary system.
Enter the next RDFSCAN function you want: DISPLAY ON File: $SYSTEM.RDF.RDFLOG, current record: 750, last record: 903, Pattern: *REMOTE* Enter the next RDFSCAN function you want: Record number: 751 2004/06/04 11:20:16 \LAB1 Record number: 752 2004/06/04 11:20:26 \LAB1 $LOST -> $BLOST Record number: 756 2004/06/04 11:20:30 \LAB1 Record number: 758 2004/06/04 11:21:46 \LAB1 $INFO -> $BINFO Record number: 760 2004/06/04 11:22:33 \LAB1 $POPPY -> $BPOPPY File: $SYSTEM.RDF.
5 Managing RDF You manage the RDF environment by monitoring various things using RDFCOM STATUS commands, the EMS log, and the ASAP product. In managing RDF, you must sometimes react to nonroutine events and conditions that affect the RDF operating environment, by performing a variety of special tasks and activities. Although most of this work is not required on a regular basis, the need for it does arise on occasion.
For information about the causes, effects, and recovery actions for all RDF event messages, see Appendix C (page 335). When present, file-system error numbers appear in the error# parameter of these messages. Table 5-1 lists the file-system error numbers and recovery actions for RDF event 700, which reports file-modification failures. Table 5-1 Recovery From File Modification Failures (RDF Event 700) File System Error Recovery Action 1 Check file integrity. The updater process skips the modify operation.
Table 5-2 Recovery From File Open Failures (RDF Event 705) File System Error Recovery Action 11 Resynchronize the file. The updater process skips the open operation. 12 Issue a FUP LISTOPENS command for the file and stop applications that have the file open. 14 Repair the device or clear the condition. 30 through 37 If the problem persists, alter the hardware configuration or perform system tuning. 48 Alter the security (probably Safeguard).
Table 5-3 Recovery From File Creation Failures (RDF Event 739) (continued) File System Error Recovery Action 190 Repair the device or clear the condition. 199 Alter the security (probably Safeguard). 200 through 231 Repair the device or clear the condition. Handling Disk Space Problems When creating a new image file, the receiver preallocates 16 disk extents. If there is not enough disk space, the receiver encounters a file-system error 43 when it tries to preallocate these extents.
After a TMF file recovery to a timestamp or to first purge, or after a TMF subsystem failure for which volume recovery cannot succeed, the databases or the affected files on the primary and backup systems must be resynchronized. If the primary system fails, you might want to request a takeover operation to switch application processing to the backup system. Communication Line Failures RDF can recover from communication line failures.
When the CPU that failed comes back up, RDF switches the extractor to run on the reactivated primary CPU. Receiver Failure If the primary CPU of the receiver process fails, the receiver process in the backup CPU takes over and resynchronizes with the extractor process. The extractor process might have to resend audit data that was generated several seconds earlier. When the CPU that failed comes back up, RDF switches the receiver to run on the reactivated primary CPU.
STATUS *, PROG RDF-software-loc.*, STOP If a state transition failure occurs during execution of a STOP UPDATE command and the operation appears to be stalled, manually stop all of the RDF updaters by issuing the following command on the backup system: STATUS *, PROG RDF-software-loc.RDFUPDO, STOP CAUTION: Issuing this command in this situation is only safe, however, if this is the backup system for a single RDF environment.
2. 3. Correct the problem on the backup system and recover the volume. From the backup system, restart TMF on the backup system by entering this command through TMFCOM: ~START TMF 4. From the primary system, resume updating of the backup database by entering this command through RDFCOM: ]START UPDATE Volume Recovery Processing RDF handles volume recovery automatically. Volume Recovery Failure RDF cannot recover from a TMF subsystem failure if TMF cannot successfully perform volume recovery.
You should not perform a file recovery to a timestamp, first purge, or TOMATPOSITION on your backup system if the location occurs prior to an RDF takeover location. Those file recovery operations normally are used to recover a database that has been corrupted. Under normal circumstances, the best way to recover the backup database is to resynchronize it with your primary database.
If the communications lines between the two systems are down and you want to stop RDF, you must issue the STOP RDF command on both the primary and backup systems. Stopping RDF leaves the backup database in an inconsistent state and also leaves the audit-trail file last opened by the extractor pinned. CAUTION: If the primary system crashes, RDF processes on the backup system remain running.
NOTE: TMF does not start RDF, which means that if you start TMF, you must then explicitly start RDF. If the communications lines are down when you stop TMF, the extractor continues to run, but it will not recognize that TMF is shut down because the extractor does not read the data in the MAT until the extractor can transmit data to the receiver on the backup system. If the extractor is not reading the MAT, it cannot encounter the TMF shutdown message.
NOTE: Even when no TMF transactions are in progress, TMF periodically writes control points to the MAT, which means that the MAT continues to fill even when no application activity is occurring. This can cause RTD times in the status display to fluctuate. For an alternate method of bringing the backup database to a consistent state, see “Access to Backup Databases in a Consistent State” (page 140). When you issue a STOP RDF command from the primary system, the following events occur: 1. 2. 3.
>STATUS *, PROG RDF-software-loc.*, STOP CAUTION: Issuing this command in this situation is only safe, however, if this is the backup system for a single RDF environment. Restarting RDF If you want to restart RDF and have it resume processing where it stopped at the previous shutdown, you can only do so if you have not reinitialized RDF subsystem since the shutdown. Use the START RDF command to restart RDF.
The planned switchover repeats the procedure described above, except that you reverse the roles of systems \A and \B. After doing so, RDF replication once again occurs from \A to \B. Using a Reverse Trigger You can automate the planned switchover operation described above by configuring a REVERSE TRIGGER and then issuing a STOP RDF, REVERSE command instead. Reciprocal Configurations In a reciprocal RDF configuration, two systems act both as a primary and as the backup to the other.
When the RDF subsystem #1 extractor starts sending current audit information to \A (and at a convenient time with respect to your processing environment), stop Applications #1 and carry out a planned switchover from \B to \A: 1. 2. 3. 4. 5. 6. On system \B, create an audited Enscribe file on each data volume in the RDF subsystem #1 configuration. Wait until all of those files are created on system \A. On system \B, stop RDF subsystem #1. Purge the Enscribe files on both systems.
Transactions that must be undone during this undo pass are stored in the ZFILUNDO file in the Master Image Trail subvolume. Phase Three Undo Pass This is also known as Network Undo. If you are running in an RDF network and you lose one or more primary systems, you must do a takeover on all backup systems in your RDF network. For a complete description of the takeover operation in an RDF network, see “RDF Takeovers Within a Network Environment ” (page 278).
3. To proceed with the takeover operation, enter Y or YES. To abort the takeover operation, enter N or NO. After you enter your response, RDFCOM returns its prompt. Then you can use the STATUS RDF command to determine the status of the takeover operation. If the takeover operation is still in progress, RDF displays the current state as “TAKEOVER IN PROGRESS.
Takeover and File Recovery After you initiate a takeover, it is possible that the last committed transactions did not make it to the backup system (meaning that the backup and primary databases are not synchronized). If the takeover completes on the backup system, the purger logs an RDF event 888 specifying a MAT position (sno, rba).
NOTE: If you are using the triple contingency feature, you must issue a COPYAUDIT command after the takeover operations are complete to copy missing audit from the backup system that has the most to the one that has the least. See Chapter 10 (page 255)for details about this situation.
Reading the Backup Database Unlike databases protected by TMF, backup databases for RDF protection have no locks on rows or records, even while these rows or records are being updated. Therefore, applications can read the backup databases at any time; the data can, however, be inconsistent because reading and updating can occur simultaneously.
RDFCOM; STOP UPDATE, TIMESTAMP 21JUN2004 12:00 If the specified timestamp is not at least five minutes greater than the current time, RDFCOM aborts the command and displays the following message: The specified timestamp must be at least five minutes greater than the current time. The STOP UPDATE command itself is logged to the EMS event log under the general RDF message 835.
When included, the WITH SHARED ACCESS option specifies that the DDL operation is to allow concurrent read-write Data Manipulation Language (DML) access and read-only utility access to the objects on which it operates during all but the final phase of the operation. For this reason, operations specifying the WITH SHARED ACCESS option are sometimes referred to as Online DDL operations. The only operations that must be performed WITH SHARED ACCESS are merge partitions and move boundaries.
command (only those updaters that did not generate a message 733 are started). Check the RDF log again to see if RDF generated another message 905. If it did, issue another START RDF, UPDATE ON command, and so forth, until RDF logs a message 908. When RDF logs the message 908, do the Steps 2 and 3 listed above. RDF does not support shared access NonStop SQL/MP DDL operations where the target file is located on a different node than the primary system.
3. for certain that AA000007 will never be needed again. When this message is written, you can start the backup process to dump AA000007 to tape. When the backup process opens AA000007 and the backup is in progress, you can stop the file-opening process run in Step 1. The purger will continue its attempts to purge AA000007, but these attempts also will fail as long as the backup process has AA000007 open.
3. Restart the updaters (issue a START UPDATE command on the primary system). Exception File Optimization The RDF exception files reside in the control subvolume on $SYSTEM. The name of each is the name of the updater’s primary system volume. Each updater maintains an exception file in which it identifies every audit record that must be undone on the backup database during a takeover. Typically records must be undone because the outcome of the associated transaction is unknown.
inconsistent with the primary database. To avoid these errors, always stop the updaters first before remirroring the disk.
6 Maintaining the Databases A vital task in working with RDF is to keep the backup and primary databases synchronized with each other.
Figure 6-2 Synchronized Databases During RDF Operations Figure 6-3 shows synchronized databases where the application is running on \PRIMARY and the transaction data for the three new transactions has been applied to the backup database. Figure 6-3 Synchronized Databases, No Outstanding Audit Figure 6-4 shows synchronized databases where TMF has just been shut down.
Figure 6-4 Synchronized Databases After STOP TMF Command Figure 6-5 shows unsynchronized databases. In this figure, T5 and T6 (transactions 5 and 6) have not been transmitted to the backup system because of a physical disaster, such as fire or flood, or because the primary or backup systems have failed.
• • Partition key changes Table purges Catalog Changes RDF views NonStop SQL/MP and NonStop SQL/MX DDL operations as updates to catalogs. NonStop SQL/MP and NonStop SQL/MX catalogs themselves are audited tables, even on the backup system. NonStop SQL/MP and NonStop SQL/MX DDL operations are not replicated by RDF; therefore, RDF does not apply updates to catalogs.
3. Specify the default catalog for the primary system. CATALOG \PRIM.$TEST.DBCAT; 4. Create an index on the primary system that corresponds to the index created on the backup system. CREATE INDEX \PRIM.$DATA1.DB.FIRST ON \PRIM.$DATA1.DB.EMPLOYEE( FIRST_NAME, LAST_NAME ); You should use WITH SHARED ACCESS for the CREATE INDEX operations in the above example if both RDF and the application are running. Multiple Indexes on a Single Base Table These issues also apply to NonStop SQL/MX.
COLUMN 88, OFFSET 300, LENGTH 15, ASC. COLUMN 87, OFFSET 285, LENGTH 15, ASC. NOT UNIQUE ) AUDIT BUFFERED AUDITCOMPRESS SECURITY (RWEP); NCNC MODIF: 27 Dec 1997, 20:01 CREATION DATE: 02 Dec 1997, 12:37 REDEFINITION DATE: 10 Jan 1998, 14:46 LAST OPEN: 10 Jan 1998, 14:46 EOF 466944 (2.
5. 6. Perform each operation on Enscribe files on the backup system and the corresponding operation on the primary system. Finally, resume application processing. Resynchronizing Databases There are two ways of resynchronizing your primary and backup databases: offline and online. With offline resynchronization you must first stop your applications and TMF on the primary system.
If you are unsure about which tables or files might not be synchronized, you need to compare the questionable tables or files between the primary and backup databases and then, based on that evaluation, resynchronize some of the database objects. To purge a NonStop SQL/MP or NonStop SQL/MX database, use the SQLCI/MXCI PURGE utility and DROP command, as explained in the SQL/MP Installation and Management Guide and the SQL/MX Installation and Management Guide.
7 Online Database Synchronization With RDF/IMP, IMPX, or ZLT you can synchronize entire databases or selected volumes, files, tables or even partitions while your applications continue to run. For information about NonStop SQL/MX databases, see Chapter 16 (page 295). Overview The RDF online database synchronization protocol consists of the following general steps (the details of which are discussed later in this chapter): • • • • • Initialize the RDF configuration with the SYNCHDBTIME option.
where system is the name of the backup system, ddmmmyyyy is today’s date (such as 17DEC2004), and hh:mm is an appropriate timestamp prior to the current time (see the description of the INITIALIZE RDF command in Chapter 8 (page 173)). NOTE: If you have multiple RDF environments, be sure to specify an appropriate SUFFIX parameter in the above INITIALIZE RDF command to keep this RDF configuration separate from the other RDF configurations on the primary system.
8. When your loaded database is on the backup system and the extractor has logged the message indicating it has completed its role in the online synchronization operation, issue the RDFCOM START UPDATE command on the primary system. NOTE: If your updaters are protecting data volumes that are all configured to the Master Audit Trail (MAT), you can start the updaters as soon as the duplicate database is on the backup system and the extractor has issued the RDF event 782.
SYNCHDBTIME Issues With the SYNCHDBTIME option in the INITIALIZE RDF command, there are three special cases you might need to consider: • • • Enscribe create operations NonStop SQL/MP Shared Access DDL operations TMF shutdown operations Enscribe Create Records If you created the same Enscribe file on the primary and backup systems prior to execution of the INITIALIZE RDF command, and if the extractor’s restart position is located before the audit record for the create operation on the primary system, you
For information about the SQLCI LOAD or FUP LOAD commands, refer to the SQL/MP Reference Manual or the File Utility Program (FUP) Reference Manual, respectively. The following information is general in nature and is not intended as a substitute for the information contained in those two manuals. General Considerations for Enscribe Files • • • • • Key-sequenced files. To improve the performance of the load operations, specify the SORTED option. Relative files.
Enscribe Queue File Issues For ENSCRIBE queue files, a different method of obtaining the fuzzy copy is required. You must use the FUP COPY command with the SHARE option specified, and with “FIRST 1” specified. For example, the following command copies the contents of file QUEUE1 to QUEUE2.
labels of the duplicate files on the backup system so they reflect the correct volume mapping of the various partitions on the backup system. For example, suppose you have a partitioned Enscribe file on the primary system whose primary partition is on $DATA1 and secondary partition is on $DATA2.
set altfile (0, $data2.test.altf0101 ) create $data2.test.part0101 volume $data3.test reset set type r, no audit set buffered, ext(10,10) set rec 4050, block 4096 set maxextents 16 set code 4700 set part (1, $data2, 2, 2 ) set altkey (1, file 0, keyoff 6, keylen set altkey (2, file 0, keyoff 6, keylen set altkey (3, file 0, keyoff 6, keylen set altkey (4, file 0, keyoff 6, keylen set altkey (5, file 0, keyoff 6, keylen set altfile (0, $data3.test.altf0200 ) create $data3.test.
Synchronizing Selected Database Portions Online There are a number of reasons why you might want to synchronize only selected portions of your database. For example: • • • If you have a large database, it might be easier to break the total number of volumes into subsets, and then synchronize one subset at a time. If a file or table has become corrupt, you might want to synchronize just that one file.
When you configure a new RDF subsystem, use your existing RDF configuration file. You then follow the guideline for an entire database synchronization operation, except that you only need to create and load a copy of the one file or partition. Partial Database Synchronization Issues There are many considerations when synchronizing selected portions of a database. You should read this chapter carefully before attempting to perform the operation.
To load the secondary partition only, issue the following command: FUP LOAD $DATA2.TEST.PART0100, $DATA2.TEMP.PART0100, PARTONLY,SHARE When the load operations are finished, use BACKUP and RESTORE (or FUP DUP) with the PARTONLY option to copy the partition you need to the backup system. Relative Files First create a non-audited duplicate file on the primary system. You must create the entire file with all its partitions. Unlike key-sequenced files, you must load the entire file.
Described below is a set of steps that can be used to synchronize individual partitions of NonStop SQL/MP tables (either primary or secondary partitions). Requirements for Synchronization of Individual Partitions The following methods work only if all the partitions of a given table still reside on disk on the backup system.
3. 4. Configure RDF and then issue a START RDF, UPDATE OFF command on the primary system. Create the entire duplicate table on your backup system with a temporary name at a temporary location (such as \BACKUP.$DATA.DUP.PART). The alternative is to create the duplicate table on the primary system at a temporary location (such as \PRIMARY.$DATA.DUP.PART). If the table whose primary partition needs to be synchronized has indexes, do not create indexes for the duplicate table. 5. 6. 7.
There is an alternate method that might be faster in some situations than the method described above, although this method requires that you rebuild all indexes associated with the table on the backup system. 1. 2. 3. 4. 5. Drop all indexes associated with the table on the backup system that has a partition in need of synchronization. Use the SQLCI LOAD command with the PARTONLY option to load the partition directly from the primary system to the backup system (without having to create a duplicate table).
11. Use the BACKUP utility with the PARTONLY option to back up just the partition you need synchronized to tape (the primary partition, in this example). Remember that the duplicate table now has the name of the original table. Thus, you now have on tape the loaded partition that you need to synchronize. Because it has the correct name, you will not need to use MAP NAMES when you eventually restore it. 12. Rename the duplicate table back to its original duplicate table name ($DATA. TEST.PART becomes $DATA.
is stored in all image trails by the receiver). All transactions that might have been started during the create/load or backup operations are now finished. NOTE: TMP control points are generated as the result of transaction activity. For high rates of transaction activity, the TMP control points might be only 1 or 2 minutes apart. For lower rates, they might be 5 to 10 minutes apart. On a completely idle system, TMP control points can be approximately 30-60 minutes apart.
Extractor Messages Messages 766, 767, and 768 in combination report the completion of phase 1. Message 782 reports the completion of phase 2. Message 782 indicates that the extractor has finished its involvement in the online synchronization operation. Updater Messages Message 782 reports the completion of phase 2 and indicates that the updater has finished its involvement in the online synchronization operation.
8 Entering RDFCOM Commands To manage, operate, and control RDF and its environment, you enter commands through the RDFCOM online utility. This chapter, directed to system managers and operators, describes the RDFCOM commands and their attributes.
The default security restrictions for all RDFCOM commands are summarized in Table 8-2. RDF State Requirement Some RDFCOM commands can only be entered after RDF has been started; others must be entered before the subsystem has been started or after it has been stopped. In each command description, these constraints are listed under the heading “RDF State Requirement.” Usage Guidelines Details about the proper use of a command appear in “Usage Guidelines.
Table 8-1 Systems for RDFCOM Commands (continued) Extractor Image Monitor RDF Receiver Purger Trail Update Volume RDFNET Network Trigger Other Objects TAKEOVER B UNPINAUDIT P VALIDATE P Legend P = Primary only B = Backup only E = Either * = SYNCH ** = RTDWARNING Table 8-2 Default User Security for RDFCOM Commands Extractor Image Monitor RDF Receiver Purger Trail ADD S ALTER S S Update Volume RDFNET Network Trigger S S S S S S S S S S S S S S S S COPYAUDIT Other Objects O*
Table 8-2 Default User Security for RDFCOM Commands (continued) Extractor Image Monitor RDF Receiver Purger Trail Update Volume RDFNET Network Trigger OUT A RESET S S S S S S S S S S SET S S S S S S S S S S SHOW A A A A A A A A A A A* A A START STATUS Other Objects O* A STOP A* S* S* A* A* S* A** S*** TAKEOVER O UNPINAUDIT S VALIDATE S Legend: A = All users S = Super-user group only O = owner of RDF subsystem * = Must also have remote password for primar
The system does not distinguish between uppercase and lowercase alphabetic characters in a file name. If all the optional left-hand parts of a file name are present, it is called a fully qualified file name; if any of the optional left-hand parts are missing, it is called a partially qualified file name. For more information about file names and process identifiers and the rules that govern them, see the Guardian Procedure Calls Reference Manual. NOTE: RDF does not support long network names.
system specifies the name of the system on which the device resides. A system name consists of a backslash (\) followed by one to seven alphanumeric characters; the first alphanumeric character must be a letter. device-name specifies the name of a device. A device name consists of a dollar sign ($) followed by one to seven alphanumeric characters; the first alphanumeric character must be a letter. qualifier is an optional qualifier.
ADD The ADD command applies configuration parameter values for the specified process or other object from the RDF configuration memory table to the RDF configuration file. ADD {RDF {MONITOR {EXTRACTOR {RECEIVER {IMAGETRAIL $volume {PURGER {RDFNET {NETWORK {[VOLUME] $volume {TRIGGER trigger-type } } } } } } } } } } RDF applies RDF global configuration parameters. MONITOR applies configuration parameters for the monitor. EXTRACTOR applies configuration parameters for an extractor.
Usage Guidelines With the ADD command, all configuration parameter settings that you previously supplied in SET commands for the particular process or other object are applied from the RDF memory table to the RDF configuration file. Any parameter settings that you did not supply are set to their default values. Each volume on the primary system protected by RDF requires a corresponding updater process on the backup system.
When the preceding command sequence is executed, all of the other RDF global parameters are set to their default values: (In this list, \LONDON is the system at which you issued the command sequence.
trigger-type is REVERSE or TAKEOVER. This command parameter alters a trigger that has already been added to the RDF configuration. Where Issued These commands can be issued only at the primary system, except ALTER TRIGGER, which can be issued at the backup system if the primary system is not available.
To change the primary and backup CPUs for the master receiver process to CPUs 3 and 4 respectively, enter an ALTER RECEIVER CPUS command: ]ALTER RECEIVER CPUS 3:4 Remember you cannot do this particular alter operation while RDF is running. To change the primary and alternate CPUs of a reverse trigger to CPUs 3 and 4, enter an ALTER TRIGGER CPU command: ]ALTER TRIGGER REVERSE CPUS 3:4 To change the path of the updater mapfile, enter an ALTER VOLUME MAPFILE command: ]ALTER VOLUME $DATA01 MAPFILE $DATA05.
command on the system that is behind, specifying the name of the other backup system and its RDF control subvolume. For the following discussion, assume that you have established these two RDF configurations: RDF Configuration #1: \A ------------------> \B (The RDF control subvolume is A1 on both systems.) RDF Configuration #2: \A ------------------> \C (The RDF control subvolume is A2 on both systems.
COPYAUDIT Restartability The COPYAUDIT command is restartable. If an error condition aborts execution of a COPYAUDIT command, you merely correct the condition and then reissue the command. Upon restart, RDFCOM quickly checks the local system image files it had previously created to be sure they are still correct, deletes the file it was working on at the time of the error condition, and then resumes copying.
NOTE: If you delete a trigger on the backup system while the primary system is down and the primary system once again becomes available, you should perform the same delete operation on the primary system before starting RDF. If you don’t do that the deletion is lost because, when it starts, RDF automatically copies configuration information from the primary system to the backup system. Security Restrictions You can issue the DELETE command if you are a member of the super-user group.
system volume $DATA6, and that the updater for that volume is acquiring its audit data from secondary image trail volume $SECITB. To delete the configuration records for the updater process and secondary image trail associated with auxiliary audit trail AUX01, enter the following commands: ]DELETE VOLUME $DATA06 ATINDEX 1 ]DELETE IMAGETRAIL $SECITB ATINDEX 1 EXIT The EXIT command ends your current RDFCOM session. EXIT Where Issued Primary or backup system.
{?} [ text ] requests RDFCOM to display the most recently issued command that begins with the specified text string. If you omit the text parameter, RDFCOM displays the most recently issued command. {!} [ text ] requests RDFCOM to execute the most recently issued command that begins with the specified text string. If you omit the text parameter, RDFCOM executes the most recently issued command. Where Issued Primary or backup system. Security Restrictions None; anyone can enter the FC command.
]INFO MONITOR . MONITOR CPUS 0:1 MONITOR PRIORITY 170 MONITOR PROCESS $MON ] On the next line, suppose you inadvertently enter an extra character in the SHOW RDF command: ]SHOW RDDF Expecting: Or: ] RDF, MONITOR, EXTRACTOR, RECEIVER, PURGER, IMAGETRAIL NETWORK, RDFNET, TRIGGER, or VOLUME You correct this entry by entering the FC command followed by the D (for delete) subcommand under the extra character displayed: ]FC ]SHOW RDDF . D ]SHOW RDF .
Usage Guidelines This command retrieves and displays information from the RDFHELP file. If you omit all options, RDFCOM uses the ALL option and lists all RDFCOM commands. Examples To display the syntax of the ADD command, enter: ]HELP ADD RDFCOM displays: { RDF { MONITOR { EXTRACTOR { RECEIVER ADD { IMAGETRAIL $volume { PURGER { RDFNET { NETWORK { TRIGGER { VOLUME $volume { $volume Cannot be performed with RDF } } } } } } } } } } } running.
RDF Concepts: Abbreviations RDF error messages: error-number E.g., "help 700" prints an explanation for the RDF error message 700 To display information about RDF message 715, enter: ]HELP 715 RDFCOM displays the following description: ------------------------------------------------------------| 715 Primary Stopped | ------------------------------------------------------------Cause: The primary process of a NonStop process pair has stopped.
History: ADD EXTRACTOR START RDF SHOW EXTRACTOR ALTER EXTRACTOR PRIORITY 170 SHOW RECEIVER ALTER RECEIVER PRIORITY 175 STATUS RDF ALTER MONITOR PRIORITY 195 INFO * HISTORY INFO The INFO command displays the current configuration parameter values from the configuration file for the specified process or other object.
command. You can use the OBEYFORM option with any variation of the INFO command: for example, with INFO EXTRACTOR, INFO RDF, or INFO *. IMAGETRAIL displays the names of all volumes on the backup system that are configured as secondary image trail volumes. RDF displays the current configuration parameter values for the RDF global options. MONITOR displays the current configuration parameter values for the monitor process.
INFO * Command To display all current RDF configuration parameters for both the primary and backup systems, enter: ]INFO * RDF displays the currently configured RDF parameter values in the following manner: RDF RDF RDF RDF RDF RDF RDF RDF RDF RDF RDF RDF RDF SOFTWARELOC $SYSTEM.
VOLUME UPDATEVOLUME $DATA2 VOLUME IMAGEVOLUME $SECIT2 VOLUME PROCESS $UP02 VOLUME VOLUME VOLUME VOLUME VOLUME VOLUME VOLUME TRIGGER TRIGGER TRIGGER TRIGGER TRIGGER TRIGGER TRIGGER $DATA03 ATINDEX 0 CPUS 2:1 PRIORITY 160 UPDATEVOLUME $DATA3 IMAGEVOLUME $SECIT2 PROCESS $UP03 PROGRAM $SYSTEM.RDF.RDFCOM INFILE $DATA01.RDF.RDFCONF OUTFILE $DATA01.RDF.OUTFILE CPUS 0:1 PRIORITY 150 NOWAIT REVERSE The primary system name is set implicitly and the backup system name is set in the INITIALIZE RDF command.
You would see this particular output, for example, if you originally configured the monitor to run in CPUs 2 and 1 at the default priority of 165, but later changed the priority to 170 (using an ALTER command). INFO RDF Command To display the current RDF global configuration parameters, enter: ]INFO RDF RDF displays the following: RDF RDF RDF RDF RDF RDF RDF RDF RDF RDF RDF RDF RDF RDF RDF SOFTWARELOC $SYSTEM.
VOLUME VOLUME VOLUME VOLUME PROCESS $UP01 MAPFILE $DATA05.CONFIG.MAPFILE MAPLOG $DATA05.LOG.
SET SET SET SET SET SET ADD TRIGGER TRIGGER TRIGGER TRIGGER TRIGGER TRIGGER TRIGGER PROGRAM $SYSTEM.RDF.RDFCOM INFILE $DATA01.RDF.RDFCONF OUTFILE $DATA01.RDF.
suffix-character is an alphanumeric character to be appended to the primary system name to form the RDF control subvolume name. If you omit the SUFFIX parameter, the default control subvolume name is the name of the primary system with no suffix character. TIMESTAMP: causes RDF to initialize at the specified time, which must correspond exactly to the time of a TMF shutdown. NOTE: There is no space between day, month, and year. The seconds must not be included in the timestamp.
! causes the command to be executed without further confirmation. If you omit the exclamation point, RDFCOM prompts you for additional responses: • If you omit the TIMESTAMP, INITTIME, SYNCHDBTIME, and ! options, RDFCOM displays: Are you sure you want to initialize? [Y/N] Enter Y or YES to proceed; • enter N or NO to cancel the command. If you include the TIMESTAMP option without the ! option, RDFCOM displays: Do you wish to proceed? [Y/N] Enter Y or YES to proceed; enter N or NO to cancel the command.
RDF State Requirement You can issue the INITIALIZE RDF command only when RDF is stopped and no files exist in the RDF control subvolumes on either the primary and backup systems. Usage Guidelines If your RDF subsystem is running and you do not include the TIMESTAMP, INITTIME, or SYNCHDBTIME options in the INITIALIZE RDF command, then you must stop, delete, and reconfigure TMF before entering the INITIALIZE RDF command.
If you initialize RDF at the shutdown point at Step d, you should restore on the backup system a copy of the primary system database taken at Step d. The databases would not be synchronized if the database at Step b was restored to the backup system. If you initialize RDF to the timestamp corresponding to Step b, you should restore on the backup system a copy of the primary system database taken at Step b. • • • • Initialize RDF at the most recent TMF shutdown point.
trail on the mirrored volume now plugged into the standby system to the receiver on the backup system. LOCKSTEP control-subvol, REMOTESYS standby-node control-subvol specifies the name of the RDF control subvolume on the backup system that requires the LOCKSTEP and subsequent TAKEOVER commands. standby-node specifies the name of the standby system where the audit-trail mirror has been brought online. Where Issued Backup system only.
Security Restrictions None; anyone can enter the OBEY command. RDF State Requirement You can enter the OBEY command at any time, whether or not RDF has been started. Usage Guidelines If you omit system, volume, or subvolume, RDFCOM uses the defaults in effect when RDFCOM was started. A command file can contain other OBEY commands, nested up to four levels deep.
Usage Guidelines Issue an OPEN command to select the RDF control subvolume to which any subsequent RDFCOM commands (except another OPEN command) will apply. Using the OPEN command is the same as specifying a control subvolume in the RDFCOM command that begins a session.
file specifies the name of the file or device to which RDFCOM is to direct subsequent output. If you enter the OUT command but omit the file identifier altogether, RDFCOM directs the session output to the output file or device originally used for the current session. Where Issued Primary or backup system. Security Restrictions None; anyone can enter the OUT command. RDF State Requirement You can enter the OUT command at any time, whether or not RDF has been started.
{PURGER {RDFNET {NETWORK {TRIGGER } } } } RDF resets the values for the RDF global options. MONITOR resets the values for the monitor process. EXTRACTOR resets the values for the extractor process (this includes resetting the ATINDEX value to 0). RECEIVER resets the values for the receiver process (this includes resetting the ATINDEX value to 0). VOLUME resets the values for the updater processes (this includes resetting the ATINDEX value to 0 and clearing all EXCLUDE and INCLUDE clauses).
To reset the extractor process parameters in the configuration file to their default values so that these values now affect RDF, issue the following commands after RDF has been initialized: ]RESET EXTRACTOR ]SET EXTRACTOR PROCESS $EXT ]ADD EXTRACTOR To reset the updater process parameters in the configuration memory table to their default values, enter: ]RESET VOLUME To reset the trigger parameters in the configuration memory table to their default values, enter: ]RESET TRIGGER SET EXTRACTOR The SET EXTR
active volume, restore volume, or overflow volume; you merely specify the volume name. For information about the ZLT capability, see Chapter 17 (page 309). Where Issued Primary system only. Security Restrictions None. RDF State Requirements None. Usage Guidelines The SET EXTRACTOR command enters the parameter values specified for the extractor in this command into the RDF configuration table in memory.
ATINDEX audittrail-index-number is an integer value identifying a configured TMF audit trail on the primary system. 0 specifies the MAT. 1 through 15 specify auxiliary audit trails AUX01 through AUX15. If 0, the image trail specified in the subsequent ADD IMAGETRAIL command is managed by the master receiver; if 1 through 15, it is managed by the auxiliary receiver with that same ATINDEX value. The default value is 0. For information about protecting auxiliary audit trails, see Chapter 13 (page 271).
RDF State Requirements None. Usage Guidelines The SET MONITOR command enters the parameter values specified for the monitor in this command into the RDF configuration table in memory. This table serves as an input buffer only, and so these values do not affect the subsystem until they are applied to the RDF configuration file with the ADD command.
Usage Guidelines The SET NETWORK command enters the RDF network parameter values specified in this command into the RDF configuration table in memory. This table serves as an input buffer only, and so these values do not affect the subsystem until they are applied to the RDF configuration file with the ADD command.
For example, assume that you have lost the original primary system (\A), you have successfully completed a takeover on both backup systems (\B and \C), and the MAT positions displayed by the respective 735 messages are: \B: \C: 735 LAST MAT POSITION: Sno 10, Rba 100500000 735 LAST MAT POSITION: Sno 10, Rba 100000000 500 kilobytes of audit information is missing on \C.
these values do not affect the subsystem until they are applied to the RDF configuration file with the ADD command. Example To configure a purger process named $PRG to run in CPUs 0 and 1 with a RETAINCOUNT of 8, issue these commands: ]SET ]SET ]SET ]ADD PURGER PROCESS $PRG PURGER CPUS 0:1 PURGER RETAINCOUNT 8 PURGER By default, in this example the purger process will run at a priority of 165 and the purger purgetime is set to 60 minutes.
UPDATERTXTIME tx-time specifies the maximum transaction duration (in seconds, from 10 to 300) for all updater processes. The default is 60 seconds. RDF updaters operate in transaction mode. Updater transactions are essentially long-running transactions that pin audit-trail files on the backup system and can affect the duration of backout operations if an updater transaction aborts for any reason.
UPDATEREXCEPTION {ON | OFF} specifies the manner in which exception files are used. When set to ON (the default value), the updaters log an exception record for each and every audit record they must undo during a takeover. When set to OFF, the updaters log exception records only for the first and last audit records that must be undone (the minimum logging necessary to support Triple Contingency operation). LOCKSTEPVOL $volume specifies the primary system disk volume on which the RDF lockstep file (ZRDFLKSP.
The userid associated with OWNER must be a valid Guardian userid and must identify an existing user account on the RDF primary and backup systems. The OWNER must also be a member of the super-user group, which is a requirement in RDF for stopping and starting RDF. OWNER is an unalterable value. You need not change the value, unless you configured it incorrectly (in which case you must reinitialize RDF with the correct value).
Security Restrictions None. RDF State Requirements None. Usage Guidelines The SET RDFNET command enters the parameter values specified for the RDFNET process in this command into the RDF configuration table in memory. This table serves as an input buffer only, and so these values do not affect the subsystem until they are applied to the RDF configuration file with the ADD command.
RDFVOLUME $volume specifies which disk volume on the backup system is to be used for the receiver’s master image trail (the image trail to which the receiver writes all commit/abort records). The default is $SYSTEM. This attribute applies only to the master receiver (the receiver process configured with an ATINDEX value of 0). It is ignored for auxiliary receivers. For best performance, do not use $SYSTEM as the RDFVOLUME.
and so these values do not affect the subsystem until they are applied to the RDF configuration file with the ADD command. For ATINDEX values greater than 0, the specified value must match the audit-trail number of a configured auxiliary audit trail. If you specify SET RECEIVER ATINDEX 2, for example, there must be a configured auxiliary audit trail AUX02.
is mandatory. Typically program-file is $SYSTEM.SYSTEM.TACL if you want to run a TACL macro. Alternatively, program-file could be RDFCOM if no TACL macro is required. CAUTION: When using RDFCOM as the TRIGGER process, the control subvolume for the reverse RDF environment must be empty before the STOP RDF, REVERSE is issued. If it is not empty, RDF will not be able to initialize, and the reverse environment cannot be started.
SET TRIGGER CPU 0:1 SET TRIGGER PRIORITY 150 ADD TRIGGER REVERSE The RDF configuration on \RIGHT is contained in the file \RIGHT.$DATA01.RDFCONF. RIGHT (specified in the INFILE). That file includes these commands (the standard SET/ADD RDF, EXTRACTOR, RECEIVER, PURGER, IMAGETRAIL and VOLUME configuration commands are omitted): INITIALIZE RDF, BACKUPSYSTEM \LEFT, INITTIME NOW ! START RDF Initially, RDF runs from \LEFT to \RIGHT.
IMAGEVOLUME $volume identifies a disk volume associated with a secondary image trail previously added to the RDF configuration (by way of an ADD IMAGETRAIL command), implicitly associating this updater process with that trail. This parameter is required. There is no default. An updater must always be explicitly associated with a secondary image trail. UPDATEVOLUME $volume specifies what volume on the backup system will receive database updates for the corresponding volume on the primary system.
Furthermore, RDF objects with a particular ATINDEX value greater than 0 must together constitute a complete set: • • • If there is an extractor with an ATINDEX value of 1, there must also be a receiver with an ATINDEX value of 1. If there is a receiver with an ATINDEX value of 1, there must also be a secondary image trail with an ATINDEX of 1.
Suppose that another volume on the primary system is named $DATA02 and you want to create an updater process named $U02 to replicate changes to only those tables and files on $DATA02 whose subvolume name begins with OEM2 or OEM5.
RDF State Requirements You can enter the SHOW command at any time. Usage Guidelines This command retrieves information from the RDF configuration memory table, which serves as an input buffer for a subsequent ADD command. If you have not yet issued any SET commands for the specified object, or have issued a RESET command for it, the SHOW command displays the default option values for the object. If you want to see what parameter values are already set in the configuration file, use the INFO command.
RECEIVER RECEIVER RECEIVER RECEIVER RECEIVER EXTENTS (1000,1000) PRIORITY 165 RDFVOLUME $IMAGE SLOWMODE OFF PROCESS $REC RDFCOM includes the line containing PROCESS process-name in the display only if the process name was specified in a SET command. SHOW PURGER Command Suppose that a series of SET PURGER commands specifies that a purger process named $PURG is to run in CPUs 3 and 2 at priority 165 with a RETAINCOUNT of 50.
SHOW NETWORK Command Suppose that a series of SET NETWORK commands specifies \RDF04 as the network master’s primary system, \RDF06 as the network master’s backup system, RDF04 as the network master’s remote control subvolume, and $DATA07 as the network master’s PNETTXVOLUME volume.
If you have initialized the TMF and RDF subsystems before issuing the START RDF command, RDF automatically begins transmitting audit data from the beginning of the first audit-trail file. CAUTION: If you initialize RDF after a STOP RDF command is issued at the primary system, you might need to resynchronize the databases before restarting RDF.
Example To initiate updating on the backup system of all volumes protected by RDF, enter: ]START UPDATE STATUS The STATUS command displays current configuration information and operational statistics for the RDF environment, or specified portions thereof. All forms of the STATUS command, except STATUS RTDWARNING, automatically include information and statistics for the monitor process.
Security Restrictions None; anyone can enter a STATUS command. RDF State Requirement You can enter a STATUS command at any time after RDF has been initialized. Usage Guidelines The STATUS command provides you with the most current information about RDF and its operational status, presenting data for the specified RDF processes. STATUS RDF Command Output Display The STATUS RDF command presents its display in this format: RDFCOM - T0346A07 - 18JAN05 (C)2005 Hewlett-Packard Development Company, L.P.
For extractors, receivers, and image trails, the configured ATINDEX value is displayed in parentheses following the object name. In the above example, the extractor $RE00 and receiver $RR00 are associated with the MAT, while the extractor $RE01 and receiver $RR01 are associated with auxiliary audit trail AUX01. Because of insufficient space, however, ATINDEX values could not be displayed explicitly for updaters.
Pri The fourth column specifies the priority at which each process is running. Volume and Seqnce The fifth and sixth columns together specify a file associated with each process: • • • • • The monitor entry reflects the name of the MAT file to which TMF is writing ($AUDIT.ZTMFAT.AA000056 in this example). Each extractor entry reflects the name of the TMF audit-trail file from which it is reading ($AUDIT.ZTMFAT.AA000056 for the master extractor and $DATA17.ZTMFAT.
affected updater processes restart, the databases are probably still synchronized with one another. In that case, the asterisks are cleared from subsequent STATUS RDF displays. For more information on critical errors, you can scan the EMS collectors on the primary and backup systems: • • The EMS collector on the primary system contains log messages for the extractor and monitor processes. The EMS collector on the backup system contains log messages for the receiver, purger, and all updater processes.
RDF State Requirement You can issue the STOP LOCKSTEP command only if a LOCKSTEP command was issued previously. Usage Guidelines The STOP LOCKSTEP command is for use only in conjunction with a LOCKSTEP command under very specific circumstances. Issue this command only if your RDF environment has been specifically configured for lockstep protection and you have read all of the applicable text in Chapter 11 (page 261).
Where Issued You can issue the STOP RDF, DRAIN and STOP RDF, REVERSE commands only at the primary system. Security Restrictions You can issue the STOP RDF command if you are a member of the super-user group that initialized RDF and have a remote password from the RDF primary system to the backup. RDF State Requirement You can issue the STOP RDF, DRAIN and STOP RDF, REVERSE commands only while RDF is running and update is on.
Updaters cannot always respond immediately to a STOP RDF command. If an updater has audit information queued for the disk process, the updater must wait until all of that information is processed before it can shut down. If all else fails, you can shut down the individual RDF processes manually. When doing that, you must first stop the extractor on the primary system, then stop all updaters on the backup system, stop the purger on the backup system, and finally stop the receiver on the backup system.
Example To issue this command as part of online database synchronization, enter: ]STOP SYNCH STOP UPDATE The STOP UPDATE command suspends updating of the backup database and stops all updater processes. When all updater processes are stopped, RDF issues a 910 EMS message. STOP UPDATE [ , TIMESTAMP : ] If you use the stop-update-to-time version of this command, the TIMESTAMP parameter suspends updating at the specified time.
The STOP UPDATE command is useful when you want to produce reports from the database on the backup system. For more information, see “Reading the Backup Database” (page 140) and “Access to Backup Databases in a Consistent State” (page 140). If the STOP UPDATE command includes the TIMESTAMP parameter, RDFCOM returns a prompt as soon as all processes have been advised of the stop operation.
If you omit the exclamation point, RDFCOM prompts you to ensure that you really want to perform a takeover. If you answer yes (Y), RDFCOM attempts to contact the primary system. If the primary system responds, the TAKEOVER command is aborted immediately. If the primary system is inaccessible, Expand returns an error (which could take several minutes to happen). The "!" eliminates both the prompt and the subsequent delay.
affected data pointed to by the exception file. For information about using RDFSNOOP, refer to Appendix B, Additional Reference Information. If the failed primary system is eventually restored to operation, and you want it to function again as the primary system: 1. 2. 3. 4. 5. 6. 7. Stop the applications and TMF on the old backup system. Back up the database on the old backup system and restore it to the old primary system. Configure TMF on the old primary system. Initialize RDF on the old primary system.
UNPINAUDIT Where Issued Primary system only. Security Restrictions You can issue the UNPINAUDIT command if you are a member of the super-user group. RDF State Requirement You can only issue the UNPINAUDIT command while RDF is stopped. Usage Guidelines If the system at which you issue the UNPINAUDIT command is the primary system in more than one RDF configuration, then you must open the RDF control subvolume and issue another UNPINAUDIT command for each of the other RDF configurations as well.
Transaction processing need not be enabled on the primary system, however, when you enter the VALIDATE CONFIGURATION command. Whenever you issue a START RDF command, RDF automatically validates the configuration as though a VALIDATE CONFIGURATION command was explicitly issued. In response to a VALIDATE CONFIGURATION command, RDF verifies: • • • • • • • • • • • RDF global options are configured. RDF is initialized, and TMF is running on the primary system.
9 Entering RDFSCAN Commands All RDF messages are directed to an EMS event log (collector). To examine that log without looking at all events for the entire system, you first use the standard EMS filter RDFFLTO to create an intermediate entry-sequenced file copy of the RDF log, and then enter commands through the RDFSCAN online utility. This chapter, which is written for system managers and operators, describes the RDFSCAN commands and their attributes.
In addition, this element is included only if applicable: • Output Displayed: Only two RDFSCAN commands (LIST and SCAN) produce output, although others influence its content and destination. For information about the other elements, see “Command Description Elements” in Chapter 8 (page 173). Except for the LOG and NOLOG commands, you can abbreviate the command name by entering only the first character (such as L for LIST) or any number of the leading characters (such as DIS for DISPLAY).
OFF disables the display of record numbers. Usage Guidelines The DISPLAY function is automatically enabled if pattern matching is enabled and is automatically disabled if pattern matching is disabled. For information about enabling and disabling pattern matching, see the MATCH command description in “MATCH” (page 251). Examples Suppose that $SYSTEM.SANFRAN.
Examples If you issue an EXIT command in response to the RDFSCAN prompt, RDFSCAN terminates the session and displays a logoff message: Enter the next RDFscan function you want: Thank you for using RDFscan EXIT If you press Ctrl-Y in response to the RDFSCAN prompt, RDFSCAN terminates the session and displays an end-of-file indication followed by the logoff message: Enter the next RDFscan function you want: EOF! Ctrl-Y Thank you for using RDFscan FILE The FILE command selects a file generated by the RDFF
HELP [ ALL ] [ INTRO ] [ command ] ALL displays the syntax of all RDFSCAN commands. INTRO displays information on how to use the RDFSCAN utility. command displays the syntax of the RDFSCAN command indicated by command.
Output Displayed The LIST command displays the records in the file, including their record number (if the DISPLAY function is enabled) and the event logged in the record: the date and time of the event, the files involved in the event, and the event itself. Examples Suppose you want to display the first four messages (starting at record 500) that contain the match pattern $AU02.
NOTE: Do not confuse the file specified in the LOG command with the EMS event log that receives RDF messages and whose contents are displayed by the LIST command. For information about selecting the file for your session, see FILE command description in “FILE” (page 248). If the file specified by the LOG command does not exist, RDFSCAN creates an EDIT file of that name.
When pattern matching is enabled, the DISPLAY function is automatically enabled; when pattern matching is disabled, the DISPLAY function is automatically disabled. Table 9-1 shows the symbols RDFSCAN uses in pattern matching. Table 9-1 Pattern Matching Symbols in RDFSCAN Symbol Meaning * Zero or more characters correspond to this position. ? Any character can be in this position. Text Text in this exact position must match.
Enter the next RDFSCAN function you want: NOLOG File: $SYSTEM.SANFRAN.RDFLOG, current record: 9454, last record: 9466 Enter the next RDFSCAN function you want: SCAN The SCAN command scans a specific number of messages in the file and displays all of those in that range that contain the current match pattern. SCAN number number is the number of messages to scan within the log file.
Created in Processor 03 Record number: 1342 2004/06/08 04:13:49 \LAB1 $AU02 718 Switched to original Primary Processor Record number: 1792 2004/06/08 05:01:35 \LAB1 $AU02 790 Backup Process Created in Processor 03 Record number: 1933 2004/06/08 05:01:35 \LAB1 $AU02 718 Switched to original Primary Processor File: $SYSTEM.SANFRAN.
10 Triple Contingency The triple contingency feature makes it possible for your applications to resume running with full RDF protection within minutes after loss of your primary system. NOTE: Replication of network transactions is not supported in conjunction with the triple contingency feature, nor is the replication of auxiliary audit trails.
• • (that is, which system had received the least amount of audit data from the extractor by the time the primary system was lost). On the backup system that was further behind (had the least amount of audit data), issue the COPYAUDIT command specifying the name of the other backup system and its RDF control subvolume. That command copies over all missing audit records from the designated system. Upon successful completion of the COPYAUDIT operation, do a second takeover on that system.
It is strongly recommended, however, that the various RDF process priorities be identical on both backup systems so that the performance of the two systems is approximately the same. WARNING! If the two backup systems are configured differently from one another in any important regard, the triple contingency feature will not work when you need it, and there will be no advance warning to that effect.
(and therefore be eligible for purging), but, because the RETAINCOUNT is set to three, the purger process can only purge AA000010 (it must keep AA000011 and AA000012 on disk). Thus, as long as the RTD times of the extractors on the two backup systems are less than 36 hours apart, the triple contingency protocol will work successfully.
500 kilobytes of audit information is missing on \C. Because \C has the least amount of audit information, you must issue this command on \C: COPYAUDIT, REMOTESYS \B, REMOTECONTROLSUBVOL A1 For each image trail, RDFCOM on \C reads its own context file to determine the MAT position of the last audit record in the trail. RDFCOM then searches the corresponding trail on \B to find that audit record and performs large block transfers to move all audit records beyond that point to the trail on \C.
RDF Subsystem #2 \A ---------> \C Because the two subsystems run independently of one another, if system \A fails and you execute TAKEOVER commands on systems \B and \C, the two backup databases might not be synchronized with one another. The extractor for the \A-to-\B subsystem, for example, might have replicated audit data to system \B, but, before the extractor for the \A-to-\C subsystem could replicate the same data to system \C, system \A failed.
11 Subvolume-Level and File-Level Replication By default, RDF provides volume-level protection, wherein changes to all audited files and tables on each protected primary system data volume are replicated to an associated backup system data volume. RDF/IMP, IMPX, and ZLT also support subvolume-level and file-level replication. To use this capability, you supply INCLUDE and EXCLUDE clauses when configuring updaters to identify specific subvolumes and files you want either replicated or not replicated.
su*v.fname, *.fname, and *.*, for example, are not valid. But DB*.filename is valid because the asterisk is used as a subvolume name suffix. In this case, changes made to all audited files and tables on all subvolumes whose name starts with DB on the protected data volume are replicated. Within Filenames When used by itself as a filename, the * designates all audited files and tables on the specified subvolume.
SET VOLUME UPDATEVOLUME $DATA01 ADD VOLUME $DATA01 In the above example, all audited files and tables on \PRIMARY.$DATA01 are replicated to \BACKUP.$DATA01. Now consider this updater configuration example: SET SET SET SET SET SET SET SET SET SET ADD VOLUME VOLUME VOLUME VOLUME VOLUME VOLUME VOLUME VOLUME VOLUME VOLUME VOLUME CPUS 1:2 IMAGEVOLUME $IMAGE PRIORITY 185 PROCESS $MM01 UPDATEVOLUME $DATA01 INCLUDE MMTEST10.* EXCLUDE MMTEST10.CONC0826 INCLUDE DATA*.* EXCLUDE DATA*.C* INCLUDE DB*.
12 Subvolume Name Mapping RDF allows users to replicate data from primary system source subvolumes to differently named destination subvolumes on the backup system. However, the recommended configuration is still one-to-one mapping between source subvolumes on the primary system and their corresponding destination subvolumes on the backup system. One-to-one mapping ensures that each partition of a partitioned file or table is mapped to the correct backup subvolume.
• • • Volume names are not allowed in mapping strings. If the updater detects a $ character, it logs an error. Reserved names are not allowed in mapping strings. See the examples of invalid mapping strings listed below. When two or more mapping rules are present in a mapfile, the rule listed first always takes precedence if it fits. For example, assume these two mapping strings are present: MAP NAMES SUBVOL1.* TO SUBVOL2.* MAP NAMES SUBVOL*.* TO SUBVOL3.
How an Updater Manages Filename Collisions If you inadvertently map two subvolumes on the primary system to the same subvolume on the backup system for an updater, the updater detects the filename collision, logs EMS event 927, and abends. This approach prevents possible data corruption or disk failure. To illustrate how a filename collision might occur, assume that the mapping string for the updater that replicates from $DATA01 on the primary system to $DATA01 on the backup system is: MAP NAMES TEST1.
You can also alter the maplog file to a different path. For example: ALTER VOLUME $DATA01 MAPLOG $DATA05.NAPCONFG.MAPLOG2 If a maplog is not properly constructed or formatted, the updater generates errors. For information about maplog-related RDF event messages and RDFCOM error messages, see “RDF Messages” (page 342) and “RDFCOM Messages” (page 389).
To illustrate this problem scenario, assume these circumstances: • • • You create an audited, partitioned, key-sequenced file (Enscribe, SQL/MP, or SQL/MX) on the primary system where the primary and secondary partitions are on the same subvolume at $DATA01.SVOL.FILE and $DATA02.SVOL.FILE. One updater replicates the changes for the primary partition $DATA01.SVOL.FILE on the primary system to $DATA11.SVOL1.FILE on the backup system using this mapping string: MAP NAMES SVOL.* TO SVOL1.
13 Auxiliary Audit Trails In addition to the Master Audit Trail (MAT), RDF/IMPX and ZLT support protection of up to 15 auxiliary audit trails. If you want to protect data volumes associated with an auxiliary audit trail, you must configure an auxiliary extractor and an auxiliary receiver for that trail. Thus, for each auxiliary audit trail, there will be one auxiliary extractor-receiver pair. Auxiliary Extractor An auxiliary extractor can only be configured to a single auxiliary audit trail.
• • It is an error if the specified atindex does not correspond to a valid index of a configured auxiliary audit trail. That is, if you have configured two TMF auxiliary audit trails with the respective audit-trail numbers of 1 and 2, you cannot configure an auxiliary extractor with an atindex value of 3. It is an error to specify two extractors or two receivers with the same atindex value.
If an auxiliary extractor is running behind the master extractor when you issue a STOP TMF command, the TMF shutdown operation cannot complete until the auxiliary extractor has caught up with the master extractor. When that happens, RDF (or more specifically, the master receiver process) might falsely appear to be hung. As soon as the auxiliary extractor has caught up, however, the TMF shutdown operation proceeds.
14 Network Transactions The RDF/IMPX and RDF/ZLT products are able to guarantee backup database consistency for transactions that update data residing on more than one RDF primary system. RDF/IMPX and RDF/ZLT can map the volumes being protected to both the MAT and auxiliary audit trails. NOTE: Network transaction processing is currently not supported in configurations that use the triple contingency feature. You must use RDF/IMPX or RDF/ZLT to protect all databases open to network transactions.
5. 6. 7. Configure the network master subsystem with all the commands SET/ADD RDF, MONITOR, UPDATER, NETWORK, and so forth. Do not perform a VALIDATE CONFIGURATION yet. Issue a VALIDATE CONFIGURATION command on each non-network master subsystem. Issue a VALIDATE CONFIGURATION command on the network master subsystem. NETWORK Attribute This attribute, located in the RDF configuration record, specifies whether or not you are configuring an RDF network.
Thus, within its configuration file, the network master has all necessary information about every system in the RDF network (whereas the other systems have only a pointer enabling them to obtain information about other systems in the network). PRIMARYSYSTEM Network Attribute This is the name of a primary system. It is set by this RDFCOM command: SET NETWORK PRIMARYSYSTEM system-name There is no default value. Each primary system within an RDF network must be unique within the network.
$volume-name.subvolume-name.ZRDFNETX where volume-name is the configured PNETTXVOLUME network attribute and subvolume-nameis the configured REMOTECONTROLSUBVOLUME network attribute. RDF Network Control Files These control files exist in the Master Image Trail (MIT) subvolume of all RDF subsystems that are configured for replication of network transactions: ZRDFLCMT, ZRDFLCM2, and ZNETUNDO. Additionally, the network master has three more files: ZRDFNMTX, ZRDFNMT2, ZRDFNMT3.
Takeover Phase 2 – File Undo This undo phase only gets executed if volumes went down on the primary system, transactions were aborted, and the volumes were never reenabled on the primary system before the primary system was lost. In that situation, RDF determines what Backout could not undo, and runs the undo. Takeover Phase 3 – Network Undo Using RDF/ZLT, no undo operations are performed during the network undo phase because no committed transactions are undone.
Communication Failures During Phase 3 Takeover Processing If one RDF subsystem is unable to reach the backup system of another RDF subsystem during phase 3 processing, phase 3 processing stalls until the communication line comes back up. This can lengthen the overall duration of takeover operations on all backup systems. Should this type of stall occur, the RDF subsystem issues an event message alerting operators to the situation.
In the past you would have had to synchronize your entire primary and backup databases. That could be a lengthy task. Now you can simply use TMF file recovery to a MAT position. If you execute this operation on your primary system using the MAT position specified in the RDF event 888 message (see the description of message 888 in Appendix C (page 335)), it brings the primary database into the exact same state that the backup database was in upon completion of the RDF takeover.
Assume that the primary system \B goes down after having transmitted the commit record for T13 to its backup system \Y. At that point \Y has the commits for T10, T13, T20, T21, T22 and T36. \Y only has to perform local undo (during which T12 is undone). The purger on \X (the network master) determines that the first transaction requiring network undo is T12 because that transaction was active on both \A and \B when \B went down.
NOTE: If you have local transactions that do not touch data involved in network transaction activity, and you do not want these local transactions undone just because data might be missing for the network transactions during a takeover operation, you are advised to configure separate RDF subsystems: one to protect just the data involved in network transaction activity, and the second to protect the non-network data. Of course, both sets of data must have no dependencies on the other.
NOTE: It is strongly recommended that you validate the configurations of all RDF subsystems in your RDF network with the RDFCOM VALIDATE CONFIGURATION command before you attempt to start any. This would then guarantee that your entire RDF network is configured correctly before you start any of the individual RDF subsystems. RDF Reinitialization in a Network Environment For any number of reasons you might choose to stop some of your RDF network subsystems and reinitialize them.
one of them is down and the RDFNET process is tying up the orderly shutdown of RDF, stop the RDFNET process manually. CAUTION: If you stop any RDF subsystem in an RDF network, you could lose large amounts of committed data in the event of an unplanned outage. RDF Networks and Stop-Update-to-Time Operations Stop-update-to-time operations affect only the backup database of the particular system on which they are initiated.
SET SET SET ADD EXTRACTOR PRIORITY 185 EXTRACTOR PROCESS $MEX1 EXTRACTOR RTDWARNING 60 EXTRACTOR SET SET SET SET SET SET SET ADD RECEIVER RECEIVER RECEIVER RECEIVER RECEIVER RECEIVER RECEIVER RECEIVER SET SET SET SET SET ADD PURGER PURGER PURGER PURGER PURGER PURGER ATINDEX 0 CPUS 3:2 EXTENTS (100,100) PRIORITY 185 RDFVOLUME $DATA11 SLOWMODE OFF PROCESS $MR41 CPUS 3:2 PRIORITY 185 PROCESS $RP40 RETAINCOUNT 5 PURGETIME 60 SET IMAGETRAIL ATINDEX 0 ADD IMAGETRAIL $DATA06 SET SET SET SET ADD NETWORK NE
ADD RDF SET SET SET ADD MONITOR CPUS 1:2 MONITOR 185 MONITOR PROCESS $MMON MONITOR SET SET SET SET SET ADD EXTRACTOR EXTRACTOR EXTRACTOR EXTRACTOR EXTRACTOR EXTRACTOR SET SET SET SET SET SET SET ADD RECEIVER RECEIVER RECEIVER RECEIVER RECEIVER RECEIVER RECEIVER RECEIVER SET SET SET SET SET ADD PURGER PURGER PURGER PURGER PURGER PURGER ATINDEX 0 CPUS 1:2 PRIORITY 185 PROCESS $MEX1 RTDWARNING 60 ATINDEX 0 CPUS 3:2 EXTENTS (100,100) PRIORITY 185 RDFVOLUME $DATA11 SLOWMODE OFF PROCESS $MR51 CPUS 3:2 P
Monitor Extractor Receiver Imagetrail Purger RDFNET $DATA07 -> (0) (0) (0) $RP40 $MNET $DATA07 $RU43 ] 288 $MMON $MEX1 $MR41 Network Transactions 185 $DATA23 0:00 185 $DATA23 0:00 185 $DATA11 $DATA06 185 165 0:08 185 $DATA06 1 1 1 3 2 1: 2 7190796 1: 2 3: 2 3: 2 0: 2 2809724 1: 2
15 Process-Lockstep Operation The RDF/IMPX and RDF/ZLT products include the process-lockstep operation, which is process-based. That is, when a process invokes the lockstep operation for a business transaction, the process must wait until all audit records associated with that business transaction are safely stored in image trails on the backup system before continuing.
The DoLockstep Procedure How you invoke the DoLockstep procedure differs depending on whether your applications are written in COBOL or TAL. Including the DoLockstep in COBOL85 Applications To invoke the DoLockstep procedure from a COBOL85 program, you must first include the DoLockstep object module in the SPECIAL-NAMES paragraph in the CONFIGURATION section. CONFIGURATION SECTION. SOURCE-COMPUTER. HP NONSTOP. OBJECT-COMPUTER. HP NONSTOP. SPECIAL-NAMES. FILE "$vol.subvol.LSLIBTO" IS LOCKSTEP-LIB.
When the RDF receiver has flushed all audit records up to and including the lockstep audit into the image trail, it replies to the extractor that the lockstep data is safe. When the extractor receives that information, it replies to the gateway which, in turn, passes status back to the DoLockstep call, and the latter then returns status to the application.
Multiple Concurrent Lockstep Operations Because DoLockstep suspends the calling application until the associated lockstep transaction commits on the backup system, a single application process cannot have more than one lockstep operation in progress at any one time. Multiple application processes, however, can invoke DoLockstep concurrently.
STARTUPMSG This attribute must include the process name of your RDF extractor (for example, STARTUPMSG "ENABLE $MEXT"). The startup message must also include either ENABLE or DISABLE as the first parameter. Failure to include either of these parameters will cause the gateway to stop. The gateway can only communicate with one extractor. If you have multiple RDF subsystems using the same node as their primary system, only one of them can execute lockstep operations.
transaction is in progress, the RDF gateway merely queues the request. Consequently, if an application process issues a DoLockstep request immediately after the gateway has started a lockstep transaction, that request must wait to be performed until the current lockstep transaction is committed on the backup system. That could also increase response times. Lockstep and Auxiliary Audit Trails You cannot use lockstep processing in an RDF subsystem that is protecting auxiliary audit trails.
16 NonStop SQL/MX and RDF RDF supports replication of NonStop SQL/MX user tables (file code 550) and indexes (file code 552). These operations are supported in much the same way as they are with NonStop SQL/MP, and the same types of data and DDL operations are replicated.
Table 16-1 ANSI Object Types and Their ANSI Space Name Identifiers (continued) ANSI Object Type ANSI Name Space Identifier Refresh Group RG Table TA Temporary Trigger Table TT Trigger TR User Defined Routine UR Obtaining ANSI Object Names From Updater Event Messages Updater event messages list Guardian filenames. If an updater generates an event against an MX object (subvolume name starts with ZSD), you can obtain the ANSI name of the object by issuing aFUP INFO guardian-name, DETAIL command.
4. Create the schema on the primary system. If you do not use the LOCATION clause, NonStop SQL/MX will set the subvolume itself. In that case, you must query NonStop SQL/MX to obtain the subvolume name because the subvolume name is needed when creating the schema on the backup system. If you specify the LOCATION clause, the subvolume name must start with "ZSD" and the entire name must be eight characters in length.
You should specify only the desired volume to allow NonStop SQL/MX to generate the complete Guardian filenames. This is true for non-partitioned objects as well as for partitioned objects. Thus, you specify only the volume name in the LOCATION clause, and NonStop SQL/MX constructs the fully qualified Guardian name for the object, using: • • • The volume you specified for the object in the LOCATION clause.
7. Create each object on the backup system. The ANSI name of the object must be constructed as follows: • • • catalog name: use the name of the backup catalog you created in Step 2. schema name: use the name you used in Steps 4 and 5. table or index name: must match on the primary and backup systems. This command creates a table called TAB1 in the schema BCAT.SCH, with three partitions, located on volumes $data02, $data13, $data14, respectively. CREATE TABLE BCAT.SCH.
the name of the subvolume used for the schema on the primary system, then you must query the primary system to obtain the Guardian subvolume name, and you must use the Guardian subvolume name with the LOCATION clause here. See “Creating NonStop SQL/MX Primary and Backup Databases From Scratch” (page 296). 3. 4. If you want each catalog to be seen from both systems, register your primary and backup catalogs.
6. At the backup system, use the RESTORE utility to place the objects on the backup system, specifying the ANSI names for the backup system. Use the LOCATION clauses to have RESTORE place the objects in the correct Guardian locations. See “Restoring to a Specific Location” for general restore syntax for NonStop SQL/MX databases. For example, assume you have the objects on your primary system that have these fully qualified Guardian names: \pnode.$DATA01.ZSDABCDEF.FILE100 \pnode.$DATA02.ZSDABCDEF.
name for the -node option. Alternatively, you can use the SHOWDDL command to obtain the fully qualified filenames of the objects you want replicated and specify the same Guardian subvol.filenames in the corresponding LOCATION clauses when creating the temporary objects. For example, suppose you have a primary table that has two partitions, for which you want make a fuzzy copy, and the fully qualified Guardian names are: $DATA01.ZSDABCDE.HWEFGH00 $DATA02.ZSDABCDE.
Creating the Fuzzy Copy on the Backup System The advantage of this method is that it eliminates the use of temporary objects as well as tape handling because you create your backup objects directly on the backup system. The disadvantage is that it requires you to load the data from your primary objects to your backup objects over Expand lines, which might take longer than the alternate method given above if the data is great in size. To create the fuzzy copy on the backup system, perform these steps. 1. 2.
Indirectly From the Primary to the Backup By Way of a Temporary File If the number of rows to load over the network is too great, you can use a temporary file on the primary system: 1. 2. 3. 4. Create a temporary catalog on your primary system to correspond to your regular catalog on your primary system whose objects you want RDF to replicate. Create a temporary schema for your temporary catalog.
(page 303), and then load the data into the backup partition using the INSERT statement also described in that topic. Correcting Incorrect NonStop SQL/MX Name Mapping Primary and Backup ANSI Catalog Are the Same If you created the primary and backup catalogs and used the same name for both, you cannot use the REGISTER CATALOG command to make either catalog visible on the other system.
At some point in the future when ANSI names are supported, CREATE LIKE will be a viable means of creating backup or temporary tables, but until then the following discussion has the utmost significance. NonStop SQL/MX will store data in rows on disk in a private format, which does not necessarily correspond to the sequence in which the user specifies columns on CREATE TABLE.
4. 5. 1. 2. You are restoring four tables from two different schemas in catalog PCAT. Schema information: Primary schema name Schema subvolume Backup schema name PCAT.MYSCHEMA ZSDAAAAA BCAT.MYSCHEMA PCAT.MYSCHEMAX ZSDBBBBB BCAT.MYSCHEMAX Table and Index information: Table or Index Name Guardian Names for partitions and indexes PCAT.MYSCHEMA.MYTABLE1 PCAT.MYSCHEMA.MYINDEX1 \P.$data01.ZSDAAAAA.HEBFRW00 \P.$data02.ZSDAAAAA.HEBFRX00 \P.$data03.ZSDAAAAA.HEBFRY00 \P.$data02.ZSDAAAAA.YREWPO00 PCAT.
Comparing NonStop SQL/MX Tables While the unsupported RDFCHEK utility program can be used to compare Enscribe files or NonStop SQL/MP tables, it cannot be used to compare NonStop SQL/MX tables. If you need to compare a NonStop SQL/MX table on your primary against a NonStop SQL/MX table on your backup system, for example, one method of doing so islows: 1. 2. 3. Use the NonStop SQL/MX Select statement to select all rows in the primary table, and then store them in an Enscribe entry-sequenced file.
17 Zero Lost Transactions (ZLT) Zero Lost Transactions (ZLT), functionality that is available only with the RDF/ZLT product, ensures that no transactions that commit on the primary system are lost on the RDF backup system if that primary system is downed by an unplanned outage. RDF achieves this though the use of remote mirroring for the relevant TMF audit-trail volume(s).
Figure 17-1 ZLT Configuration With a Single Standby/Backup System Figure 17-2 shows the configuration where a single system serves as both the standby and backup systems, and the remote mirror is located at an intermediate site. Figure 17-2 ZLT Configuration With a Single Standby/Backup System and With the Remote Mirror Located at an Intermediate Site Figure 17-3 shows the configuration where individual standby and backup systems are located at separate sites.
Figure 17-3 ZLT Configuration With Standby and Backup Systems Located at Separate Sites If the standby and backup systems are not one and the same, you must remember to set up remote passwords between the standby and backup systems. You must do so with the same userid that has control over starting and stopping RDF. If you lose your primary system due to an unplanned outage, you connect the remote mirrors to the standby system, and then initiate a takeover operation on the backup system.
If you want ZLT protection, you must configure your audit trails with the COMMITHOLDMODE attribute set to on. Doing so causes each write to the audit trail to be directed to the remote audit-trail disk first. If that write fails for any reason, TMF activates commit-hold mode. If CommitHoldMode mode is activated, TMF stops all further commit operations.
system, the monitor places the primary processes of three extractors on one CPU and the primary processes for the other three extractors on the other CPU. If the monitor process selects the primary CPU of an extractor and the configured backup CPU is not available on the standby system, then the extractor does not run as a process pair; it only has the primary process.
volume-name must be a valid volume name specified in the current TMF configuration on your primary system. Use a SET statement for each individual volume. You do not need to specify whether the volume is an active volume, restore volume, or overflow volume; you merely specify the volume name. The list of volumes you specify is placed in the extractor configuration record. When you ADD the extractor attributes, RDFCOM checks to ensure that each configured volume is a valid volume.
it has completed its ZLT task. When all extractors are finished, they are terminated and deleted. Upon receiving the “ZLT finished” indication, each receiver logs an event (903) reporting it has completed its ZLT task, and tells its updater to commence normal takeover operations. When all receivers have finished their ZLT processing, the overall takeover operation proceeds to phase 2.
RDFCOM INFO and SHOW Commands The INFO command output includes the RDF and extractor configuration attributes for ZLT, as does the output for the SHOW command. Old Audit-Trail Files When a ZLT takeover operation completes, you should not purge the old audit-trail files on the remote mirrors connected to the standby system if you believe you can recover the primary system. The old audit-trail files are necessary for recovering the primary system.
1. Determine which disks (the local disk on the primary system or the remote mirror on the standby system) for all audit trails in the RDF configuration received the most audit records. The example that follows shows how to do so for the MAT. If your RDF configuration includes one or more auxiliary audit trails, you must do the same for each auxiliary audit trail.
e. Start TMF. When startup is complete, the database on the primary system contains the same data that the database on the backup system had at the conclusion of the RDF takeover operation. If any local disk (the MAT or any auxiliary audit trail) has more audit records than the corresponding remote mirror (this can only happen if CommitHold was not configured or was configured but disabled on the primary system when the outage occurred): f. g. h. i. j. 3.
A RDF Commands Quick Reference The syntax rules for the RDFCOM and RDFSCAN commands, explained in detail in Chapter 8 (page 173) and Chapter 9 (page 245), are summarized in this appendix. This appendix, which is written for system managers and operators, summarizes the syntax descriptions for: • The command to run RDFCOM from the Guardian user interface to the NonStop operating system. See “RDFCOM Run Syntax”. • The RDFCOM commands, listed in alphabetical order, beginning with the ADD command.
{PURGER {RDFNET {TRIGGER {VOLUME purger-option } netsync-option } {trigger-type } {trigger-option } } updater-option } COPYAUDIT The COPYAUDIT command copies missing audit information from the backup system that has the most to the backup system that has the least. This command is only for use with the triple contingency feature. Where Issued: Backup system only (the backup system with the least amount of audit information).
Where Issued: Primary or backup system. Security: Any user. HISTORY INFO The INFO command displays the current configuration parameter values from the configuration file for the specified process or other object. Where Issued: Primary or backup system. Security: Any user.
Security: Any user. OUT [\system.][$volume.][subvolume.][file] RESET The RESET command resets all configuration parameters for the specified process to their default values within the RDF configuration memory table. The corresponding parameters within the configuration file do not change, however, unless you issue an ADD command. Where Issued: Primary system only. Security: Super-user group member.
{PRIORITY priority {PROCESS process-name } } SET NETWORK The SET NETWORK command sets RDF network configuration parameters within the RDF configuration memory table. The supplied values are not applied to the RDF configuration file, however, until you issue an ADD NETWORK command. Where Issued: Primary system only. Security: Super-user group member.
SET RDFNET The SET RDFNET command sets the designated configuration parameters for the RDFNET process to the supplied values within the RDF configuration memory table. The supplied values are not applied to the RDF configuration file, however, until you issue an ADD command. Where Issued: Primary system only. Security: Super-user group member.
where volume-option is: {ATINDEX atindex {CPUS primary-CPU : backup-CPU {PRIORITY priority-number {PROCESS process-name {IMAGEVOLUME volume {UPDATEVOLUME volume {INCLUDE subvol.file {EXCLUDE subvol.file {MAPFILE $vol.subvol.file {MAPLOG $vol.subvol.file } } } } } } } } } } SHOW The SHOW command displays the current parameter values contained in the RDF configuration memory table for the specified process.
{RTDWARNING {RDFNET } } STOP RDF The STOP RDF command shuts down the RDF subsystem. Where Issued: Primary or backup system (can be issued on the backup system only when all communications lines to the primary system are down). Security: Super-user group member with remote password from the primary system to the backup. STOP RDF { [, DRAIN ] } { [, REVERSE ] } STOP SYNCH The STOP SYNCH command is used as part of the online database synchronization protocol.
RDFSCAN Commands Quick Reference RDFSCAN runs under the Guardian user interface (normally the TACL command interpreter) to the NonStop operating system. The RDFSCAN command starts an RDFSCAN session that lets you enter RDFSCAN commands interactively, noninteractively, or through a command file. Where issued: primary or backup system. Security: Any user. RDFSCAN [ file ] AT The AT command specifies the record in the RDF log file at which RDFSCAN begins the next operation.
NOLOG The NOLOG command disables LIST command copying that was previously enabled by a LOG command. NOLOG SCAN The SCAN command scans a specific number of messages in the log file and displays all of those in that range that contain the current match pattern. SCAN number File Names and Process Identifiers File names and process identifiers sometimes appear as parameters in RDFCOM and RDFSCAN commands. These names typically identify objects such as disk files, log devices, and processes.
B Additional Reference Information This appendix provides additional reference information about: • “Default Configuration Parameters” • “Sample Configuration File” (page 330) • “RDFSNOOP Utility” (page 332) • “RDF System Files” (page 333) • “RDF File Codes” (page 334) Process names are also reserved: $X* , $Y* , and $Z*. Certain keywords in the NonStop SQL/MP product are reserved words in SQL commands. Those reserved words are listed in the SQL/MP Reference Manual.
Parameter Default Value(s) MIN MAX TRIGGER WAIT WAIT n.a. n.a. TRIGGER NOWAIT WAIT n.a. n.a. PURGER CPUS 0:1 0 15 PURGER PRIORITY 165 10 199 PURGER PURGETIME 60 30 1440 PURGER RETAINCOUNT 2 2 5000 VOLUME ATINDEX 0 0 15 VOLUME CPUS 0:1 0 15 VOLUME PRIORITY 160 10 199 VOLUME UPDATEVOLUME $SYSTEM n.a. n.a. VOLUME IMAGEVOLUME RECEIVER RDFVOLUME n.a. n.a. VOLUME MAPFILE none n.a. n.a. VOLUME MAPLOG none n.a. n.a.
| *** ADD RECEIVER | *** | *** Add secondary image trails. | *** ADD IMAGETRAIL $SECIT1 ADD IMAGETRAIL $SECIT2 | | | | | | | | *** *** *** *** *** *** *** *** SET SET SET SET SET SET SET | | | | | Set the updater parameters for the first volume to be protected by the RDF product. $U01 is the name of this updater. Volume $DB1 on the backup node corresponds to the volume $DB01 on the primary node. This updater will use the secondary image trail SECIT1.
| | | | | | *** *** *** *** *** *** SET SET SET SET | | | | | $DB3 on the backup node corresponds to the volume $DB03 on the primary node. Note that the IMAGEVOLUME parameter is omitted; it defaults to $SECIT2 because it was not reset after the previous ADD VOLUME command. VOLUME VOLUME VOLUME VOLUME CPUS PRIORITY UPDATEVOLUME PROCESS 2:1 160 $DB3 $U03 *** *** Add the RDF updater parameters for *** the third updater process to the *** configuration file.
RDF System Files The following files are created by the RDF subsystem and used by RDF processes: • Configuration file This is a key-sequenced file with record length 4062. The configuration file contains an internal representation of the configuration parameters that are set through RDFCOM commands. The configuration file resides on both the primary and backup node; on both nodes, the configuration file is named: $SYSTEM.control-subvolume.
• ZFILEINC file This is a key-sequenced file that stores information about transactions and files involved in transactions that aborted on the primary system, but TMF Backout could not undo the audit because the volumes were down. A record for each transaction and file is stored in the ZFILEINC file. If a volume is re-enabled on the primary system and TMF Backout is able to undo the audit data it could not previously undo, then the corresponding records are removed from the ZFILEINC file.
C Messages This appendix describes the lockstep gateway messages and all messages generated by RDF. The RDF subsystem produces three general types of messages: • “Lockstep Gateway Event Messages”, which are reported during NEED INFO HERE.
Effect The lockstep gateway stops. Recovery In your SCF script for starting the lockstep gateway, you must specify either ENABLE or DISABLE and the RDF extractor process name with the STARTUPMSG attribute. The process name must not include a node name. 3 The first argument of the STARTUPMSG attribute for your lockstep gateway was neither ENABLE nor DISABLE. Cause You did not specify ENABLE or DISABLE as the first argument of the STARTUPMSG attribute in your SCF script. Effect The lockstep gateway stops.
Recovery Correct the error condition and restart the lockstep gateway. 7 Open error errnum on filename. errnum is a file-system error number. filename is the name of a lockstep file. Cause The lockstep gateway received the specified error while attempting to open the specified lockstep file. Effect The lockstep gateway stops. Recovery Correct the error condition and restart the lockstep gateway. 8 Error errnum received when attempting to obtain info on file filename. errnum is a file-system error number.
Recovery Either the file was not created by the lockstep process, or the audit attribute was erroneously turned off. Purge the file and restart the lockstep gateway. 12 Invalid message-id msgid returned from RDF extractor. msgid is the invalid message id. Cause The lockstep gateway sent a request to the RDF extractor, and the latter returned the included message id number. Effect The lockstep gateway stops. Recovery This is an internal error, but the gateway is restarted.
17 Open error errnum on $RECEIVE. errnum is a file-system error number. Cause The lockstep gateway received the specified error when attempting to open $RECEIVE. Effect The lockstep gateway stops. Recovery This is an internal error, but the gateway is restarted. If the problem persists, contact the Global Mission Critical Solution Center (GMCSC) or your service provider. 18 Filename formatting error errnum. errnum is a file-system error number.
errnum is a file-system error number. procname is the name of an extractor process. Cause The specified error was returned when the lockstep gateway attempted to open the RDF extractor. Effect The gateway continues trying to open the extractor and will repeat this message every five minutes until the open is successful. Recovery This is an informational message. If you want lockstep operations to resume, and if your RDF subsystem is not currently running, you must restart the subsystem.
Recovery This is an informational message; no recovery is required. 27 Lockstep Gateway Started. Cause The lockstep gateway is started. Effect The lockstep gateway continues its initialization activity. Recovery This is an informational message; no recovery is required. 28 RDF extractor procname responded with error errnum to lockstep request. procname is the name of an extractor process. errnum is a file-system error number.
32 A spurious STARTUPMSG argument was encountered for the lockstep gateway. Cause In your SCF script for starting the lockstep gateway, the STARTUPMSG attribute contained an extra or unrecognizable argument. Effect The lockstep gateway stops. Recovery The STARTUPMSG attribute must include exactly two arguments: the word ENABLE or DISABLE, and a valid RDF extractor process name, all enclosed in quotes.
filename is the Guardian file name of the file that encountered the error. sno is the sequence number of the file that encountered the error. rba is the relative byte address within the file where the error occurred. Cause A file-system error occurred. The message includes both the file-system error number and the name of the file or table that encountered the error. Effect Variable; depends on which file-system error occurred.
Effect The updaters are stopped, but the backup database is not in a consistent state corresponding to the stop update timestamp. Recovery Restart the updaters. If you still need to bring the backup database to a consistent state, do the following. Wait for the updaters to catch up and then issue a new stop update to time command, specifying a new timestamp.
707 TMF is not yet started Cause The extractor detected that TMF has not been started yet. Effect RDF cannot run if TMF is not also running. Normally RDFCOM will recognize that TMF has not been started and will prevent RDF from starting. In the case of an RDF 707 event, TMF was running when RDFCOM verified that TMF was started, but TMF was then stopped before the extractor was started. If the extractor detects that TMF is not started, it aborts itself, and the monitor aborts the receiver and itself.
Cause The monitor encountered an error while attempting to create an RDF process. The error fields reported in the message are the upper and lower bytes of the status returned by the NEWPROCESS system procedure followed by the filename of the program that was to be run. Effect The process is not started, and RDF shuts down. Recovery See the description of the NEWPROCESS procedure in the Guardian Procedure Errors and Messages Manual to determine the cause of the failure.
Effect The backup process takes over, but not in fault-tolerant mode, until the primary process can be re-created. Recovery Scan the EMS event log to determine why the process abended. An INSPECT SAVEABEND file should have been created in the volume and subvolume where you placed the RDF/IMP software; you should save that file for problem resolution by your service provider. 717 Primary processor down Cause The primary CPU of a NonStop process pair has stopped.
Effect This is only a warning. Normal processing continues. It is possible, however, that the backup database is no longer consistent with the primary database. Recovery This is an informational message; no recovery is required. Tell your database administrator that this error occurred. The database administrator should consider checking the synchronization of the primary and backup databases.
Recovery If UPDATE was OFF at the time of the RDF TAKEOVER, then a second RDF TAKEOVER operation is automatically started, and no recovery is required. Otherwise, you must restart the takeover operation with the RDFCOM TAKEOVER command. 726 Updater did not complete the TAKEOVER vol => vol vol => vol are the volume on the primary node that the updater is protecting and the corresponding volume to which it is writing on the backup node.
731 RDF monitor started Cause The operator issued a START RDF command. Effect The RDF monitor process is running and starting up the other RDF processes. Recovery This is an informational message; no recovery is required. 732 Unable to create exception file filename, error error filename is the name of the exception file that the updater was trying to create. error is the file-system error number that identifies the specific error.
processname is the name of the process that sent the message. programfile is the name of the object file from where the process that sent the message was started. Cause An RDF process received a message that does not apply to it. This message is a warning that indicates a possible problem in the configuration file, a programming problem within RDF, or that a process outside of RDF tried to communicate with an RDF process.
Effect The updater delays for 30 seconds and then tries to obtain the information again. Recovery If the specified file is an Enscribe file, you must create the file on the backup system. You should always create SQL objects on the backup system first and then create them on the primary system. 737 RDF extractor establishing synch Cause When the extractor is starting or restarting, it must send a request to the receiver to obtain its starting position in the TMF audit trail.
Recovery For partitioned files and files with alternate keys, if any partition or alternate key file is on a volume protected by RDF, then all partitions and alternate key files must be on volumes protected by RDF. Either the file must be redefined on the primary node, or the other volume must be made protected by RDF. In the latter case, the backup file must then be resynchronized with the primary file.
745 Audit record conversion error error error is the error number. Cause The extractor encountered the specified error while attempting to convert an audit record from one version to another. Effect The extractor abends, thereby stopping the other RDF processes. Recovery This is an internal error. Contact your service provider. 746 Error during program initialization Cause A fatal error occurred during RDF subsystem initialization. Effect RDF stops. Error 743 should follow this message.
Recovery Issue a STOP RDF command immediately. Then investigate why there is a shortage of TLEs in the CPU of the RDF process that could not obtain one. If you want to start RDF again while conducting this investigation, you should alter the RDF configuration of the process that could not obtain the TLE, specifying a different set of CPUs. 751 FILE_OPEN_CHKPT_ error error on filename error is the file-system error number that identifies the specific error.
754 Network restored - continuing service Cause The primary system processes have determined that the communications lines have been restored. The extractor is now able to communicate with the receiver. Effect Processing continues from the point at which the network failed. Recovery This is an informational message; no recovery is required.
Alternatively, if the record was associated with a PURGEDATA or increase to MAXEXTENTS, the operation is not replicated on the backup system. Recovery If the record was associated with an Enscribe create, you must manually create the file on the backup system. If the record was associated with a PURGEDATA or increase to MAXEXTENTS, you must issue the STOP UPDATE command and then perform the operation manually on the backup system.
Cause The RDF monitor process detected an internal inconsistency regarding RDF’s understanding of an SQL shared access operation. Effect The monitor abends. Recovery This is an internal error. Contact your service provider. 765 Invalid audit record encountered [, type record-type ] Cause The updater process has sent an audit record to the disk process that is the wrong version to the disk process that is in the wrong version. The record type is included in the message if it is available.
Cause The receiver has successfully completed its initialization. Effect The receiver is prepared to receive data from the extractor. Recovery This is an informational message; no recovery is required. 772 TMF is not running on the remote system Cause The receiver has determined that TMF is not started on the RDF backup system. Effect The receiver abends. Recovery Start TMF on the backup system and then restart RDF.
Recovery This is an internal error. If no database synchronization operation was in progress, you must restart RDF. If a database synchronization operation was in progress, you must restart the entire operation from the beginning. 778 Remote RDF updater shutdown complete Cause The updater has terminated normal processing as the result of a STOP TMF, STOP RDF, STOP UPDATE, or TAKEOVER command. Effect Normal RDF shutdown processing continues.
If the process is an updater, then the backup database is synchronized for the volume protected by the particular updater. Recovery This is an informational message; no recovery is required. 783 RDF receiver process is not running Cause The monitor or extractor process could not open the remote receiver process after a communications failure. Effect If the monitor or extractor process receives a file-system error 14 (process does not exist), RDF will shut down on the primary node.
rba is the relative byte address where the error occurred. Cause The receiver or an updater has encountered the indicated error while attempting to position into an image file. Effect The process abends. Recovery Correct the problem that caused the error and then restart RDF. 788 ALLOCATESEGMENT failure. Returned status status status is a status code reflecting information about the error. Cause An RDF process received an error from the ALLOCATESEGMENT system procedure.
797 Warning - Image file purge error error# on filename [File is currently opened by proc-id, program-filename] error is the file-system error number that identifies the specific error. filename is the name of the image file associated with the error. proc-id is the process ID of the opener process. program-filename is the program filename of the opener process. Cause The purger process could not purge an image file that is no longer needed.
Cause An RDF process encountered an error while attempting to read an image file. Effect This is a catastrophic error; the process abends, and RDF stops. The message includes the error number returned by the READ system procedure, followed by the file name. Recovery Restart RDF. If the condition persists, you might have to reinitialize RDF. Preserve the designated image file and report the problem to your service provider.
Effect The RDFNET process aborts its current transaction, posts a timer, and waits for that timer to expire before attempting a new transaction. Recovery You should determine the cause of the error and take appropriate corrective action. 804 READUPDATELOCK error error on filename error is the file-system error number that identifies the specific error. filename is the name of the file on which the error occurred. Cause The RDFNET process has encountered the specified error on the specified file.
Effect The RDF process stops normally. Recovery This is an informational message; no recovery is required. 810 Shutting down in response to STOP TMF, timestamp timestamp timestamp is the time of the shutdown. Cause The operator issued a TMFCOM STOP TMF command at the primary node. timestamp is the time of that shutdown. Effect The RDF process stops normally. Recovery This is an informational message; no recovery is required. 811 RDF TAKEOVER initiated Cause The operator issued a TAKEOVER command.
Recovery This is an informational message, although you should determine why the primary process stopped and take corrective action if necessary. 815 Primary process takeover in processor cpu cpu is the number of the processor in which the primary process is now running. Cause A new primary process has been created by the backup process, and the backup process has switched control to this primary process. Effect The primary process of the process pair has taken over.
Recovery A subsequent warm start of RDF might be possible, but the success of the restart depends on the nature of the failure that caused the original process to stop. If the message is issued during ZLT processing, no recovery is required. 820 RDF receiver stopped unexpectedly, receiver receiver is the name of the receiver process that stopped. Cause The receiver has stopped unexpectedly. The message includes the name of the stopped process. Effect This message is issued by the RDF monitor.
Cause The RDF monitor was unable to find an extractor configuration record when performing a START RDF command. The ATINDEX value in the message indicates the audit-trail index for the extractor. Effect The START operation fails and RDF shuts down. Recovery Use the SET and ADD commands to create an extractor configuration record and then retry the START RDF command.
name is the name of the RDF process that was not stopped. Cause The RDF monitor is attempting to stop a process on the backup node but cannot do so because the communications lines are down. Effect If a STOP RDF command was being processed, the RDF monitor continues with the shutdown, and all processes on the primary system will stop. The backup processes will remain running.
Cause This message is issued by the purger if it has to terminate the current purge pass for one of a variety of reasons. The reason codes refer to the internal conditions that might be of use to support and development staff. Effect The purger terminates the current purge pass. A new purge pass will be initiated after PURGETIME minutes. Recovery This is an informational event. Under normal conditions, it should be logged infrequently.
process, or various file errors. The reason for the updater restart can be determined from previous messages. During an updater restart, file-system errors 10, 11, and 71 are not reported by the updater because they probably represent database operations that have already been performed. Recovery Perform any corrective actions suggested by the preceding messages (actions such as reloading the appropriate CPU, correcting the underlying file error condition).
Recovery If any updaters have not shutdown after the monitor has sent ABORT RDF messages, then you might have to terminate the surviving updaters manually using a TACL STOP command. 842 Error - START prevented by RDF TAKEOVER Cause You issued a START RDF command, but the monitor detected that RDF has already processed a TAKEOVER command. Effect The START RDF command fails. Recovery The backup database is consistent and ready for use as a backup contingency database.
Recovery There is no recovery. If you lose your primary system while the updaters are trying to catch up from an INITIALIZE RDF...INITTIME operation, the backup database has not yet been synchronized, and the data in it therefore might not be consistent. 848 RDF extractor waiting for network reply Cause The extractor has sent the maximum number of messages to the receiver and it has not received any replies for at least five minutes. Effect The extractor cannot proceed any further.
Recovery Contact your service provider for assistance with recovering from this situation. 854 ZTXUNDO file cannot be opened Cause While attempting to write the list of transactions that need to be undone to the ZTXUNDO file, that file could not be opened. Effect RDF aborts. Recovery If the operation involves an RDF takeover, take corrective action to enable the file to be opened and then reissue the TAKEOVER command.
Cause The named RDF process has encountered the specified error when attempting to begin a new transaction. Effect The process either restarts or abends, depending on the error. Recovery See the description of BEGINTRANSACTION errors in the TMF Application Programmer's Guide and take appropriate corrective action, if necessary. 860 Fatal error error on BEGINTRANSACTION encountered error is an error number.
Recovery Restart RDF. If the record is still missing, then you might have to reinitialize RDF. 864 SQL Shared Access DDL record found during undo pass Cause The updater has encountered audit associated with an SQL Shared Access DDL operation during undo processing for a stop-update-to-time operation. Effect The updater terminates immediately, and the stop-update-to-time operation is unsuccessful.
872 Warning; Lockstep operation is denied Cause An application has attempted an RDF lockstep operation but you have not configured RDF for lockstep operations. Effect No lockstep operations can take place, and the lockstep gateway process abends. Recovery This is a warning. If you want lockstep operations, you must stop RDF and create a new RDF configuration with the RDF LOCKSTEPVOL attribute set. 873 Remote RDF purger started Cause The purger has started as the result of a START RDF command.
877 First network transaction to be undone: %num num num num %num num num num identifies a network transaction. Cause This is the first transaction that requires network undo with respect to local processing. Note, however, that some transactions preceding it might also require undo for business consistency across all backup nodes. The transid is listed in internal format. Effect This is an internal event. There is no effect.
Effect The process abends, and RDF will abort. Recovery You need to reissue the RDFCOM TAKEOVER command. This will ensure that the stop-update-to-time operation has been aborted and the RDF subsystem is prepared to execute the takeover operation. 881 Aborting current RDF process transaction Cause The named RDF process has encountered a restart condition and must abort its current transaction. Effect The process aborts the transaction and restarts. Recovery This is an informational message.
887 Process trapped. Signal sig-num sig-num is the signal number associated with the trap. Cause The process reporting the event experienced an internal error and has trapped. The message indicates the signal number associated with the trap. Effect The process abends. Recovery This is an internal error. Preserve the saveabend file created and report the incident to your service provider. 888 MAT position for File Recovery: SNO num RBA num Cause A successful takeover has completed.
892 Image file filename is missing filename is the name of the missing image file. Cause An updater has attempted to roll over to the specified image file, but that file is missing. Effect The updater retries until the file is restored (the event message is repeated every minute until the file has been restored). Recovery Restore the missing file to the image trail.
898 SQL NSA operation detected in network undo operation Cause An SQL SHARED ACCESS DDL operation was detected during the network undo phase of the RDF takeover operation. Effect The updater abends, and the takeover operation aborts. Recovery Recovery might not be possible. Contact your service provider. 899 Too many transactions for undo processing. Repeat the operation. Cause The updater has detected more than the default maximum number of transactions that need to be undone.
Effect If this message comes from the master receiver, then normal RDF TAKEOVER processing is ready to proceed. If it comes from an auxiliary receiver, then normal RDF TAKEOVER processing does not start until the master receiver has finished ZLT processing. Recovery This is an informational message; no recovery is required. 904 Auxiliary receiver is catching up Cause The master receiver has found a TMF shutdown record.
number and error detail returned by the PROCESS_CREATE_ system procedure followed by the filename of the program that was to be run. This error will occur if one or more parameters in the configuration file are incorrect, if the required processor is not running, or if there are insufficient resources. Effect The backup process is not started. The primary continues to run, but will be vulnerable to a CPU failure. The primary will try to create its backup repeatedly until it succeeds.
Effect The trigger process is started. Recovery This is an informational message; no recovery is required. 914 Trigger process completed. [ Completion Code: num ] [ Termination Text: text ] [ The process is abended. ] num is the completion code. text is the termination text. Cause The purger has seen that the user specified trigger process has stopped. The message might include completion code and/or termination text information that indicates why the process stopped.
Cause A STOP RDF, DRAIN (or REVERSE) operation is being processed and the RDF extractor encountered a STOP TMF record in the TMF audit trail. Effect These two operations cannot be processed concurrently, which causes RDF to abort. Recovery Restart RDF and the STOP TMF record will be processed as normal. Once RDF has stopped as a result of the STOP TMF record, RDF can be restarted and a new STOP RDF, DRAIN (or REVERSE) command can be issued.
Cause The updater has detected that the specified mapping string is invalid. The position, if included in the event, indicates the string index at which the mapping string is invalid. The event also includes a description of the reason for the string to be invalid. Effect The updater stops and RDF aborts. Recovery Correct the mapping string in the mapfile, and restart RDF. 926 The MAPFILE filename is not found filename is the name of the updater mapfile specified in the updater configuration.
Effect The updater stops and RDF will abort. Recovery Provide an edit file, and restart RDF. RDFCOM Messages The following pages list all messages generated by RDFCOM. These messages appear on your terminal screen during an RDFCOM session. Alternatively, they can be directed to another output device or file through the OUT command, issued during an RDFCOM session or the OUT parameter entered in the RDFCOM command that begins the session. The messages appear in alphabetic order by message text.
Recovery Either shut down RDF and reenter the ALTER command, or select another command to enter. ALTER of this element cannot be performed with updaters running Cause An ALTER command was issued for a non-runtime ALTER option. Effect The command fails. Recovery Stop updating by entering the STOP UPDATE command through RDFCOM, and then reenter the ALTER command. ALTER RECEIVER RDFVOLUME is no longer supported Cause RDFCOM no longer supports this command. Effect The command fails.
Recovery You must execute the RDF TAKEOVER operation on both backup systems before you can use the COPYAUDIT command of the triple contingency protocol. An RDF TAKEOVER has completed Cause The operator issued a TAKEOVER command at the backup node and the TAKEOVER operation has completed. Effect The backup database becomes the database of record. Recovery This is an informational message; no recovery is required.
BACKUPSYSTEM \node is Unavailable node is the name of the backup node that was unavailable. Cause Either the START RDF command failed because the backup node was unavailable, or the RDF configuration file is invalid. Effect The command or requested operation fails. Recovery Examine the RDF configuration file, and correct it if necessary. Otherwise, reenter the START RDF command when the backup node becomes available.
Cause The configuration file data cannot be created or cleared while START RDF processing is performed after INITIALIZE RDF. Effect START RDF processing is aborted. Recovery See the Operator Messages Manual for a description of the error code. For additional details about understanding and correcting file-system errors, see the Guardian Procedure Errors and Messages Manual. If possible, correct the error and reenter the command that encountered the error. Otherwise, see your system manager.
Cause A START RDF command failed because the specified CPUs do not exist (they were not configured during SYSGEN). Effect The command fails. Recovery Reconfigure RDF to use other CPUs or, if you must use the specified CPUs, see your system manager. Creation error error# on IMAGETRAIL volume-name error# is the file-system error number that identifies the specific error. volume-name is the image trail volume on which the error occurred.
Do you still wish to start at this point? [Y/N] Cause In response to your INITIALIZE RDF command and your confirmation to proceed with that command’s execution, RDFCOM has found the record with the specified TMF shutdown timestamp in the MAT and RDF is ready to be initialized at that shutdown point. This message requests your confirmation to proceed further.
Recovery See the Guardian Procedure Errors and Messages Manual for a description and recovery actions for the file-system error. Correct the error indicated by error#, and then reenter the command. Error error# obtaining FILECODE and EOF of the MAPLOG filename error# is the file-system error number that identifies the specific number. filename is the name of the updater maplog specified in the updater configuration.
error# is the file-system error number that identifies the specific error. filename is the name of the updater maplog specified in the updater configuration. Cause Purgedata operation returned an error when RDFCOM tried to clean the updater maplog file when an ADD VOLUME, ALTER VOLUME, or START RDF command was being executed. Effect The command fails. Recovery See the Guardian Procedure Errors and Messages Manual for a description of the recovery actions for the file-system error.
Recovery See the Operator Messages Manual for a description of the error code. For additional details about understanding and correcting file-system errors, see the Guardian Procedure Errors and Messages Manual. Take appropriate corrective action, and then reissue the COPYAUDIT command. Error in the MAPFILE filename filename is the name of the updater mapfile specified in the updater configuration.
Recovery Check the control subvolume name and make sure that you are spelling it correctly. Then reenter the command, including the proper control subvolume name or specifying a different control subvolume. Expecting: RDF, MONITOR, EXTRACTOR, RECEIVER, VOLUME Cause RDF did not understand the command. Effect The command fails. Recovery Check the syntax rules for the command you entered. Perhaps you misspelled a keyword parameter or misplaced a delimiter. Expecting 'Yes' or 'No' response.
EXTRACTOR record NOT found Cause The INFO command could not find an extractor record in the configuration file. Effect The command fails. Recovery Alter the configuration to include an extractor process. Fixing up context to enable another RDFCOM Takeover command Cause The COPYAUDIT command has finished copying the missing audit from the remote system to the local system, and is now about to update context records to permit execution of another TAKEOVER command.
Effect The COPYAUDIT command aborts. Recovery There might be no recovery for this problem. You must perform the database synchronization without the help of RDFCOM. IMAGETRAIL for IMAGEVOLUME vol-name does not exist vol-name is the image trail volume for which the image trail does not exist. Cause You tried to add an updater, but have not yet added an image trail for the updater’s volume. Effect The ADD command fails. Recovery Add the image trail. Then add the updater.
IMAGETRAIL volume-name record not found; DELETE aborted volume-name is the name of the secondary image trail that was specified in the command. Cause You tried to delete a secondary image trail that does not exist. Effect The command fails. Recovery Select a different secondary image trail to delete, or select another command. IMAGETRAIL VOLUME volume-name does NOT exist volume-name is the name of the volume.
Cause You are attempting to initialize RDF to a timestamp that is earlier than the current time, and database synchronization is not involved. A record whose timestamp is less than timestamp has been found, and timestamp has been stored in the RDF configuration record. Effect The RDFCOM INITIALIZE RDF command continues. Recovery This is an informational message; no recovery is required. Initialization with database synchronization is only available with the NonStop(TM) RDF/IMP(X) product.
Library Conflict Cause A NEWPROCESS error occurred during START RDF or TAKEOVER processing. Effect The START RDF or TAKEOVER operation is aborted. Recovery If possible, correct the error and reenter the command that encountered the error. Otherwise, see your system manager. Library File Error: error# error# is the NEWPROCESS error number that identifies the specific error. Cause A NEWPROCESS error occurred during START RDF or TAKEOVER processing. Effect The START RDF or TAKEOVER operation is aborted.
Recovery See the Guardian Procedure Errors and Messages Manual for a description and recovery actions for the file-system error. Correct the error indicated by error#, then, reenter the command. Mapping string mapping-string is invalid in the MAPFILE filename The subvolume subvolume-name is invalid. mapping-string is the erroneous mapping string specified in the MAPFILE. filename is the name of the updater MAPFILE specified in the updater configuration.
Effect RDF does not start. Recovery Add a network record to describe the network master subsystem. MONITOR Record exists, use ALTER MONITOR Cause An ADD MONITOR command was issued when the configuration file already contained a monitor record. Effect The command fails. Recovery No recovery is required if you want to use the existing monitor process as configured. If you want to change any of the monitor’s configuration options, however, enter an ALTER MONITOR command that specifies those changes.
Recovery Alter the configuration to include the extractor. No EXTRACTOR is configured for ATINDEX atindex Cause You added a receiver with the specified ATINDEX, but there is no extractor with that value. Effect The validation fails. Recovery Add an extractor with the same ATINDEX value or delete the particular receiver. No RECEIVER is configured for ATINDEX atindex Cause You added an extractor with the specified ATINDEX, but there is no receiver with that value. Effect The validation fails.
Cause The RDF configuration file is invalid. Effect The configuration validation fails. Recovery Check the receiver parameter entries in the configuration file for invalid values and correct any errors found. No VOLUMEs are configured Cause The RDF configuration file is invalid. Effect The configuration validation fails. Recovery Check the updater process parameters in the configuration file for invalid values and correct any errors found.
Recovery See the Guardian Procedure Errors and Messages Manual for a description of the recovery actions for the file-system error. Correct the error indicated by error#, then reenter the command. Open error error# on MAPLOG file filename error# is the file-system error number that identifies the specific error. filename is the name of the updater maplog specified in the updater configuration.
Effect RDFCOM reads backward through the MAT in search of a TMF shutdown record with the same timestamp you specified. Recovery This is an informational message; no recovery is required. You can terminate the operation at any time by pressing the BREAK (or equivalent) key. PNETTXVOLUME volume for ctrl-subvol must be protected by a MAT based-updater volume is the name of an RDF data volume. ctrl-subvol is the name of an RDF subsystem control subvolume.
filename is the name of the image trail file associated with the error. Cause The COPYAUDIT command encountered the specified error while attempting to position into the specified image file on the local image trail volume. Effect The COPYAUDIT command aborts. Recovery See the Operator Messages Manual for a description of the error code. For additional details about understanding and correcting file-system errors, see the Guardian Procedure Errors and Messages Manual.
Program File Error: error# on progfile error# is the error number that identifies the specific error. progfile is the name of the program file on which the error was encountered. Cause A NEWPROCESS error occurred during START RDF or TAKEOVER processing. Effect The START RDF or TAKEOVER operation is aborted. Recovery See the Operator Messages Manual for a description of the error code.
Effect The command fails. Recovery Reissue the command after RDF is started. RDF record exists, use ALTER RDF Cause An ADD RDF command was issued when the configuration file already contained an RDF global record. Effect The command fails. Recovery No recovery is required if you want to use the subsystem with the existing RDF global parameters configured. If you want to change any of the global parameters, however, enter an ALTER RDF command that specifies those changes.
Effect The attempted command is aborted. Recovery Contact the Global Mission Critical Solution Center (GMCSC) or your service provider. RDFCOM is asking the TMP to restore the file. If the file was previously dumped to tape, watch for the TMP to tell you to mount the appropriate tape. Cause In response to a prompt, you requested RDFCOM to trigger restoration of an audit-trail file.
Read error error# on remote image file error# is the file-system error number that identifies the specific error. Cause The COPYAUDIT command encountered the specified error while attempting to read data from a remote image file on the remote image trail. Effect The COPYAUDIT command aborts. Recovery See the Operator Messages Manual for a description of the error code. For additional details about understanding and correcting file-system errors, see the Guardian Procedure Errors and Messages Manual.
Effect The command fails. Recovery See the Operator Messages Manual for a description of the error code. For additional details about understanding and correcting file-system errors, see the Guardian Procedure Errors and Messages Manual. If possible, correct the error and reenter the command that encountered the error. Otherwise, see your system manager. RECEIVER RDFVOLUME device is NOT a disk volume device is the name of the non-disk device. Cause The RDF configuration file is invalid.
Recovery You must add the corresponding receiver process before adding an imagetrail with the same ATINDEX value. Remote system for Triple Contingency CopyAudit command is unavailable: remote-system remote-system is the name of the RDF backup system that received the most audit. Cause You entered a COPYAUDIT command, but remote-system cannot be reached because of a network problem. Effect The COPYAUDIT command aborts. Recovery When the remote system becomes available, reissue the COPYAUDIT command.
Cause The COPYAUDIT command is about to search for missing audit; this audit reached the specified image trail on the remote system but did not reach the local system before the original primary system was lost. Effect The COPYAUDIT command begins the search. Recovery This is an informational message; no recovery is required. Shutdown at specified timestamp timestamp does not exist timestamp is the shutdown timestamp to which the initialization was requested.
Recovery You must specify a valid primary system name. Specified network primary system name is unavailable. Cause RDFCOM is unable to reach the specified primary system. Effect The configuration command fails. Recovery Determine why the comm path to this system is down and take the appropriate recovery steps to bring it up. Specified TMF shutdown timestamp at timestamp is earlier than the earliest timestamp in the TMF MAT. Please examine the OPRLOG for a correct TMF shutdown timestamp.
Recovery Enter another command, or wait until RDF is started and then reenter the STATUS RDF command. STOP SYNCH command is aborted. Cause You are attempting to execute the RDFCOM STOP SYNCH command, but either the RDF product is not running or another critical operation is already in progress. Effect The RDFCOM STOP SYNCH command aborts. Recovery Correct the situation and then reissue the command. STOP SYNCH command is aborted because database synchronization is not in progress.
Recovery See the Operator Messages Manual for a description of the error code. For additional details about understanding and correcting process errors, see the Guardian Procedure Errors and Messages Manual. If possible, correct the error and reenter the command that encountered the error. Otherwise, see your system manager. Synch point for synchdbtime has been found synchdbtime is a SYNCHDBTIME timestamp specified previously by an operator in an RDFCOM INITIALIZE RDF command.
Recovery You must purge $SYSTEM.name.* on the primary system before you can retry the INITIALIZE RDF command. Before doing so, however, be sure that the existing files do not belong to a different RDF configuration that is still valid. The EXTRACTOR must be a named process Cause You must specify a process name for the extractor process before issuing an ADD command. Effect The start command fails. Recovery You must reconfigure RDF with a named extractor process.
Recovery See the Guardian Procedure Errors and Messages Manual for a description of the recovery actions for the file-system error. Correct the error indicated by error#, then reenter the command. The MAPLOG file filename should be an edit file filename is the name of the updater maplog specified in the updater configuration. Cause RDFCOM found that the updater maplog is not an edit format file when an ADD VOLUME, ALTER VOLUME, START RDF, or START UPDATE command was being executed. Effect The command fails.
The RDF primary system in the environment you are attempting to copy audit from does not match the primary system in this environment. Cause The COPYAUDIT command detected that the RDF primary system in the RDF environment you are attempting to copy audit from is not the same as the RDF primary system in the local environment. Effect The COPYAUDITcommand aborts. Recovery Correct the REMOTESYS remote-sys and REMOTECONTROLSUBVOL rcvs parameters and reissue the COPYAUDIT command.
The Triple Contingency COPYAUDIT command has completed successfully. You must now issue a new RDFCOM Takeover command. Cause The COPYAUDIT command has finished copying the missing audit from the remote system to the local system and has updated all context records on the local system. Effect The context records are updated. Recovery This is an informational message; no recovery is required.
TMF is not running. Cause While either attempting to validate the RDF configuration or to start RDF, RDFCOM discovered that TMF is not running. Effect The command fails. Recovery Start TMF. Then validate your configuration and start RDF. TMF is not started yet. Cause TMF has not been started. Effect The requested RDFCOM operation fails.
Recovery Delete some of the volumes. Too many volumes are specified in this ALTER command Cause You specified too many volumes in the command parameter list of an ALTER command. Effect The ALTER command aborts. Recovery Eliminate some of the volumes from the command parameter list. Triple Contingency CopyAudit command aborted. Cause The COPYAUDIT command has aborted because of a problem reported in the previous RDFCOM message. Effect The COPYAUDIT command aborts.
Cause A START RDF command failed because the reported error prevented RDFCOM from purging the old image file. Effect The command fails. Recovery See the Operator Messages Manual for a description of the error code. For additional details about understanding and correcting file-system errors, see the Guardian Procedure Errors and Messages Manual. Manually purge any files on the image file subvolume, and then reissue the START RDF command.
Effect The command fails. Recovery Scan the EMS event log to determine why the command could not be performed. Correct the error condition, if possible, and request the update operation again. VOLUME device is NOT a disk volume device is the non-disk device assigned to the updater. Cause The RDF configuration file is invalid. Effect RDF will not start. Recovery Change the RDF configuration to reflect a valid disk volume.
VOLUME volume needs the IMAGETRAIL image-trail; DELETE aborted volume is the name of the volume on the primary system that requires the image trail. image-trail is the name of the required image trail. Cause You tried to delete an image trail that is still being used by an updater. Effect The command fails. Recovery Delete the updater, and then delete the image trail.
Recovery Stop RDF, reconfigure it to include a backup CPU for the RDF process, and start the subsystem once again. * * * WARNING * * * NSA SQL DDL operation encountered in the audit trail. If you have already performed this DDL operation on the backup database, you should initialize RDF to a later point in the audit trail. Cause You tried to initialize RDF to a timestamp, and RDFCOM encountered an audit record indicating that you previously performed a SQL shared-access DDL operation.
error# is the file-system error number that identifies the specific error. Cause You are attempting to execute an RDFCOM STOP SYNCH command, but RDFCOM encountered the specified error while sending the message to the extractor. Effect The STOP SYNCH command aborts. Recovery See the Operator Messages Manual for a description of the error code. For additional details about understanding and correcting file-system errors, see the Guardian Procedure Errors and Messages Manual.
Cause You entered a COPYAUDIT command and receive this message as a prompt for confirmation that you want to proceed with the command’s execution. Effect If you respond YES or Y, RDF executes the command. If you respond NO or N, the command terminates. Recovery This is an informational message; no recovery is required. You are about to unpin a file that the extractor needs. Are you sure you want to proceed? Cause You have asked RDFCOM to unpin a file that is currently needed by the extractor.
You cannot START RDF after an RDF Takeover operation. Cause You tried to start RDF after an RDF takeover operation has been performed. Effect The START RDF command fails. Recovery You must initialize RDF on the primary system. You should also ensure that the takeover operation completed successfully. You cannot start updaters before the extractor has completed Phase 2 of its online database synchronization operation.
error# is the file-system error number that identifies the specific error. filename is the name of the log file associated with the error. Cause A file-system error occurred while RDFSCAN was trying to open the specified log file. Effect The command fails. Recovery See the Operator Messages Manual for a description of the error code. For additional details about understanding and correcting file-system errors, see the Guardian Procedure Errors and Messages Manual.
D Operational Limits Table D-1 Operational Limits for RDF/IMP, IMPX and ZLT Limit Description Maximum Value Number of volumes being protected 255 Number of volumes in an SMF pool on backup system 15 Number of auxiliary image trails 255 Number of files per updater 500 Number of RDF configurations with the same primary system 37 Number of systems that can contribute audit to a primary system 255 Maximum number of image trail file primary and secondary extents 65,500 Maximum number of primary s
E Using ASAP ASAP (Availability Statistics and Performance) allows many subsystem entities to be monitored across a network of NonStop servers. The status and statistics for the entities are collected on a single system, and are then monitored either through the ASAP command interface or through the ASAP graphical user interface (GUI) PC client.
Figure E-1 The RDF/ASAP Environment Installation The RDF SGP is packaged with the RDF/IMP and IMPX products and, by default, is installed on $SYSTEM.RDF. You might, however, place this object file wherever you want. If you install the SGP object file somewhere other than $SYSTEM.RDF, you must ensure that the ASAP configuration points to the correct location (by way of the SET RDF command within the ASAP command interface). See the ASAP Server Manual for details about the SET RDF command.
MONITOR RDF DOME->TANDA Adding and Removing RDF Environments The RDF SGP performs the auto detection and processing of the RDF environments added through the MONITOR command when the process starts. If RDF environments are added or removed while the RDF SGP is running, ASAP does not monitor them until the next time the RDF SGP is stopped and restarted. Version Compatibility The RDF SGP supplied with each version of RDF/IMP(X) only runs with that version of RDF.
Table E-1 RDF Metrics Reported by ASAP (continued) Information Passed to ASAP Monitor Extractor Receiver Imagetrail Purger RDFNET Updater Relative Byte Address — X — — — — X RTD Time X X X — — — X Primary CPU X X X — X X1 X Backup CPU X X X — X X1 X Priority X X X — X X1 X 1 2 442 Only in an RDF Network environment Only reported by the master receiver where the master image trail (MIT) volume is reported Using ASAP
Index Symbols * wildcard character, 251 900, File code, 68 ? wildcard character, 251 ] prompt, 101 A Abbreviations, 189, 320 ADD command, 179, 319 ADD EXTRACTOR command, 91, 94 ADD MONITOR command, 93 ADD RECEIVER command, 95, 96 ALTER command, 181, 319 ALTER command, FUP, 78 Altering TMF configuration, 82 ANSI object types summary, 295 ASAP, Using with RDF, 62, 439 Asterisk wildcard character, 251 AT command, 246, 253, 327 ATINDEX parameter, 185, 192, 208, 210, 218 Audit compression, 74 Audit dumping, STA
AT, 246, 327 DISPLAY, 246 EXIT, 247, 327 FILE, 248, 327 HELP, 248, 327 LIST, 249, 327 LOG, 250, 327 MATCH, 251, 327 NOLOG, 251, 252, 328 SCAN, 253, 328 RDFSCAN commands DISPLAY, 327 STATUS RDF, 113 CommitHoldMode, 311 Communications estimating required resources, 64 RDF requirements, 63, 65 Communications line failure, 125 Comparing SQL/MX tables, 308 CONFIG file description, 333 Configuration backup system, 63 command file, creating for RDF, 97 extractor process, 91, 94 monitor process, 93 primary system,
Error messages, file system, 342 Error recovery create operation, 123 modify operation, 122 open operation, 122 RDF error 700, modify operation, 122 RDF error 705, open operation, 122 RDF error 739, create operation, 123 Event log, scanning messages in EMS, 44, 117 Exception files description, 333 examining, 332 records, 43 EXCLUDE clauses, 261 EXIT command, 187, 247, 320, 327 Expand estimating required resources, 64 multi-CPU paths (superpaths), 273 EXPAND line failure, 125 Extractor process, 47 auxiliary,
Installing the RDF subsystem, 79 K Keywords, 105 L Label modifications, file, 69 Licensed programs, 80 Line failure, 125 LIST command, 249, 327 LOCATION option, 306 LOCKSTEP command, 202 Lockstep gateway messages, 335 Lockstep operation, 61 LOG command, 250, 327 Log device, messages sent to, 342 Log file, 245 $0, 342 description, 43 example, 118, 342 messages in, 117 scanning messages in, 44 specifying in RDFSCAN, 248, 327 Log, EMS event, 117 LOGDEVICE parameter, 214 LOGFILE parameter, 214 M Managing the
synchronizing databases with, 75 OBEYFORM option, 192 of INFO command, 97 OBEYVOL command, 204 ODBC catalog changes, 150 Offline synchronization for a single partition, 303 Online database synchronization, 155 phases of, 169 Online dumps on backup system, 68 Online help RDFCOM, 108 RDFSCAN, 111 Online initialization, 84 OPEN command, 204, 321 Open operation error recovery, 122 file-system errors, 122 RDF errors, 122 Operating system RDF requirements, 65 security, 80 Operating the RDF subsystem, 101 Operatio
messages, 342 messages, scanning, 44, 117 network transactions, 275 NonStop process pairs, 46 operating, 101 operations, 47 parameters BACKUPSWAP, 214 BACKUPSYSTEM, 198 CPUS, 208, 209, 210, 211, 212, 217, 218, 220, 222, 322, 323 EXTENTS, 212, 218 extractor process, 94 image trail, 91 IMAGETRAIL, 185 IMAGEVOLUME, 222 LOGDEVICE, 214 LOGFILE, 214 monitor process, 93 PRIMARYSWAP, 214 PRIORITY, 208, 209, 210, 211, 212, 217, 218, 220, 222, 322, 323 PROCESS, 208, 209, 210, 211, 212, 217, 218, 220, 222, 322, 323 RD
security requirements, 81 RDFNETO, security requirements, 81 RDFRCVO licensed program, 80 receiver object file, 79 security requirements, 81 RDFSCAN description, 245 description of use, 44, 117 ending a session, 110 help text file, 79 messages, 434 object code file, 79 online help, 111 running, 109 security requirements, 81 starting a session, 110 wildcard characters in match patterns, 251 RDFSCAN commands AT, 246, 327 DISPLAY, 246, 327 EXIT, 247, 327 FILE, 248, 327 HELP, 248, 327 LIST, 249, 327 LOG, 250, 3
SQL/MX offline synchronization for a single partition, 303 SQL/MX tables comparing, 308 restoring, 306 START RDF command, 98, 228, 325 START TMF command, TMFCOM, 98 START TRANSACTION command, TMFCOM, 78, 82 START UPDATE command, 99, 229, 325 Starting the RDF subsystem, 98 Starting the TMF subsystem, 98 STATUS RDF command, 113, 230, 325 STOP LOCKSTEP command, 234 STOP RDF command, 235, 326 STOP RDF, DRAIN operations, 132 STOP SYNCH command, 237, 326 STOP UPDATE command, 140, 238, 326 stop-update-to-time, 140
RESET VOLUME example, 208 resetting option values, 206, 322 SET VOLUME example, 224 setting option values, 222 SHOW VOLUME example, 227 partitioned files, auditing, 53 RDF errors, 121 restart point, 53 restart points, error recovery, 121 Updater, failure, 126 UPDATERDELAY parameter, 214 UPDATEVOLUME parameter, 222 User interfaces, RDF subsystem, 43 V VALIDATE CONFIGURATION command, 242, 326 Views, NonStop SQL/MP, 68, 75 Volume audited on backup system, 74 configuration, 64 failure, TMF, 127 limit, 64 mappi
