HP NonStop RDF J-series RVUs, NonStop RDF H-series RVUs, NonStop RDF Management Manual

HP NonStop RDF System Management
Manual for J-series and H-series RVUs (RDF

1.9)

HP Part Number: 529826-006
Published: June 2009
Edition: J06.03 and subsequent J-series RVUs and H06.03 and subsequent H-series RVUs

© Copyright 2009 Hewlett-Packard Development Company, L.P.

Legal Notice

Confidential computersoftware. 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 informationcontained hereinis subject to change without notice. Theonly warranties forHP productsand servicesare set forth in the express

warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP

shall not be liable for technical or editorial errors or omissions contained herein.

Export of the information contained in this publication might require authorization from the U.S. Department of Commerce.

Microsoft, Windows, and Windows NT are U.S. registered trademarks of Microsoft Corporation.

Intel, Pentium, and Celeron are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other

countries.

Java is a U.S. trademark of Sun Microsystems, Inc.

Motif, OSF/1, UNIX, X/Open, and the "X" device are registered trademarks, and IT DialTone and The Open Group are trademarks of The Open

Group in the U.S. and other countries.

Open Software Foundation, OSF, the OSF logo, OSF/1, OSF/Motif, and Motif are trademarks of the Open Software Foundation, Inc. OSF MAKES

NO WARRANTY OF ANY KIND WITH REGARD TO THE OSF MATERIAL PROVIDED HEREIN, INCLUDING, BUT NOT LIMITED TO, THE

IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULARPURPOSE. OSF shall not be liable for errors contained

herein or for incidental consequential damages in connection with the furnishing, performance, or use of this material.

© 1990, 1991, 1992, 1993 Open Software Foundation, Inc. The OSF documentation and the OSF software to which it relates are derived in part

from materials supplied by the following:© 1987, 1988, 1989 Carnegie-Mellon University. © 1989, 1990, 1991 Digital Equipment Corporation. ©

1985, 1988, 1989, 1990 Encore Computer Corporation. © 1988 Free Software Foundation, Inc. © 1987, 1988, 1989, 1990, 1991 Hewlett-Packard

Company. © 1985, 1987, 1988, 1989, 1990, 1991, 1992 International Business Machines Corporation. © 1988, 1989 Massachusetts Institute of

Technology. © 1988, 1989, 1990 Mentat Inc. © 1988 Microsoft Corporation. © 1987, 1988, 1989, 1990, 1991, 1992 SecureWare, Inc. © 1990, 1991

Siemens NixdorfInformationssysteme AG. © 1986, 1989,1996, 1997Sun Microsystems, Inc. © 1989,1990, 1991Transarc Corporation.OSFsoftware

and documentationare basedin parton the Fourth Berkeley SoftwareDistribution underlicense from The Regents of the Universityof California.

OSF acknowledgesthe followingindividuals and institutions for their role in its development:Kenneth C.R.C. Arnold, Gregory S. Couch, Conrad

C. Huang, Ed James, Symmetric Computer Systems, Robert Elz. © 1980, 1981, 1982, 1983, 1985, 1986, 1987, 1988, 1989 Regents of the University

of California.

Table of Contents

About This Document.......................................................................................................23

Supported Release Version Updates (RVUs)........................................................................................23

Intended Audience................................................................................................................................23

New and Changed Information in This Edition...................................................................................23

New features in the RDF 1.9 manual...............................................................................................23

Updates in the RDF 1.9 manual.......................................................................................................24

Document Organization.......................................................................................................................24

Notation Conventions...........................................................................................................................26

General Syntax Notation.................................................................................................................26

Notation for Messages.....................................................................................................................28

Related Information..............................................................................................................................29

Publishing History................................................................................................................................30

HP Encourages Your Comments..........................................................................................................30

1 Introducing RDF............................................................................................................31

RDF Subsystem Overview....................................................................................................................32

Unplanned Outages With ZLT........................................................................................................34

Unplanned Outages Without ZLT...................................................................................................34

Planned Outages..............................................................................................................................35

Features............................................................................................................................................35

User Interfaces......................................................................................................................................38

RDFCOM for Subsystem Management and Operations.................................................................38

Scanning the EMS Event Log...........................................................................................................38

RDF Tasks..............................................................................................................................................39

RDF Processes.......................................................................................................................................40

Primary System Processes...............................................................................................................41

Backup System Processes................................................................................................................42

RDF Operations....................................................................................................................................42

Monitor Process...............................................................................................................................42

Extractor Process.............................................................................................................................42

Receiver Process..............................................................................................................................44

Sorted Image Trails.....................................................................................................................45

RDF Control Points....................................................................................................................46

RDFNET Process.............................................................................................................................46

Updater Processes............................................................................................................................46

Audited Database Files..............................................................................................................47

REDO Pass..................................................................................................................................48

UNDO Pass.................................................................................................................................48

Restart Information....................................................................................................................48

Partitioned Files, Alternate Key Files, and Indexes...................................................................48

File System Errors Involving Data Files.....................................................................................49

RTD Times..................................................................................................................................49

Purger Process.................................................................................................................................49

Reciprocal and Chain Replication Require Mutually Exclusive Datavols.................................50

Available Types of Replication to Multiple Backup Systems...............................................................52

RDF Control Subvolume.................................................................................................................53

Other RDF Features..............................................................................................................................53

Triple Contingency..........................................................................................................................53

Loopback Configuration (Single System)........................................................................................53

Online Product Initialization...........................................................................................................54

Table of Contents 3

Online Database Synchronization...................................................................................................54

Online Dumps of the Backup Database..........................................................................................54

Subvolume-Level and File-Level Replication..................................................................................54

Shared Access DDL Operations......................................................................................................54

Configurable Software Location......................................................................................................54

EMS Support....................................................................................................................................55

SMF Support....................................................................................................................................55

RTD Warning Thresholds................................................................................................................55

Process-Lockstep Operation............................................................................................................55

Support for Network Transactions..................................................................................................55

RDF and NonStop SQL/MX.............................................................................................................56

Zero Lost Transactions (ZLT)..........................................................................................................56

Monitoring RDF Entities With ASAP..............................................................................................56

2 Preparing the RDF Environment..................................................................................57

Configuring Hardware for RDF Operations.........................................................................................57

Primary System Configuration........................................................................................................57

Backup System Configuration.........................................................................................................57

Disk Volume Limit...........................................................................................................................58

Volume-to-Volume Mapping...........................................................................................................58

Subvolume-to-Subvolume Name Mapping....................................................................................58

Expand (Data Communication) Resources.....................................................................................58

Preparing Software and Database Files for RDF Operations...............................................................59

Configuring TMF for RDF Operations on the Primary System......................................................60

AUDITTRAIL BUFFER..............................................................................................................60

TMF Configuration With Dump Process on the Primary System.............................................61

TMF Configuration Without Dump Process on the Primary System........................................61

Configuring TMF for RDF Operations on the Backup System.......................................................61

Preparing Databases for RDF Protection.........................................................................................62

Audited Files Per Volume on Primary System..........................................................................62

Audited Backup Database Files.................................................................................................62

Reload of Backup Database...................................................................................................62

Disk Process Pins on Database Volumes..............................................................................62

DSM Catalogs and File Code 900...............................................................................................63

Views on the Backup System.....................................................................................................63

Partitioned Tables and Files.......................................................................................................63

Database Block Sizes and Cache on the Backup System............................................................63

Specifying System Generation Parameters for an RDF Environment.............................................63

Designing Transactions for RDF Protection....................................................................................64

Replicating Database Operations...............................................................................................64

NonStop SQL DDL Operations............................................................................................64

Enscribe File-Label Modifications.........................................................................................64

Purge Operations..................................................................................................................64

Partitioned Files....................................................................................................................65

Temporary Disk Files............................................................................................................65

Using SMF With RDF............................................................................................................................65

Configuring an SMF Environment on the Primary System............................................................66

Configuring an SMF Environment on the Backup RDF System.....................................................66

3 Installing and Configuring RDF..................................................................................69

Preparing the Primary System..............................................................................................................69

Stopping the Software.....................................................................................................................69

Preparing the Tables and Files.........................................................................................................69

4 Table of Contents

Separating NonStop SQL Tables................................................................................................70

Compressing Audit Data for Tables and Files...........................................................................70

Preparing the Backup System...............................................................................................................70

Synchronizing the Primary and Backup Databases........................................................................71

Re-Creating an Empty Database With an OBEY Command.....................................................71

Synchronizing Databases With SQLCI Commands...................................................................72

Synchronizing Databases With BACKUP and RESTORE Utilities............................................73

Synchronizing Databases With FUP..........................................................................................74

Synchronizing Partitioned Files.................................................................................................74

Backing Up Application Programs and Files..................................................................................74

Cache for RDF IMAGETRAILS and UPDATER UPDATEVOLUMES............................................74

Installing RDF.......................................................................................................................................75

RDF/IMP (T0346) Product Components..........................................................................................75

RDF/IMPX (T0347) Product Components.......................................................................................75

RDF/ZLT (T0618) Product Components..........................................................................................76

Process-Lockstep Gateway (T1226) Product Components..............................................................76

Component Licensing......................................................................................................................76

Security Guidelines..........................................................................................................................76

Using the OWNER Attribute to Allow Super Group Users to Start, Stop, and Manage RDF........78

Initializing and Configuring TMF........................................................................................................78

TMF Subsystem Not Running Previously.......................................................................................78

TMF Subsystem Running Previously..............................................................................................79

Initializing and Configuring RDF.........................................................................................................79

Initializing RDF...............................................................................................................................79

Initializing RDF To a TMF Shutdown Timestamp.....................................................................80

Initializing RDF Without any Timestamp Option.....................................................................80

Initializing RDF Without Stopping TMF (Using INITTIME Option)..............................................80

Determining a Valid inittime Value.......................................................................................81

Special Considerations...............................................................................................................81

Enscribe Create Records.......................................................................................................81

Stop-RDF-Updater Records..................................................................................................81

TMF Shutdown Records.......................................................................................................82

Online Installation and Initialization Without Stopping RDF........................................................82

Disaster Points............................................................................................................................83

Considerations............................................................................................................................83

Configuring RDF.............................................................................................................................84

Setting Global Attributes............................................................................................................85

LOGFILE Attribute...............................................................................................................85

UPDATERDELAY Attribute.................................................................................................85

UPDATERTXTIME Attribute................................................................................................86

UPDATERRTDWARNING Attribute...................................................................................86

UPDATEROPEN Attribute...................................................................................................86

SOFTWARELOC Attribute...................................................................................................86

NETWORK Attribute............................................................................................................87

NETWORKMASTER Attribute.............................................................................................87

UPDATEREXCEPTION Attribute........................................................................................87

LOCKSTEPVOL Attribute....................................................................................................87

REPLICATEPURGE Attribute..............................................................................................87

REMOTE MIRROR Attribute................................................................................................87

REMOTE STANDBY Attribute.............................................................................................88

OWNER Attribute.................................................................................................................88

Setting Image Trail Attributes....................................................................................................88

Dedicated Image Trails or Image Trails on UpdateVolumes................................................89

Setting Trigger Attributes...........................................................................................................89

Setting Network Configuration Record Attributes....................................................................90

Table of Contents 5

PRIMARYSYSTEM Attribute................................................................................................90

BACKUPSYSTEM Attribute.................................................................................................91

REMOTECONTROLSUBVOL Attribute..............................................................................91

PNETTXVOLUME Attribute................................................................................................91

Setting Individual Process Attributes........................................................................................91

RDFNET Process...................................................................................................................91

Monitor Process....................................................................................................................91

Extractor Process...................................................................................................................92

Receiver Process....................................................................................................................93

Purger Process.......................................................................................................................94

Updater Processes.................................................................................................................95

Creating a Configuration Command File........................................................................................96

Configuration File Compatibility....................................................................................................96

Enabling RDF Operations.....................................................................................................................97

Starting TMF....................................................................................................................................97

Starting RDF....................................................................................................................................97

Restarting the Applications.............................................................................................................98

4 Operating and Monitoring RDF.................................................................................99

Running RDFCOM...............................................................................................................................99

Command Syntax for Starting an RDFCOM Session......................................................................99

Using RDFCOM Interactively.......................................................................................................100

Starting a Session......................................................................................................................100

Ending a Session.......................................................................................................................101

Interrupting Command Processing..........................................................................................101

Using RDFCOM Noninteractively (without an IN File)...............................................................102

Using RDFCOM From a Command File (IN file)..........................................................................102

Using Scripts for Easy and Fast RDF Initialization and Configuration........................................103

Managing Multiple RDF Environments from One RDFCOM Session.........................................104

Controlling Multiple RDF Environments Running on Different Nodes with a Single Obey

File..................................................................................................................................................104

Using RDFCOM Commands.........................................................................................................105

Configuration Commands........................................................................................................105

Operational Commands...........................................................................................................106

Utility Commands....................................................................................................................106

Entering Commands................................................................................................................107

Requesting Online Help................................................................................................................107

Help for Command Syntax......................................................................................................107

Help for RDF Error Messages..................................................................................................108

Running RDFSCAN............................................................................................................................109

Command Syntax for Starting an RDFSCAN Session...................................................................109

Using RDFSCAN...........................................................................................................................109

Starting a Session......................................................................................................................109

Ending a Session.......................................................................................................................110

Using RDFSCAN Commands........................................................................................................110

Requesting Online Help................................................................................................................111

Help for Command Syntax......................................................................................................111

Introductory Usage Information..............................................................................................112

Performing Routine Operational Tasks...............................................................................................112

Displaying Current Operating Statistics and Configuration Information....................................112

RDF States.................................................................................................................................113

Main STATUS RDF Display......................................................................................................114

Using RDF Status Data to Control TMF Audit Dumping........................................................116

Changing Configuration Attributes..............................................................................................116

6 Table of Contents

Process Priority.........................................................................................................................117

EMS Logs (Collectors)..............................................................................................................117

RETAINCOUNT.......................................................................................................................117

PURGETIME.............................................................................................................................117

UPDATERDELAY.....................................................................................................................117

UPDATEROPEN......................................................................................................................117

Reading Log Messages..................................................................................................................118

Examining RDF Messages........................................................................................................118

ASAP...................................................................................................................................................120

5 Critical Operations, Special Situations, and Error Conditions.............................121

Recovering From File System Errors..................................................................................................121

Handling Disk Space Problems..........................................................................................................124

Exceeding the Maximum Number of Concurrent File Opens............................................................125

Responding to Operational Failures...................................................................................................125

Communication Line Failures.......................................................................................................126

System Failures..............................................................................................................................126

Processor Failures..........................................................................................................................127

Extractor Failure.......................................................................................................................127

Receiver Failure........................................................................................................................127

Updater Failure........................................................................................................................127

Purger Failure...........................................................................................................................128

RDFNET Failure.......................................................................................................................128

RDF State Transition Failure....................................................................................................128

Problems Involving TMF...............................................................................................................128

TMF Audited Volume Failure..................................................................................................128

TMF Subsystem Failure on the Primary System......................................................................128

TMF Subsystem Failure on the Backup System.......................................................................129

Volume Recovery Processing..............................................................................................129

Volume Recovery Failure....................................................................................................129

File Recovery on the Primary System............................................................................................130

File Recovery on the Backup System.............................................................................................130

TMFCOM ABORT TRANSACTION With AVOIDHANGING Option on Primary System........131

Audit Trails Pinned by RDF on the Primary System.....................................................................131

Stopping RDF......................................................................................................................................132

Stopping RDF by Stopping TMF...................................................................................................133

Stopping RDF From the Primary System......................................................................................134

Stopping RDF From the Backup System.......................................................................................134

Stopping RDF Using STOP RDF, DRAIN......................................................................................135

Stopping RDF using STOP RDF, REVERSE Operation.................................................................135

Restarting RDF....................................................................................................................................136

Carrying Out a Planned Switchover...................................................................................................136

Standard Configurations...............................................................................................................136

Using STOP RDF, REVERSE and the REVERSE Trigger...............................................................137

Reciprocal Configurations and Switchover...................................................................................137

Takeover Operations...........................................................................................................................139

The RDF Takeover Operation........................................................................................................139

Phase One Undo Pass...............................................................................................................139

Phase Two Undo Pass...............................................................................................................140

Phase Three Undo Pass............................................................................................................140

Issuing the TAKEOVER Command...............................................................................................140

Issuing the TAKEOVER Command in an Obey File.....................................................................142

Monitoring Takeover Outcome......................................................................................................142

Takeover Failure............................................................................................................................143

Table of Contents 7

Monitor Considerations...........................................................................................................143

Updater Considerations...........................................................................................................143

Takeover and Triple Contingency..................................................................................................143

Checking Exception Files for Uncommitted Transactions............................................................143

How to Plan for the Fastest Movement of Business Operations to Your Backup System After

Takeover.........................................................................................................................................144

Restoring the Primary System.......................................................................................................147

Online Method of Resynchronizing the Primary Database.....................................................148

Offline Method of Resynchronizing the Primary Database.....................................................148

Reading the Backup Database (BROWSE versus STABLE Access)....................................................149

Near Real Time Read Access to Updates on the Primary System......................................................149

Access to Backup Databases with Stable Access................................................................................150

Stopping TMF on the Primary System..........................................................................................150

Using the STOP RDF, DRAIN Command.....................................................................................150

STOP UPDATE to a Timestamp....................................................................................................150

RDF and NonStop SQL DDL Operations...........................................................................................151

Performing Nonshared Access DDL Operations..........................................................................152

Performing Shared Access DDL Operations.................................................................................152

Network Configurations and Shared Access NonStop SQL DDL Operations........................153

RDF and NonStop SQL/MX Operations.............................................................................................153

Backing Up Image Trail Files..............................................................................................................153

TMF and Online Dumps on the Backup System................................................................................154

Doing FUP RELOAD Operations With Updaters Running...............................................................155

Exception File Optimization...............................................................................................................155

Switching Disks on Updater UPDATEVOLUMES.............................................................................155

Online Remirroring of Updater SUBVOLUMES................................................................................156

6 Maintaining the Databases......................................................................................157

Understanding Database States..........................................................................................................157

Making Changes to Database Structures............................................................................................159

NonStop SQL/MP or NonStop SQL/MX Databases......................................................................160

Catalog Changes.......................................................................................................................160

DDL Operations.......................................................................................................................160

With Shared Access.............................................................................................................160

Without Shared Access.......................................................................................................161

Adding a New Column.......................................................................................................161

Guidelines for Create Index and Alter Table Move Operations.........................................162

Example for CREATE INDEX With Shared Access............................................................162

Multiple Indexes on a Single Base Table.............................................................................162

Partition Key Changes..............................................................................................................163

Table Purges.............................................................................................................................163

Enscribe Databases........................................................................................................................164

The STOP TMF Method............................................................................................................164

The STOP RDF DRAIN Method...............................................................................................164

Resynchronizing Databases................................................................................................................164

Resynchronizing Entire Databases Offline....................................................................................165

Resynchronizing Individual Volumes, Tables, and Files Offline..................................................165

Resynchronizing Individual Tables or Files Offline......................................................................166

7 Online Database Synchronization...........................................................................167

Overview.............................................................................................................................................167

Synchronizing Entire Databases Online.............................................................................................168

Considerations When Synchronizing Entire Databases................................................................169

8 Table of Contents

Duration and Preparation Issues..............................................................................................170

SYNCHDBTIME Issues............................................................................................................170

Enscribe Create Records......................................................................................................170

Stop-RDF-Updater Records................................................................................................170

TMF Shutdown Records.....................................................................................................171

CREATE/LOAD Issues (Step 4, Method 1)...............................................................................171

General Considerations for Enscribe Files..........................................................................171

Special Consideration for Enscribe Files.............................................................................172

General Considerations for NonStop SQL Tables...............................................................172

Enscribe Queue File Issues.......................................................................................................172

Different NonStop SQL Product Versions................................................................................173

Moving Duplicated Tables and Files to the Backup System....................................................173

Example of Synchronizing An Entire Database Online................................................................174

Synchronizing Selected Database Portions Online.............................................................................176

Overview........................................................................................................................................176

Example #1 – Staged Synchronization of an Entire Database..................................................176

Example #2 – Synchronization of an Individual Volume.........................................................176

Example #3 – Synchronization of an Individual File or Partition on a Volume.......................176

Partial Database Synchronization Issues.......................................................................................177

Enscribe Files Without Partitions.............................................................................................177

Key-Sequenced and Relative Files......................................................................................177

Entry-Sequenced Files.........................................................................................................177

Enscribe Files With Partitions...................................................................................................177

Key-Sequenced Files with Create/Load (Step 4, Method 1)...............................................177

Key-Sequenced Files with FRNL (Step 4, Method 2)..........................................................178

Relative Files with Create/Load (Step 4, Method 1)...........................................................178

Relative Files with FRNL (Step 4, Method 2)......................................................................178

Entry-Sequenced Files.........................................................................................................178

NonStop SQL/MP and NonStop SQL/MX Tables Without Partitions.....................................178

Tables with SYSKEY or Clustering Keys.............................................................................178

Tables without SYSKEY and Clustering Keys....................................................................178

NonStop SQL/MP and NonStop SQL/MX Tables With Partitions...........................................179

Requirements for Synchronization of Individual Partitions...............................................179

Key-Sequenced Tables.........................................................................................................180

Relative Tables.....................................................................................................................181

NonStop SQL/MP and NonStop SQL/MX Indexes (With or Without Partitions)...................183

Phases of Online Database Synchronization.......................................................................................183

Extractor Phases.............................................................................................................................183

Phase 1, Part 1...........................................................................................................................183

Phase 1, Part 2...........................................................................................................................183

Phase 1, Part 3...........................................................................................................................183

Phase 2......................................................................................................................................184

Updater Phase 2.............................................................................................................................184

Extractor Restart Considerations During Online Database Synchronization....................................184

Determining When Online Database Synchronization Is Complete..................................................184

Extractor Messages........................................................................................................................184

Updater Messages..........................................................................................................................184

8 Entering RDFCOM Commands................................................................................187

Elements of RDFCOM Command Descriptions.................................................................................187

Purpose, Syntax, and Attributes....................................................................................................187

Where Issued.................................................................................................................................187

Security Restrictions......................................................................................................................187

RDF State Requirement.................................................................................................................188

Table of Contents 9

Usage Guidelines...........................................................................................................................188

Output Displayed..........................................................................................................................190

Examples........................................................................................................................................190

RDFCOM-Related Filenames and Process Identifiers........................................................................190

Reserved File Names.....................................................................................................................191

Disk File Names.............................................................................................................................191

Nondisk Device Names.................................................................................................................191

Process File Names........................................................................................................................192

RDFCOM Commands.........................................................................................................................192

ADD...............................................................................................................................................193

Where Issued............................................................................................................................193

Security Restrictions.................................................................................................................193

RDF State Requirement............................................................................................................193

Usage Guidelines......................................................................................................................194

Examples..................................................................................................................................194

ALTER............................................................................................................................................195

Where Issued............................................................................................................................196

Security Restrictions.................................................................................................................196

RDF State Requirement............................................................................................................196

Usage Guidelines......................................................................................................................196

Examples..................................................................................................................................196

COPYAUDIT..................................................................................................................................197

Where Issued............................................................................................................................197

Security Restrictions.................................................................................................................197

RDF State Requirement............................................................................................................197

Usage Guidelines......................................................................................................................197

COPYAUDIT Restartability......................................................................................................198

Example....................................................................................................................................199

DELETE..........................................................................................................................................199

Where Issued............................................................................................................................199

Security Restrictions.................................................................................................................200

RDF State Requirement............................................................................................................200

Usage Guidelines......................................................................................................................200

Examples..................................................................................................................................200

EXIT...............................................................................................................................................201

Where Issued............................................................................................................................201

Security Restrictions.................................................................................................................201

RDF State Requirement............................................................................................................201

Usage Guidelines......................................................................................................................201

Example....................................................................................................................................201

FC...................................................................................................................................................201

Where Issued............................................................................................................................202

Security Restrictions.................................................................................................................202

RDF State Requirement............................................................................................................202

Usage Guidelines......................................................................................................................202

Examples..................................................................................................................................202

HELP..............................................................................................................................................203

Where Issued............................................................................................................................203

Security Restrictions.................................................................................................................203

RDF State Requirement............................................................................................................204

Usage Guidelines......................................................................................................................204

Examples..................................................................................................................................204

HISTORY.......................................................................................................................................205

Where Issued............................................................................................................................205

Security Restrictions.................................................................................................................205

10 Table of Contents

RDF State Requirement............................................................................................................205

Examples..................................................................................................................................205

INFO..............................................................................................................................................206

Where Issued............................................................................................................................207

Security Restrictions.................................................................................................................207

RDF State Requirements...........................................................................................................207

Usage Guidelines......................................................................................................................207

Output Displayed.....................................................................................................................208

Examples..................................................................................................................................208

INFO * Command...............................................................................................................208

INFO EXTRACTOR Command..........................................................................................209

INFO EXTRACTOR Command With OBEYFORM Option...............................................209

INFO MONITOR Command..............................................................................................210

INFO RDF Command.........................................................................................................210

INFO VOLUME Command................................................................................................210

INFO PURGER Command..................................................................................................211

INFO TRIGGER Command................................................................................................211

INFO TRIGGER Command With OBEYFORM Option......................................................212

INFO RDFNET Command..................................................................................................212

INFO NETWORK Command.............................................................................................212

INITIALIZE RDF...........................................................................................................................212

Where Issued............................................................................................................................215

Security Restrictions.................................................................................................................215

RDF State Requirement............................................................................................................215

Usage Guidelines......................................................................................................................215

Examples..................................................................................................................................217

OBEY..............................................................................................................................................217

Where Issued............................................................................................................................217

Security Restrictions.................................................................................................................217

RDF State Requirement............................................................................................................217

Usage Guidelines......................................................................................................................218

Example....................................................................................................................................218

OPEN.............................................................................................................................................218

Where Issued............................................................................................................................218

Security Restrictions.................................................................................................................218

RDF State Requirement............................................................................................................218

Usage Guidelines......................................................................................................................218

Examples..................................................................................................................................219

OUT................................................................................................................................................219

Where Issued............................................................................................................................220

Security Restrictions.................................................................................................................220

RDF State Requirement............................................................................................................220

Usage Guidelines......................................................................................................................220

Examples..................................................................................................................................220

RESET............................................................................................................................................220

Where Issued............................................................................................................................221

Security Restrictions.................................................................................................................221

RDF State Requirement............................................................................................................221

Usage Guidelines......................................................................................................................221

Examples..................................................................................................................................222

SET EXTRACTOR..........................................................................................................................222

Where Issued............................................................................................................................223

Security Restrictions.................................................................................................................223

RDF State Requirements...........................................................................................................223

Usage Guidelines......................................................................................................................223

Table of Contents 11

Examples..................................................................................................................................223

SET IMAGETRAIL.........................................................................................................................224

Usage Guidelines......................................................................................................................224

SET MONITOR..............................................................................................................................224

Where Issued............................................................................................................................225

Security Restrictions.................................................................................................................225

RDF State Requirements...........................................................................................................225

Usage Guidelines......................................................................................................................225

Example....................................................................................................................................225

SET NETWORK.............................................................................................................................225

Where Issued............................................................................................................................226

Security Restrictions.................................................................................................................226

RDF State Requirements...........................................................................................................226

Usage Guidelines......................................................................................................................226

Example....................................................................................................................................226

SET PURGER.................................................................................................................................226

Where Issued............................................................................................................................228

Security Restrictions.................................................................................................................228

RDF State Requirements...........................................................................................................228

Usage Guidelines......................................................................................................................228

Example....................................................................................................................................228

SET RDF.........................................................................................................................................228

Where Issued............................................................................................................................231

Security Restrictions.................................................................................................................231

RDF State Requirements...........................................................................................................231

Usage Guidelines......................................................................................................................231

SET RDFNET.................................................................................................................................231

Where Issued............................................................................................................................232

Security Restrictions.................................................................................................................232

RDF State Requirements...........................................................................................................232

Usage Guidelines......................................................................................................................232

Example....................................................................................................................................232

SET RECEIVER..............................................................................................................................232

Where Issued............................................................................................................................234

Security Restrictions.................................................................................................................234

RDF State Requirements...........................................................................................................234

Usage Guidelines......................................................................................................................234

Examples..................................................................................................................................234

SET TRIGGER................................................................................................................................235

Where Issued............................................................................................................................235

Security Restrictions.................................................................................................................236

RDF State Requirements...........................................................................................................236

Usage Guidelines......................................................................................................................236

Example....................................................................................................................................236

SET VOLUME................................................................................................................................236

Where Issued............................................................................................................................238

Security Restrictions.................................................................................................................238

RDF State Requirements...........................................................................................................238

Usage Guidelines......................................................................................................................238

Examples..................................................................................................................................239

SHOW............................................................................................................................................239

Where Issued............................................................................................................................240

Security Restrictions.................................................................................................................240

RDF State Requirements...........................................................................................................240

Usage Guidelines......................................................................................................................240

12 Table of Contents

Output Displayed.....................................................................................................................240

Examples..................................................................................................................................240

SHOW RDF Command............................................................................................................240

SHOW RECEIVER Command..................................................................................................241

SHOW PURGER Command.....................................................................................................241

SHOW VOLUME Command...................................................................................................241

SHOW RDFNET Command.....................................................................................................242

SHOW NETWORK Command................................................................................................242

SHOW TRIGGER Command...................................................................................................242

START RDF....................................................................................................................................242

Where Issued............................................................................................................................243

Security Restrictions.................................................................................................................243

RDF State Requirement............................................................................................................243

Usage Guidelines......................................................................................................................243

Examples..................................................................................................................................244

START UPDATE............................................................................................................................244

Where Issued............................................................................................................................244

Security Restrictions.................................................................................................................244

RDF State Requirement............................................................................................................244

Usage Guidelines......................................................................................................................244

Example....................................................................................................................................244

STATUS..........................................................................................................................................244

Where Issued............................................................................................................................245

Security Restrictions.................................................................................................................245

RDF State Requirement............................................................................................................245

Usage Guidelines......................................................................................................................245

STATUS RDF Command Output Display................................................................................245

RDF Process..............................................................................................................................247

Name........................................................................................................................................247

RTD Time.................................................................................................................................247

Pri..............................................................................................................................................248

Volume and Seqnce..................................................................................................................248

Cpus..........................................................................................................................................249

Error..........................................................................................................................................249

Special Messages......................................................................................................................249

Examples..................................................................................................................................250

STOP RDF......................................................................................................................................250

Where Issued............................................................................................................................250

Security Restrictions.................................................................................................................251

RDF State Requirement............................................................................................................251

Usage Guidelines......................................................................................................................251

Examples..................................................................................................................................252

STOP SYNCH................................................................................................................................252

Where Issued............................................................................................................................252

Security Restrictions.................................................................................................................252

RDF State Requirement............................................................................................................252

Usage Guidelines......................................................................................................................253

Example....................................................................................................................................253

STOP UPDATE..............................................................................................................................253

Where Issued............................................................................................................................253

Security Restrictions.................................................................................................................253

RDF State Requirement............................................................................................................253

Usage Guidelines......................................................................................................................254

Examples..................................................................................................................................254

TAKEOVER....................................................................................................................................255

Table of Contents 13

Where Issued............................................................................................................................255

Security Restrictions.................................................................................................................255

Usage Guidelines......................................................................................................................255

Limitation.................................................................................................................................257

Example....................................................................................................................................257

UNPINAUDIT...............................................................................................................................257

Where Issued............................................................................................................................257

Security Restrictions.................................................................................................................257

RDF State Requirement............................................................................................................258

Usage Guidelines......................................................................................................................258

Example....................................................................................................................................258

VALIDATE CONFIGURATION....................................................................................................258

Where Issued............................................................................................................................258

Security Restrictions.................................................................................................................258

RDF State Requirement............................................................................................................258

Usage Guidelines......................................................................................................................258

Example....................................................................................................................................259

9 Entering RDFSCAN Commands...............................................................................261

About the EMS Log.............................................................................................................................261

Elements of RDFSCAN Command Descriptions................................................................................261

RDFSCAN Commands.......................................................................................................................262

AT...................................................................................................................................................262

Usage Guidelines......................................................................................................................262

Examples..................................................................................................................................262

DISPLAY........................................................................................................................................262

Usage Guidelines......................................................................................................................263

Examples..................................................................................................................................263

EXIT...............................................................................................................................................263

Usage Guidelines......................................................................................................................263

Examples..................................................................................................................................264

FILE................................................................................................................................................264

Usage Guidelines......................................................................................................................264

Examples..................................................................................................................................264

HELP..............................................................................................................................................265

Usage Guidelines......................................................................................................................265

Examples..................................................................................................................................265

LIST................................................................................................................................................265

Usage Guidelines......................................................................................................................265

Output Displayed.....................................................................................................................266

Examples..................................................................................................................................266

LOG................................................................................................................................................266

Usage Guidelines......................................................................................................................267

Output Displayed.....................................................................................................................267

Examples..................................................................................................................................267

MATCH..........................................................................................................................................267

Usage Guidelines......................................................................................................................267

Examples..................................................................................................................................268

NOLOG..........................................................................................................................................268

Usage Guidelines......................................................................................................................269

Examples..................................................................................................................................269

SCAN.............................................................................................................................................269

Usage Guidelines......................................................................................................................269

Examples..................................................................................................................................269

14 Table of Contents

10 Triple Contingency...................................................................................................271

Overview.............................................................................................................................................271

Requirements......................................................................................................................................271

How Triple Contingency Works.........................................................................................................271

Hardware Requirements.....................................................................................................................272

Software Requirements.......................................................................................................................272

The RETAINCOUNT Configuration Parameter.................................................................................273

The COPYAUDIT Command..............................................................................................................274

COPYAUDIT Restartability................................................................................................................275

Using ZLT to Achieve Triple Contingency Protection for Auxiliary Audit Trails.............................275

Triple Contingency Without ZLT..................................................................................................275

Using ZLT to Achieve the same Protection...................................................................................276

Summary.............................................................................................................................................277

11 Subvolume-Level and File-Level Replication...........................................................279

INCLUDE Clauses..............................................................................................................................279

EXCLUDE Clauses..............................................................................................................................279

Wildcard Character (*)........................................................................................................................280

Within Subvolume Names.............................................................................................................280

Within Filenames...........................................................................................................................280

INCLUDE/EXCLUDE and RDFCOM In-Memory Table....................................................................280

INCLUDE and EXCLUDE Processing................................................................................................281

INCLUDEPURGE and EXCLUDEPURGE.........................................................................................281

Error Checking....................................................................................................................................282

Performance Ramifications.................................................................................................................282

Summary Examples............................................................................................................................282

12 Subvolume Name Mapping...................................................................................285

Creating a Mapfile to Define the Rules for Subvolume Name Mapping...........................................285

Rules for Creating Mapfile Mapping Strings......................................................................................285

How an Updater Manages Filename Collisions.................................................................................286

Creating a Maplog to Log Subvolume Name Mapping.....................................................................287

Adding a Mapfile and Maplog to an Updater's Configuration Record.............................................288

Managing Subvolume Name Mapping for Partitioned Files.............................................................288

13 Auxiliary Audit Trails...............................................................................................291

Auxiliary Extractor..............................................................................................................................291

Auxiliary Receiver...............................................................................................................................291

Configuring Extractors and Receivers................................................................................................291

Error conditions.............................................................................................................................291

Configuring Image Trails....................................................................................................................292

Configuring Updaters.........................................................................................................................292

Error Conditions............................................................................................................................292

Ramifications for STOP TMF, Stop-Update-to-Time, and SQL Shared Access DDL Ops..................292

Takeover Ramifications.......................................................................................................................293

Usage of Master and Auxiliary Audit Trails.......................................................................................293

Using Expand Multi-CPU Paths.........................................................................................................293

14 Network Transactions..............................................................................................295

Configuration Changes.......................................................................................................................295

NETWORK Attribute.....................................................................................................................295

Table of Contents 15

NETWORKMASTER Attribute.....................................................................................................296

Network Configuration Record.....................................................................................................296

PRIMARYSYSTEM Network Attribute....................................................................................296

BACKUPSYSTEM Network Attribute.....................................................................................296

REMOTECONTROLSUBVOL (RCSV) Network Attribute.....................................................297

PNETTXVOLUME Network Attribute....................................................................................297

Adding the Network Record....................................................................................................297

RDF Network Synchronizer (RDFNET) Process...........................................................................297

RDF Network Control Files................................................................................................................297

Normal RDF Processing Within a Network Environment.................................................................297

RDF Takeovers Within a Network Environment................................................................................298

Takeover Phase 1 – Local Undo.....................................................................................................298

Takeover Phase 2 – File Undo........................................................................................................298

Takeover Phase 3 – Network Undo...............................................................................................298

Takeover Phase 3 Performance......................................................................................................299

Communication Failures During Phase 3 Takeover Processing....................................................299

Takeover Delays and Purger Restarts............................................................................................299

Takeover Restartability..................................................................................................................299

Takeover and File Recovery...........................................................................................................300

The Effects of Undoing Network Transactions..............................................................................300

Takeover and the RETAINCOUNT Value.....................................................................................302

Network Configurations and Shared Access NonStop SQL/MP DDL Operations............................303

Network Validation and Considerations............................................................................................303

RDF Reinitialization in a Network Environment...............................................................................303

Network Master Subsystem Initialization.....................................................................................303

Non-Network Master Subsystem Initialization............................................................................303

RDF Networks and ABORT or STOP RDF Operations......................................................................304

RDF Networks and Stop-Update-to-Time Operations.......................................................................304

Sample Configurations.......................................................................................................................305

Sample Network Master Configuration........................................................................................305

Sample Non-Network Master Configuration................................................................................306

RDFCOM STATUS Display.................................................................................................................307

15 Process-Lockstep Operation....................................................................................309

Starting a Lockstep Operation............................................................................................................309

The DoLockstep Procedure.................................................................................................................310

Including the DoLockstep in COBOL85 Applications..................................................................310

Invoking DoLockStep by Way of TAL...........................................................................................310

DoLockStep Execution...................................................................................................................310

The Lockstep Transaction....................................................................................................................311

RDF Lockstep File...............................................................................................................................311

Multiple Concurrent Lockstep Operations.........................................................................................312

Lockstep and Auxiliary Audit Trails..................................................................................................312

The Lockstep Gateway Process...........................................................................................................312

NAME............................................................................................................................................312

PROGRAM....................................................................................................................................312

STARTUPMSG...............................................................................................................................313

AUTORESTART.............................................................................................................................313

Disabling Lockstep..............................................................................................................................313

Reenabling Lockstep...........................................................................................................................313

Lockstep Performance Ramifications..................................................................................................313

Lockstep and Auxiliary Audit Trails..................................................................................................314

Lockstep and Network Transactions...................................................................................................314

Lockstep Gateway Event Messages....................................................................................................314

16 Table of Contents

16 NonStop SQL/MX and RDF...................................................................................323

Including and Excluding SQL/MX Objects.........................................................................................323

Creating NonStop SQL/MX Primary and Backup Databases.............................................................323

Creating a NonStop SQL/MX Backup Database From an Existing Primary Database......................326

Online Database Synchronization With NonStop SQL/MX Objects..................................................328

Creating the Fuzzy Copy on the Primary System.........................................................................328

Creating the Fuzzy Copy on the Backup System..........................................................................330

Offline Synchronization for a Single Partition....................................................................................330

Directly From the Primary to the Backup......................................................................................330

Indirectly From the Primary to the Backup By Way of a Temporary File.....................................331

Backup Partition Does Not Already Exist.....................................................................................331

Online Synchronization for a Single Partition....................................................................................331

Correcting Incorrect NonStop SQL/MX Name Mapping...................................................................332

Primary and Backup ANSI Catalog Are the Same........................................................................332

Primary and Backup ANSI Schema Names Are Not the Same.....................................................332

Schema Subvolume Names Are Not the Same..............................................................................332

Guardian Filename Is Incorrect for Partition.................................................................................332

Consideration for Creating Backup Tables.........................................................................................333

Restoring to a Specific Location..........................................................................................................333

Example.........................................................................................................................................333

Comparing NonStop SQL/MX Tables.................................................................................................335

17 Zero Lost Transactions (ZLT).....................................................................................337

How It Works......................................................................................................................................337

Using CommitHoldMode...................................................................................................................340

Hardware Setup..................................................................................................................................340

Assigning CPUs on the Standby System............................................................................................340

RDF Configuration Attributes............................................................................................................341

RDF Remote Mirror Configuration...............................................................................................341

RDF Remote Standby Configuration.............................................................................................341

RDF Configuration Record Validation..........................................................................................341

Extractor Audit-Trail Configuration..............................................................................................341

ALTER RDF Remote Mirror Configuration...................................................................................342

ZLT Takeover Operations...................................................................................................................342

Phase 1 (ZLT Processing)...............................................................................................................342

The Audit-Fixup Process..........................................................................................................343

Phase 2 (Takeover Processing).......................................................................................................343

ZLT Events.....................................................................................................................................343

Error Conditions............................................................................................................................343

STATUS RDF..................................................................................................................................343

RDFCOM INFO and SHOW Commands......................................................................................344

Old Audit-Trail Files......................................................................................................................344

Recovering the Primary System After an RDF ZLT Takeover............................................................344

ZLT and RDF Networks......................................................................................................................346

STOP TMF Operations........................................................................................................................346

During Normal Operations...........................................................................................................346

During ZLT Takeover Processing..................................................................................................346

SQL Shared Access DDL Operations..................................................................................................347

A RDF Commands Quick Reference............................................................................349

RDFCOM Run Syntax.........................................................................................................................349

RDFCOM Commands Quick Reference.............................................................................................349

ADD...............................................................................................................................................349

Table of Contents 17

ALTER............................................................................................................................................349

COPYAUDIT..................................................................................................................................350

DELETE..........................................................................................................................................350

EXIT...............................................................................................................................................350

FC...................................................................................................................................................350

HELP..............................................................................................................................................350

HISTORY.......................................................................................................................................350

INFO..............................................................................................................................................351

INITIALIZE RDF...........................................................................................................................351

OBEY..............................................................................................................................................351

OPEN.............................................................................................................................................351

OUT................................................................................................................................................351

RESET............................................................................................................................................352

SET EXTRACTOR..........................................................................................................................352

SET IMAGETRAIL.........................................................................................................................352

SET MONITOR..............................................................................................................................352

SET NETWORK.............................................................................................................................353

SET PURGER.................................................................................................................................353

SET RDF.........................................................................................................................................353

SET RDFNET.................................................................................................................................354

SET RECEIVER..............................................................................................................................354

SET TRIGGER................................................................................................................................354

SET VOLUME................................................................................................................................354

SHOW............................................................................................................................................355

START RDF....................................................................................................................................355

START UPDATE............................................................................................................................355

STATUS..........................................................................................................................................355

STOP RDF......................................................................................................................................356

STOP SYNCH................................................................................................................................356

STOP UPDATE..............................................................................................................................356

TAKEOVER....................................................................................................................................356

UNPINAUDIT...............................................................................................................................356

VALIDATE CONFIGURATION....................................................................................................356

RDFSCAN Commands Quick Reference............................................................................................357

AT...................................................................................................................................................357

DISPLAY........................................................................................................................................357

EXIT...............................................................................................................................................357

FILE................................................................................................................................................357

HELP..............................................................................................................................................357

LIST................................................................................................................................................357

LOG................................................................................................................................................357

MATCH..........................................................................................................................................357

NOLOG..........................................................................................................................................358

SCAN.............................................................................................................................................358

File Names and Process Identifiers.....................................................................................................358

Reserved File Names.....................................................................................................................358

Disk File Names.............................................................................................................................358

Nondisk Device Names.................................................................................................................358

Process File Names........................................................................................................................358

B Additional Reference Information.............................................................................359

Default Configuration Parameters......................................................................................................359

Sample Configuration File..................................................................................................................360

RDFSNOOP Utility.............................................................................................................................362

18 Table of Contents

RDF System Files.................................................................................................................................362

RDF File Codes....................................................................................................................................364

C Messages...................................................................................................................365

About the Message Descriptions........................................................................................................365

RDF Messages.....................................................................................................................................365

RDFCOM Messages............................................................................................................................413

RDFSCAN Messages...........................................................................................................................461

D Operational Limits.....................................................................................................463

E Using ASAP................................................................................................................465

Architectural Overview......................................................................................................................465

Installation...........................................................................................................................................466

Auto Discovery...................................................................................................................................466

Monitoring Specific RDF Environments.............................................................................................466

Adding and Removing RDF Environments.......................................................................................467

Version Compatibility.........................................................................................................................467

RDF Metrics Reported by ASAP.........................................................................................................467

Index...............................................................................................................................469

Table of Contents 19

List of Figures

1-1 Basic RDF Configuration...............................................................................................................33

1-2 RDF Topologies.............................................................................................................................37

1-3 RDF Tasks to Maintain a Copy of a Database...............................................................................40

1-4 RDF Subsystem Processes.............................................................................................................41

1-5 Extractor Process Operation..........................................................................................................43

1-6 Receiver Process Operation...........................................................................................................45

6-1 Synchronized Databases Before Starting RDF............................................................................157

6-2 Synchronized Databases During RDF Operations......................................................................158

6-3 Synchronized Databases, No Outstanding Audit.......................................................................158

6-4 Synchronized Databases After STOP TMF Command...............................................................159

6-5 Unsynchronized Databases.........................................................................................................159

10-1 RDFZLT with Triple Contingency...............................................................................................276

17-1 ZLT Configuration With a Single Standby/Backup System........................................................338

17-2 ZLT Configuration With a Single Standby/Backup System and With the Remote Mirror Located

at an Intermediate Site.................................................................................................................338

17-3 ZLT Configuration With Standby and Backup Systems Located at Separate Sites....................339

E-1 The RDF/ASAP Environment......................................................................................................466

20 List of Figures

List of Tables

1-1 Audit Records at the Time of a Primary System Failure..............................................................34

2-1 RDF Hardware Requirements.......................................................................................................57

2-2 Software Requirements.................................................................................................................60

3-1 RDF Process and Program Security Attributes.............................................................................76

4-1 RDFCOM Configuration Commands..........................................................................................105

4-2 RDFCOM Operational Commands.............................................................................................106

4-3 RDFCOM Utility Commands......................................................................................................107

4-4 RDFSCAN Commands................................................................................................................110

4-5 RDF States....................................................................................................................................113

5-1 Recovery From File Modification Failures (RDF Event 700).......................................................122

5-2 Recovery From File Open Failures (RDF Event 705)...................................................................123

5-3 Recovery From File Creation Failures (RDF Event 739)..............................................................123

8-1 Systems for RDFCOM Commands..............................................................................................188

8-2 Default User Security for RDFCOM Commands........................................................................189

9-1 Pattern Matching Symbols in RDFSCAN....................................................................................268

D-1 Operational Limits for RDF/IMP, IMPX, and ZLT......................................................................463

E-1 RDF Metrics Reported by ASAP.................................................................................................467

21

List of Examples

1-1 Reciprocal Replication...................................................................................................................50

1-2 Chain Replication..........................................................................................................................51

1-3 Invalid Chain Replication..............................................................................................................51

22 List of Examples

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. At the backup system, RDF software uses the transported information to update the
backup database so that it reflects all changes made to the primary database. The backup database
is usually current within seconds of the primary. If system capability is lost at the primary system,
service can be recovered quickly at the backup system using the live backup database.

This manual describes the RDF subsystem as implemented in version 1, update 9 (RDF 1.9) for
RDF IMP, RDF/IMPX and RDF/ZLT on J-series and H-series RVUs.

This manual contains introductory and conceptual information for new users, followed by
directions for installing, configuring, and operating RDF and managing the RDF environment.
It covers activities at both the primary and backup sites and fully describes all commands available
to users. It provides complete reference information for these commands, including their syntax
and semantics. Finally, it lists all RDF messages and describes their meaning and any corrective
actions that users must take.

Supported Release Version Updates (RVUs)

This manual supports J06.03 and all subsequent J-series RVUs and H06.03 and all subsequent
H-series RVUs, until otherwise indicated by its replacement publications.

Intended Audience

This manual contains information for everyone responsible for RDF installation, management,
and operations on HP Integrity NonStop™ systems:

• System managers

• System operators

• Database administrators

• System analysts

• Application designers

Before reading this manual, you should be familiar with Integrity NonStop system architecture.
You should also understand the TMF product on which RDF is based. For information about
TMF, see the TMF manuals listed in “Related Information”.

Additionally, it is essential to note that throughout this manual the phrases NonStop SQL products
and NonStop SQL refer to the NonStop SQL/MP and NonStop SQL/MX product set.

New and Changed Information in This Edition

Besides minor corrections and clarifications throughout the manual, the significant new and
changed information contained in this manual are organised in the following manner:

New features in the RDF 1.9 manual.

• Added information on the new option of automatic deletion of RDF control files during

initialization in “Initializing RDF” (page 79) and “INITIALIZE RDF” (page 212).

• Added new section on“Managing Multiple RDFEnvironments from One RDFCOM Session”

(page 104).

• Added information on altering “UPDATEROPEN” (page 117).

Supported Release Version Updates (RVUs) 23

• Added information on running a TAKEOVER command using an OBEY file/IN File in

“Issuing the TAKEOVER Command in an Obey File”(page 142) and “TAKEOVER” (page 255).

• Added information about FASTUPDATEMODE in “Near Real Time Read Access to Updates

on the Primary System” (page 149) and “SET RECEIVER” (page 232).

• Added information on support for long filenames in “Process File Names” (page 358).

• Added the figure for Triple contingency under “Using ZLT to Achieve the same Protection”

(page 276).

• Added information on Subvolume/File Level REPLICATEPURGE option in

Chapter 11 “Subvolume-Level and File-Level Replication”.

• Added the section “INCLUDEPURGE and EXCLUDEPURGE” (page 281).

• Added a new EMS event 931 that displays the ANSI name of a SQL/MX object on which a

SHARED ACCESS DDL operation was performed.

• Added Fast TAKEOVER Guidelines in “How to Plan for the Fastest Movement of Business

Operations to Your Backup System After Takeover” (page 144).

Updates in the RDF 1.9 manual

• Updated description of AUDITTRAILBUFFER attribute in “Configuring TMF for RDF

Operations on the Primary System” (page 60).

• Updated information on Online dumps and configuration of UPDATEROPEN mode in

“Configuring TMF for RDF Operations on the Backup System” (page 61).

• Updated recommended number of Audited files per volume in “Audited Files Per Volume

on Primary System” (page 62).

• Updated details on PROTECTED mode in “UPDATEROPEN Attribute” (page 86).

• Added the section “Dedicated Image Trails or Image Trails on UpdateVolumes” (page 89).

• Added the section “Using Scripts for Easy and Fast RDF Initialization and Configuration”

(page 103).

• Added and updated Table 4-5 “RDF States” in “RDF States” (page 113).

• Updated “Main STATUS RDF Display” (page 114).

• Updated effects and workaround for “Exceeding the Maximum Number of Concurrent File

Opens” (page 125).

• Updated significance of audit pinning operation and precautions in “Audit Trails Pinned

by RDF on the Primary System” (page 131).

• Added significance of taking TMF and online dumps on backup system with respect to

business continuity in “TMF and Online Dumps on the Backup System” (page 154).

• Added the following sections in DDL Operations:

“With Shared Access” (page 160)
“Without Shared Access” (page 161)
“Adding a New Column” (page 161)

• Updated the STATUS command with description of its elements on (page 244).

• Updated the example to reflect new features in “Sample Configuration File” (page 360).

• Updated new limits for number of files open per updater in Table D-1 “Operational Limits

for RDF/IMP, IMPX, and ZLT”.

• Updated message 733 in Appendix C (page 365).

• Added new error messages in “Messages” (page 365).

Document Organization

This manual presents three levels of information: introductory and conceptual information
(Chapter 1), task-oriented guidelines (Chapters 2 through 7 and Chapters 10 through 14), and
reference information (Chapters8 and 9 and Appendixes A, B,and C). The following table shows

24

where to look for the information you need, based upon the responsibility you have or the kind
of tasks you perform at your site:

Chapter/AppendixResponsibility

AllSystem manager

1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 14, 15, 16, 17, A, C, D, ESystem operator

1, 2, 3, 5, 6, 7, 10, 11, 12, 13, 14, 15, 16, 17, A, B, C, D, EDatabase

administrator

1, 2, 3, 10, 11, 12, 13, 14, 15, 16, 17System analyst

1, 2, 10, 11, 12, 14, 15, 17, A, B, C, DApplication designer

The chapters and appendixes contain this information:

• Chapter 1 (page 31) introduces RDF and its goals, features, and capabilities; describes the

main RDF processes and their functions; introduces the RDFCOM and RDFSCAN command
interfaces used to communicate with the subsystem; and presents an overview of RDF
operation.

• Chapter 2 (page 57) describes how to configure hardware and prepare software for RDF

installation and operation.

• Chapter 3 (page 69) explains how to install and configure RDF, including how to copy

databases and files from the primary system to the backup system before starting RDF.

• Chapter 4 (page 99) discusses how to operate RDF, including how to issue RDFCOM and

RDFSCAN commands and how to display RDF configuration parameters and operating
statistics, change configuration parameters, and interpret log files.

• Chapter 5 (page 121)explains how to manage the RDF environment, including how to recover

from file-system errors, respond to failures, stop and restart the RDF product, direct the
backup system to take over application processing when a disaster occurs at the primary
system site, and perform other specialized tasks.

• Chapter 6 (page 157)details how to back up altered database structures and how to

resynchronize the primary and backup databases.

• Chapter 7 (page 167)describes how to synchronize entire databases or selected database

volumes online.

• Chapter 8 (page 187) and Chapter 9 (page 261) present the syntax of all RDFCOM and

RDFSCAN commands, respectively, and give examples of these commands.

• Chapter 10 (page 271) describes the triple contingency feature.

• Chapter 11 (page 279) describes subvolume-level and file-level replication.

• Chapter 12 (page 285) describes how to use the mapfile, maplog, and updater configuration

record to support mapping between primary system and backup system subvolumes.

• Chapter 13 (page 291) describes support for auxiliary audit trails.

• Chapter 14 (page 295) describes support for network transactions.

• Chapter 15 (page 309) describes lockstep operation.

• Chapter 16 (page 323) describes SQL/MX database setup for RDF.

• Chapter 17 (page 337) describes the Zero Lost Transactions (ZLT) functional capability.

• Appendix A (page 349) summarizes the syntax of all RDFCOM and RDFSCAN commands.

• Appendix B (page 359) provides additional information about RDF, including reserved

words, default values for configuration parameters, and system file descriptions.

• Appendix C (page 365) lists all messagesthat can be generated by the lockstep gateway, RDF

processes, RDFCOM, and RDFSCAN, and their probable causes, effects, and recovery actions.

• Appendix D (page 463) lists all the operational limits that apply to the RDF/IMP, IMPX, and

ZLT products.

• Appendix E (page 465) describes how to monitor RDF entities using ASAP.

Document Organization 25

Notation Conventions

General Syntax Notation

This list summarizes the notation conventions for syntax presentation in this manual.

UPPERCASE LETTERS

Uppercase letters indicate keywords and reserved words. Type these items exactly as shown.
Items not enclosed in brackets are required. For example:

MAXATTACH

Italic Letters

Italic letters, regardless of font, indicate variable items that you supply. Items not enclosed
in brackets are required. For example:

filename

Computer Type

Computer type letters indicate:

• C and Open System Services (OSS) keywords, commands, and reserved words. Type
these items exactly as shown. Items not enclosed in brackets are required. For example:

Use the cextdecs.h header file.

• Text displayed by the computer. For example:

Last Logon: 14 May 2006, 08:02:23

• A listing of computer code. For example

if (listen(sock, 1) < 0)
{
perror("Listen Error");
exit(-1);
}

Bold Text

Bold text in an example indicates user input typed at the terminal. For example:

ENTER RUN CODE

?123
CODE RECEIVED: 123.00

The user must press the Return key after typing the input.

[ ] Brackets

Brackets enclose optional syntax items. For example:

TERM [\system-name.]$terminal-name

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

26

{ } Braces

A group of items enclosed in braces is a list from which you are required to choose one item.
The items in the list can be arranged either vertically, with aligned braces on each side of the
list, or horizontally, enclosed in a pair of braces and separated by vertical lines. For example:

LISTOPENS PROCESS { $appl-mgr-name }
{ $process-name }

ALLOWSU { ON | OFF }

| Vertical Line

A vertical line separates alternatives in a horizontal list that is enclosed in brackets or braces.
For example:

INSPECT { OFF | ON | SAVEABEND }

… Ellipsis

An ellipsis immediately following a pair of brackets or braces indicates that you can repeat
the enclosed sequence of syntax items any number of times. For example:

M address [ , new-value ]…

- ] {0|1|2|3|4|5|6|7|8|9}…

An ellipsis immediately following a single syntax item indicates that you can repeat that
syntax item any number of times. For example:

"s-char…"

Punctuation

Parentheses, commas, semicolons, and other symbols not previously described must be typed
as shown. For example:

error := NEXTFILENAME ( filename ) ;

LISTOPENS SU $process-name.#su-name

Quotation marks around a symbol such as a bracket or brace indicate the symbol is a required
character that you must type as shown. For example:

"[" repetition-constant-list "]"

Item Spacing

Spaces shown between items are required unless one of the items is a punctuation symbol
such as a parenthesis or a comma. For example:

CALL STEPMOM ( process-id ) ;

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. For example:

ALTER [ / OUT file-spec / ] LINE

[ , attribute-spec ]…

Notation Conventions 27

!i and !o

In procedure calls, the !i notation follows an input parameter (one that passes data to the
called procedure); the !o notation follows an output parameter (one that returns data to the
calling program). For example:

CALL CHECKRESIZESEGMENT ( segment-id !i
, error ) ; !o

!i,o

In procedure calls, the !i,o notation follows an input/output parameter (one that both passes
data to the called procedure and returns data to the calling program). For example:

error := COMPRESSEDIT ( filenum ) ; !i,o

!i:i

In procedure calls, the !i:i notation follows an input string parameter that has a corresponding
parameter specifying the length of the string in bytes. For example:

error := FILENAME_COMPARE_ ( filename1:length !i:i
, filename2:length ) ; !i:i

!o:i

In procedure calls, the !o:i notation follows an output buffer parameter that has a
corresponding input parameter specifyingthe maximum length of the output buffer in bytes.
For example:

error := FILE_GETINFO_ ( filenum !i
, [ filename:maxlen ] ) ; !o:i

Notation for Messages

This list summarizes the notation conventions for the presentation of displayed messages in this
manual.

Bold Text

Bold text in an example indicates user input typed at the terminal. For example:

ENTER RUN CODE

?123
CODE RECEIVED: 123.00

The user must press the Return key after typing the input.

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. For example:

Event number = number [ Subject = first-subject-value ]

28

A group of items enclosed in brackets is a list of all possible items that can be displayed, of
which one or none might actually be displayed. 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:

proc-name trapped [ in SQL | in SQL file system ]

{ } Braces

A group of items enclosed in braces is a list of all possible items that can be displayed, of
which one is actually displayed. The items in the list can be arranged either vertically, with
aligned braces on each side of the list, or horizontally, enclosed in a pair of braces and
separated by vertical lines. For example:

obj-type obj-name state changed to state, caused by
{ Object | Operator | Service }

process-name State changed from old-objstate to objstate
{ Operator Request. }
{ Unknown. }

| Vertical Line

A vertical line separates alternatives in a horizontal list that is enclosed in brackets or braces.
For example:

Transfer status: { OK | Failed }

% Percent Sign

A percent sign precedes a number that is not in decimal notation. The % notation precedes
an octal number. The %B notation precedes a binary number. The %H notation precedes a
hexadecimal number. For example:

%005400

%B101111

%H2F

P=%p-register E=%e-register

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.

• TMF Planning and Configuration Guide, whichprovides information on howto plan, configure,

and manage a TMF system.

• TMF Operations and Recovery Guide, which describes how to monitor TMF operations,

reconfigure TMF, perform online and audit dumps, and respond to a variety of exception
conditions.

• TMF Reference Manual, which covers the syntax, cautionary considerations, and examples

for using the TMFCOM command interface to the TMF product.

Another manual in the Data Management Library, Introduction to Data Management, provides an
overview of NonStop data management products, including RDF, and discusses the use of these
products in OLTP applications.

Related Information 29

Manuals for other software products that contain information helpful to RDF users include:

• SQL/MX Installation and Management Guide and the SQL/MP Installation and Management

Guide, which explain how to install the NonStop SQL/MX and SQL/MP relational database
management systems andhow to plan, create, and manage SQL/MX and SQL/MP databases
and applications.

• SQL/MX Reference Manual and the SQL/MP Reference Manual, which describe the command

and statement syntax and usage considerations for the NonStop SQL/MX and SQL/MP
relational database management systems, including interaction with the NonStop SQL
product for database protection.

• SQL/MP Version Management Guide, which describes version management for different

versions of the NonStop SQL/MP software, catalogs, objects, messages, files, and programs.

• TACL Reference Manual, which discusses operations available in the HP Tandem Advanced

Command Language (TACL), the standard command interface to the NonStop operating
system. This is the interface through which you run RDFCOM and RDFSCAN and manage
files used by them.

• File Utility Program (FUP) Reference Manual, which describes the command syntax and error

messages for the File Utility Program (FUP).

• Operator Messages Manual, which describes various error codes.

• Guardian Procedure Errors and Messages Manual, which provides additional details about

understanding and correcting file system errors.

Publishing History

Publication DateProduct VersionPart Number

July 2005NonStop RDF/IMPX 1.6 (T0346 and T0347)

NonStop RDF/ZLT 1.6 (T0618)

529826-002

November 2005NonStop RDF/IMPX 1.7 (T0346 and T0347)

NonStop RDF/ZLT 1.7 (T0618)

529826-003

August 2007NonStop RDF/IMPX 1.8 (T0346 and T0347) and Lockstep Gateway
(T1226)
NonStop RDF/ZLT 1.8 (T0618)

529826–004

May 2009NonStop RDF/IMPX 1.9 (T0346 and T0347) and Lockstep Gateway
(T1226)
NonStop RDF/ZLT 1.9 (T0618)

529826–005

June 2009NonStop RDF/IMPX 1.9 (T0346 and T0347) and Lockstep Gateway
(T1226)
NonStop RDF/ZLT 1.9 (T0618)

529826–006

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:

[e-mail]

Include the document title, part number, and any comment, error found, or suggestion for
improvement you have concerning this document.

30

1 Introducing RDF

This manualdescribes the Remote Database Facility (RDF) subsystem as implemented inversion
1, update 9 of the HP NonStop RDF/IMP, IMPX, and ZLT independent products. Customers
who install RDF 1.9 can use existing RDF configuration scripts provided the scripts are not
making use of new functionality.

This chapter, which is intended for all readers, discusses these topics:

• “RDF Subsystem Overview” (page 32)

• “User Interfaces” (page 38)

• “RDF Processes” (page 40)

• “RDF Operations” (page 42)

RDF monitors changesmade to a production database on alocal (primary) system and maintains
a copy of that database on one or more remote (backup) systems. Because it applies changes to
the backup database as soon as they are detected on the primary system, RDF keeps the backup
database continuously up to date with changes made by business applications on the primary
system. You are able, therefore, to switch your business operations from the primary system to
the backup system with minimal interruption and loss of data in the event of planned or
unplanned outages of the primary system. With NonStop RDF/ZLT, the failover involves no loss
of data.

RDF also allows you to use backup databases as read-only resources to balance the overall
workload and improve response times. Activities at a backup system can include querying the
database, processing heavy batch-reporting loads, and consolidating data from multiple sites
into one central site.

Backup systems might be located far from the primary system for protection against regional
disasters, communicating with the primary system over an Expand network.

System managers and operators control RDF through RDFCOM, a utility much like the TMFCOM
command interpreter used to access TMF.

RDF/IMP, IMPX, and ZLT generate fully-tokenized command, event, error, and warning messages
in the Event Management System (EMS) log. System managers and operators can monitor those
messages online using Viewpoint or whatever other tool they normally use for monitoring $0.
In addition, they can use the supplied EMS filter RDFFLTO with an EMS printing distributor to
isolate the RDF messages to an entry-sequenced file which they then can peruse using the
RDFSCAN utility.

RDF works with the Transaction Management Facility (TMF) subsystem.

There are three versions of the RDF product:

1. RDF/IMP (product number T0346) provides online product initialization, online database

synchronization, triple contingency support, subvolume-level and file-level replication,
stop-update-to-time (for quiescing the backup database to a stable state), and many other
features.

2. RDF/IMPX (product numbers T0346 and T0347) provides the same functionality as RDF/IMP,

but also replication of auxiliary audit trails, support for network transactions, and lockstep
operation.

3. RDF/ZLT (product number T0618) provides zero lost transaction (ZLT) protection using

mirrored disks.

NOTE: HP NonStop RDF software works with HP NonStop S-Series servers, HP Integrity

NonStop NS-Series servers, and HP Integrity NonStop BladeSystems.

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

31

operates, such as transactions, audit trails, and audit volumes. You should understand how
TMF software uses elements like before-images, after-images, and control records. In addition,
you should also understand the TMF processes that perform backout, volume recovery, and
file recovery. If you are not familiar with this information, you should read TMF Introduction.

RDF Subsystem Overview

RDF maintains a logically replicated database on one or more backup systems by monitoring
changes made to audited tables and files on designated primary system volumes and applying
those changes to corresponding volumes on the backup system. Although logically the same as
the primary database, a backup database is not an actual physical copy. For those volumes
designated to beprotected by RDF, the backup database contains thesame data for all committed
transactions as in the primary database.

On the primary system, RDF extractor processes read audit trails (logs maintained by TMF of
all database transactions that affect audited tables and files), and send all audit records associated
with volumes protected by RDF to RDF receiver processes on the backup system. Each receiver
process sorts the audit records and writes it to the appropriate image trail. RDF updater processes
on the backup system read their image trails and apply the changes to the backup database. An
RDF purger process on the backup system interacts with the updaters to determine when image
files can be purged.

Each volume protected by RDF on the primary system has its own updater process on the backup
system responsiblefor applying audit records to the corresponding volume on the backup system.

Figure 1-1 illustrates a basic RDF configuration that protects data volumes configured to a Master

Audit Trail (MAT) and an auxiliary audit trail.

32 Introducing RDF

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 records for volumes $D1 through $D10 and $D16 through $D20 are sent to the master
audit trail (MAT). The RDF master extractor process reads the MAT and sends audit records
associated with volumes $D1 through $D10 to the RDF master receiver process on the backup
system.

Audit records for volumes $D11 through $D15 are sent to the auxiliary audit trail. The RDF
auxiliary extractor process reads the auxiliary audit trail and sends audit records associated with
volumes $D11 through $D15 to the RDF auxiliary receiver process on the backup system.

The master receiver writes transaction status information to the master image trail. In this example,
each receiver process writes all audit records to a single secondary image trail. As will be discussed
later, however, either could write to multiple sorted image trails.

Updater processes $UP1 through $UP10 read audit records from the secondary image trail and
apply it to volumes $D1 through $D10, respectively, on the backup system. For example, updater
process $UP1 only looks for audit records for tables and files associated with volume $D1 on the
primary system (ignoring any for volumes $D2 through $D10), and applies that information to
the corresponding tables and files on $D1 on the backup system.

Updater processes $UP11 through $UP15 read audit records from the AUX01 secondary image
trail and apply it to volumes $D11 through $D15, respectively, on the backup system.

As mentioned earlier, the RDFCOM process on the primary system provides the user interface
for issuing RDF commands. The RDF monitor process coordinates user commands among the
RDF processes and monitors those processes during all RDF states.

RDF Subsystem Overview 33

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. You do that by starting RDFCOM on the backup system and
initiating an RDF takeover operation.

An RDF takeover operation ensures that all audit records associated with transactions that are
known to have been committed is applied to the backup database

Unplanned Outages With 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). That is, one mirror of an
audit trail volumeremains local to the primary system,but the other mirror is located at a remote
standby site.

When a primary system is downed by some unplanned outage or disaster, there might be some
audit data that the extractor on the primary system was unable to send to the backup system
before the outage. With ZLT functionality, RDF fetches all remaining audit data from the remote
mirror, thereby guaranteeing no loss of committed data during the RDF takeover operation.

For information about the ZLT function, see Chapter 17 (page 337).

Unplanned Outages Without ZLT

Without ZLT functionality, it is possible for some committed transactions to be lost during an
unplanned outage. When the RDF TAKEOVER command is issued, any transaction whose final
outcome is unknown on the backup system is backed out of the backup database. One or more
transactions might have committed on the primary system, but, before the extractor could read
and send the associated audit data to the backup system, the primary system failed. Lossof audit
data in this manner typically involves no more than a fraction of a second.

If the primary system is unexpectedly brought down because of a disaster, the outcome of some
transactions might never be known, as illustrated in Table 1-1.

Table 1-1 Audit Records at the Time of a Primary System Failure

Updates sent to the backup (Sequence in image trail file)Primary database updates (Sequence in master audit trail

file)

TRANS100—Update 1TRANS100—Update 1

TRANS100—Update 2TRANS100—Update 2

..

..

..

TRANS100—Update 10TRANS100—Update 10

TRANS101—Update 1TRANS101—Update 1

TRANS100—Commit record

(Primary system fails)

In the example illustrated in Table 1-1, a disaster has brought down the primary system
immediately after the commit record for transaction 100 was written to the MAT, but before the
RDF extractor process was able to send the commit record to the backup system. For transaction

34 Introducing RDF

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. Therefore, in the example illustrated in Table 1-1, the audit records associated
with transactions 100 and 101 is backed out of the backup database.

Typically, the extractor process sends audit records to the backup system within a second after
it has been written to the MAT on the primary system, so a minimum number of transactions
are lost when a disaster brings down the primary system.

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. In such a situation, you might determine it is unacceptable to stop
your business applications for the time required.

With RDF, you need only stop the applications momentarily, do a switchover from the primary
system to the backup system, and then restart the applications on the backup system. When the
primary system is ready for use again,you can use RDF to bring the primary database up-to-date
with changes made to the backup database while the primary system was shut down. After the
primary database is consistent with the backup database, you can perform another switchover,
this time from the backup system to the primary system, and then restart the applications on the
primary system. For instructions on how to perform a switchover, see “Carrying Out a Planned

Switchover” (page 136).

Features

In providing backup protection for online databases, RDF offers many advantages:

• Continuous Availability

RDF maintains an online copy of your production database on one or more backup systems.
If the primary system should go down, the backup database(s) will be consistent and you
can resume your business processing on a backup system with minimal interruption and
data loss.

• Fault tolerance

You can restart RDF after a system failure. Single processor failures do not bring the
subsystem down. If a double processor failure occurs, RDF goes down, but it can be restarted
with no loss of data (issue a START RDF command after the processors have been restored).

• High performance

RDF can typically replicate data from the primary RDF node as fast as the customer
application is capable of generating it.

• Flexibility in protection

You can run RDF with updating on the backup system either enabled or disabled.

RDF is also very flexible with regard to system interrelationships and to disk usage
requirements on backup systems. Besides the most basic configuration of a single primary
system protected by a single backup system, you can have configurations such as these (see

Figure 1-2 (page 37)).

— Multiple primary systems protected by one backup system.
— Reciprocal protection between two systems, where each is the backup to the other

(different databases on the two systems).

RDF Subsystem Overview 35

— A single primary system whose database changes are replicated to databases on multiple

backup systems. Such an environment makes possible simultaneous read-only access
to all of the backup databases (this is desirable for query-intensive applications such as
telephone directory assistance).

— Triple contingency—a special instance of the database replication feature whereby a

single primary system is protected by two identical backup systems. This feature allows
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.

— RDF does not require an identical one-to-one volume relationship between volumes on

the primary system and those on the backup system. Backup volume names do not
have to match primary volume names. The subsystem can direct audit records from
more than one audited volume on the primary system to a single volume on the backup
system, provided that no more than one partition of a file exists on any backup volume.
(For information on partitioned files, see the Guardian User’s Guide.)

• Application independence

RDF is application independent. It can protect through replication any audited NonStop
SQL tables and indexes as well as any audited Enscribe key-sequenced, relative, or
entry-sequenced files, including partitions, alternate key files, and Queue files. Unstructured
Enscribe files, however, are not supported.

36 Introducing RDF

Figure 1-2 RDF Topologies

• Supports 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.

RDF Subsystem Overview 37

• 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 records to the backup system. The extractor process automatically filters out
any audit records not relevant to the backup database.

On the backup system RDF stores and applies all audit records without using any primary
system resources.

RDF helpsbalance the load between the primary and backup systems. For example, to reduce
the application load on the primary system, you can perform database queries on the backup
system; RDF does not, however, guarantee database consistency while changes are being
processed for a transaction.

• Access to Consistent Backup Databases

There are two ways to quiesce the backup database in a logically consistent state with regard
to transactionboundaries: stop TMF on the primary system or use theTIMESTAMP parameter
in a STOP UPDATE command (referred to as a stop-update-to-time operation). The latter
allows you to do so without stopping TMF, your applications, or the RDF extractor.

• Zero Lost Transactions (ZLT)

ZLT is a functional capability that uses mirrored disks to guarantee that no committed
transactions on the primary system will be lost in the event of an RDF takeover by the backup
system.

User Interfaces

To useRDF, you run two online utilities: RDFCOM and RDFSCAN. Bothare interactive command
interpreters through which you begin a session and enter requests to the subsystem.

RDFCOM for Subsystem Management and Operations

To manage, operate, and control RDF, use the RDFCOM utility. You can issue commands to:

• Configure RDF

• Control RDF operation

• Obtain status information about RDF regarding database activity on the primary system

and processing on the backup system

Tasks and examples using RDFCOM commands appear throughout the manual. Reference
information for all commands appears in Chapter 8 (page 187).

Scanning the EMS Event Log

RDF writes messages to the EMS event log when any of these events occurs:

• RDF is initialized

• RDF is started or stopped

• Updating is started or stopped

• RDF issues an informational, warning, or error message (including RTD warning messages)

• An RDF process takeover occurs

• Control switches from the primary to the backup database

• A NonStop SQL/MP DDL operation using the WITH SHARED ACCESS option is detected

• An exception record is written

38 Introducing RDF

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.

Using RDFSCAN commands, you can specify:

• A starting point for scanning the intermediate RDF message file

• How many records to scan

• Text to search for in the file

Tasks and examples for using RDFSCAN commands appear throughout the manual. Reference
information for all commands appears in Chapter 9 (page 261).

RDF Tasks

To maintain a duplicate of the primary database on the backup system, RDF performs four
fundamental tasks:

• On the primary system, the extractor process captures audit records from the TMF MAT

and, optionally, from auxiliary audit trails.

• On the primary system, the extractor process filters out audit records that are not relevant

to the backup database (audit records for volumes or files not protected by RDF) and then
transmits the relevant audit records to the backup system. These auditrecords have additional
information added to them by the extractor and the transformed audit records are then
called image records.

• On the backup system, the receiver process accepts the buffer of image records sent by the

extractor, sorts each record to the correct image trail buffer, and eventually writes the
collection of image trail buffers to the actual image trailson disk.

• On the backup system, each updater process reads the image records it is responsible for

out of its image trail and sends the audit portion directly to disk process that manages the
volume where that updater's database files reside. During normal RDF operations, the disk
process applies the audit to the affected database file or table with the logical REDO operation.
During the special RDF Takeover or stop-update-to-time operations, the disk process can
also perform logical UNDO operations for those audit records that need to be backed out
of the backup database.

NOTE: Throughout this manual, the terms image records and audit records are used

interchangeably on the backup system. An image record is just the original audit record with some
additional RDF specific information added to it. When an updater prepares an image record to
send to the disk process, it strips out that added RDF information and sends the original audit
record.

Figure 1-3 illustrates these tasks as they are performed during normal processing when RDF

updating is enabled. The sequence of events differs when updating is disabled, as explained in

“RDF Operations”.

RDF Tasks 39

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.
More details about their operation appear in“RDF Operations” (page 42) .

40 Introducing RDF

Figure 1-4 RDF Subsystem Processes

Primary System Processes

On the primary system:

• The monitor process coordinates most RDFCOM commands involving the main RDF

processes (for example, start and stop).

• Each extractor process reads an audit trail (the MAT or a particular auxiliary audit trail),

filters out audit records not relevant to the backup database, transforms the audit record
into an image record, and then transmits the image records to an associated receiver process
on the backup system. Some control information for synchronizing the extractor and receiver
process pair is included each time the extractor process transmits the audit records.

RDF Processes 41

Backup System Processes

On the backup system:

• There is one receiver process for each configured extractor process. A receiver accepts the

image 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. The backup
database is updated in cache each time the disk process performs a logical REDO operation
requested by an updater process.

• The purger process interacts with the updaters to determine when image files can be purged,

and also determines which transactions updaters must undo for takeover and
stop-update-to-time operations.

RDF Operations

RDF can be run with updating of the backup database either enabled or disabled.

When updating is enabled, the RDF processes maintain a current, online copy of the primary
database on the backup system. By default, the subsystem starts with updating enabled, and the
RDF processes continue their updating activities until updating is explicitly disabled or the
subsystem is shut down.

When updating is disabled, the extractor process still transmits the TMF audit records from the
audit trails to the backup system, but no changes are applied to the backup database. The receiver
continues to collect audit records from the extractor and writes these records to the image trails.
However, the updater processes do not run while updating is disabled.

Updating can be explicitly enabled or disabled through RDFCOM commands, as described later
in this manual. If takeover performance is critical, you should run RDF with updating enabled.
If updating is disabled, it is possible for the image trails to fill up; also, it may take significant
time for the updaters to apply all audit records when a takeover operation is started.

The monitor, extractor, receiver, RDFNET, updater, and purger processes run as process pairs.

Monitor Process

The monitor process is a process pair that normally runs on the primary system. This process is
responsible for starting, stopping, and monitoring all other RDF processes on the primary and
backup systems.

Extractor Process

An extractor process is a process pair that runs on the primary system. Each extractor process
reads an audit trail (the MAT or a particular auxiliary audit trail), filters out audit records not
relevant to the backup database, and then transmits the relevant audit records over the Expand
network to an associated receiver process on the backup system, as shown in Figure 1-5.

42 Introducing RDF

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 291).

Figure 1-5 Extractor Process Operation

Reading large amounts of data from the MAT, the extractor process stores the following records
for subsequent transmission to the backup system:

• TMF control records

— All transaction state records
— TMP control point records
— TMF shutdown records
— File-incomplete records
— File-complete records
— Stop-RDF-Updater records

• Redo audit records for RDF protected files (generated by applications)

• Undo audit records for RDF-protected files (generated by TMF undo processing)

• Filelabel modifications for the following Enscribe DDL operations

— CREATE
— PURGEDATA
— ALTER MAXEXTENTS
— PURGE (if REPLICATEPURGE is enabled)

• Filelabel modifications for the following NonStop SQL operation

— PURGEDATA

NOTE: Except for PURGEDATA, RDF does not replicate NonStop SQL DDL operations on

any SQL objects. For more information about NonStop SQL DDL operations and databases on
a system protected by the RDF product, see Chapter 6 (page 157) and Chapter 16 (page 323).

The extractor filters out all other records and does not send them to the receiver. Among those
filtered out are audit records for volumes and files not protected by RDF (and files implicitly or

RDF Operations 43

explicitly excluded by INCLUDE/EXCLUDE lists), most of the physical audit records generated
either for block splits or during FUP RELOAD operations, and all audits generated by the RDF
updaters.

The extractor always tries to fill the buffer to be sent to the receiver. The buffer never contains
partial records; if the buffer is nearly full and the next record to be transmitted does not fit in its
entirety, the extractor transmits the current buffer and puts that next record at the beginning of
the next buffer. The extractor never waits for more than one second to send data to the receiver.
If its current buffer is not filled within a second, the extractor transmits the buffer (even though
it is not filled).

Although the extractor runs as a process pair, the primary process does not maintain restart
information nor checkpoint this information to its backup. Instead, the receiver maintains all
restart information for the extractor, ensuring that the extractor can be restarted without any loss
of data. The restart point is based on the MAT position of the last record safely stored in the
image trail on the backup system.

Whenever you start RDF, the extractor requests its starting position in the audit trail from the
receiver. Because this position is based on the audit trail position of the last image record safely
stored in the image trail by the receiver, this method guarantees that no audit is mistakenly
omitted. If the primary extractor process fails, the backup process requests from the receiver a
new starting position in the audit trail, ensuring a correct restart position. This extractor-receiver
protocol also provides protection against messages from the extractor erroneously arriving
out-of-order: if a message arrives out-of-order, the receiver directs the extractor to restart.

When the extractor reads from an audit trail file, it pins the file by sending a message to TMF.
Once pinned, an audit trail file remains pinned until the extractor unpins it or if you issue the
RDFCOM UNPINAUDIT command at the primary system.

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.
If they are not dumped, and the TMP renames the file or files required by the extractor, you will
have to reinitialize RDF and resynchronize the primary and backup databases.

In response to the UNPINAUDIT command, RDFCOM issues a prompt asking you to confirm
your request.

If the files are unpinned successfully, RDFCOM issues an informational message to that effect.

If an error occurs while attempting to unpin the audit trail files, the command is ignored, and
RDFCOM issues a message indicating the error.

Receiver Process

A receiver process is a process pair that runs on the backup system. There is one receiver for
each configured extractor. A receiver process accepts audit records from its extractor, sorts them,
and then writes them to the appropriate RDF image trail, as shown in Figure 1-6. (The restartability
of a receiver ensures the receiver's correctness at process takeover or under any conditions
requiring resynchronization with its extractor.)

A receiver determines which updater will apply a given image record, and it sorts that record
into the image trail used by that updater. The records in the image trails are subsequently used
by updater processes to update the backup database.

Each receiver creates its own image trail files, preallocates extents, initiates rollovers, and manages
them, except for purging, a task performed by the purger process .

44 Introducing RDF

Sorted Image Trails

RDF maintains its image data on disk volumes specified during RDF configuration. On each of
these volumes, the collection of files that contains image data is known as an image trail; that
is, there is one image trail per individual image trail volume.

The standard image trail used by RDF, called the master image trail, contains the transaction
status records that hold key information about whether a transaction has committed or aborted.
The master image trail is stored on the disk volume specified by the master receiver’s
RDFVOLUME configuration option. You cannot configure any updaters to the master image
trail.

Secondary image trails primarily contain the audit records that log changes made to the user's
database on the primary system. Updaters read secondary image trails and apply the changes
recorded in the records to the database on the backup system. All updaters must be configured
to secondary image trails. You can configure up to 255 secondary image trails. Each secondary
image trail is stored on a separate volume, specified by the IMAGETRAIL configuration option.

RDF uses multiple sorted image trails. With this feature, the receiver detects which updaters are
associated with which image trails. When it receives a record, the receiver identifies the updater
that will apply the record to the backup database. The receiver then sorts the record into the
image trail used by the updater responsible for applying the record.

Figure 1-6 Receiver Process Operation

RDF Operations 45

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. This
approach is not recommended, however, if you require very high RDF performance or if RDF
is running with the UPDATE option turned off; in this case, the image trails could eventually
fill the volume; in such cases, it is best to have volumes exclusively dedicated to the image trails.

NOTE: You should keep all image trail files off of the $SYSTEM volume and its controller.

Otherwise, if there is a lot of audit data to send from the primary system to the backup system,
it could take a while for the updaters to start.

Image trails can be added only after RDF has been initialized but before it has been started.

RDF Control Points

When the extractor has no information to send from the audit trail, it transmits a buffer containing
no audit images (an empty buffer) to the receiver. When the receiver process receives an empty
buffer, it generates an RDF control-point record in each image trail. Therefore, even when no
TMF transactions are generated on the primary system, RDF adds internal control points to the
image trail on the backup system. The file-filling rate for RDF control point records is very slow.

A receiver determines which updater will apply each audit record, and sorts the data into the
image trail used by that updater. The records in the image trails are subsequently used by updater
processes to update the backup database. Each receiver creates its own image trail files,
preallocates extents, initiates rollovers, and manages them, except for purging, a task performed
by the purger process .

The receiver also adds RDF control points to individual image trails if they have not received
new audit while other trails have. Thus, the image trails can appear to be growing in size even
though no transaction activity is taking place on the primary system. The primary importance
of RDF Control Points is that they are used to reflect accurate RTD times for the updaters when
new audit has not been added to their image trails for any period of time. They are also useful
for the coordination of other special operations.

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.

Each updater reads the image trail to which it has been configured, looking for audit records
(image records) associated with the data volume it protects (it ignores audit records associated
with volumes protected by other updaters). When it finds applicable audit records, the updater
sends the audit records to the disk process to be applied to the backup database.

Each updater performs the following functions:

• Reads large blocks of data from the RDF image file and searches for image records associated

with the updater’s volume on the primary system.

• Opens and closes database files on the backup system for updating and maintaining the

backup database.

• Defines restart points and updates restart information in the context file (named CONTEXT).

For an explanation of restart points, see “Restart Information”.

• Sends information to RDFCOM for use in the STATUS RDF command display.

46 Introducing RDF

• Issues a logical REDO request to the disk process (during the normal forward pass over the

image trail) for each update associated with its volume.

• Issues logical UNDO requests to the disk process when backing out changes associated with

transactions that need to be undone during RDF takeover or stop-update-to-timestamp
operations.

• Bundles the REDO and UNDO requests into batch TMF transactions, the duration of which

is specified by the UPDATERTXTIME configuration parameter.

• For Enscribe files only, performs the following DDL operations:

CREATE, PURGE (ifREPLICATEPURGEis enabled), PURGEDATA, ALTER MAXEXTENTS
(used only for increasing MAXEXTENTS).

• For NonStop SQL files only, performs the following DDL operation: PURGEDATA

An updater cannot always respondimmediately to the STOP UPDATE andSTOP RDF commands.
If an updater has audit records queued for the disk process, the updater must wait until all of
that information is processed before it can shut down.

You specify the primary and backup CPUs for each updater. If the original backup process has
to take over because the primary CPU failed, this backup process runs by itself.When it determines
that the primary CPU has come back up, it creates a new backup process in that CPU. When it
has to take over, the original backup process becomes the primary process, and remains so even
after it creates a new backup process; that is, the updater does not switch back to the original
CPU configuration after the new backup process is created. If you stop the updaters by way of
a STOP RDFor STOPUPDATEcommand, however, when yourestart the updaters, youroriginal
configuration is once again used.

The updaters will shut down if any of the following occurs:

• You issue a STOP RDF or STOP UPDATE command on the primary system.

• You issue a STOP RDF command on the backup system when the communications lines

between the two systems are down.

• You issue a STOP TMF command on the primary system.

• The monitor detects the unexpected termination of any RDF process and sends out abort

RDF messages.

• You perform a NonStop SQL DDL operation on the primary system that includes the WITH

SHARED ACCESS option for an RDF-protected file. For more information, see “Performing

Shared Access DDL Operations” (page 152).

If you perform a NonStop DDL operation WITH SHARED ACCESS on a table or index that
is not configured for RDF protection by your current RDF subsystem, then this current RDF
subsystem does not shut down.

• A takeover operation completes on the RDF backup system.

Audited Database Files

All database files on the backup system are audited files.

Each updater maintains a file status table to keep track of the files it has open. An updater closes
any database file that has not been updated recently. Updaters also close database files when a
STOP RDF or STOP UPDATE command is issued, or when the updater restarts because of error
conditions. Additionally, if you alter the updater's OPENMODE while UPDATE is ON, then the
updater closes all its file and then reopens them with the new OPENMODE.

An updater process can have up to 3000 files open simultaneously. When it has the maximum
number of files open and needs to open another file, it first determines if there are any files that
have not been accessed recently and closes just them; if all of the open files have been accessed
recently, then the updater closes all of them before it continues processing. For the SMF
ramifications of this file limit, see the note in “Using SMF With RDF” (page 65).

RDF Operations 47

Each updater maintains a file status table to keep track of the files it has open. An updater closes
any database file that has not been updated recently. Updaters also close database files when a
STOP RDF or STOP UPDATE command is issued, or when the updater restarts because of error
conditions. Additionally, if you alter the updater's OPENMODE while UPDATE is ON, then the
updater closes all its file and then reopens them with the new OPENMODE.

An updater process can have up to 3000 files open simultaneously. When it has the maximum
number of files open and needs to open another file, it first determines if there are any files that
have not been accessed recently and closes just them; if all of the open files have been accessed
recently, then the updater closes all of them before it continues processing. For the SMF
ramifications of this file limit, see the note in“Using SMF With RDF” (page 65) .

REDO Pass

Updaters perform REDO operations during all normal processing. The updater applies each
audit record as a redo operation, regardless of whether the transaction associated with that audit
record committed, aborted, or is still in progress on the primary system.

The updaters apply all audit records to their data volumes regardless of whether the associated
transaction has committed, has aborted, or is still in progress. If a transaction commits, each
updater involved in the transaction applies allaudit associated with that transaction and associated
with its protected volume to its corresponding UpdateVolume on the backup system. If a
transaction aborts, the updater applies all application-generated audit followed by all TMF
Backout-generated audit - all with REDO operations. For those who are familiar with audit record
formats, updaters always apply the after-images when performing Redo operations.

UNDO Pass

Updaters perform an UNDO pass over the image trail during final processing of RDF takeover
and stop-update-to-time operations. This is because data already applied to the backup database
must be undone if the associated transaction(s) did not commit prior to the start of the takeover
operation or prior to the specified timestamp.

For takeover operations there are three phases of undo: local undo, file undo (if file-incompletes
from the primary system are still unresolved), and network undo (if you are operating in an RDF
network). For stop-update-to-time operations there is only local undo (file-incompletes cause
abend, and network undo is not supported).

If an updater encounters a multi-block operation on the primary system that aborted, then the
updater also enters a special UNDO pass while it searches for the start of the aborted multi-block
operation, and it undoes any audit associated with the aborted transaction in order to guarantee
all aspects of the aborted transaction are undone from the backup database.

For those familiar with audit record formats, the updater applies before-images when it performs
UNDO operations.

Restart Information

RDF has a CONTEXT file in which each updater process maintains a context record. A context
record specifies the position (referred to as the restart position) in the image trail where the
updater was at the last context save point. All data for the associated data volume in the backup
database prior to the specified restart position is safe on disk (has been applied to the backup
database).

If an updater detects a restartable error, it restarts. Upon being restarted, an updater reads its
context record and restarts processing in the image trail at the specified restart position.

Partitioned Files, Alternate Key Files, and Indexes

Each updater is responsible for applying audit data to partitions corresponding to the volume
on the primary system that updater is protecting. Updates are applied directly to the specific

48 Introducing RDF

partition, regardless of whether it is a primary or secondary partition. RDF does not use the file
system for partition mapping.

Furthermore, because updates to the backup database are applied by logical REDO/UNDO
operations, alternate key files and NonStop SQL indexes are not affected by an update to a file
or table. Alternate key files or NonStop SQL indexes are updated independently as a consequence
of the individual audit records generated on the primary system by TMF software.

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 partitionsare also configured for protection.

File System Errors Involving Data Files

File system errors can occur when:

• A file is created.

• A file is opened.

• A modify operation is performed on the file. Modify operations are those that the updater

might perform on an open file, such as updating the file (logical REDO/UNDO) or altering
the owner or security after the replication of a file creation.

Errors encountered are reported in the EMS event log.

If an updater process encounters a file-system error, it responds in either of the following ways
(depending upon the type of error that occurred):

• Restarts and retries the operation again by reprocessing all database updates since the last

restart point. If the updater takes this course of action, it continues to do so until the
underlying problem goes away. This would be the action, for example, if an updater process
cannot create a data file on a backup volume because that volume is protected by the
Safeguard security management subsystem; in this case, the updater logs error message 739,
with an error 48, and restarts.

• Skips the operation. This would be the action, for example, in response to an error 10 (“record

already exists”).

RTD Times

Write operations to the various sorted image trails occur asynchronously to one another. To
ensure correct operation, the updaters cannot read to the end-of-file. Instead, they can only read
as far as the receiver allows (determined by receiver “save” points in the image trail). Thus, on
a finely tuned RDF backup node, the RTD time (relative time delay) for an updater can typically
indicate that the updater is 1 to 15 seconds behind TMF processing on the primary system. This
15-second delay does not mean that 15 seconds are needed for the updater to catch up; catching
up typically requires less than a second. See the discussion on RTD Times in “RDF States”

(page 113)

Purger Process

The purger process is responsible for purging image trail files when they are no longer needed.

The purging of redundant image trail files is based on transaction information. Specifically, the
receiver process maintains general information on what transactions might be in each image file.
This information is system-wide, not specific to any particular image trail. The reasons for this
pertain to performance.

First, if the receiver had to maintain specific information about what transactions were actually
represented in each image file on each image trail, the extractor-receiver performance rate would
be seriously degraded. Therefore, the receiver keeps general information about all transactions
it has seen across all trails.

RDF Operations 49

Second, because considerable checking must be done across all trails to determine what files can
be purged based on what transactions might be represented in the various files on the various
image trails, the purger process performs this task.

The purger process is a restartable process pair that runs on the backup system (it is started
during START RDF and runs even when the updaters are stopped; image files are purged,
however, only when updating is enabled).

No image file in a given image trail can be purged until it is absolutely certain 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.

For example, assume the following:

• There are two image trails.

• Five updaters are assigned to each trail.

• A long-running transaction (T1000) involves all five updaters on one trail, but none on the

other.

• T1000 became active when the current image file in each trail was AA000002, and is still

active.

• The receiver is currently writing to image file AA000015 in both trails.

• All updaters are currently reading audit records from AA000015.

Although all the updater restart locations are in AA000015,none of the image files from AA000002
through AA000014 can be purged while T1000 is active or aborting because they will be required
if T1000 needs to be backed out during an RDF takeover or stop-update-to-timestamp operation.
This is true for both trails, even though none of the updaters on one trail have ever been involved
with T1000. If an UNDO pass becomes necessary, all updaters must perform that pass in search
of any audit records associated with T1000 (they must go back in each image trail to the point
where T1000 began: AA000002 in this example).

The purger process exists to avoid having the receiver keep track of all this information, which
could impact extractor-receiver throughput significantly. The purger process interacts with the
updaters to determine when image files can be purged.

Reciprocal and Chain Replication Require Mutually Exclusive Datavols

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).

50 Introducing RDF

Example 1-2 Chain Replication

System \A System \B System \C

RDF Subsystem 1

Primary DB 1 ---------> Backup DB 1

Primary DB 2 ----------> Backup DB 2

RDF Subsystem 2

Thus, system \B is both the backup system in RDF subsystem 1 and the primary system in RDF
subsystem 2.

Example 1-3 Invalid Chain Replication

System \A System \B System \C

RDF Subsystem 1

Primary DB 1 ---------> Backup DB 1

RDF Subsystem 2

Backup DB 1 ---------------> Another Backup DB 1

In Example 1-3 , RDF should not be configured to replicate RDF updater changes to another
backup system. You would not get an error in configuring this environment, but replication to
the database on \C would only consist of TMF Backout-generated audit on \B due to updater
transactions that aborted because RDF extractors filter out all updater-generated audit.

The updaters generate audit records as they replicate data to the target files and target tables,
and these auditrecords are internally marked as updater-generated audit records. The extractors
filter out all updater-generated audit. Thus, under normal circumstances, the extractors do not
send updater-generated audit to their backup systems for replication.

Consider the following example. Assume that Primary DB 1 and Backup DB 2 are both located
on $DATA on \A, and assume that Primary DB 2 and Backup DB 1 are also located on $DATA
on \B. Using the reciprocal example, suppose your application does an update on \A to Primary
DB 1 as in Example 1-1 “Reciprocal Replication”. The extractor of RDF Subsystem 1 sees that the
update was for $DATA and sends that update to \B where the updater applies that update to
Backup DB 1. This update generates an audit record that goes into the audit trail on \B and is
marked as updater-generated. The extractor for RDF Subsystem 2 reads the audit trail looking
for audit associated with $DATA. When it reads the record generated by the updater, it sees the
update was associated with $DATA, but it also sees that the record was updater-generated,
which causes the extractor to filter that record out and not send it to \A. This is correct and
desired behavior.

If an updater transaction aborts, the TMF Backout process executes undo for the aborted
transaction, and Backout has no information about what process generated the original audit for
the transaction before it aborted. This can corrupt your primary and backup databases unless
you take appropriate steps (see further below).

Consider the following extension to the example above. After the updater on \B has replicated
the application's update from \A and before the update can commit its transaction on \B, a CPU
failure causes TMF to abort the transaction. Backout undoes the updater's update. The resulting
audit record is associated with $DATA, but Backout does not know which process generated
the original update, and the resulting record is not marked as updater-generated. When the
extractor for RDF Subsystem 2 reads this record generated by Backout, it sees it was for $DATA
and it sees that the record was not updater generated. It therefore sends this record to \A. Now,

RDF Operations 51

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.

Although this example describes a reciprocal configuration, the same basic problem can happen
with chain replication. In the chain case, the extractor for RDF Subsystem 2 would be sending a
Backout generated update to \C where the file or table involved in the update does not even
exist. This will cause the updater responsible for $DATA on \C to stall, waiting for you to create
the file or table on \C.

The same effect occurs when you set up reciprocal environments or chain environments, where
you also have the REPLICATEPURGE attribute set. In this case, the updater purges the file
through the file system, and the resulting audit record does not indicate that it was generated
by an updater. If the extractor sends the audit record for the purge to its backup system, the
updater might purge a file you do not want purged, or it might encounter an error 11.

To prevent these problems in a reciprocal configuration or chain configuration, you must ensure
that Backup DB 1 and Primary DB 2 are on mutually exclusive volumes. For example, put Primary
DB 1 and Backup DB 1 is on $DATA1 and put Primary DB 2 and Backup DB 2 on $DATA2. Thus
the extractor can filter out the audit by volume name and not depend on records being marked
as updater generated.

Alternatively, if your two databases must share the same disks, then you must explicitly specify
which files andtables you want replicated by each RDF subsystem. For example, RDF Subsystem
1 would INCLUDE only Primary DB 1, and RDF Subsystem 2 would INCLUDE only Primary
DB 2.

Available Types of Replication to Multiple Backup Systems

RDF allows you to replicate database changes from a single primary system to multiple backup
systems. This makes possible simultaneous read-only access to all of the backup systems, a
capability particularly desirable for query-intensive applications where a central database can
be distributed to several remote systems for local query processing.

Replication to multiple backup systems is achieved by establishing multiple RDF configurations,
each protecting the same database on the primary system. As an example, you might want to
replicate the same data to different backup systems:

RDF Configuration #1
\A ---------> \B

RDF Configuration #2
\A ---------> \C

RDF Configuration #3
\A ---------> \D

You can also have two RDF configurations replicating two separate databases (DB1 and DB2)
from the same primary system to two different backup systems:

RDF Configuration #1, protecting database DB1
\A ---------> \B

RDF Configuration #2, protecting database DB2
\A ---------> \C

As a third possibility, youcan also have two RDFconfigurations replicating two separate databases
(DB1 and DB2) from the same primary system to the same backup system:

RDF Configuration #1, protecting database DB1
\A ---------> \B

RDF Configuration #2, protecting database DB2
\A ---------> \B

52 Introducing RDF

In the preceding examples, each RDF configuration operates entirely independently of the other
RDF configuration primaried on the same node; that is, each RDF system has its own extractor
and monitor process. In this way, Expand problems 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. If you include this parameter, the RDF control
subvolume on $SYSTEM will be the local (primary) system name without the backslash and with
the specified character appended to it. If you omit this parameter, the RDF control subvolume
on $SYSTEM will merely be the local system name without the backslash.

If you want to have several RDF susbsystems configured on the same primary node, the RDF
configuration for each RDF subsystem must have its own control subvolume and you must
specify the SUFFIX parameter when you initialize each subsystem. For example, if the name of
your primary node is \BOSTON, you could specify "1" as the SUFFIX when you configure the
first RDF subsystem, and its control subvolume will be BOSTON1. If you specify "2" as the SUFFIX
for your second RDF subsystem, then its control subvolume is BOSTON2. Both are located on
$SYSTEM, but each RDF subsystem has its own control subvolume.

For a description of the files in the control subvolumes on the primary backup systems, see “RDF

System Files” (page 362) .

Other RDF Features

Triple Contingency

If you are replicating your database to two backup systems and then lose your primary system,
you can perform an RDF takeover on both the backup systems upon loss of the primary system
and continue application processing on the new system within minutes. To proceed with full
RDF protection, however, you must:

1. Initiate a takeover on two of the backup systems.

2. Synchronize the two databases.

3. Configure the two systems as a primary-backup pair.

4. Initialize and start RDF on the system that you want to be the new primary system.

Depending upon the size of your database, the second step listed, database synchronization,
could take days to accomplish without the RDF triple contingency feature. Triple contingency,
however, streamlines this step, enabling you to achieve rapid database synchronization after a
takeover operation. Triple contingency allows your applications to resume, with full RDF
protection, within minutes after the loss of your primary system, provided that the two systems
are not too far behind.

The triple contingency feature builds upon the ability to replicate to multiple backup systems.
To use this feature, you establish two essentially identical RDF configurations:

RDF Configuration #1
\A ---------> \B

RDF Configuration #2
\A ---------> \C

To achieve Triple Contingency protection, see the various requirements that are outlined in detail
in Chapter 10 (page 271).

Loopback Configuration (Single System)

A loopback configuration is one where the primary and backup systems are the same system.
This configuration is of no use in a disaster protection plan, but can be useful for testing purposes.

Other RDF Features 53

One set of disks can be replicated to another set of target disks to provide a copy of the live
database. There are two operational considerations unique to this environment:

• The updaters operate in transaction mode, which means you should not stop TMF before

stopping RDF.

• The RDF takeover operation cannot be performed unless you manually stop the monitor

and extractor processes before issuing the TAKEOVER command or include the ! option in
the TAKEOVER command.

Online Product Initialization

You can initialize RDF/IMP, IMPX, or ZLT while your applications continue to run. This is
particularly useful for installing new versions of RDF into existing production environments
where you cannot afford to stop your applications even briefly to generate a TMF shutdown
timestamp. It is also useful if you encounter a problem for which you would like to reinitialize
RDF without stopping your applications.

For information about this capability, see:

• “Initializing RDF Without Stopping TMF (Using INITTIME Option)” (page 80)

• “Online Installation and Initialization Without Stopping RDF” (page 82)

• “INITIALIZE RDF” (page 212)

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 167).

Online Dumps of the Backup Database

With RDF/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. For information about taking dumps while the updaters are
running, see Chapter 5 (page 121).

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.

For information about subvolume-level and file-level replication, see Chapter 11 (page 279).

Shared Access DDL Operations

RDF includes two event messages (905 and 908) that assist you in the proper performance of
NonStop SQL/MP shared access DDL operations on the backup system. See “Performing Shared

Access DDL Operations” (page 152).

Configurable Software Location

By default, RDF software resides on $SYSTEM.RDF. You can, however, override this location
when you configure RDF. When you configure the general RDF attributes, use the SET RDF
SOFTWARELOC command. This can be useful if you have different releases of RDF on your
system.

54 Introducing RDF

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). They direct their
command, event, warning, and error messages to an EMS collector in the form of fully-tokenized
messages.

You can view messages in the EMS log online using Viewpoint or any other tool you normally
use for monitoring $0. When you do, so you are perusing the entire EMS log. You can, however,
use the standard EMS filter RDFFLTO to isolate RDF messages into an entry-sequenced file
which you then can examine using the RDFSCAN online utility.

SMF Support

RDF supports the use of the NonStop Storage Management Foundation (SMF) product on both
the primary and backup RDF systems. The database on the primary system can reside on SMF
virtual disks, as can the replicated database on the backup system.

All combinations of replication from physical disk to virtual disk, virtual disk to physical disk,
and virtual disk to virtual disk are supported.

There are some issues and restrictions that you should be aware of before using RDF in an SMF
environment; these are discussed in “Using SMF With RDF” (page 65).

RTD Warning Thresholds

RDF/IMPX and ZLT allow you to designate a pair of RTD warning thresholds: one for the
extractor, and another for all of the updaters. Having set those thresholds, you can issue an
RDFCOM STATUS RTDWARNING command with a designated repeat interval to display
information and statistics for only those processes (the extractor or any updater) that have fallen
behind the configured RTD threshold. For information about setting the RTD threshold, see “SET

RDF” (page 228) and “RDF States” (page 113) .

Process-Lockstep Operation

Process-lockstep operation, which is available with the RDF/IMPX and ZLT products, prevents
an application from executing further processing based on a committed business transaction
until all audit associated with that transaction is safely stored in the image trails on the backup
system.

This isaccomplished by means ofa new procedure, named DoLockstep, that you call immediately
after calling EndTransaction. With this lockstep protocol, the business transaction is actually
committed on the primary system prior to the start of the DoLockstep operation, but the
application is not allowed to continue processing until DoLockstep has returned status to the
application.

For information about this capability, see Chapter 15 (page 309).

Support for Network Transactions

The RDF/IMPX and ZLT products support network transactions: transactions that update data
residing on more than one RDF primary system.

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. Thus the distributed backup database is inconsistent
with regard to the affected network transaction.

Other RDF Features 55

For information about this capability, see Chapter 14 (page 295).

RDF and NonStop SQL/MX

RDF can replicate NonStop SQL/MX user tables and indexes as well as NonStop SQL/MP objects
and Enscribe files.

For information about this capability, see Chapter 16 (page 323).

Zero Lost Transactions (ZLT)

Zero Lost Transactions (ZLT), which is available only with the RDF/ZLT product, is a functional
capability that uses mirrored disks to guarantee that no committed transactions on the primary
system will be lost in the event of an RDF takeover by the backup system.

For information about this capability, see Chapter 17 (page 337).

Monitoring RDF Entities With ASAP

ASAP (Availability Statistics and Performance) allows many different 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 PC client.

RDF/IMP, IMPX, and ZLT are instrumented to feed state information to ASAP, thus allowing
RDF subsystemsto be monitored, in an integrated way, alongside all other subsystems supported
by ASAP. The following RDF entities report state and statistical information to ASAP:

• Monitor

• Extractor

• RDFNET (optional)

• Receiver

• Purger

• Updater

For information about using ASAP to monitor RDF entities, see Appendix E (page 465).

56 Introducing RDF

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. This information, intended for all readers, covers the following
tasks:

• “Configuring Hardware for RDF Operations” (page 57), including primary and backup

system configurations, disk volume considerations, and network requirements

• “Preparing Software and Database Files for RDF Operations” (page 59), including TMF and

RDF considerations, NonStop SQL database conventions, Enscribe database conventions,
and application design factors

• “Using SMF With RDF” (page 65)

Configuring Hardware for RDF Operations

The RDF hardware requirements are summarized in Table 2-1 and described in detail in the next
few pages.

Table 2-1 RDF Hardware Requirements

RequirementsHardware

RDF runs on NonStop systems under control of the
NonStop operating system. Each RDF primary system
must be connected through an Expand path to its RDF
backup system.

Primary and Backup Systems

The RDF product transmits data on any Expand data
communications lines.

Communications

Primary System Configuration

The RDF primary system must operate under control of the NonStop operating system, which
is the standard operating system for NonStop systems. This system must be connected over an
Expand data communication path to one or more RDF backup systems.

Backup System Configuration

The RDF backup system, like the primary system, must operate under control of the NonStop
operating system and be connected over an Expand path to one or more RDF primary systems.

In the event of a disaster at the primary site, an identical copy of the primary system’s hardware
configuration ensures that the backup system can support your business operations without
lowering system performance. If the backup system’s configuration is identical to that of the
primary system, your system personnel can adjust more quickly to the backup environment
during disaster recovery.

If you choose not to configure the backup system as an identical copy of the primary system,
plan the configuration of the backup system with enough processing power and disk drives to
enable RDF to keep the backup database current with the primary database.

Because RDF applies database modifications on the backup system through a private low-level
and privileged interface to the disk process, by-passing the file system, the CPU requirements
on the backup system when running RDF will typically be lower than the total CPU requirements
on the primary system running the applications. Repeated analysis has shown that the cost of
replication on the backup system is usually 25% or less than the cost on the primary system. The
actual backup CPU requirements depend on many factors, including the RDF configuration, the

Configuring Hardware for RDF Operations 57

rate of audit transmission from the primary system to the backup system, the database update
rate, and whether or not you have copies of your applications installed (in “standby” mode).

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.

Disk Volume Limit

The RDF/IMP, IMPX, and ZLT products can protect up to 255 physical or virtual volumes on
your primary system, and the updaters for these volumes replicate to either a single physical or
virtual disk on the backup system.

Volume-to-Volume Mapping

The recommended disk drive configuration for RDF products is a one-to-one mapping between
the primary volumes and their corresponding backup volumes, with mirrored disks on both
systems. This one-to-one mapping ensures that each partition of a partitioned file or table is
mapped appropriately to a backup volume.

Volume names on the backup system can differ from those on the primary system, but the use
of identical primary and backup volume names prevents naming conflicts after a takeover
operation. If the names of the backup volumes are different than those of the corresponding
primary volumes, you mustchange all volume references before the primary system’s applications
can start on the backup system.

Subvolume-to-Subvolume Name Mapping

RDF can replicate data from subvolumes on the primary system to same or differently named
subvolumes on the backup system. For more information, see Chapter 12 (page 285).

Expand (Data Communication) Resources

RDF sends filtered audit data from the primary system over the network to the backup system.
A communicationspath between the systems can be any form of Expand linkage. Plan to configure
sufficient communications resources between the primary and backup systems so that RDF can
do the following:

• Handle the peak rate of audit data

• Catch up processing in any audit trail if the communications paths go down and are restored

(without RDF reinitialization)

If you are using a dedicated Expand path with high throughput, you should set
PATHPACKETBYTES to 8192. If you are not using a dedicated Expand path, you should use
Multipacket frameswith PATHBLOCKBYTES set to 8192. See also “Specifying System Generation

Parameters for an RDF Environment” (page 63).

RDF is designed to extract audit records from the primary system and transmit it to the backup
system as quickly as possible. If you are not using the ZLT capability, this limits the number of
transactions that could be lost if a disaster should occur at the primary system. See Unplanned
Outages Without ZLT in Chapter 1 (page 31).

To estimate the data communications resources needed for RDF, calculate the amount of audit
trail data generated per second during peak loads. If your business has seasonal peaks, such as
holidays or the ends of calendar quarters, consider the peak rate at those times.

The discussion that follows pertains to the Master Audit Trail (MAT). If you are replicating
auxiliary audit trails, you should use the same algorithm for each auxiliary audit trail.

Use the following sampling process once an hour for two weeks to establish your needs:

58 Preparing the RDF Environment

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. If all the TMF audit data is generated on volumes protected by RDF, subtract the first EOF
value from thesecond EOF value to obtain the number of bytesgenerated during the 5-minute
period. Then divide the number of bytes by 300 seconds to determine the amount of audit
data generated in a second; for example:

(11653120-11292672)/300 = 1202 bytes per second

The extractor does not necessarily transmit all audit records associated with a particular
transaction. For example, audit records associated with physical operations is not transmitted.
The reason for this is that the backup database is maintained as a logically identical copy of the
primary database, not as a physically identical copy.

The data communications link should have at least two paths (multi-line Expand). Each path
should go through different communications carrier paths or switches, and each should be able
to transmit the peak data rate. It is often sufficient to have a single Expand path driven out of a
single processor, and the use of Expand-over-Servernet, Expand-over-IP, Expand with ATM, or
Expand with Fast Ethernet provides considerable bandwidth. For RDF environments where
multi-line Expand is absolutely required, see Chapter 13 (page 291).

It is almost impossible to calculate the RDF audit transmission rate from the TMF audit generation
rate alone.

HP has developed a sizing tool that can be used to predict accurately the Expand bandwidth
requirements between the primary and backup systems by simulating the RDF extractor. That
utility reads the TMF audit trails and generates detailed information about TMF audit generation
and RDF audit transmission activity. This information is particularly useful when a single system
supports multiple applications and RDF will only be configured to protect a subset of these
applications. This tool was designed and developed as part of the RDF Professional Service.

Contact your service provider for further details.

Preparing Software and Database Files for RDF Operations

The software requirements for the RDF/IMP, IMPX, and ZLT products appear in Table 2-2.

Preparing Software and Database Files for RDF Operations 59

Table 2-2 Software Requirements

RequirementSoftware

The RDF/IMP, IMPX, and ZLT products protect only files
on the primary system that are audited by the TMF
subsystem.

Files

The RDF/IMPXand ZLT products supportthe 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.

Auditing

The RDF/IMP, IMPX, and ZLT products use Expand
software to connect the primary system to the backup
system.

Communications

On theprimary and backup systems, the installed release
version update (RVU) of the operating system must be
supported.

Operating System

On both the primary and backup systems, the installed
RVU of the TMF subsystem must be compatible with the
installed RVU of the operating system.

TMF Subsystem

On both the primary and backup systems, the installed
RVU of the NonStop SQL product must be compatible
with the installed RVU of the operating system.

NonStop SQL Products

Configuring TMF for RDF Operations on the Primary System

TMF attempts to purge old audit trail files each time it rolls over to a new one. The purge is
performed only if the audit trail file is not pinned on behalf of RDF.

RDF automatically pins audit trail files. The only ways TMF can purge an old audit trail file that
is still required by RDF are:

• If you issue an RDFCOM UNPINAUDIT command while RDF is not running.

• If youstop TMF and restart it without restarting RDF. TMF does not retain pinning on behalf

of RDF when TMF is stopped and then restarted. If you must stop and restart TMF, be sure
to restart RDF before you restart your applications. This causes RDF to re-pin the audit trail
files it needs, and thereby prevents TMF from purging the files before RDF has finished
processing them.

If you issue an UNPINAUDIT command while audit dumping is disabled and TMF purges an
audit trail that has not yet been processed by RDF, you will have to reinitialize RDF and
resynchronize the databases. If you have configured TMF for audit dumping, however, you will
not need to reinitialize RDF or resynchronize the databases (the extractor will wait until the
needed audit trail is restored and then resumes).

AUDITTRAIL BUFFER

After you have configured your TMF audit trails, for each audit trail disk you should configure
the AUDITTRAILBUFFER ON and configure it with a reasonable value. You do this with the
SCF utility program. By default, AUDITTRAILBUFFER has a value of 128 megabytes, and this
may well be a reasonable value for you. By configuring AUDITTRAILBUFFER to at least 128
megabytes, you allow the extractor to read the audit trail files from disk cache rather than
physically from disk. Also, by setting the buffer to a high value, you allow the extractor reads
to continue to go to cache instead of to disk even when the extractor has fallen behind. Note, if
the extractor should fall way behind, for example the communications line to the backup system
fails, and if you have insufficient cache, then the extractor's reads will go to disk until it catches
up to what is in cache. The ability to read from cache is clearly a performance gain for optimal

60 Preparing the RDF Environment

extractor-to-receiver throughput. Please note that altering the value of AUDTITRAILBUFFER
can be done offline or online, but if you do it online your new value will not take effect until you
take the disk down and then bring it back up.

TMF Configuration With Dump Process on the Primary System

When you configure TMF with audit dump on, that subsystem dumps an audit trail file to tape
or disk before purging the audit trail file. 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. See also the description
of the UNPINAUDIT command in Chapter 8 (page 187).

You can control when TMF dumps an audit trail by configuring TMF for dump to tape. For
example, when configured with a tape dump process, TMF issues a prompt for the operator to
mount a tape when TMF is ready to dump and purge an old audit trail file. Because TMF cannot
execute the dump and purge of the audit trail file until a tape is mounted, the operator can wait
until the RDF extractor finishes that file before mounting the tape.

For more information on configuring TMF, see the TMF Planning and Configuration Guide.

TMF Configuration Without Dump Process on the Primary System

Long ago, the RDF product required that you configure TMF with a dump process that dumps
to tape. RDF no longer imposes this requirement for the following reasons:

• On the primary system, the RDF extractor explicitly pins the audit trail it is currently

processing, thereby preventing TMF from purging it. This explicit pinning remains in effect
even if the extractor process fails or RDF is shut down.

If you must unpin one or more audit trail files, you can do so by issuing an RDFCOM
UNPINAUDIT command. Later, when RDF is restarted, you can restore the necessary audit
trail files from tape.

• TMF includes the functional capability of audit overflow volumes. You should always

configure them with at least one overflow audit volume.

CAUTION: Although RDF no longer requires you to configure TMF with a dump process

that dumps to tape, you should nevertheless configure TMF for dumping to tape or disk if
you want to achieve full TMF protection for your primary database. In addition, if the RDF
extractor is running behind and you stop the TMF and RDF subsystems before RDF has
caught up to the TMF shutdown point, when you subsequently restart TMF, the TMP might
roll over the files before the RDF extractor can process them.

If you are required to do a takeover, it is recommended that you take online dumps of the backup
database before restarting the applications that will use it.

Configuring TMF for RDF Operations on the Backup System

As is indicated in Chapter 5 (page 121), you are strongly urged to configure TMF on your RDF
backup system with audit dumping and you are urged to take frequent online dumps of your
backup database. Performing both of these operations helps ensure fast switching of your
application from the primary to the backup system. Online dumps of your backup database can
also be used to recover a volume on the backup system from a complete media failure, but these
online dumps are not useful for any other type of TMF File Recovery operation on your backup
system (for example, Recover to First Purge). When you want to take an online dump of your
backup database, you must change the RDF UPDATEROPEN parameter from Protected (the
default value) to Shared. When the online dump has completed, you can set the RDF
UPDATEROPEN parameter back to Protected. Please note that if you take online dumps of your

Preparing Software and Database Files for RDF Operations 61

backup database, you must also take audit dumps too. For more information see, “SET RDF”
command in Chapter 8 (page 187).

Preparing Databases for RDF Protection

When preparing databases on the primary system for RDF protection, you must consider the
following system aspects:

• Maximum Number of Audited Files Per Volume on Primary System

• Copies of files for the backup database

• DSM catalog and file code 900 replication

• Copies of NonStop SQL views on the backup systems

• Placement of partitioned Enscribe files and NonStop SQL tables

Audited Files Per Volume on Primary System

The RDF updater process has a limit on the number of database files it can have open concurrently
on a volume - 3,000. Therefore, when you set up your database on your primary system for RDF
protection, you should ensure that you do not have more than 3,000 audited files on any single
volume that you want replicated. If you have more, then you should consider moving some of
these to a different volume. If you fail to do this, in some situations it can cause the updater to
slow down in performance. For more information, see Chapter 5 (page 121).

Audited Backup Database Files

The backup system must have copies of all files that RDF protects. For a successful takeover of
business operations in the event of a primary system failure, the backup system should also have
copies of all the files needed by the primary system applications (including alternate key files
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.

Chapter 3 (page 69) explains how to copy NonStop SQL/MP databases and Enscribe files to the

backup system after stopping both the TMF product and the applications that use that product
on the primary system. That is the time to copy any files the applications need to the backup
system so that the files are identical on both systems before RDF starts running.

Chapter 16 (page 323) explains how to copy NonStop SQL/MX databases to the backup system

after stopping both the TMF product and the applications that use that product on the primary
system.

Reload of Backup Database.

If you need to reload the backup database, you must change the RDF UPDATEROPEN parameter
from Protected (the default value) to Shared. When you are done with the reload, you should
then change the RDF UPDATEROPEN parameter back to Protected. Previously you needed to
stop the updaters before modifying this attribute, but you can now modify it online, without
stopping the updaters. For more information see, “SET RDF”command in Chapter 8 (page 187).

Disk Process Pins on Database Volumes

To ensure the fastest updater performance, you should configure as many disk process pins as
possible for the volumes on which your backup database resides. This is a particularly important
requirement if your primary system has really high audit generation rates and you want the
RDF updaters to keep up with that audit generation rate.

62 Preparing the RDF Environment

DSM Catalogs and File Code 900

All files that have the file code 900 are replicated by the RDF product. These consist of DSM Tape
Catalog files as well as some related files. In the case of files having the file code 900, RDF
replication of them to the RDF backup system can provide critical information if you later lose
the primary system to a disaster. However, if you also have a DSM Tape Catalog and related
files that specifically pertain to the backup system, you must be careful to place the replicated
files in a different location on the backup system. For example, suppose you have a DSM Tape
Catalog and related files on $CAT.DSMCAT on the primary system, and you have a different
DSM Tape Catalog and related files on $CAT.DSMCAT on the backup system that specifically
pertain to the backup system. In that case you must replicate the DSM Tape Catalog and related
files on the primary system to a different location than $CAT.DSMCAT on the backup system.
For example, you might want to replicate $CAT.DSMCAT.* on the primary system to
$DATA.DSMCAT.* on the backup system. In that way replication of the DSM Tape Catalog and
related files from the primary to the backup system does not affect the DSM Tape Catalog and
related files in $CAT.DSMCAT.* on the backup system.

Views on the Backup System

If an application uses any NonStop SQL shorthand or protection views on a volume protected
by RDF, audit data for transactions on the views refers only to the underlying tables and not to
the views. Views and their underlying base tables must be present on the backup system after
a takeover operation so that applications can continue without interruption.

All base tables underlying the views must also reside on volumes protected by RDF on the
primary system.

Partitioned Tables and Files

If any partition of a partitioned NonStop SQL table or Enscribe file exists on a volume protected
by RDF, then all partitions for that file should be on volumes 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.

Database Block Sizes and Cache on the Backup System

The block size of a file or table on your backup system must be identical to the corresponding
size of the file or table on the primary system. Failure to set proper block sizes on your backup
system can lead to unavoidable data corruption and failure. To ensure fastest RDF updater
performance configure as much cache for the block sizes of your database files as possible.

Specifying System Generation Parameters for an RDF Environment

When performing system generation:

• Use the PATHPACKETBYTES modifier to enable the Expand Variable Packetsize feature

so that Expand will send large packets.

• Use the CONGCTRL modifier to enable Expand congestion control.

• Use the AUDITTRAILBUFFER parameter to improve RDF extractor performance (set to the

highest value).

You might also want to enable the multipacket frame feature, depending upon the type of traffic
that will be passed over the Expand path.

For best results, consider using the RDF Professional Service to assist you in defining the Expand
requirements for your RDF environment. Contact your service provider for further details.

Preparing Software and Database Files for RDF Operations 63

Designing Transactions for RDF Protection

When designing applications containing transactions that update databases protected by RDF,
you must consider the following restrictions that apply to the subsystem:

• The effects of network (distributed) transactions after an RDF takeover operation

• Database operations not replicated by RDF

The sections that follow explain these restrictions.

Replicating Database Operations

Database administrators preparing to work with RDF should be aware of considerations
concerning:

• NonStop SQL Data Definition Language (DDL) operations

• NonStop SQL DDL operations with Shared Access

• Enscribe file-label modifications

• Purge operations

• Partitioned files

• Temporary disk files

NonStop SQL DDL Operations

Although RDF replicates NonStop SQL Data Manipulation Language (DML) operations, it does
not replicateNonStop SQL Data Definition Language (DDL) operations except for PURGEDATA.
Excluding PURGEDATA, the database administrator needs to perform all other DDL operations
(such as CREATE TABLE or CREATE INDEX) manually on the backup system as well as on the
primary system.

User programs should not create audited NonStop SQL tables and write to them without
coordinating table creation on the primary system with table creation on the backup system.

Recommended procedures for performing NonStop SQL DDL operations in an RDF environment
are described in “NonStop SQL/MP or NonStop SQL/MX Databases” (page 160).

Enscribe File-Label Modifications

In general, RDF does not replicate Enscribe file-label modifications.

File-label modifications in Enscribe are similar to DDL operations in NonStop SQL products, 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.

The only file-label modifications that RDF replicates are:

To create an audited Enscribe fileCREATE

To increase the number of extents for an audited Enscribe
file

ALTER MAXEXTENTS

To purge data from an audited Enscribe filePURGEDATA

To purge an Enscribe file (if REPLICATEPURGE is
enabled)

PURGE

Purge Operations

The two kinds of purge operations are PURGEDATA and PURGE. RDF replicates PURGEDATA
operations for NonStop SQL tables and Enscribe files. RDF replicates PURGE operations for
Enscribe files if REPLICATEPURGE is set on.

64 Preparing the RDF Environment

Partitioned Files

All partitions of a partitioned Enscribe file or NonStop SQL table or index must reside on volumes
protected by RDF, or none should. Corresponding partitions on each system must have the same
key values.

CAUTION: For partitioned files, it is essential that the partial key value for Enscribe files or

first key value for NonStop SQL tables on the backup system exactly match those on the primary
system. This is the RDF database administrator’s responsibility.

If you are using RDF to replicate the creation of partitioned files and an RDF takeover operation
occurs in the midst of a set of creations, some partitions might have been created while others
were not, because each partition of a partitioned file is created independently.

Temporary Disk Files

File creation, modification, and updates are not replicated for audited temporary disk files. All
audit data is filtered out by the extractor on the primary system for file names of the form
$volume.#nnnnnnn.

A filename that begins with # (pound sign) indicates a temporary disk file; this type of file name
is returned when only the volume name is specified in a call to the file-system CREATE procedure
or FILE_CREATE_ procedure.

Using SMF With RDF

RDF supports the full use of SMF on both the primary and backup nodes.

There are two basic ways to configure SMF logical volumes:

• Map many physical disks to a single virtual disk Create SMF pools where each is comprised

of many physical volumes and create SMFvirtual disks from these pools. In this configuration,
the files on any given virtual disk will be spread across multiple physical disks allowing
you to pool together many physical disks to create a very large virtual disk.

NOTE: A single updater process can only work on 3000 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 3000, 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 3000 files, the performance of the updater will be impacted.
For optimal updater performance, you should ensure that no single updater has to work on
more than 3000 files on a regular basis. This might mean that you have to reduce the number
of physical disks in a pool.

• Map many virtual disks to a single physical disk Create SMF pools where each is comprised

of a single physical disk and create SMF virtual disks from these pools. In this configuration,
all the files on a given virtual disk reside on one physical disk allowing you to have a very
large physical disk volume subdivided into a number of smaller logical volumes. In this
way it is possible to have multiple partitions of a file residing on a single physical volume,
with each partition of the file stored on a different logical volume.

Both of these configurations are supported by RDF. There are some restrictions when using SMF
on the backup system which are described in detail later in this chapter.

Using SMF With RDF 65

Configuring an SMF Environment on the Primary System

When configuring an SMF environment on an RDF primary system, make sure that SMF catalog
files are not replicated by RDF to the backup system. The SMF catalogs on the primary and
backup systems must remain independent of each other. There are three ways to do so:

• Place the SMF catalog on a primary system volume that is not protected by RDF.

The extractor ignores any audit generated by disks outside the RDF configuration, and hence
will not replicate any changes to the SMF catalog on the primary system. With this option,
you can store the catalog in either the default SMF catalog subvolume or your own
subvolume.

• Place the SMF catalog in the default SMF catalog subvolume on a volume that is protected

by RDF.

The extractor automatically filters out changes to the SMF catalog if the catalog is in the
default SMF catalog subvolume. If you store the catalog in your own subvolume, the extractor
will try to replicate changes to the catalog, which could have an adverse affect on RDF and
any SMF catalogs with the same subvolume name on the backup system.

• Place the SMF catalog in a subvolume that is explicitly excluded from RDF protection.

INCLUDE and EXCLUDE clauses are described in Chapter 11 (page 279).

Configuring an SMF Environment on the Backup RDF System

RDF supports the replication to SMF logical volumes on the backup system, with the following
restrictions:

• When replicating to an SMF logical volume, the logical volume must belong to an SMF pool

that contains 15 or fewer physical volumes, hence each updater can apply audit to up to 15
physical disks.

• The RDF/IMP product limits the total number of physical or virtual UPDATE volumes to

255. RDF/IMPX and ZLT have no such limitation, other than the limit of 255 updaters and
each updater only being able to work on a maximum of 15 physical volumes.

• Image trail volumes cannot reside on SMF logical volumes.

There are no restrictions on the placement of SMF catalog files on the backup system. If the
backup system could ever become a primary (such as after an RDF takeover, for example, or as
the result of a planned switchover), then the restrictions described in the preceding topic for
primary systems also apply.

NOTE: A single updater process only works on 3000 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 3000, 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
3000 files, the performance of the updater is impacted. For optimal updater performance, ensure
that no single updater must work on more than 3000 files on a regular basis. This condition might
mean that you have to reduce the number of physical disks in a pool.

RDF replicates Enscribe file creations when audited Enscribe files are created on RDF protected
volumes. When the UPDATEVOLUME is a virtual disk, the updater process tells SMF to create
the file and register it in the SMF catalog. When the UPDATEVOLUMEis a virtual disk consisting
of multiple physical disks, SMF decides which physical disk will store the file. You have no
control over where a new Enscribe file is created. For more information about the factors SMF
uses to decide on the file placement, see the Storage Management Foundation User's Guide .

You can change the physical volume on which files reside in the SMF pool using the FUP
RELOCATE command. This command only works on closed files, so the updaters must be
stopped before relocating any files.

66 Preparing the RDF Environment

SMF allows physical disks to be added and removed from pools. The RDF updaters must be
stopped prior to the addition or deletion of any physical disks from SMF pools on the backup
system.

Using SMF With RDF 67

68

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.

The procedures described in this chapter require that your business applications already be
operational on the primary system, all important database files already be protected by TMF,
the necessary Expand lines already exist between the primary and backup systems, and the
backup system includes all necessary disk volumes.

Installing and configuring RDF involves these steps:

• “Preparing the Primary System” (page 69)

• “Preparing the Backup System” (page 70)

• “Installing RDF” (page 75)

• “Initializing and Configuring TMF” (page 78)

• “Initializing and Configuring RDF” (page 79)

• “Enabling RDF Operations” (page 97)

Typically, this work involves using RDFCOM, TMFCOM (the interactive interface to TMF),
SQLCI (the NonStop SQL/MP interactive interface), MXCI (the NonStop SQL/MX interactive
interface), TACL (the interactive interface to the NonStop operating system), or FUP.

Preparing the Primary System

Before installing RDF, you must perform the following operations at the primary system:

1. If you are going to do offline initialization or offline database synchronization, stop the
necessary software in this order:

a. Stop all applications being protected by TMF.
b. Stop TMF.

NOTE: If you are going to use the DBSYNCHTIME parameter (for online database

synchronization) or the INITTIME parameter (for online initialization), you do not need
to stop your applications or TMF. For information about online database synchronization,
see Chapter 7 (page 167).

2. Prepare your NonStop SQL tables and Enscribe files for RDF protection:
a. Separate the tables to be protected by RDF from the tables not to be protected. (This

step is recommended but not required.)

b. Set audit compression (the AUDITCOMPRESS file attribute) ON for all tables and files

to be protected by RDF. Audit compression ON is the creation default for NonStop SQL
tables and indexes. Although not required by RDF, audit compression will enhance
RDF performance.

Stopping the Software

After you stop all applications protected by TMF, stop TMF itself by issuing a STOP TMF
command through the TMFCOM interactive interface. (You only need to stop your applications
and TMF if you are going to use the TIMESTAMP parameter of the INIT RDF command or if
you are going to omit the timestamp parameter in all forms). For information about issuing this
and other TMFCOM commands, see the HP NonStop TMF Reference Manual.

Preparing the Tables and Files

Now prepare your tables and files.

Preparing the Primary System 69

Separating NonStop SQL Tables

It is recommended that you avoid registering NonStop SQL 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. TMF compresses the audit data generated for NonStop SQL tables and Enscribe
files for which AUDITCOMPRESS is ON. For applications involving updates of only a few bytes
to large existing rows or records, this audit compression greatly reduces both the amount of
audit records the extractor must read and send to the receiver and the corresponding amount of
RDF traffic on the communications line.

For NonStop SQL tables and indexes, AUDITCOMPRESS is the default. If the value has been
changed to NO AUDITCOMPRESS for a table, you can use an ALTER TABLE command, entered
through the NonStop SQL conversational interface, to reset the default value:

ALTER TABLE table-name AUDITCOMPRESS;

For Enscribe files, the default for AUDITCOMPRESS is OFF. To turn off the AUDITCOMPRESS
attribute for an Enscribe file, use the File Utility Program (FUP) to enter an ALTER command:

FUP ALTER filename, AUDITCOMPRESS

Preparing the Backup System

Before starting RDF, you need to copy every database, program, and file that the primary system
applications use to the backup system so that the backup system can take over in the event of a
primary system failure. In the backup copies, you need to change any occurrences of the primary
system name to the backup system name. RDF replicates the database; you should use the
NonStop Autosync product to replicate everything else that is not audited, such as important
application files, objects, and scripts.

If the names of any volumes or devices that the applications might use on the backup system
are different from the names on the primary system, you must also change any references to
these volumes or devices.

It is strongly recommended that the backup system have one volume for every volume protected
by RDF on the primary system and that each backup volume have the same name as the
corresponding primary volume. If the backup volume names are not identical to the primary
volume names, then you need to update every backup partitioned file and every backup file that
has alternate keys so that each points to the right volume name. Also, if you replicate two or
more volumes on the primary system to a single volume on the backup system, the updaters
might fall behind under very high throughput due to the double workload on the underlying
disk process.

RDF requires that TMF be started on the backup system, the database on the backup system
resides on configured data volumes, the data volumes be physically up, and the files and tables
be audited.BEGINTRANS should be enabled. SMF disks should be audited. If replicating NonStop
SQL Format 2 audit data, be sure the backup system supports it.

For NonStop SQLdatabases, you must createcatalogs on the backup system and you need copies
of the following objects on the backup system:

• Catalogs in which base tables protected by RDF and objects dependent on those base tables

are registered, preferably with the same names as the primary system catalogs

• All base tables that reside on primary system volumes protected by RDF

• 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

70 Installing and Configuring RDF

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 it easy to compare catalogs on the primary and backup systems, it is strongly
recommended that you register objects protected by RDF in separate catalogs from objects not
protected by RDF. Either all the tables in a catalog should be protected or none of the tables
should be protected.

Every NonStop SQL object maintained on the backup system must be registered in a catalog,
even if the object is not protected by RDF.

Synchronizing the Primary and Backup Databases

For databases to be synchronized in an RDF environment, the database on the backup system
must be logically identical to the database on the primary system. There are two ways to
synchronize your databases: offline and online. This topic covers offline database synchronization.
For a description of online database synchronization, see Chapter 7 (page 167).

To ensure consistency between the primary and backup databases, you should copy the primary
database to the backup system before RDF updating starts. The most effective way to synchronize
the databases follows:

1. Stop TMF auditing onthe primary system by turning off the applications and stopping TMF.

2. Create a copy of the primary database on the backup system.

The tools for synchronizing databases on NonStop systems are:

• The TACL OBEY command enables you to create the same database structures on the primary

system and the backup system by using commands in an EDIT file to create reusable TACL
macros and routines.

• The SQLCI or MXCI CREATE CATALOG command can re-create NonStop SQL/MP or

NonStop SQL/MX catalogs on the backup system.

• The SQLCI or MXCI DUP utility can copy NonStop SQL/MP or NonStop SQL/MX objects

and Enscribe files from one system to another.

• The BACKUP and RESTORE utilities can copy NonStop SQL/MP or NonStop SQL/MX

objects and Enscribe files to and from tape.

• The FUP DUP command can copy Enscribe files from one system to another.

• The NonStop Autosync product can replicate all application programs and files other than

your RDF database.

Backing up partitioned files requires some extra planning, as explained in “Synchronizing

Partitioned Files” (page 74).

For a complete discussion of synchronized versus unsynchronized databases and their
ramifications, see “Understanding Database States” (page 157).

Re-Creating an Empty Database With an OBEY Command

If a database on the primary system does not contain any data yet, use either an OBEY command
file or a TACL macro to re-create the database on the backup system.

To create logically identical database structures on the primary and backup systems, first do the
following at the primary system:

1. Place the database creation commands in either an EDIT (command) file or TACL macro
or routine. See the TACL Reference Manual for more information.

2. Through the TACL command interpreter, issue an OBEY filename command or run the
macro to create the primary database.

Preparing the Backup System 71

3. Copy the command file or TACL macro to the backup system.

Now do the following on the backup system:

• Change any system references in thecommand file or TACL macro from the primary system

name to the backup system name. If the volume names are different or if you want a different
database layout on the backup system, change volume references as well.

• Through the TACL command interpreter, issue an OBEY filename command or run the

macro to create the backup database.

Synchronizing Databases With SQLCI Commands

This topic only applies to NonStop SQL/MP databases. For instructions on how to synchronize
NonStop SQL/MX databases, see Chapter 16 (page 323).

You can use SQLCI commands to synchronize NonStop SQL/MP databases online. For NonStop
SQL/MP databases, you create the catalog or catalogs on the backup system and then duplicate
the objects registered in each catalog.

For complete information about using SQLCI to copy databases, see the information on moving
databases in the SQL/MP Installation and Management Guide. For the syntax of SQLCI commands,
see the SQLCI online help or the SQL/MP Reference Manual.

The following example shows how you can create a partitioned NonStop SQL/MP table with an
alternate index on the primary system with the SQLCI CREATE command, and then duplicate
this table on the backup system by using the SQLCI DUP command. In this example, \PRIM is
the primary system and \BACK is the backup system.

Notice that the catalog for this NonStop SQL/MP table is created on the backup system before
starting RDF on the primary system so that RDFwill recognize the backup catalog and not report
errors when attempting to process audit data for this catalog.

1. Using SQLCI, enter a CREATE command to create the catalog on the backup system. TMF
must be up for NonStop SQL/MP catalog updating:

CREATE CATALOG \BACK.$DATA1.DBCAT;

2. Set up DEFINEs on the primary system to simplify referring to NonStop SQL/MP tables in
subsequent SQLCI commands for the primary system:

SET DEFMODE ON;
ADD DEFINE =EMPLOYEE, CLASS MAP,
FILE \PRIM.$DATA1.DB.EMPLOYEE;
ADD DEFINE =EMPLPAR2, CLASS MAP,
FILE \PRIM.$DATA2.DB.EMPLOYEE;
ADD DEFINE =EMPLNAME, CLASS MAP,
FILE \PRIM.$DATA2.DB.EMPLNAME;

3. Create the catalog on your primary system and make this the default catalog for all partitions:

CREATE CATALOG \PRIM.$TEST.DBCAT;
CATALOG \PRIM.$TEST.DBCAT;

4. Enter a CREATE TABLE command to create the partitioned table:

CREATE TABLE =EMPLOYEE (
EMPNUM DECIMAL (5) UNSIGNED NO DEFAULT,
FIRST_NAME CHARACTER(15) NO DEFAULT,
LAST_NAME CHARACTER(20) NO DEFAULT,
PRIMARY KEY EMPNUM )
ORGANIZATION KEY SEQUENCED
PARTITION ( =EMPLPAR2 FIRST KEY 3000 );

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:

72 Installing and Configuring RDF

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. Enter commands to specify the data to be inserted into the table on the primary system:

INSERT INTO =EMPLOYEE ( EMPNUM, FIRST_NAME, LAST_NAME )
VALUES ( 826, "Evans", "Joan" );

INSERT INTO =EMPLOYEE ( EMPNUM, FIRST_NAME, LAST_NAME )
VALUES ( 3351, "MacArthur", "Bill" );

INSERT INTO =EMPLOYEE ( EMPNUM, FIRST_NAME, LAST_NAME )
VALUES ( 10809, "Gember", "Tom" );

Now direct your attention to the backup system (\BACK). As you perform the necessary
tasks on this system, note these considerations:

• DEFINEs cannot be used if you specify MAP NAMES parameter in the DUP command.

• The DUP operation moves the entire database, including all partitions and indexes, by

default.

• The catalog \BACK.$DATA1.DBCAT is used for all partitions and all indexes.

8. Specify the catalog for the backup system:

CATALOG \BACK.$DATA1.DBCAT;

9. Use the SQLCI DUP command to copy the primary system’s database to the backup system:

DUP ( *.*.* FROM CATALOG \PRIM.$TEST.DBCAT ),
MAP NAMES ( \PRIM.$DATA1.*.* TO \BACK.$DATA1.*.* ,
\PRIM.$DATA2.*.* TO \BACK.$DATA2.*.* )
SAVEALL ON;

10. After using the SQLCI DUP command, perform a TMF online dump on the primary system
to create a recovery point.

Synchronizing Databases With BACKUP and RESTORE Utilities

You can use the BACKUP and RESTORE utilities to synchronize NonStop SQL/MP, NonStop
SQL/MX, orEnscribe databases by copyinga database to tape on the primary system and restoring
the database from tape on the backup system. This method is preferable when you want a backup
tape of the primary system database, or when the database is large.

The following example of BACKUP and RESTORE commands shows how to copy a NonStop
SQL/MP database from the primary system \PRIM to the magnetic tape device named $TAPE
and how to restore the database to volumes of the same name on the backup system \BACK.
You must include the AUDITED parameter in both the BACKUP and RESTORE commands.

1. Back up the database from \PRIM onto tape:

BACKUP $TAPE, (*.*.* FROM CATALOG \PRIM.$TEST.DBCAT),
AUDITED, INDEXES IMPLICIT, LISTALL

2. Restore the database from tape onto \BACK (assuming the catalog was already created):

RESTORE $TAPE, *.*.*, AUDITED,
MAP NAMES ( \PRIM.$DATA1.*.* TO \BACK.$DATA1.*.* ,
\PRIM.$DATA2.*.* TO \BACK.$DATA2.*.* ),
CATALOG \BACK.$DATA1.DBCAT, INDEXES IMPLICIT,
SQLCOMPILE OFF, LISTALL

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

Preparing the Backup System 73

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.*.*), AUDITED

Synchronizing Databases With FUP

You can use the FUP DUP command to copy Enscribe database files from the primary system
to the backup system. If you use FUP DUP, the “FUP ALTER filename , NO AUDIT” command
is performed implicitly for each backup file that corresponds to a primary file protected by RDF.
You will therefore need to turn the audit flags back on for all the data volumes on the backup
system after the FUP DUP operation is complete.

NOTE: For this copy operation to work correctly, do not specify the SAVEALL parameter in

the FUP DUP command.

Synchronizing Partitioned Files

When synchronizing partitionedfiles, you mustconsider onemajor difference between NonStop
SQL/MP tables and Enscribe files: a NonStop SQL/MP catalog has a description of all indexes of
a table and partitions of a partitioned table, but a partitioned Enscribe file has no associated
catalog.

To ensure the consistency of a NonStop SQL/MP catalog, you must copy all partitions of a
NonStop SQL/MP table and its dependent indexes at one time rather than on a partition basis.
You can use either the SQLCI DUP command or the BACKUP and RESTORE utilities to copy
the partitions.

For an Enscribe file, you can use the FUP DUP command or the BACKUP and RESTORE utilities
to copy the individual indexes and partitions. Then use FUP ALTER to incorporate the other
partitions and any alternate indexes into the primary partition.

If the volume names for partitions on the backup system are different from the volume names
on the primary system, you need to change the volume references for those partitions.

Backing Up Application Programs and Files

To enable the backup system to take over in the event of a primary system failure, you need to
put usable copies of all program files, OBEY command files, and other files your applications
use on the backup system. You can do this by using the NonStop Autosync product. After copying
these files, you might need to change names to reflect the backup system’s naming conventions,
and you might need to recompile some programs.

The following practices are recommended:

• SQL compile all NonStop SQL/MP programs after moving them to the backup system. A

static recompilation reduces the applications’ startup costs after an RDF takeover operation.

Alternatively, you can use the late binding feature. To do this, the SIMILARITY CHECK
attribute for all referenced tables and protection views must be enabled and the program
compiled with the CHECK INOPERABLE PLANS parameter.

• Use DEFINEs for all NonStop SQL/MP objectswhere possible; this simplifies the commands

for your OBEYcommand files and the commands for yourNonStop SQL/MP DDL operations.

Cache for RDF IMAGETRAILS and UPDATER UPDATEVOLUMES

When you have determined the volumes you wish to use for Imagetrails and Updatevolumes,
you should configure several thousand 4k blocks of cache for each volume. This will considerably
increase the performance of the receiver and updaters.

74 Installing and Configuring RDF

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/IMP (T0346) Product Components

The release CD includes these components for the RDF/IMP product:

Documentation for RDFCHEK (an EDIT file)CHEKDOC

The RDF audit-fixup object code fileRDFAFXO

An RDF file comparison utilityRDFCHEK

An RDF file comparison utilityMD5CHEK

The server component of MD5CHEKMD5SRVO

The RDF command interface object code fileRDFCOM

The RDFCOM HELP file (an EDIT file)RDFHELP

The RDF extractor object code fileRDFEXTO

The RDFINST TACL macro (an EDIT file)RDFINST

The RDF monitor object code fileRDFMONO

The RDFNET object code fileRDFNETO

The RDF receiver object code fileRDFRCVO

The RDF purger object code fileRDFPRGO

The RDFSCAN object code fileRDFSCAN

The RDFSCAN HELP file (an EDIT file)RDFSCANH

The RDFSNOOP object code fileRDFSNOOP

The RDF updater object code fileRDFUPDO

A diagnostic tool for analysts that reads undo lists and dumps data into
entry-sequenced files

READLIST

A diagnostic tool for HP analystsRDIMAGE

The software documentation file (an EDIT file)

T0346ann

A filter to use with EMSDIST to isolate RDF messagesRDFFLTO

Information about the release CD itselfREADME

Information about component licensingLICENSE

RDF/IMPX (T0347) Product Components

The release CD includes these components for the RDF/IMPX product:

All of the T0346 product components plus the RDF/IMPX enabler moduleRDF/IMPX

The software documentation fileReadme

Installing RDF 75

RDF/ZLT (T0618) Product Components

The release CD includes the following components for the RDF/ZLT product:

The RDF/ZLT enabler moduleRDF/ZLT

The software documentation fileReadme

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.

Process-Lockstep Gateway (T1226) Product Components

The release CD includes the following files associated with the process-lockstep capability:

Sample code for invoking the DoLockstep procedure from a COBOL 85 program.SLOCKCOB

RDF lockstep gateway object code.LSGO

DoLockstep procedure object code.LSLIBTO

Forward declarations of the DoLockstep procedure call.FDOLOCK

The process-lockstep capability is available only with the RDF/IMPX and ZLT products. For
information about this capability, see Chapter 15 (page 309).

Component Licensing

Some of the files on the CD must be licensed before they can be run.

One of the advantages of using the RDFINST macro is that it automatically licenses those programs
that need to be licensed.

RDFINST licenses these programs:

• RDFAFXO

• RDFCOM

• RDFEXTO

• RDFMONO

• RDFPRGO

• RDFRCVO

• RDFSNOOP

• RDFUPDO

• RDIMAGE

Security Guidelines

The information that follows will help you establish appropriate NonStop operating system and
Safeguard security for your RDF environment. Table 3-1 identifies the special security-related
attributes for each type of program in an RDF environment.

Table 3-1 RDF Process and Program Security Attributes

LICENSE Required for Object File?Run Under a Specific Logon ?Program Name

YESYES ++RDFAFXO

NONORDFCHEK

NONOMD5CHEK

NONOMD5SRVO

YES

YES; 255,nnn +

RDFCOM

76 Installing and Configuring RDF

Table 3-1 RDF Process and Program Security Attributes (continued)

LICENSE Required for Object File?Run Under a Specific Logon ?Program Name

YESYES ++RDFEXTO

YESYES ++RDFMONO

NOYES ++RDFNETO

YESYES ++RDFPRGO

YESYES ++RDFRCVO

NONO++++RDFSCAN

YESYES +++RDFSNOOP

YESYES ++RDFUPDO

NONOREADLIST

YESYES ++RDIMAGE

+ RDFCOM operational commands require super-user group access; however, INFO and STATUS commands can
be issued by all users.
++ The RDF processes run under the userid of the user who set the PROGID attribute, or the RDF OWNER.

+++ RDFSNOOP requires super-user group access to read image files.

++++ Depends upon security of entry-sequenced file being accessed.

The followingsummarizes the reasons forthe various security requirements of each RDF program:

• RDFAFXO. The RDFAFXO process uses privileged TMF procedures to fix the audit trail

files and reset the CRASHOPEN flag in the audit trail file label and must be licensed with
FUP or by running the RDFINST macro. RDFAFXO can be owned by any user ID.

• RDFCOM. The RDFCOM program communicates with the TMP in privileged mode and

must be licensed with FUP or by running the RDFINST macro. RDFCOM can be owned by
any user ID; however, it must be run by a member of the super-user group (user ID 255,nnn)
to change the running state of RDF.

Alternatively, RDFCOM supports the use of the SAFEGUARD PROGID attribute to enable
any user to start, stop, and manage RDF. Once the PROGID attribute is set, you must limit
EXECUTE access to the RDFCOM object so that only those persons authorized to manage
RDF can run RDFCOM.

• RDFEXTO. The RDF extractor program communicates with the TMP in privileged mode

and must be licensed with FUP or by running the RDFINST macro. RDFEXTO can be owned
by any user ID.

• RDFMONO. The RDF monitor program communicates with the TMP in privileged mode

and must be licensed with FUP or by running the RDFINST macro. RDFMONO can be
owned by any user ID.

• RDFNETO. The RDFNETO program opens and writes to the network synchronization file

on each of the primary systems participating in the RDF network. RDFNETO can be owned
by any user ID.

• RDFPRGO. The RDF purger program purges image files in privileged mode and must be

licensed with FUP or by running the RDFINST macro. RDFPRGO can be owned by any user
ID.

• RDFRCVO. The RDF receiver program opens the image files in privileged mode and must

be licensed with FUP or by running the RDFINST macro. RDFRCVO can be owned by any
user ID.

• RDFSCAN. The RDFSCAN program contains no privileged calls or privileged code and

need not be licensed. RDFSCAN can be owned and run by any user ID.

Installing RDF 77

• RDFSNOOP. The RDFSNOOP program opens the image files in privileged mode and must

be licensed with FUP or by running the RDFINST macro. RDFSNOOP can be owned by any
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. The RDIMAGE program opens the image files in privileged mode and must

be licensed with FUP or by running the RDFINST macro. RDIMAGE can be owned by any
user ID. RDIMAGE must be run by a member of the super-user group (user ID 255,nnn) to
read the image files.

Using the OWNER Attribute to Allow Super Group Users to Start, Stop, and Manage
RDF

By setting the OWNER global configuration parameter in a SET RDF configuration command,
you are specifying the primary owner of your RDF environment (such as SUPER.RDF, for
example). Doing so enables other super group userids to start, stop, and manage RDF.

Once the OWNER attribute is set, you must use SAFEGUARD to limit EXECUTE access to the
RDFCOM object so that only those super group users authorized to manage RDF can run
RDFCOM. Failure to do so is a serious security risk because, thereafter, all RDF objects run as
the userid of the RDF OWNER.

Initializing and Configuring TMF

After copying the appropriate files from the primary system to the backup system, you must
ensure that TMF is configured on both systems to support RDF operations. The actions you take
to do this depend on whether or not TMF was running previously on this system.

TMF Subsystem Not Running Previously

If TMF was not running previously on the primary system, after you have installed TMF you
should take the following steps:

1. Include the following commands in the TMF configuration OBEY command file:

START TMF, DISABLE BEGINTRANS
DISABLE AUDITDUMP MAT

Although not required by RDF, it is recommended that you start TMF with transaction
processing turned off, and then turn it on after the RDF subsystem is started. Doing so
assures you that RDF is fully operational before transaction processing begins.

The DISABLE AUDITDUMP command ensures that TMF does not purge any audit trail
files before RDF extracts all pertinent data from them.

2. Initiate a TMFCOM session and then execute the TMF configuration OBEY command file.

NOTE: You should not restart the applications until RDF has been installed, initialized,

started, and transaction processing in the primary system has been turned on (by issuing a
TMFCOM ENABLE BEGINTRANS command).

If TMF was not running previously on the backup system, after you have installed TMF you
must use TMFCOM to issue a START TMF command and one or more ADD DATAVOLS
commands to add to the TMF configuration all disk volumes to be used by the RDF updater
processes.

78 Installing and Configuring RDF

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.

Initializing RDF

To initialize RDF, you issue an INITIALIZE RDF command at theprimary system. When executed,
this command:

• Establishes new configuration and context files for the new RDF configuration (that resides

in the control subvolume)

• Identifies the backup system in the configuration

• Establishes a starting location in the audit trail where each configured extractor commences

reading audit.

The INITIALIZE RDF command also establishes the name of the RDF control subvolume, which
you must subsequently specify when initiating RDFCOM sessions. If you enter this command
for an RDF configuration that already exists, you must explicitly purge the configuration files
and context files from the control subvolumes on both the primary and backup systems; otherwise,
an error messagewill appear. This requirement helps ensure that you do notaccidentally destroy
the wrong RDF configuration in cases where multiple RDF configurations exist for replication
to multiple backup systems.

NOTE: Previously you were required to purge the RDF control subvolumes on the primary

and backup systems before you could run the RDFCOM Initialize RDF command (see details on
RDF control subvolume in Chapter 4 (page 99)). You can now specify a special option that
automatically purges the existing control subvolume on the primary and backup system as part
of the RDFinitialization command.For complete information on INITIALIZE RDF, see Chapter 8

(page 187).

If you are going to replicate database changes to multiple backup systems, you must also specify
a one-character control subvolume suffix in the INITIALIZE RDF command for individual
configurations. If you specify a suffix character, the control subvolume name is the name of the
primary system without the backslash and with the suffix character appended to it. If you omit
the suffix character, the control subvolume name is the name of the primary system without the
backslash and without a suffix character.

As a general rule, you can only issue the INITIALIZE RDF command if all of the following
conditions exist:

• TMF is initialized.

• RDF is not running.

• You are logged on under TACL as a member of the super-user group.

• You have a remote password from the primary system to the backup system. (It is

recommended, but not required, that you have a remote password from the backup system
to the primary system as well.)

For complete information about the INITIALIZE RDF command, see the description of the
INITIALIZE RDF command in Chapter 8 (page 187).

Initializing and Configuring RDF 79

Initializing RDF To a TMF Shutdown Timestamp

If TMF was running previously on the primary system and did not need to be initialized and
configured, you can initialize RDF to a timestamp that reflects the time of the last TMF shutdown.
This initialization is typically used when one stops TMF in order to initialize RDF to that TMF
stop location. This might be useful if you are about to use RDF for the first time and you stop
TMF in order to synchronize your backup database to your primary database. After you have
synchronized the databases and initialized RDF, you can start TMF, start RDF, and start your
applications with an assurance that no audit will be skipped when RDF commences replication
operations.

To issue the INITIALIZE RDF command without first initiating an RDFCOM session, enter the
command in the following format in response to the TACLprompt. In the TIMESTAMP parameter,
be certain to specify the exact time (to the minute) that TMF was last shut down. You determine
the appropriate timestamp by examining previous TMF messages in the EMS log. In this example,
the TIMESTAMP parameter specifies 1:32 p.m., January 7, 1999:

>RDFCOM;INITIALIZE RDF, BACKUPSYSTEM \CHICAGO,
SUFFIX A, TIMESTAMP 7JAN1999 13:32

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.

Initializing RDF Without any Timestamp Option

If you have just installed (or deleted and reinstalled) TMF so that it starts at relative byte address
(rba) 0 in audit trail file sequence number 1, you should now issue an INITIALIZE RDF command
without the TIMESTAMP parameter at the TACL prompt on the primary system:

>RDFCOM; INITIALIZE RDF, BACKUPSYSTEM \BOSTON, SUFFIX A

When you begin an RDFCOM session on a system in which RDF has never been previously
initialized (such as \PRIMSYS, for example), RDFCOM responds with the following prompt:

***Warning*** The control subvolume PRIMSYS is not presently
***Warning*** configured for an RDF primary system.

You must use the OPEN command to open an RDF CONFIG file in an
existing RDF control subvolume, or you must initialize a new RDF
configuration with the INITIALIZE RDF command.

To continue with the session, you must either enter an INITIALIZE RDF command, or use the
OPEN command as directed in Chapter 8 (page 187).

Initializing RDF Without Stopping TMF (Using INITTIME Option)

The INITIALIZE RDF command includes a parameter, INITTIME inittime , that you can use
to initialize the RDF product without stopping TMF or your applications.

There are two cases where you would typically use this capability:

• If you want to install a new version of the RDF product and you cannot afford to stop TMF

even momentarily to get a TMF shutdown timestamp.

• If you are running RDF and encounter a problem for which you would like to reinitialize

RDF without having to resynchronize your databases.

80 Installing and Configuring RDF

Determining a Valid inittime Value

When using the INITTIME parameter without the NOW clause, it is important that you specify
a valid inittime value.

To do so, first issue a STATUS RDF command and take note of the highest updater RTD time.
Then round that RTD time up to the next higher minute (0:43 becomes 1:00, 1:27 becomes 2:00,
3:04 becomes 4:00, and so forth). Finally, subtract that rounded-up time from the current system
time shown in the status display.

inittime := (current-system-time — rounded-highest-updater-RTD-time)

RDFCOM then subtracts an additional three minutes from the specified timestamp. This is to
ensure that the extractor’s starting position is at a point in the MAT where RDF had previously
sent audit records to the backup system and the updaters had applied it to the backup database.
This practice guarantees that no audit record is lost during initialization.

When you includethe INITTIME parameter in the INITIALIZERDF command, RDFCOM initiates
a backward scan of the MAT searching for the first commit or abort record whose timestamp is
less than the specified inittime . When RDF is subsequently restarted, some of the auditrecords
will be reapplied to the backup database. This does not cause any inconsistencies between the
primary and backup databases, but rather ensures that they stay completely synchronized with
one another.

CAUTION: The NOW clause of the INITTIME parameter causes RDF to be initialized at the

current date and time. The NOW value should only be used in a situation where you have
configured a reverse trigger and the INITIALIZERDF command is used for reversing the direction
of RDF. For more information see “Example” (page 236).

Special Considerations

When using this form of the INITIALIZE RDF command with a timestamp specified with
INITTIME, there are three special cases that you might encounter.

Enscribe Create Records

If the previous version of RDF performed an Enscribe create operation on the backup system
prior to execution of the INITIALIZE RDF command and the extractor’s restart position in the
audit trail precedes the location of the Enscribe create record that an updater previously applied,
then, when you restart RDF and the updater tries to apply the create record, it will report a File
System error 10 (File Already Exists) and you must purge the existing file. The updater will
continue to report the error until you have purged the file.

Stop-RDF-Updater Records

Stop-RDF-Updater records in the master audit trail (MAT) are associated with committed NonStop
SQL DDL operations performed on the primary system with the SHARED ACCESS parameter.
Although such operations can be performed on the primary system without stopping your
applications, they must be performed manually on the backup system after all updaters have
shut down in response to the same Stop-RDF-Updater record.

As a general rule, you should not initialize RDF to an inittime if you recently performed a
NonStop SQL/MP or NonStop SQL/MX operation with SHARED ACCESSon the primary system.
For example, suppose you have a NonStop SQL/MP or NonStop SQL/MX table (tableA) that
contains the range of keys A through Z and you just moved its partition boundary such that
tableA now contains only the keys A through M and a new table (tableB) contains the keys N
through Z. Suppose also that you performed this operation manually on the backup system.

If you then initialize RDF to a point in the MAT prior to the Stop-RDF-Updater record associated
with the partition boundary change and an updater encounters audit records associated a key
N through Z, the updater will report an error because it will try to apply the audit record to

Initializing and Configuring RDF 81

tableA (which used to contain it, but now does not), and the audit record will not be applied
to the backup database. In this particular case, the database is not corrupted, but data corruption
could happen for other NonStop SQL/MP or NonStop SQL/MX DDL SHARED ACCESS
operations.

If you did recently perform a NonStop SQL/MP or NonStop SQL/MX operation with SHARED
ACCESS on the primary system and you want to initialize RDF to a inittime , you should wait
before issuing the command until you can specify an inittime that includes the three minutes
added by RDFCOM so that the starting position in the MAT is after the Stop-RDF-Updater record.

As a precaution, if RDFCOM encounters a Stop-RDF-Updater record during its backward search
of the MAT, it issues a warning message asking if you want to proceed with initialization. If you
continue the operation, the updaters will shut down when they encounter the Stop-RDF-Updater
record, at which time you should try to perform the NonStop SQL/MP DDL operation manually
again on the backup system.

TMF Shutdown Records

TMF shutdown records in the MAT do not cause a problem, except that if RDF is initialized to
a point in the MAT prior to a TMF shutdown record, then once you have started RDF it will
shutdown as soon as it reaches that TMF Shutdown record. All you need to do then is restart
RDF.

Online Installation and Initialization Without Stopping RDF

For the procedure described in “Initializing RDF Without Stopping TMF (Using INITTIME

Option)” (page 80), you are required to stop RDF, delete the control subvolumes, reinitialize

RDF, and then restart RDF. Although unlikely, stopping RDF does leave you briefly vulnerable
to inconsistent data on the 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. For your current RDF subsystem (RDF04->RDF06), issue an RDFCOM STATUS RDF
command on the primary system.

2. Notice the general timestamp and the RTD times (11AUG2008 05:26).

RDFCOM - T0346H09 – 11AUG08
C)2008 Hewlett-Packard Development Company, L.P.

Status of \RDF04 -> \RDF06 RDF 2008/08/11 05:26:49.082
Control Subvol: $SYSTEM.RDF04
Current State : Normal
RDF Process Name RTD Time Pri Volume Seqnce Rel Byte Addr Cpus Err

------------------ ------ --------- --- -------- ------ ------------- ----- ---­Monitor $RMON 185 $AUDMAT 56 1: 2
Extractor (0) $REXT0 0:00 185 $AUDMAT 56 928000 1: 2
Receiver (0) $RRCV0 0:00 185 $MIT 12 1: 2
Imagetrail (0) $IMAGE0 3822
Imagetrail (0) $IMAGE1 793
Imagetrail (0) $IMAGE2 1790
Imagetrail (0) $IMAGE3 998
Purger $RPRG 185 1: 2
$DATA10 -> $DATA10 $RUPD1 1:26 185 $IMAGE0 3821 1926445 1: 2
$DATA11 -> $DATA11 $RUPD2 0:02 185 $IMAGE1 793 811008 2: 3
$DATA12 -> $DATA13 $RUPD3 0:05 185 $IMAGE2 1790 1568 3: 0
$DATA13 -> $DATA14 $RUPD3 0:10 185 $IMAGE3 998 3 3587 3: 0
]

3. If the extractor RTD is greater than 0:00, wait until the extractor reports this value. If the
value is 0:00, take the highest updater RTD and round up to the next minute. In this example,
the highest updater RTD rounded up to the next minute is 2:00.

82 Installing and Configuring RDF

4. Subtract this value from the general timestamp (11AUG2008 05:24).

5. Issue the STOP UPDATE command. This command stops the updaters but allows the
extractor and receiver to continue to shipping and storing audit, respectively.

6. Install the new RDF software in a different volume.subvolume from that housing the current
version of RDF that is running. For example, if you are upgrading to T0346ABS, you might
specify $system.rdfabs.

7. Run $system.rdfabs.RDFCOM and initialize a new RDF configuration, using:

• The suffix parameter (such as suffix "a")

• The INITTIME parameter, using the timestamp calculated in the preceding example

(11AUG2008 05:24).

Initialize RDF, backupsystem \RDF06, suffix a, inittime 11AUG2008 05:24

8. If you do not already have a copy of the configuration script used for the current version of
RDF, you can get it by starting the RDFCOM for that RDF subsystem and using the INFO
*, OBEYFORM command.

9. Use the same script to configure your new RDF subsystem, but you will need to change the
following:

a. Set SOFTWARELOC to $system.rdfaav
b. Set the extractor name(s) to a different name(s)
c. Set the monitor name to a different name
d. Set the receiver name(s) to different name(s)

10. Now start your new RDF subsystem:

] run $system.rdfaav.rdfcom rdf04a
] start RDF, update off

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. Purge the previous control subvolumes on the primary and backup, as well as the

imagetrails for the previous subsystem.

You have now installed and started new RDF software without jeopardizing disaster-recovery
protection by having to stop RDF.

Disaster Points

If the primary system fails between steps 1 and 10, you perform the takeover operation using
your previous RDF subsystem. If the primary system fails at or after step 11, you perform the
takeover operation using the new subsystem (RDF04A).

Considerations

This method does not work with long-running transactions. You must not have any long-running
transactions in the system when you start Step 1, above. If you have long-running transactions,
you must stop them and wait until they clear the TMF subsystem before you start Step 1.

If you are runningwith RDF process lockstep, you should change the RDF gateway startup script
to reference the new extractor name before executing Step 11. Then stop the gateway manually.
This action will restart the gateway, and the gateway will access the new extractor.

Initializing and Configuring RDF 83

For RDFnetwork environments, you should subtract an additional15 minutes from the timestamp
you calculated in Step 4.

Configuring RDF

For RDF to operate correctly, you must establish values for the following sets of attributes in the
RDF configuration file:

• Global attributes that apply across RDF

• Attributes that apply to image trails

• Attributes that apply to triggers

• Network configuration record attributes

• Process attributes that apply to the individual RDFNET, monitor, extractor, receiver, purger,

and updater processes

In addition to the configuration file on disk, RDFCOM maintains a copy in memory. To configure
RDF, first use RDFCOM SET commands to establish the values you want in the configuration
memory table, and then use ADD command to apply those values to the configuration file. You
do this for each process individually; do all of the SETs for a process, and then add the particular
object. Notice that the only purpose of the configuration memory table is to serve as a temporary
repository of configuration attributes for the SET command.

Initially, some of the configuration attributes in the memory table are set to their default values.
You use SET commands only for those attributes that you want to change from the default value.

Before issuing the ADD command, you can verify the current attributes in the memory table by
issuing SHOW commands.

After issuing the ADD commands (but before starting RDF), you can change some attribute
values in the configuration file by issuing ALTER commands.

84 Installing and Configuring RDF

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.
After you have configured RDF, you can easily create a command file from the existing
configuration file as explained in “Creating a Configuration Command File” (page 96). You can
then use that command file whenever you need to reconfigure RDF. See Appendix B (page 359)
for a sample configuration file.

Setting Global Attributes

The SET RDF command establishes values for global attributes that apply either to the entire
RDF system or to all updater processes. These attributes and their default values are:

$0• LOGFILE

10 (seconds)• UPDATERDELAY

60 (seconds)• UPDATERTXTIME

60 (seconds)• UPDATERRTDWARNING

PROTECTED• UPDATEROPEN

$SYSTEM.RDF• SOFTWARELOC

OFF• NETWORK

OFF• NETWORKMASTER

ON• UPDATEREXCEPTION

volume undefined• LOCKSTEPVOL

OFF• REPLICATEPURGE

OFF• REMOTE MIRROR

system undefined• REMOTE STANDBY

(no default)• OWNER

LOGFILE Attribute

The LOGFILE attribute specifies the name of the EMS collector to which all RDF command,
event, error, and warning messages are to be directed.

The following commands specify the EMS collector $CTD25 as the RDF log file on both the
primary and backup systems:

]SET RDF LOGFILE $CTD25
]ADD RDF

The collector on the primary system receives log messages from the extractor and monitor
processes (plus RDFCOM messages that are logged in message 835).

The collector on the backup system receives log messages from the receiver, purger, and all
updater processes (plus RDFCOM messages that are logged in message 835).

UPDATERDELAY Attribute

The UPDATERDELAY attribute specifies how many seconds (from 1 to 10) the updater processes
should delay upon reaching the logical EOF in the image trail before checking to see if logical
EOF has advanced. The default is 10 seconds.

This attribute 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.

Initializing and Configuring RDF 85

UPDATERTXTIME Attribute

The UPDATERTXTIME attribute 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.

The default value is recommended for RDF environments with heavy updater activity (aggregate
updater throughput greater than 300 kb/second). Raising the tx-time in such environments
might adversely affect TMF performance on the backup system.

In RDF environments with low to moderate updater activity and where no other transaction
activity is occurring on the backup system, you could raise the tx-time without affecting TMF
performance on the backup system.

The goal of the UPDATERTXTIME is to allow each updater to do as much work as possible in
a single transaction, but not so much work that it would take a long time to undo the transaction,
if that transaction should abort. For this reason the default value of 60 seconds is generally an
optimal value.

UPDATERRTDWARNING Attribute

The UPDATERRTDWARNING attribute specifies the RTD warning threshold (in seconds, 0 or
greater) for all configured updaters. The default is 60 seconds.

This threshold is used by the STATUS RTDWARNING command to determine which updaters,
if any, are to be included in its display. The display includes the monitor process and only those
RDF processes (extractor or updaters) whose RTD exceeds their configured RTD warning
threshold.

UPDATEROPEN Attribute

The UPDATEROPEN attribute specifies the access mode (PROTECTED, PROTECTED OPEN,
or SHARED) that updaters use when opening database files. The default is PROTECTED.

PROTECTED mode is strongly recommended at all times to protect your backup database from
improper write activity by processes other than an RDF updater. PROTECTED mode also allows
user applications to open backup database files for read access but not for write access while the
updater process has the file open. PROTECTED mode, however, is incompatible with taking
online dumps and RELOAD operations. Therefore, if you want to perform one of these two
operations, you need to change UPDATEROPEN from PROTECTED to SHARED. When you
have finished the operation, you should set UPDATEROPEN back to PROTECTED. Previously
you had to stop the updaters before you could change the UPDATEROPEN mode. You can now
do this online, without stopping the updaters.

PROTECTED OPEN is a special variation of PROTECTED. If you have PROTECTED set, it is
possible for the updater to close a file if that file has had no update activity for five or more
minutes. If a rogue user application then opens the file for write access, it is able to write to the
backup database files. If the updater then wants to apply audit from the primary system to that
file, the updater will encounter an error 2 on its REDO operations, and the file will no longer be
in synchronization with the corresponding file on the primary system. The PROTECTED OPEN
mode means that once the updater has opened the file, it will not close the file even if it encounters
a period of idle activity against the file.

SOFTWARELOC Attribute

The SOFTWARELOC attribute specifies where the RDF software is installed on both the primary
and backup systems. The default is $SYSTEM.RDF.

86 Installing and Configuring RDF

NETWORK Attribute

The NETWORK attribute specifies whether or not you are configuring an RDF network.

When set to OFF (the default value), an RDF takeover operation provides local database
consistency, but it cannot provide transaction consistency for network transactions that involved
several RDF backup databases.

When set to ON, the RDF subsystem provides database consistency for network transactions
that were replicated to other backup databases by other RDF subsystems.

When set to ON, you must either have the NETWORKMASTER attribute for the same system
also set to ON or have another system configured as the network master.

NETWORKMASTER Attribute

The NETWORKMASTER attribute specifies whether the particular system is the master of the
RDF network.

When set to OFF (the default value), the particular system is not the network master.

When set to ON, the particular system is the network master of the RDF network and this RDF
system coordinates takeover operations across all the RDF subsystems that make up the RDF
network. When this attribute is set to ON, the NETWORK attribute must also be set to ON.

UPDATEREXCEPTION Attribute

The UPDATEREXCEPTION attribute 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 Attribute

The LOCKSTEPVOL attribute specifies the primary system disk volume on which the RDF
lockstep file (control-subvolume.ZRDFLKSP) is to be located. The specified volume must be
configured to the Master Audit Trail (MAT), and either the entire volume or at least the lockstep
file must be protected by the RDF subsystem. For information about the RDF lockstep capability,
see Chapter 15 (page 309).

REPLICATEPURGE Attribute

The REPLICATEPURGE attribute specifies whether Enscribe purge operations on the primary
system are to be replicated on the backup system.

When set to OFF (the default value), Enscribe purge operations are not replicated. You should
use the default (OFF) for all RDF configurations unless you have a specific need for replicating
Enscribe purge operations.

If you configure the RDF subsystem to replicate network transactions, you should not replicate
Enscribe purge operations because doing so might result in unexpected errors during the updater
network undo processing.

When set to ON, all Enscribe operations on RDF-replicated files are replicated on the backup
system. Ifyou want specific Enscribe files purged, thenyou must also configure INCLUDEPURGE
and/or EXCLUDEPURGE clauses for each affected updater (see “Updater Processes”).

REMOTE MIRROR Attribute

The REMOTE MIRROR attribute specifies whether ZLT is enabled or disabled. The default is
off. For information about the ZLT capability, see Chapter 17 (page 337).

Initializing and Configuring RDF 87

REMOTE STANDBY Attribute

The REMOTE STANDBY attribute specifies the system name of the ZLT standby system.
node-name must be a valid name and must identify a system in your current Expand network.
The default is the name of the backup system. For information about the ZLT capability, see

Chapter 17 (page 337).

OWNER Attribute

The OWNER attribute specifies a userid under which all RDF processes will always run. This
global configuration parameter providesfunctionality whereby any super-user group userid can
start and stop RDF.

To illustrate this functionality, imagine ten users are responsible for managing a particular RDF
configuration and that SUPER.RDF is configured as the OWNER. Instead of providing all ten
users access to the SUPER.RDF userid, each individual user can be assigned a separate super-user
group userid. If one user is assigned SUPER.FIRST and another SUPER.SECOND, for example,
they can both log on with their userid and be able to start or stop RDF. The RDF processes do
not run under SUPER.FIRST or SUPER.SECOND, however, but under SUPER.RDF (the RDF
OWNER assigned during configuration). The same principal applies to the other eight users.

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).

If the OWNER attribute is omitted, only the userid that initializes RDF can start or stop RDF (as
is true for all versions of RDF prior to 1.7).

Setting Image Trail Attributes

Use SET IMAGETRAIL and ADD IMAGETRAIL commands to configure the following image
trail attribute:

• ATINDEX

The ATINDEX attribute associates an image trail with a specific audit trail on the primary system.

The RECEIVER RDFVOLUME attribute specifies the disk volume that contains the receiver’s
master image trail. The receiver process writes all commit/abort records to this volume. All
updaters must be configured to secondary image trails.

To create secondary image trails, use the ADD IMAGETRAIL command. Later, when you
configure your individual updater processes, you assign each of these processes to a specific
image trail. By spreading updaters across secondary image trails, you reduce the number of
updaters contending for a specific trail. ATINDEX specifies which receiver will write to thattrail;
0 is the default.

Each secondary image trail contains the audit records needed by the associated updater processes.
Image trail files in secondary image trails have the same extent sizes as image trail files on the
volume specified by RDFVOLUME.

88 Installing and Configuring RDF

NOTE: To have secondary image trails, you must add them after initialization and before RDF

has been started for the first time. Also you cannot add secondary image trails until you have
configured the receiver, as described in the previous paragraphs. The secondary image trail files
have the same extents as the master image trail files. To delete a secondary image trail, you must
stop RDF, delete any updaters associated with the particular trail, and then delete the trail.
Normally, you should never delete a secondary image trail until RDF has completely caught up
with TMF.

To add one secondary image trail to the volume named $IMAGA1 and another to the volume
named $IMAGA2, issue the following commands:

]SET IMAGETRAIL ATINDEX 0
]ADD IMAGETRAIL $IMAGA1
]SET IMAGETRAIL ATINDEX 1
]ADD IMAGETRAIL $IMAGA2

Dedicated Image Trails or Image Trails on UpdateVolumes

The master image trail (MIT) should always be placed on an image trail not used by any updaters.
For secondary image trails, however, you have two options. If your peak time audit generation
rates for RDF-protected data on a given audit trail are generally in the range of 1 to 3 megabytes
of audit per second, the number of updaters you need does not exceed 30, and you normally run
with Update ON, you may be able to configure one image trail per updater and place that
imagetrail on that updater's UPDATEVOLUME. You should have sufficient disk space to hold
both your database files as well as the image trail. When determining if you have sufficient disk
space on the UPDATEVOLUME, you should consider size of individual image trail files and the
configured value of the purger's RETAINCOUNT, and you should consider worst-case situations
where an updater might fall way behind, in which case there might be a large number of image
files on that UPDATEVOLUME.

Alternatively, you may find that you can configure a small number of dedicated image trails
and configure a large number of updaters to each dedicated trail provided that the volume of
audit being written to the trail is generally less than 5 megabytes per second. For high volume
throughput where the volume of RDF-protected data in an audit trail exceeds 5 megabytes per
second, for optimal extractor-to-receiver throughput as well as for optimal updater throughput,
it is recommended that you always use dedicated image trails and that you configure no more
than 3 or 4 updaters per image trail.

As you can see from this discussion, there are many combinations one can achieve, depending
on the volume of audit being generated per datavol on the primary system and the number of
updaters you configure to an image trail. The recommendations provided above are no more
than general recommendations. Each customer's environment differs. When you are ready to
configure your image trails, you need to consider carefully the different considerations raised
above.

Setting Trigger Attributes

RDF offers two typesof triggers, where a trigger istypically a user-generated script of operations
that are automatically executed upon the completion of a specificevent. Thetwo typesof triggers
are the REVERSE trigger and the TAKEOVER trigger. The REVERSE trigger is executed by RDF
only for a STOP RDF, REVERSE operation, and it is executed immediately after RDF stops. The
TAKEOVER trigger is executed immediately upon the successful completion of an RDF takeover
operation.

Use SET TRIGGER and ADD TRIGGER commands to configure the following trigger attributes:

• PROGRAM

• INFILE

• OUTFILE

Initializing and Configuring RDF 89

• CPUS

• PRIORITY

• WAIT or NOWAIT

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 attribute 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 attribute specifies the name of a file or process that will be passed as the OUT file
to the trigger process when it is created.

The CPUS attribute specifies the number of the primary and alternate CPUs in which the trigger
process is to run.

The PRIORITY attribute specifies the priority at which the trigger process will run.

WAIT causes RDF to wait for the trigger process to terminate before shutting down. NOWAIT
specifies that once the trigger process is launched, RDF can immediately proceed to shut down.

For further details on how you might use these triggers, see the sections on switchover and
takeover in Chapter 6 (page 157).

Setting Network Configuration Record Attributes

Use SET NETWORK and ADD NETWORK commands to configure the following network
configuration record attributes:

• PRIMARYSYSTEM system-name

• BACKUPSYSTEM system-name

• REMOTECONTROLSUBVOL subvolume-name

• PNETTXVOLUME volume-name

If you are configuring the network master RDF subsystem, you must include a network
configuration recordfor every RDF subsystem in the RDF network (including the network master
itself). Each of those records must include the following parameters:

Name of the primary system.

PRIMARYSYSTEM system-name

Name of the associated backup system.

BACKUPSYSTEM system-name

Name of the primary system’s remote control subvolume.

REMOTECONTROLSUBVOL subvolume-name

Name of the primary system volume on which the RDF
subsystem stores an audited network synchronization file.

PNETTXVOLUME volume-name

If you are configuring a non network master RDF subsystem, you must include a single network
configuration record containing the following attributes:

Name of the network master’s primary system.

PRIMARYSYSTEM system-name

Name of the network master’s backup system.

BACKUPSYSTEM system-name

Name of the network master’s remote control
subvolume.

REMOTECONTROLSUBVOL subvolume-name

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 Attribute

The PRIMARYSYSTEM attribute specifies the name of a primary system. There is no default
value. Each primary system within an RDF network must be unique within the network. An

90 Installing and Configuring RDF

RDF network cannot contain two or more RDF subsystems with the same primary system (that
is, it cannot contain RDF subsystems for \A to \B and \A to \C).

BACKUPSYSTEM Attribute

The BACKUPSYSTEM attribute specifies the name of the backup system associated with the
specified primary system. There is no default value.

REMOTECONTROLSUBVOL Attribute

The REMOTECONTROLSUBVOL attribute 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 Attribute

The PNETTXVOLUME attribute specifies the name of the volume on the particular primary
system where the RDF network master stores an audited network-synchronization file. The
specified volume must be a data volume protected by the RDF subsystem on the primary system
and be configured to the MAT.

You only use this attribute when configuring the network master. On the master you must include
this parameter within every network configuration record (including the one for the master
itself).

Setting Individual Process Attributes

Having set the global attributes, you are now ready to set the parameters that apply to individual
RDF processes: the RDFNET, monitor, extractor, receiver, purger, and updater processes.

RDFNET Process

Use SET RDFNET and ADD RDFNET commands to configure the following RDFNET attributes:

• CPUS primary-CPU : backup-CPU

• PRIORITY

• PROCESS

The CPUS attribute specifies the processors in the primary system in which the RDFNET process
will run.

The PRIORITY attribute specifies the priority at which the RDFNET process will run. You should
set the RDFNET process’ priority slightly lower than that of the RDF monitor process.

The PROCESSattribute supplies a name forthe RDFNET process. You should specifya meaningful
mnemonic such as $RNET. The process name can be any unique valid process name up to six
characters, including the $ symbol. However, you cannot specify HP reserved process names
that are of the form $X*, $Y*, or $Z*, in which * is any alphanumeric string.

Monitor Process

Use SET MONITOR and ADD MONITOR commands to configure the following monitor
parameters:

• CPUS primary-CPU : backup-CPU

• PRIORITY

• PROCESS

The CPUS attribute in the following form specifies the primary and backup processors in which
the monitor will run:

CPUS primary-CPU:backup-CPU

If the primary processor is not available when RDF is started, the monitor executes in the specified
backup processor without benefit of a backup process. When the primary processor is brought

Initializing and Configuring RDF 91

back online, the monitor creates its own backup process in the primary processor and then
switches control to that monitor process.

The PRIORITY attribute specifies the priority at which the monitor will run. You should set the
monitor’s priority higher than that of any application’s process.

The PROCESSattribute supplies a name for the monitor process. You should specify a meaningful
mnemonic such as $AMON or $MON1. The process name can be any unique valid process name
up to six 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.

To configure an RDF monitor process named $MON1 to execute as a process pair in CPUs 4 and
6 of the primary system at a priority of 186, issue the following commands:

]SET MONITOR PROCESS $MON1
]SET MONITOR CPUS 4:6
]SET MONITOR PRIORITY 186
]ADD MONITOR

You can issue ADD MONITOR commands only when RDF is stopped.

Extractor Process

Use SET EXTRACTOR and ADD EXTRACTOR commands to configure the following extractor
parameters:

• ATINDEX

• CPUS primary-CPU : backup-CPU

• PRIORITY

• PROCESS

• RTDWARNING

• VOLUME

The ATINDEX attribute specifies an integer value from 0 through 15 specifying the TMF audit
trail on the primary system with which the extractor is associated. 0 specifies the MAT. 1 through
15 specify auxiliary audit trails AUX01 through AUX15. The default is 0. If you omit this attribute,
RDFCOM assumes the extractor is associated with the MAT. For information about protecting
auxiliary audit trails, see Chapter 13 (page 291).

The CPUS attribute specifies the processors in the primary system in which the extractor will
run.

The PRIORITY attribute specifies the priority at which the extractor will run. You should set the
extractor’s priority slightly lower than that of the RDF monitor process.

The PROCESSattribute supplies a name for the extractor process. You should specify a meaningful
mnemonic such as $EXT. The process name can be any unique valid process name up to six
characters, including the $ symbol. However, you cannot specify HP reserved process names
that are of the form $X*, $Y*, or $Z*, in which * is any alphanumeric string.

The RTDWARNING attribute specifies the RTD warning threshold (in seconds, 0 or greater) for
the extractor. This threshold is used by the STATUS RTDWARNING command to determine if
the extractor is to be included in its display. The display includes the monitor process and only
those RDF processes (extractor or updaters) whose RTD exceeds their configured RTD warning
threshold.

The VOLUME attribute specifies a valid volume name in the current TMF configuration on your
primary system. When configuring RDF for ZLT, you must add the complete set of audit trail
volumes to whichprotected data volumes are configured. You use a SET EXTRACTOR VOLUME
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. For
information about the ZLT capability, see Chapter 17 (page 337).

92 Installing and Configuring RDF

To configure an RDF extractor process named $EXT to run as a process pair in CPUs 5 and 3 of
the primary system, at a priority of 185, with an RTD warning threshold of 360 seconds, issue
the following commands:

]SET EXTRACTOR ATINDEX 0
]SET EXTRACTOR PROCESS $EXT
]SET EXTRACTOR CPUS 5:3
]SET EXTRACTOR PRIORITY 185
]SET EXTRACTOR RTDWARNING 60
]ADD EXTRACTOR

You can issue ADD EXTRACTOR commands only when RDF is stopped.

Receiver Process

Use SETRECEIVER and ADD RECEIVER commands to configure the following receiver attributes:

• ATINDEX

• CPUS primary-CPU : backup-CPU

• PRIORITY

• PROCESS

• RDFVOLUME

• EXTENTS

• FASTUPDATEMODE

The ATINDEX attribute specifies 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. The default is 0. For each configured extractor, there must be a corresponding
receiver with the same ATINDEX value. For information about protecting auxiliary audit trails,
see Chapter 13 (page 291).

The CPUS attribute specifies the processors in the backup system in which the receiver is to run.

The PRIORITY attribute specifies the priority at which the receiver will run. You should set the
receiver’s priority higher than that of any application’s process and higher than that of any RDF
updater process.

The PROCESS attribute supplies a name for the receiver process. You should specify a meaningful
mnemonic such as $RECV. The process name can be any unique valid process name up to 5
characters, including the $ symbol. However, you cannot specify HP reserved process names
that are of the form $X*, $Y*, or $Z*, in which * is any alphanumeric string.

The RDFVOLUME attribute applies only to the master receiver. It specifies which volume on
the backup system will contain the receiver’s master image trail. The file naming convention for
image trail files is $volume.control-subvolume.AAnnnnnn, where n is a digit. For example,
the first image file is named $volume.control-subvolume.AA000001. You cannot specify the
subvolume name because that name is controlled by RDF.

The EXTENTS attribute only applies to the master receiver. It specifies the size of the primary
and secondary extents for all image trail files on all image trails.

The FASTUPDATEMODE value controls the frequency with which the receiver writes to the
image trails and makes image trail data available to the updaters. With FASTUPDATEMODE
OFF, the receiver buffers the audit sent by the extractor and writes those buffers out to the image
trails at the most convenient time. This ensures that RDF can achieve the highest possible
extractor-to-receiver throughput, but it does delay the updaters in how quickly they are allowed
to read and apply the audit to the backup database. One can typically observe updater RTD
times in the range of 1-20 seconds, although it may only take an updater a fraction of one second
to apply 20 seconds worth audit.

With FASTUPDATEMODE ON, as a receiver receives an extractor message, it buffers all the
audit sent in that message by the extractor, writes those buffers immediately to the image trails,
and then makes that data immediately available to the updaters. Depending on the value of the

Initializing and Configuring RDF 93

UPDATERDELAY attribute in the global RDF configuration record, the updaters can then read
the image trails and apply the freshly written audit to the backup database immediately, thereby
keeping updater RTD times to the lowest possible value. Because the receiver writes the audit
immediately to the image trails after processing each extractor message, having
FASTUPDATEMODE set ON can impact extractor-to-receiver throughput.

For a complete discussion of FASTUPDATEMODE, see the description involving the SET
RECEIVER command in Chapter 8 (page 187).

To configure an RDF receiver process named $RECV to run as a process pair in CPUs 0 and 2 of
the backup system at a priority of 185 with FASTUPDATEMODE off, and to have the RDF image
trail file (with a primary extent size of 3000 pages and a secondary extent size of 3000 pages)
reside on the volume $IMAGE, issue the following commands:

]SET RECEIVER ATINDEX 0
]SET RECEIVER PROCESS $RECV
]SET RECEIVER CPUS 0:2
]SET RECEIVER PRIORITY 185
]SET RECEIVER RDFVOLUME $IMAGE
]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 attributes:

• CPUS primary-CPU : backup-CPU

• PRIORITY

• PROCESS

• RETAINCOUNT

• PURGETIME

The CPUS attribute specifies the processors in the backup system in which the purger is to run.

The PRIORITY attribute specifies the priority at which the purger will run. You should set the
purger’s priority higher than that of any application’s process and higher than that of any RDF
updater process.

The PROCESS attribute supplies a name for the purger process. You should specify a meaningful
mnemonic such as $PURG. The process name can be any unique valid process name up to 5
characters, including the $ symbol. However, you cannot specify HP reserved process names
that are of the form $X*, $Y*, or $Z*, in which * is any alphanumeric string.

The RETAINCOUNT attribute specifies how many of the most recent image trail files will be
retained on disk for each image trail. The default value is 2. For details about the RETAINCOUNT
attribute and triple contingency, see Chapter 10 (page 271).

The PURGETIME attribute specifies the number of minutes the purger process waits between
attempts to purge redundant image trail files. The default value is 60.

To configure an RDF purger process named $PURG to run as a process pair in CPUs 0 and 2 of
the backup system at a priority of 185, and to ensure that at least six image trail files are always
retained on disk, issue the following commands:

]SET PURGER PROCESS $PURG
]SET PURGER CPUS 0:2
]SET PURGER PRIORITY 185
]SET PURGER RETAINCOUNT 6
]SET PURGER PURGETIME 30
]ADD PURGER

You cannot start RDF until you have configured a purger process.

94 Installing and Configuring RDF

You can issue ADD PURGER commands only when RDF is stopped.

Updater Processes

Use SET VOLUME and ADD VOLUME commandsto configure the following updater attributes:

• ATINDEX

• CPUS primary-CPU : backup-CPU

• PRIORITY

• PROCESS

• IMAGEVOLUME

• UPDATEVOLUME

• INCLUDE

• EXCLUDE

• EXCLUDEPURGE

• INCLUDEPURGE

You must configure an updater process for each primary system volume to be protected by RDF.

The ATINDEX attribute 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 attribute specifies the processors in the backup system in which the updater will run.

The PRIORITY attribute specifies the priority at which the updater will run. You should set the
updater’s priority higher than that of any application’s process but less than the priority of the
RDF receiver process.

The PROCESSattribute supplies a name for the updater process. You should specify a meaningful
mnemonic such as $UP01. The process name can be any unique valid process name up to
5 characters, including the $ symbol. However, you cannot specify HP reserved process names
that are of the form $X*, $Y*, or $Z*, in which * is any alphanumeric string.

The IMAGEVOLUME attribute associates this updater process with a specific image trail you
have previously added to the RDF configuration. You cannot add this updater process, associating
it toan image volume, unless you have alreadyadded the image trail with the ADD IMAGETRAIL
command. Also, the ATINDEX of this updater must match the ATINDEX of the associated image
trail.

The UPDATEVOLUME attribute specifies the name of the disk volume on the backup system
that corresponds to a particular volume on the primary system. This attribute enables you to use
different volume names on the backup system than are being used on the primary system, if you
so desire.

The following guidelines are strongly recommended:

• There should be an identical one-to-one volume relationship between volumes on the primary

system and those on the backup system.

• Each backup volume should have the same name as the associated primary volume.

If the backup volume names are not identical to the corresponding primary volume names, then
you will have to update every partitioned file and everyfile that has alternate keys on the backup
system so that each points to the correct volume name.

You can use INCLUDE and EXCLUDE lists to specify which files are to be, or are not to be,
protected by RDF. For a description of INCLUDE and EXCLUDE lists, see Chapter 11 (page 279).

If you want Enscribe purge operations replicated, but you want to be selective and have some
purges replicated and others not, then you use INCLUDEPURGE and EXCLUDEPURGE to
specify what purges you want replicated. Please note that you must also have the RDF
REPLICATEPURGE attribute set to ON. For more details, see Chapter 11 (page 279).

Initializing and Configuring RDF 95

The following RDFCOM commands configure an updater named $UP01 to run as a process pair
in CPUs 2 and 4 at a priority of 180. The updater will be associated with an secondary image
trail on the volume $IMAGA1. The name of the backup volume and the primary volume being
protected is $DATA01.

]SET VOLUME ATINDEX 0
]SET VOLUME PROCESS $UP01
]SET VOLUME CPUS 2:4
]SET VOLUME IMAGEVOLUME $IMAGA1
]SET VOLUME PRIORITY 180
]SET VOLUME UPDATEVOLUME $DATA01
]ADD VOLUME $DATA01

The mapping between the configured updater process and a particular primary volume is
accomplished by the ADD VOLUME command.

You can issue ADD VOLUME commands only when RDF is stopped.

You must configureall updaters to use secondary image trails, thereby leaving the RDFVOLUME
(master image trail) exclusively for use by the master receiver (at index 0).

Creating a Configuration Command File

You can use the INFO * command with the OBEYFORM attribute to create a configuration
command file quickly and easily from an existing RDF configuration:

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 attribute:

]INFO *,OBEYFORM

RDFCOM lists the current attributes in the RDF configuration file to RDF.INIT in OBEY
command file format.

3. Issue another OUT command to redirect subsequent session output back to your terminal:

]OUT

For further information about configuration command files, see the example file in Appendix B

(page 359).

Configuration File Compatibility

Before running certain commands, RDFCOM compares its own version against the version of
the RDF configuration file to ensure that the configuration file is compatible with the current
version of the RDF software. If RDFCOM detects a difference, it prints the following message to
the home terminal and aborts the command:

RDFCOM version (version1) does not match the config file version (version2)

If that happens, you should make sure you are using the correct RDFCOM. If you are using the
correct version and you get this message, then you must reinitialize RDF.

If RDFCOM cannot determine the configuration file version, it prints the following message to
the home terminal and aborts the command:

RDFCOM version (version) does not match the config file version unknown

If that happens, you should make sure you are using the correct RDFCOM. If you are using the
correct version and you get this message, then you must reinitialize RDF.

96 Installing and Configuring RDF

Enabling RDF Operations

After you have copied all pertinent database files from the primary system to the backup system,
installed the RDF software on both systems, initialized and configured TMF on the primary and
all backup systems, and initialized and configured RDF, you can then start the TMF and RDF
subsystems. You must start TMF on the primary and all backup systems before you can start
RDF.

Starting TMF

To start or restart TMF, issue the TMFCOM command START TMF. If you plan to start the
applications being protected by TMF before starting RDF, you can include the DISABLE
BEGINTRANS attribute in the START TMF command; this attribute prevents the applications
from starting any transactions until you issue the TMFCOM command ENABLE BEGINTRANS.
For details about these TMFCOM commands, see the TMF Reference Manual.

Starting RDF

There are twoways tostart RDF: with updating enabled and with updating disabled. If updating
is enabled, the updaters begin updating the backup database immediately. If updating is disabled,
they do not (but the extractor and receiver continue to work normally). The default is to start
RDF with updating enabled.

To start RDF, issue the RDFCOM command START RDF:

]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). You can have a different super
ID if the RDF OWNER attribute has been set.

• You have a remote password on the primary system (it is also recommended, but not

required, that you have a remote password on the backup system as well).

• The RDF configuration file contains all necessary attributes.

• All updater volumes on the backup system are enabled for transaction processing.

When RDF starts execution, it automatically performs a validation check on the configuration
file; if the check succeeds, RDF copies the configuration file
$SYSTEM.control-subvolume.CONFIG to the backup system.

If the RDF configuration file does not exist, or if there are any missing or invalid attributes,
RDFCOM displays an error message and aborts the start operation.

If you did not start TMF on the backup system, or if you did not add an updater volume to the
TMF configuration on the backup system and enable it for transaction processing, the
corresponding updater logs an RDF error and terminates immediately. If you started TMF on
the backup system and added the updater volume to the TMF configuration but did not enable
that volume for transaction processing, the updater issues an error message and then stops.

If TMF BEGINTRANS is disabled, RDF issues an error message.

Unless you explicitly specify otherwise, RDF always starts with updating enabled: all updater
processes immediately begin updating their volumes by reading audit images from the RDF
image files and applying the appropriate changes to the backup database files.

If you want to start RDF with the updater processes disabled, you should specify the UPDATE
OFF attribute in the START RDF command on the primary system:

]START RDF, UPDATE OFF

Enabling RDF Operations 97

If you later want to start the updater processes, you merely issue a START UPDATE command.

Restarting the Applications

As the final step in establishing an RDF environment, if you had shut down your applications
previously, you can restart them now.

98 Installing and Configuring RDF

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 withthe subsystem. This chapter, which is intended for system operators, explains
how to use these utilities by focusing on the following topics:

• “Running RDFCOM” (page 99), including:

— Command syntax for starting an RDFCOM session
— Running RDFCOM interactively, noninteractively, and through a command file
— Using RDFCOM commands
— Requesting online help for RDFCOM commands

• “Running RDFSCAN” (page 109), including:

— Command syntax for starting an RDFSCAN session
— Using RDFSCAN
— Using RDFSCAN commands
— Requesting online help for RDFSCAN commands

• “Performing Routine Operational Tasks” (page 112), including:

— Displaying configuration attributes and operating statistics with RDFCOM
— Changing configuration attributes with RDFCOM
— Reading (monitoring) EMS messages with RDFSCAN

The syntax and functional descriptions of all RDFCOM and RDFSCAN commands appear in

Chapter 8 (page 187) and Chapter 9 (page 261), respectively.

For information about responding to error messages, handling failures, and stopping and
restarting RDF, see Chapter 5 (page 121). For information about the messages themselves, see

Appendix C (page 365).

Running RDFCOM

RDFCOM is an interactive command interpreter through which you begin a session and enter
requests to manage, operate, and control RDF. RDFCOM runs under the Guardian user interface
(normally the TACL command interpreter) to the NonStop operating system. To initiate
communication with RDFCOM, enter the keyword RDFCOM at the current TACL prompt. This
begins an RDFCOM session that lets you enter RDFCOM commands interactively,
noninteractively, or through a command file, as explained shortly.

Command Syntax for Starting an RDFCOM Session

To enter an RDFCOM session, use the following general command syntax. The specific attributes
you enter depend, of course, on the options you desire.

RDFCOM [/[IN command-file ] [,OUT output-file ]/ ]

[control-subvolume] ; [command ]

RDFCOM

is animplicit RUN command, instructing the TACL command interpreter to run the RDFCOM
utility program.

Running RDFCOM 99

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.

Typically, it is very useful to have your RDF configuration commands specified in a text file.
Then you specify this text file as the IN file. RDFCOM then performs the same configuration
each time you use the IN file and this saves you from having to enter all the commands
manually, one line at a time.

Vertical bar (|) is the comment character, if you want to include comment lines in the
configuration file. For more details see, “Sample Configuration File” (page 360).

OUT output-file

specifies a file to which all output (other than prompts for entering RDFCOM commands) is
to be written. This file might receive listings requested by INFO, SHOW, and STATUS
commands, for example. It might also receive RDFCOM commands generated by the
OBEYFORM option of the INFO command.

If you do not specify the OUT option, TACL supplies the name of its current default output
destination—usually the terminal from which you issued the RDFCOM command.

If you specify a disk file that does not exist, an EDIT file (file code 101) having the name you
specified is automatically created, and RDFCOM output is directed to it. If you specify a disk
file that exists, this must be an EDIT file (file code 101); RDFCOM output is appended to that
file. If you omit the volume or subvolume portions of the file name specifier, the default is
your current volume or subvolume, respectively.

control-subvolume

is the name of the RDF control subvolume on $SYSTEM on the primary and backup systems,
as well as the subvolume on the image trail volumes on the backup system in which the
image trail files reside.

The control subvolume name is the same as the name of the primary system without the
backslash (and with a one-character suffix appended to it, if you included the suffix in the
INITIALIZE RDF command).

If you omit control-subvolume, RDFCOM uses the name of the local system as the control
subvolume, without the backslash and with no suffix character appended.

command

is an RDFCOM command. If the command is present, RDFCOM executes it and then
terminates.

NOTE: You should not specify an IN file as well as a command. If you do, RDFCOM will

execute the command and terminate without ever reading the IN file.

If a command is not present and no input file is specified, RDFCOM displays a right bracket (])
as a prompt for you to enter commands interactively.

Using RDFCOM Interactively

When you use RDFCOM interactively, you conduct a continuous online dialog with it through
a series of prompts, commands, output displays, and messages.

Starting a Session

To start an interactive RDFCOM session, enter the RDFCOM keyword at your TACL prompt,
followed optionally by the name of the RDF control subvolume:

100 Operating and Monitoring RDF