unisys ClearPath Enterprise Servers Remote Database Backup Planning and Operations Guide ClearPath MCP 18.0 April

Transcription

1 unisys ClearPath Enterprise Servers Remote Database Backup Planning and Operations Guide ClearPath MCP 18.0 April

2 NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product or related information described herein is only furnished pursuant and subject to the terms and conditions of a duly executed agreement to purchase or lease equipment or to license software. The only warranties made by Unisys, if any, with respect to the products described in this document are set forth in such agreement. Unisys cannot accept any financial or other responsibility that may be the result of your use of the information in this document or software material, including direct, special, or consequential damages. You should be very careful to ensure that the use of this information and/or software material complies with the laws, rules, and regulations of the jurisdictions with respect to which it is used. The information contained herein is subject to change without notice. Revisions may be issued to advise of such changes and/or additions. Notice to U.S. Government End Users: This software and any accompanying documentation are commercial items which have been developed entirely at private expense. They are delivered and licensed as commercial computer software and commercial computer software documentation within the meaning of the applicable acquisition regulations. Use, reproduction, or disclosure by the Government is subject to the terms of Unisys standard commercial license for the products, and where applicable, the restricted/limited rights provisions of the contract data rights clauses. Unisys and other Unisys product and service names mentioned herein, as well as their respective logos, are trademarks or registered trademarks of Unisys Corporation. All other trademarks referenced herein are the property of their respective owners.

3 Contents Section 1. Overview of the Remote Database Backup System Documentation Updates What s New? What Remote Database Backup Can Do for You Roles of Databases and Hosts in a Remote Database Backup System Configurations of Remote Database Backup Systems Basic Remote Database Backup Hardware and Software Requirements Network Service Audit Trail Synchronization The Next Step More About Audit Transmission Modes Section 2. Understanding Audit Transmission Modes Audit Block (ABW) Transmission Mode Error-Handling Options for the ABW Mode Drop Error-Handling Option Operator Error-Handling Option Audit File Mirror (AFM) Transmission Mode Audit Transmission Modes (AFS, SCA, and NSC) Audit File Switch (AFS) Mode Server Capable (SCA) Mode Not Server Capable (NSC) Mode Audit Transmission Mode Options Impact of the Block Transmission Mode on Resources Impact of the File Transmission Modes on Resources Impact of the AFS Mode on Resources Impact of the SCA and NSC Modes on Resources The Next Step Selecting Options and System Resources for Your Goals Section 3. Selecting Remote Database Backup Options and System Resources for Your Goals Overview of the Process Identifying Your Goals for Remote Database Backup Clarifying Your Disaster Recovery Goals iii

4 Contents Considerations About the Use of the Primary Host Establishing Performance Requirements Selecting Audit Transmission Modes to Meet Your Goals Describing Your Resources Introduction to Gathering Data to Calculate Utilization A Two-Step Process General Impact of Remote Database Backup on Existing Resource Utilization Gathering Data on Existing Network Utilization Gathering Data on Future Network Utilization with Remote Database Backup Preliminary Measurements for the ABW Mode Preliminary Measurements for the AFS, SCA, and NSC Modes Obtaining Communications Processor Utilization Statistics Gathering Data on Host Processor Utilization Calculating the Total Secondary Host Processor Utilization The Next Step Preparing to Configure a Remote Database Backup System Section 4. Preparing to Configure a Remote Database Backup System Overview of Preparation Tasks Checking on the Remote Database Backup Installation Preparing to Use TCP/IP Preparations for Using a Nonusercoded Database with BNA Understanding Remote Database Backup Software Understanding Other Remote Database Backup Software Automating Some Remote Database Backup Operations Understanding How Remote Database Backup Uses Port Files Understanding More About the ABW Mode Automatic Audit Synchronization Process of the ABW Mode Integrating Remote Database Backup into Your Security Setup Setting Up Guard Files for the Secondary Host Preparing Personnel to Run the Remote Database Backup System Reviewing DASDL Source Files Designating Usercodes and Packs Ensuring Database File Availability on the Secondary Host I/O Timeout Value for the Ports Responding to a Port-I/O Timeout Error iv

5 Contents Influencing Tracker Performance Affecting the Speed of Tracker Performance Manipulating the Frequency of Restart Points Section 5. Configuring a Remote Database Backup System Configuration Tasks Defining Your Remote Database Backup System Initializing and Defining the Primary and Secondary Hosts Testing the Interhost Connection Enabling the Remote Database Backup System Cloning the Database on the Secondary Host Making the Required Database Files Available on the Secondary Host Specifying Dump Information and Pack Names for Database Structures on the Secondary Host Identifying Pack Names for Database Software Files on the Secondary Host Specifying Pack Names for Database Guard Files on the Secondary Host Providing Code File Titles and Memory Management Parameters on the Secondary Host Selecting a Method of Running the Clone Operation Verifying the Remote Database Backup System Starting the Secondary Database After a Clone Operation Synchronizing the Databases After Cloning with an Online Dump Section 6. Performing Takeovers Overview of a Takeover Performing Takeover Tasks Terminating Update Programs Transferring and Applying Audit Images Estimating Lost Transactions Establishing the New Primary Host Establishing the New Secondary Host Managing the Transaction Server Synchronized Recovery Section 7. Monitoring Your Remote Database Backup System Overview of Remote Database Backup Monitoring Accessing Messages Accessing the Current State of Audit Transfers v

6 Contents Accessing Cumulative Remote Database Backup Statistics Interpreting Remote Database Backup Statistics Accessing Database Statistics on Remote Database Backup Performance Section 8. Managing a Remote Database Backup Environment Interdependencies in the Remote Database Backup Environment Audit File Accumulation Acknowledgment of Audit Files Viewing and Updating Host Information Records Viewing a Host Information Record Modifying a Host Information Record Changing the Audit File Transmission Mode Cloning the Database on the Secondary Host Disabling Tracker Performing an Offline Dump of the Secondary Database Performing Replication of the Secondary Database Disabling the Remote Database Backup System Reenabling the Remote Database Backup System Changing the Network Service Changing the TCP/IP Credentials Changing the TCP/IP Key Container Using Visible DBS Commands in the Remote Database Backup Environment Section 9. Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment DASDL Updates in the Remote Database Backup Environment Processing Updates Under the ABW or AFM Mode Processing Updates Under the AFS, SCA, or NSC Mode Changing Code File or Guard File Names and Pack Locations Adding New Structures Tracker and the Reinitialization of an Existing Structure Reorganizations in the Remote Database Backup Environment Minimizing the Consequences of an Aborted Reorganization Deciding Whether to Perform Tasks Manually or Automatically Effects of Reorganization Open Options Availability of Database Structures During a Reorganization vi

7 Contents Handling Nonusercoded and Usercoded Databases Auditing During Reorganizations Performing a Structure Clone Operation Handling the Effects of an Extensive Online Reorganization Section 10. Recovering a Database in the Remote Database Backup Environment Types of Recovery in the Remote Database Backup Environment Rebuild Recovery Rollback Recovery Halt/Load and Abort Recovery Reconstruct Recovery Copying Database Structures from an Offline Dump Restoring Lost or Corrupt Database Files Section 11. Using an Enterprise Application Environment in a Remote Database Backup Environment Finding the Information You Need Secondary Database Functions Hints for Successful Enterprise Application Environment Operations Section 12. Troubleshooting Minimizing Problems Resolving Operational Problems with Database Operations Center Enable Operation Clone Operation Mode Change Resolving Takeover Problems Resolving Primary Database Problems Resolving Secondary Database Problems Reestablishing Synchronization Resolving Catchup Problems Resolving Tracker Problems Resolving Miscellaneous Problems Resolving Port and Network Errors Resolving Updating and Reorganization Problems Resolving Tape Audit Failures vii

8 Contents Section 13. Programmatic Interfaces Establishing the Link to the RDB Support Library Using the Takeover Entry Point Example Takeover Entry Point ALGOL Program Using the RDB_INFO Entry Point Using the GET_PRIMARY_MODE Entry Point Example GET_PRIMARY_MODE Application Program Text Using the SET_RDB_MODE Entry Point Using the GET_RDB_MESSAGE Entry Point Section 14. SYSTEM/RDBOPS Running RDBOPS Appendix A. Sample Clone WFL Job Sample Full Clone WFL Job A 1 Appendix B. Resource Assessment Forms System Resource Description Form B 1 Database Description Form B 2 Primary Host Database Applications List Form B 3 Primary Host Nondatabase Applications List Form B 3 Secondary Host Applications List Form B 4 Network Description Form B 5 Audit Generation Rate Form B 6 Applications Activity Form B 7 Appendix C. Methods of Measuring Resource Utilization Tools to Measure Database Activity C 1 Tools to Obtain an Audit Generation Rate C 5 Tools to Obtain an Audit Block Size C 6 Appendix D. Operational Considerations for Mirrored Audit Remote Database Backup System Environment D 1 Setting Up Shared Disks on ClearPath Hosts for EMC Mirrored Disks D 2 Recovering from a Corrupted Pack Label on Target Packs D 4 Changing Audit File Transmission Modes D 4 Disabling the Remote Database Backup System D 7 viii

9 Contents Performing a Planned Takeover in AFM Mode D 7 Restoring the Original Remote Database Backup Configuration Following a Planned Takeover D 9 Performing an Unplanned Takeover in AFM Mode D 11 Restoring the Original Remote Database Backup Configuration Following an Unplanned Takeover D 13 Index ix

10 Contents x

11 Figures 4 1. How Remote Database Backup Components Work Together for the ABW Mode Normal Flow of Audit Blocks in ABW Mode Catchup Process Flow of Audit Blocks in ABW Mode Sample Output from the Visible DBS STATUS Command Relation of Restart Points to Control Points Sample Report from the AUDIT ANALYZE AFN Command Sample Report Including AUDIT PROCESSOR TIMES Command Information Sample Output from the LIBS Command Sample template of the TEMPLATE/RDBOPS/CONFIG file C 1. Sample Output from the AUDIT ANALYZE AFN Command (Part 1) C 3 C 2. Sample Output from the AUDIT ANALYZE AFN Command (Part 2) C 4 D 1. Remote Database Backup System Environment and How It Works with Disk Subsystems D xi

12 Figures xii

13 Tables 1 1. Audit Transmission Modes Effects of the Open Options on Database Availability xiii

14 Tables xiv

15 Section 1 Overview of the Remote Database Backup System Remote Database Backup Overview This section contains overview information about the Remote Database Backup system, including What Remote Database Backup can do for you Roles of databases and hosts in a Remote Database Backup system Configurations of Remote Database Backup systems Basic Remote Database Backup hardware and software requirements Audit trail synchronization Documentation Updates This document contains all the information that was available at the time of publication. Changes identified after release of this document are included in problem list entry (PLE) To obtain a copy of the PLE, contact your Unisys representative or access the current PLE from the Unisys Product Support Web site: Note: If you are not logged into the Product Support site, you will be asked to do so. What s New? This guide provides changes and information specific to the current release as shown in the following table: New Or Revised Information Added information about using the TCP/IP network service instead of BNA. Location Throughout the guide

16 Overview of the Remote Database Backup System New Or Revised Information Made the following updates: Updated the Remote Database Backup Installation Checklist. Updated Files Installed with Remote Database Backup Updated Related Information Topics Updated Remote Database Backup Software Components Updated Database Operations Center and removed the table following it. Updated Port-I/O Timeout Error. Made the following updates: Updated the table after Methods of Running the Clone Operation. Updated Starting the Secondary Database After a Clone Database. Updated Actions that Initiate Tracker. Made the following updates: Updated subsection, Acknowledgement of Audit Files. Updated subsection, What Audit File Number (AFN) to Acknowledge. Removed subsection, Deleting the Host Information Record for the Secondary Host. Updated subsection, Changing the Audit Transmission Mode. Updated the list in Definition of a Host Information Record. Updated Viewing a Host Information Record. Added subsection, Code File Name Changes. Updated Examples of Offline Reorganizations with Structure Clones. Section 4: Location Preparing to Configure a Remote Database Backup System Section 5: Configuring a Remote Database Backup System Section 8: Managing a Remote Database Backup Environment Section 9: Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment

17 Overview of the Remote Database Backup System New Or Revised Information Location Made the following updates: Updated subsection title, Tracker Stops Applying Audit Images to, Tracker Stops Applying Audit to a Partitioned Structure. Updated subsection title, NO FILE Condition Under the SCA and NSC Modes to, Tracker Stops Applying Audit Images in SCA or NSC Modes. Updated Situation 1 and Situation 2 in subsection, Tracker Stops Applying Audit Images in SCA or NSC Modes. Updated subsection, Unexpected Audit Block Serial Number. Added subsection, RDBSUPPORT Library Unavailable. Added topic, Version Mismatch within Resolving Miscellaneous Problems. Made the following updates: Updated Example Remote Database Backup INFO Application Program Text. Updated Example GET_PRIMARY_MODE Application Program Text. Updated Declaration for the SET_RDB_MODE Entry Point. Updated Example Remote Database Backup INFO Application Program Text. Updated Using the GET_PRIMARY_MODE Entry Point. Updated Declaration for the SET_RDB_MODE Entry Point. Updated Example SET_RDB_MODE Application Program Text. Made the following updates: Updated information regarding the RDB Configuration File. Updated railroad diagram for <ops command> and its description. Updated command section and description of Example 6. Section 12: Troubleshooting Section 13: Programmatic Interfaces Section 14: SYSTEM/RDBOPS

18 Overview of the Remote Database Backup System New Or Revised Information Made the following updates: Updated the descriptions within, Changing Audit File Transmission Modes. Replaced instances of new target (primary) with target (new primary). Replaced instances of new source (secondary) with source (new secondary). Updated Performing a Planned Takeover in AFM Mode. Updated Performing an Unplanned Takeover in AFM Mode. Updated Synchronizing the Database on Both Hosts. Appendix D: Location Operational Considerations for Mirrored Audit What Remote Database Backup Can Do for You What Is Remote Database Backup? Remote Database Backup is a database recovery system. Remote Database Backup can be a key component of any disaster recovery plan because it minimizes the amount of time needed to recover from a loss of database access. Remote Database Backup also minimizes loss of productivity, loss of revenue, and loss of business because of interruptions in the ability to access your database. Remote Database Backup works with Enterprise Database Server databases. Components of a Remote Database Backup System The Remote Database Backup system consists of a database and a copy of the database. One database is update capable and the other can be used for inquiry purposes only. The update-capable database is called the primary database. The host on which this database resides is called the primary host. The current online remote database copy, called the secondary database, is inquiry capable only. The host on which this database resides is called the secondary host. The configuration of the primary and secondary databases on their separate hosts is called a Remote Database Backup system. A single host can participate in multiple Remote Database Backup systems

19 Overview of the Remote Database Backup System What Remote Database Backup Does Remote Database Backup enables you to maintain a current online inquiry-only copy of a database on an enterprise server separate from the enterprise server on which the update-capable database resides. The host locations can be at the same site or at two geographically distant sites. Remote Database Backup keeps the database copy up-to-date by applying the audit images from the audited database to the database copy. A choice of five audit transmission modes enables you to choose the means of audit transfer between hosts that best suits your needs. You also have a choice of two network protocols, BNA or TCP/IP. If the primary database or primary host fails, you can quickly switch the primary database operations to the secondary database on the secondary host. Related Information Topics For information about... Refer to... Audit transmission modes Sections 2, 3, and 4 Resource assessment for using Remote Database Backup Section 3 Roles of Databases and Hosts in a Remote Database Backup System Roles of the Databases In the Remote Database Backup system, the terms primary and secondary indicate the intended function of each copy of the database and the host on which it resides. The following table shows the functions of the primary and secondary databases. Database Function Primary Secondary Database inquiry and update Database inquiry only The secondary database Cannot be updated by application programs The secondary database is modified only by the application of audit images of transactions performed on the primary database. Can assume the role of the primary database if the primary database becomes unavailable

20 Overview of the Remote Database Backup System Roles of the Hosts One complete Remote Database Backup system is made up of one database the primary database on one host, and one copy of that database the secondary database on another host. A host is the system on which a primary or secondary database resides. A host can function as a primary host in one Remote Database Backup system and concurrently function as a secondary host for another Remote Database Backup system. In addition, one host can function as a secondary host (or primary host) for multiple Remote Database Backup systems. When you first initialize Remote Database Backup for a database, by default, the primary host is the host upon which the database resides. The other host you define for that database is designated as the secondary host. It remains a secondary host until a takeover is performed or until the Remote Database Backup capability is disabled. The primary and secondary hosts must have sufficient resources to support your Remote Database Backup system and your application environment. A Scenario of How the Databases Work Together The following scenario demonstrates how the primary database on a system called Host1 and the secondary database on a system called Host2 work together in response to, or possibly in anticipation of, an interruption on the primary host. In this scenario, the application normally runs against the primary database, with Remote Database Backup transferring audit images to the secondary database. Inquiry programs can be running against the secondary database. Then in response to, or possibly in anticipation of, an interruption on the primary database, you decide that the secondary database should assume responsibility for transaction processing. A designated person at your site, such as a database administrator (DBA), issues a command to tell the secondary database to take over the role of the primary database. Before the takeover command is issued, the primary database, if it is still available, should be brought down. After the takeover command is issued, the DBA transfers all update processing to Host2. When the takeover process completes, Host2 becomes the primary database for all transaction processing. If Host1 is still available, the DBA at the site has the option of running inquiry programs against the copy of the database on Host1. As you can see, the roles of the two databases are reversed and audit images are now transferred from Host2 to Host

21 Overview of the Remote Database Backup System Configurations of Remote Database Backup Systems Introduction You can configure the hosts and databases within the Remote Database Backup environment in many different ways. The choices range from the simple to the complex: A simple configuration would be one Remote Database Backup system two hosts with one database on each host. A complex configuration could involve multiple Remote Database Backup systems many hosts and databases configured on several hosts. Although there are many possible configurations, the most typical configurations are described in the following text. One Remote Database Backup System The following figure illustrates a single primary database and a single secondary database configuration. The primary payroll database on one host is backed up by a secondary payroll database on the other host. Reciprocal Backup Hosts for Two Remote Database Backup Systems The following figure illustrates the configuration of two Remote Database Backup systems in which each host acts as a reciprocal backup host for the other. Both hosts support a primary database and a secondary database

22 Overview of the Remote Database Backup System Multiple Primary Hosts with a Single Backup Host The following figure illustrates a configuration with multiple primary hosts and a single backup host. One host contains all the secondary databases for primary databases on several other hosts. This configuration illustrates a centralized corporate and division strategy in which three division hosts each contain a primary database that is backed up on the corporate host. The corporate host allows you to inquire against each of the secondary databases. Each primary database on a division host is both inquiry and update capable. Multiple Remote Database Backup Systems with Multiple Backup Hosts The following figure illustrates a configuration with multiple databases on one corporate host and multiple backup databases on several other hosts. The corporate host contains multiple primary databases that are backed up by secondary databases on other hosts. This configuration illustrates three primary databases running on the corporate host. This host allows inquiry against and update to each primary database payroll, accounting, and billing. Each of these databases is backed up by a secondary database on one division host. Each secondary database on a division host allows only inquiry users

23 Overview of the Remote Database Backup System Two Remote Database Backup Systems Sharing Primary and Secondary Hosts The following figure illustrates the configuration of two Remote Database Backup systems that share a common primary host and secondary host. The primary payroll and accounting databases on one host are backed up by secondary payroll and accounting databases on another host. The host containing the primary databases can be used for both update and inquiry purposes, while the host containing the secondary databases can be used for inquiry purposes only. Basic Remote Database Backup Hardware and Software Requirements The following table lists the basic hardware and software requirements for the Remote Database Backup system. For additional details on any item of hardware or software, contact your account manager

24 Overview of the Remote Database Backup System Hardware Memory MCP/AS Hardware/Software Remote Database Backup product Enterprise Database Server data management software Network Disk Requirement Two enterprise servers. The two systems do not need to be the same model, but extremes should be avoided, for example, pairing servers of widely varying available performance and capacity. Refer to the Enterprise Database Server Getting Started and Installation Guide. The primary and secondary hosts can run on different software release levels. The same software release level must be installed on both the primary and secondary hosts. The same software release level (compiled with the same target level) must be installed on both the primary and secondary hosts. This includes manually compiled tailored components such as DMSUPPORT and Reorganization. Hardware and software sufficient to handle Remote Database Backup traffic and other traffic between the primary and secondary hosts. If audit files will be transferred manually only under NSC mode, a network is not required. Enough storage capacity on both hosts to accommodate system software, application software, and your database and audit files. Audited Database Requirement Because Remote Database Backup uses the audit images from the primary database to update the secondary database, any database that is a candidate for Remote Database Backup must be audited. You can use single or duplicate audit files. Compatible Databases Remote Database Backup works with any database that uses the Enterprise Database Server for physical file management. Incompatible Databases Remote Database Backup is not qualified and not supported to work with the Transaction Processing System (TPS). Remote Database Backup also does not work with flat files, for example, KEYEDIO or KEYEDIOII files

25 Overview of the Remote Database Backup System Open Distributed Transaction Processing and Remote Database Backup You can use Remote Database Backup with databases that participate in Open Distributed Transaction Processing operations. However, in the event of a takeover, the synchronization between all databases in the Open Distributed Transaction Processing global transaction cannot be guaranteed. Related Information Topics For information about... Refer to... Compatible MCP release levels Configuring a Remote Database Backup system Open Distributed Transaction Processing and Remote Database Backup ClearPath MCP Migration Guide Section 5 Section 4 Network Service The TCP/IP network protocol is supported in addition to BNA. When using TCP/IP, there are no dependencies on BNA. It does not need to be present on either host. All audit transfer modes are supported with both TCP/IP and BNA. The choice of network service is per database. So, one database can use TCP/IP while another database on the same primary host uses BNA. This is particularly useful when multiple primary databases on the same host are backing up to different secondary hosts. The network service for a database is bi-directional. The same network service is used from the primary host to the secondary host and from the secondary host to the primary host. If the selected network service is TCP/IP, files will be transferred between the hosts using the File Transfer Protocol (FTP). If the network service is BNA, either Native File Transfer (NFT) or FTRapid may be used to transfer files. Audit Trail Synchronization Importance You need to decide on the level of audit trail synchronization you want for your Remote Database Backup system. This means answering the question, How closely must the backup database match its source? Or, in Remote Database Backup terms, How closely synchronized should the secondary database audit trail be to the primary database audit trail?

26 Overview of the Remote Database Backup System Your answer to these questions impacts the Remote Database Backup configuration options you choose and therefore the resources you need to meet your requirements. Modes of Audit Transmission Remote Database Backup provides five specific audit transmission modes that enable you to regulate Whether the transmission of audit images is automatic or manual Whether the transmission of audit images is as individual audit blocks or whole audit files Whether the transmission of audit images can be interrupted (that is, suspended) The degree of audit trail synchronization between the primary and secondary hosts Audit Block Write (ABW) The secondary audit trail is constantly and automatically kept synchronized with the primary database audit trail on a block-by-block basis. The ABW mode enables this close synchronization level by Handling interruptions to audit transmissions through one of two error-handling options Initiating a catch-up process for audit block transfer whenever the usual synchronization level is disrupted When the system detects a need for a Catchup process, you can specify the time synchronization restart interval on the Host screen before the Catchup process begins. Audit File Mirror (AFM) The secondary audit trail is constantly and automatically kept synchronized with the primary database audit trail on a block-by-block basis. The AFM mode enables this close synchronization level by supporting the remote mirrored disk environment and the shared disk feature. The physical mirroring of the audit disk is external to a Remote Database Backup system. At the secondary host, the RDB-agent task monitors audit activity occurring at the primary host. This monitoring cycle also includes re-initiation of Tracker if it is not running. As long as the RDBSUPPORT library is active, the RDB-agent task re-initiates Tracker and attempts to monitor audit activity. This monitoring cycle occurs at 20 second intervals unless communication has been disrupted, in which case the interval is increased to 60 seconds. When communication is resumed, the interval is returned to 20 seconds. If the audit transfer mode from the secondary host to he primary host is NSC mode, then the audit monitoring activity at the secondary host cannot be accomplished. Refer to the System Administration Guide and the System Commands Reference for additional information about the shared disk feature

27 Overview of the Remote Database Backup System Audit File Switch (AFS), Server Capable (SCA), and Not Server Capable (NSC) The secondary database audit trail can be kept periodically synchronized with the primary database audit trail through Automatic update, audit file by audit file Remote Database Backup enables this synchronization level with the audit file switch (AFS) audit transmission mode. Compatible file transfer products are Native File Transfer (NFT) and FTRapid for BNA and FTP for TCP/IP. If a transmission does not complete, Remote Database Backup automatically retries it at the next audit file switch. Operator-initiated update through a manual transfer of audit files Remote Database Backup allows the operator to choose a level of audit trail synchronization with the following audit transmission modes: Server capable (SCA) mode that can employ either the network or tape to transfer audits Not server capable (NSC) mode that can also employ either the network or tape to transfer audits, but does not perform any Remote Database Backup network-related services such as reporting information from the remote host on the View Remote Auditing Status screen or automatically copying files during the enable operation In the manual method, you transfer all audit images as individual audit files by using whatever means available. For example, you could transfer the files through a physical tape or a network. Remote Database Backup has no knowledge of or control over the transfer of the audit files, and you must inform Remote Database Backup of the presence of the audit files on the secondary host. Table 1 1 briefly describes the five Remote Database Backup audit transmission modes and identifies the degree of audit trail synchronization that you can expect with each mode. Table 1 1. Audit Transmission Modes Mode Expected Degree of Synchronization Audit block write (ABW) When an audit block is written to the audit file on the primary host, it is automatically transmitted by way of the network to the audit file on the secondary host. ABW also uses the network for the transmission of control information. Two error-handling options are available. Goal: Best possible audit trail synchronization (near real time). Best case: To within one audit block on a nonsectioned audit file with an acknowledgment rate value of 1. Note: This mode implicitly links the performance and response times of the primary and secondary hosts, and the network

28 Overview of the Remote Database Backup System Table 1 1. Audit Transmission Modes (cont.) Mode Expected Degree of Synchronization Audit file mirror (AFM) When an audit block is written to the audit file on the primary host, it is automatically mirrored to the audit file at the secondary host. Goal: Best possible audit trail synchronization (near real time). Best case:to within one audit block on a nonsectioned audit file. Audit file switch (AFS) When an audit file switch occurs on the primary host, the completed audit file is automatically transmitted through the network to the secondary host using the NFT or FTRapid transfer product for BNA or FTP for TCP/IP. Goal: Periodic synchronization. Best case: To within one completed audit file. AFS also uses the network for the transmission of control information. Server capable (SCA) After an audit file switch on the primary host, at a time you determine, you must manually transfer the completed audit file to the secondary host. After transferring the file, you must manually inform Remote Database Backup that the file is present. Goal: Periodic synchronization, completely under user control. Best case: To within one completed audit file. SCA also uses the network for the transmission of control information. Not server capable (NSC) After an audit file switch on the primary host, at a time you determine, you must manually transfer the completed audit file to the secondary host. After transferring the file, you must manually inform Remote Database Backup that the file is present. Goal: Periodic synchronization, completely under user control. Best case: To within one completed audit file. Under the NSC mode, Remote Database Backup does not use the network if one exists. What the Remote Database Backup Automatic Synchronization Process Does When Remote Database Backup transfers audit images block by block, Remote Database Backup synchronizes the secondary database audit trail with the primary database audit trail by transmitting audit images from the primary host to the secondary host

29 Overview of the Remote Database Backup System Data is considered to be backed up when the audit records for that data have been copied from the primary host to the secondary host. At this point, the information in the audit trail has not yet been applied to the secondary database. Therefore, the primary and secondary databases are not necessarily synchronized, even though their audit trails are synchronized. For example, if you run the same inquiry on a newly updated record on both hosts simultaneously, you can retrieve different answers if that record is in the audit trail of the secondary host and not yet applied to the secondary database. Remote Database Backup ensures that the primary and the secondary databases are synchronized by applying audit images to the secondary database as they are received on the secondary host. Synchronization Levels Related to Database Recovery The level of database audit trail synchronization you choose is tied to the two key factors of database recovery: The amount of time required to reestablish database access following an interruption The amount of data that will be lost as a result of an interruption If you have a secondary database audit trail that is synchronized with its primary database audit trail when the primary becomes unavailable, you are obviously in a very good position to recover the database quickly and with a minimal loss of data. You can also be in a good position to recover quickly and with a minimal loss of data if you operate Remote Database Backup at a delayed level of synchronization. Because you have a database already set up to take over the operations of the primary database, you can apply outstanding audits as quickly as possible, and be back online in a minimal and predictable length of time. Considerations About Synchronization Levels Before you choose a synchronization level, you need to consider the impact of Losing data if the primary database becomes unavailable The more closely synchronized your audit trails, the smaller the amount of data that might be lost if a host failure occurs. If most of your transactions are easily reproducible, having closely synchronized audit trails might not be so important to you. Degrading database, host, or network performance The workload and performance of the database, the hosts, and the network are tightly integrated. A heavy workload in any one component can impact the performance of either, or both, of the other two components. For example, heavy network traffic could cause a degradation in database performance. The more closely synchronized your audit trails, the more sensitive your environment becomes to heavy workloads in any one component. Purchasing suitable hardware and network components

30 Overview of the Remote Database Backup System To accommodate the host activity and network traffic that occurs in a closely synchronized Remote Database Backup environment, you might find it necessary to upgrade some or all of the host and network hardware components at your site. Related Information Topics For information about... Refer to... Audit synchronization Sections 2, 3, and 4 Audit transmission modes Sections 2, 3, 4, and 5 Estimating system and network resources for Remote Database Backup Sections 2 and 3 The Next Step More About Audit Transmission Modes The audit transmission modes are a major factor in the operation of Remote Database Backup. Although you have been introduced to the modes and know that the modes enable varied levels of audit trail synchronization, you still need to ensure that you understand the characteristics and benefits of each mode thoroughly. The modes, the error-handling options for ABW mode, and the impact of each mode on system and network resources are fully explained in Section

31 Section 2 Understanding Audit Transmission Modes In This Section This section explains the five Remote Database Backup audit transmission modes; these modes are the key factors influencing how current the secondary database is with the primary database. The topics in this section are as follows: Audit block (ABW) transmission mode Error-handling options for the ABW mode Audit file mirror (AFM) transmission mode Audit transmission modes (AFS, SCA, and NSC) Audit file switch (AFS) mode Server capable (SCA) mode Not server capable (NSC) mode Audit transmission mode options Impact of the block transmission mode on resources Impact of the file transmission modes on resources The next step selecting options and system resources for your goals Audit Block (ABW) Transmission Mode Goal The goal of the ABW mode is to transfer audit blocks to the secondary host as they are generated on the primary host. Under this mode, Remote Database Backup is able to establish and maintain a greater degree of synchronization between the primary and secondary audit trails when compared to the file by file transmission modes (AFS, SCA and NSC). Characteristics The ABW mode

32 Understanding Audit Transmission Modes Transmits audit data to the secondary hostblock by blockas it is being written to the audit file on the primary host. Immediately applies audit images to the secondary database as the audit images are received. Makes constant use of the network communications. Network speed and capacity should exceed audit generation rates to a sufficient degree that the network does not impede database throughput. Makes the primary host dependent on acknowledgments from the secondary host. Secondary processor speed and capacityand disk speed and capacitymust support the audit generation rates so that the secondary host does not impede response times on the primary host. Automatically creates both the original and duplicate audit files on the secondary host while transferring the audit data only once. Operates with one of two options for handling problems with audit block transmission. Benefits The principal benefits of using the ABW mode are that Synchronization of audit trails on the primary and secondary host is usually closer than is possible with the file transfer modes. Minimal loss of audit information occurs in a disaster or other interruption. Following a takeover, restoration of database access is faster than with the other modes. Considerations When Setting an Acknowledgment Rate The acknowledgment rate is the rate at which the secondary host sends acknowledgments to the primary host for receipt of the audit blocks. You set the acknowledgment rate when you define the database characteristics for the primary and secondary hosts. A higher acknowledgment rate results in fewer demands on the network, less risk of communication error, and potentially less wait time between audit block transmissions in other words, faster throughput. However, the potential for less wait time can diminish at a certain increased acknowledgment rate because of network buffering and other configuration and processor availability factors at your site. You can experiment by increasing the acknowledgment rate for a period of time and observing the average and total Accessroutines wait time on the View Remote Auditing Statistics screen

33 Understanding Audit Transmission Modes Acknowledgment Rate and Audit Trail Synchronization The acknowledgment rate affects the audit trail synchronization in ABW mode. In addition, the way in which the acknowledgment rate affects audit trail synchronization depends on whether audit files are sectioned. Nonsectioned Audit Files The acknowledgment rate is defined as one acknowledgment message for every n audit blocks, and the value n can be from 1 through 99. The default value is 10. The audit trail synchronization is within (2 * n) 1 audit blocks unless the secondary database is dropped. Sectioned Audit Files The Remote Database Backup system attempts to acknowledge every n audit blocks, where n is the rate. The Remote Database Backup software rotates the acknowledgment through the sections so that the same section does not always read the acknowledgment. The audit trail synchronization should generally be within 2 * n 1 blocks, but could be higherup to the number of audit sections. For example, if the number of audit sections is 3, the audit trail synchronization would be within (2 * n 1) + 3 blocks. For additional information, refer to Accessing Cumulative Remote Database Backup Statistics in Section 7 and Modifying a Host information Record in Section 8. Error-Handling Options for the ABW Mode What an Error Is An error during audit block transmissions under the ABW mode is a problem in communications detected by the port-i/o timeout function. If the audit blocks cannot be transmitted from the primary host to the secondary host and acknowledged within the time you specify for the port-i/o timeout value, the Remote Database Backup system registers an error for the audit block transmission, and the currently selected error handling option is activated. Some Causes of Errors The following circumstances can cause sufficient delay in sending an audit block so that the port-i/o timeout function registers an error: Too much network traffic from the primary to the secondary host causes a delay in sending the audit block. Too much traffic from the secondary to the primary host prevents the automatic acknowledgment of the previous audit block from reaching the primary host

34 Understanding Audit Transmission Modes A network hardware or software failure occurs. The Remote Database Backup software is waiting because of insufficient priority for the task, insufficient pack space, or a NO FILE condition. Error-Handling Options With the ABW mode, you can choose from the two error-handling options. Each option affects the Remote Database Backup system differently. Therefore, one option can be more appropriate than the other, depending on the conditions and the throughput of your network. Each option has advantages for particular database needs. Option Drop the secondary (the default) Operator intervention Description Changes activity on the secondary host Enables the DBA to choose one of two actions depending on the situation in which the error occurs Note: In the remainder of this document, the error-handling options are referred to as Drop and Operator. Related Information Topics For information about... Refer to... Catchup Section 4 Port-I/O timeout function Section 4 View Remote Auditing Status screen Section 7 Sectioned audit files Enterprise Database Server Utilities Operations Guide DASDL Programming Reference Manual View Remote Auditing Statistics screen Section 7 Takeovers Section 6 Drop Error-Handling Option What the Option Does The error-handling option called Drop automatically suspends the transfer of audit images to the secondary host when there is a problem with audit transfers. Updates continue on the primary database, and audit images collect to be transmitted and applied to the secondary database later

35 Understanding Audit Transmission Modes When to Use the Drop Option You use the Drop error-handling option when it is important to continue processing on the primary database. Application programs on the primary host are not interrupted while you are diagnosing and solving the communications problem. Both the primary and secondary hosts automatically attempt to reestablish communications. On the secondary host, a catch-up process attempts to communicate with the primary host every n seconds. On both the primary and secondary host, Remote Database Backup periodically attempts to ensure the initiation of the catch-up process. There is no limit on the number of times that the catch-up task attempts to communicate with the other host. Option Results The result of the Drop option after an error occurs is a buildup of audit blocks on the primary host that need to be transferred to the secondary host. After the communications error has been corrected, the catch-up process begins to transmit audit blocks to the secondary host until the audit trails are synchronized. After the audit trails are synchronized, new audit blocks are again transmitted through the normal audit transfer mechanism. Operator Error-Handling Option What the Option Does The error-handling option called Operator causes the system to wait for operator intervention when there is a problem with audit transfers. The operator can then manually designate one of the following actions, depending on the needs of the situation: Stop sending audits to the secondary host. Retry communications. For the retry action to work correctly, the acknowledgment rate must be set to 1. When to Use the Operator Option You use the Operator error-handling option when you want to identify the problems that are occurring before deciding on the action to take. Any failure to receive an acknowledgment from the secondary host during audit transmission results in the primary database waiting on an AX (Accept) system command. Until the operator responds to the AX command, all update activity on the primary database stops. In response to prompts on the ODT, the operator enters one of the AX commands listed in the following table

36 Understanding Audit Transmission Modes Action to Be Taken Stop sending audits to the secondary host. Retry communications. <mix number> AX D <mix number> AX R Syntax for AX Command Option Results The result of the Operator option after an error occurs depends on which action the operator chooses to perform until the error is corrected: The result of stopping audit transfer to the secondary host is similar to the result of the Drop error-handling option explained earlier in this section. The result of retrying communications is either that communications between the hosts are restored or that communications remain in an interrupted state. Audit File Mirror (AFM) Transmission Mode Goal The goal of the AFM mode is to transfer audit blocks to the secondary host as they are generated on the primary host. Under this mode, Remote Database Backup is able to establish and maintain a greater degree of synchronization between the primary and secondary audit trails when compared to the file by file transmission modes (AFS, SCA and NSC). Characteristics The AFM mode Includes an option to disable COPYAUDIT at the secondary host. Mirrors audit data to the secondary site by using the Symmetrix Remote Data Facility (SRDF), a disk-mirroring software solution from EMC, as data is being written to the audit file on the primary host. Immediately applies audit images to the secondary database as the audit images are being mirrored. Uses physical mirroring of the audit disk that is external to a Remote Database Backup system. Requirements The AFM mode Requires mirroring of both the original and duplicate audit file. Requires a shared disk feature for each physical disk that is mirrored. Requires SRDF from EMC

37 Understanding Audit Transmission Modes Audit File Copy and Removal For a Remote Database Backup system that is configured for AFM audit transfer, the audit file copy and removal are handled in the following way when COPYAUDIT is enabled for the secondary host: COPYAUDIT runs at the primary host and copies the audit data without removing the file. COPYAUDIT runs at the secondary host and copies the audit data without removing the file. After COPYAUDIT completes successfully at the secondary host, a message is sent to the primary host to initiate the removal of the audit file. For a Remote Database Backup system that is configured for AFM audit transfer, the audit file copy and removal are handled in the following way when COPYAUDIT is disabled for the secondary host: COPYAUDIT runs at the primary host, is initiated by the database stack, and copies the audit data without removing the file. After Tracker applies the audit file at the secondary host, a message is sent to the primary host to initiate the removal of the audit file. Benefits The principal benefits of using the AFM mode are as follows: Synchronization of audit trails on the primary and secondary host is usually closer than is possible with the file transfer modes. Network traffic is minimized between the primary and secondary hosts. Minimal loss of audit information occurs in a disaster or other interruption. Following a takeover, restoration of database access is faster than with the file transfer modes. Operational Considerations The primary host needs sufficient disk space to store all audit files until they are no longer needed by the secondary host. The secondary host needs sufficient processor performance to process audit data at a rate that does not prevent the primary host from having enough disk space to create new audit data. AFM is the recommended audit transmission mode for the secondary host when the audit transmission mode for the primary host is AFM. SCA or NSC can be specified for the audit transmission mode for the secondary host, although these modes might require additional manual steps during and following a takeover

38 Understanding Audit Transmission Modes Audit Transmission Modes (AFS, SCA, and NSC) Advantages of Audit File Transmission In relation to the ABW mode, the file transmission modes (AFS, SCA, and NSC) create less impact on primary host and network performance because only audit file not audit block acknowledgments are involved during the file transmission. The AFS mode provides greater throughput than the throughput achievable under the ABW mode. The AFS mode also has a minimal impact on the primary database. If you do not require that the secondary database be closely in step with the primary database, you can transfer audit files automatically by means of the AFS mode. With both the SCA and NSC modes, you can govern audit transfer to the secondary host and audit application to the secondary database to achieve the synchronization that best fits your goals and your resources. Audit Transmission Modes and Risk to Data Projecting into the future, you should consider what occurs when you need the secondary database to take over the role of the primary database. This change of role called a takeover is required when the primary database becomes unavailable for whatever reason. Once the secondary database has taken over as the primary database and begins to be updated, it is not possible to recover and apply any audits from the primary database that were not applied to the secondary database before the takeover. Therefore, you can lose some audits during a takeover unless you can Keep the secondary audit trail perfectly synchronized. Retrieve unapplied audit files from the primary host and apply them to the secondary host before you do the takeover. Reprocess the transactions. Audit File Switch (AFS) Mode Goal The goal of the AFS mode is to establish and maintain periodic synchronization between the primary and secondary audit trails. Synchronization can be within one completed audit file

39 Understanding Audit Transmission Modes Description Under the AFS mode, Remote Database Backup automatically transmits an audit file to the secondary host when an audit file switch occurs on the primary host. The Remote Database Backup software automatically acknowledges the receipt of the audit file, reads the audit file from disk, and applies the audit images from the file to the database. The AFS mode makes intermittent use of the network communications for the transmission of audit files and control information. To transfer the audit file under the AFS mode, Remote Database Backup uses either the NFT or FTRapid file transfer product for BNA and FTP for TCP/IP. The transfer rate of FTRapid is significantly faster than the NFT transfer rate. Both products are dependent on the physical connections of your network. FTRapid is an optional product in a Remote Database Backup system and must be purchased separately from Remote Database Backup. For BNA, the file transfer option you specify NFT or FTRapid is directional. That is, if you choose the AFS mode for both hosts, you designate one file transfer option on the primary host for primary-to-secondary host audit file transfer. You also designate a file transfer option for the secondary host to use in case of a takeover when the current secondary host becomes the primary host. When the Remote Database Backup system transfers sectioned audit files, the mix reflects one task for each audit file section. The task name incorporates the audit file number. For example, the task name of the primary audit file 5 would be <database name>/auditxfer/audit5/ <section n>. The task name for the duplicate audit file would be <database name>/auditxfer/2audit5/<section n>. The task initiates a WFL job that is responsible for copying the audit file. If the audit file has more than one section, then the WFL job initiates parallel copy jobs for each section of the audit file. Benefits The AFS mode provides automatic audit file transmission with a minimum of demand on your network and processor capabilities. The AFS mode transfers an entire audit file by means of a file transfer mechanism as soon as the audit file is filled and closed and the next audit file is opened. Once the audit file is received on the secondary host, Remote Database Backup applies the audit file images to the backup database. You specify the size of the audit file as you normally do by setting Enterprise Database Server parameters. Remote Database Backup reinitiates failed audit transfers at the next audit file switch, as shown in the following table:

40 Understanding Audit Transmission Modes When the following audit unit fails... Remote Database Backup reinitiates... Nonsectioned audit file Sectioned audit file Several audit files The audit file Remaining audit file sections in parallel All audit files in parallel Server Capable (SCA) Mode Goal The goal of the SCA mode is to achieve periodic audit trail synchronization that is completely under your control. At the optimum, synchronization can be within one completed audit file. Description Under this mode, you determine the method of audit file transfer and the timing of audit file transmissions. Remote Database Backup reports the audit files that are present on the secondary host. You must manually acknowledge receipt of audit files you copy to the secondary host using the Acknowledge the Manual Transfer of Audit Files Selection screen. The acknowledgment communicates that the entire audit file is present on the secondary host. When you transfer sectioned audit files, the system accepts the acknowledgment only after all sections of the file are present. The Remote Database Backup software then reads the audit file and applies the audit images to the secondary database. You can use single or duplicate audit files; however, if you use duplicate audit files, you must manually transfer both files to the secondary host. Benefits The SCA mode enables you to maintain a duplicate database without the network overhead that accompanies the ABW mode or even the AFS mode. The SCA mode also does not impact the throughput of the primary database. This mode entails minimum processor and network demands for Remote Database Backup, but still affords you the audit application services of Remote Database Backup. Not Server Capable (NSC) Mode Goal As with the SCA mode, the goal of the NSC mode is to achieve periodic audit trail synchronization that is completely under your control. At the optimum, synchronization can be within one completed audit file

41 Understanding Audit Transmission Modes Description Under this mode, Remote Database Backup functions as though there were no communications link between the hosts. You determine the method of audit file transmission (network or tape) and the timing of audit file transmissions. There is no processor overhead for Remote Database Backup control information, and you keep your own records of the status of audit file transmissions. You must manually acknowledge receipt of audit files you copy to the secondary host using the Acknowledge the Manual Transfer of Audit Files Selection screen. The acknowledgment communicates that the entire audit file is present on the secondary host. When you transfer sectioned audit files, the system accepts the acknowledgment only after all sections of the file are present. The Remote Database Backup software then reads the audit file and applies the audit images to the secondary database. You can use single or duplicate audit files; however, if you use duplicate audit files, you must manually transfer both files to the secondary host. Benefits The NSC mode enables you to maintain a duplicate database with a minimum of the processor and network overhead that is entailed with the other modes. This mode does not impact the throughput of the primary database. You are in complete control of the audit file transmission process, with minimum processor demands. Related Information Topics For information about... Refer to... Acknowledging audit files Section 8 Duplicate audit files Section 4 View Remote Auditing Status screen Section 7 Sectioned audit files Enterprise Database Server Utilities Operations Guide DASDL Programming Reference Manual Audit Transmission Mode Options Introduction Two mode options enable you to adjust the audit transmission process while you run Backup: Bi-directional modes Ability to alternate between modes

42 Understanding Audit Transmission Modes Bi-Directional Mode Selection When you configure a Remote Database Backup system, you designate one mode on the primary host for primary-to-secondary host audit transmission. You also designate a mode for the secondary host to use in case of a takeover when the current secondary host becomes the primary host. The ABW mode with the Drop error-handling option is the default mode for each host. Alternating Between Modes You can use the audit transmission modes in a complementary fashion. Select the alternate mode while Remote Database Backup is operational by using the Mode screen. In daily operations, you would usually run Remote Database Backup under one audit transmission mode. However, you could also alternate daily between modes, for example, ABW mode during prime time and SCA mode during off-hours. The point at which a mode change takes effect varies depending on whether the database is open or closed at the time of the change. The process of switching from one mode to the other is complete when the current audit file is closed. Audit file closure can occur automatically as a result of the audit file being filled or can occur manually by using the appropriate Visible DBS command to perform an audit file switch. The mode you are changing to becomes active as soon as the next audit file is opened. Example The following scenario describes how the ABW and AFS modes can be used alternately. A company has its main corporate databases on a host located at the corporate headquarters. A backup of these databases is maintained on the MIS development host located in another part of the building. A large volume of offline transactions accumulate during the business day. These transactions are processed and applied to the main databases in batch mode between the hours of 10 p.m. and midnight. The updates must be initiated at 10 p.m. and completed by midnight. During normal business hours, other transactions are processed online against the corporate databases. These are home-office transactions, which update mission-critical information in the corporate databases. The data processed in these transactions are sensitive, and the backup database on the MIS host must be maintained in as close to real time as possible. The volume of these transactions is lower than that of the batch updates performed between 10 p.m. and midnight. An evaluation of the transaction volumes and time periods associated with this scenario indicates that the high-volume period (10 p.m. to midnight) should be handled by Remote Database Backup using the AFS mode with FTRapid. The AFS mode provides a higher throughput capability, and the situation does not require the primary and secondary databases to be in step during the update period. Processing requirements for the

43 Understanding Audit Transmission Modes remainder of the day indicate the use of the ABW mode since the transactions being processed must update the backup database as soon as possible and the volume of transactions can be handled by the ABW mode. In a single 24-hour period (midnight to midnight), the Remote Database Backup environment would be managed as shown in the following table: Time Midnight Midnight to 10 p.m. Event Remote Database Backup is placed in ABW mode for the normal processing of transactions entered during the day. The operator closes the audit file to force the mode change. All audits created during online transaction processing are sent to the secondary host as they are created on the primary host. Then the audits are applied to the secondary database. 10 p.m. The operator requests that Remote Database Backup be placed in AFS mode and closes the current audit file to force the mode change. 10 p.m. to Midnight The nightly batch update of the database takes place. Audit files of offline transactions are created and sent to the secondary host where Remote Database Backup applies the updates to the secondary database. Related Information Topics For information about... Refer to... ABW mode (technical description) Section 4 Changing audit transmission modes Section 8 Synchronization levels Sections 1 and 3 Takeovers Section 6 Impact of the Block Transmission Mode on Resources General Impact Some primary database performance degradation is possible when you use ABW mode for hightransaction-rate databases. The existence and the amount of degradation is dependent on Remote Database Backup configuration Volume of audits

44 Understanding Audit Transmission Modes Network configuration Application requirements The best way to eliminate or minimize the chance of primary database performance degradation is to ensure that ample secondary host and network resources are available and optimally configured. Impact of Audit Block Acknowledgments The Remote Database Backup protocol used to transfer audit blocks to the secondary host can make the greatest impact on system resources. This protocol calls for a periodic acknowledgment message from the secondary host to the primary host, indicating that the secondary host is receiving and storing the audit blocks being sent. The acknowledgment rate is a number from 1 through 99 that you designate. For example, if you designate 20 as the acknowledgment rate, the system sends the acknowledgment message from the secondary host after receiving the first of the 20 audit blocks to be sent. If the acknowledgment messages are not returned promptly, either substantial degradation of primary database performance or temporary loss of synchronization occurs, depending on how you have configured Remote Database Backup. When acknowledgment messages are not returned promptly, the update applications are suspended on the primary host. When the configured wait time is exceeded, Remote Database Backup software reacts as though the secondary host were inactive and suspends audit transfer temporarily. Impact on the Secondary Host The secondary host must have the capacity to enable application of audits at the average rate of audit data generation. In other words, the secondary host must be able to apply the audits sooner or later if the secondary database is to be a viable resource for disaster recovery or useful for inquiry purposes. Sufficient system capacity must exist to handle the average audit processing requirements, but not necessarily peak processing requirements. You assess secondary processor utilization for the following two components: Audit transfer Establish the overhead by using the guidelines suggested for assessing primary host utilization. Audit application Estimate the overhead according to database statistics from the primary host

45 Understanding Audit Transmission Modes Impact of Duplicate Audit Files In ABW mode, Remote Database Backup automatically creates both the original and duplicate audit files on the secondary host while transferring the audit data only once. Related Information Topics For information about... Refer to... ABW mode (technical description) Section 4 Accessroutines Enterprise Database Server Utilities Operations Guide Audit generation rates Section 3 Catchup Section 4 Choosing an audit transmission mode and an error-handling option Sections 5 and 8 Configuring a Remote Database Backup system Section 5 Duplicate audit trails DASDL Programming Reference Manual Network transmission rates Section 3 Remote Database Backup acknowledge task Section 8 Tracker Sections 4 and 8 Impact of the File Transmission Modes on Resources Summary The three audit transmission modes that transfer entire audit files can provide one the following results, depending on which mode you use: Immediate audit file transfer to minimize the possibility of data loss and immediate application of audit data to the secondary database Delayed transfer and therefore less assurance of complete data on the secondary database Immediate processing of audit files can require additional resources to avoid resource contention. Any lag in the audit file transfer increases the risk of losing the audited transactions if the primary host becomes unavailable

46 Understanding Audit Transmission Modes Comparative Benefits In relation to resources, the principal benefits of the file-based audit transmission modes AFS, SCA, and NSC are as follows: The additional network and processor utilization of Remote Database Backup cannot directly affect primary database performance, as it can in the audit block transmission mode, ABW. File-based modes provide options that might enable you to avoid indirect performance impacts by eliminating resource contention during peak periods. Security of Immediate Audit File Transmission The AFS mode is best for minimizing potential loss of data and interruption of database access. This mode transfers and applies each audit file immediately after the audit file is filled and closed on the primary host. In general, immediate audit file transmission and application of audits to the secondary database requires some extra network and secondary host capacity to handle peak audit generation rates without an unacceptable impact on existing network traffic or secondary host processing. If this capacity is not available, however, you can use less secure alternatives that might still meet your requirements. In the SCA and NSC modes, immediate audit file transfer is optional and accomplished manually. Impact of the AFS Mode on Resources Summary The AFS audit file transmission mode provides Automatic immediate transfer of audit files by way of NFT or FTRapid for BNA and FTP for TCP/IP Immediate application of audits to the secondary database Copying of the primary and secondary audit files if you use duplicate audit files The AFS mode requires that you consider both network and processor use at peak periods. Benefits The principal benefit of AFS mode is that audit files are automatically transferred, acknowledged, and applied to the secondary database when these files are closed on the primary host

47 Understanding Audit Transmission Modes Therefore, you need to have network and processing capacity to handle file transfer whenever the transfers are initiated. To benefit fully from the automatic nature of this mode, you also need to have processor capacity on the secondary host to apply the audits when the audit files arrive. When necessary, however, you can temporarily delay the application of audit files to the secondary database. Effect of Duplicate Audits on the Network When you specify duplicate audits in DASDL, both the original and duplicate audits are automatically copied to the secondary host. Handling Peak Periods If an audit file fills during the peak audit generation period, then the transfer of the audit file or files can overlap the latter portion of the peak processing period. Online transactions could be negatively affected if the following conditions exist: The peak audit generation rate occurs during online transaction processing. Insufficient network capacity exists to handle both the online transactions and the audit file transfer to the secondary host. Handling Audit Transfer Delays The Remote Database Backup system provides an internal scheduling mechanism for transferring the audit files to the secondary host. This mechanism allows for up to 50 audit files to be scheduled for copying. If this limit is exceeded, the following message is issued and the audit file identified in the message must be copied manually to the secondary host; the copy job is not rescheduled. AUDIT TRANSFER TASK LIMIT OF 50 EXCEEDED, AUDIT FILE nn WILL NOT BE TRANSFERRED The variable nn represents the audit file number of the audit file that needs to be copied manually. If your system experiences audit transfer delays, you can increase the number of sections for your audit files, thereby expanding the amount of audit information contained in a logical audit file. This expansion can be done by performing an SM command, such as the following, on the database stack at the primary host: <db mix> SM AUDIT SECTIONS = 2 At the next audit file switch, the audit sections are increased to 2, thereby doubling the amount of audit information that a logical audit file represents. This action might allow your network to finish the audits that are already scheduled, avoiding the scheduling overflow condition previously described. Your audit archival mechanisms might also need to be altered to reflect a change in audit sections at the primary and secondary hosts

48 Understanding Audit Transmission Modes Note: If your secondary database is seriously behind due to audit transfer problems during peak periods, you can consider recloning your secondary database with a current database backup of the primary database to avoid the time it would take the secondary host to apply the delayed audits. Related Information Topic For information about... Refer to... Sectioning audit files DASDL Programming Reference Manual Impact of the SCA and NSC Modes on Resources Impact on Network Resources The SCA and NSC audit file transmission modes cause no impact for audit file transfer using the network, and some impact for a network copy job. You should consider the total audit generation rate versus the possible off-peak transfer volume to be sure that you can transfer audits for each day within that day. The effect on your network of using the SCA or NSC mode depends on the means and timing of the audit transmission. The following table lists the network effects that result from these factors. Means of Transfer Effect on Network Resources Tape Network No significant requirement for network resources. Depends on the timing requirements for the transfer: For immediate transfer, base your transfer rate assessment on the network and processor capacity available during peak, worst-case system utilization periods. For off-peak transfer, determine whether the total amount of audit data can be copied during the off-peak period at a rate that is possible during this off-peak period. Impact on Primary Processor Use Except for the overhead of the tape or network copy job, the SCA and NSC audit file transmission modes cause no impact on the primary processor. To minimize the impact on primary processor use, you should consider both peak and off-peak audit transmission possibilities

49 Understanding Audit Transmission Modes However, if audit files are not to be copied immediately, you should ensure that sufficient pack space exists to store the files until they are copied. Impact on Secondary Processor Use The SCA and NSC audit file transmission modes impact the secondary processor by adding overhead from the tape or network copy job and from Remote Database Backup applying audits to the secondary database. You should consider the total audit generation rate versus the possible off-peak transfer volume to be sure that you can transfer the audits for each day within that day. Initiation of Audit Application Since you must use the Remote Database Backup Acknowledge function to initiate application of audits on the secondary host each time an audit file is transferred, you have some control over the scheduling of processor, memory, and I/O resources on the secondary host. For example, you need not cause Remote Database Backup to start application of audits as soon as each audit file arrives. If immediate application of audits would degrade the performance of other tasks, you can acknowledge the files at a later time when sufficient excess system capacity is available to support the additional processing required for audit application to the secondary database. Duplicate Audit Files In the SCA and NSC modes, you can create duplicate audit files by making a local copy of the audit file after the original audit file is on the secondary host. Related Information Topics For information about... Refer to... Audit generation rates Section 3 Choosing an audit transmission mode and an error-handling option Configuring a Remote Database Backup system Sections 5 and 8 Section 5 The Next Step Selecting Options and System Resources for Your Goals The performance of an Remote Database Backup system is based primarily on how well your computing resources and network capabilities match the requirements to keep your database audit trails at the desired level of synchronization

50 Understanding Audit Transmission Modes Section 3 of this guide leads you through the steps required to analyze how a Remote Database Backup system can work in your environment

51 Section 3 Selecting Remote Database Backup Options and System Resources for Your Goals In This Section This section explains how to select Remote Database Backup configuration options and how to size your system resources to achieve your goals for Remote Database Backup. The section presents an overview of the process and then explains the steps in the process in the order in which you perform them: Identifying your goals for Remote Database Backup - Clarifying your disaster recovery goals - Considerations about the use of the primary host - Establishing performance requirements Selecting audit transmission modes to meet your goals Describing your resources Introduction to gathering data to calculate utilization - A two-step process - General impact of Remote Database Backup on existing resource utilization Gathering data on existing network utilization Gathering data on future network utilization with Remote Database Backup - Preliminary measurements for the ABW mode - Preliminary measurements for the AFS, SCA, and NSC modes - Obtaining communications processor utilization statistics Gathering data on host processor utilization - Gathering data on existing host processor utilization Calculating the total secondary host processor utilization - Secondary host for the purpose of remote backup - Secondary host for the purpose of taking over the primary host role The next step preparing to configure a Remote Database Backup system

52 Selecting Remote Database Backup Options and System Resources for Your Goals Overview of the Process The process of selecting the Remote Database Backup configuration options that can fulfill your goals and performance requirements and then sizing your system resources so that Remote Database Backup can run efficiently with the options you want is an iterative process. The steps in the process are as follows: 1. Identifying your goals and related performance requirements for Remote Database Backup If you have more than one goal, you need to prioritize the goals. 2. Selecting Remote Database Backup configuration options that enable you to achieve your goals Choosing an audit transmission mode is the main factor in this effort. 3. Describing your resources 4. Gathering utilization data This process includes two efforts: Making a profile of your current processing requirements and determining how your current resources are meeting these needs Projecting processing requirements for Remote Database Backup and determining how your resources can handle these requirements If your determination shows that your resources are not adequate, either obtain added resources or repeat steps 1 through 4 until you achieve a plan that balances your resources with your goals. Identifying Your Goals for Remote Database Backup Purpose of Remote Database Backup Remote Database Backup is designed as a database recovery system that can be a component of your overall disaster recovery plan. A secondary purpose for Remote Database Backup can be to free primary host resources by moving inquiry or nondatabase applications to the secondary host. Disaster A Relative Term What constitutes a disaster for one business might be an acceptable interruption for another business. Specific goals for Remote Database Backup differ from user to user. Goals need to be identified and planned for on an individual basis. Performance requirements also differ. Both your disaster recovery goals and your performance requirements impact your choice of Remote Database Backup options

53 Selecting Remote Database Backup Options and System Resources for Your Goals Clarifying Your Disaster Recovery Goals Some Questions Every business needs to withstand some interruptions in the availability of data resources. Your answers to the following questions might help you determine how you want to employ Remote Database Backup in your environment so that you can minimize interruptions and the amount of data loss an interruption might entail. What are the acceptable limits of service interruption and data loss? What are the critical applications that must be available to ensure viability of the business? What volume of processing must the secondary host support if it is to assume the role of primary processing resource? What levels of network speed, capacity, and reliability are necessary to achieve the objectives? Can I automate all database and network functions required to move processing from the primary host to the secondary host as well as automating the initiation of these functions? What impact will high synchronization requirements have on the primary host? Some Assumptions Some assumptions under which Remote Database Backup was developed for disaster recovery purposes are When a disaster of sufficient length and extent strikes a business that is unprepared, the business might not be able to survive the disruption. Supporting the viability of the business after a major disaster means timely restoration of critically important application services and prevention of extensive losses of critically important data. The secondary host must be in a secure location and distant enough from the primary host that a single disaster is unlikely to affect both hosts at the same time. Situations Where Remote Database Backup Is Useful In general, for purposes of disaster recovery, Remote Database Backup is useful for instances where long interruptions are not acceptable. Remote Database Backup minimizes the time needed to recover after any interruption and enables you to recover your database within minutes. Specifically, Remote Database Backup is useful for Planned disruptions of the primary host, for example, periodic system maintenance, system software upgrades, and offline database dumps Unplanned disruptions of the primary host, for example, power outages or other circumstances that make your data unavailable

54 Selecting Remote Database Backup Options and System Resources for Your Goals Remote Database Backup is also useful as a component of a comprehensive disaster recovery system that provides a continuous processing environment. Considerations About the Use of the Primary Host Introduction You can consider freeing primary host resources by relocating to the secondary host any function that requires batch or low-volume online inquiry access to reasonably current data. For example, Remote Database Backup enables you to move functions such as production reporting and inquiry application testing from a fully utilized primary host to a less fully utilized secondary host. Such a move can provide More efficient use of an existing secondary host A less disruptive or less expensive alternative to replacing the primary host with a more powerful model Increased throughput on the primary host Some Questions To assess the suitability of freeing primary host resources in your setting, you need answers to the following questions: How might inquiry applications make use of the secondary database? How current does the data have to be in order to support inquiry applications? What response time or database access performance is required to support the inquiry applications? Some Guidelines Some guidelines regarding freeing primary host resources are as follows: Moving real-time applications to a Remote Database Backup secondary host is questionable if the applications access very volatile data and have strict response time requirements. A reasonable expectation is to offload batch reporting against a database. Establishing Performance Requirements Introduction Establishing your performance requirements for Remote Database Backup enables you to

55 Selecting Remote Database Backup Options and System Resources for Your Goals Identify tradeoffs between requirements. For example, Level of synchronization compared with the possibility of data loss Impact on your primary host performance compared with the expense of purchasing a larger processor Identify the balance of requirements that best serves your business. Characteristics of Your Requirements Your performance requirements should be Verifiable Absolute You should convert relative or estimated requirements to absolute requirements. Identified as legal or self-imposed You should distinguish between regulations over which you have no control and requirements that you create and control. Prioritized or phased, if necessary Examples of Requirements Depending on your goals, examples of performance requirements that you should establish include Maximum acceptable disaster data loss Maximum acceptable time to restore applications Desired audit synchronization Least acceptable audit synchronization Desired database synchronization Least acceptable database synchronization Acceptable impact on the primary database Acceptable secondary database performance Selecting Audit Transmission Modes to Meet Your Goals Introduction Your main Remote Database Backup configuration decision is whether to transfer audits using the audit block transfer mode or an audit file transfer mode. The goals you establish for Remote Database Backup can guide you in making these decisions

56 Selecting Remote Database Backup Options and System Resources for Your Goals If you select ABW, the audit block transfer mode, you also need to select an error-handling option and a port-i/o timeout value. Mode Options for Disaster Recovery In general, one of the audit transmission modes should provide sufficient audit synchronization to meet your disaster recovery requirements: If you require high levels of audit synchronization for optimal resumption of database access following a disruption, you require ABW mode. If lower levels of audit synchronization are acceptable, then consider the following situations and choices of audit transmission mode: - If your network and system resources are sufficient to support immediate transfer and processing of the audit files on the secondary host, then the AFS mode is the most convenient mode. - If your resources are insufficient to support immediate transfer and processing of the audit files, then using the SCA mode enables you to stagger the transfer of files and allows the use of an alternative file transfer utility. - If a network does not exist, or if using a network for Remote Database Backup communication is not desirable, the NSC mode is recommended. Error-Handling Options of the ABW Mode An error is an interruption in audit transmission. As you choose an error-handling option, consider that the effects of the error-handling options are as follows: The Drop option protects primary host performance, but might introduce a temporary loss of audit trail synchronization. The Operator option provides flexibility but can be disruptive because all database activity is suspended until you respond. If you choose Operator, consider using System Assistant to automate the response this option requires. Port-I/O Timeout Value The port-i/o timeout value limits the impact of network and secondary host interruptions because it designates the length of time that the Remote Database Backup software waits for an acknowledgment of an audit transmission before terminating the attempted audit transmission. The port-i/o timeout value is not a solution for performance problems. The value is especially important if the secondary host or the network processing is slower than the primary database processing. In general, High values act as a flow control. They slow the primary database to match the limit of the network or secondary host processing. Low values protect primary database performance but can result in a loss of audit trail synchronization

57 Selecting Remote Database Backup Options and System Resources for Your Goals Related Information Topics For information about... Refer to... Audit transmission modes Sections 1, 2, 4, and 5 Error-handling options for ABW mode Sections 2, 4, and 5 Mode impact on resources Section 2 Port-I/O timeout value Section 4 Describing Your Resources Introduction Describing your environment is a necessary part of matching your resources to your goals and performance requirements for Remote Database Backup. Appendix B contains sample forms to help you assemble resource descriptions. System Resource Descriptions The descriptions of your systems should include the following items and any other descriptive information you think is pertinent to your existing or planned-for systems: Network node name Site location Style, model Memory Database disk configuration Communications processors Descriptions of Databases Requiring Remote Backup The descriptions of the databases for which you want to configure a Remote Database Backup system should include the following items and any other descriptive information you think is pertinent to your existing or planned-for databases: Database name Primary host Secondary host DASDL options DASDL parameters Application Descriptions

58 Selecting Remote Database Backup Options and System Resources for Your Goals Grouping your applications can help you get an overall picture of the applications you need to support. Group your applications as follows: A list under the host on which the application runs primary or secondary Under each host, separate groupings of database and nondatabase applications Under the database and nondatabase categories, separate groupings of - Critical update and report applications essential applications that must be reactivated immediately after any interruption in data availability - Noncritical update and report applications applications that do not need to be continued on the secondary host or transferred from the primary host following a failure at the primary host Outline of Application Groups Following is an outline that shows how you can organize the groupings just described. Primary Host Applications Database - Critical update - Critical report - Noncritical update - Noncritical report Nondatabase - Critical - Noncritical Secondary Host Nondatabase Applications Critical Noncritical Network Description The descriptions of your network processors and links that connect the primary and secondary hosts in your Remote Database Backup system should include hardware styles, the number of links and their types, and link and communications processor utilization levels for your existing and planned-for network equipment. This information should be obtained from your network administrator or product support representative. Keep in mind that the networking resources available in a disaster recovery situation might be different from those available under normal operating conditions, and that the maximum audit transmission rate attainable is limited by the slowest, least available network component

59 Selecting Remote Database Backup Options and System Resources for Your Goals Introduction to Gathering Data to Calculate Utilization Guidelines To determine whether your resources can handle your requirements, you need to assemble information about their current utilization and then estimate the additional utilization that Remote Database Backup requires. In general, for each utilization factor that requires measurement, you should identify a peak value and an average value. If your utilization information indicates extended periods of high or low activity, you should determine several sets of average and peak utilization statistics. You have selected the audit transmission mode under which you want to run Remote Database Backup. You need to follow one set of instructions through to the end of your data-gathering effort. Follow either the instructions for ABW mode or the instructions for the AFS, SCA, and NSC modes. Basic Calculations That Are Needed Calculations of utilization are necessary for the following categories of resources: Network components Host processors Secondary host processor for two roles: the backup role and the primary host role after a takeover is performed Calculations for the Simplest Case The simplest case a single database being backed up and the primary and secondary hosts are of comparable models and capacities is sufficient to demonstrate the principles and calculations of the data gathering process. Therefore, the procedures in the remainder of this section reflect Remote Database Backup planning for a single database. Additional Calculations for More Complex Situations In a more complex situation involving several databases or dissimilar hosts, additional considerations and calculations might apply: An estimate of the utilization on one host based on measurements from the other To estimate host B utilization from host A measurements, multiply the host A measurements by the ratio of a host B performance index to a comparable host A performance index. Measured or estimated performance indexes are available for most configurations from your product support representative. Effect of multiple databases that are to run under Remote Database Backup If you are dealing with multiple databases running under Remote Database Backup,

60 Selecting Remote Database Backup Options and System Resources for Your Goals then measurements of peak, average, and slack utilization for the host must reflect the combined peak, average, and slack utilization for all individual databases. Depending on the levels of database activity that actually occur at the same time, you need total measurements from concurrent activities to determine these values. You do not necessarily determine the combined peak utilization by adding the peak values of the individual databases unless these peak utilization periods actually occur at the same time. A Two-Step Process Introduction When you gather utilization data, you perform two processes: Gathering data about existing utilization for the following entities: - Each network component that is to handle Remote Database Backup data comm traffic A network component utilization rate is often expressed as a percentage of the total capacity of the component. - The primary and secondary hosts Host utilization is expressed as the total percentage of database and nondatabase program use of processor time. Gathering data about future utilization when you add Remote Database Backup You tailor this process to the audit transmission mode under which you intend to run Remote Database Backup. For any mode, part of this process requires that you obtain from your product support representative the current performance statistics about network and host utilization under Remote Database Backup. Measuring Tools Some of the tools you use to measure utilization data provide the information necessary for several calculation or estimation procedures. For example, the report of the AUDIT ANALYZE AFN command provides you with an audit generation rate in bits per second that you can use for network sizing. The report also provides the raw percentages of host processor utilization for the applications for which the audit file was generated. For explanations of the tools you can use to measure utilization data, refer to Appendix C. Recording Utilization Data You should systematically record the utilization data that you measure so that you can arrive at meaningful totals for your network components and host processors. After performing the calculation or estimation procedures explained in this section, you need to record your data in a way that makes sense in your setting. Record your data in a simple but efficient way so that you can gain a meaningful picture of your resources

61 Selecting Remote Database Backup Options and System Resources for Your Goals Appendix B provides some forms on which you can record descriptive and summary information. Use these forms if you find them helpful. The procedures that are explained later in this section reference the forms in Appendix B where appropriate. General Impact of Remote Database Backup on Existing Resource Utilization Introduction The addition of Remote Database Backup for a database involves the database itself and the applications associated with the database. Existing nondatabase application utilization is not changed but must still be considered. Impact of Remote Database Backup on the Network If you have a network connection between the hosts that are to be the primary and secondary hosts, the impact of Remote Database Backup depends on the audit transmission mode under which you plan to operate Remote Database Backup. ABW mode adds constant audit block transmission traffic while audits are being generated. AFS mode adds intermittent traffic when each audit file is closed and transferred to the secondary host. SCA and NSC modes add traffic only if the network is used for copying audit files to the secondary host. If tapes are used to transfer audit information, these modes do not impact the network. Impact of Remote Database Backup on the Primary Host The only impact on the primary host results from The need to transfer audit information from the primary host to the secondary host The relocation of any inquiry or report applications from the primary host to the secondary host after Remote Database Backup is operating, or the relocation of any Enterprise Database Server utility functions, such as database backups Impact of Remote Database Backup on the Secondary Host Additional processor utilization on the secondary host can result from The need to update the Remote Database Backup secondary database according to the audits received The values in the DMS UPDATE column of the AUDIT ANALYZE AFN command report for the primary database approximate this utilization (refer to Appendix C). Any relocation of inquiry or report applications from the primary host to the secondary host after Remote Database Backup is operating, or the relocation of any Enterprise Database Server utility functions, such as database backups

62 Selecting Remote Database Backup Options and System Resources for Your Goals If you are not able to obtain individual program utilization statistics for these inquiry or report programs, you need to estimate a value. Since some portion of the DMS INQUIRY processor utilization value results from update programs, you should estimate the part of this percentage that actually results from the programs you plan to move. You also need to estimate the part of the NON DMS processing that applies. The DMS INQUIRY and NON DMS processing values are provided in the report of the AUDIT ANALYZE AFN command. Gathering Data on Existing Network Utilization Measuring Existing Network Utilization To measure your existing network utilization, your network administrator or product support representative can assess the current utilization of your existing network components and perform the estimates necessary for components you need to obtain. Also, when measuring existing network utilization, test every component in your network and measure existing utilization of the component as a percentage of the total capacity of the component. Whoever gathers your existing network utilization data should record data for later use when you are measuring or estimating utilization with Remote Database Backup. The Network Description Form in Appendix B is a suitable recording form. Related Information Topics For information about... Refer to... Network Description Form Appendix B Gathering Data on Future Network Utilization with Remote Database Backup General Capacity Planning Guidelines For planning purposes, links and communications processors should not be configured for more than 80 percent utilization. Network links Network Component Communications processors Recommended Utilization 80 percent of the signaling rate 80 percent of processor utilization

63 Selecting Remote Database Backup Options and System Resources for Your Goals Example The signaling rate of a T1 line is 1.54 megabits per second (Mbps) or megabytes per second (MBps). The MBps value is determined by dividing 1.54 by 8. Suppose the existing utilization of a T1 link is 50 percent, and you want to know if the link can support an additional MBps. The value MBps represents 26 percent of additional utilization: / = The new utilization would be 76 percent (50 percent of existing utilization plus an additional 26 percent). Since this value is less than 80 percent, the link should be able to handle the additional utilization for Remote Database Backup. Preliminary Measurements The Remote Database Backup processes that impact your existing network resources are Transmission of audits between the primary and secondary hosts Acknowledgment of audit blocks or files Therefore, before you gather data on future network utilization with Remote Database Backup, you need to identify Values for the audit generation characteristics for the audit transmission mode under which you plan to run Remote Database Backup - ABW mode - AFS, SCA, NSC, or AFM mode Current communications processor utilization values Preliminary Measurements for the ABW Mode Introduction To ensure that you have sufficient network resources to run Remote Database Backup under the ABW mode, you need to determine the audit transmission rate for each database that is to run under Remote Database Backup. You need the audit transmission rates calculated in Bytes per second (for link utilization) Messages per second (for communications processor utilization) You use these values in subsequent procedures for estimating network utilization with Remote Database Backup operating under the ABW mode

64 Selecting Remote Database Backup Options and System Resources for Your Goals Calculating the Audit Generation Rate in Bytes per Second Calculate the audit generation rate in bytes per second for each time interval that reflects peak, average, or other unique periods of audit generation in your environment. To calculate the audit generation rate in bytes per second, perform the following procedure for the time intervals you have designated. Step Action 1 Use the AUDIT PROCESSOR TIMES ON command to initialize the collection of statistical data, and allow a specified time interval to elapse. 2 Run the AUDIT ANALYZE AFN command on an audit file that was created after the AUDIT PROCESSOR TIMES ON command was issued. 3 From the report generated in step 2, identify the audit generation rate in bits per second. 4 To obtain the audit generation rate in bytes per second, use the following formula: <audit generation rate in bits per second> / 8 = <bytes per second> Record the result on the Audit Generation Rate Form (see Appendix B). 5 Repeat steps 1 through 4 for each time interval for which you are keeping records. 6 When you no longer need to collect statistical data, use the AUDIT PROCESSOR TIMES OFF command to end the collection of statistical data. Calculating the Audit Generation Rate in Messages per Second You must determine the messages per second value by first identifying the average block size from the Enterprise Database Server Statistics report and then using this value to calculate an optimal message size a size that is probably larger than the simple average block size. If you rank all audit blocks according to size, the optimal message size is large enough to hold any of the audit blocks in the bottom 80 percent of the ranking. The actual block size varies and is determined by Enterprise Database Server. To calculate the audit generation rate in messages per second, perform the following procedure. Step Action 1 Run Enterprise Database Server Statistics and identify the average block size in words from the Statistics report

65 Selecting Remote Database Backup Options and System Resources for Your Goals Step Action 2 To convert the average audit block size from words to bytes, use the following formula: <audit block size in words> x 6 = <audit block size in bytes> 3 To calculate the messages per second, use the following formula: <bytes per second> / <average block size> = <messages per second> Bytes per second is the result of the procedure under the heading Calculating the Audit Generation Rate in Bytes per Second earlier in this section. Record the result on the Audit Generation Rate Form (see Appendix B). 4 Repeat steps 1 through 3 for each time interval for which you are keeping records. To calculate the optimal message size, perform either of the following tasks. Task A results in a value that is more accurate than the value resulting from task B, but is more difficult to calculate. You can use either value as the optimal message size. Task A Rank the sizes of generated audit blocks by running the PRINTAUDIT program (refer to Appendix C), and identify the size that is large enough to hold any of the audit blocks in the bottom 80 percent of the ranking. Task B Use the following formula: <average block size> x 1.5 = <optimal message size> Preliminary Measurements for the AFS, SCA, and NSC Modes Introduction The audit characteristics you need to measure for the audit file transmission modes depend on whether you plan to use a network to transfer audit files. If you plan to use tape to transfer audit files under the SCA or NSC mode, no measurements are necessary. If you plan to run Remote Database Backup under the AFS mode, or if you plan to use a network under the SCA or NSC mode, your calculations depend on whether you - Have hosts and a network available for testing - Use NFT or FTRapid as the file transfer product if you re using BNA If the hosts and a network are not available for testing, you must measure the audit generation rate and then estimate the utilization

66 Selecting Remote Database Backup Options and System Resources for Your Goals To ensure that you have sufficient network resources to run Remote Database Backup under one of the audit file transmission modes, you need to determine the audit generation rate for each database that is to run under Remote Database Backup. You need the audit generation rates calculated in Bytes per second (for link utilization) Messages per second (for communications processor utilization) You use these values in subsequent procedures for estimating network utilization with Remote Database Backup operating under the AFS, SCA, or NSC mode. If the hosts and a network are available for testing, you measure both the audit generation rate and the network and host processor utilization. It is usually sufficient to measure audit generation rate in terms of units such as number of audit files per hour or day. Calculating the Audit Generation Rate in Bytes per Second To calculate the audit generation rate in bytes per second, perform the following procedure. Express your results as a rate such as files per day or files per hour. Step Action 1 Identify the number of bytes per audit file based on the file attributes of the audit file. 2 For a specific time period, count the number of complete audit files contained in the system summary log (SUMLOG). You can calculate a value for one day, or you can calculate values for several shorter periods to obtain a more detailed set of averages. 3 To obtain the number of bytes per time period, use the following formula: <number of bytes per audit file> x <number of complete audit files> = <bytes per time period> 4 To obtain the utilization value in bytes per second, perform the following calculations: 1. Convert the time period into seconds. 2. Calculate the following formula: <bytes per time period> / <seconds> = <bytes per second> Record the result on the Audit Generation Rate Form (see Appendix B). 5 Repeat steps 1 through 4 for each time interval for which you are keeping records

67 Selecting Remote Database Backup Options and System Resources for Your Goals Calculating the Audit Generation Rate in Messages per Second The message size for the AFS, SCA, or NSC mode is the message size of the file transfer product you use. For the AFS mode with BNA, you can use either the NFT or FTRapid product. For the AFS mode with TCP/IP, FTP will be used. For the SCA and NSC modes, you can use NFT, FTRapid, FTP, or any other compatible file transfer product. To calculate the audit generation rate in messages per second, perform the following procedure. Step Action 1 To obtain the messages per second, use the following formula: <bytes per second> / <message size> = <messages per second> The message size is that of NFT, FTRapid, FTP, or any other compatible file transfer product you use. The bytes per second value is the result obtained from the preceding procedure. Record the result on the Audit Generation Rate Form (see Appendix B). 2 Perform step 1 for the time periods for which you are keeping records. Related Information Topics For information about... Refer to... AUDIT ANALYZE AFN command AUDIT PROCESSOR TIMES command Count of audit files Enterprise Database Server statistics PRINTAUDIT program Appendix C of this manual Enterprise Database Server Utilities Operations Guide Appendix C of this manual Enterprise Database Server Utilities Operations Guide Appendix C of this manual Enterprise Database Server Utilities Operations Guide Appendix C of this manual Enterprise Database Sever Utilities Operations Guide Appendix C of this manual Enterprise Database Server Utilities Operations Guide

68 Selecting Remote Database Backup Options and System Resources for Your Goals Obtaining Communications Processor Utilization Statistics To proceed with estimating future utilization of your communications processors under Remote Database Backup, ask your network administrator to provide the current performance ratings for the network components of your system configuration. Performance statistics for communications processors are subject to change as new options, new products, or new data becomes available. For BNA performance statistics, contact your Unisys representative. In most cases, utilization statistics vary depending on whether your BNA network parameters are optimal or default. Estimating Future Network Utilization for ABW Mode The network must support the peak audit generation rate. For each component you identified in your network description, you must determine that the component can transfer data at the peak audit generation rate without exceeding 80 percent utilization. To estimate the network utilization for Remote Database Backup audit block transfer, you need to Obtain from your network administrator or product support representative the current performance statistics for the configuration, communications processors, and errorhandling option you plan to use. Add the Remote Database Backup audit generation rate to current network utilization to actually estimate the network capacity. The maximum audit transmission rate attainable is limited by the slowest, least available network component. Therefore, all link and communications processor utilization levels need to be analyzed to determine whether the network can support the transfer rate you require. Determining Future Network Utilization for AFS, SCA, and NSC Modes For the AFS mode, and for the SCA and NSC modes if you plan to use a network for file transfer, you must verify whether the volume of audit information produced can be transferred to the secondary host within the time available. The time available varies depending on your performance requirements for Remote Database Backup. In general, however, you should expect to complete the transfer of a day s audit data during a 24-hour period. Otherwise, the secondary host might not be a viable resource for disaster recovery or inquiry purposes. The transfer rate, therefore, must be at least high enough to transfer the audits for one day during that day. The network utilization for Remote Database Backup audit transfer and therefore the transfer rate is the same as for any file transfer. You determine the rate from the following characteristics of the file transfer process:

69 Selecting Remote Database Backup Options and System Resources for Your Goals Power of the host processors Available capacity of the host processors Available capacity of the network links and hardware Speed of the file transfer product If the Remote Database Backup hosts and a network already exist, you can measure the transfer rate for Remote Database Backup by copying the actual files and measuring the transfer rate and utilization. Otherwise, you must estimate these values. Measuring the Network Utilization Rate Make your measurements under appropriate combinations of network and system utilization so that your results reflect the actual operation of Remote Database Backup. Explore the result of running multiple copy jobs concurrently if the occurrence of multiple copy jobs is a probability during your normal operations. To measure the audit transfer rate, perform the following procedure. Step Action 1 Copy audit files from the proposed primary host to the secondary host, and note the following values during the copy job: Elapsed time Network utilization Processor utilization 2 To obtain the audit transfer rate, use the following formula: <number of files copied> / <elapsed time> = <audit transfer rate> If your transfer rate is greater than the audit generation rate, or if the transfer rate is sufficient to complete the copy jobs within the time period dictated by your Remote Database Backup performance requirements, then the network capacity might be sufficient. To be certain that the network capacity is sufficient, however, you also need to verify that the host processor utilization required to copy at your test rate will be available during actual Remote Database Backup operation. Estimating Future Communications Processor Utilization To estimate the utilization of a communications processor, provide to your network administrator your average audit block size and ask how much audit information the network can transfer in a given time period

70 Selecting Remote Database Backup Options and System Resources for Your Goals Gathering Data on Host Processor Utilization To determine future host processor utilization with Remote Database Backup, you need to begin with the total percentage of existing processor utilization for the primary and secondary hosts. Then you need to establish An increment for Remote Database Backup audit transmission An increment for Remote Database Backup audit application to the secondary database The existing utilization for any application programs that you plan to relocate from the primary to the secondary host For the secondary host, calculations for backup purposes and for the purpose of assuming the role of the primary host after a takeover Gathering Data on Existing Host Processor Utilization To measure your primary host processor activity, perform the following procedure for each time interval for which you are keeping records. Step Action 1 For each database application program during a specific time period, identify the following values from the reports of the AUDIT PROCESSOR TIMES and AUDIT ANALYZE AFN commands: DMS INQUIRY percentage DMS UPDATE percentage NON DMS processor percentage 2 To determine the percentage of processor utilization for database application programs for the time period, use the following formula: <DMS INQUIRY percentage> + <DMS UPDATE percentage> + <NON DMS processor percentage> = <total database utilization for the period> Record the total database utilization on the Applications Activity Form (see Appendix B) for the time period. 3 To calculate processor utilization for critical and noncritical nondatabase applications, run the TeamQuest SMFII product or a similar tool against each application. Use the same time period used for database applications. 4 Calculate the total nondatabase utilization for the primary host by adding together the application utilization for each application. Record the total nondatabase utilization on the Applications Activity Form for the time period

71 Selecting Remote Database Backup Options and System Resources for Your Goals Step Action 5 To obtain a total for all utilization of the primary host, use the following formula: <total database utilization> + <total nondatabase utilization> = <total utilization> Record the total utilization on the Applications Activity Form for the time period. To measure your secondary host processor activity, perform the following procedure. Step Action 1 To calculate processor utilization for critical and noncritical nondatabase secondary host applications, run the TeamQuest SMFII product or a similar tool against each application. Use the same time period used in the preceding procedure for the primary host. 2 Calculate the total nondatabase utilization for the secondary host by adding together the application utilization for each application. Record the total utilization on the Applications Activity Form for the time period. Calculating the Total Secondary Host Processor Utilization Secondary Host for the Purpose of Remote Backup You can use the figures reported in the DMS INQUIRY and NON DMS columns in the AUDIT ANALYZE AFN report to estimate the increase in secondary host processor requirements that can result from inquiry or report applications being moved from the primary host. However, as you calculate your estimates, keep in mind that these reported values also include any update application processor time. Most update applications perform a modest amount of application code and inquiry functions in order to establish the validity of a transaction. To compute secondary host utilization as a backup system with Remote Database Backup, perform the following procedure for each time interval for which you are keeping records. Step Action 1 Begin with the existing secondary host utilization for the time interval. 2 Identify the increment for Remote Database Backup audit transfer for the time interval. The value of this increment is the result of your estimate for future primary host processor utilization for the mode under which Remote Database Backup is to operate

72 Selecting Remote Database Backup Options and System Resources for Your Goals Step Action 3 Identify the increment for Remote Database Backup audit processing for the time interval by performing one of the following actions: Run a rebuild/recovery operation on the database. During the operation, determine the time interval required for the application of audit images to the database. This time interval roughly equals the time required for Remote Database Backup to apply audit images to the secondary database. Identify the value from the DMS UPDATE column of the report you generated earlier by running the AUDIT PROCESSOR TIMES and AUDIT ANALYZE AFN commands. 4 Identify the utilization for any programs being moved to the secondary host. The utilization is the same as the total utilization for the program on the primary host. 5 To calculate the total utilization for the secondary host, use the following formula: <audit transfer increment> + <audit processing increment> + <utilization for moved programs> = <total utilization for the secondary host> Record the total utilization value on the Applications Activity Form (see Appendix B). 6 Ensure that the result from step 5 is less than 100 percent of capacity by a reasonable margin. 7 Repeat steps 1 through 6 for the time intervals for which you are keeping records. Secondary Host for the Purpose of Taking Over the Primary Host Role When you use the secondary host to assume the role of the primary host after a takeover, you should consider the following factors: Possible difference in audit transfer rate The increment for Remote Database Backup audit transfer can be somewhat smaller than for normal operation. The smaller size is due to the difference between the audit generation rate of the critical applications assumed by the original secondary and the audit generation rate of all database applications normally running on the original primary host. Possible effect of the change in direction of the audit transfer If you use a full duplex line such as a T1 line, then consider the line utilization in each direction. Such a consideration is warranted if the network traffic is normally heavier from the original secondary host to the original primary host. After a takeover, Remote Database Backup traffic will be competing with the normally heavier volume in that direction. To compute secondary host utilization for the purpose of taking over the role of the primary host, perform the following procedure

73 Selecting Remote Database Backup Options and System Resources for Your Goals Step Action 1 Begin with the existing critical secondary host utilization. 2 Identify the total of all critical processing that must be assumed from the failed primary host. This value is the total utilization for all critical database applications on the primary host. 3 Identify an increment for Remote Database Backup audit transfer. The value of this increment is the result of your estimate for future primary host processor utilization for the mode under which Remote Database Backup is to operate. 4 To calculate the total utilization for the secondary host when it takes on the role of the primary host, use the following formula: <primary host critical processing > + <audit transfer increment> = <total utilization for the secondary host> Record the total utilization value on the Applications Activity Form (see Appendix B). 5 Ensure that the result from step 4 is less than 100 percent of capacity by a reasonable margin. The Next Step Preparing to Configure a Remote Database Backup System Once you have settled on a hardware and software configuration that fulfills the requirements of the Remote Database Backup system or systems you plan to operate, you need to ensure that certain areas of your database setup for example, installation, security, usercode and pack designations, and database definitions are compatible with, and not obstacles to, the smooth running of a Remote Database Backup system. Two major characteristics of a Remote Database Backup system are that the same database is to run on two hosts and that it is probable that these hosts will exchange roles at some time. Therefore, it is important to ensure that the Remote Database Backup software can find the files it needs on both hosts and that the privileges under which the Remote Database Backup software runs on one host are extended to the other host. Otherwise, you might experience costly interruptions in Remote Database Backup operation that could have been avoided with advance preparations. The necessary preparations constitute a fine-tuning in certain areas of your database definition and functioning. These preparations are explained in Section

74 Selecting Remote Database Backup Options and System Resources for Your Goals

75 Section 4 Preparing to Configure a Remote Database Backup System In This Section This section contains instructions for preparing to configure a Remote Database Backup system. The instructions include the following topics: Overview of preparation tasks Checking on the Remote Database Backup installation Understanding Remote Database Backup software Understanding how Remote Database Backup uses port files Understanding more about the ABW mode Integrating Remote Database Backup into your security setup Preparing personnel to run the Remote Database Backup system Reviewing DASDL source files Designating usercodes and packs Ensuring database file availability on the secondary host I/O timeout value for the ports Influencing Tracker performance Overview of Preparation Tasks The Tasks At this time, you might be preparing to install your Remote Database Backup software or you might have already installed it. In either case, you should check that your environment includes the hardware and software required to configure and run a Remote Database Backup system. Once you have ensured that your equipment and software meet your proposed Remote Database Backup requirements, and once you have installed the Remote Database Backup software, you are ready to prepare for the next major step configuring a Remote Database Backup system for your database

76 Preparing to Configure a Remote Database Backup System You can use the list of tasks on the previous page as a checklist of the areas of database setup that you need to consider for possible changes prior to configuring your Remote Database Backup system. One task is to understand how Remote Database Backup software components work together and with other database software. The actual changes to your ordinary database setup might be minimal, but you should understand the rationale for the changes the requirements of Remote Database Backup functioning. Advantages of Preparation Careful preparation for configuring your Remote Database Backup system minimizes the risk of costly interruptions and provides you with the following advantages: A clear idea of what Remote Database Backup can do for you and confidence that Remote Database Backup will fulfill your expectations Optimal use of your host resources Personnel who are trained in Remote Database Backup and knowledgeable about your recovery strategies Workable processes for round-the-clock Remote Database Backup operation A security arrangement that gives your data the best practical protection A solid plan from which to monitor, manage, and modify the Remote Database Backup system Checking on the Remote Database Backup Installation Remote Database Backup Installation Checklist Before you install Remote Database Backup, ensure that your setup meets the basic requirements in the following list. If you have already installed Remote Database Backup, check the requirements to be sure you have not overlooked anything. Caution To prevent the loss or corruption of files, observe proper backup procedures before beginning a software installation. To prevent interruptions to system and user activity, ensure that files residing on disk that might be affected by the installation are not in use

77 Preparing to Configure a Remote Database Backup System Check to see that you have A version of Enterprise Database Server software that is the same release level as the Remote Database Backup software Two enterprise server hosts, each with the necessary MCP Communications processor equipment to enable you to switch between hosts Sufficient disk and memory capacity on each host for your database needs Network capability (unless you use manual audit transfer exclusively) An audited database that uses Enterprise Database Server for management of all physical files (including Enterprise Database Server databases) Files Installed with Remote Database Backup The following table lists the files that should be present on the primary and secondary hosts after Remote Database Backup installation procedures are complete. (For installation instructions, refer to the Enterprise Database Server Getting Started and Installation Guide). Use the SL (Support Library) system command to ensure that each function listed in the table is equated to its corresponding file. File Name Function Name Description SYSTEM/RDBSUPPORT SYSTEM/RDBSERVER SYSTEM/DBCENTER/SERVER SYSTEM/DOCSUPPORT RDBSUPPORT N/A N/A DOCSUPPORT Code files that provide the Remote Database Backup functions Files that provide the data and messages for the Database Operations Center Caution An accidental DS of the Remote Database Backup support library can result in all linked database systems becoming hung. To prevent an accidental DS of the Remote Database Backup support library, it is recommended that you execute the MP system command with the + LOCKED option. An example of using this command is MP *SYSTEM/RDBSUPPORT ON DISK + LOCKED The effects of this procedure are documented in the System Commands Reference

78 Preparing to Configure a Remote Database Backup System Verifying the Installation Before you attempt to configure your Remote Database Backup system, you should verify the software installation using the following table as a guide. What to Verify The Remote Database Backup files are installed on the correct disk families and under the appropriate usercodes. The Remote Database Backup files have the correct release level. The Remote Database Backup system is established. Ways to Verify Review the Simple Installation report, which is a print request available at the completion of the Simple Installation WFL job. Run the Simple Installation menu mode CHECK function. Execute the PD (Print Directory) system command or the CANDE LFILES command. Execute the SL (Support Library) system command for the RDBSUPPORT library. Preparing to Use TCP/IP Verifying the DSS Installation In a TCP/IP-only environment (without BNA), Host Services is not available to perform remote tasking. Therefore, the SYSTEM/RDBSUPPORT library is configured as a Distributed System Service (DSS) in order to initiate the RDB server task at the remote host. The default port number is 2556, but it can be changed. Enter the following system commands to verify the DSS installation. The result displayed should match the text below each command. NA REG SHOW EP RDBEP Endpoint Name: RDBEP, Public Endpoint: TRUE Filename: RDBSP, Applicationgroup: Myname: "2556" NA REG SHOW DSS RDBDSS DSSname: RDBDSS, Class: OTHER Recovery after Halt/Load: FALSE, Initialize DSS: TRUE Endpoints: RDBEP NA REG SHOW PROV RDBSUPPORT Provider name: RDBSUPPORT, Task type: NonMonitoredSupportLibrary Interface: Message SL: RDBSUPPORT

79 Preparing to Configure a Remote Database Backup System DSSes provided: RDBDSS If any of the DSS entities are missing, use one of the following commands to create them. NA REG ADD EP RDBEP FILENAME=RDBSP, MYNAME="2556", PUBLIC = TRUE NA REG ADD DSS RDBDSS ENDPOINT=(RDBEP), CLASS=OTHER, INITIALIZE=TRUE NA REG ADD PROV RDBSUPPORT DSS=(RDBDSS), SL=RDBSUPPORT, TYPE=NMSL, INTERFACE=MESSAGE If a DSS entity exists but has incorrect values, delete it using one of the following system commands and then recreate it. NA REG DEL PROV RDBSUPPORT NA REG DEL DSS RDBDSS NA REG DEL EP RDBEP Running Multiple Versions of Enterprise Database Server If you are running multiple versions of Enterprise Database Server but only one version uses TCP/IP, if that version uses a non-standard RDBSUPPORT SL name, use the following command to modify the DSS configuration: NA REG MODIFY PROV RDBSUPPORT SL=<RDBSUPPORT SL name> If you are running multiple versions of Enterprise Database Server that use TCP/IP, each version will require its own DSS configuration. Use the following commands to configure the DSS connection for alternate versions. NA REG ADD EP <endpoint name> FILENAME=RDBSP, MYNAME="<port number>", PUBLIC = TRUE NA REG ADD DSS <DSS name> ENDPOINT=(<endpoint name>), CLASS=OTHER, INITIALIZE=TRUE NA REG ADD PROV <provider name> DSS=(<DSS name>), SL=<RDBSUPPORT SL name>, TYPE=NMSL,INTERFACE=MESSAGE You can copy the preceding commands to a ClearPath MCP sequential data file and load them using the following command: NA LOAD <file title> See the section describing how to change the port number for instructions on how to configure the RDB support library to use the port number specified in the command above

80 Preparing to Configure a Remote Database Backup System Providing a Queue for Remote Database Backup-Related Tasks Remote Database Backup automatically creates, at run time, the required WFL job for initiating processes on the remote host. For RDB server and all related tasks to run unimpeded, you must ensure that a queue exists to handle the tasks by either: Checking that the attributes of the default queue on the remote host do not prevent Remote Database Backup processes from running correctly. For example, if the mix limit for the default queue is set to 0 (zero), no Remote Database Backup processes can run on the remote host. Configuring and specifying a queue other than the default queue to handle all Remote Database Backup tasks. You can use the MARC screens to check queue numbers and the attributes associated with them. To specify a queue other than the default queue, use a WFL statement with the following syntax at the remote host: WFL MODIFY *SYSTEM/RDBSUPPORT; TASKSTRING = <queue number> Ensure that you specify a valid queue number. Otherwise, the RDB server task does not run. Next, prepare the RDB support library using the Support Library (SL) system command. The syntax is as follows: SL RDBSUPPORT = *SYSTEM/RDBSUPPORT ON DISK Securing Credentials for TCP/IP When configuring a database to use RDB with the TCP/IP network service, a usercode and password must be identified for each host. These credentials are assigned to the RDB server task and are used by FTP. Each password is obscured before being stored in the RDB control file. If Security Center is installed on both hosts, the passwords can be encrypted. You must access Security Center to create a key container with an RSA key on the primary host and then import it on the secondary host. All of the databases on a host can share the same key container. When creating a key container with an RSA key The names entered for Application and Service will be concatenated to form the key container name. Enter RDBSUPPORT as the Usercode. The recommended Key Strength is It is not necessary to create a certificate request. After the key is created, export it and copy the resulting file to the secondary host. Then access the Security Center at the secondary host and import the key

81 Preparing to Configure a Remote Database Backup System If a key container is not provided, the passwords will be obscured using a process similar to the one used by DATAMASK. Standard FTP exposes the password on the wire. Secure FTP can be used to secure the logon but it requires configuring SSL and certificates on both hosts. Therefore, using secure FTP is optional. Unsecured FTP is used by default. See the topic, Changing to Secure FTP later in this section for instructions on how to change to secure FTP. Preparing FTP Depending on the system settings, code files that are copied by FTP to the secondary host may be copied as restricted making them unusable. This will affect the DMSUPPORT, RECONSTRUCT and DESCRIPTION files that are copied during the clone and reorganization processes. To avoid this problem, some steps might need to be executed by a security administrator. Whether or not the files are restricted depends on two options, the system security RESTRICTUNWRAP option and the FTP RESTRICTED option. The setting for the RESTRICTUNWRAP option can be viewed with the SECOPT system command. The setting for the RESTRICTED option can be found in the LIBRARY section of the FTP global configuration file. If the RESTRICTUNWRAP option is not set, copied files will not be restricted and no special steps are required. If the RESTRICTUNWRAP option is set, then: If the RESTRICTED option is set, copied files will be restricted unconditionally and cannot be used. One of these options must be changed or some other method of copying code files during the clone and reorganization processes must be used. If the RESTRICTED option is not set, files must be copied by a security administrator to avoid being restricted. On a system on which security-administrator status has been authorized, this must be under a usercode designated as SECADMIN. Otherwise, it must simply be under a privileged usercode. To avoid problems during the clone and reorganization processes, when you initialize the remote auditing capability in the Database Operations Center and select TCP/IP as the network service, ensure that the credentials you provide are those of a security administrator. These credentials will be assigned to the RDBSERVER tasks and to all file transfers

82 Preparing to Configure a Remote Database Backup System If security administrator status is enabled for the system and you do not want to assign a SECADMIN usercode as the TCP/IP credentials for a database, some additional steps are required. - For cloning, create but do not start a WFL job as described in Section 5 under Selecting a Method of Running the Clone Operation. Edit the WFL job to use SECADMIN credentials on all file copy statements. Then start the clone WFL under a SECADMIN usercode. After the clone completes, be sure to secure the WFL file or edit it to remove the credentials. - For reorganizations, copy the necessary files as described in Section 9, Procedure to Manually Transfer Files. SECADMIN credentials must be used when copying the files. For more information about the RESTRICTED file attribute: see the File Attributes Programming Reference Manual. RESTRICTUNWRAP Security Option: see the Security Overview and Implementation Guide. RESTRICTED FTP option: see the TCP/IP Distributed Systems Services Operations Guide. Configuring an MCP Firewall If TCP/IP end system security (firewall) is running, rules must be set to allow the necessary TCP/IP connections. And, since communications are bi-directional, these rules must be set at both the primary and secondary hosts. For communications via the RDB support library DSS port to start a remote RDB server, allow: Port 2556 to/from ports at the IP address or subnet of the other host Ports to/from port 2556 at the IP address or subnet of the other host (This assumes the DSS port number has not been changed from the default of 2556.) For communications between the RDB support library and the RDB server to send audit and control information, allow ports to/from ports at the IP address or subnet of the other host. For information about: TCP/IP end system security: see the TCP/IP Installation and Operations Guide. FTP and firewalls: see the TCP/IP Distributed Systems Services Operations Guide. Configuration File A configuration file can be used to override the default DSS port number or to specify secure FTP instead of standard FTP. The RDBSUPPORT configuration file should be located on the same usercode and pack as the SYSTEM/RDBSUPPORT code file. If the file is not present, the default values are assumed

83 Preparing to Configure a Remote Database Backup System Note: Changing the values in the configuration file is only one step in the change process. Please read the full instructions for changing the DSS port number or changing the type of FTP before starting the process. An example of a configuration file is provided in SYSTEM/RDBSUPPORT/CONFIG/EXAMPLE. Its contents follow. % DMSII Remote Database Backup Configuration File % % This file is read by the RDBSUPPORT library % and these options apply to all databases % supported by that library. % % If an option is preceded by a percent sign, % the default value will be used. %DSS_PORT_NUMBER 2556 % default is 2556 %FTP_TYPE FTP % choices are FTP (default) or FTPS To create your own configuration file, copy the example file as SYSTEM/RDBSUPPORT/CONFIG. Remove the percent sign (%) preceding the option you want to change (DSS_PORT_NUMBER or FTP_TYPE) and then set the value you want. Use FTPS to specify secure FTP. The SYSTEM/RDBSUPPORT library reads the configuration file (if one exists) when it starts up. If it is already running, enter the following command using the mix number of the SYSTEM/RDBSUPPORT library to cause it to read a new or updated configuration file. <mix number>ax:reconfig Enter the following command to view the configuration values that are currently being used by a running RDBSUPPORT library. The values will be written to the sumlog. They are also logged each time the library starts up. <mix number>ax:show CONFIG Changing the DSS Port Number To change the DSS port number, perform the following steps at both hosts. 1. Enter the following system command. NA REG MODIFY EP RDBEP MYNAME = <new number> Note: MYNAME must be a TCP/IP port number unique to the system. Failure to choose a unique number could cause conflicts between different TCP/IP-based services

84 Preparing to Configure a Remote Database Backup System 2. Edit the configuration file, SYSTEM/RDBSUPPORT/CONFIG. If it does not exist, copy SYSTEM/RDBSUPPORT/CONFIG/EXAMPLE as SYSTEM/RDBSUPPORT/CONFIG. The RDBSUPPORT configuration file should be located on the same usercode and pack as the SYSTEM/RDBSUPPORT code file. Modify the following line to incorporate the new number. If the line is preceded by a percent sign (%), remove the percent sign. DSS_PORT_NUMBER <new number> % default is If the SYSTEM/RDBSUPPORT library is running, enter the following command using the mix number of the library to cause it to read the new value from the configuration file. <mix number>ax:reconfig If the library is not running, it is not necessary to enter this command. The library will pick up the new port number the next time it is run. Changing to Secure FTP By default, unsecure FTP is used to transfer files. Optionally, secure FTP may be used to secure the logon credentials so the password is not exposed on the wire. However, this requires that both hosts are configured to support SSL. Also, the following must be set in the LIBRARY section of the FTP global configuration file: USE_SSL_INTERFACE = <ALL is recommended, can use EXPLICIT> See the topic, Managing Secure File Transfer in the TCP/IP Distributed Systems Services Operations Guide for more information. Once SSL has been properly configured, perform the following steps at both hosts to configure RDB to secure the logon credentials. 1. Edit the configuration file, SYSTEM/RDBSUPPORT/CONFIG. If it does not exist, copy SYSTEM/RDBSUPPORT/CONFIG/EXAMPLE as SYSTEM/RDBSUPPORT/CONFIG. The RDBSUPPORT configuration file should be located on the same usercode and pack as the SYSTEM/RDBSUPPORT code file. On the following line, replace FTP with FTPS. If the line is preceded by a percent sign (%), remove the percent sign. FTP_TYPE FTP % choices are FTP (default) or FTPS 2. If the SYSTEM/RDBSUPPORT library is running, enter the following command using the mix number of the library to cause it to read the new value from the configuration file. <mix number>ax:reconfig If the library is not running, it is not necessary to enter this command. The library will pick up the new value the next time it is run

85 Preparing to Configure a Remote Database Backup System Preparations for Using a Nonusercoded Database with BNA Introduction When you establish a Remote Database Backup system for a nonusercoded database, Remote Database Backup-related tasks can be prevented from running unless you modify the RDB support library in two ways. For the modification procedure, refer to Modifying the RDB Support Library for a Nonusercoded Database later in this section. Providing a Queue for Remote Database Backup-Related Tasks The mechanism used to start processes on a remote host differs for usercoded and nonusercoded databases: For usercoded databases, processes are initiated directly under the database usercode. For nonusercoded databases, processes are initiated using a WFL job. For a nonusercoded database, Remote Database Backup automatically creates, at run time, the required WFL job for initiating processes on the remote host. For RDB server and all related tasks to run unimpeded, you must ensure that a queue exists to handle the tasks by either Checking that the attributes of the default queue on the remote host do not prevent Remote Database Backup processes from running correctly. For example, if the mix limit for the default queue is set to 0 (zero), no Remote Database Backup processes can run on the remote host. Configuring and specifying a queue other than the default queue to handle all Remote Database Backup tasks. You can use the MARC screens to check queue numbers and the attributes associated with them. Facilitating the NFT Task Under the AFS Mode Under the AFS mode, certain Remote Database Backup-related tasks (including the RDB server, the Audit server, and Tracker) execute under the database usercode. However, BNA does not allow the NFT task to run without a usercode. To enable the NFT task to run, you provide the NFTINFOFILE file with a privileged usercode and password during a RDB support library modification. You can perform the modification on both the primary and secondary hosts, or perform it on the primary host and copy the modified RDB support library to the secondary host

86 Preparing to Configure a Remote Database Backup System Modifying the RDB Support Library for a Nonusercoded Database When you use a nonusercoded database with Remote Database Backup, prepare for its proper functioning by performing the following procedure. Step Action 1 Establish a privileged usercode (and password) as a remote user on the primary and secondary hosts. 2 Modify the title attribute of the NFTINFOFILE file to the usercode and password established in step 1, using a WFL statement with the following syntax: WFL MODIFY *SYSTEM/RDBSUPPORT; FILE NFTINFOFILE (TITLE = <usercode>/<password>); The RDB support library must be modified on both hosts. 3 Optionally, specify a queue other than the default queue to handle all Remote Database Backup processes on the remote host. Ensure that you specify a valid queue number. Otherwise, the RDB server task does not run. Use a WFL statement with the following syntax at the remote host: WFL MODIFY *SYSTEM/RDBSUPPORT; TASKSTRING = "<queue number>" 4 Prepare the RDB support library using the Support Library (SL) system command. The syntax is as follows: SL RDBSUPPORT = *SYSTEM/RDBSUPPORT ON DISK Considerations When Using Remote Database Backup with Databases Participating in Open Distributed Transaction Processing Operations You can use Remote Database Backup with databases participating in Open Distributed Transaction Processing operations. You should understand the following considerations when you enable for Remote Database Backup a database that is participating in Open Distributed Transaction Processing operations: The Remote Database Backup secondary database cannot be inquired upon using Open Distributed Transaction Processing inquiry transactions because the secondary database cannot enter transaction state. Normally, a database using Remote Database Backup capabilities must be kept synchronized with all other databases that participate in the global transaction. If the need arises to execute a Remote Database Backup takeover, synchronization between the new primary database and the other databases cannot be guaranteed. Transactions that were considered complete on the original primary host might not have been applied to the original secondary host prior to the takeover. The synchronization issue is similar to the issue of performing a rollback on any databases participating in a global transaction. Whenever a takeover is attempted on a database that has the OPENOLTP DASDL option specified, the Remote Database Backup software issues the following warning:

87 Preparing to Configure a Remote Database Backup System "<database name> has the Open/OLTP option set which may result in partial or missing global transactions." Related Information Topics For information about... Refer to... Enterprise Application Environment databases Section 11 Establishing the Remote Database Backup Hardware and memory information Job queues and queue attributes Open Distributed Transaction Processing Remote Database Backup installation Task attributes Enterprise Database Server Getting Started and Installation Guide The operations manual for your host System Administration Guide Open/OLTP Administration Guide Open/OLTP Programming Guide Enterprise Database Server Getting Started and Installation Guide Task Attributes Reference ALGOL Reference Manual, Vol. 1 Understanding Remote Database Backup Software Remote Database Backup Software Components In addition to the Enterprise Database Server, the Remote Database Backup system consists of two specialized files. These files are: RDB server code file RDB support library The Database Operations Center provides the user interface for the Remote Database Backup system. Database Operations Center Database Operations Center is the menu-driven user interface managing an Enterprise Database Server. By selecting the Remote Database Backup option from the Database Operations Center Tools menu, you can use Database Operations Center to configure database operations within each Remote Database Backup system. This configuration includes the name of the hosts, various communication options, and various pack mapping options

88 Preparing to Configure a Remote Database Backup System Database Operations Center also reports the status of audit transmissions under the ABW audit transmission mode and provides database and network cumulative statistics about audit transmissions. RDB Server Code File The RDB server code file initiates three tasks ACR server, Audit server, and RDB server to process automatically General purpose communication between the primary and secondary hosts Typical server tasks include monitoring the link that initiates the Catchup process, monitoring on the primary host the current state of the secondary host, and adding stacks as the number of audit file sections changes. The ACR server task appears in the mix as <database name>/acr/server Audit blocks Under the ABW audit transmission mode, the Audit server receives and acknowledges audit blocks that are transferred from the primary host during normal operations. The Audit server writes the audit images to disk on the secondary host for the ABW mode only. Then Tracker applies the audit images to the secondary database. The Audit server task appears in the mix as one task for a nonsectioned audit file and as several tasks for a sectioned audit fileone task for each section. The Audit server task appears in the mix as follows for a nonsectioned file or for the first section of a sectioned file: <database name>/audit/server For subsequent sections of a sectioned audit file, a number is appended in sequential ascending order as follows: <databasename>/audit/server/<n> Remote Database Operations Center requests The RDB server handles utility requests for information from the remote host. For instance, if you are connected to the primary host and you access the View Remote Auditing Status screen, the Database Operations Center on the primary host retrieves the information through a request to the RDB server on the secondary host. The RDB server task appears in the mix as <database name>/rdb/server The ACR server, the Audit server, and the RDB server run on the remote host of a Remote Database Backup system. They appear on the secondary host when the primary database is active and on the primary host when the secondary database is active

89 Preparing to Configure a Remote Database Backup System Priority of RDB Server Tasks The initiation of the RDB server task at the secondary host is controlled by the RDB support library at the primary host. The initiation of the RDB server task at the primary host is controlled by the RDB support library at the secondary host. If the network service is BNA and the RDB server task runs under a usercode, the RDB server task is given the same priority as the RDB support library on the initiating host. If the network service is TCP/IP or if the RDB server task is run without a usercode, the task is run from a job queue at the remote host and has the default priority of that queue. The queue number can be selected by modifying the TASKSTRING attribute of the RDB support library at the initiating host; otherwise, the default queue is used. For additional information, refer to Modifying the RDB Support Library for a Nonusercoded Database earlier in this section. RDB Support Library The RDB support library provides centralized access for all Remote Database Backup host-to-host communication, input/output functions, and the functions for maintaining the RDB control file. It is the interface to the database for all Remote Database Backup-related functions. RDB support appears as a library on the primary and secondary hosts. How the Remote Database Backup Components Work Together Figure 4 1 shows how the Remote Database Backup components work together under the ABW mode. The two hosts communicate through the network. When you open the primary database, the RDB support library is invoked. The support library in turn calls the Audit server on the secondary host. The RDB support library then takes the audit images from the primary database on the primary host and transfers these images to the Audit server on the secondary host. Under the ABW audit transmission mode, the Audit server then writes the images to the secondary database audit trail. The Audit server with RDBSUPPORT and possibly Catchup maintains synchronization of the two audit trails. Tracker on the secondary host maintains synchronization of the two databases by applying the audit images from the audit trail to the secondary database

90 Preparing to Configure a Remote Database Backup System Figure 4 1. How Remote Database Backup Components Work Together for the ABW Mode ABW Mode Tasks for Sectioned Audit Files On the primary host, an ACR port I/O task is responsible for sending audit blocks to the secondary host through a dedicated subport of the ACR port. On the secondary host, the Audit server receives audit blocks and writes them to the appropriate audit section. The system generates one ACR port I/O task and one Audit server task for each audit section. These tasks are always present on both the primary and secondary hosts to provide swift response in the event of a takeover. The following table lists the format of the ACR port I/O and Audit server task names during the transfer of sectioned audit files from the primary host to the secondary host. Section Number ACR Port I/O Task Name Audit Server Task Name 0 <database name>/acrportio <database name>/audit/server 1 <database name>/acrportio/1 <database name>/audit/server/1... n <database name>/acrportio/<n> <database name>/audit/server/<n>

91 Preparing to Configure a Remote Database Backup System Understanding Other Remote Database Backup Software Tracker Tracker is an asynchronous Remote Database Backup task declared and processed from the Accessroutines. The Tracker task appears on either host as <database name>/tracker. Tracker is initiated when The database is opened at either the primary or secondary host. Audit images are received at the secondary host. Remote Database Backup-agent detects that a Catchup process is necessary. A Remote Database Backup acknowledgment is performed. Tracker Operations Tracker performs the following operations: On the secondary host, Tracker reads audit images from the audit trail and applies those images directly to the secondary database through a mechanism similar to the rebuild recovery mechanism. Tracker does not reprocess transactions. The reading and applying of audit images occurs in two separate phases. During the first phase, known as prescanning, Tracker reads the audit file looking for a point at which no transactions are in progress. Such a point is known as a quiet point. During the second phase, Tracker begins to apply all audit images from its current position in the audit trail to the quiet point found during the prescanning phase. In other words, Tracker applies audit images from transactions to the secondary database; Tracker does not apply actual transactions. The Quickfix process of reconstructing rows from the audit cannot be used on the secondary database to fix write errors. Instead, a backup dump must be used. On the primary host, Tracker is always initiated by the first database opener. In most cases, Tracker quickly goes to end of task (EOT). If a halt/load recovery is needed, however, Tracker waits for the DMRECOVERY task to complete and then applies any audit after-images required by the recovery before going to EOT. Under the ABW audit transmission mode, Tracker initiates the Catchup task as soon as it reads to the end of the audit trail at the secondary host and detects that the primary and secondary audit trails are not synchronized. How Tracker and Inquiry Programs Work Together Because of database integrity constraints, Tracker must have exclusive use of the database when it is applying audit images. Consequently, when Tracker is applying audit images, inquiry programs are locked out of the database. Conversely, when inquiry programs are accessing the database, Tracker is not able to apply audit images

92 Preparing to Configure a Remote Database Backup System Inquiry programs and Tracker lock out each other from the database only during the time that Tracker applies audit images. The length of the lockout time is dependent on the contents of the audit trail; the time also varies by site and database. Tracker does not lock out inquiry programs while Tracker is prescanning the audit trail. If the Tracker task does not terminate normally, it locks out all inquiry programs when it resumes applying audits to the database until it comes to a point where the database is in a consistent state. At that point, Tracker again allows inquiries while it is prescanning audits. Each time Tracker comes up, inquiry programs are locked out until Tracker can ensure the integrity of the database. Catchup and Catchup-Server The Catchup and Catchup-server tasks operate only when the Remote Database Backup system is functioning under the ABW audit transmission mode. Their combined functions are called the audit synchronization process. This process is designed to bring the secondary database audit trail back into synchronization with the primary database audit trail when the former is behind the latter. The Catchup and Catchup-server tasks are part of the Catchup process (Figure 4 3), which operates in the following way: 1. Whenever Tracker on the secondary host reaches the end of the audit trail, Tracker determines whether the audit trails are still synchronized. If they are not synchronized, Catchup is initiated at the secondary host. If a communication problem prevents the Catchup process from initiating immediately, then the Remote Database Backup-agent task, which is named <database name>/rdb/agent, attempts communication with the other host at the following intervals: On the primary host, 1 minute following an audit transmission error and every 5 minutes thereafter On the secondary host, every 5 minutes following an audit transmission error The Remote Database Backup-agent task is an asynchronous task processed from the RDB support library. This task stays in the mix as long as the Remote Database Backup software is executing. 2. The Catchup-server task reads audit blocks on the primary host and sends these blocks to the Catchup task on the secondary host. The Catchup-server task appears on the primary host as <database name>/catchup/server/<secondary host name>. 3. The Catchup task operates on the secondary host and writes to the audit pack the incoming audit blocks sent by the Catchup-server task. The Catchup task also acknowledges receipt of the audit blocks. The Catchup task appears on the secondary host as <database name>/catchup

93 Preparing to Configure a Remote Database Backup System 4. The Catchup task communicates with the Catchup-server task to determine when the Catchup process is complete. 5. If Catchup terminates, it restarts automatically after the synchronization restart interval has elapsed. Sectioned Audit Files and Catchup With sectioned audit files, one Catchup task per section runs on the secondary host. A dedicated subport of the Catchup CU_PORT port file is used to transfer audit blocks of a particular section to the secondary host. The task appears as indicated in the following table. Audit File Section Secondary Host 0 <database name>/catchup 1 <database name>/catchup/1... n <database name>/catchup/<n> Note: Because Catchup server cannot read sectioned audits directly from tape, copy audits from the quickcopy tape to disk. Automating Some Remote Database Backup Operations Overview You can automate some of the operations of the Remote Database Backup system through one or more of the following means: Remote Database Backup takeover entry point System Assistant software Other products Product support personnel are available to build an automated disaster recovery system using the Remote Database Backup software, some other specialized programs, and System Assistant software or other products

94 Preparing to Configure a Remote Database Backup System System Assistant System Assistant is a software package that enables system administrators to effectively monitor system activities and system states, and to automate responses to system events. You can use the System Assistant software to detect and automate some recovery strategies or other operations in a Remote Database Backup system. In particular, System Assistant can help in monitoring events that could lead to takeover situations. Related Information Topics For information about... Refer to... Audit synchronization Sections 1 and 2 Disabling Tracker Section 8 Preventing the existence of two primary databases Quickfix process Restart points Section 6 Enterprise Database Server Utilities Operations Guide Manipulating the Frequency of Restart Points later in this section Restarting Tracker Section 8 Sectioned audit files System Assistant Enterprise Database Server Utilities Operations Guide System Assistant Guide Takeovers Sections 6 and 13 Understanding How Remote Database Backup Uses Port Files Overview The Remote Database Backup system uses the network port file communications facility for host-to-host communication. Remote Database Backup uses the three port files described in the following table. The table lists the port file name, its purpose, the code file location for the host initiating the communication, and the code file location for the host responding to, or cooperating with, the initial port file communication

95 Preparing to Configure a Remote Database Backup System File Name Purpose Location of Initiating Host Declaration Location of Cooperating Host Declaration PORT Serves the Database Operations Center and the Accessroutines for communication between the primary and secondary hosts In the RDB support library In the RDB server code file ACR_PORT Under the ABW mode, serves the Accessroutines for the transfer of audit images during normal operations In the RDB support library In the RDB server code file CU_PORT Under the ABW mode, serves the transfer of audit blocks during the Catchup process In the RDB support library on the secondary host In the Catchup-server task, declared in the Accessroutines on the primary host Characteristics of the PORT Port File The PORT port file is used to communicate status information while the database is open or Database Operations Center is running. The PORT port file transfers Database Operations Center information between the RDB server and the RDB support library. This file has the following characteristics: Traffic on this port file is normally intermittent. This port file only closes when the RDB support library for the database goes to end of task (EOT), or when there is a communications error. Characteristics of the ACR_PORT Port File The ACR_PORT port file is used only during normal audit transfer operations when the ABW audit transmission mode is set. This file has the following characteristics: Messages consist of audit blocks that, as they are filled, are sent from the primary host to the secondary host. Traffic on this port file is directly proportional to the primary database audit generation. During the Catchup task, this port file can be open, but audit block transfers only occur through the CU_PORT port file. The Accessroutines opens the ACR_PORT port file during a database open operation. An ACR_PORT port file task appears in the mix as <database name>/acrportio

96 Preparing to Configure a Remote Database Backup System Characteristics of the CU_PORT Port File The CU_PORT port file is open only during Catchup audit transfer operations. This file has the following characteristics: Messages consist of audit blocks that are sent from the primary host to the secondary host. Traffic on this port file is heavy and continuous. As soon as Catchup stops running, this port file closes. Sectioned Audit Files and Port Files The Remote Database Backup system transfers audit images from sectioned audit files through subports of each port file (one subport for each section). The subport used is the section number plus 3. For example, in an audit file with three sections, the name of the task for the third section would be <database name>/acrportio/2 In this example, the task would use subport 5. Related Information Topics For information about... Refer to... Accessroutines Enterprise Database Server Utilities Operations Guide Audit transmission modes Sections 1, 2, and 3 Catchup and Catchup-server Port-I/O timeout function RDB code files Sectioned audit files Catchup and Catchup-Server earlier in this section I/O Timeout Value for the Ports later in this section Understanding Remote Database Backup Software earlier in this section Enterprise Database Server Utilities Operations Guide

97 Preparing to Configure a Remote Database Backup System Understanding More About the ABW Mode Data Flow Under ABW With the ABW mode, audit block images are transmitted from the database stack through the RDB support library on the primary host by way of the ACR_PORT port file to the Audit server task on the secondary host. The Audit server task on the secondary host then writes the audit block images to an audit file on disk. Tracker later reads these audit blocks from disk and applies these audit block images to the database. This data flow is illustrated in Figure 4 2. Figure 4 2. Normal Flow of Audit Blocks in ABW Mode Initiation of Data Transmission The creation of an audit block image initiates the data transmission from the primary host to the secondary host. This data transmission is part of an Enterprise Database Server audit block write operation that includes The logical (direct I/O) write to the audit disk on the primary host This logical write waits for the completion of the physical write to disk. The logical (port file I/O) write to the ACR_PORT port file that leads to the secondary host This logical write waits for an event that indicates the completion of the port file I/O write, as follows: - The write always waits for a write result from the MCP indicating that the port file I/O write has occurred. - When an acknowledgment is required, the write waits for a message acknowledgment from the Audit server task on the secondary host. The actual order of the previously mentioned events is

98 Preparing to Configure a Remote Database Backup System 1. Disk write 2. Disk wait 3. Network write 4. Network wait Steps of the Port File I/O Write Operation The steps that complete the port file I/O write operation are as follows: 1. The network transmits the write operation from the primary host to the secondary host. When an audit block acknowledgment is required, the RDB support library indicates the requirement by setting a field in the port file I/O message. 2. The Audit server task reads the write operation from the corresponding port file on the secondary host. 3. When required, the Audit server task writes an audit block acknowledgment to the ACR port file on the secondary host, and the network transmits the audit block acknowledgment from the secondary to the primary host. 4. When an acknowledgment is requested, the primary host writes and transmits (n 1) more audit blocks (where n is the acknowledgment rate) before it reads the acknowledgment from the secondary host. The audit block acknowledgment confirms only that the Audit server task has received the audit block. Waiting for the audit block acknowledgment might impose a delay on the auditing process on the primary host. However, it is the only way to confirm that the audit blocks are present on the secondary host. Handling of the Audit Block on the Secondary Host After receiving the audit block and sending an audit block acknowledgment, when required, the following actions occur on the secondary host: 1. The Audit server task writes the audit block to the audit file on disk. 2. Tracker reads the audit block. First Opening of the Primary Database for Update When the primary database is first opened for update, the following actions take place: 1. The RDB support library on the primary host initiates an Audit server task on the secondary host for each section of the audit file. Steps 2 through 5 are repeated for each section of the audit file. 2. The Accessroutines writes the first audit block on the primary host. 3. The Accessroutines stops further database activity until the Audit server on the secondary host acknowledges receipt of the first audit block for that section

99 Preparing to Configure a Remote Database Backup System 4. The RDB support library on the primary host receives the acknowledgment and informs the Accessroutines for the primary database. 5. The Accessroutines completes the audit block write process and allows processing to continue. Effect of the Port-I/O Timeout You can set a port-i/o timeout value to specify the maximum length of time that the RDB support library on the primary host waits for an audit block acknowledgment. When the timeout period is exceeded under the Drop option, control of the audit transmission process passes to the Catchup process. Catchup Process When the transmission of audit blocks is delayed and the primary and secondary audit trails are out of synchronization, the Catchup process begins. To restore audit trail synchronization as quickly as possible, the Catchup-server task employs an audit transfer process that is different from the normal audit transfer process. The Catchup-server task essentially tanks up, or batches, the audit blocks so that they can be reblocked for transmission more efficiently as bundles of blocks. In relation to regular audit transfer, the Catchup-server task is analogous to the Accessroutines on the primary host. The Catchup task or tasks are analogous to the Audit server tasks on the secondary host. The Catchup-server task on the primary host collects and sends audit blocks through the CU_PORT port file to the Catchup task or tasks on the secondary host. When audits are sectioned, multiple Catchup tasks exist on the secondary host. Every 10th transmission requires an audit block acknowledgment. Figure 4 3 illustrates the flow of the Catchup process. Figure 4 3. Catchup Process Flow of Audit Blocks in ABW Mode

100 Preparing to Configure a Remote Database Backup System Automatic Audit Synchronization Process of the ABW Mode Definition and Purpose Automatic audit synchronization occurs under the ABW mode only. Audit synchronization is a process designed to bring the secondary audit trail back to synchronization with the primary audit trail. Two tasks combine in the audit synchronization process. These tasks make use of Tracker, the Catchup and Catchup-server tasks, and the port files. The two tasks are as follows: The sending and receiving of audits The Catchup-server task on the primary host transmits audit blocks through the CU_PORT port file to the secondary host where a Catchup task reads the audits and places them in the audit trail. The applying of the audits to the secondary database On the secondary host, Tracker applies the audit images in the audit trail to the secondary database. During the audit synchronization process, the primary host does not send newly created audit blocks to the secondary host. When audit synchronization is complete, the primary host automatically resumes sending new audit blocks to the secondary host through the ACR_PORT port file. Conditions That Initiate Audit Synchronization Audit synchronization starts automatically under the following conditions: When an audit write operation at the primary host does not complete successfully on the secondary host or when the secondary host does not acknowledge the Remote Database Backup host-to-host communication, audit synchronization begins. The first time the primary host sends the first audit block to the secondary host, the Audit server tasks on the secondary host verify that the audit blocks are valid. The first block of each section is checked. Each audit block has its own audit block serial number (ABSN) and timestamp and the timestamp of the previous audit block. An audit block is valid when - The ABSN of the current block is greater than the ABSN of the previous audit block. - The timestamp value of the previous audit block that is stored in the current block matches the timestamp stored in the previous block. If the audit block is valid and there are missing audit blocks on the secondary host, audit synchronization begins. Note: If the audit block is not valid, the secondary host rejects the audit block and marks the secondary database as requiring a clone operation. When the first inquiry program opens the secondary database, Tracker identifies the

101 Preparing to Configure a Remote Database Backup System last audit block created by the primary host. If there are missing audit blocks on the secondary host, audit synchronization begins. When an interruption in network communication is detected, Tracker attempts to start audit synchronization after the synchronization restart interval has expired. The interval is a value in seconds that you set within Database Operations Center. The range is 1 through 999 seconds; the default is 100 seconds. After a secondary host halt/load, audit synchronization begins as soon as the following occurs: - Network communication becomes available. - The secondary database is opened by the initiation of the primary database, by an inquiry program at the secondary host, or by the Remote Database Backup-agent task. Integrating Remote Database Backup into Your Security Setup Why Security Problems Occur Because a Remote Database Backup system operates on two hosts and involves two databases, you must ensure that the Remote Database Backup operations that traverse both hosts or both databases are functioning under compatible security restrictions or privileges. If not, some operations cannot proceed at all; other operations require additional actions for example, making the DMSUPPORT library executable before they can proceed. Goal of Integration The goal of integrating Remote Database Backup into your normal security setup is to ensure that your data is protected as you intend it to be, and that security definitions do not become an obstacle to the smooth running of the Remote Database Backup system. If you license the Security Sources for ClearPath MCP product and use the DMALGOLUNSAFE option on either host, then you need to be aware that the DMSUPPORT library that is generated as a result of a database compilation needs to be marked as executable before it can be used. You use the MP (Mark Program) system command to mark a library as executable, for example, MP (PROD)DMSUPPORT/PAYROLL ON PRODUCTION + EXECUTABLE

102 Preparing to Configure a Remote Database Backup System Enabling Remote Database Backup The process of enabling your database for use as a Remote Database Backup system requires that you perform the enable task from a usercode that is defined with update privileges in the guard files for your database. The enable task opens your database for update so that it encounters the same restrictions as any open update request on the database. For information about... Refer to... Enable task Section 5 Setting Up Guard Files for the Secondary Host Introduction If your DASDL source file contains the GUARDFILE or SECURITYGUARD option on either the database or the individual data sets, then you need to define corresponding guard files on the secondary host. You do this by copying the guard files from the primary to the secondary host and by specifying secondary host pack locations for the guard files to Database Operations Center. Specifying Guard File Pack Locations As part of the clone operation during the Remote Database Backup configuration, you need to identify the packs on the secondary host where any guard files for the database reside. Therefore, before configuring your Remote Database Backup system, you should understand the existing guard file protection in place for the database. Defining Guard File Access Your guard files and their locations on the primary host should be defined in the database DASDL source file. You should define the corresponding guard files for the secondary host on the Guard screen when you clone the database on the secondary host. Although it is possible to designate one type of access for a file for example, the database control file on the primary host and a different type of access for this file on the secondary host, it is recommended that you keep your access types consistent on both hosts. If you do not maintain this consistency, security violations can occur in the event of a takeover

103 Preparing to Configure a Remote Database Backup System Attaching Guard Files You should specify the guard file definitions in the database DASDL source file. Any other method of attaching guard files is not supported in the Remote Database Backup environment. Required Read/Write Access If you configure a Remote Database Backup system for an existing Enterprise Database Server database that already uses guard files, then the required guard file read/write access between Enterprise Database Server code files and the database control file, the audit file, and data sets should be set up. Remote Database Backup does not require any additions to guard file read/write access. If you are setting up guard files for your database for the first time when you configure your Remote Database Backup system, ensure that your guard file definitions allow the required database read/write access. Related Information Topics For information about... Refer to... Guard files MP command Security administration DASDL Programming Reference ALGOL Reference Manual, Vol. 1 Security Operations Guide System Commands Reference Manual Security Overview and Implementation Guide Preparing Personnel to Run the Remote Database Backup System You should have sufficient personnel trained in Remote Database Backup and thoroughly knowledgeable about your strategies for using Remote Database Backup as part of your disaster recovery plan. Trained personnel should be available at both Remote Database Backup host sites during key operating hours. Trained product support personnel can assist you in understanding how to manage a Remote Database Backup system. Contact your product support representative. Personnel should be trained in Monitoring and adjusting the rate of audit transmission Audit synchronization Initiating and following through on takeover strategies

104 Preparing to Configure a Remote Database Backup System Troubleshooting Recovery and reorganization in a Remote Database Backup environment Reviewing DASDL Source Files Importance of the DASDL Source File to a Remote Database Backup System Whatever you can define in the database DASDL source file, you should define there. Because there are two hosts involved in Remote Database Backup that do not necessarily have the same pack identifications, and because it is possible to have the primary and secondary databases switch roles, a clear definition of all Enterprise Database Server and other database software and the software locations can keep problems of file location to a minimum during Remote Database Backup operations. Defining Code Files Ensure that the file title of the following code files and their locations on the primary host are defined in the database description: DMSUPPORT library If you run SYSTEM/RDBSERVER on DISK at the primary host and the DMSUPPORT library is not defined, the Catchup-server cannot find the DMSUPPORT library. DMRECOVERY program If the location of the DMRECOVERY program is not defined in the database description, the Catchup-server might not be able to find the correct version of DMRECOVERY. REAPPLYCOMPLETED Option Setting the DASDL option REAPPLYCOMPLETED causes smaller audit blocks. The smaller block size provides a better basis for recovery in case of a disaster or other interruption. However, the smaller block size also increases the overall number of network acknowledgments required during audit transmission in the ABW mode, and therefore can cause less efficient throughput. Alternate Audit Trail Specification When the ALTERNATE audit location is other than TAPE in the audit trail option for the primary database, you must specify a corresponding alternate location for the secondary database in Database Operations Center. If you specify TAPE for the ALTERNATE option in the DASDL, Remote Database Backup ignores the option

105 Preparing to Configure a Remote Database Backup System When you run Remote Database Backup under the AFS mode, the AFS copy operation uses the alternate disk location as a source when transferring audit images to the secondary host. The secondary host location for the alternate audit trail is used by the new primary host after a takeover. Guard Files To ensure that Remote Database Backup recognizes the attachment of guard files to database files, you should be certain that all guard files are attached to their files through the database description. Number of Partitions in Database Structures If you partition database structures in the database in your Remote Database Backup system, you specify the physical options of PARTITION and OPEN PARTITIONS as you would on any database that is not in a Remote Database Backup system. However, determining the number of open partitions you can specify in a Remote Database Backup system requires a different calculation than for a database that is not in a Remote Database Backup system. This different calculation is necessary because Remote Database Backup restricts the use of partitions on the primary database to only 75 percent of the OPEN PARTITIONS value you specify. Why Remote Database Backup Restricts the Number of Partitions on the Primary Database Remote Database Backup enforces the 75 percent partition restriction in order to provide sufficient partitions for Tracker to use on the secondary host and still leave one or more partitions on the secondary host that an inquiry program can use. In other words, in a Remote Database Backup environment The description file is duplicated from the primary to the secondary database, furnishing each database with the same number of partitions. As applications open and access partitions on the primary database, Tracker on the secondary host must be able to simultaneously open and access the same number of partitions on the secondary database. If, in addition, the secondary database is used for inquiry, then a partition or partitions must be available on the secondary host to support access by an inquiry program. However, the 75 percent partition restriction has two side effects that require your attention:

106 Preparing to Configure a Remote Database Backup System While acceptable OPEN PARTITIONS values outside of Remote Database Backup are in the range 1 (the default) to 15, the lowest effective Remote Database Backup value is 3. Using the lowest values (1 and 2) effectively denies any access to a partitioned structure by an inquiry program on the secondary database. The program receives a LIMITERROR error. Therefore, you must enter a value in the range 3 to 15 in the DASDL OPEN PARTITIONS option. Applications on the primary host have fewer partitions than you intended to provide when you specified the OPEN PARTITIONS value in your DASDL source file. Therefore, these applications can receive a LIMITERROR error because of a lack of open partitions. You should inflate the value you specify for the OPEN PARTITIONS option in the Remote Database Backup environment. Procedure to Inflate the DASDL OPEN PARTITIONS Value To offset the effect of the 75 percent Remote Database Backup partition restriction, you can inflate the number of open partitions you specify in your DASDL source file by performing the following procedure. Step Action 1 Divide by 0.75 the number of open partitions you need for the database structure that is not in the Remote Database Backup system. 2 Divide by 0.25 the number of open partitions you need for inquiry programs on the secondary host. 3 Insert the larger of the results in steps 1 and 2 as the value for the OPEN PARTITIONS option in the DASDL source file. Example Assume you need six open partitions for a nonremote Database Backup database structure. For Remote Database Backup, you need at least eight open partitions (6 /.75 = 8). When you specify an OPEN PARTITIONS value of eight, this calculation provides two open partitions for inquiry programs on the secondary host. Assume also that you estimate you actually need four open partitions for inquiry programs on the secondary host. When you specify an OPEN PARTITIONS value of 15 (the maximum allowed), your calculation results in 16 open partitions (4 /.25 = 16). To properly inflate the number of partitions, you would specify the larger of the two results as the OPEN PARTITIONS value in the database DASDL source file

107 Preparing to Configure a Remote Database Backup System Related Information Topics For information about... Refer to... ALTERNATE DASDL option Catchup-server DASDL source file OPEN PARTITIONS DASDL option REAPPLYCOMPLETED DASDL Programming Reference Manual Catchup and Catchup-Server earlier in this section DASDL Programming Reference Manual DASDL Programming Reference Manual DASDL Programming Reference Manual Designating Usercodes and Packs Need for Planning Usercodes and File Locations Because Remote Database Backup provides the capability to switch the primary and secondary database roles, you must plan your usercode and pack specifications so that the databases, database files, and Remote Database Backup files can always be accessed. When you use Database Operations Center to configure your Remote Database Backup system, you are asked to specify the usercodes, pack names, and file names for Remote Database Backup and Enterprise Database Server system software files. The following information provides tips and considerations that can help you in completing this part of the configuration process. Usercode Factors Keep the following factors in mind as you define the usercodes for your Remote Database Backup system: The primary and secondary databases either must both be nonusercoded or must both have the same usercode. On the two Remote Database Backup hosts, the database usercode must be defined in the USERDATAFILE both as a user on one host and as a remote user on the other host. This definition can include a default family statement and other attributes. For example, the usercode defined for the primary database, PRODDB, must also be defined as a remote user for the secondary host. The usercode attributes, in particular the ACCESSCODE and CHARGE attributes, must be compatible between the primary and secondary host. The compatibility becomes especially important for AFS mode when the completed audit files are copied automatically from the primary host to the secondary host. The usercode defined for the database is used during the copy process. If that usercode has been defined to require an accesscode, the first accesscode in the accesscode list

108 Preparing to Configure a Remote Database Backup System for that usercode is used for the copy process. The accesscode used on the primary host must be defined as an accesscode on the secondary host. The database usercode can be different from the usercodes that access the database. If the database is nonusercoded, all the code files specified in the DASDL source file must have the security level of PUBLIC. Queue Factors In a Remote Database Backup environment, for databases using TCP/IP or nonusercoded databases using BNA, the RDB server on the remote host must be initiated using a WFL job. Remote Database Backup automatically creates, at run time, the required WFL job for initiating the RDB server on the remote host. The WFL job runs under a queue on the remote host, so you must ensure that the attributes associated with the queue do not prevent Remote Database Backup processes from running correctly. For example, if the mix limit for the queue is set to 0 (zero), no Remote Database Backup processes can run on the remote host. Use the MARC screens to check the queue number and attributes associated with the queue. When using nonusercoded databases, you can avoid problems associated with queue settings by checking the attribute settings of the queue While checking Remote Database Backup installation On the primary host prior to performing a planned takeover On the old primary host (the new secondary host) after an unplanned takeover Pack and Family Factors Keep the following factors in mind as you define the packs for your Remote Database Backup system: System efficiency is best served by designating the location of your database files in your DASDL source file. The packs on your primary and secondary hosts can be identically named, or they can be different. It is recommended that pack names on both hosts be the same. If pack names are not the same on both hosts, reorganization activities that add a structure to these packs require an offline manual intervention to complete properly. You should specify the DISK pack for Remote Database Backup and Enterprise Database Server file locations and family statements ONLY with a full understanding of the meaning of using the DISK pack to the enterprise server operating system. Specifying packs for particular files during the Remote Database Backup configuration is optional. However, for file-searching purposes, it is recommended that you specify the packs on which you want these particular files to reside. Your specifications are recorded in the Remote Database Backup control file and in the database control file, the primary sources for file locations for the data management software. If the file is not found by the data management software, the search continues with the usual file-searching mechanism

109 Preparing to Configure a Remote Database Backup System The advantages of specifying packs for certain files are as follows: - Efficiency Once the file is found, the search activity ends. - Stability The file-searching mechanism accesses the file that you designate. If other versions of the sought-after file exist elsewhere on the system, and if you do not specify a location in the DASDL source file or on Database Operations Center screens, the file-searching mechanism might locate an incorrect version of the file. This incorrect version could cause errors and thus delay processing. Code Files Enterprise Database Server and Remote Database Backup make use of certain code files as part of running the database and Remote Database Backup. If you do not specify the location of these code files on Database Operations Center screens when you configure Remote Database Backup, the system uses its own file-searching order to find these code files. The code files are Accessroutines DMSUPPORT library Recovery Data recovery Reconstruct Reorganization Primary audit copy job Secondary audit copy job File-Searching Order Knowing the order in which the system searches for code files can help you understand circumstances that might appear as error conditions or unpredictable results. For example, a situation in which a task is not initiated because the code file is not found might be confusing from an operations standpoint. If you do not specify the location, the order of file-searching depends on the Remote Database Backup activity initiated

110 Preparing to Configure a Remote Database Backup System To find code files for a local Remote Database Backup task, the system searches in the designated order for a code file pack location specified in one of the following: - The database control file - An active family substitution (FAMILY command) usually specified at the beginning of a session, but sometimes specified by a program - The USERDATAFILE of the usercode opening the session To find a remote code file to initiate a Remote Database Backup-related task, the system searches for the code file under the family of the usercode that initiated the task. If the file is not found, the system does not initiate the task. Related Information Topics For information about... Refer to... Checking Remote Database Backup installation Family and pack administration Processes for different pack names on the primary and secondary hosts Queue on remote host Task attributes USERDATAFILE Checking on the Remote Database Backup Installation earlier in this section System Administration Guide Sections 5, 8, and 9 Providing a Queue for Remote Database Backup-Related Tasks earlier in this section Task Attributes Reference Manual MCP Security Overview and Implementation Guide Ensuring Database File Availability on the Secondary Host Specifying Enterprise Database Server Code Files in the DASDL Source File Specifying your Enterprise Database Server code files in your DASDL source file simplifies the locating of necessary files during Remote Database Backup operations. DASDL specifications are especially important for the DMSUPPORT library and the database control file when usercodes are associated with the databases. Because Enterprise Database Server code files are required in running Remote Database Backup and because database files can reside on different locations on the primary and secondary hosts, Database Operations Center provides a means for you to identify the different locations on the secondary host. You can also modify these locations at any time

111 Preparing to Configure a Remote Database Backup System Ensuring Application Access to the Secondary Database Before a takeover occurs, you should ensure that the latest application software resides on the secondary host. If information such as packs and usercodes are hard-coded into the application, you need to change the application so that it uses the correct packs and usercodes on the secondary host. If the database control file on the secondary host resides on a different family from the primary host, perform either of the following steps: Ensure that all WFL jobs that run programs having access to the secondary database contain the required database equation. Ensure that the programs are WFL modified with the appropriate database equation. Sample syntax of a database equation follows: RUN PROD/APPLICATION; DATABASE <database name> (TITLE = <database name> ON <pack name>); Providing a Dump of the Primary Database Cloning the primary database on the secondary host requires that a dump of the primary database be present on the secondary host. Notes: The dump must be produced with a version of Enterprise Database Server software that matches the Remote Database Backup software level. In order to decrypt an encrypted dump on a system other than the local system, the tape encryption keys used to encrypt the dump must first be exported from the local system and imported on the destination system. Refer to the MCP Cryptography Services Manager link in the Security Center Help for instructions on exporting and importing tape encryption keys. An acceptable dump (or collection of dumps) can reside on disk or tape and is produced by the standard DMUTILITY program. You can use either offline or online dumps and either full or partial dumps for a full clone operation. Timing of the Dump To reproduce the primary database on the secondary host, the clone operation uses the dump of the primary database plus any audit files created between the time you perform the dump and the time you perform the enable operation. During the configuration of a Remote Database Backup system, the enable operation sets the groundwork for establishing a duplicate database on a secondary host. One of the actions that the enable operation performs is to update the database control file to indicate that remote auditing is enabled

112 Preparing to Configure a Remote Database Backup System If you let some time elapse between the time you enable the database and the time you clone the database, and you have the SCA or NSC audit transmission mode set for the primary database, you must also copy to the secondary host any audit files that have accumulated in that time period. Under the ABW audit transmission mode, if you perform the dump after the enable operation and a communication failure occurs between the time of the enable operation and the time you perform the dump, then you must copy to the secondary host the audit file that was in use at the time of the dump. Copy this audit file before you clone the database. Related Information Topics For information about... Refer to... Cloning the database Sections 5 and 8 DASDL source file Database dumps Database equation DMUTILITY program DASDL Programming Reference Manual Enterprise Database Server Utilities Operations Guide WFL Reference Manual Enterprise Database Server Utilities Operations Guide Enable operation Section 5 Takeovers Section 6 I/O Timeout Value for the Ports Definition The port-i/o timeout value applies to the ACR_PORT port file through which Database Operations Center transfers audit blocks when the Remote Database Backup system runs under the ABW mode. The port-i/o timeout value is the maximum amount of time that can elapse between the sending of an audit block by Remote Database Backup in ABW mode and the time Remote Database Backup receives an acknowledgment of the receipt of the audit block from the secondary host. After this time interval has passed, the Remote Database Backup system proceeds as though communications with the remote host have terminated. The following port files have fixed timeout values of 60 seconds:

113 Preparing to Configure a Remote Database Backup System PORT port file through which Database Operations Center communicates between the primary and secondary hosts CU_PORT port file through which Database Operations Center transfers audit blocks during the Catchup process under ABW mode Setting the Port-I/O Timeout Value You set the port-i/o timeout value using Database Operations Center while you are configuring or modifying the Remote Database Backup system. The value, which indicates seconds, can be an integer between 1 and The default is 60 seconds. You should specify a value for the port-i/o timeout that relates to the normal behavior of your hosts and network. If the port-i/o timeout value is exceeded, a port timeout error message is displayed. Responding to a Port-I/O Timeout Error Causes of the Error To determine the cause of a port-i/o timeout error on the sending host, check the mix on the receiving host for messages relating to the unavailability of the RDB server task and the Audit server tasks. The causes for a timeout error are varied. Some examples are An RDB server task was discontinued, hung, or is running at a low priority. One reason that the RDB server task would be discontinued by the MCP is that a task inherited from the sending host contains a task attribute that is not valid on the receiving host. The host is halt/loading or dumping. The system could not find a file. The hosts are not communicating. The acknowledgment rate is too low to prevent a port-i/o timeout error. The RDB control file on the other host is corrupt. Related Information Topics For information about... Refer to... Port files Understanding How Remote Database Backup Uses Port Files earlier in this section Setting the port-i/o timeout value Sections 5 and

114 Preparing to Configure a Remote Database Backup System Influencing Tracker Performance Introduction Tracker is the process that reads and applies audit images to the secondary database. You can influence two aspects of the Tracker process: Speed of performance Frequency of restart points Affecting the Speed of Tracker Performance Phases of the Tracker Process Tracker reads and applies audit images in two separate phases: 1. Prescanning, during which Tracker reads the audit file looking for a point at which no transactions are in progress. This point is called a quiet point. Tracker uses the prescanning phase to initiate reads of the database files that are needed during the application phase. This Tracker action helps to minimize the wait times on data block reads during the application phase. 2. Application, during which Tracker applies all audit images from the current audit trail position of Tracker to the quiet point found during the prescanning phase. Experimenting with the Prescanning Phase You can indicate the number of quiet points that Tracker processes during the prescanning phase. The default value is 1; that is, Tracker reads ahead in the audit file to the first quiet point it finds, and then returns to the point where it started reading to apply the audit images. Theoretically, an increase in the number of quiet points that Tracker can include in a scan could speed up the overall rate at which Tracker performs its task. However, because the speed of the Tracker prescanning phase depends upon several other factors amount of system I/O and buffer availability to name two increasing the number of quiet points in a scan does not necessarily increase Tracker performance. Determining the Optimal Number of Quiet Points in a Scan The frequency of quiet points in a scan is governed by the value associated with the TRACKERQPFACTOR option on the secondary database. You can use the Visible DBS command STATUS to view the current value for this option and use the Visible DBS command CHANGE to change the value. The default (and minimum) value of the TRACKERQPFACTOR option is 1. When you experiment with the TRACKERQPFACTOR value, compare the results of the default value with the results from a small increase in the value, for instance, an increase of 2 or

115 Preparing to Configure a Remote Database Backup System The results of your comparison will show whether increasing the quiet points in a scan is beneficial to Tracker performance. If Tracker speed is increased, you can experiment with further small increases until you reach a point of diminishing returns. Changing the Number of Quiet Points per Scan You change the value of the TRACKERQPFACTOR option with the Visible DBS CHANGE command. For example, the syntax for setting the TRACKERQPFACTOR value to 2 is <database stack mix number> SM TRACKERQPFACTOR = 2 To view the current value of the TRACKERQPFACTOR option, execute the Visible DBS STATUS command with the following syntax: <database stack mix number> SM STATUS When you use the Visible DBS STATUS command, a report similar to that shown in Figure 4 4 appears in the system messages. The information about the TRACKERQPFACTOR option appears toward the end of the report. OPEN COUNTS: INQUIRY = 2, UPDATE = 0 FORCED OVERLAYS = 1 SYNC WAIT IS 0 SECONDS OVERLAYGOAL = 5 % ALLOWEDCORE / MINUTE RESIDENT TOTAL: ALLOWED = 25000, IN USE =22576 CORE TOTAL: ALLOWED = 50000, IN USE = 47974, OLAYRATE= % CONTROL POINT AGEING AFTER AUDIT SWITCHES = FORCE SYNCPOINT = 100, CONTROLPOINT = 2 AUDIT BLOCKSIZE = 900, AREASIZE = 3000, AREAS = 100 AUDIT PROCESSOR TIMES OFF LAST TRACKED ADDRESS: AFN = 5, ABSN = 6240, OFFSET = 16 PRINT STATISTICS = ON TRACKERQPFACTOR = 10 TRACKERFLUSHDB = 10 DMSII ACCESSROUTINES Figure 4 4. Sample Output from the Visible DBS STATUS Command Manipulating the Frequency of Restart Points Restart Points and Tracker Sometimes you need to disable Tracker so that Tracker can leave the mix. Tracker is unable to leave the mix until it encounters a control point in the audit trail that it can designate as a restart point. At a restart point, Tracker writes control information to disk. To disable Tracker, issue a disable Tracker request. Because a restart point might not occur for several minutes, Tracker might stay in the mix for a relatively long period of time following a disable Tracker request

116 Preparing to Configure a Remote Database Backup System To minimize the delay involved with Tracker waiting for a restart point, you can take some steps to ensure that restart points occur more frequently, or you can cause a restart point to occur after you issue a disable Tracker request. What Governs the Frequency of Restart Points A restart point is created at a control point only. Therefore, unless the system establishes sufficient control points in the audit trail, Tracker performance cannot be positively influenced no matter how small you make the TRACKERFLUSHDB value. The frequency of restart points is governed by the value associated with the CONTROLPOINT option on the primary database as well as with the value associated with the TRACKERFLUSHDB option on the secondary database. You can use the Visible DBS command STATUS to view the current values for these options and use the Visible DBS command CHANGE to change the values. The actions and allowable values of the TRACKERFLUSHDB and CONTROLPOINT options are listed in the following table. Option Action Option Values TRACKERFLUSHDB CONTROLPOINT Specifies the interval between the time Tracker sets a restart point and the next time Tracker looks for a control point to make a restart point. Specifies the number of syncpoints that must occur before a new control point occurs. 10 minutes (default) 1 minute (minimum) 255 minutes (maximum) 2 (default) 1 (minimum) 4095 (maximum) Changing the Frequency of Restart Points To change the frequency of restart points, you change the TRACKERFLUSHDB setting, using the Visible DBS CHANGE command. For example, to alter the TRACKERFLUSHDB setting to 2 minutes, use the following syntax: <database stack mix number> SM TRACKERFLUSHDB = 2 You can display the current TRACKERFLUSHDB setting using the Visible DBS STATUS command as follows: <database stack mix number> SM STATUS A report similar to that shown in Figure 4 4 appears in the system messages. The information about the TRACKERFLUSHDB setting appears toward the end of the report

117 Preparing to Configure a Remote Database Backup System When a Restart Point Is Designated Tracker designates a restart point Upon encountering the first control point that occurs after the time interval specified by the TRACKERFLUSHDB option expires At the first control point of a new audit file, regardless of the TRACKERFLUSHDB and CONTROLPOINT option specifications When TRACKER designates a restart point, the TRACKERFLUSHDB timer is reset to 0 (zero). When applying audit images generated by a reorganization, Tracker also creates restart points After purging each row of a structure during the generation phase After processing the generation of a structure Figure 4 5 illustrates when restart points (RS) are taken, assuming that the TRACKERFLUSHDB option is set to 5 minutes and that control points (CP) occur after 4, 8, 15, and 21 minutes. RS1 RS2 RS3 ^ ^ ^ CP1 CP2 CP3 CP4 ^ ^ ^ ^ > (Time in minutes) Figure 4 5. Relation of Restart Points to Control Points Ways to Increase the Occurrence of Restart Points In some instances, you can speed up the creation of restart points by closing the audit file on the primary database. To increase the rate at which Tracker creates restart points, you can perform one or both of the following actions: Decrease the value of the TRACKERFLUSHDB option setting. Increase the occurrence of control points on the primary database. Related Information Topics For information about... Refer to... Control points DASDL Programming Reference Manual Disabling Tracker Section

118 Preparing to Configure a Remote Database Backup System For information about... Refer to... Visible DBS commands Enterprise Database Server Utilities Operations Guide

119 Section 5 Configuring a Remote Database Backup System In This Section In addition to an introduction to Remote Database Backup configuration tasks, this section explains the following Remote Database Backup configuration tasks in the order in which they are to be performed: Defining your Remote Database Backup system - Initializing and defining the primary and secondary hosts Enabling the Remote Database Backup system Testing the interhost connection Cloning the database on the secondary host - Making the required database files available on the secondary host - Specifying dump information and pack names for database structures on the secondary host - Identifying pack names for database software files on the secondary host - Specifying pack names for database guard files on the secondary host - Providing the titles of the DMCONTROL and DMUTILITY code files and memory management parameters on the secondary host - Selecting a method of running the clone operation Verifying the Remote Database Backup system Starting the secondary database after a clone operation - Synchronizing the databases after cloning with an online dump Configuration Tasks Introduction Configuring the Remote Database Backup capability for a database establishes a Remote Database Backup system in which that database is remote capable. If you have several databases that you wish to make remote capable, you must configure a separate Remote Database Backup system for each database

120 Configuring a Remote Database Backup System Remote capable refers to the Remote Database Backup capability of a given database, corresponding to the remote auditing flag in the database control file. The flag is set when the database is enabled through Database Operations Center and is reset when the database is disabled. The database can be open during all configuration tasks. Order of Tasks Before configuring a Remote Database Backup system for a database, you should first back up that database using the DMUTILITY program. The clone tasks must be performed as one continuous sequence in the order in which they are presented in this guide. Other configuration tasks should be performed in the sequence in which they are presented in this guide, but do not have to be performed at the same time or in the same session. Related Information Topics For information about... Refer to... DMUTILITY program Running Database Operations Center Enterprise Database Server Utilities Operations Guide Database Operations Center Help Defining Your Remote Database Backup System Introduction Once you have decided how you want your system to be configured, you must supply Database Operations Center with the information it needs to run the Remote Database Backup system according to your specifications. Refer to the Database Operations Center Help for details about the definition tasks. Initializing and Defining the Primary and Secondary Hosts What the Task Does This task creates the RDB control file that controls how the Remote Database Backup system operates. The RDB control file contains information that controls both database and Remote Database Backup system behavior at the primary and secondary hosts. Database Operations Center uses information from the database control file and from user input to create the RDB control file

121 Configuring a Remote Database Backup System RDB Control File Information The following table provides some information about the RDB control file. Information Item Where to initialize On the host containing the database Explanation Note: Database Operations Center designates the initializing host as the primary host. Name Location <database name>/rdb/control Two copies of the RDB control file are maintained one on each host. The file is located with the database control file. Contents Host information records one record each for the primary host and the secondary host Options and parameters for the participating hosts and for the database Run-time information for maintaining coordination between the hosts Procedure To initialize the RDB control file, on the Tools menu in Database Operations Center, point to Remote Database Backup, and choose Initialize the Remote Auditing Control File. The screen that appears asks for information about the primary host. Related Information Topics For information about... Refer to... Database control file Enterprise Database Server Utilities Operations Guide Database Operations Center Help Usercodes and packs Section 4 Testing the Interhost Connection What the Task Does This task tests the connection between the two hosts. This is primarily useful for verifying a new TCP/IP configuration but it can be used at any time with either the BNA or the TCP/IP network service. To test the connection from the primary host, the remote auditing

122 Configuring a Remote Database Backup System capability must be initialized but it does not need to be enabled. After the remote auditing capability has been enabled, it is recommended that the connection be tested from the secondary host in order to verify that communications work properly in both directions. When the test is initiated, an RDB server task will be started on the remote host (if one is not already running) and a test message will be sent to verify the connection. Then the file transfer configuration (FTP/NFT) will be tested by copying the RDB control file to the remote host under the name <dbname>/test/file_copy. This file will be removed from the remote host before the test completes. If the test fails there are several possible causes as described in the Troubleshooting section. Procedure To test the interhost connection, on the Tools menu in Database Operations Center, point to Remote Database Backup, and choose Test the Interhost Connection. Enabling the Remote Database Backup System What the Task Does This task sets the groundwork for establishing a duplicate database on the secondary host. As part of the groundwork, this task Closes the current audit file. Updates the database control file to indicate that remote auditing is enabled. The listing of the database control file includes CF REMOTE AUDITING = ENABLED Copies the database control file and the RDB control file to the secondary host under the ABW, AFS, and SCA audit file transmission modes. Under the NSC mode, the files must be transferred manually. Opens a new audit file. Under ABW mode, audit transfer begins one block at a time. Under AFS mode, audit transfer begins only after an audit file switch and continues as audit files are switched. Notes: You might find it helpful to note the number of the current audit file on the primary host before you begin the enable procedure. If your database is using guard files for security access, the enable task must be performed while running with a usercode that is defined in the guard file with update privileges. Procedure To enable the Remote Database Backup system, on the Tools menu in Database Operations Center, point to Remote Database Backup, and choose Enable the Remote Audit Capability

123 Configuring a Remote Database Backup System Related Information Topics For information about... Refer to... Defining a host information record Defining the Database Characteristics for the Secondary Host earlier in this section Cloning the Database on the Secondary Host Introduction Once you have enabled the database to be part of the Remote Database Backup system, you can perform the tasks that establish the database on the secondary host. The tasks ensure that the database and all its files are available on the secondary host. Clone Tasks The procedures for performing the tasks are summarized in the following table and presented in order in this section. Notes: All the clone tasks must be performed in the order shown. In addition, tasks 2 through 6 must be performed as one continuous sequence in the same session. If any of these clone tasks are omitted or not completed in the specified order, unpredictable results can occur. A remote copy of the database located at the secondary host (created by using the QUIESCE command) is recognized by a Remote Database Backup system as a complete, valid database source for a clone operation. The QUIESCE command and procedures required to create this remote copy of the database are documented in the Enterprise Database Server Utilities Operations Guide. All physical disks containing the database must be mirrored in order to clone from a QUIESCE copy. Task Description 1. Making required files available Makes the required database files available on the secondary host 2. Specifying dump information and pack mappings for structures Provides Dump names for tape or disk dumps Worker, cycle, version, serial number, and density values for tape dumps Secondary host locations for database structures 3. Identifying database file locations Identifies the secondary host packs on which the database software files reside

124 Configuring a Remote Database Backup System Task Description 4. Specifying guard file locations If guard files are used, identifies the secondary host packs on which the guard files reside 5. Providing Enterprise Database Server code file information and memory management parameters 6. Selecting the method of running the clone operation Provides the secondary host titles for the DMCONTROL and DMUTILITY code files and secondary host memory management parameters Selects one of three methods of running the clone operation, and optionally initiates the operation Making the Required Database Files Available on the Secondary Host What the Task Does During this task you make available specific files on the secondary host. The files can reside on any pack on the secondary host, but the files must reside under the same usercode on the primary and secondary hosts. Required Files The files that must be made available on the secondary host are as follows: Dump of the database You can copy a disk stream dump to the secondary host or make the tape dump available. Audit files, if any, created during and after the dump and up to the enable operation Under the SCA and NSC audit file transmission modes, audit files created after the enable operation up to but not including the current audit file These files must reside on the pack you specified for the secondary host on the Host screen. Database description file Copy this file to the same usercode and pack as the database control file. Database DMSUPPORT library Database RECONSTRUCT code file (if present) Guard files (if any) Tapeset directory (<multidump tape name>/tapesetdir/<date timestamp>), if using the Multidump feature. Refer to the following notes for additional information on the location of this file

125 Configuring a Remote Database Backup System Notes: If you performed an audited reorganization after you performed the dump with which you intend to clone the database, then you need to copy the database description file and DMSUPPORT files from before and after the reorganization as well as all the files pertaining to the reorganization. All the files must have the same name on the primary and secondary hosts. Under the ABW audit transmission mode, if you perform the dump after the enable operation and a communication failure occurs between the time of the enable operation and the time you perform the dump, then you must copy to the secondary host the audit file that was in use at the time of the dump. Copy this audit file before you clone the database. The tapeset directory for the Multidump feature must reside under the same usercode as on the primary host and on the LIBMAINTDIR pack. If the LIBMAINTDIR pack is not defined, then the tapeset directory must reside on the halt/load unit pack. The tapeset directory for the Multidump feature can be re-created on the secondary host instead of copying it from the primary host. However, it is recommended that this file be copied from the primary host. To decrypt an encrypted dump on a system other than the local system, you must first export from the local system the tape encryption keys used to encrypt the dump and then import these keys to the destination system. Refer to the MCP Cryptography Services Manager link in the Security Center Help for instructions on exporting and importing tape encryption keys. Procedure To make the required database files available on the secondary host, perform the following procedure

126 Configuring a Remote Database Backup System Step Action 1 Select either of the following means to make the required files available on the secondary host: Library maintenance procedures (for example, the CANDE COPY command) to copy the files through the network Copying the following files to tape and then onto the secondary host: Notes: - Dump of the database (if the dump is a disk stream dump) - Audit files, if any, created after the dump and up to the enable operation - Under the SCA and NSC audit file transmission modes, audit files, if any, created after the enable operation up to but not including the current audit file - Database description file - Database DMSUPPORT library - Database RECONSTRUCT code file (if present) - Guard files (if any) - Tapeset directory, if using the Multidump feature If the secondary host site is geographically distant and your files are very large, it might be appropriate to send the files on tapes to the secondary site instead of using library maintenance procedures. The Clone screen provides three optional fields to provide the family information for the database description file, the database DMSUPPORT library, and the database RECONSTRUCT code file. Each field that is provided produces an automatic copy of that file from the primary host to the secondary host at the time the clone operation is started. If a WFL file is being generated, the copy statements will be included in the WFL file. 2 Use library maintenance procedures (for example, the CANDE FILES command) to verify that the files you copied are resident in the appropriate locations on the secondary host. Related Information Topics For information about... Refer to... Clone operation while managing the Remote Database Backup system Database description file Database dumps DMSUPPORT library Section 8 DASDL Programming Reference Manual Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide

127 Configuring a Remote Database Backup System For information about... Refer to... Library maintenance CANDE Operations Reference Manual Providing a dump of the database Section 4 RECONSTRUCT code file REORGANIZATION program Reorganizations in the Remote Database Backup environment Tape encryption keys Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Section 9 Security Overview and Implementation Guide Security Center Help Specifying Dump Information and Pack Names for Database Structures on the Secondary Host What the Task Does This task specifies database dump information and structure pack mappings for the secondary host. This task is the first of several subtasks that create a backup copy (clone) of the database on the secondary host. The clone tasks must be performed as one continuous sequence in the order in which they are presented in the same session. The subtasks are listed under Clone Tasks earlier in this section. You can use any type of dump for cloning the database, including an incremental or an accumulated dump. Follow the same ordering of dumps that are required for a recovery operation. Ineffective Pack Combinations Certain combinations of pack mappings cannot be made by Database Operations Center. An example of a mapping that cannot be handled as intended follows: The following structure pack mappings are entered on the Clone screen: Primary Host Secondary Host PACKA PACKB PACKB PACKA

128 Configuring a Remote Database Backup System These structure pack mappings are passed as family statements to DMCONTROL, which processes them and reflects the changes in the database control file on the secondary host. The result of processing the first statement (FAMILY PACKA = PACKB) is that all structures on PACKA in the database control file are changed to PACKB. When the second family statement (FAMILY PACKB = PACKA) is processed, all matching structures are changed to PACKA. This includes those that were originally on PACKB and those that were changed to PACKB by the previous mapping. Therefore, no structures remain on PACKB. To effect the preceding pack mapping correctly, enter the structure pack mappings on the Clone screen in a pattern similar to the following: Primary Host Secondary Host PACKA PACKB X X PACKA PACKB Procedure To specify the names of the database dump and of the pack mappings for database structures, on the Tools menu in Database Operations Center, point to Remote Database Backup, and choose Clone the Database. Related Information Topics For information about... Refer to... Clone operation while managing the Remote Database Backup system Creating a database dump Database structures Density and serial numbers; worker, version, and cycle numbers Dump file attributes Section 8 Enterprise Database Server Utilities Operations Guide DASDL Programming Reference Manual Enterprise Database Server Utilities Operations Guide DASDL Programming Reference Manual Providing a dump of the database Section 4 Ordering a dump for a clone operation Section

129 Configuring a Remote Database Backup System Identifying Pack Names for Database Software Files on the Secondary Host What the Task Does This task identifies secondary host pack names for eight database files that might be located differently from the corresponding primary host database files. These are the same database files that can be specified in the DASDL source file. During the clone operation, Database Operations Center updates the copy of the database control file on the secondary host with the pack names you provide during this task. Refer to Database Operations Center Help for information about the database files and designating the pack names for the database files. Database Files The files are Accessroutines DMSUPPORT library Recovery program DMDATARECOVERY program RECONSTRUCT program REORGANIZATION program Primary audit copy job Secondary audit copy job Only the DMSUPPORT library pack specification is required. Providing pack names for the locations of the other files is optional but strongly recommended. The Remote Database Backup system uses the pack specification for the REORGANIZATION program to copy the REORGANIZATION program automatically from the primary host when a reorganization is performed. Procedure To designate the pack names for the database files, use Database Operations Center. Related Information Topics For information about... Refer to... Accessroutines DASDL Programming Reference Manual

130 Configuring a Remote Database Backup System For information about... Refer to... Changing database guard file pack names Clone operation while managing the Remote Database Backup system DASDL source files DMDATARECOVERY program DMSUPPORT library Guard files Primary audit copy job RECONSTRUCT program Recovery program REORGANIZATION program Secondary audit copy job Database files and designating pack names Enterprise Database Server Utilities Operations Guide Section 8 DASDL Programming Reference Manual Section 4 of this guide Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Security Operations Guide Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Database Operations Center Help Specifying Pack Names for Database Guard Files on the Secondary Host What the Task Does If you have database guard files, this task specifies pack names for these files on the secondary host. The guard files, using the Accessroutines, control access to the database files. Procedure To specify pack names for guard files on the secondary host, use the series of Clone screens

131 Configuring a Remote Database Backup System Related Information Topics For information about... Refer to... Clone operation while managing the Remote Database Backup system Creating guard files Guard file access to Remote Database Backup processes Specifying guard files Section 8 DASDL Programming Reference Manual Section 4 Security Features Guide Providing Code File Titles and Memory Management Parameters on the Secondary Host What the Task Does This task specifies to Database Operations Center the titles of the DMCONTROL and the DMUTILITY code files on the secondary host. These files were loaded onto the secondary host when the Enterprise Database Server software was installed on that system, and they are required by the clone operation. This task also identifies memory management parameters to be used at the secondary host. Because of differences in machine size or loads, it may be necessary to set values for ALLOWEDCORE, OVERLAYGOAL, and RESIDENT LIMIT at a secondary database that are different from those at the primary database. Procedure To provide the titles of the DMCONTROL and the DMUTILITY code files on the secondary host and the memory management parameters for the secondary host, use Database Operations Center. Related Information Topics For information about... Refer to... Clone operation while managing the Remote Database Backup system DMCONTROL code file DMUTILITY code file Section 8 Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide

132 Configuring a Remote Database Backup System Selecting a Method of Running the Clone Operation What the Task Does This task selects the method of running the clone operation on the secondary host and optionally initiates the clone operation. Factors Affecting Your Selection Some factors differentiate the three methods of running the clone operation: Timing of the clone operation Your need for a saved copy of the clone job Your need to perform other Database Operations Center tasks while the clone operation is in progress Methods of Running the Clone Operation The following table lists the methods and how these factors apply to each of them. Method Job/Action Considerations 1 Performs the clone operation online. 2 Creates and starts a WFL job and optionally saves the job. 3 Creates and saves a WFL job without starting it. If the clone operation is initiated from the primary host, the primary database should not be opened during the clone operation. If the primary database is open, the database activity might stop until the clone process is complete. The job restarts automatically if a problem occurs. If you save the WFL job, you may be able to use it later if a clone situation arises. You can perform other tasks from this session while the WFL job is running. The WFL job is written, but you can postpone running the job until a convenient time. The job restarts automatically if a problem occurs. You might also be able to reuse the WFL job later if a clone situation arises. Advantages of Creating a WFL Job and Saving It Methods 2 and 3 provide you with a WFL job that, if saved, gives you the following advantages:

133 Configuring a Remote Database Backup System You can easily restart the WFL job if a problem arises when the job runs. If a clone operation is needed later, the saved WFL job can be reused (possibly with modifications) instead of performing the clone procedures through Database Operations Center again. If you choose method 3, you also have the following advantages: If clone dump tapes are still being moved, or audit files are still being copied, to the secondary host, you can choose to initiate the WFL job after the dump and audit files are available on the secondary host. You can run the WFL job during off-hours and test the secondary database when your users are not accessing the primary database. WARNING When using the TCP/IP network service instead of BNA, passwords will be visible in clear text in a saved WFL job. Therefore, this file must be secured or the passwords should be removed from the file when it is not in use. If neither is possible or practical, then either do not save the WFL job or perform an online clone instead of using a WFL job. Clone WFL Job By default, the clone WFL job is called WFL/CLONEDB/<databasename>/AT/<secondary host name> Whatever name you assign to the WFL job, the job appears in the mix as CLONEDB. For ease of reference in this section, the clone WFL job is referred to as the CLONEDB job. The CLONEDB job initiates the following tasks in order: 1. Runs the DMCONTROL code file to Reset a flag in the RDB control file. Update the pack location of the DMSUPPORT library in the database control file so that the DMUTILITY code file can link to the library when it runs. 2. Runs the DMUTILITY code file to load the dump and create the secondary copy of the database through the initiation of the database TAPECLONE function. This function is exclusive to Remote Database Backup. 3. Runs the DMCONTROL code file to Set a flag in the RDB control file. Update the database control file on the secondary host with pack name changes for structures and guard files, if any are specified

134 Configuring a Remote Database Backup System Caution If you change pack names or make other modifications to your Remote Database Backup system after the clone WFL job is saved, the information in the saved WFL job for the clone operation will be out-of-date. Modify the saved WFL job for the clone operation so that it matches the modified Remote Database Backup system. Procedure To select the method of running the clone operation, use the series of Clone screens. When the Secondary Database Is Inquiry Capable After a successful clone operation, the secondary database is not always immediately available for inquiry purposes. The secondary database becomes available after Tracker has applied the required audit information. If the dump used for the clone operation was created prior to the enable operation, you must make available on the secondary host all audit information created between the time of the dump and the time of the enable operation. The database is not available under the AFS, SCA, and NSC modes until the audit file created by the enable operation is available and acknowledged on the secondary host. Related Information Topics For information about... Refer to... Audit transmission modes Sections 1, 2, 3, and 4 CANDE CLONEDB sample program Clone operation while managing the Remote Database Backup system Managing WFL jobs MARC TAPECLONE function CANDE Operations Reference Manual Appendix A Section 8 WFL Reference Manual MARC Operations Guide Enterprise Database Server Utilities Operations Guide

135 Configuring a Remote Database Backup System Verifying the Remote Database Backup System Introduction After the clone operation completes, you should verify that it has been successful and that the Remote Database Backup system is functioning properly. Procedures To verify that the configured Remote Database Backup system is functioning correctly, perform one or more of the following procedures using small test programs. Notes: For the following two procedures, assume that no programs are allowed to update the database until you perform these procedures. Under AFS, SCA, and NSC modes, also assume that the audit file created by the enable operation has already been transferred to the secondary host and acknowledged. The results of the following procedures might take some time to display. Checking on Catchup or Tracker Step Action 1 On the secondary host, run a test inquiry program against the database. 2 Check the mix on the secondary host for Tracker. If the Catchup task is needed, it also appears in the mix. The following message appears while the inquiry program is waiting: WAITING FOR TRACKER QUIET POINT TO ALLOW INQUIRY When a quiet point occurs, the following message appears: AVAILABLE FOR INQUIRY Running a Remote Database Backup Report After checking on Catchup or Tracker, run a Remote Database Backup report using the View Remote Auditing Status screen. Ensure that you verify the values on this screen. Testing Inquiry and Update Programs Step Action 1 Start a test inquiry program on the primary host and on the secondary host. 2 Verify that the inquiry programs are running successfully on each host

136 Configuring a Remote Database Backup System Step Action 3 Start an update program on the primary host. 4 Verify the transmission of audit images so that you can perform a Report operation on either host. In the received and applied AFN and ABSN fields of the View Remote Auditing Status screen, verify that the values are in line with the proper functioning of the audit file transmission mode and the probable rate of audit generation on the primary host. If there is any problem with the audit transmission, wait until the update program is complete, and then determine and correct the audit transmission problem. 5 Start an update program on the secondary host. When the program attempts to enter transaction state, ensure that you receive an error message from the secondary database indicating that the database cannot be updated. If you do not receive an error message, ensure that you are running the update program on the secondary host. If your Remote Database Backup configuration did not complete successfully, consult Section 12 on troubleshooting to ascertain what went wrong and then retry the clone operation. Starting the Secondary Database After a Clone Operation Conditions of Starting What happens when you start the secondary database after a clone operation depends on the type of dump you used for the clone operation: With an offline dump of the entire database, you can access the secondary database immediately because the secondary database is synchronized with the primary database. With an online dump, you might not be able to access the secondary database until Tracker has processed the audit images required to bring the database up-to-date. Actions That Initiate Tracker Following the clone operation, one of the following actions starts Tracker: In ABW mode, the transfer of audit blocks from the primary host In AFS, SCA, and NSC modes, the transfer and acknowledgment of an audit file or audit files A program on the secondary host that accesses the database

137 Configuring a Remote Database Backup System Synchronizing the Databases After Cloning with an Online Dump The following text describes synchronizing the primary and secondary databases after using an online dump for a clone operation. Synchronization processes differ depending on the audit file transmission mode under which your Remote Database Backup system runs. Automatic Synchronization Under the ABW Mode Under the ABW audit transmission mode only, when you open the secondary database following the clone operation, Remote Database Backup attempts to synchronize the primary and secondary audit trails by tracking through all secondary host audit files that are present, and known or acknowledged, beginning with the audit file in use at the time of the dump. After tracking through all known audit files, Remote Database Backup begins a Catchup process if necessary to obtain any audit information that is not present on the secondary host but is required for synchronization. The Catchup process is as efficient as a file copy operation, so there is no need to transfer audit files to the secondary host by copying the files. The audit files must, however, be present on the primary host. Manual Synchronization Under AFS, SCA, and NSC Modes Under the AFS, SCA, and NSC audit transmission modes, before you open the secondary database following the clone operation, ensure that the audit files that Tracker requires to apply audits to the secondary database are available on the secondary host. Audit Files That Tracker Requires Tracker requires the following audit files before it can begin applying audits to the secondary host: Audit file in use at the start of the dump used in the clone operation Tracker might also need the audit file prior to the audit file in use at the start of the dump if the last control point is in the previous audit file. Subsequent audit files up to and including the audit file identified by the received AFN value displayed on the View Remote Auditing Status screen If the database dump was created before the database was enabled, all audit files created between the time of the dump and the time of the enable operation If the required audit files are not present on the secondary host, Tracker waits on a NO FILE condition

138 Configuring a Remote Database Backup System Received AFN Under the ABW and AFS Modes In the ABW and AFS audit transmission modes, the Remote Database Backup software automatically maintains the received AFN value. Under these modes, you can observe the received AFN value displayed in the Received AFN field on the View Remote Auditing Status screen. However, events preceding a clone operation can sometimes cause this value to be different from the AFN value that Tracker requires following the clone operation. When such an event occurs, you must manually acknowledge the most recently received audit file before opening the secondary database following a clone operation. Supplying the Audit Files That Tracker Requires To supply the audit files that Tracker requires, perform the following procedure. Step Action 1 Check to see whether the audit files listed under Audit Files That Tracker Requires reside on the secondary host. 2 Perform one of the following actions: If the required files reside on the secondary host, go to step 3. If the required files do not reside on the secondary host, copy them from the primary host. 3 Check to see whether Tracker has started to apply audits. 4 Perform one of the following actions: If Tracker has started, the procedure is complete. If Tracker has not started, go to step 5. 5 Check to see whether the received AFN value on the View Remote Auditing Status screen correctly indicates the most recent audit file present on the secondary host. 6 Perform one of the following actions: If the received AFN value is equal to the number of the most recent audit file present on the secondary host, Tracker should start. Ensure again that all required audit files are present on the secondary host. If the received AFN is not equal to the number of the most recent audit file present on the secondary host, go to step 7. 7 Use the Acknowledge function to acknowledge the most recent audit file present on the secondary host. Then verify that the received AFN value on the View Remote Auditing Status screen has changed to the value of the audit file you acknowledged

139 Configuring a Remote Database Backup System Related Information Topics For information about... Refer to... Audit transmission modes Sections 1, 2, 3, and 4 Audit synchronization Sections 1 and 4 CLONEDB sample program Clone operation while managing the Remote Database Backup system Appendix A Section 8 Received AFN Section 7 Tracker Sections 4 and

140 Configuring a Remote Database Backup System

141 Section 6 Performing Takeovers In This Section This section explains how to perform Remote Database Backup takeovers, including Overview of a takeover Performing takeover tasks - Terminating update programs - Transferring and applying audit images - Estimating lost transactions - Establishing the new primary host - Establishing the new secondary host Managing the Transaction Server synchronized recovery Overview of a Takeover Definition of a Takeover A Remote Database Backup takeover is a process that enables the secondary database to assume, or take over, the role of the primary database. Two processes must occur to complete a takeover: The original secondary database must change into a primary database. This change begins immediately after you request the takeover by designating the new primary host name. After your request, sometimes the database requires a short interval during which it completes processing similar to a halt/load recovery. When the change is completed and the database becomes available, applications can update the database. After the change, this database is called the new primary database. The original primary database must change into a secondary database. This change occurs either automatically when the new primary host is established or manually at a later time. The change must be complete before the database is reopened after the takeover. When the change is complete, this database is called the new secondary database. Applications can access the database for inquiry only, and Remote Database Backup maintains audit synchronization

142 Performing Takeovers Considerations Before Performing a Takeover You should consider performing a takeover when you know that the primary database will be unavailable for an extended period of time. In some instances, it might be less disruptive to wait for the original primary to become available again rather than to do a takeover. Your decision to perform the takeover should be based on several considerations: If the primary host or the network has failed, the time required to restore them If the database has been damaged, the time required to restore the primary database using normal Enterprise Database Server recovery techniques If the audit trails on the two hosts are not synchronized, the time required to synchronize the audit trails If the audit trails cannot be synchronized because of primary host or network failure, the impact of losing transactions or having to reprocess transactions When to Perform a Takeover In general, a takeover might be warranted under two circumstances: When the primary host will be unavailable for an extended period of time because of planned activities such as routine system maintenance A takeover performed under these circumstances is called a planned takeover. Typically, communication can be maintained between the two hosts during a planned takeover if the audit transmission mode is ABW, AFS, or SCA. When the primary host suddenly becomes unavailable for an extended period of time, possibly because of a system failure A takeover performed under these circumstances is called an unplanned takeover. Typically, the hosts cannot communicate during an unplanned takeover, and this lack of communication creates additional responsibilities for the system operators. Performing Takeover Tasks Introduction Whether you perform a planned or unplanned takeover, your success depends on your ensuring minimal transaction loss and minimal disruption of database access. The takeover process includes the following tasks: 1. Terminating update programs 2. Transferring and applying audit images to the original secondary host 3. Estimating lost transactions, if any 4. Establishing the new primary host 5. Establishing the new secondary host

143 Performing Takeovers Terminating Update Programs The first step of any takeover process is to terminate normally all update programs on the primary database, assuming in an unplanned takeover that this action is possible. This action enables you to ensure that the audit trails of the primary and secondary hosts are synchronized before you initiate the takeover function of the Database Operations Center. It is not necessary to terminate inquiry applications on the primary database. However, if you do not terminate update applications before initiating the takeover, the system terminates abnormally the database stack and all applications accessing the primary database (both inquiry and update). In addition, halt/load recovery delays access to the database when the database is reopened. Transferring and Applying Audit Images The second step of the takeover process is to ensure that all audit images generated by the primary database have been transferred and applied to the secondary database if possible. You can use the View Remote Auditing Status screen to verify that the applied ABSN on the secondary database matches the current ABSN of the primary database. If the current and applied ABSNs are not equal, to achieve audit synchronization, you must perform one of the following actions: Under ABW mode, allow the Catchup process to complete, or manually copy and acknowledge the required audit files. Under the AFS, SCA, and NSC modes, copy and acknowledge the required audit files. Estimating Lost Transactions Introduction The third step of the takeover process is to estimate lost transactions, if any. How Synchronization Affects Transaction Loss The potential for transaction loss is related to the degree of audit trail synchronization that is present before you perform the takeover. If your Remote Database Backup system is configured to run under ABW mode, audit images for all transactions completed on the primary host might be resident on the secondary host but not necessarily. Under the AFS, SCA, and NSC modes, usually some audit images on the original primary host will not have been transferred to the secondary host

144 Performing Takeovers If you cannot complete the transfer of audit images to the secondary host before the takeover, the transactions that generated those audit images on the original primary host will not have been applied to the new primary database when the new primary database becomes available for update after the takeover. You must, therefore, identify the transactions and resubmit them to the new primary database if it is important to retain them. How to Estimate Lost Transactions If the primary host becomes unavailable and synchronizing the audit trail is impossible, you must estimate the extent of lost transactions. Display the View Remote Auditing Status screen and perform one of the following actions depending on the mode under which your Remote Database Backup system is running: Under the ABW and AFS modes, compare the timestamp of the received ABSN with the time of the primary host failure. Under the SCA and NSC modes, the received ABSN is not displayed on the View Remote Auditing Status screen. Therefore, you must compare the received AFN with the number of the current audit file at the primary host. As an alternative, you can also use the PRINTAUDIT program to determine the timestamp of the last block in the most current audit file at the secondary host and compare that value with the time of the primary host failure. You must also verify that the audit file shown on the View Remote Auditing Status screen reflects the most current audit file resident on the secondary host. Identifying Lost Transactions To identify lost transactions, you can perform one or more of the following actions: Use PRINTAUDIT to compare the primary and secondary audit trails to determine where they diverge. Use PRINTAUDIT to identify specific transactions that were not received on the secondary host when the primary database became unusable. Handling Multiple Takeovers After a takeover when the new primary database has been updated under the AFS, SCA, or NSC mode, the current audit file on the new primary host can contain more audit blocks than the audit file of the same number that resides on the new secondary host. Before you perform a second takeover to restore the hosts to their original roles, you must copy the audit file from the new primary host to the new secondary host. Otherwise, transactions can be lost and the database might need to be cloned

145 Performing Takeovers Establishing the New Primary Host Introduction The fourth step in the takeover process is to establish the new primary host. You establish the new primary host by initiating a takeover operation. The takeover can be performed at either host. However, if the hosts are not communicating, you must perform this takeover at the original secondary host. The results of this takeover are If your Remote Database Backup system operates under the ABW, AFS, or SCA mode, and if the hosts are communicating, this procedure is sufficient to change both hosts to their new roles. If your Remote Database Backup system operates under the NSC mode, or if the hosts are not communicating while you perform this procedure, the original secondary host only is changed into the new primary host. To change the original primary host into the new secondary host, you must perform another takeover. Notes: Perform the procedure to establish the original primary host as the new secondary host as soon as the original primary host is available and before update programs are allowed to open the database on the original primary host. It is recommended that you initiate a dump of the new primary database immediately after a takeover. A dump helps to ensure a successful rebuild recovery should one become necessary, because rebuild recovery does not attempt to use the pack mappings between the primary and secondary hosts that were defined as part of the clone process. Rebuild recovery attempts to rebuild the database using the pack names of the system from which the dump originated. Procedure To establish the new primary host, terminate all update programs that are accessing the primary database (if possible). Next, if possible, transfer audit images from the primary host to the secondary host. If the audit transmission mode is AFS, SCA, or NSC, or if the audit trails are not synchronized under ABW mode, transfer and acknowledge any audit files containing audit images that have not yet been transferred to the secondary host. This transfer includes the current audit file, which is not full and would not normally be transferred at this time. Under the ABW mode, if the audit trails are not synchronized and you plan to copy the audit files manually, you must first close the secondary database. Then copy the audit files and reopen the secondary database. If you use the duplicate audit capability of Enterprise Database Server, copy both copies of the current audit file to the secondary host. On the secondary host, run Database Operations Center and select the Takeover screen

146 Performing Takeovers Takeover Confirmation Messages for Establishing a New Primary Host One or more confirmation messages appear when you perform a takeover in the preceding task. The messages depend on the conditions surrounding the takeover. The text of the confirmation messages follows, along with an explanation of the consequences of continuing with the takeover. If more than one message appears, then you need to consider the consequences for each message. <original primary host name> is currently defined as primary. Consequences of continuing: Under the ABW, AFS, or SCA mode, both hosts are changed. Under NSC mode, only the original secondary host is changed to the new primary host. Later you must initiate a takeover for the original primary host and change it to the new secondary host. Port file communication could not be established between hosts <original secondary host name> and <original primary host name>. Consequences of continuing: Under the ABW, AFS, or SCA mode, the original secondary host is changed to the new primary host. Later you must initiate a takeover on the original primary host and change it to the new secondary host. <database name> is open update on <original primary host name> and will be terminated if you choose to continue. Consequences of continuing: The database on the original primary host is discontinued. Under the ABW, AFS, or SCA mode, both hosts are changed. When the database on the original primary host is reopened, halt/load recovery runs. Recommendation: To avoid discontinuing the original primary database and to avoid the subsequent running of halt/load recovery and a possible clone operation, it is recommended that you terminate normally all update programs before continuing with the takeover. Port file communication could not be established to <original secondary host name>. Note: This message appears only when you initiate the takeover from the original primary host. Consequences of continuing: The original primary host is changed to the new secondary host. Later you must initiate a takeover on the original secondary host and change it to the new primary host. You may need to clone the database on <original primary host name> as <database name> is open update on <original secondary host name>. Consequences of continuing: In this duplicate-primary-host situation, the host whose name you specified in the Enter new primary host name field remains a primary host and the other host is changed to the new secondary host

147 Performing Takeovers <database name> has the Open/OLTP option set which may result in partial or missing global transactions. Consequences of continuing: Global Open Distributed Transaction Processing transactions require manual investigation. A structure clone is required on <original secondary host name>. Consequences of continuing: Under the ABW, AFS, or SCA modes, both hosts are changed. Under NSC mode, only the original secondary host is changed to the new primary host. Later, you must initiate a takeover for the original primary host and change it to the new secondary host. For all modes, after the takeover, you must perform a structure clone operation on the new primary host using the dump taken after the offline reorganization on the original primary host. If an attempt is made to open the database before the structure clone operation is completed, the error message DMOPENERROR #103 (STRUCTURECLONE IS REQUIRED) is issued. When a Structure Clone Is Required If you perform a takeover when a structure clone is required on the secondary database, then you must perform the structure clone on the new primary host using the dump taken after the offline reorganization of the original primary host. If you try to open the database before performing the structure clone operation, the system displays the following DMOPENERROR 103 message: STRUCTURE CLONE REQUIRED If a takeover occurs when a structure clone is required on the secondary database and no database dump is available for the reorganized structure or structures, you must perform a rebuild recovery at the new primary host using a dump taken before the reorganization. Handling a Duplicate Primary Host Situation You cannot always prevent some automatic functions from opening the database after an original primary host comes back online after a failure and before you have been able to convert the original primary host to the new secondary host. You can respond to the messages that display by establishing the original primary host as a new secondary host. The functions to which messages alert you are as follows: Reopening of the old primary database, or if the new primary database is closed and then reopened after the original primary host is back online The following message appears at the host where the database is attempting to open: <remote host> IS AN <active/inactive> RDB PRIMARY (AT AFN=nnnn, ABSN=nnnn, mm/dd/yy hh:mm:ss) THIS HOST IS ALSO AN RDB PRIMARY (AT AFN=nnnn, ABSN=nnnn, mm/dd/yy hh:mm:ss) THE TAKEOVER DOCUMENTATION MAY HELP TO RESOLVE THIS PROBLEM Sending of audit images between the hosts in either direction The following message is displayed at both hosts:

148 Performing Takeovers AN ATTEMPT WAS MADE TO SEND AUDIT TO A PRIMARY Establishing the New Secondary Host Introduction The fifth step in the takeover process is to establish the new secondary host if the new secondary host was not established when you established the new primary host. This step is required under the NSC mode or after an unplanned takeover. Note: :It is important to establish the new secondary host before performing another takeover to restore the original configuration. Establishing the new secondary host allows any necessary recovery and resynchronization to occur. How you activate and use the new secondary host depends on whether the audit trails were synchronized before the takeover. When Audit Trails Were Synchronized If you believe the audit trails on the two hosts were perfectly synchronized at the time of the takeover, you should allow the new secondary database to open. Under the AFS, SCA, and NSC modes, copy and acknowledge all full audit files created on the new primary host since the takeover. Under ABW mode, open the database and monitor the Catchup process. When Audit Trails Were Not Synchronized Remote Database Backup requires a cloning of the database when audit trails were not synchronized at the time of a takeover. Performing a clone operation before attempting to open the new secondary database is less disruptive for users of this database. Otherwise, events similar to the following can occur: The new primary host initiates communication by sending an audit block to the new secondary host. When the new secondary host receives the audit block, the system displays the message CLONE REQUIRED. The new secondary host initiates host communication, and the Catchup-server task on the new primary host might encounter an audit error and then display the message ACCEPT:ENTER OK TO REPOSITION AND RETRY. This message might also mean that a clone operation is required. You can use a dump of the new primary database or a dump of the old primary database for the clone operation. The old primary database must have been dumped before the start of any transactions that were not applied to the old secondary database prior to the takeover. In addition, any audits not applied to the new primary database should be removed from the new secondary host prior to the clone operation

149 Performing Takeovers Procedure for Establishing the New Secondary Host You establish the new secondary host by initiating a takeover from the original primary host. You must perform this takeover if your Remote Database Backup system operates under the NSC mode, or if the hosts were not communicating while you performed the takeover to establish the new primary host. Note: You must change the original primary host to the secondary host after you have established the new primary host. Make this change as soon as the original primary host becomes available. Otherwise, update programs might attempt to open the original primary database. In modes other than NSC, Remote Database Backup requires an operator response before allowing database access to these programs. The operator must respond with a DS command to prevent access by these programs until the new secondary host is established. If these programs are not discontinued, the act of the OPEN UPDATE causes an audit block to be written and then a clone operation is required to restore synchronization. Takeover Confirmation Messages for Establishing a New Secondary Host One or more confirmation messages might appear. The messages depend on the conditions surrounding the takeover. The text of the confirmation messages follows, along with an explanation of the consequences of continuing with the takeover. If more than one message appears, then you need to consider the consequences for each message. <original primary host name> is currently defined as primary. Consequences of continuing: The original primary host is changed to the new secondary host. Port file communication could not be established between hosts <original secondary host name> and <original primary host name>. Consequences of continuing: The original primary host is changed to the new secondary host. <database name> is open update on <original primary host name> and will be terminated if you choose to continue. Consequences of continuing: The database on the original primary host is discontinued. The original primary host is changed to the new secondary host. A clone operation is probably required. Recommendation: Allow the database to be discontinued. If the database terminates normally, audit records related to the closure are written and a clone operation is required. However, even if the database is discontinued, a clone operation might still be required. You may need to clone the database on <original primary host name> as <database name> is open update on <original secondary host name>

150 Performing Takeovers Consequences of continuing: In this duplicate-primary-host situation, the database on the original primary host is discontinued, and the original primary host is changed to the new secondary host. A clone operation is probably required. <database name> has the Open/OLTP option set which may result in partial or missing global transactions. Consequences of continuing: The original primary host is changed to the new secondary host. Global Open Distributed Transaction Processing transactions require manual investigation. A structure clone is required on <original secondary host name>. Consequences of continuing: The original primary host is changed to the new secondary host. Later you must perform a structure clone operation on the new primary host using the dump taken after the offline reorganization on the original primary host. If an attempt is made to open the database before the structure clone is completed, the error message DMOPENERROR #103 (STRUCTURECLONE IS REQUIRED) is issued. Managing the Transaction Server Synchronized Recovery Introduction While transferring audit images to the secondary host, Remote Database Backup does not transfer Transaction Server transaction trail information. Each time a takeover is required, you must reestablish the Transaction Server transaction trail feature before allowing users to access the new primary database. Procedure To reestablish the Transaction Server transaction trail feature, perform the following procedure. Step Action 1 Disable the Transaction Server database. 2 Use the DRC option in the COMS Utility to create a new Transaction Server transaction trail and to set the RDS pointer to the end of the new Transaction Server transaction trail. 3 Reenable the Transaction Server database

151 Performing Takeovers Related Information Topics For information about... Refer to... Audit transmission modes Sections 1, 2, 3, 4, and 5 Clone operation Sections 5 and 8 Error-handling options for ABW mode Sections 2, 3, 4, and 5 Job queues and queue attributes System Administration Guide Programmatic takeover Section 14 Rebuild recovery Section 10 Enterprise Database Server Utilities Operations Guide Task attributes Transaction Server synchronized recovery Task Attributes Reference Manual Transaction Server Operations Guide Transaction Server Programming Guide

152 Performing Takeovers

153 Section 7 Monitoring Your Remote Database Backup System In This Section This section explains how to keep track of the activity on your Remote Database Backup system, including Overview of Remote Database Backup monitoring Accessing messages Accessing the current state of audit transfers Accessing cumulative Remote Database Backup statistics Interpreting Remote Database Backup statistics Accessing database statistics on Remote Database Backup performance Overview of Remote Database Backup Monitoring Dimensions of Monitoring Monitoring the Remote Database Backup system is an important aspect of using Remote Database Backup successfully. The Remote Database Backup monitoring task has a broad focus because the Remote Database Backup system interacts with other software operating on the Remote Database Backup hosts. The Remote Database Backup system and other software mutually impact each other s performance. When you run Remote Database Backup with the ABW or AFS audit transmission modes, there is a direct correlation between the performance of Remote Database Backup and the databases, the network, the host systems, and the database applications. Goals of Monitoring Before you installed the Remote Database Backup software, you should have assessed the performance of your host systems, database, and other software. The purpose of the assessment was to ensure a well-configured and supported Remote Database Backup system

154 Monitoring Your Remote Database Backup System As you run your Remote Database Backup system, you should take the same care in monitoring how the Remote Database Backup system performs and how other software on your system is impacted by the use of Remote Database Backup. For instance, ask the following questions: Is Remote Database Backup performing according to my expectations? How does the performance of my programs under Remote Database Backup compare to their performance before the Remote Database Backup system was configured? If the performance has changed, what factors have caused the change? Is there a way to enhance the performance of one program and not lose performance from others? The goal of monitoring is to determine the adjustments you can make to tune the system so that Remote Database Backup and other software can perform efficiently. How to Get the Most from Monitoring To get the most from monitoring Remote Database Backup, you need to set up a system to track the statistics available to you. Then you must assess these statistics in relation to statistics collected at other time periods and in relation to statistics of other programs in the same and different time periods. Such a tracking system is necessarily unique to your site. The monitoring tools explained in this section can help you obtain useful information and might help you to devise your tracking system. Monitoring Tools The monitoring tools explained in this section include Messages that provide you with immediate feedback on Remote Database Backup and other system functions Remote Database Backup reports on the current audits being sent and applied Cumulative Remote Database Backup statistics focusing on audit transmission rates over specific time periods of ABW mode activity Statistics that provide database-specific performance information collected by the database system software Accessing Messages Immediate Feedback on System Functioning The most common and immediate way of monitoring the Remote Database Backup system is by watching and reading system messages and Remote Database Backup messages. It might help you to note the types of messages that appear frequently. For example, if you frequently receive port-i/o error messages, look at both the primary and

155 Monitoring Your Remote Database Backup System secondary hosts for either network messages or messages from Remote Database Backup tasks or tasks that access a Remote Database Backup database to find the cause and apply a solution quickly. Frequently repeated messages can indicate areas of smooth functioning as well as areas where problems exist. Procedure to Access Messages To display messages for Remote Database Backup system activity, you can use any message command available on your system. Some of the most commonly used commands are listed in the following table. The ability to use CANDE and MARC to display information is dependent on the usercode of the CANDE/MARC session and the usercode under which the network or Remote Database Backup tasks are running. Information Displayed CANDE Commands MARC Commands System Commands Mix information?m JOBS AA System messages?msg SMSG MSG Completed jobs and tasks?c C C Scheduled tasks?s S S Waiting tasks?w W W Related Information Topics For information about... Refer to... CANDE commands MARC commands System commands CANDE Operations Reference Manual MARC Operations Guide System Commands Reference Manual Accessing the Current State of Audit Transfers When To Do This Task Access the current audit transfer information to determine whether

156 Monitoring Your Remote Database Backup System The Remote Database Backup system is enabled. The database needs to be structure cloned. The database needs to be cloned. Primary Factors Affecting Auditing Status Updates When the primary and secondary hosts are communicating, the information displayed on the View Remote Auditing Status screen depends primarily on the following factors: The host from which you access the screen The audit transmission mode set on the primary and secondary hosts Information is updated except when the audit transmission mode of the accessing host is NSC or when the hosts are not communicating. In these instances, information about the remote host is not updated on the accessing host. Other Factors Affecting the Information Displayed Other factors also affect the information displayed. For example, Fields concerning applied audits are filled when Tracker is in the mix on the secondary host and blank when Tracker is not in the mix. When the Remote Database Backup system is disabled, the audit fields are blank on the primary host, and the data displayed on the secondary host is invalid. Under the SCA and NSC audit transmission modes, the fields Received ABSN and Received Timestamp are blank. When to Display Remote Database Backup Auditing Status Information You can display Remote Database Backup auditing status information whenever you are curious about the flow of audits on your Remote Database Backup system. Situations in which auditing status information might be particularly helpful to you are when you See a Catchup task in the mix and want to check on audit transmissions Are uncertain whether you need to clone the database Need to check on the flow of audits between the hosts Want to note the current audit file number before you initiate a database dump Are planning a takeover, and want to ensure that the audit trails are synchronized or need to determine the amount of data that is likely to be lost if the audit trails are not synchronized Want to know which audit transmission modes are designated for the primary and secondary hosts

157 Monitoring Your Remote Database Backup System Procedure To access Remote Database Backup remote auditing status, on the Tools menu in Database Operations Center, point to Remote Database Backup, and choose View Remote Auditing Status. Remote Database Backup Report Information The following tables briefly explain the information on the View Remote Auditing Status screen. General Database Information Information Item Database name Remote Database Backup capability Full clone required Structure clone required Explanation Name of the database for which the Remote Database Backup system exists One of two words indicating the state of remote auditing for the primary host: Enabled means Remote Database Backup can send audits automatically to the secondary host. Depending upon the audit transmission mode that is set, automatic transfer of audits can take place. Disabled means Remote Database Backup is disabled as a result of issuing a successful DISABLE command or of having never performed an enable operation on the database. One of two words indicating whether the secondary database needs to be cloned: Yes means a full clone operation is required or a clone operation in progress has not yet completed. No means a full clone operation is not required. Under NSC mode, this field is blank. One of two words indicating whether reorganized structures need to be structure cloned on the secondary host: Yes means a structure clone operation is required or a structure clone operation in progress has not yet completed. No means a structure clone operation is not required. Under NSC mode, this field is blank

158 Monitoring Your Remote Database Backup System Current Primary Host Audit Information Information Item Explanation Primary host Current AFN, ABSN, Timestamp Audit transmission mode Name of the primary host Audit file number, audit block serial number, and timestamp in use on the primary host Mode of audit transfer designated from the primary to the secondary host Note: The timestamp indicates the date and time the audit image was created on the primary host. Current Secondary Host Audit Information Information Item Explanation Secondary host Received AFN, ABSN, Timestamp Applied AFN, ABSN, Timestamp Control record applied ABSN, Timestamp, Date Audit transmission mode Name of the secondary host Audit file number, audit block serial number, and timestamp of the last audit block received at the secondary host Audit file number, audit block serial number, and timestamp of the last audit block applied to the secondary database Audit block serial number, timestamp, and date of the last control record applied to the secondary database Mode of audit transfer designated from the secondary to the primary host Note: All timestamps and the date indicate the date and time the audit image was created on the primary host Updating of the Current ABSN Value The Current ABSN value displayed on the View Remote Auditing Status screen on the primary host is the last ABSN transmitted to the secondary host. Remote Database Backup maintains the current ABSN value in memory on the primary host, and periodically writes the value to the RDB control file on the primary host. When Remote Database Backup reinitializes after a halt/load on the primary host, Remote Database Backup retrieves the current ABSN value from the RDB control file. Depending on the interval between the last update of the RDB control file and the halt/load, the value retrieved by Remote Database Backup might not be up-to-date. If the current ABSN value is not up-to-date and you access the View Remote Auditing Status screen while the database on the primary host is recovering, the current ABSN value you see on the screen is less than the last ABSN received on the secondary host. As

159 Monitoring Your Remote Database Backup System soon as the primary host has recovered from the halt/load and transmits the first audit block, Remote Database Backup updates the RDB control file and any subsequent displays of the View Remote Auditing Status screen reflect the proper value. Control Records Control records are a type of audit record contained in the audit blocks being transferred from the primary host to the secondary host. Among audit records, control records are those that contain a timestamp and date. By providing the timestamp and date of the last control record applied to the secondary database on the View Remote Auditing Status screen, Remote Database Backup enables you to learn how current the secondary database is in relation to the primary database. The following audit records are control records. DBSI DBST BCP ECP RECOV SPT FILEDC STRDC Control Record Mnemonic Full Name of Control Record DATABASE STACK INITIATE DATABASE STACK TERMINATE BEGIN CONTROL POINT END CONTROL POINT RECOVERY POINT SYNCPOINT FILE DISCONTINUITY STRUCTURE DISCONTINUITY Relationships Between Selected Report Values In general, the following statements are true, and if a value in your report contradicts these statements, you should investigate the reason a difference exists. Under the ABW audit transmission mode, the number of the current audit block is always greater than or equal to the number of the last audit block received. The number of the last audit block applied is always less than or equal to the number of the last audit block received. Because audit blocks are applied only at quiet points, which might not occur for many audit blocks, the applied number can be less than the received number. When the AFN or ABSN rolls over to 1, the value relationship might be invalidated for a short period of time. If the applied number is unexpectedly much less than the received number, you need to investigate the cause of the discrepancy

160 Monitoring Your Remote Database Backup System Related Information Topics For information about... Refer to... Audit transmission modes Sections 2, 3, 4, and 5 Cloning the database Sections 5 and 8 Disabling the Remote Database Backup system Enabling the Remote Database Backup system Section 8 Sections 5 and 8 Tracker performance Section 4 Accessing Cumulative Remote Database Backup Statistics What Remote Database Backup Statistics Are Remote Database Backup statistics are a group of selected database and network values about the audit transmission process that can be displayed on the View Remote Auditing Statistics screen on either the primary or the secondary host. The statistics feature can help you to determine how well the network is serving the database. Statistics accumulate from the most recent statistics reset point. The most recent statistics reset point is the result of the last successful SM STATISTICS RESTART command or the latest initiation of the RDBSUPPORT library. What Remote Database Backup Statistics Are Not The Remote Database Backup statistics do not provide An overall look at network performance Information on other parallel processing such as disk reads and writes Complete database statistics Purpose of Remote Database Backup Statistics The statistics can be the basis for deciding to adjust such network-related variables as the network maximum segment size or the acknowledgment rate. Adjusting these variables can effect improvements in such factors as send-time and wait-time values

161 Monitoring Your Remote Database Backup System The specific goal is to keep the average send-time and wait-time values for audits as low as possible. An average wait-time value close to 0 (zero) and an average send-time value that is low represent the most efficient backup to the secondary database when you are using the ABW audit transmission mode. When to Access Remote Database Backup Statistics Initially, you might check Remote Database Backup statistics regularly at the same time each day and at different times of the day to create and maintain an informal record of network performance for the database. Once you have determined the statistics that represent normal performance levels for your environment, you can access Remote Database Backup statistics when the audit transmission process seems slow or when some other event makes you curious about how your network is performing in relation to the database. When Remote Database Backup Statistics Are Updated When the primary and secondary hosts are communicating, the information appearing on the View Remote Auditing Statistics screen depends on the following factors: The host from which you access the View Remote Auditing Statistics screen The audit transmission mode set on the primary and secondary hosts When the hosts are not communicating, or when the audit transmission mode of either host is NSC, some values on the View Remote Auditing Statistics screen remain static at last-known values or are blank. In general, Database information of the accessing host is always updated. Network information of the accessing host is updated only when the audit transmission mode for the primary host is ABW. Effect of Start Time on Statistics The start time for the accumulation of database statistics can be different from the start time for the accumulation of network statistics because the network statistics are collected only during audit transfers under the ABW mode. One result of different start times is that the values for audit words generated and for the total number of words sent might vary more widely than usual. Consequently, you need to monitor the growth rates for the two items rather than the absolute values. Remote Database Backup Statistical Information The following tables briefly explain the Remote Database Backup statistical information that appears on the View Remote Auditing Statistics screen. Refer to Database Operations Center Help for additional information

162 Monitoring Your Remote Database Backup System General Database Information Information Item Database name Primary host Secondary host Explanation Name of the database for which the Remote Database Backup system exists Name of the primary host Name of the secondary host Database Information Information Item Average block size Audit words generated Accessroutines average wait time Explanation In all modes, the result in words per block of the following formula: total audit words generated number of audit blocks generated A value in k words that is calculated by Remote Database Backup as audit information is transmitted. Contrast this value with the total number of words sent. The result in seconds of the following formula: total wait time number of send calls Note: The display for total wait time shows a rounded figure. An internally stored number is used for the calculation. Accessroutines total wait time The total time in seconds that the Accessroutines waits for acknowledgments. Note: Because the average wait time is given in fractions of seconds, that field can show a value while the total wait time field shows a 0 (zero)

163 Monitoring Your Remote Database Backup System Network Information Information Item Audit blocks transferring? Total number of words sent Average send time Total send time Explanation One of two letters indicating whether the primary host is presently sending audit blocks successfully to the secondary host: Y meaning that audit blocks are being transmitted. N meaning that no audit blocks are being transmitted. In ABW mode, the total number (in k words) of audit block words sent plus any control words. Contrast this value with the number of audit words generated. In ABW mode, the result in seconds of the following formula: total send time total number of send calls In ABW mode, the result in hours, minutes, and seconds (HH:MM:SS) of adding the total time from the beginning of a send call until its acknowledgment is received. Procedure To access Remote Database Backup statistical information, on the Tools menu in Database Operations Center, point to Remote Database Backup, and choose View Remote Auditing Statistics. Interpreting Remote Database Backup Statistics Definitions Wait Time The Accessroutines wait time is the idle time between initiating an audit I/O and receiving the acknowledgment that the I/O is complete. When using the ABW mode, the write across the network is included as part of the audit I/O operation

164 Monitoring Your Remote Database Backup System Example of Wait Time For example, in ABW mode, the audit block is written to the secondary host by way of the port file. The write of the next audit block from the primary host is delayed until the first audit block has been successfully sent and, if required, an acknowledgment received. During the delay, the processor can do some useful tasks and the remainder of the time is idle. This idle time is the wait time. Send Time Relative to the ABW mode, the send time is the entire time from the initiation of the audit I/O until the arrival of the acknowledgment of the audit I/O, including wait time. In the previous example, the send time is the number of seconds from the initiation of the audit I/O until the arrival of the acknowledgment of the audit I/O. Send time always includes wait time and therefore is always a larger value than wait time. Measuring the Impact of Network Performance on Primary Database Performance You can use the average wait time as an index to measure the impact of network performance on primary database performance. An acceptable, or normal, average wait time depends on the configuration, on total network traffic, and on many other factors. You can establish your site index for this statistic by monitoring the average wait time during periods with known levels of database activity and typical network performance. Later, if the average wait time significantly exceeds the index for the expected levels of database activity, the increase might mean that communication performance has degraded. If you diagnose a network problem that cannot be corrected promptly, you can change the Remote Database Backup audit transmission mode temporarily to avoid impacting database performance. Determining the Network Capacity for Your Database To determine the network capacity for your Remote Database Backup system, complete the following procedure. Then compare the result with the signaling rate and maximum effective throughput rate of your network. Step Action 1 Calculate the total number of audit bits by multiplying the total number of audit words by Divide the total number of audit bits by the time period (in seconds) during which statistics were accumulated

165 Monitoring Your Remote Database Backup System Example During a test period of 10 minutes, 600,000 audit words were transmitted. 600,000 is multiplied by 48. The result is 28.8 million bits. Therefore, the minimum network capacity is 48,000 bits per second (28.8 million divided by 600 seconds). Related Information Topics For information about... Refer to... Accessroutines Enterprise Database Server Utilities Operations Guide Acknowledgment rate Sections 2, 4, and 5 Audit transmission modes Sections 1, 2, 3, 4, and 5 Database auditing Database statistics Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Accessing Database Statistics on Remote Database Backup Performance Generating Database Statistics The benefits of generating database statistics are the same whether your database runs with Remote Database Backup or without Remote Database Backup. However, when your database runs with Remote Database Backup, you can use some database statistics to compare with Remote Database Backup statistics. From the comparison, you might get a better picture of how database operations and Remote Database Backup operations are affecting each other. Figure 7 1 shows the beginning of a sample report resulting from the AUDIT ANALYZE AFN command. UNISYS HOST1 AUDIT ANALYSIS VERSION (TEST)PRODUCTDB/AUDIT16 ON PROD1 TIME AUDIT BITS / SECOND (* = 1000) 09:12: ********** 09:12: ******** 09:12: ******** 09:12: ********* 09:12: ********* 09:12: ********* 09:13: ********* Figure 7 1. Sample Report from the AUDIT ANALYZE AFN Command

166 Monitoring Your Remote Database Backup System Figure 7 2 shows the beginning of a sample AUDIT ANALYZE AFN report that was run on an audit file generated when audit processor information was being collected. To collect audit processor information, use the Visible DBS AUDIT PROCESSOR TIMES command. UNISYS HOST1 AUDIT ANALYSIS VERSION (TEST)PRODUCTDB/AUDIT16 ON PROD1 Audit created on an A9 BLOCK ZERO TIMESTAMP: 6/28/96 12:47 TIME PROCESSOR TIME IN SECONDS AND % OF INTERVAL (* = 10 %) I/ O TIME AND % OF INTERVAL DMS INQUIRY DMS UPDATE NON DMS DMS I/O 12:48: % % % % 12:49: % % % % 12:50: % % % % 12:51: % % % % 12:52: % % % 0, % 12:53: % % % 0, % 12:54: % % % % 12:55: % % % % Figure 7 2. Sample Report Including AUDIT PROCESSOR TIMES Command Information Related Information Topics For information about... Refer to... Database statistics Visible DBS commands Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide

167 Section 8 Managing a Remote Database Backup Environment In This Section This section contains explanations of Remote Database Backup system management tasks and accomplishing these tasks. The topics include Interdependencies in the Remote Database Backup environment Audit file accumulation Acknowledgment of audit files Viewing and updating host information records - Viewing a host information record - Modifying a host information record Changing the audit file transmission mode Cloning the database on the secondary host Disabling Tracker Performing an offline dump of the secondary database Performing replication of the secondary database Disabling the Remote Database Backup system Reenabling the Remote Database Backup system Using Visible DBS commands in the Remote Database Backup environment Interdependencies in the Remote Database Backup Environment As you manage your Remote Database Backup system, you need to be aware of how your Remote Database Backup system interfaces with your database software and with other software. When a task does not proceed according to your expectations, you should consider the requirements of other software products associated with the task as well as the requirements of Remote Database Backup. The relationship between the primary and secondary databases is such that if you discontinue (using the DS system command) any of the following tasks on a host, you also discontinue the database on that host:

168 Managing a Remote Database Backup Environment <database name>/rdbsupport <database name>/tracker SYSTEM/RDBSUPPORT Caution Discontinuing SYSTEM/RDBSUPPORT discontinues any other databases running under Remote Database Backup on the host where you take this action. Audit File Accumulation When audit files cannot be transferred to the secondary host, they accumulate on the primary host and a disk space problem can arise. The audit pack on the primary host can become full, and the ability to update the primary host is hampered by the lack of disk space. To help prevent a lack of disk space, you can designate in the database DASDL description an alternate disk location for primary audit files and any specified duplicate audit files. When a disk space problem occurs, you should take one of the following actions depending on the options you have set: Verify that copies of any audit files have been made and then remove the audit files from the primary host. If the COPY and REMOVE options are set in the DASDL source file, and if you have set the option in Database Operations Center to delay the removal of audit files, access Database Operations Center and change the option to No so that the COPYAUDIT program removes the audit files in the future. When the option to delay the removal of audit files is set, the audit files are removed by the RDB support library on the primary host only after Tracker on the secondary host has processed the audit files. If the COPY and REMOVE options are not set, run the COPYAUDIT program with the COPY and REMOVE options. Later, you can reload the audit files on the primary host. Or, if your system is running under the AFS, SCA, or NSC audit file transmission mode, you can copy the audit files directly to the secondary host

169 Managing a Remote Database Backup Environment Acknowledgment of Audit Files What an Audit File Acknowledgment Is Following the audit file transfer from the primary host to the secondary host, the Remote Database Backup software at the secondary host requires an acknowledgment that the audit file was received. The audit file acknowledgment allows Tracker to process the audit file. If you use sectioned audit files, you cannot acknowledge an audit file until all sections of the file are present on the secondary host. If you attempt to do so, the system displays an error message. Note: The automatic communications message acknowledgment that occurs under the ABW mode for audit blocks is different from the audit file acknowledgment function and is explained in Section 2, Understanding Audit Transmission Modes. How the Acknowledgment Is Sent The audit file acknowledgment is sent automatically in AFS mode and must be provided manually in SCA and NSC modes. You cannot prevent the automatic acknowledgment in AFS mode, but you can duplicate it manually by running Database Operations Center. Reasons to Acknowledge an Audit File You need to manually acknowledge audit files under any of the following circumstances: Under the NSC or SCA mode, if you need to inform the Remote Database Backup system that audit files are available on the secondary host that need to be applied to the secondary database If a manual recovery is performed at the primary host that rebuilds or rolls back the database to an audit file prior to the last one received at the secondary host before the recovery Under the AFS, SCA, and NSC modes, when you synchronize audits for a DASDL update Under the AFS, SCA, and NSC modes, when you synchronize audits for a software upgrade When to Do This Task You perform the acknowledgment task to alert Tracker to the presence of the audit files on the secondary host after you manually transfer audit files from the primary to the secondary host. Tracker does not need to be running before you begin this task. If Tracker is not running, the transmission of the acknowledgment initiates Tracker. Notes:

170 Managing a Remote Database Backup Environment If you send an acknowledgment of an audit file before the file is available on the secondary host, Tracker hangs when it tries to apply the file before the file is available. Copy only complete audit files to the secondary host. Do not manually copy the current, incomplete audit file unless instructed otherwise (for example, during a software upgrade). If you want to transfer the current audit file to the secondary host, you must first close it with the SM AUDIT CLOSE command. For instructions on upgrading your software, refer to the Enterprise Database Server Getting Started and Installation Guide. What Audit File Number (AFN) to Acknowledge Under the ABW, AFS, and SCA modes, the View Remote Auditing Status screen is a source of information about the status of current audit transmissions. When you transfer several audit files to the secondary host, you need to acknowledge only the most recently created file. The system returns a warning if the file you acknowledged is not present on the secondary host. However, it does not verify the presence of any preceding files. You must ensure that all required files are transferred successfully. Usually the numbers of the transferred audit files are greater than the current AFN on the secondary host. However, Remote Database Backup also accepts numbers that are equal to or less than the current AFN because these numbers can be necessary when Rolling over from the maximum audit file number allowed (9999) to the first number allowed (1) Replacing audit files that were already copied to the secondary host, but not applied to the secondary database. Procedure To send an acknowledgment to the Remote Database Backup system of an audit file that you have manually copied to the secondary host, on the Tools menu in Database Operations Center, point to Remote Database Backup, and choose Acknowledge the Manual Transfer of Audit Files. Note: In NSC mode, the procedure must be performed from the secondary host. Related Information Topics For information about... Refer to... ALTERNATE audit trail option Section 4 DASDL Programming Reference Manual Audit file transmission modes Sections 1, 2, 3, 4, and 5 Error-handling options for the ABW mode Sections 2, 3, 4, and

171 Managing a Remote Database Backup Environment For information about... Refer to... View Remote Auditing Status screen information Sectioned audit files Section 7 Enterprise Database Server Utilities Operations Guide Tracker Section 4 Visible DBS AUDIT CLOSE command Sending an acknowledgement of an audit file Enterprise Database Server Utilities Operations Guide Database Operations Center Help Viewing and Updating Host Information Records Definition of a Host Information Record The host information record is a record in the RDB control file that contains information about one of the host systems associated with the database. There is one host information record in the RDB control file for each host system. You create host information records when you configure a Remote Database Backup system on Database Operations Center. A host information record contains Name and location of the database that runs or is to run under the Remote Database Backup system Name of the host Pack names of the essential database files Title of the RDB server code file Audit transfer mode and options Port-I/O timeout value for the ABW mode Acknowledgment rate for the ABW mode Synchronization restart interval for the ABW mode Instructions to delay, or not to delay, the removal of audit files on the primary host when the COPY and REMOVE options are included in the DASDL audit trail declaration Reasons for Accessing the Host Information Record You access a host information record using Database Operations Center to View the record. Modify or delete the record. (These options are available from the primary host only.)

172 Managing a Remote Database Backup Environment Procedure To create, modify, or view host information for either the primary or secondary host or for both hosts, on the Tools menu in Database Operations Center, point to Remote Database Backup, and choose Create, Modify, or View Host Information. Related Information Topics For information about... Refer to... Acknowledgment rate Sections 2, 4, and 5 Modifying a host information record Remote Database Backup configuration procedures Modifying a Host Information Record later in this section Section 5 RDB control file Section 5 Synchronization restart interval Sections 4 and 5 Viewing a host information record Viewing a Host Information Record later in this section Viewing a Host Information Record What the Task Does You can examine the host information records for the primary and secondary host. You can perform this task from the primary host or the secondary host. Procedure To view a host information record, use the Host screen from either the primary or secondary host. Related Information Topics For information about... Refer to... Audit transmission modes Sections 1, 2, 3, 4, and 5 Error-handling options for the ABW mode Sections 2, 3, 4, and 5 Viewing a host information record Database Operations Center Help

173 Managing a Remote Database Backup Environment Modifying a Host Information Record What the Task Does Modifying a host information record updates the RDB control file with new information about the Remote Database Backup environment on either the primary or the secondary host. Using this task you can alter your choices of Location of audit files on the secondary host Audit transmission mode Audit file removal delay Port-I/O timeout value for the ABW mode Acknowledgment rate for the ABW mode Synchronization restart interval for the ABW mode You can also use this task to inform Remote Database Backup about changes you have made to Location of database control files on the primary or secondary host Future location of audit files on the secondary host RDB server file location on the primary or secondary host Note: The audit file locations, as recorded in the host information record, should be the same as the audit file locations stored in the database control file of that host. If the audit file locations are changed in either the database control file or the host information record, a corresponding change must be made manually to maintain this sameness. What You Cannot Use This Task For You cannot use this task to move Database control files on the primary or secondary host Audit files on the primary host Existing audit files on the secondary host You also cannot modify the name of the primary or secondary host or the name of the database. These changes require a complete reconfiguration of the Remote Database Backup system. Procedure To modify a host information record, use the Host screen from the primary host

174 Managing a Remote Database Backup Environment Related Information Topics For information about... Refer to... Acknowledgment rate Sections 2, 4, and 5 ALTERNATE audit trail option Section 4 DASDL Programming Reference Manual Audit file transmission modes Sections 1, 2, 3, 4, and 5 Changing the audit transmission mode Error-handling options for ABW mode Modifying a host information record Changing the Audit File Transmission Mode later in this section Sections 2, 3, 4, and 5 Database Operations Center Help Synchronization restart interval Sections 4 and 5 Changing the Audit File Transmission Mode What the Task Does This task changes one or more of the following specifications in the RDB control file: The audit transmission mode for the hosts in the Remote Database Backup system: - One mode for the primary host for the transmission of audit information to the secondary host - One mode for the secondary host for the transmission of audit information to the primary host in the event of a takeover when the host roles are reversed The mode for each host also determines the information that can be viewed on the View Remote Auditing Status and the View Remote Auditing Statistics screens from that host. If the mode of the accessing host is NSC, no information about the other host can be viewed. The error-handling option when the audit transmission mode is ABW The file transfer option when the audit transmission mode is AFS You can perform this task from the primary host only. From the secondary host, however, you can view the audit transmission modes for both the primary and secondary hosts and, if applicable, the error-handling options

175 Managing a Remote Database Backup Environment Reason to Perform This Task You change the audit transmission mode or the error-handling option to meet a business requirement relating to database throughput or the synchronization of the secondary audit trail. When the Change Takes Effect The change of an audit transmission mode takes effect as follows: If you make the mode change while the database is open, the change takes effect when the next audit file switch takes place or when the database is closed, whichever event comes first. If you make the mode change when the database is down, the change goes into effect with the next open update operation because that operation triggers an audit file switch. If you want to change the audit transmission mode to AFM mode, the mode change and the audit switch that effects the change must occur before the physical disks are configured as Symmetrix Remote Data Facility (SRDF) target mirrors with the MCP shared disk functionality. If you want to change from AFM mode to any other audit transmission mode, the physical disks must be released as Symmetrix Remote Data Facility (SRDF) mirrors, and the shared disk functionality must be disabled before the mode is changed. Note: Symmetrix Remote Data Facility (SRDF) is the disk-mirroring software solution for use with Symmetrix hardware. This solution is provided by EMC, a global enterprise storage company. The change remains in effect until you repeat this task. When you change from the AFS, AFM, SCA, or NSC mode to another mode, the audit file that is closed during the mode change is transferred under the new audit transmission mode. Procedure To change the audit file transmission mode for either the primary host or the secondary host or for both hosts, on the Tools menu in Database Operations Center, point to Remote Database Backup, and choose Modify the Audit File Transmission Mode. When changing the audit transmission mode from ABW to anything else, if the audit trails are not synchronized, after the mode change takes effect, manually copy the recently closed audit file to the secondary host. If any prior audit files are not present on the secondary,copy them as well. If the files are not copied, Tracker will report the following error at the secondary host: ERROR AT LINE ( ): BAD AUDIT BLOCK SERIAL NUMBER IN BLOCK 0. If this error occurs, copying the files will resolve the problem

176 Managing a Remote Database Backup Environment Related Information Topics For information about... Refer to... Audit transmission modes Sections 1, 2, 3, 4, and 5 Error-handling options for the ABW mode Sections 2, 3, 4, and 5 View Remote Auditing Status screen Section 7 Specifying an audit transmission mode Section 5 View Remote Auditing Statistics screen Section 7 Takeovers Sections 6 and 13 Cloning the Database on the Secondary Host When to Do This Task You clone the database when You have completed an unplanned takeover. You have disabled and reenabled the Remote Database Backup system. The View Remote Auditing Status screen indicates that a full clone is required. You reconfigure the Remote Database Backup system. Handling an Audit Backlog with a Clone Operation A clone operation can sometimes be more efficient than allowing Tracker and Catchup to deal with a backlog of audits. For example, if you had at least 2 weeks of updates to be applied to the secondary host because the secondary system had been unavailable, cloning the database might be a quicker way to update the secondary database than to apply all the changes through Tracker. Using a Previous Clone WFL Job If you saved a WFL job from a previous clone of the database, you might be able to save time by running this job instead of performing the clone tasks again. You can use the former clone WFL job if You have not made any changes to the Remote Database Backup configuration since the clone WFL job was saved. You have made changes to the Remote Database Backup configuration, but you can

177 Managing a Remote Database Backup Environment modify the WFL job to reflect the changes before you run the WFL job. You can initiate the clone operation from either the primary or secondary host with a dump from either the primary or secondary host. Cloning the Database Using a Remote Copy of the Database Located at the Secondary Host Tracker must be terminated before you can clone a database using a database copy created by the QUIESCE command. The procedures for creating a database copy by using the QUIESCE command are documented in the Enterprise Database Server Utilities Operations Guide. Full Clone Tasks To perform a full clone operation of the database, perform the same tasks explained in Section 5 for cloning the database on the secondary host. Perform the tasks sequentially and in the same session. If any of these clone tasks are omitted or not completed in the specified order, unpredictable results can occur. Note: To decrypt an encrypted tape on a system other than the local system, you must first export from the local system the tape encryption keys used to encrypt the dump and then import these keys to the destination system. Refer to the MCP Cryptography Services Manager link in the Security Center Help for instructions on exporting and importing tape encryption keys. Ensure that you understand the introductory information about the clone operation in Section 5. The tasks are listed in order in the following text along with any further information you need for a clone operation that is not mentioned in Section Making the required database files available to the secondary host The reason the database must be cloned can determine which files you need to make available during this task: If the need to perform a clone operation is the result of disabling and then reenabling the Remote Database Backup system, you should have removed all Remote Database Backup and database files from the secondary host after disabling the system. Therefore, you must now replace all files on the secondary host. If the need to perform a clone operation is due to any other circumstance, you need to make available on the secondary host only those files that have changed

178 Managing a Remote Database Backup Environment Caution Prior to starting any clone process, you must remove the following files from the secondary host if they are present: - <database name>/trackerinfo - <database name>/recoveryinfo 2. Specifying dump information and pack mappings for database structures on the secondary host You can use any type of dump for cloning the database, including an incremental or an accumulated dump. Follow the same ordering of dumps as required for a recovery operation. Before a clone operation, under any audit transmission mode, access the View Remote Auditing Status screen and note the following values so that you can use them after the clone operation: The current AFN value on the primary host Under the ABW mode, the current ABSN on the primary host The received AFN value on the secondary host The received ABSN value on the secondary host After the clone operation is complete, ensure that the audit file in use on the primary host when the dump was started is present on the secondary host. Tracker requires this file before it can make the secondary database available to inquiry programs. 3. Identifying pack names for database software files on the secondary host 4. Specifying pack names for database guard files on the secondary host 5. Providing the titles of the DMCONTROL and DMUTILITY code files on the secondary host 6. Selecting a method of running the clone operation Note: When the mode is changed from SCA or NSC to ABW following the re-clone, the following steps must be followed in order for Catchup to run automatically: copy to the secondary host the audit file in use at the time of the dump using Database Operations Center Acknowledge the audit file number that was copied

179 Managing a Remote Database Backup Environment Related Information Topics For information about... Refer to... Catchup Section 4 Clone sample program Cloning the database Database dumps Disabling the Remote Database Backup system Appendix A Section 5 Database Operations Center Help Enterprise Database Server Utilities Operations Guide Disabling the Remote Database Backup System later in this section Ordering a dump for a clone operation Section 10 Providing a dump of the database Section 4 QUIESCE command Reenabling the Remote Database Backup system Enterprise Database Server Utilities Operations Guide Reenabling the Remote Database Backup System later in this section View Remote Auditing Status screen data Section 7 Starting the secondary database after a clone operation Section 5 Structure clone operation Section 9 Tape encryption keys Security Overview and Implementation Guide Security Center Help Tracker Section 4 WFL jobs WFL Reference Manual Ordering a dump for a clone operation Section 10 Disabling Tracker What Disabling Tracker Does Disabling Tracker temporarily or permanently stops the Tracker operation on the secondary host. The request to disable Tracker takes effect at the first restart point following the issuance of the request. The frequency of restart points and hence the time lag between your issuance of the disable request and Tracker leaving the mix is affected by

180 Managing a Remote Database Backup Environment The current setting for the TRACKERFLUSHDB option The frequency of transactions on the primary database audit trail The frequency of control points on the primary database Reasons to Disable Tracker Examples of reasons to disable Tracker include To freeze the secondary database at a logical point in time To perform a DASDL update on the secondary database when you are operating in AFS mode Consequences of Disabling Tracker Disabling Tracker has the following consequences: Catchup will not be initiated following an interruption of audit transfers. The secondary database is not updated. Depending on the audit transmission mode that is set, audit information can accumulate on the secondary host. If the option to delay the removal of audit files from the primary host is set, audit files build up on the primary host. Difference Between Temporarily and Permanently Disabling Tracker Temporarily or permanently disabling Tracker always results in Tracker leaving the mix at the first restart point following the disable request. The difference between temporarily and permanently disabling Tracker lies in the actions that cause Tracker to restart. When you disable Tracker temporarily, any of the following events cause Tracker to restart: A halt/load Closing the secondary database and then reopening it Automatic opening of the secondary database by the Remote Database Backup software at the primary or secondary host When you permanently disable Tracker, Tracker restarts only after you enter a request to enable Tracker. Procedure The interface to the DISABLE TRACKER command is provided through the RDBSUPPORT stack. To temporarily or permanently disable Tracker, perform the following procedure

181 Managing a Remote Database Backup Environment Step Action 1 Use the LIBS (Library Task Entries) system command to identify the mix number of the RDB support library for the database on the secondary host. Sample output from the LIBS command is shown in Figure Perform one of the following actions: To temporarily disable Tracker, enter the following system command: <RDB support library mix number> AX DISABLE For example: 515 AX DISABLE To permanently disable Tracker, enter the following system command: <RDB support library mix number> AX DISABLE PERMANENT For example: 515 AX DISABLE PERMANENT --Mix--Frz---Shr---Usr FROZEN LIBRARIES USER=ACCT Temp All 2 JOB (ACCT) (ACCT)DMSUPPORT/CTRLDB ON PROD$ 519 Ctrl All 1 (ACCT) (ACCT)DMSUPPORT/CTRLDB ON PROD4 515 Ctrl All 2 (ACCT) (ACCT)CTRLDB/RDBSUPPORT Figure 8 1. Sample Output from the LIBS Command Results of Disabling Tracker Once you have issued the request to disable Tracker, the system initiates a task named <database name>/disabletracker and displays the following message: Waiting for Tracker to leave per user s request. At the next restart point, Tracker leaves the mix. Because the next restart point might not occur for several minutes or even longer, Tracker might stay in the mix for a relatively long period of time following the disable request. Restarting Tracker To restart Tracker after it has been temporarily disabled, close and then reopen the secondary database. To restart Tracker after it has been permanently disabled, use the following procedure. Step Action 1 Use the LIBS (Library Task Entries) system command to identify the mix number of the RDB support library for the database on the secondary host

182 Managing a Remote Database Backup Environment Step Action 2 Enter the following system command on the secondary host: <RDB support library mix number> AX ENABLE Results of Restarting Tracker Once you have issued the request to restart Tracker, the system initiates a task named <database name>/enabletracker and displays the following message: Waiting for Tracker quiet point to allow inquiry. The task terminates when Tracker encounters a quiet point. Checking Tracker Status To check on the status of Tracker, list the database control file on the secondary host to determine whether Tracker is currently enabled or disabled. Write or list the control file using either of the following commands: Run $SYSTEM/DMUTILITY ("db = <database name> WRITE <database name>/control") Run $SYSTEM/DMUTILITY ("db = <database name> LIST <database name>/control") The Tracker status is marked Enabled if Tracker is enabled or if you have temporarily disabled Tracker Disabled if you have permanently disabled Tracker Related Information Topics For information about... Refer to... Controlpoints LIST/WRITE statements DASDL Programming Reference Manual Enterprise Database Server Utilities Operations Guide Restart points and Tracker Section 4 SYSTEM/DMUTILITY Enterprise Database Server Utilities Operations Guide Tracker performance Section 4 Visible DBS commands Enterprise Database Server Utilities Operations Guide

183 Managing a Remote Database Backup Environment Performing an Offline Dump of the Secondary Database Introduction Remote Database Backup supports offline dumps only of the secondary database. You use DMUTILITY to create the dump using the same syntax as you would with a database that is not a Remote Database Backup database. Application inquiry programs can continue to run while the dump is being created. Notes: To decrypt an encrypted dump on a system other than the local system, you must first export from the local system the tape encryption keys used to encrypt the dump and then import these keys to the destination system. Refer to the MCP Cryptography Services Manager link in the Security Center Help for instructions on exporting and importing tape encryption keys. Offline dumps of the secondary database are intended as backup sources for complete or partial database recovery at either the primary or secondary host using the DMUTILITY RECOVER command. An offline dump of the secondary database is not recommended as a source for the DMUTILITY COPY command. If an offline dump of the secondary database is used, the following warning message appears: DATABASE DUMP WAS CREATED AT A QUIET POINT AT THE SECONDARY HOST WHICH MAY NOT GUARANTEE PHYSICAL CONSISTENCY An incremental or an accumulated dump is allowed. For a recovery operation at the primary host, you can use a mixture of incremental or accumulated dumps and a full dump from either host, as long as all dumps were taken at the same host. A full dump of the database is always required before any incremental or accumulated dump can start. The following database operations require a full database dump prior to the start of the next incremental or accumulated dump: Applying an online reorganization Structure cloning of all structures requiring such an operation Cloning the database Applying an online garbage collection Performing a takeover Applying any structure initialization Interruption of Tracker Because the secondary database is updated by Tracker, and because updates during the creation of the dump could compromise the integrity of the dump, DMUTILITY automatically interrupts Tracker while the dump is in progress

184 Managing a Remote Database Backup Environment The Tracker interruption works differently depending on whether the primary and secondary hosts can communicate at the time the dump is initiated. Secondary Host Can Communicate with the Primary Host If the audit transmission mode from the secondary host to the primary host is ABW, AFS, or SCA, and the hosts can communicate when the dump is initiated, Remote Database Backup forces a control point in the audit trail on the primary host to identify the point at which Tracker can be interrupted. Tracker remains active on the secondary host, and the dump does not proceed until Tracker processes a control point. Tracker designates a restart point, leaves the mix, and the dump proceeds. In addition, the audit transmission modes from the primary host to the secondary host provide the following variations: Under the ABW mode with audit transfer active and current, Tracker is interrupted relatively quickly. However, if the secondary host has been dropped, the dump is delayed until Catchup transfers a portion of the audit trail containing a control point and Tracker processes the control point. Under the AFS mode, you can perform one of the following actions: - Wait until the control point is automatically transferred when the current audit file is full. - Force an audit file closure using the Visible DBS SM AUDIT CLOSE command. Under the SCA or NSC mode, proceed as though you were in the AFS mode, but transfer and acknowledge the audit file manually. Secondary Host Cannot Communicate with the Primary Host If the audit transmission mode from the secondary host to the primary host is NSC, or if the hosts cannot communicate when the dump is initiated because of a network problem or a primary host problem, then Tracker is interrupted at a quiet point in the audit trail. The quiet point could be either The current ABSN if Tracker is waiting at a quiet point The prior quiet point if Tracker is processing audits Tracker designates a restart point at the location of the quiet point in the audit trail, then Tracker leaves the mix, and the dump proceeds. Procedure It is suggested that, whenever possible, you initiate the offline dump when Remote Database Backup processes on the two hosts can communicate. Such a dump has optimal integrity for recovery of either the primary or secondary database. To take an offline dump of the secondary database, perform the following procedure

185 Managing a Remote Database Backup Environment Step Action 1 Run DMUTILITY to initiate the offline dump. The timestamp of the resulting dump indicates the time audit images were generated rather than the time the dump took place. 2 If it is necessary to interrupt Tracker (refer to the preceding explanation), perform one or more of the following actions: Under the AFS, SCA, or NSC mode, force an audit file switch by using the SM AUDIT CLOSE command. Manually transfer the closed audit file to the secondary host. Acknowledge the transferred audit file through Database Operations Center. 3 If DMUTILITY is discontinued during the offline dump or if DMUTILITY fails to unlock the control file, execute the following DMUTILITY command before restarting the offline dump: Run $SYSTEM/DMUTILITY ("DB = <database name> CANCEL"); Performing Replication of the Secondary Database Introduction Use the QUIESCE command at a Remote Database Backup secondary host to enable additional database replication. The QUIESCE command for a Remote Database Backup secondary host prevents Tracker from performing audit application until a RESUME command is executed. Use the DMUTILITY program with the QUIESCE command, and use the same syntax as you would with a database that is not a Remote Database Backup database. What the Task Does When a QUIESCE command is entered, the Remote Database Backup system sends a message to the primary host to request two control points. The creation of two control points is the only effect on the primary database system. When Tracker encounters the two control points, the following events occur: 1. The DMUTILITY program waits until all data buffers are flushed to disk and Tracker creates a restart point. 2. The database control file is marked as being in an inactive state. 3. The control file stores a QUIESCE timestamp. 4. The DMUTILITY program completes with the message DATABASE QUIESCED. 5. The database remains in an inactive state with Tracker suspended until you initiate the DMUTILITY RESUME command. You can make database inquiries at the secondary host while the database is in an inactive state

186 Managing a Remote Database Backup Environment The physical mirroring of the disk is external to a Remote Database Backup system. Note: A Quiesce command with the QDC option is not allowed at the secondary host. Configuring the Replicated Copy Perform the following steps to split mirrored disks from their source while the database is in a quiesced state: 1. Rename and acquire the split mirrored disks at a third host, for example, one that is not the primary or secondary host. 2. Run the SYSTEM/DMCONTROL QUIESCERDBRESET command. Note: The database control file of the secondary database might have different FAMILY specifications than the primary database. Use the DMCONTROL OVERRIDE FAMILY command prior to updating this information through a DASDL update. Related Information Topics For information about... Refer to... QUIESCERDBRESET command OVERRIDE FAMILY command Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Disabling the Remote Database Backup System What the Task Does This task disables the Remote Database Backup remote auditing capability for the designated database. The listing of the database control file includes CF REMOTE AUDITING = DISABLED Note: Instead of disabling the Remote Database Backup system, you can temporarily suspend audit transmission by setting the audit transmission mode to SCA or NSC. This action avoids the consequences of disabling the Remote Database Backup system, namely, reenabling the Remote Database Backup system and performing a clone operation. Reasons to Perform This Task You perform this task to permanently remove the remote auditing capability of a database through a Remote Database Backup system. The disable command is necessary, for example, when you change a host in a Remote Database Backup system

187 Managing a Remote Database Backup Environment Notes: When you disable the Remote Database Backup system, reenabling it requires that you perform the enable and clone operations. You must perform this task when the primary database is inactive. Performing a Dump of the Database Immediately after the disable operation, you should perform a dump of the database. The dump reflects that the database is no longer operating in the Remote Database Backup environment. Subsequent database recovery operations that use the dump can therefore run without attempting to incorporate outdated Remote Database Backup data and structures. Tasks After a Disable Operation After you disable your Remote Database Backup system, you should perform the following tasks. Step Action 1 Terminate any Remote Database Backup tasks still running at the secondary host for the disabled system. These tasks include <database name>/rdbsupport, <database name>/rdb/server, and <database name>/acr/server. 2 Remove files from the secondary host that belonged to the disabled system. These files include the DMSUPPORT library, RECONSTRUCT code files, audit files, and so forth. The file removal is especially important if you intend to reestablish a Remote Database Backup system for the database, for example, with a new secondary host. 3 Optionally, remove the RDB control file (<database name>/rdb/control) from the primary host. It is not necessary to remove any files from the primary host. 4 To reestablish a Remote Database Backup system for the database, reconfigure Remote Database Backup, which includes performing the enable and clone operations. Related Information Topics For information about... Refer to... Database dumps QUIESCE command Reenabling the Remote Database Backup system Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Reenabling the Remote Database Backup System later in this section

188 Managing a Remote Database Backup Environment For information about... Refer to... Remote Database Backup configuration procedures Tape encryption keys Section 5 Security Overview and Implementation Guide Security Center Help Reenabling the Remote Database Backup System What the Task Does This task reestablishes remote auditing in the Remote Database Backup system after the system has been disabled by the disable operation. Preparing to Reenable the System To reenable the Remote Database Backup system, perform the task explained in Section 5 under the heading Enabling the Remote Database Backup System. Before beginning the reenable operation, you should perform the following actions: Note the number of the current audit file on the primary host (for use later in opening the secondary database). When you open the secondary database after the reenable clone operation, Tracker needs all audit files between the audit file that was in use at the time of the dump used for the clone through the current audit file on the primary host. Ensure that all Remote Database Backup and database-related files from the previously disabled Remote Database Backup system have been removed from the secondary host. Ensure that the <database name>/rdbsupport task is not active on the secondary host. Related Information Topics For information about... Refer to... Defining a host information record Section 5 Disabling the Remote Database Backup system Enabling the Remote Database Backup system Disabling the Remote Database Backup System earlier in this section Section

189 Managing a Remote Database Backup Environment For information about... Refer to... Making the required database files available on the scondary host Section 5 Troubleshooting enable operation problems Section 12 Changing the Network Service The Remote Database Backup remote auditing capability must be disabled for the designated database in order to change the network service from BNA to TCP/IP, or from TCP/IP to BNA. It must then be reenabled, and the secondary database must be recloned. Use the Database Operations Center to change the network service. Because the syntax to transfer files is different, any saved clone WFL jobs must be recreated. Changing the TCP/IP Credentials The TCP/IP credentials for the designated database can be changed at any time via the Database Operations Center. The new credentials will be used the next time that a file is transferred or a remote RDB Server is started. Changing the TCP/IP Key Container The TCP/IP key container for the designated database can be changed at any time through the Database Operations Center. However, the passwords for each host must be entered as well. They will be encrypted with the new key container before being stored in the RDB control file. Using Visible DBS Commands in the Remote Database Backup Environment Introduction The Visible DBS commands enable you to retrieve database status information and to modify various database parameters. All Visible DBS commands are applicable to the primary database in a Remote Database Backup environment; a subset of the commands apply to and can be used with the secondary database. Visible DBS Commands and Takeovers When you use the Visible DBS commands on the secondary host, you should consider how the command will affect the database in case of a takeover, when the secondary database takes on the role of the primary database

190 Managing a Remote Database Backup Environment For example, if you want an audit block size of 2K no matter which host is primary, you should set the value at both hosts. However, it is likely that you would want the ALLOWEDCORE settings for each host to be different depending on whether the host is primary or secondary. If so, then after a takeover, you would want to change the ALLOWEDCORE value on each host. Visible DBS Commands and the Secondary Database The following table shows which Visible DBS commands can be run for the secondary database and which cannot be run. Commands That CAN be Run DBS Change DBS Status Statistics Status Mix Commands That CANNOT be Run Audit Analyze Audit Close Audit Processor Times Status Reorg Structure Change Structure Status Visible DBS Command for Remote Database Audit Statistics Use the Status RDB command to report on the statistics that are accumulated and reported for port I/Os in the Remote Database Backup environment. Visible DBS Change Commands You can run the Visible DBS Change commands at both the primary and secondary hosts. Changes that you intend for both hosts must be run at both hosts. The effect of the command is limited to the database for which the command is entered. Commands Run at the Primary Host Run at the Secondary Host Allowedcore Takes effect immediately for the primary database Takes effect immediately for the secondary database

191 Managing a Remote Database Backup Environment Commands Run at the Primary Host Run at the Secondary Host Audit Blocksize Controlpoint Overlaygoal Syncpoint Syncwait Affects both the primary and secondary databases Affects only the primary database Takes effect immediately for the primary database Affects only the primary database Affects only the primary database No effect until a takeover is performed (and the database becomes the primary database) The value for AUDIT BLOCKSIZE in the new primary database control file becomes the audit block size. No effect until a takeover is performed (and the database becomes the primary database) Takes effect immediately for the secondary database No effect until a takeover is performed (and the database becomes the primary database) No effect until a takeover is performed (and the database becomes the primary database) Trackerflushdb No effect Takes effect after the database is closed and reopened TRACKERQPFACTOR Affects the halt/load recovery time Takes effect immediately Related Information Topics For information about... Refer to... DASDL database options Visible DBS commands DASDL Programming Reference Manual Enterprise Database Server Utilities Operations Guide

192 Managing a Remote Database Backup Environment

193 Section 9 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment In This Section This section includes the following topics: DASDL updates in the Remote Database Backup environment - Processing updates under the ABW or AFM mode - Processing updates under the AFS, SCA, or NSC mode - Changing code file and guard file names and pack locations - Adding new structures Tracker and the reinitialization of an existing structure Reorganizations in the Remote Database Backup environment - Minimizing the consequences of an aborted reorganization - Deciding whether to perform tasks manually or automatically - Effects of reorganization open options - Availability of database structures during a reorganization - Handling nonusercoded and usercoded databases - Auditing during reorganizations - Performing a structure clone operation - Handling the effects of an extensive online reorganization DASDL Updates in the Remote Database Backup Environment Introduction All the usual good practices associated with updates, such as taking backup dumps before and after the update, need to be followed in the Remote Database Backup environment

194 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment However, for a database in the Remote Database Backup environment, you also have to be concerned with how, when, and whether to replicate the DASDL update on the secondary host. Basic Procedure The basic update process for databases in a Remote Database Backup environment is the same as that for databases not in a Remote Database Backup environment. The steps are as follows. Step Action 1 Alter the DASDL source file. Note: It is strongly recommended that you declare the RECONSTRUCT file title, including the pack name, in the DASDL definition. The declaration ensures that the system automatically copies the RECONSTRUCT file to the secondary host after an offline reorganization. 2 Compile the DASDL source file to make a new description file. 3 If necessary, recompile the DMSUPPORT library and other tailored software. 4 Update the database control file. Notes: If necessary, recompile the user programs. The database control file being updated might have different FAMILY specifications than that recorded in the description file from the previous DASDL compilation. Use the DMCONTROL OVERRIDE FAMILY command prior to updating this information through a DASDL update. Conditions for Replicating the Update on the Secondary Host The method you use to replicate the DASDL update depends upon three factors: Whether the update modifies code file titles or locations Whether the update adds a new structure The audit transmission mode under which the Remote Database Backup system is operating Under the AFS, SCA, or NSC audit file transmission mode, the method also depends upon whether the update causes the control file update level to change

195 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Related Information Topics For information about... Refer to... Audit transmission modes Sections 1, 2, 3, 4, and 5 Changing the DASDL source file Code files OVERRIDE FAMILY command Performing DASDL updates DASDL Programming Reference Manual Section 4 Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide DASDL Programming Reference Manual Enterprise Database Server Utilities Operations Guide Processing Updates Under the ABW or AFM Mode Introduction If you are operating your Remote Database Backup environment under the ABW or AFM mode, you should synchronize the primary and secondary databases before performing a DASDL update. Having the databases synchronized before you start a DASDL update simplifies the update process. Procedure for Processing Updates Under the ABW or AFM Mode To process a DASDL update under the ABW or AFM mode, perform the following procedure. Step Action 1 Close the primary database. 2 Open the secondary database to allow the secondary database to become synchronized with the primary database. 3 Close the secondary database. 4 Perform the DASDL update on the primary database. If necessary, recompile any tailored software

196 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Step Action 5 On the primary host, run the DMCONTROL program with the UPDATE option if the DMCONTROL option was reset during the DASDL update. This action regenerates the database control file using the description file created by the DASDL update on the primary host. 6 Copy the following new files from the primary host to the secondary host: DMSUPPORT library and any other tailored software (if recompiled) Description file 7 Perform one of the following actions: If the update makes one of the following changes, refer to the procedure in this section for the appropriate steps to take: - Alters code file titles - Adds new data sets - Adds new sets or subsets If the update does not contain any of the preceding changes, run the DMCONTROL program on the secondary host with the UPDATE option. 8 Open the primary database for update purposes. Tracker automatically initializes any new structures on the secondary host. Processing Updates Under the AFS, SCA, or NSC Mode Introduction When you are operating your Remote Database Backup environment under the AFS, SCA, or NSC mode, the secondary database is usually at least one partial audit file behind the primary database. As a result, the procedure you use to complete a DASDL update while operating in these modes becomes dependent on whether the DASDL update causes an increase in the control file update level. Procedure to Process an Update When the Update Level Increases When the DASDL update increases the control file update level on the primary database, perform the following procedure. Note: If the update makes any of the following changes, refer to the procedures given later in this section for the appropriate steps to take: Alters code file titles Adds new data sets Adds new sets or subsets

197 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Step Action 1 Perform the DASDL update on the primary database. If necessary, recompile any tailored software. 2 On the primary host, run the DMCONTROL program with the UPDATE option if the DMCONTROL option was reset during the DASDL update. This action regenerates the database control file using the description file created by the DASDL update on the primary host. 3 Open the primary database for update purposes. 4 Wait for the following system message on the secondary host: TRACKER TERMINATING - A DMCONTROL UPDATE IS NECESSARY DUE TO A DASDL UPDATE ON THE PRIMARY 5 Close the secondary database. 6 Copy the following new files from the primary host to the secondary host: DMSUPPORT library and any other tailored software (if recompiled) Description file 7 On the secondary host, run the DMCONTROL program with the UPDATE option. 8 Open the secondary database. Tracker automatically initializes any new structures on the secondary host. Procedure to Use When the Update Level Does Not Change When the DASDL update does not modify the control file update level on the primary database, perform the following procedure. You can perform steps 3 through 8 at any time your schedule permits; you do not need to update the secondary database as soon as the primary database has been updated. Step Action 1 Perform the DASDL update on the primary database. 2 Copy the following new files from the primary host to the secondary host: DMSUPPORT library and any other tailored software (if recompiled) Description file 3 Open the primary database. 4 Issue a request to disable Tracker on the secondary host. 5 Once Tracker leaves the mix, close the secondary database

198 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Step Action 6 Perform one of the following actions: If the update alters code file titles, refer to the procedure in this section for the appropriate steps to take. If the update does not alter code file titles, run the DMCONTROL program on the secondary host with the UPDATE option. 7 If you permanently disabled Tracker in step 4, use the ENABLE command to restart Tracker. 8 Open the secondary database. Changing Code File or Guard File Names and Pack Locations Introduction Remote Database Backup requires that the names of the database code files and guard files you can specify in the DASDL source file be the same on both the primary and the secondary host. However, these code files and guard files do not need to be located on the same packs on both hosts. When you clone the database, you enter the pack locations of the code files and guard files for the secondary host. This is done as you progress through the series of Clone screens. If you later make any changes to the pack locations or to the code file or guard file names, you must run the DMCONTROL program either to update the pack locations or to update the file names with the new description file. Procedure for Changing Code File or Guard File Names To update the primary and the secondary databases with changed code file or guard file names, perform the following procedure. Step Action 1 On the secondary host, run the DMCONTROL program with the OVERRIDE FAMILY option. This action resets the family change bit in the control file of the secondary database. 2 On the secondary host, run the DMCONTROL program with the UPDATE option. This action modifies the control file for the secondary database using the new description file created on the primary host

199 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Step Action 3 On the secondary host, run the DMCONTROL program and supply the appropriate family assignments for the code files, structures, and guard files that differ between the primary and the secondary hosts. For examples of the DMCONTROL syntax you need to supply, either refer to the WFL job created during the clone operation or refer to the Enterprise Database Server Utilities Operations Guide. Procedure for Changing Code File and Guard File Pack Locations To change the code file or guard file pack locations on either the primary or the secondary host, run the DMCONTROL program and supply the appropriate family assignments for the code files or guard files. For examples of the DMCONTROL syntax, either refer to the WFL job created during the clone operation or refer to the Enterprise Database Server Utilities Operations Guide. Adding New Structures Adding a New Data Set and Its Associated Sets To add a new data set and its associated sets to the primary database and to replicate the changes on the secondary host, perform the following procedure. Step Action 1 To initialize the new structures, run the DMUTILITY program on the primary host. Note: If you do not run the DMUTILITY program, the primary database might hang with a NO FILE condition on the new structure when you attempt to open the database. 2 On the secondary host, run the DMCONTROL program with the UPDATE option. This action regenerates the database control file using the description file created by the DASDL update on the primary host. 3 If the pack name for the added structures is different between the two hosts, run the DMCONTROL program again on the secondary host, and supply the appropriate family information for the added structures. For examples of the syntax you need to supply, either refer to the WFL job created during the clone operation or refer to the Enterprise Database Server Utilities Operations Guide

200 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Adding a New Set or Subset to an Existing Data Set To add a new set or subset to an existing data set on the primary database and to replicate the changes on the secondary host, perform the following procedure. Step Action 1 On the secondary host, run the DMCONTROL program with the UPDATE option only when a reorganization is not required. This action regenerates the database control file using the description file created by the DASDL update on the primary host. Note: If a reorganization is required, this step might fail because the update operation can be performed only by the REORGANIZATION program. 2 If the pack name for the added structures is different between the two hosts, run the DMCONTROL program again on the secondary host, and supply the appropriate family information for the added structures. For examples of the syntax you need to supply, either refer to the WFL job created during the clone operation or refer to the Enterprise Database Server Utilities Operations Guide. 3 To generate the new set or subset from an existing data set, perform a reorganization on the primary host. (Refer to Procedure to Perform an Offline Reorganization later in this section, but be aware that you have already performed steps 2 and 3 of that procedure.) Notes: If you do not perform a reorganization, the primary database might hang with a NO FILE condition on the new structure when you attempt to open the database. When you run the BUILDREORG utility, include a generate statement for the new set; otherwise, the secondary database might hang with a NO FILE condition. Related Information Topics For information about... Refer to... Audit record types Enterprise Database Server Utilities Operations Guide Audit transmission modes Sections 1, 2, 3, 4, and 5 Changing the DASDL source file Section 4 DASDL Programming Reference Manual Code files DASDL Programming Reference Manual Enterprise Database Server Utilities Operations Guide

201 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment For information about... Refer to... DMCONTROL program DMSUPPORT library DMUTILITY program Reorganization Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide DASDL Programming Reference Manual Enterprise Database Server Utilities Operations Guide Synchronization of audit trails Sections 1, 2, 3, and 8 Tracker Sections 4 and 8 Tracker and the Reinitialization of an Existing Structure The reinitialization of an existing structure causes a structure discontinuity (STRDC) record to be audited. When Tracker reads an STRDC record at the secondary host, Tracker performs the initialization by creating the new physical file. During the initialization, Tracker can cause the following events to take place: If database users are accessing the database on the secondary host, Tracker waits until all users have left the mix before completing the initialization and periodically displays the following message: Tracker waiting for all users to leave to complete structure initialization. If a new user attempts to open the database on the secondary host, the user receives the following message: OPENERROR 97: Structure initialization pending. If a current user tries to access a structure being initialized, he or she receives the following message: VERSIONERROR 5: Reference to structure being initialized. When all users have left the mix, Tracker brings down the database and brings it back up again. Then all users can again access the database

202 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Reorganizations in the Remote Database Backup Environment Preparing for a Reorganization Perform the Usual Tasks All the usual good practices associated with reorganizations, such as performing backup dumps before and after the reorganization, need to be followed in the Remote Database Backup environment. Consider the Remote Database Backup Environment When preparing to reorganize your database in the Remote Database Backup environment, it is important to remember that the Remote Database Backup system consists of a primary and a secondary database, and that activities performed on the primary database generally affect the secondary database. However, activities performed on the secondary database do not necessarily affect the primary database. Note: The REORGANIZATION program should not be run at the secondary host. Any attempt to run the program at the secondary host results in the following DMOPENERROR 101 exception: REORGANIZATION PROGRAM CANNOT BE RUN AT SECONDARY. The name of the REORGANIZATION program must be the same on both the primary and secondary hosts. The default name is REORGANIZATION/<database name>/<yyyymmdd>/<hhmm> Make the RECONSTRUCT File Available Before beginning an offline reorganization, ensure that the RECONSTRUCT file is available on the primary host. Code File Name Changes You should not make any changes to the code file names during a reorganization. It should be done in a separate DASDL update. If you change a code file name along with other updates that will require a reorganization, the DASDL compiler will not report a syntax error because it cannot detect whether or not a database is RDB-enabled. However, the processing of the reorganization audit images at the secondary host will fail. Considerations Before a Reorganization Before you begin your reorganization, you should be aware of the implications of the reorganization in the Remote Database Backup environment and consider how best to proceed where you have choices. Some topics worth considering are How to minimize the consequences of an aborted reorganization The decision to perform some tasks manually or automatically

203 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Effects of the reorganization open options in the Remote Database Backup environment Availability of database structures during a reorganization Methods of handling nonusercoded and usercoded databases Handling the effects of an extensive online reorganization Minimizing the Consequences of an Aborted Reorganization The Problem Under the ABW, AFM, or AFS audit transmission mode, if an online reorganization is aborted at the primary host and an unplanned takeover is performed, the reorganization might fail at the new primary host. The consequence would be that both databases become unusable, and a complete database rebuild would be required. A Precautionary Measure As a precautionary measure, before you perform an online reorganization at the primary host in the ABW, AFM, or AFS mode, ensure that the files required for a rebuild are available on the secondary host. A Way to Prevent the Problem To prevent this problem, you can change the audit transmission mode to SCA or NSC before starting the online reorganization. You must ensure that no audit files are acknowledged at the secondary host until the reorganization completes successfully at the primary host. When the reorganization completes successfully, you can restore the original mode, and acknowledge the audit files that were generated during the reorganization. One side effect of the mode switch is that Tracker at the secondary host might be several audit files behind the primary host when the reorganization completes at the primary host. Related Information Topics For information about... Refer to... Audited reorganizations Performing offline dumps on the secondary database Enterprise Database Server Utilities Operations Guide Procedure to Perform an Audited Reorganization later in this section Section

204 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment For information about... Refer to... Reorganization open options Reorganizing a database Enterprise Database Server Utilities Operations Guide DASDL Programming Reference Manual Deciding Whether to Perform Tasks Manually or Automatically Pros and Cons In some cases, there might be an advantage to performing some tasks in the reorganization process manually; in other cases, having the system perform these tasks automatically would be more beneficial, for example: When you compile the DASDL source file, you can set the ZIP compiler control option to cause the DMSUPPORT library to compile automatically. If this option is not set, you must compile the DMSUPPORT library manually. You can run the BUILDREORG utility with or without automatically compiling the REORGANIZATION program. If you run the utility without automatically compiling the REORGANIZATION program, you must manually compile the program at a later time. The following table lists some advantages to performing tasks automatically and manually. Advantages of Performing a Task Automatically Less chance of error since the task is done for you Elimination of the need to know how to perform the task Advantages of Performing a Task Manually Control over when you perform the task Spreading the reorganization process over a longer and perhaps more convenient time span Some additional factors that might influence your decision to plan automatic or manual tasks: Estimated time for the reorganization Database usage Type of reorganization

205 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Making the RECONSTRUCT File Available on the Secondary Host After an offline reorganization, the RECONSTRUCT file is required on the secondary host. When you declare the RECONSTRUCT file title, including the pack name, in the DASDL definition, the system automatically copies the RECONSTRUCT file to the secondary host. If you omit the RECONSTRUCT file declaration from the DASDL definition, you must manually copy the RECONSTRUCT file from the primary host to the secondary host before starting a structure clone operation. Effects of Reorganization Open Options By default, during a reorganization in the Remote Database Backup environment, the primary database is available for both update and inquiry purposes. To limit the availability of the primary database, use one or more of the BUILDREORG utility open options. Table 9 1 explains these open options. Table 9 1. Effects of the Open Options on Database Availability Option Action Results INQUIRYONLY EXCLUSIVE PREVERIFY Prohibits update programs from accessing the database during the reorganization process. Prohibits inquiry and update programs from accessing the database during the reorganization process. Prior to the reorganization, locks and verifies all data sets that are to be generated. Prevents the loss of updates during reorganization if the reorganization run does not complete. If an attempt is made to disable Tracker while the reorganization audit images are being applied at the secondary host, the DISABLETRACKER option tries to open the database in update mode. An error message is displayed stating that the database may not be opened in update mode. Prevents the loss of updates during reorganization if the reorganization run does not complete. Stops the reorganization process from occurring if a data set fails the verification. Allows update and inquiry programs to open the database. Can be combined with any of the other open options

206 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Table 9 1. Effects of the Open Options on Database Availability (cont.) Option Action Results OFFLINE Prohibits access to the database structures involved in the reorganization, but allows access to other structures during the reorganization process. Prevents recordlevel auditing but provides for state change records. Generates minimal audit overhead. Enables a partial reorganization of structures and a partial dump of changed structures. Enables the structure cloning of reorganized structures at the secondary host. Availability of Database Structures During a Reorganization Structure availability on the primary database depends upon the BUILDREORG utility open option that you specify. The availability of structures is the same as that for a database being reorganized outside of the Remote Database Backup evironment. While the reorganization is being replicated on the secondary database, you cannot access any structures affected by the reorganization. Structures not touched by the reorganization are available. During a structure clone of the database following an offline reorganization, the structures requiring the structure clone are not accessible until the structure clone operation at the secondary database completes successfully. Handling Nonusercoded and Usercoded Databases Nonusercoded Databases When you reorganize a nonusercoded database in the Remote Database Backup environment, you need to know whether the following information is included in the DASDL source file: Location of the database control file Title of the DMSUPPORT library Title of the REORGANIZATION program Title of the Accessroutines Note: If possible, specify the preceding information in the DASDL source file. When the Information Is in the DASDL Source Run the REORGANIZATION program from any usercode (subject to normal security constraints). The database does not need to be opened prior to the beginning of the reorganization

207 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment When the Information Is Not in the DASDL Source Before beginning the reorganization task, make the information available by performing the following procedure. Step Action 1 Open the database and initiate the RDB server on the secondary host. 2 Run the REORGANIZATION program without a usercode. For example, initiate the program through a WFL job or from an ODT. Usercoded Databases The following table shows where the REORGANIZATION program looks for the database control file depending on the specifications you have included in the DASDL source for the control file. DASDL Specifications for the Control File Reorganization Run from Usercode * None Usercode only Location only Usercode and location Default family of the usercode from which the REORGANIZATION program is run Default family of the usercode from which the REORGANIZATION program is run Usercode under which the REORGANIZATION program is running on the specified pack Usercode and location specified in the DASDL source * on DISK Usercode on DISK A file equation might be required; that is, it might not be on DISK. * on the specified location Usercode and location specified in the DASDL source Related Information Topics For information about... Refer to... Availability of structures on Enterprise Database Server databases during a reorganization BUILDREORG utility Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide

208 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment For information about... Refer to... DMCONTROL program DMSUPPORT library DMUTILITY program Preparing for an offline dump of the secondary database Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Section 8 Tracker Sections 4 and 8 Auditing During Reorganizations A Comparison The following table lists the auditing options available during Enterprise Database Server reorganizations, the BUILDREORG open options that apply, if any, and the process that applies changes to the secondary database following a successful reorganization. Auditing Options Audited BUILDREORG Open Options Required None Optional: INQUIRYONLY, EXCLUSIVE, PREVERIFY Process That Applies Changes to the Tracker Secondary Database Partially audited OFFLINE Structure clone operation Characteristics of Audited Reorganizations Some characteristics of audited reorganizations are Remote Database Backup applies the reorganization changes to the secondary database using the Remote Database Backup audit tracking mechanism. The secondary database does not need to be cloned following the reorganization. Less time might be needed to perform an audited reorganization compared with a reorganization of some database structures with the OFFLINE or high availability (USEREORGDB) option set that requires a structure clone of the reorganized structures. Full or partial availability of the primary database exists. Partial database availability exists on the secondary database because the structures that are not affected by the reorganization are still available for use

209 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Characteristics of the Partially Audited (Offline) Reorganization Some characteristics of partially audited reorganizations are Either the OFFLINE or a high availability (USEREORGDB) option must be set. Partial audit means that the system produces audits of some records and not of other records: State change records and structure format timestamp records are audited. These audits enable the application of structure changes to the secondary database during a structure clone operation. Data change, fix-up records, and other overhead audit records are not audited. A structure clone operation is required after the reorganization completes. During the structure clone operation, the structures that are not affected by the reorganization are still available for use. For the sake of simplicity, the partially audited reorganization is called an offline reorganization for the remainder of this section. Reorganization and the Restart Data Set Online You can perform an online reorganization on the restart data set. Offline It is recommended that you not perform an offline reorganization on the restart data set in the Remote Database Backup environment. If you do, the Remote Database Backup system disables the restart data set on the secondary host with the following results: Every program trying to open the secondary database encounters a VERSIONERROR 6 message. The secondary database becomes unusable until you perform a structure clone on the restart data set. Before you perform a structure clone of the restart data set on the secondary host Bring down any update or inquiry program on the primary host in order to terminate Tracker and the secondary database. Do not use the DS (Discontinue) system command to discontinue Tracker or the database stack on the secondary host. Perform a structure clone operation on the secondary host. Bring up inquiry or update programs on the primary host. Procedure to Perform an Audited Reorganization To perform an audited reorganization on a database in the Remote Database Backup environment, use the following procedure on the primary host

210 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Note: To add a new structure, refer to the procedure under the heading Adding New Structures earlier in this section. Step Action 1 Produce a database dump using DMUTILITY. It is recommended that you perform an offline dump. In addition to the offline dump, make backup copies of the following files: Description file DMSUPPORT library Control file Current audit file Use the COPYAUDIT option to copy this file while the audit file is closed. Any other tailored software 2 Update and compile the DASDL source file on the primary host with the reorganization changes. 3 If the ZIP compiler option is not set, recompile the DMSUPPORT library. 4 Run the BUILDREORG utility with the desired options. 5 Ensure that the BUILDREORG utility completed successfully by verifying that the DESCRIPTION/REORGANIZATION/<database name> file exists. 6 If you are manually compiling the REORGANIZATION program, compile this program now using the newly created description file. 7 Run the REORGANIZATION program. The system places a reorganization state change record in the audit file on the primary host. 8 After the reorganization completes, produce a database dump using DMUTILITY on the primary host. 9 Apply the reorganization to the secondary database using the procedure under the heading Procedure to Apply a Reorganization to the Secondary Database later in this section. Procedure to Perform an Offline Reorganization To perform either an offline or a high availability reorganization on a database in the Remote Database Backup environment, use the following procedure on the primary host. Note: When you perform an offline reorganization, you must perform a structure clone operation at the secondary host when the reorganization completes. To add a new structure, refer to the procedure under the heading Adding New Structures earlier in this section

211 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Step Action 1 Produce a database dump using DMUTILITY. It is recommended that you perform an offline dump. In addition to the offline dump, make backup copies of the following files: Description file DMSUPPORT library Control file Current audit file Use the COPYAUDIT option to copy this file while the audit file is closed. Any other tailored software 2 Update and compile the DASDL source file on the primary host with the reorganization changes and set the OFFLINE option. 3 If the ZIP compiler option is not set, recompile the DMSUPPORT library. 4 Run the BUILDREORG utility with the desired options. 5 Ensure that the BUILDREORG utility completed successfully by verifying that the DESCRIPTION/REORGANIZATION/<database name> file exists. 6 If you are manually compiling the REORGANIZATION program, compile this program now using the newly created description file. 7 Run the REORGANIZATION program. The system places a reorganization state change record in the audit file on the primary host. 8 After the reorganization completes, produce a backup dump of the reorganized structures using DMUTILITY on the primary host. This dump needs to be available at the secondary host during the structure clone operation. 9 Apply the reorganization to the secondary database using the procedure under the heading Procedure to Apply a Reorganization to the Secondary Database later in this section. 10 Perform a structure clone operation in Database Operations Center on the reorganized structures using the dump created in step 8. Structure Availability After an Offline Reorganization Applications that attempt to access reorganized structures during an offline reorganization and prior to the completion of a structure clone operation receive the following VERSIONERROR 6 message when the application first accesses the database: REFERENCE TO STRUCTURE NEEDING A STRUCTURE CLONE

212 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Procedure to Apply a Reorganization to the Secondary Database To apply an audited reorganization to the secondary database, perform the following procedure on the secondary host. Step Action 1 Open the database for inquiry. Tracker applies audit images and finds the reorganization state change record. Note: If the pack name for added structures is different between the primary and secondary hosts, the Tracker task waits after displaying the following messages: NO FAMILY <family from primary> REQUIRES PK <primary packname> Respond with an IL (Ignore Label) system command in the following format: <Tracker mix number> IL PK <target pack number> 2 Use the MSG (Display Messages) system command to see if the following message is present: TRACKER ENCOUNTERED REORG, WAITING FOR ALL USERS TO LEAVE This message verifies that the update level has been detected by Tracker. Once this message is displayed, go to step 3. 3 Close all inquiry programs. Tracker displays the following message: TRACKER LEAVING FOR REORG 4 Verify that the latest versions of the following files were automatically copied to the secondary host: Description file REORGANIZATION program DMSUPPORT library If the following message appears, refer to Section 4 for instructions on modifying the RDB support library: DATABASE/<database name> IS NONUSERCODED. FOR RDB TO COPY REORGANIZATION FILES, YOU MUST WFL MODIFY THE RDBSUPPORT CODEFILE AS DESCRIBED IN THE INSTALLATION INSTRUCTIONS. AX TO CONTINUE. If the files were not automatically copied, refer to Procedure to Manually Transfer Files later in this section for the steps to manually copy the files to the secondary host. 5 If the RECONSTRUCT file title, including the pack name, is not declared in the DASDL definition, manually copy the RECONSTRUCT file to the secondary host

213 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Step Action 6 If the pack name for the added structures is different between the two hosts, run the DMCONTROL program again on the secondary host, and supply the appropriate family information for the added structures. For examples of the syntax you need to supply, either refer to the WFL job created during the clone process or refer to the Enterprise Database Server Utilities Operations Guide. 7 Open the database for inquiry. Tracker restarts and For an online reorganization, applies the reorganization to the secondary database. For an offline or high availability reorganization, marks reorganized structures as requiring a structure clone. Note: When new structure(s) are generated by the reorganization, the creation of the STRUCTURECLONE WFL by Database Operations Center must occur after all affected structures are marked as requiring structure clone. Procedure to Manually Transfer Files After a reorganization, your files might not be automatically copied to the secondary host if your network connection went down or if your Remote Database Backup system is operating under the NSC mode. If your files are not automatically copied, then during the procedure for applying the reorganization to the secondary database, transfer the files manually by performing the following procedure

214 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Step Action 1 If you are performing file-format or record-format reorganizations, copy the following files from the primary host: DESCRIPTION/<database name>/<mmddyy>/<hhmm> DESCRIPTION/<database name> This file is the most recently updated description file. Copy this file to the usercode and pack on which the database control file resides. DMSUPPORT/<database name>/<prior update level> This is the old DMSUPPORT library that existed before the reorganization on the primary host began. DMSUPPORT/<database name> This is the new DMSUPPORT library that exists after the reorganization on the primary host completes. RECONSTRUCT/<database name> If you declare the RECONSTRUCT file title, including the pack name, in the DASDL definition, the system automatically copies the RECONSTRUCT file to the secondary host after an offline reorganization. This file is required on the secondary host before you start a structure clone operation. For an audited reorganization, copying this file is optional but recommended in case it is later needed on the secondary host. The tapeset directory, if using the Multidump feature. Notes: - The tapeset directory for the Multidump feature must reside under the same usercode as on the primary host and on the LIBMAINTDIR pack. If the LIBMAINTDIR pack is not defined, then the tapeset directory must reside on the halt/load unit pack. - The tapeset directory for the Multidump feature can be re-created on the secondary host instead of copying it from the primary host. However, it is recommended that this file be copied from the primary host. 2 For all types of reorganizations, transfer the following file to the secondary host: REORGANIZATION/<database name>/<yyyymmdd>/<hhmm> The <YYYYMMDD> construct refers to the year, month, and day of the reorganization of the primary database. The <HHMM> construct refers to the hour and minute of the primary database reorganization run. Related Information Topics For information about... Refer to... Cloning a database Sections 5 and

215 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment For information about... Refer to... Modifying the RDB support library for a nonusercoded database Section 4 Performing a Structure Clone Operation When to Do This Task You should perform a clone operation when the View Remote Auditing Status screen indicates that a structure clone is required. You should perform a structure clone operation on the database when you have updated primary database structures using an offline reorganization. A structure clone operation typically requires less time and fewer computer resources than a full clone operation because you can use An offline reorganization A partial dump of updated structures (causing less impact on the primary database) Structure Clone Tasks and Procedures The structure clone tasks are summarized in the following table. Each task has its own procedure. Notes: The structure clone tasks must be performed in the order shown, in one continuous sequence in the same session. Tracker is essential to a successful structure clone operation. Do not disable Tracker before or during the operation. After performing a successful structure clone, any old and unused structure files should be removed manually to avoid pack space problems. Old and unused structure files exist when a structure specification is changed from no sections to multiple sections, or when a specification change results in a reduction of sections. Task and Procedure 1. Specifying dump information and structure names What the Task Does Provides Dump names for tape or disk dumps Worker, cycle, version, serial number, and density values for tape dumps Names of database structures to be cloned

216 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Task and Procedure 2. Providing Enterprise Database Server code file information 3. Selecting the method of running the clone operation What the Task Does Provides the secondary host pack name for the RECONSTRUCT code file and the title of the DMUTILITY code file Selects one of three methods of running the structure clone operation, and optionally initiates the operation Structure Clone Under the ABW Mode Under the ABW mode, it is recommended that you perform an audit file switch on the primary host before you begin a structure clone operation at the secondary host. Performing the audit file switch reduces the amount of time that Tracker must be suspended when the final phase of the structure clone (the reconstruct recovery) begins. Tracker is suspended because the structure clone operation uses the same file that Tracker uses. The structure clone process on the secondary host is the equivalent of the reconstruct restore function of the DMUTILITY program. This process involves a reconstruction type of recovery to run on the secondary host. Therefore, the requirements listed in Section 10 under the heading Requirements for a Reconstruct Recovery on the Secondary Database apply for a structure clone process. The dump used in the structure clone operation must have been generated when the primary database was using an audit file prior to the one currently in use at the secondary host. Procedure On the Tools menu in Database Operations Center, point to Remote Database Backup, and choose Clone Specific Structures. Structure Clone WFL Job Tasks The STRUCTURECLONEDB job initiates the following tasks in order 1. Runs the DMUTILITY code file to load the necessary structures from the specified dump or dumps. 2. Runs the RECONSTRUCT program to bring the loaded structures up-to-date on the secondary host. Verifying Completeness of the Structure Clone Operation After the structure clone operation finishes, if the structure clone operation omitted any structures that needed to be structure cloned, the Structure clone required field of the View Remote Auditing Status screen continues to indicate that a structure clone is required

217 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Verify whether any structures still require a structure clone by using the LIST/WRITE command to list the database control file. If you see that any structure listed in the control file still needs a structure clone, repeat the structure clone operation for those structures. Examples of Offline Reorganizations with Structure Clones Assume the following DASDL specification: DI DATA SET (F1NUMBER (6); F2NUMBER (7); F3NUMBER (7); F4ALPHA (6); F5NUMBER (7); ); S1SET OF D1 KEY F1; S2SET OF D1 KEY F2; S3SET OF D1 KEY F3; Example 1 Perform a garbage collection of data set D1. This reorganization affects D1 and all of its sets. All affected structures require a structure clone after the reorganization. When the REORGANIZATION program waits with a message to dump the reorganized structures, perform the dump. This dump is used for the structure clone at the secondary host. Make the dump available at the secondary host and perform the structure clone by specifying D1 in the structure name field of the Structure Clone screen. Since D1 is a data set, D1 and all of its sets are included in the structure clone. The entire family of structures must reside on the same pack as the data set on the secondary host. The structure clone process automatically executes the following tasks: RUN SYSTEM/DMUTILITY("DB=<database name> OPTIONS(NOZIP) STRUCTURECLONE(<usercode>)<database name>d1/= AS (<usercode>)<database name>/d1/= ON <secondary pack name> FROM <dump name>"); RUN RECONSTRUCT/<database name>; Example 2 Add the following new set to the DASDL description: S4 SET OF D1 KEY F5;

218 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Perform a DASDL update followed by a reorganization that does not affect the data set D1. The new set is the only structure that requires a structure clone. When the REORGANIZATION program waits with a message to dump the reorganized structures, perform the dump. This dump is used for the structure clone at the secondary host. Make the dump available at the secondary host and perform the structure clone by specifying S4 in the structure name field of the Structure Clone screen. Since S4 is a set and the only structure in D1 that is modified, only S4 is structure cloned. The structure clone process automatically executes the following tasks: RUN SYSTEM/DMUTILITY("DB=<database name> OPTIONS(NOZIP) STRUCTURECLONE (<usercode>)<database name>d1/s4 AS (<usercode>)<database name>/d1/s4 ON <secondary pack name> FROM <dump name>"); RUN RECONSTRUCT/<database name>; Related Information Topics For information about... Refer to... RECOVER/ROWS RESTORE command Enterprise Database Server Utilities Operations Guide Tracker Section 4 Performing an Online Garbage Collection An online garbage collection on the primary database is performed at the secondary host automatically through audit applications by the Tracker process. Handling the Effects of an Extensive Online Reorganization For a large reorganization at the primary host, you might save time and resources by suspending audit transfer before the reorganization and then recloning the database using a dump taken after the reorganization. Use the following procedure to apply a reorganization to the secondary host without carrying the ABW audit blocks. Step Action 1 Prior to the reorganization, change the audit transfer mode from ABW to NSC. 2 Close the current audit file. 3 Perform the reorganization

219 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment Step Action 4 Perform a dump of the database. 5 Terminate the secondary database and remove the <db>/trackerinfo file, if it is present. 6 Copy the following files to the secondary host: DESCRIPTION/DB file DMSUPPORT/DB library Database dump (from step 4) following the reorganization Audit file (from the time when step 4 was performed) 7 Remove the <db>/control file from the secondary host. 8 Copy the <db>/control file from the dump on the secondary host. 9 Reclone the database on the secondary host. 10 Change the audit transfer mode back to ABW. 11 Close the current audit file. Related Information Topics For information about... Refer to... Closing current audit file Copying the <db>/control file from the dump Dumping the database Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide

220 Updating and Reorganizing an Enterprise Database Server Database in the Remote Database Backup Environment

221 Section 10 Recovering a Database in the Remote Database Backup Environment In This Section In general, the methods of recovery available outside of the Remote Database Backup environment are also supported in the Remote Database Backup environment. There are, however, special considerations for each form of recovery; for example, a clone operation is often required following a rebuild or a rollback recovery. The following topics are presented in this section: Types of recovery in the Remote Database Backup environment Rebuild recovery Rollback recovery Halt/load and abort recovery Reconstruct recovery Recovering from a database backup using a copy from an offline dump Restoring lost or corrupt database files Types of Recovery in the Remote Database Backup Environment The following table provides a summary of the different types of recovery in the Remote Database Backup environment and of the hosts on which each can be run. Type of Recovery Rebuild Rollback Halt/Load Abort Recovery Location Can be performed only on the primary host. Can be performed only on the primary host. Usually runs automatically on the primary host after the database goes down abnormally. Runs automatically on the primary host

222 Recovering a Database in the Remote Database Backup Environment Type of Recovery Reconstruct Copy from an offline dump Recovery Location Can be performed on either host. Before running reconstruct recovery on the secondary database, it is recommended that you perform an audit file switch on the primary host when using ABW mode. Can be performed only on the primary host. Note: In a Remote Database Backup environment, recovery of any kind is allowed. You can use a combination of incremental or accumulated dumps and a full dump from either host, as long as all dumps were taken at the same host. Database Recovery Using Incremental and Accumulated Dumps When using incremental and accumulated dumps in the recovery process, the order of the dumps specified in the recovery source list construct must adhere to the following guidelines: A full dump must be designated as the first dump specification. One accumulated dump and one or more incremental dumps follow a full dump. An accumulated dump cannot follow an incremental dump. Specified dumps must be in the order in which they are performed. If the recovery starts and the dumps were not specified according to the previous guidelines, you must choose whether to abort or initialize the recovery process without using the remaining dump files. This is done by processing the necessary audit files. Rebuild Recovery Introduction Rebuild recovery rebuilds the primary database from a previous DMUTILITY dump of the database. Audit images are applied to a specified stopping point. Rebuild recovery can be performed only on the primary host

223 Recovering a Database in the Remote Database Backup Environment Performing Rebuild Recovery To recover a database using rebuild recovery, perform the following procedure. Step Action 1 Run rebuild recovery on the primary host. If you just changed the time on your system, recover to a point of time outside the hours that identify the change. 2 Clone the database unless You have rebuilt the primary database to an audit file that has not yet been transferred and acknowledged to the secondary host. You rebuild through the end of the current audit file following a normal closure of the database. Related Information Topics For information about... Refer to... Cloning the database Sections 5 and 8 Database dumps Rebuild recovery Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Rollback Recovery Introduction Rollback recovery rolls back the database to a specified stopping point. Rollback recovery begins with the current database files. The DMRECOVERY program applies audit trail beforeimages to move the database back to a specified point. Once the stopping point is reached, the audit file is truncated, purging all audit images beyond the stopping point. The stopping point specifies the minimal requirement for rollback recovery. The Enterprise Database Server might roll back the database further, depending upon the contents of the audit trail

224 Recovering a Database in the Remote Database Backup Environment Performing Rollback Recovery To recover a database using rollback recovery, perform the following procedure. Step Action 1 Run rollback recovery on the primary database. 2 Clone the database unless you have rolled back the primary database to an audit file that has not yet been transferred to the secondary host. Note: Cloning the database is the only way that the primary and secondary databases in the Remote Database Backup environment can be synchronized after a rollback recovery, unless you have rolled back the primary database to an audit file that has not yet been transferred to the secondary host. Related Information Topics For information about... Refer to... Cloning the database Sections 5 and 8 Rollback recovery Enterprise Database Server Utilities Operations Guide Halt/Load and Abort Recovery Recovery Process Recovery can be a two-step process: 1. The system rolls back incomplete transactions. 2. If the DASDL REAPPLYCOMPLETED option is set, the system reapplies completed transactions. Outside of the Remote Database Backup environment, recovery is responsible for both steps. But in the Remote Database Backup environment, Tracker performs the second step. Halt/Load Recovery Halt/load recovery runs on the primary host when the database goes down abnormally. The DMRECOVERY program, which performs the halt/load recovery, runs automatically when the first program opens the database. The DMRECOVERY program can also be run manually. A clone of the database is not required after halt/load recovery

225 Recovering a Database in the Remote Database Backup Environment The actions of halt/load recovery on the primary host are applied to the secondary database through Tracker. When a failure occurs on the secondary host, Tracker applies images starting at its last restart point. There are two occasions when halt/load recovery runs on the secondary host, as follows: If you perform a takeover because of a halt/load, then halt/load recovery runs on the old primary host the first time the database is opened. Make sure you mark the old primary as a secondary host before opening the database. Caution If communication between the hosts is not available when performing a takeover, the takeover function must be executed at both hosts. Failure to notify both hosts of the takeover leads to a duplicate-primary-host situation whereby update processing could occur at each of the hosts during the time that communication is unavailable. When communication is reestablished, Remote Database Backup detects the duplicate-primary-host situation and requires that the DBA identify the correct primary host. If a takeover is in progress and the old secondary host halt/loads, then halt/load recovery runs on the old secondary host after that host comes back online. Abort Recovery Abort recovery runs only on the primary host and is automatically performed; you do not need to initiate it. Because the database is never updated by a user program on the secondary host, abort recovery never runs on the secondary host. Related Information Topics For information about... Refer to... Abort recovery Halt/load recovery Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Takeovers Sections 6 and

226 Recovering a Database in the Remote Database Backup Environment Reconstruct Recovery Introduction Reconstruct recovery allows certain portions of the database to be reconstructed after disk failures such as disk write errors, read errors, or pack crashes. For a database in the Remote Database Backup environment, these errors can occur on either the primary or the secondary database. The designated portions of the database files are copied from a DMUTILITY dump, and audit images that affect the specified portions of the database are applied through the end of the audit files. When you perform reconstruct recovery, you do not need to clone the database. Performing Reconstruct Recovery on the Primary Database You perform reconstruct recovery on the primary database exactly the same as you would on a database that is not in the Remote Database Backup environment. You specify to the DMUTILITY program the rows to be reconstructed, and the DMUTILITY program copies those rows from dump files. Then the RECONSTRUCT program initiates a reconstruct recovery. Performing Reconstruct Recovery on the Secondary Database It is recommended that, if you are operating in ABW mode, you perform an audit file switch on the primary host before you start reconstruct recovery on the secondary database. Performing the audit file switch reduces the amount of time that Tracker must be suspended when the final phase of reconstruct recovery begins using the same audit file that Tracker is using. On the secondary database, the reconstruct recovery process operates the same as it does on the primary database. If Tracker encounters disk write errors, the rows are locked out in a way that is similar to the way rows are locked out on the primary database or on a database not in the Remote Database Backup environment. Tracker ignores audit images affecting the locked-out rows until the reconstruct recovery is done. Tracker works with the reconstruct recovery process in one of two ways, depending on whether Tracker is running when the reconstruct recovery process begins: If Tracker is running when the reconstruct recovery begins, Tracker continues to update the database. Other users continue to access the database while the reconstruct recovery is taking place until the final phase of reconstruct recovery begins using the same audit file that Tracker is using. If Tracker is not running when the reconstruct recovery begins, then once Tracker starts, it waits until the reconstruct recovery process is complete before updating the database. Other database users must also wait for the reconstruct recovery process to complete before they can access the database. It is also possible for read errors to occur when inquiry programs are accessing the database. The rows are restored in the same way as described for disk write errors

227 Recovering a Database in the Remote Database Backup Environment Requirements for a Reconstruct Recovery on the Secondary Database The following requirements apply to performing a reconstruct recovery on the secondary database: The dump used by the reconstruct recovery must have been generated when the primary database was using an earlier audit file than the one currently in use. For example, if the audit file in use on the secondary database is audit file 230, the dump must have started and finished while an earlier audit file was in use. For instance, the dump could have been performed while audit file 222 was in use. Do not use the IN PLACE option in the reconstruct recovery statement. An error occurs if you use this option. During a reconstruct recovery on the secondary database, the following steps occur: 1. You initiate reconstruct recovery on the secondary database. 2. Under ABW mode, the RDB server stops receiving audit images. 3. Tracker stops applying audit images once the recovery process starts reconstructing images in the audit file currently being applied by Tracker. 4. Under ABW mode, after reconstruct recovery completes, Catchup might run. Reconstruct Recovery with the NOZIP Option Set If you have the NOZIP option set, the reconstruct recovery does not start automatically, and you must initiate it with the following syntax: RUN RECONSTRUCT/<database name>; DATABASE DB(TITLE = <database name> ON <local family name> Local family name is the location of the database control file on the secondary host. Example R $SYSTEM/DMUTILITY ("DB = PAYDB RECOVER(ROWS USING BACKUP) PAYDB/PERSONNEL/DATA FROM TAPEX") In this example, TAPEX is the backup dump tape from the other host. The system automatically performs the reconstruct recovery operation with the structure files present on the local host. If NOZIP were specified in this example, subsequently, the RECONSTRUCT program should be run with the following syntax: R RECONSTRUCT/PAYDB;DATABASE DB(TITLE = PAYDB ON MYPACK) MYPACK is the location of the database control file on the secondary host

228 Recovering a Database in the Remote Database Backup Environment Related Information Topics For information about... Refer to... Audit synchronization Sections 1, 2, 3, 4, and 8 IN PLACE option Reconstruct recovery Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Copying Database Structures from an Offline Dump You can recover the entire database using the DMUTILITY COPY command to copy the database structures from an offline dump. The DMUTILITY COPY command can be performed only on the primary host. Performing the Copy Operation from a Dump To recover a database using the DMUTILITY COPY command, perform the following procedure. Step Action 1 Remove all database and audit files on the primary host. 2 From the backup, copy to disk the RDB control file and the audit file in use at the time of the dump. These backup copies were made when the offline dump was performed and represent the state of the database at that time. 3 Initiate the DMUTILITY COPY command. 4 Clone the secondary database, unless the audit file in use at the time of the dump has not yet been transferred to the secondary host. Caution If the audit file is not saved at the time of the offline dump, it is impossible to use the DMUTILITY COPY command to restore the database to the point immediately after the dump. This is because Tracker processes all audit images after the dump during the next database initiation

229 Recovering a Database in the Remote Database Backup Environment Related Information Topics For information about... Refer to... Database dumps DMUTILITY COPY statement Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Cloning the database Sections 5 and 8 Restoring Lost or Corrupt Database Files In the Remote Database Backup environment, four database files can be lost or corrupted: RDB control file Database control file DMSUPPORT library Database structures files Restoring a Primary Host RDB Control File To restore a lost or corrupt RDB control file for the primary host, perform one of the following actions: If the databases are synchronized, copy the RDB control file from the secondary host to the primary host. If the databases are not synchronized, perform the following procedure. Step Action 1 Reinitialize the Remote Database Backup system. 2 Enable the Remote Database Backup system. 3 Clone the secondary database. Restoring a Secondary Host RDB Control File To restore a lost or corrupt RDB control file for the secondary host, perform one of the following actions: If you have not independently updated the primary host RDB control file, copy that file to the secondary host. If you have updated the primary host RDB control file, follow the preceding procedure for restoring the primary host RDB control file

230 Recovering a Database in the Remote Database Backup Environment Restoring a Primary Database Control File If you need to copy the database control file from a secondary host database dump, ensure that the family locations are correct for the primary host. If the family locations are not correct, then before you perform the following procedure, run DMCONTROL with the FAMILY option to ensure that the correct family locations are stored. To restore the primary database control file, perform the following procedure. Step Action 1 Run SYSTEM/DMCONTROL, specifying the RECOVER UPDATE option. The Remote Database Backup system is now disabled. 2 Enable the Remote Database Backup system. 3 Clone the secondary database. Restoring a Secondary Database Control File To restore the secondary database control file, perform the following procedure. Step Action 1 Disable the Remote Database Backup system. 2 Enable the Remote Database Backup system. 3 Clone the secondary database. Restoring a Corrupt DMSUPPORT Library To restore a corrupt DMSUPPORT library, copy the DMSUPPORT library from the other host. Restoring Corrupt Database Structure Files To restore corrupt database structure files, perform a reconstruct recovery. The reconstruction can be performed with the database online. Related Information Topics For information about... Refer to... Database control file Enterprise Database Server Utilities Operations Guide

231 Recovering a Database in the Remote Database Backup Environment For information about... Refer to... DMSUPPORT library Enterprise Database Server Utilities Operations Guide RDB control file Section 5 Updating code file titles and structure locations Section

232 Recovering a Database in the Remote Database Backup Environment

233 Section 11 Using an Enterprise Application Environment in a Remote Database Backup Environment In This Section This section addresses the needs of Enterprise Application Environment database users in a Remote Database Backup environment and includes the following topics: Finding the information you need Secondary database functions Hints for successful Enterprise Application Environment operations in a Remote Database Backup environment Finding the Information You Need Three Information Sources When you configure an Enterprise Application Environment database to run in a Remote Database Backup environment, you have the following primary sources of information: Enterprise Application Environment guides These guides provide an overview of using an Enterprise Application Environment database with Remote Database Backup, and explain the steps you must perform in order to move a new or an existing Enterprise Application Environment database into a Remote Database Backup environment. This Remote Database Backup Planning and Operations Guide This guide describes the planning stages for configuring a Remote Database Backup system, how to configure the system, and how to monitor and manage day-to-day Remote Database Backup operations. It also offers hints for successful Enterprise Application Environment operations in a Remote Database Backup environment. Database Operations Center Help Database Operations Center Help text assists Enterprise Database Server for ClearPath MCP database administrators (DBAs) in using Database Operations Center, a client-based graphical user interface (GUI) for the Enterprise Database Server utilities and schema maintenance. Database Operations Center enables DBAs to perform

234 Using an Enterprise Application Environment in a Remote Database Backup Environment familiar administrative tasks, such as recovery, reorganization, backup, and analysis, from a Windows environment, as well as maintain database schemas Remote Database Backup Planning and Operations Guide References The following table lists sections of this guide and the topics in these sections that you should read. Section Topic Section 2, Understanding Audit Transmission Modes Section 3, Selecting Remote Database Backup Options and System Resources for Your Goals Section 4, Preparing to Configure a Remote Database Backup System Section 5, Configuring a Remote Database Backup System Section 7, Monitoring Your Remote Database Backup System Section 8, Managing a Remote Database Backup Environment Section 10, Recovering a Database in the Remote Database Backup Environment All topics All topics All topics Designating the audit file transmission mode Designating an error-handling option Verifying your configuration All topics Changing the audit file transmission mode All topics Secondary Database Functions Disaster Recovery The most important function of the secondary database is to take over the role of the primary database if the primary database becomes unavailable for any reason. Inquiry Programs Another function of a secondary database is to be available for inquiry programs that you run against the database. You can query the secondary database using either of the following programs:

235 Using an Enterprise Application Environment in a Remote Database Backup Environment User-written Enterprise Application Environment Reports either that are inquiry only or that use the GLB.SECONDARY data item to ensure that no update code is accessed Ad hoc query tools, such as Extended Retrieval with Graphic Output (ERGO) Hints for Successful Enterprise Application Environment Operations Introduction Following are a series of tips that might help you use your Enterprise Application Environment database in a Remote Database Backup environment. The topics are ordered alphabetically. Changing Audit Transmission Modes If you want to use the NSC mode and your database has not been cloned, then If there is network connectivity between your two hosts, the Enterprise Application Environment automatically changes the mode to SCA in order to complete the clone operation. Once the clone operation is complete, use the Mode screen to change the mode back to NSC. If there is no network connectivity between your two hosts, the Enterprise Application Environment cannot complete the clone operation. Use the instructions in this guide to complete the clone operation, and then generate your Enterprise Application Environment database in a Remote Database Backup system with the Clone DB option set to N for No. If you want to change the audit transmission mode without regenerating your Enterprise Application Environment database in a Remote Database Backup system, use the Mode screen. At the next generation of your Enterprise Application Environment database, the mode is reset to the value selected at the preceding generation, unless you change the value. Cloning Large Databases If you initiate the clone operation through the Enterprise Application Environment, then the Enterprise Application Environment automatically initiates an offline dump of your database to disk unless you specify a dump name. If there is insufficient disk space for the offline dump to complete successfully, the clone operation fails. To get around this problem, perform an offline dump of your database prior to requesting the clone, and provide the dump name and location on the Configure Remote DB Options screen

236 Using an Enterprise Application Environment in a Remote Database Backup Environment Pack Mappings During the clone operation, a copy of the database is created on the secondary host. You have the option of designating where the database structures should exist on the secondary host, or you can choose to use the default pack mappings. However, the default pack mappings used by the Enterprise Application Environment and Database Operations Center are different as explained in the following text. Default Pack Mappings for the Enterprise Application Environment As you define your Remote Database Backup environment through the Enterprise Application Environment you are prompted for a default pack location on the Configure Options screen. If you do not explicitly provide any pack mappings, then all database structures are copied to the default pack on the secondary host during the clone operation. Default Pack Mappings for the Remote Database Backup If you use Database Operations Center to perform your clone operation, by default Remote Database Backup puts the database structures on the same packs as those used on the primary host. For example, structures that reside on the ADDTEST pack on the primary host are copied to the ADDTEST pack on the secondary host; structures that reside on the DMTEST pack on the primary host are copied to the DMTEST pack on the secondary host. Preventing Update Programs from Accessing the Secondary Database If you are using Remote Database Backup for disaster recovery purposes, you need to have copies of all update programs available on the secondary host in case a takeover situation arises. Recovery Recovery in a Remote Database Backup environment is not addressed in the Enterprise Application Environment documentation. If you need to recover either your primary or secondary database, refer to Section 10, Recovering a Database in the Remote Database Backup Environment, in this guide. Takeovers If you are using the Remote Database Backup facility for the Enterprise Application Environment, takeover requests must be issued through the Enterprise Application Environment. After a takeover, before allowing users to access the new primary database, reestablish the Transaction Server transaction trail by performing the procedure described under the heading Managing the Transaction Server Synchronized Recovery in Section

237 Using an Enterprise Application Environment in a Remote Database Backup Environment Usercodes and Passwords The Enterprise Application Environment imposes a requirement that the database usercode and password must be the same on both the primary and secondary hosts. You should follow this requirement even though it is not a Remote Database Backup requirement. Using Remote Database Backup Capabilities in the Enterprise Application Environment If you made your Enterprise Application Environment database Remote Database Backupcapable without using the Remote Database Backup facility provided with the Enterprise Application Environment and now want to use the Remote Database Backup facility in the Enterprise Application Environment, you do not need to clone your database. Instead, generate your Enterprise Application Environment database with the Clone DB option set to N for No. This action generates the RDB/PARAMS file needed by the Enterprise Application Environment. Once the RDB/PARAMS file exists, you must make any changes to your Remote Database Backup environment through the Remote Database Backup facility in the Enterprise Application Environment. For example, if you request a takeover through Database Operations Center once the RDB/PARAMS file exists, the Enterprise Application Environment does not allow any update programs to be used against the new primary database until you issue the takeover request through the Enterprise Application Environment

238 Using an Enterprise Application Environment in a Remote Database Backup Environment

239 Section 12 Troubleshooting In This Section This section provides information to help you resume operations quickly if you experience Remote Database Backup operational problems. This section also provides suggestions about how to keep the need for troubleshooting to a minimum. Problem situations and solutions are organized under several areas of Remote Database Backup operation and then are listed under individual operations within the areas. The areas of operation are Remote Database Backup and Database Operations Center Takeover Primary database Secondary database Synchronization Port and network errors Updating and reorganization Failures with tape audit Minimizing Problems Suggestions To minimize the time you spend troubleshooting, ensure that You sized your hosts and network before setting up your Remote Database Backup system. You double-checked the Remote Database Backup installation on both hosts before you configured your Remote Database Backup system. (Refer to the installation checklist in Section 4.) You understood and followed the recommendations in Section 4 before configuring your Remote Database Backup system

240 Troubleshooting Only knowledgeable and well-trained personnel are making decisions about running the Remote Database Backup system on both hosts. Personnel responsible for each host are communicating with each other. You are following good database practices such as performing dumps before and after DASDL updates and reorganizations. What Troubleshooting Covers The information in this section focuses on Common causes of common problems Troubleshooting suggestions cover the known reasons for common problems. Suggestions probably do not include all the causes that generate the problem. Remote Database Backup software solutions Solutions focus on how to operate Remote Database Backup software properly and strategically. However, some problem causes might be attributed either to the management of Remote Database Backup software or to conditions in the environment in which Remote Database Backup operates. For example, when a file cannot be located, the solution text explains how to designate file locations. The solution does not address other strategies for locating files. What Troubleshooting Does Not Cover This section does not provide solutions to problems originating with software other than Remote Database Backup software such as the network and Enterprise Database Server utilities. For example, if the cause of a Remote Database Backup problem is a network failure, information is provided about how to operate Remote Database Backup while the network is down. However, no information is provided about how to fix the network failure. Resolving Operational Problems with Database Operations Center Introduction Database Operations Center operations are those that you perform using Database Operations Center and specifying the Remote Database Backup option. Instructions for accessing Database Operations Center and performing configuration operations are in Section 5. Information about other Remote Database Backup operations using Database Operations Center is in Sections 6, 7, and

241 Troubleshooting Enable Operation Enable Operation Does Not Complete Successfully under the ABW, AFS, or SCA Mode Situation The system displays the following message: An error has been encountered while attempting to open port file communication to another host. Solution Perform one or both of the following actions: Check the status of host-to-host communications. For information on network status, refer to the BNA/CNS Network Implementation Guide, Volume 1: Planning or the TCP/IP Implementation and Operations Guide as appropriate. Display the Hostinfo screen for the secondary host to verify that the pack names and RDB server file information is correct. The Enable Failed. Cannot Open the Database. Situation After initiating the enable operation from the Enable screen, the system displays the following message: The enable failed. Cannot open the database. See system messages for more information. Solution Review the system messages relating to the enable operation to determine the reason the operation was not able to open the primary database. Resolve the open error and then retry the enable operation. The Enable Failed. RDB Control File Is Resident. Situation After initiating the enable operation from the Enable screen, the system displays the following message: The enable failed. RDB control file is resident on the destination host. Retransmit to enable the destination host

242 Troubleshooting Solution Ensure that all Remote Database Backup-related and database-related files from the previously disabled Remote Database Backup system have been removed from the destination host. Retry the enable operation. The Enable Failed. RDB Control File Is Open. Situation After initiating the enable operation from the Enable screen, the system displays the following message: The enable failed. RDB control file is open on the destination host. Retransmit to enable the destination host. Solution Review the state of the database on the secondary host. If the secondary database is active, terminate it normally. If the RDBSUPPORT library is active, discontinue it. Ensure that all Remote Database Backup-related and database-related files from the previously disabled Remote Database Backup system have been removed from the secondary host. Then retry the enable operation. Clone Operation Unexpected Secondary Host Pack Designations Situation After a successful clone operation, the secondary host packs are different from the designations that you made on the Clone, Pack, Guard, and Codefile screens. Certain combinations of pack changes cannot be made by using Database Operations Center. An example of such a combination follows. Example The following structure pack mappings are entered on the Clone screen: Primary Host PACKA PACKB Secondary Host PACKB PACKA These structure pack mappings are passed as family statements to the DMCONTROL program, which processes them and reflects the changes in the database control file on the secondary host. The result of processing the first family statement

243 Troubleshooting (FAMILY PACKA = PACKB) is that all structures on PACKA in the database control file are changed to PACKB. When the second family statement (FAMILY PACKB = PACKA) is processed, all matching structures are changed to PACKA, including those structures that were originally on PACKB and those that were changed to PACKB by the previous mapping. Therefore, no structures remain on PACKB. Solution To correctly effect the intended pack mappings shown in the previous example, perform one of the following actions: Enter the structure pack mappings on the Clone screen in a pattern similar to the following: Primary Host PACKA PACKB X Secondary Host X PACKA PACKB Update the secondary host database control file using the DMCONTROL STRUCTURE statement for each structure in the database that must be mapped. Use the following WFL example as a guide: RUN SYSTEM/DMCONTROL("*"); FILE DASDL % file-equate info FILE CF % file-equate info FILE CFOLD % file-equate info?data STRUCTURE S1A FAMILY = PACKB, STRUCTURE S2A FAMILY = PACKB,? DMSUPPORT Library Fails to Initiate During a Clone Operation Situation 1 The DMSUPPORT library terminates for security reasons if the secondary host is running with the C2 security option. Solution Each time you copy a DMSUPPORT library to a secondary host that uses C2 security, mark the library as executable. For example, MP <dmsupport library name> on <PACK NAME> + EXECUTABLE

244 Troubleshooting Situation 2 The DMSUPPORT library fails to initiate because the value of the COMPILERTARGET option for the primary host is not compatible with the secondary host. Solution Set the COMPILERTARGET option for the primary host to a value that is compatible with both hosts. Recompile the DMSUPPORT library on the primary host, and then copy the recompiled library to the secondary host. Database Missing After a Clone Operation Situation A message such as the following is displayed by Database Operations Center, yet the database is not on the secondary host: The database clone has been initiated. The message indicates that the clone operation began, but not that it has completed. Solution Check for system messages associated with the CLONEDB job to determine whether the clone operation completed successfully. DMOPENERROR 66 Situation The DMCONTROL task of the clone operation fails with a DMOPENERROR 66 error message. The database is nonusercoded but has usercoded code files specified in the DASDL source file. Solution Ensure that the code files specified in the DASDL source file have a security level of PUBLIC. DMOPENERROR 67 Situation 1 The DMUTILITY program terminates on the primary or secondary host with a DMOPENERROR 67 error message. The release levels of the DMSUPPORT library and the DMUTILITY code file are incompatible

245 Troubleshooting Solution Perform one or both of the following actions: Ensure that the DMUTILITY code file is the same release level as the release level at which the DMSUPPORT library is compiled. Perform the proper procedure to transfer tailored software to the secondary host. Situation 2 The DMUTILITY program terminates on the secondary host with a DMOPENERROR 67 error message. A DMSUPPORT library compiled on a gamma machine cannot run on a beta machine. Solution Perform one of the following actions: Recompile the DMSUPPORT library on the beta machine. Recompile the DMSUPPORT library on the gamma machine with the $TARGET=LEVEL1 option and copy it to the beta machine. Timestamp Mismatch Situation During a DMUTILITY recovery function or a clone function, the system might display a timestamp mismatch if the dump being used is from a previous update level. The mismatch is between the data files and the database control file. The mismatch can occur on either the primary or secondary database. Solution Perform one of the following actions: Perform a new dump of the database and then retry the DMUTILITY recovery or clone function. Reload the old control file for the dump, and reorganize and rebuild the database. No Response from RDBSERVER During a Clone Job Situation You initiated a clone job at the primary host, but a check of messages in the mix on the secondary host shows that the RDB server has not been initiated. Either there are tasks waiting on the secondary host, or other problems exist on the secondary host

246 Troubleshooting Solution To isolate the problem, display messages and waiting entries on the secondary host, and determine whether any of the following scenarios are true: The system displays the following message: REQUIRES PK <pack name> This message means that either - The database control file pack name was not specified correctly on the Hostinfo screen. Discontinue the waiting task, display the Host screen, select Modify, and enter the correct pack name for the database control file on the Hostinfo screen. - The incorrect pack for the disk stream dump was specified on the Clone screen. Redisplay the Clone screen and enter the correct pack name for the disk stream dump. Then redisplay and transmit the Pack, Guard, Codefile, and Task screens, and rerun the clone operation. If you have not exited Database Operations Center, the screens should retain the information you entered earlier. The following message appears: The RDB control file on the secondary host may be corrupt. You should quit and recopy the RDB control file to the secondary host This message means that one of the following situations has occurred: - The enable operation which copies the RDB control file to the secondary host did not complete successfully. To verify that the enable operation did not complete, check to see whether the Remote Database Backup capability on the View Remote Auditing Status screen is marked disabled. If it is, repeat the enable operation, verify that the operation completes successfully, and then verify that the RDB control file is resident on the secondary host. If the Remote Database Backup capability on the View Remote Auditing Status screen is marked enabled, look for another cause for the message. - The RDB control file was removed accidentally from the secondary host. Check to see whether the control file is present on the secondary host. If it is not, copy the RDB control file to the secondary host. If it is, look for another cause for the message. One of the following messages appears: NO FILE / <database name>/control O FILE / <dump file name> The file that is the subject of the message (the database description file or the dump file) was not copied to the secondary host or was not copied to the correct location on the secondary host. Ensure that the file that is the subject of the message is copied to the correct pack on the secondary host, and repeat the clone operation

247 Troubleshooting There are no waiting entries, and the RDB server has not been initiated. An RDB server file name was specified that does not exist on the secondary host pack, or a pack was specified in Database Operations Center that does not exist on the secondary host. Ensure that the RDB server information on the Hostinfo screen of Database Operations Center matches the actual RDB server file name and location. Mode Change Mode Change Apparently Not Successful Situation The change you make in the audit transmission mode does not take effect immediately. The Remote Database Backup system continues to function as it did under the previous mode. Solution When a mode change takes effect depends on whether the database is open or closed when you make the change. If the database is open, the change takes effect when the next audit file switch occurs or when the database is closed, whichever event comes first. To force the mode change, enter the following Visible DBS command on the primary host: <mix number> SM AUDIT CLOSE If the database is closed, the change takes effect with the next open update operation because that operation detects the mode change and causes an audit file switch. Resolving Takeover Problems Duplicate Primary Database Situation A duplicate primary database can result during a takeover if application programs update both the new primary and the original primary databases. Two hosts and two databases can perform the role of the primary host and database in NSC mode because this mode does not use the network to communicate the status of each host. Under the following circumstances the same situation can result when using the ABW, AFS, or SCA mode:

248 Troubleshooting The hosts were not communicating when the original secondary host was made the primary host. You did not perform a takeover on the original primary host when this host became available. You performed updates against both primary databases while host-to-host communications are down. Notes: If the hosts are communicating, the system detects a potential double-primarydatabase situation as soon as a program opens one of the databases. The program cannot proceed until you perform a takeover to specify which host is to be the primary host. If the hosts are not communicating, you can detect the potential for a double-primarydatabase situation by accessing the View Remote Auditing Status screen once on either host. If you access the View Remote Auditing Status screen on one host only, the screen shows the other host as the secondary host. Solution To recover from a duplicate-primary-database situation, perform the following procedure. Step Action 1 Decide which database should be the primary database. 2 Terminate normally any update programs running on the other database. 3 Save the audit files on the other database so that later you can determine the transactions that were lost. 4 Use the Takeover screen to identify the correct primary host. If the hosts are not communicating, perform this step on the intended secondary host. 5 Clone the database. 6 Perform the following optional actions: 1. Determine the extent of lost transactions, if any. 2. Manually update the new primary database with transactions applied to the original primary database after the initial takeover, if these transactions have not already been resubmitted at the new primary database. Performing a Takeover When a Database Is Corrupted Situation 1 The primary database has been corrupted (for example, a pack or rows of a pack have been lost)

249 Troubleshooting Solution Ideally, you would first use Enterprise Database Server recovery procedures to correct the corruption on the primary database, and then perform the takeover. The assumption, however, is that circumstances are less than ideal, and that you are performing a takeover before correcting the corruption. The takeover ignores the corrupted contents of the primary database. Depending on whether the audit trails are synchronized, one of the following situations results from performing the takeover: When the audit trails are synchronized at the time of the takeover (that is, if no outstanding transactions exist on the primary host), the new secondary database retains whatever corruption existed before the takeover. You can correct the corruption by performing a reconstruct recovery, which is the only Enterprise Database Server recovery procedure available for the secondary database. If the recovery procedure does not correct the corruption, eventually you must perform either of the following actions: - A clone operation to restore the integrity of the secondary database - Another takeover to return the original primary host to primary status so that you can employ other Enterprise Database Server recovery procedures to eliminate the corruption When the audit trails are not synchronized at the time of the takeover, then the takeover causes the loss of some transactions, and you must perform a clone operation to restore the integrity of the database on the new secondary host. Situation 2 The secondary database has been corrupted (for example, a pack has been lost). Solution Ideally, you would restore the integrity of the secondary database before the takeover, either through the use of reconstruct recovery (the only Enterprise Database Server recovery procedure available for the secondary database) or by performing a clone operation. The assumption, however, is that circumstances are less than ideal, and that you are performing a takeover before correcting the corruption. The takeover ignores the corrupted contents of the secondary database. Depending on whether the audit trails are synchronized, one of the following situations results from performing the takeover: When the audit trails are synchronized at the time of the takeover (that is, if no outstanding transactions exist on the primary host), the new primary database retains whatever corruption existed before the takeover. You must then correct the corruption on the new primary database by using Enterprise Database Server recovery procedures. When the audit trails are not synchronized at the time of the takeover, then the

250 Troubleshooting takeover causes the loss of some transactions. You must perform a clone operation to restore the integrity of the database on the new primary host. Resolving Primary Database Problems Database Operations Center on the Primary Host Shows the Primary Host as Undefined Situation When you perform a software upgrade on the secondary host, and you copy files such as the database description file and the DMSUPPORT file from the primary host to the secondary host, the View Remote Auditing Status screen on the primary host shows the primary host as undefined. Solution In a Remote Database Backup system, you must perform a software upgrade first on the primary host and then copy files to the secondary host according to installation instructions in the Enterprise Database Server Getting Started and Installation Guide. The reverse procedure (upgrading the secondary host and copying files to the primary host) is not supported. Application Program Receives an Attribute Error When Catchup is Running Situation When Catchup is running, the following error message occurs: PAUDIT.LASTRECORD File Must Be Closed. This error message can be displayed up to 10 times before the application continues running normally. Solution This is a nonfatal error and occurs when Catchup is reading the current audit file. This error message does not indicate any software malfunction. Programs Wait on an AX Command Background When a program attempts to open a Remote Database Backup database, Remote Database Backup checks whether the current host is the primary host. The check involves verifying that in all audit transmission modes except the NSC mode, communications can be established between the current host and the other host

251 Troubleshooting The check involves verifying the following conditions. Condition 1 In all audit transmission modes except the NSC mode, communications can be established between the current host and the other host. If Remote Database Backup is unable to verify that the hosts can communicate, the following message appears: <database name>; RDB CANNOT COMMUNICATE WITH <host name>; AX OK WILL ALLOW PROGRAM TO CONTINUE WITHOUT A SECONDARY; ACCEPT OK, DS, RETRY <minutes>. Solution Enter one of the three alternatives specified in the message: To continue the program with the database open and without a secondary host, enter AX OK. To terminate the user program, enter?ds. To abort the OPEN operation and return the appropriate open error result to the user program, enter AX DS. All open errors are fatal unless the program has an errorhandling routine to handle the result of the open operation. To retry the operation immediately, enter AX RETRY or AX RETRY 0. Condition 2 The current host is the only host that is marked as primary. If Remote Database Backup is unable to verify that the current host is the only host that is marked as primary, the following message appears: <database name>; <other host> IS AN [inactive active] primary (AT AFN=nn ABSN=nn mm/dd/yy hh:mm:ss); THIS HOST IS ALSO AN RDB PRIMARY (AT AFN=nn ABSN=nn mm/dd/yy hh:mm:ss); THE TAKEOVER DOCUMENTATION MAY HELP RESOLVE THIS PROBLEM; ACCEPT DS or RETRY < minutes >. Solution Enter one of the two alternatives specified in the message: To terminate the program, enter?ds. To abort the open operation and return the appropriate open error result to the user program, enter AX DS. All open errors are fatal unless the program has an errorhandling routine to handle the result of the open operation. To retry the operation immediately, enter AX RETRY or AX RETRY

252 Troubleshooting DMOPENERROR 66 Situation Access to the primary database results in a DMOPENERROR 66 error message after you copy the database control file from a dump of the secondary host. Solution Ensure that the family locations in the database control file are correct for the primary host. If they are not, run DMCONTROL with the FAMILY option to correct the family locations. Audit Copy Fails in AFS Mode Situation 1 File transfer fails to copy audit files from the primary host to the secondary host when Remote Database Backup is operating under the AFS mode and using BNA. Solution If the Remote Database Backup database is nonusercoded, you might not have established a privileged usercode and password for the database or modified the RDB support library. Perform the following procedure. Step Action 1 Establish a privileged usercode (and password) as a remote user on the primary and secondary hosts. 2 Use a WFL statement to modify the title attribute of the NFTINFOFILE file to the usercode and password established in step 1. The syntax is as follows: WFL MODIFY *SYSTEM/ RDBSUPPORT; FILE NFTINFOFILE (TITLE = <usercode>/<password>); The RDB support library should be modified on both hosts or modified on one host and copied to the other host. 3 Prepare the RDB support library using the SL (Support Library) system command. The syntax is as follows: SL RDBSUPPORT = *SYSTEM/RDBSUPPORT ON DISK Situation 2 File transfer fails to copy audit files from the primary host to the secondary host when Remote Database Backup is operating under the AFS mode with BNA, and the usercode of the database requires an accesscode. A log entry exists with the following message: "RDB: AUDIT FILE COPY JOB HAS SYNTAX ERRORS" "RDB: AUDIT FILE # NN COPY FAILED, RECOPY REQUIRED" P-DS <database name>/auditxfer/auditnn

253 Troubleshooting Solution Usercode compatibility problems might exist between the primary host and the secondary host. Review the guidelines for usercodes under Usercode Factors in Section 4. Until the problem is solved, manually copy the audit files that could not be copied to the secondary host, and send an acknowledgment of the audit files as discussed in Section 8. Remote Database Backup Fails to Initiate at the Primary Host Because of Audit Open Errors Situation Audit at the primary host is corrupted. Tracker or Catchup-server fails continually with audit open errors. If a good audit file cannot be provided, perform either of the following solutions. Solution 1 Use a complete database dump and rebuild the database through the audit file that precedes the corrupted file. Take a complete database dump, and then clone the database at the secondary host using the new dump file. Solution 2 Disable Remote Database Backup. Repair the database using standard Enterprise Database Server procedures. Perform a complete database dump, and enable Remote Database Backup. Finally, clone the database at the secondary host using the new dump file Resolving Secondary Database Problems Application Program Waits for Tracker Quiet Point Situation You attempt to open the secondary database for the first time after a clone operation, and an application program is suspended with the following message: WAITING FOR TRACKER QUIET POINT TO ALLOW INQUIRY The waiting condition exists until Tracker encounters a quiet point that has a timestamp greater than or equal to the timestamp at the end of the dump tape used for the clone operation. Solution Update the primary database until a quiet point is audited, transferred to the secondary host, and processed by Tracker

254 Troubleshooting STRUCTURECLONE Required Following Successful STRUCTURECLONE Situation A STRUCTURECLONE is performed and reports STRUCTURECLONE COMPLETED OK. However, subsequent efforts to access affected structures result in VERSION errors stating that a structure clone is required. Any attempt to restart the STRUCTURECLONE job results in a STRUCTURECLONE NOT REQUIRED message. Solution Perform a RECONSTRUCT operation (such as DMUTILITY RECOVER) on all affected structures. READONLY 1#2 Error Situation Application programs accessing the secondary database terminate with a READONLY 1#2 error. These programs attempted to enter transaction state at the secondary database. The error is displayed because the secondary database cannot be updated. It can be inquired upon only. Solution Disable the update functions of programs that access the secondary database. DMOPENERROR 37 Update Level Mismatch Situation The system discontinues an application program on the secondary host with an DMOPENERROR 37 error message and displays an update level mismatch message. The timestamps of the database control file and the DMSUPPORT library are incompatible. You have probably performed a DASDL compilation on the primary database that resulted in a change to the database update level, and you did not correctly transfer the tailored software to the secondary host. Solution Perform one of the following actions: Transfer tailored software to the secondary host. Clone the database. (For clone operation instructions, refer to Sections 5, 8, and 9.) Unexpected Audit Block Serial Number

255 Troubleshooting Situation 1 A manual recovery at the primary host, such as a rebuild or rollback results in the removal of audit records from the audit trail. The audit records that were removed have already been applied to the secondary database. Solution Reclone the database at the secondary host. Situation 2 On rare occasions, an automatic recovery such as a recovery initiated as the result of a system halt/load at the primary host can create audit inconsistencies between the audit trails at the primary and secondary hosts. Solution Depending on your audit transfer mode, perform one of the following audit synchronization solutions. Each audit transfer mode has different requirements. Audit Mode NSC, SCA, AFS ABW AFM Solution Manually copy the necessary audit file or files, including the entire recovery region, from the primary host to the secondary host. Copy only complete audit files; the audit file currently in use by the primary database should not be copied until it is complete. Acknowledge the audit file or files copied. You might need to discontinue the Tracker task at the secondary host. A special Catchup process called a Catchup from previous quiet point is automatically performed. This mode discontinues itself. When Tracker restarts, the processing starts from the previous restart point and applies the new audit trail, including the recovery region. Situation 3 When Tracker is processing audit in AFM mode, on rare occasions if the mirrored disk set is involved in a self-correcting error by external processes (such as SRDF software), Tracker faults due to inconsistencies between the source and target disks of the mirrored set. Solution Tracker discontinues itself. When Tracker restarts, the processing restarts from the previous restart point and continues to apply audit images from the self-corrected disk

256 Troubleshooting DMOPENERROR 66 Situation An application program terminates with a DMOPENERROR 66 error message. The application cannot locate the DMSUPPORT library. Solution Verify that the location of the DMSUPPORT library on the secondary host corresponds to your entry on the Pack screen for the clone operation. If not, perform one or more of the following actions: If you have a clone WFL job, look in the program for the DMSUPPORT library pack you specified during the clone operation. List or write the database control file to check on the pack name for the DMSUPPORT library, and modify that pack name if necessary. Perform one of the following actions: - Move the DMSUPPORT library to the pack designated in the database control file. - Run SYSTEM/DMCONTROL to change the DMSUPPORT library pack location. DMOPENERROR 73 Situation An attempt to open a Remote Database Backup database results in a DMOPENERROR 73 error message. The RDB support library is not available or cannot be located. Solution Ensure that the RDB support library is resident on the primary host and that it has been established by means of the system command SL (Support Library). Tracker Stays in the Mix Situation You have disabled Tracker but Tracker does not leave the mix. Solution Tracker cannot leave the mix until it encounters a control point that it can designate as a restart point. The solution depends on the mode under which the Remote Database Backup system is operating and the action that is occurring on the primary database:

257 Troubleshooting Under the ABW mode, if the primary database is actively being updated, you can wait until a control point occurs. Otherwise, you can perform one of following actions to force the occurrence of a control point: - Close the primary database. - Perform a number of transactions. There is no exact number; it depends on the settings for syncpoint and control point, and the number of transactions that have transpired since the last control point was taken. - Perform a number of database close operations, that is, have a number of tasks close the database, or have a single task perform several database open and close operations. The exact number of close operations that are needed depends on the settings for syncpoint and control point, and depends on the number of syncpoints that have accumulated since the last control point was taken. Performing a number of database close operations differs from performing a number of transactions because each time a program closes its database invocation, Enterprise Database Server forces a syncpoint. The task does not necessarily go to end of task and does not necessarily bring down the database stack. Control points occur every n number of syncpoints. You specify the value of n in the DASDL source file; the default is 2. Under the AFS, SCA, or NSC mode, you might need to transfer and acknowledge the next audit file before Tracker finds a control point. Depending on the transactions being performed at the primary database, you might have to perform multiple audit file transfers and acknowledgments before a control point occurs. For information on how to manipulate the frequency of restart point occurrences, refer to Section 4. NO FILE SYSTEM/ACCESSROUTINES Message Situation 1 The system displays the following message: <mix number> NO FILE SYSTEM/ACCESSROUTINES ON <pack name> Solution You might have specified an incorrect pack name for the Accessroutines on the Pack screen during the clone operation. (For information about the clone operation, refer to Sections 5, 8, and 9.) To establish the correct pack location for the Accessroutines, perform one of the following actions: If you saved the clone WFL program, insert the correct pack name in the WFL program and rerun the program. (For information about restarting a clone WFL program, refer to Section 8.) Run a control file update. (For information on how to perform a control file update, refer to Section 9.)

258 Troubleshooting Situation 2 Your Accessroutines file is not located on DISK and the DASDL specification does not include the family name. Solution Perform a DASDL update that specifies the Accessroutines file title. NO FILE <database name>/control Message Situation The system displays the following message: <mix number> NO FILE <database name>/control ON <primary database control file family name> A program that runs on the primary host does not run on the secondary host. Solution 1: Application Program or WFL Job Perform one of the following actions: Include a database equation in the RUN statement by using the following syntax: RUN <program name>; DATABASE <database name> (TITLE = <database name> on <pack name>) From CANDE, use the WFL MODIFY command to modify the database title attribute of the application program as follows: WFL MODIFY <program code file name>; DATABASE <database name> (TITLE = <database name> on <pack name>) Solution 2: Database Certification, dbatools, or DUMPDIR When you are running Database Certification, dbatools, or DUMPDIR on the secondary database, use the following syntax: RUN <program code file name>; FILE CF(TITLE = <database name>/control ON <pack name>) Solution 3: ERGO with Database Interpreter When running ERGO and accessing the database through the DMINTERPRETER library, refer to solution 4 to modify the DMINTERPRETER library. Solution 4: Database Interpreter or Inquiry When running Database Interpreter or Inquiry, use the following WFL MODIFY command statement to identify the database name as DB: WFL MODIFY <program code file name>; DATABASE DB (TITLE = <database name> on <pack name>)

259 Troubleshooting RDB CONTROL FILE ERROR: RDB CONTROL FILE NOT RESIDENT Message Situation When the RDB server is initiated on the secondary host after the RDB control file has been lost on the secondary host for some reason, the RDB server hangs and Remote Database Backup displays the following message: RDB CONTROL FILE ERROR: RDB CONTROL FILE NOT RESIDENT Solution Perform the procedure for restoring a lost or corrupt RDB control file. (For the procedure, refer to Section 10.) Guard File Read/Write Access Situation The system displays unexpected security messages, refuses file access on the secondary host, or allows access to nonprivileged users. Solution Ensure that guard files have been Copied from the primary host and are resident on the secondary host Attached to the database by means of the DASDL source file Otherwise, during a reorganization or a clone operation, the guard files do not travel with the files to new locations. Set up with the required read/write access. For information on guard file read/write access, refer to the DASDL Programming Reference Manual. SYSTEMERROR 6 Fatal Software Error Situation When the primary and the secondary hosts are not compatible (for example, the primary host is a gamma machine and the secondary host is a beta machine), running programs that are compiled on the primary host can cause one of the following messages to display on the secondary host: FATAL ERROR IN DB SYSTEMERROR 6 THIS CODEFILE NOT COMPATIBLE WITH MACHINE

260 Troubleshooting Solution Recompile the program on the secondary host. ERROR: STRUCTURE: <structure name> STRUCTURECLONE NOT REQUIRED Situation During the application of a reorganization to the secondary database for which new sets or data sets have been added, and for which the added structures require pack information that is different from the pack information on the primary database, Tracker waits after issuing the following messages: NO FAMILY <family from primary> REQUIRES PK <primary packname> If you begin the structure clone WFL job before giving the Tracker task the pack information it needs to finish processing the reorganization information in the audit trail, the following error is displayed for each structure that needs a structure pack update and that needs a structure clone operation: ERROR: STRUCTURE: <structure name>: STRUCTURECLONE NOT REQUIRED Solution Follow the procedure explained under Adding New Structures in Section 9. If the pack name for the added structures is different between the two hosts, you must complete the reorganization process by performing the following steps before creating the structure clone WFL job on the secondary host. Step Action 1 Respond to the Tracker waiting message by issuing the IL (Ignore Label) system command in the following format:?<waiting Tracker mix number> IL PK <pack number location for new structures> 2 When Tracker completes the processing of the reorganization information in the audit trail, make sure that no application accesses the database. 3 Run the DMCONTROL program using the STRUCTURE FAMILY syntax to supply the correct family information for the added structures

261 Troubleshooting Reestablishing Synchronization Resolving Catchup Problems Catchup Does Not Run After Mode Change from SCA or NSC to ABW Situation The following events occurred in the order shown: 1. Under the SCA or NSC mode, a successful clone operation completed. 2. The audit file that was current at the start of the clone operation was copied to the secondary host. 3. The mode was changed to ABW. 4. When the primary database or the secondary database was opened, Tracker initiated on the secondary host. However, Catchup did not initiate on the secondary host to transfer the audits that were created during operation under the SCA or NSC mode. Solution To initiate Catchup, perform one of the following actions: Using Database Operations Center, acknowledge the audit file number that was transferred in event 2. Copy all audit files created under the SCA or NSC mode to the secondary host and then acknowledge the last audit file number. Catchup Does Not Run After a Secondary Host Halt/Load Situation Your Remote Database Backup system is running under the ABW mode, and a halt/load just completed on the secondary host. The View Remote Auditing Status screen shows that audits are not being applied to the secondary database even though update programs are running on the primary host. Solution The audit synchronization process eventually runs because RDB-agent checks for synchronization at set intervals. (For information on RDB-agent intervals, refer to Section 4.) However, if you do not want to wait for the RDB-agent process, you can initiate audit synchronization on the secondary database after a halt/load by ensuring that Host-to-host communications are available. The secondary database is open by one of the following means:

262 Troubleshooting Initiation by the primary database An inquiry program Catchup from Previous Quiet Point Fails Repeatedly Situation A halt/load at the primary host occurs during transactional activity. In some cases, the resulting recovery removes audit records from the end of the audit trail. When this happens, an initial failed Catchup task occurs and the following message appears: CATCHUP FROM PREVIOUS QUIET POINT REQUIRED In some cases, the next Catchup task initiated from the previous quiet point also fails with the same message. When this occurs, the problem might not be self-correcting and all subsequent Catchup requests continue to fail with the same message. Solution First, manually synchronize the audit past the recovery region. You can copy the audit file or files to the secondary host as soon as the primary database has switched to the next audit file. If the database is still using the current audit file, either wait until the next natural audit file switch, or force an audit switch by performing a database SM AUDIT CLOSE request. Acknowledge the copied audit file using Database Operations Center Monitor the Tracker activity at the secondary host using Database Operations Center. When Tracker has applied the audit region around the time of the recovery, which can be determined by comparing the original messages that are issued by the Catchup task at the secondary host, the catchup condition should be cleared automatically. If Tracker has successfully applied the audit beyond the failing catchup region and subsequent catchup attempts are still failing with the same message, correct the latent Catchup task from previous quiet point information by performing the following procedure: 1. Find the mix number of the <database>/rdsupport task for the affected database from an operator display terminal (ODT). 2. Issue the following command, using that mix number for <mix>: <mix> HI 20 If the catchup condition is still set in the database control file, this activity triggers the following message from the database: CFHLRECOVERY CLEARED

263 Troubleshooting Resolving Tracker Problems Secondary Audit Trail Not Synchronized Situation Your Remote Database Backup system is running under the ABW mode, and a halt/load occurs on the secondary host. The View Remote Auditing Status screen shows that the secondary database audit trail is not synchronized with the primary database audit trail. Audit synchronization and tracking operations automatically begin on the secondary host as soon as the primary or secondary database is opened or as soon as the RDB support library is initiated on the primary host. Solution Audit synchronization occurs eventually. However, to start audit synchronization and tracking operations immediately, perform one of the following actions: If the secondary database is closed, open it by running an inquiry program that accesses the secondary database. If the primary database is closed, open it by running any program that accesses the primary database. In ABW Mode, Tracker Does Not Run After a Successful Clone Operation Situation After you clone the database and the first transactions are being generated on the primary database, the View Remote Auditing Status screen records the transfer of audit blocks, but the audit blocks are not being applied. Tracker is not running. Explanation The initiation of Tracker requires that an inquiry program must open the secondary database. Partial Audit File Message Under the SCA or NSC Mode Situation The system displays the following message: The audit file: nn on the secondary host may be a partial audit file. You have performed the following actions in the order indicated:

264 Troubleshooting 1. Under the SCA or NSC mode, you synchronized the audit trails by copying necessary audit files, including the current partial audit file, to the secondary host. 2. You acknowledged the audit files. 3. You continued updating the primary database under either the SCA or NSC mode for a period of time. 4. You copied and acknowledged additional audits. 5. When action 4 was complete, Tracker initiated on the secondary host and failed on the last audit that was copied during action 1. Tracker cannot process the next audit because of the partial audit copied from the primary host. Solution Perform the following procedure. Step Action 1 When Tracker leaves the mix after the failure, manually recopy the audit file from the primary host, thus replacing a partial audit file with a complete (full) audit file. 2 Initiate Tracker by opening the secondary database or by acknowledging the last audit file number again. Tracker Stops Applying Audit to a Partitioned Structure Situation Tracker stops when attempting to apply an audit to a partitioned structure. Solution Ensure that the value specified in the data structure OPEN PARTITIONS option in the DASDL source file is inflated sufficiently so that applications on the primary host and inquiry programs on the secondary host have ready access to a partitioned structure. Tracker Stops Applying Audit Images in SCA or NSC Modes Situation 1 If you acknowledge an audit file that you intended to acknowledge, but the acknowledged audit file or prior audit files are not present on the secondary host, then Tracker hangs waiting for the absent audit file. Solution Perform the following procedure

265 Troubleshooting Step Action 1 Close the current audit file using a Visible DBS SM AUDIT CLOSE command. 2 Copy all the audit files that are not resident on the secondary host, up to and including the audit file you closed in step 1. 3 Acknowledge the audit file you closed in step 1. Tracker begins processing all audit files through the audit file you acknowledged. Situation 2 If, by mistake, you acknowledge a nonexistent audit file with a number higher than the audit file number you intended to acknowledge, Tracker hangs waiting for the next audit file that Tracker expects to process and that is not present on the secondary host. Solution Perform the following procedure. Step Action 1 Allow further updating to take place on the primary database, and then copy the audit files from the primary to the secondary host. 2 Acknowledge the correct audit file (the last in a consecutive series). Tracker begins processing all audits through the audit file you acknowledged. Resolving Miscellaneous Problems Current ABSN Is Less Than Received ABSN Situation After a halt/load or during a recovery operation on the primary host, the View Remote Auditing Status screen shows a current ABSN value that is less than the received ABSN value. Solution Depending on the interval between the last update of the RDB control file and the time of the system interruption, the value retrieved by Database Operations Center from the RDB control file can be out-of-date. Wait to access the View Remote Auditing Status screen until the first audit transmissions take place after the recovery operation. As soon as the primary host has recovered and transmits the first audit block, Database Operations Center updates the value of the current ABSN

266 Troubleshooting Tracker Fault After Mode Change from AFS to ABW Situation After a mode change from AFS to ABW, the Catchup task comes up and Tracker receives a fatal error. Solution When Tracker restarts, it proceeds normally. RDBSUPPORT Library Unavailable Situation On rare occasions, a process attempting to link to an RDBSUPPORT library that is terminating at the same time may fail with the following message: RDBSUPPORT: LIBRARY IS UNAVAILABLE Solution Restart the process and it will link to a new RDBSUPPORT library instance. Version Mismatch Situation VERSION MISMATCH. RDBSUPPORT VERSION: <n> OTHER COMPONENT S VERSION: <n> This message can occur in two situations. The RDBSUPPORT SL references a SYSTEM/RDBSUPPORT file that has a different Mark release version than the SYSTEM/ACCESSROUTINES file. The SYSTEM/RDBSERVER file on the remote host has a different Mark release version than the SYSTEM/RDBSUPPORT file on the local host. Solution For Situation 1, change the RDBSUPPORT SL so that it references a version of the SYSTEM/RDBSUPPORT file that matches the SYSTEM/ACCESSROUTINES file. For Situation 2: 1. In the Database Operations Center, display the Remote Database Backup: Modify or View Host Information screen and verify that the title for RDB Server has been entered correctly. 2. If the file title is correct, then the DMSII software installed on one of the hosts must be changed to match the other host

267 Troubleshooting Resolving Port and Network Errors Interhost Connection Test Fails Situation 1 Using the TCP/IP network service, the following error is returned when the interhost connection is tested: <dbname>: UTILITY REQUEST ERROR: THE COPIED TEST FILE IS NOT PRESENT AT THE REMOTE HOST. Solution If secure FTP has been configured (FTPS), check for SSL configuration errors in the sumlog of the local host. For example, the following messages from the (<usercode>)ftp/file/transfer/to/<hostname> task: FTP: SSL negotiation failed. CLOSE REASON: Certificate authentication failed (-244) >>>>> FAILURE TYPE = Security Violation <<<<< Situation 2 Using the TCP/IP network service, the following error is returned when the interhost connection is tested: UTILITY REQUEST ERROR: THE DESTINATION HOST IS NOT CURRENTLY COMMUNICATING WITH THIS SESSION. Solution Two of the possible causes are: An invalid remote server name. The sumlog on the remote host should have the following message from the JOB/<dbname>/RDBSERVER job: <invalid server title> NOT RESIDENT. An invalid remote usercode or password. The sumlog on the remote host should have the following message from the JOB/<dbname>/RDBSERVER job: SECURITY VIOLATION - INVALID TASK ATTRIBUTE: USERCODE VIOLATION CODE: 32 (USERDATA ERRORCODE: 10) ERROR ITEM: <usercode> Situation 3 Using the TCP/IP network service, the following error is returned when the interhost connection is tested:

268 Troubleshooting <dbname>: UTILITY REQUEST ERROR: A PORTFILE COMMUNICATION ERROR TO HOST <host> HAS BEEN ENCOUNTERED. SEE THE SUMLOG FOR A MORE DETAILED ERROR MESSAGE FOR THIS DATABASE. Solution One possible cause is an invalid SL for the RDBSUPPORT library at the remote host. The sumlog on the local host should have the following message from the (<usercode>)<dbname>/rdbsupport library: <dbname>: RDBSP, FILE OPEN ERROR: OFFER TIMED OUT FOR HOST <host>, SUBFILE Situation 4 Using the BNA network service, the following error is returned when the interhost connection is tested: UTILITY REQUEST ERROR: THE DESTINATION HOST IS NOT CURRENTLY COMMUNICATING WITH THIS SESSION. Solution Two of the possible causes are: An invalid SL for the RDBSUPPORT library at the remote host. The sumlog on the remote host should have the following message from the SYSTEM/RDBSERVER job: Function <SL name> is not defined. SL, FA or DS An invalid remote server name. Audit Transfer Stops at the Secondary Host Situation 1 When your Remote Database Backup system is running under the ABW mode, Remote Database Backup stops transferring audit blocks to the secondary host, there is a CONTROLCARD waiting on a NO FILE <COPYAUDIT WFL name> exception, and the application program eventually displays a port-i/o timeout error. The COPYAUDIT WFL job is not resident on the secondary host under the correct title. Solution If you are using the default COPYAUDIT WFL job under the default file name, ensure that the file *DATABASE/WFL/COPYAUDIT has been copied to each host as part of the Remote Database Backup installation. Otherwise, ensure that the correct title is specified in the DASDL source file

269 Troubleshooting Situation 2 The ACRSERVER task on the secondary host is waiting with the following message: Sectors required on PK <audit pack> The ACRSERVER task must write audits to the audit pack as part of its normal operation. After the audit files have been applied by Tracker, they are removed by the action of the COPYAUDIT option. Solution Check for one or more of the following conditions and perform the actions suggested: If Tracker is not active, initiate Tracker by running an inquiry program on the secondary host. If Tracker has finished applying audit files that are present on disk, then applied audit files are not being removed from disk. Check for a problem with the COPYAUDIT WFL job. For example, perhaps the tape drive to which the COPYAUDIT WFL job is writing is not ready or there are waiting entries. If there is an unexpected accumulation of unapplied audits, then Tracker is not applying audits as fast as they are being generated. Check for the following possibilities: - If Tracker is applying audits more slowly than is normal for your site, check the priority for Tracker, check the overall performance of the secondary host, or check both. - If Tracker is applying audits at the normal rate for your site, investigate a sizing mismatch between your primary and secondary hosts. If nondatabase application files (that is, files other than audit files) are accumulating, then move those files. If none of the preceding conditions are present, then pack space might simply be inadequate. Situation 3 After a clone operation, Remote Database Backup stops transferring audit blocks to the secondary host under the ABW mode, and Catchup does not come up on the secondary host. Solution Perform the following procedure. Step Action 1 Run Database Operations Center on the secondary host

270 Troubleshooting Step Action 2 Perform one of the following actions on the View Remote Auditing Status screen, depending on the value in the Received AFN field: If the received AFN value is less than the number of the audit file in use at the start of the dump, go to step 3. If the received AFN value is the number of the audit file in use at the start of the dump, make sure that the audit file is present on the secondary host. 3 Display the Acknowledge screen, and acknowledge the AFN value that was in use at the start of the database dump. Port-I/O Timeout Exceeded Situation Communication between the primary and secondary hosts has been stopped longer than the port-i/o timeout interval designated when you configured the Remote Database Backup system. The cause can be any factor that would delay or prevent the completion of a communication. Solution Check the following possible causes of the port-i/o timeout interval being exceeded, and take appropriate action to address the cause. If none of the following causes apply, investigate other possible causes. The title of the RDB server code file is not correctly specified in Database Operations Center. An RDB server task was discontinued, hung, or is running at a low priority. A host is halt/loading or dumping. A Remote Database Backup task is waiting on a NO FILE condition. The network is down. The RDB server task cannot run on the secondary host because - A task attribute of the primary host task is not valid on the secondary host. - The database usercode is not defined as a remote user in the USERDATAFILE of the secondary host. The log-in process on the secondary host did not complete. In the system log on the secondary host, look for a message regarding the Remote Database Backup software, such as one of the following messages: RDB Control File Creation Time Stamp Mismatch RDB Control File Not Resident RDB Login Failed Database Control File Not Resident

271 Troubleshooting Frequent Port-I/O Timeout Errors Situation The system reports port-i/o timeout errors frequently. Solution Consider making one of the following changes: Increase the number of audit blocks per acknowledgment if you use the ABW mode. Lengthen the interval specified for the port-i/o timeout. The default is 60 seconds. Some factors that might justify a value greater than the default are as follows: The number of nodes, which is also known as the hop count For information on node and the hop count, refer to the BNA/CNS Network Implementation Guide, Volume 1: Planning or the TCP/IP Implementation and Operations Guide as appropriate. Machine loading/program priorities Network traffic levels Factors to consider when increasing the port-i/o timeout value are as follows: All primary database activity can be suspended for intervals as long as the timeout value if the secondary host is slow in acknowledging receipt of audit blocks. This suspension can affect primary database performance. Increasing the timeout value might mask an underlying performance problem in the network or on the secondary host. Frequent Communications Errors Situation The Remote Database Backup system runs with frequent communications errors. Solution An error in network communications can be caused by one or more factors. To detect possible causes, ensure that No task is suspended on either host. For example, if a port-i/o timeout error occurs, the primary or secondary database could be waiting for disk space. Physical network connections are intact. Network communications are enabled. The system is not contending for resources. For example, using the same pack for both sumlog and overlay could cause the system to stop processing momentarily if the designated pack becomes full

272 Troubleshooting Port Subfile State Error Situation The system displays the following message: PORT SUBFILE STATE ERROR: WRITE TIMEOUT: RSLT: xxxxxxx The RDB support library on the primary host cannot see the RDB server code file on the secondary host. Solution Verify that the title of the RDB server code file on the Hostinfo screen matches the title of that file on the secondary host. Unexpected Port File Errors with a Database Using TCP/IP or a Nonusercoded Database Using BNA Situation When opening a database using TCP/IP or a nonusercoded database using BNA, port file errors begin to occur where none previously occurred. Solution Ensure that the settings for the job queue have not been changed recently. Remote Database Backup automatically creates, at run time, the required WFL job for initiating processes on the secondary host. The WFL job runs under the default queue or under a queue you have set up for Remote Database Backup tasks on the secondary host. Therefore, you must ensure that the attributes associated with the queue do not prevent Remote Database Backup processes from running correctly. Resolving Updating and Reorganization Problems Reorganization Waits While Looking for a Pack Situation A reorganization on the secondary database waits because the Tracker fix-up task is looking for a pack called DISK or some other pack name. The Tracker fix-up task message includes the following syntax: <structurename>/fixup on DISK (or other pack name) One of the following actions has occurred:

273 Troubleshooting You have used SORT USING or INTERNAL FILES parameters in the BUILDREORG specifications without specifying a pack (the default for these parameters is DISK), and there is no pack named DISK on the secondary host. You have used SORT USING or INTERNAL FILES parameters in the BUILDREORG specifications and have specified a pack that does not exist on the secondary host. Solution For each structure affected by the BUILDREORG that uses the parameter SORT USING or INTERNAL FILES, enter the following commands in the order shown: <mix number> OF <mix number> IL <existing pack on secondary host> DMOPENERROR 0 or DMOPENERROR 37 Situation While manually transferring the reorganization files to the secondary host, you copied the reorganization files before copying the DMSUPPORT files, and the reorganization started before the new DMSUPPORT files were available. The inadvertent use of the old DMSUPPORT file by the REORGANIZATION program causes the DMOPENERROR error message. Solution Ensure that all the required reorganization files are transferred to the secondary host, and start an inquiry program that reruns the reorganization. NO FILE Condition on a New Structure Situation You performed a DASDL update to the primary database for which the only change was the addition of a data set and its sets. When an inquiry program attempts to access the new data set on the secondary database, the system displays a NO FILE condition message on the new structure. Solution The inquiry program cannot find the structure because the structure has not yet been initialized on the secondary database. To initialize the data set on the secondary database, perform the following procedure

274 Troubleshooting Step Action 1 Open the new data set or its sets for update on the primary database. The initialization of the data set and its sets is entered into the audit trail. 2 Ensure that the audit is transferred to the secondary host and applied to the secondary database. Handling Large Reorganizations For a large reorganization on the primary database, you might save time and resources by suspending audit transfer before the reorganization and then recloning the database using a dump taken after the reorganization. Use the following procedure to apply a reorganization to the secondary host without carrying the ABW audit blocks. Step Action 1 Prior to the reorganization, change the audit transfer mode from ABW to NSC. 2 Close the current audit file. 3 Perform the reorganization. 4 Perform a dump of the database. 5 Terminate the secondary database and remove the <db>/trackerinfo file, if it is present. 6 Copy the following files to the secondary host: DESCRIPTION/DB file DMSUPPORT/DB library Database dump (from step 4) following the reorganization Audit file (from the time when step 4 was performed) 7 Remove the <db>/control file from the secondary host. 8 Copy the <db>/control file from the dump on the secondary host. 9 Reclone the database on the secondary host. 10 Change the audit transfer mode back to ABW. 11 Close the current audit file

275 Troubleshooting Related Information Topics For information about... Refer to... Closing current audit file Copying the <db>/control file from the dump Dumping the database Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Resolving Tape Audit Failures Introduction The Tracker, Catchup, and Catchup-server tasks can run into trouble when a database has an audit definition that includes an ALTERNATE IS TAPE specification, and the audit is switched to tape. Tracker Task at the Primary Host Situation The last audit file accessed by the primary host before the database went down was a tape file. Tracker might fail with an error such as AUDIT REEL SWITCH SHOULD NOT BE NECESSARY. Solution Use the COPYAUDIT utility to copy the audit file from tape to the audit family pack. Catchup-Server Task at the Primary Host Situation 1 The Catchup-server task stops sending audit information because the task encounters audit information on tape and displays the following message: CANNOT USE AUDIT WRITTEN DIRECTLY TO TAPE, USE COPYAUDIT FOR db/audit5. The Catchup task at the secondary host is failing. Solution Use the COPYAUDIT utility to copy the audit file from tape to the audit family pack

276 Troubleshooting Situation 2 The Catchup-server task needs to open an audit file that is on tape, and that audit file is the current audit file in use by the database audit. The task stops sending audit information to the secondary host and displays the following message: CANNOT READ TAPE AUDIT UNTIL THE NEXT AUDIT FILE SWITCH The Catchup task at the secondary host is failing. Solution Use the COPYAUDIT utility to copy the audit file from tape to the audit family pack

277 Section 13 Programmatic Interfaces In This Section This section includes information on the following topics: Establishing the link to the RDB support library Using the takeover entry point Using the GET_PRIMARY_MODE entry point Using the SET_RDB_MODE entry point Using the GET_RDB_MESSAGE entry point Establishing the Link to the RDB Support Library Introduction Instead of using Database Operations Center, you might want to write your own utility program to perform Remote Database Backup functions. Such a program would enable you, for example, to automate some of your Remote Database Backup operations. Your program must call entry points in the RDB support library to perform the desired function. The entry points described in this section are currently supported. Declaring the RDB Support Library The RDB support library is declared in an ALGOL program with the following declaration: LIBRARY RDBSUPPORT (LIBACCESS = BYFUNCTION,FUNCTIONNAME = "RDBSUPPORT." ); Making the RDB Support Library Ready for an Entry Point Call To make the RDB support library entry points available, before you call the library, you must set the library parameter as follows: RDBSUPPORT.LIBPARAMETER:= "(<usercode>)<database title> ON <pack name>";

278 Programmatic Interfaces Using the Takeover Entry Point What the Takeover Entry Point Does A Remote Database Backup takeover is a process that enables the secondary database to assume, or take over, the role of the primary database. You can automate the takeover process by using the entry point defined in the RDB support library. The automatic takeover process is an alternative to the manual takeover process described in Section 6. When to Automate a Takeover You can use an automatic takeover when the takeover situation is predictable, identifiable, and repeatable. For example, a planned takeover for database maintenance purposes would be a candidate for an automatic takeover. When you write your ALGOL program to automate a takeover in a predictable situation, you must cover every circumstance of the takeover situation in the program. When to Require Manual Intervention For all unplanned takeovers, manual intervention of some sort is suggested to properly evaluate the situation before proceeding with the takeover. For all planned takeovers, manual intervention is suggested if the program detects an unanticipated error or warning. The way to enforce manual intervention for a takeover is to perform one of the following actions: Perform a manual takeover through Database Operations Center. Perform a programmatic takeover, but ensure that the program requires operator intervention. Process of Calling the Takeover Entry Point To complete the takeover, you might need to call the takeover entry point more than once. You might receive warning indicators from the RDB support library such as The hosts are not communicating. The primary database is open and will be discontinued. The new secondary database might have to be cloned. The new primary database might require a structure clone operation. If you receive these warnings and you still want to proceed with the takeover, you must call the entry point again

279 Programmatic Interfaces The warning indicators can also be used to selectively override certain warnings before calling the entry point the first time. Declaration That Calls the Takeover Entry Point The name of the takeover entry point is RDB_TAKEOVER. An ALGOL program declares this entry point: BOOLEAN PROCEDURE RDB_TAKEOVER (PRIMARY_HOSTNAME, PARAMS); VALUE PRIMARY_HOSTNAME; STRING PRIMARY_HOSTNAME; ARRAY PARAMS[*]; LIBRARY RDBSUPPORT; Result Values of the Takeover Entry Point Procedure The following table shows the result values of the ALGOL takeover procedure, the meaning of the values, and the action recommended when you receive each value. Value Meaning Action 0 (zero) No errors occurred Check for warnings in the PARAMS array. Nonzero One or more errors occurred Handle the error as you would any Enterprise Database Server error. Specifying Values for PRIMARY_HOSTNAME and PARAMS To use the takeover entry point, you must specify values for the following parameters: PRIMARY_HOSTNAME PRIMARY_HOSTNAME is a string parameter that specifies the name of the host that will be the primary host after the takeover is complete. PARAMS PARAMS is an array parameter that Remote Database Backup uses to communicate various operational details and options. Remote Database Backup uses PARAMS in two ways: - Remote Database Backup sets values in this parameter to warn you of certain operational conditions when it attempts to perform the takeover. You should always consider these warnings before you continue. - You use this parameter to inform Remote Database Backup that it is to proceed with the takeover. The minimum length of the actual array passed in the PARAMS parameter varies according to the value specified in the VERSION_WORD field. To determine the minimum length requirements, refer to the explanation of VERSION_WORD later in this section

280 Programmatic Interfaces Organization of the PARAMS Array The PARAMS array is organized as follows: VERSION_WORD = PARAMS [0] Versions 1, 2, and 4 of the PARAMS array organization are supported. Caution Version 3 is reserved for Unisys internal use only. The organization for version 2 is the same as the organization for version 1 except for the addition of the WARNINGS bit OLTP_DB = [09:01]. Similarly, the organization for version 4 is the same as for version 2, except for the addition of the WARNINGS bit STCLONE = [10:01]. The organization of version 4 is as follows: WARNINGS = PARAMS [1] WARN_HOST = [47:12 STCLONE = [10:01] (Version 4 only) OLTP_DB = [09:01] RECLONE = [08:01] DS = [07:01] ALREADY_PRIMARY = [04:01] BNA_DOWN = [02:01] OVERRIDE_REQD = [01:01] OVERRIDE_OK = [00:01] OPTIONS = PARAMS [2] IMMEDIACY = [03:04] T_O_DEFAULT (0) = 0 T_O_END_OF_AUDIT = 3 WARN_HOSTNAME (A) = PARAMS [3] to PARAMS [5] WARN_HOSTNAME_LEN = PARAMS [3].[47:08] P_WARN_HOSTNAME_TEXT = POINTER (PARAMS [3])+1 Description of PARAMS Array Information The values returned in each field of the PARAMS array are explained in the following table

281 Programmatic Interfaces Field VERSION_WORD WARNINGS RECLONE STCLONE DS ALREADY_PRIMARY BNA_DOWN OVERRIDE_REQD Explanation A value identifying the contents of the remainder of the PARAMS array. The values currently supported are 1, 2, or 4. Because multiple variants might be supported at any given time, it is important that the value specified corresponds with the actual parameter contents. PARAMS arrays using version 1, 2, or 4 must have a minimum length of 6 words. Consists of the values of the following fields. A value of either 0 (zero) or 1 (one): 0 means that this warning does not apply. 1 means that, if you proceed with the takeover, you might need to clone the database. A value of either 0 (zero) or 1 (one): 0 means that this warning does not apply. 1 means that, if you proceed with the takeover, you must perform the necessary structure clone operation on the new primary host before opening the database on this host. A value of either 0 (zero) or 1 (one): 0 means that this warning does not apply. 1 means that, if you proceed with the takeover, the database on the host identified in the WARN_HOST field will be terminated. A value of either 0 (zero) or 1 (one): 0 means that this warning does not apply. 1 means that the host specified by the PRIMARY_HOSTNAME parameter is the primary host. A value of either 0 (zero) or 1 (one): 0 means that this warning does not apply. 1 means the primary and secondary hosts are not communicating and only the current host is changed if you complete the takeover by making the procedure call again. A value of either 0 (zero) or 1 (one): 0 means that this warning does not apply. 1 means that, to continue the takeover, you must call the RDB_TAKEOVER entry point again, and pass the value returned in the WARNINGS field on the previous call. The value returned by the WARNINGS field identifies one or more warnings. On the next call of the procedure, the WARNINGS field overrides the reported warnings and continues with the takeover

282 Programmatic Interfaces Field WARN_HOST OVERRIDE_OK OPTIONS IMMEDIACY WARN_HOSTNAME (A) Explanation A numeric host identifier associated with any of the following warning flags, as follows: BNA_DOWN When the BNA_DOWN flag is set, this field contains the remote host identifier. RECLONE DS When the RECLONE flag is set, this field contains the current primary host identifier. When the DS flag is set and the BNA_DOWN flag is not also set, this field contains the current primary host identifier. When the DS flag is set and the BNA_DOWN flag is also set, this field contains the remote host identifier. In this case, the host that is discontinued is the current (local) host. ALREADY_PRIMARY This flag does not apply. OVERRIDE_REQD When the OVERRIDE_REQD flag is set and the BNA_DOWN flag is not also set, this field contains the current primary host identifier. When the OVERRIDE_REQD flag is set and the BNA_DOWN flag is also set, this field contains the remote host identifier. If an override is required, the WARN_HOST value must be returned. If an override is required, the WARN_HOST value must be returned. The WARN_HOST value normally does not need to be examined. The host name for the host identified in this field appears in the WARN_HOSTNAME field. When an override is required, this bit is set to communicate to Remote Database Backup that the takeover warnings are being overridden. When OVERRIDE_REQD is set, OVERRIDE_OK is also set. Specifies when the takeover is to take place through the value in the IMMEDIACY subfield. One of the following values that identifies when the takeover is to take place: T_O_DEFAULT (0) Instructs Remote Database Backup to perform the takeover according to default Remote Database Backup specifications. The default behavior is T_O_END_OF_AUDIT. T_O_END_OF_AUDIT (3) Instructs Remote Database Backup to perform the takeover when Tracker has gone to the end of the audit trail on the secondary system. The name of the host identified by the WARN_HOST field value and contained in the following two subfields

283 Programmatic Interfaces Field WARN_HOSTNAME_LEN P_WARN_HOSTNAME_TEXT OLTP_DB Explanation The length of the name of the host identified in the WARN_HOST field. The text string of the name of the host identified in the WARN_HOST field. Ignore characters in this field that are not part of the text string; that is, only the first n number of characters (as defined by WARN_HOST_LEN) are valid. A value of either 0 (zero) or 1 (one): 0 means that this warning does not apply. 1 means that the database has the Open/OLTP option set, which might result in partial or missing global transactions. Procedure for Running a Takeover Program To run a takeover program, perform the following procedure. Step Action 1 Call the procedure. 2 Examine the result returned by the procedure: RESULT:= RDB_TAKEOVER (HOST_NAME, PARAMS) 3 Perform one of the following actions: If no errors are returned, go to step 4. If an error has been returned in the RESULT value, correct the error and return to step 1. 4 Examine the WARNINGS parameter and perform one of the following actions: If no override is required, the takeover completed successfully. If an override is required, examine the warning flags. If you still want to proceed with the takeover, leave the WARNINGS parameter as is, and return to step 1. Possible warnings are RECLONE DS BNA_DOWN OVERRIDE_REQD STCLONE Note: An override might be required even though none of the other warning flags are set. Such an override serves as a confirmation to do the takeover

284 Programmatic Interfaces Overriding Warnings Selectively You can selectively override any of the warnings before calling the entry point the first time. You do this by setting OVERRIDE_OK and the flags of the warnings you want to mask out to 1 (one). For example, you can avoid the confirmation request but still receive any other warnings by setting OVERRIDE_OK to 1 and all the warning flags to 0 (zero) before calling the entry point. Example Takeover Entry Point ALGOL Program Following is an example ALGOL program illustrating use of the takeover entry point: BEGIN FILE RMT (KIND=REMOTE); LIBRARY RDBSUPPORT (LIBACCESS = BYFUNCTION,FUNCTIONNAME = "RDBSUPPORT." ); BOOLEAN PROCEDURE RDB_TAKEOVER (PRIMARY_HOSTNAME, PARAMS); VALUE PRIMARY_HOSTNAME; STRING PRIMARY_HOSTNAME; ARRAY PARAMS [*]; LIBRARY RDBSUPPORT; % END OF RDBSUPPORT LIBRARY DECLARATIONS % DEFINE RDB_TO_VERSION (A) = A [RDB_TO_VERSIONW] #, RDB_TO_VERSIONW = 0 #, RDB_TO_WARNINGS (A) = A [RDB_TO_WARNINGSW] #, RDB_TO_WARNINGSW = 1 #, WARN_HOST = [47:12] #, STCLONE = [10:01] #, OLTP_DB = [09:01] #, RECLONE = [08:01] #, DS = [07:01] #, ALREADY_PRIMARY = [04:01] #, BNA_DOWN = [02:01] #, OVERRIDE_REQD = [01:01] #, OVERRIDE_OK = [00:01] #, RDB_TO_OPTIONS (A) = A [RDB_TO_OPTIONSW] #, RDB_TO_OPTIONSW = 2 #, T_O_IMMEDIACY (A) = RDB_TO_OPTIONS(A).T_O_IMMEDIACYF #, T_O_IMMEDIACYF = [03:04] #, T_O_DEFAULT = 0 #, T_O_END_OF_AUDIT = 3 #, RDB_WARN_HOSTNAME (A) = A[RDB_WARN_HOSTNAMEW] #, RDB_WARN_HOSTNAMEW = 3 #, RDB_WARN_HOSTNAME_LENF = [47:08] #, RDB_WARN_HOSTNAME_LEN (A) = RDB_WARN_HOSTNAME (A). RDB_WARN_HOSTNAME_LENF #, RDB_WARN_HOSTNAME_P (A) = POINTER (RDB_WARN_HOSTNAME(A))+1 #, END_OF_RDB_DEFINES = #; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

285 Programmatic Interfaces % MISCELLANEOUS VARIABLES AND DEFINES % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% DEFINE CATEGORY = [35:8]#, SUBCAT = [19:16]#, END_OF_DEFINES = #; ARRAY AX [0:10], PARAMS [0:5]; STRING HN, WARN_HN; LABEL EOT; BOOLEAN DONE, RSLT, OVERRIDE_RSLT; % % DEFINE CHECK_RDB_RESULT (RSLT) = BEGIN IF RSLT THEN BEGIN DISPLAY ("RDB "!! STRING(LINENUMBER, *)!! " failed, "!! "CATEGORY = "!! STRING(REAL(RSLT).CATEGORY, *)!! ", SUBCATEGORY = "!! STRING(REAL(RSLT).SUBCAT, *) ); MYSELF.TASKVALUE:= 1; GO EOT; END; END #; % CHECK_RDB_RESULT PROCEDURE INITIALIZE; BEGIN RDBSUPPORT.LIBPARAMETER:= "(TEST)RDBDB ON TESTPACK."; END; % INITIALIZE PROCEDURE REPORT_TAKEOVER_BITS (HOSTNAME, RSLT); VALUE HOSTNAME, RSLT; STRING HOSTNAME; BOOLEAN RSLT; BEGIN ARRAY MSG [0:10]; POINTER PMSG; REPLACE PMSG:MSG BY "For host ", HOSTNAME, ":"; WRITE (RMT, OFFSET(PMSG), POINTER(MSG)); IF RSLT.RECLONE THEN WRITE (RMT, <" RECLONE is set">); IF RSLT.STCLONE THEN WRITE (RMT, <" STCLONE is set">); IF RSLT.DS THEN WRITE (RMT, <" DS is set">); IF RSLT.ALREADY_PRIMARY THEN WRITE (RMT, <" This host is already the primary">); IF RSLT.BNA_DOWN THEN WRITE (RMT, <" BNA IS DOWN (Unable to communicate)">); IF RSLT.OVERRIDE_REQD THEN

286 Programmatic Interfaces WRITE (RMT, <"*** OVERRIDE IS REQUIRED ***">); IF RSLT.OLTP_DB THEN WRITE (RMT, <" OLTP_DB is set">); END; % REPORT_TAKEOVER_BITS %%%%%%%%%%%%%%%%%%%%%%% OUTER BLOCK %%%%%%%%%%%%%%%%%%%%%%%%%%% INITIALIZE; HN:= "BACKUP"; RDB_TO_VERSION (PARAMS):= 4; RDB_TO_WARNINGS (PARAMS):= 0; RDB_TO_OPTIONS (PARAMS):= 0; T_O_IMMEDIACY (PARAMS):= T_O_DEFAULT; DO BEGIN RSLT:= RDB_TAKEOVER (HN, PARAMS); CHECK_RDB_RESULT (RSLT); OVERRIDE_RSLT:= BOOLEAN(RDB_TO_WARNINGS (PARAMS)); IF REAL(OVERRIDE_RSLT) IS 0 THEN BEGIN WRITE (RMT, <"No warnings or errors returned">); DONE:= TRUE; END ELSE BEGIN WARN_HN:= STRING (RDB_WARN_HOSTNAME_P (PARAMS),RDB_WARN_HOSTNAME_LEN (PARAMS) ); REPORT_TAKEOVER_BITS (WARN_HN, OVERRIDE_RSLT); IF OVERRIDE_RSLT.OVERRIDE_REQD THEN BEGIN % % If the OVERRIDE_REQD bit is set, another is required. % The value returned in WARNINGS should be passed back in to % RDB as part of the second call. % % Note that it is the responsibility of the site to determine % if the Takeover operation should continue. To continue with % the Takeover, this example program requires that an AX OK % reply be given. % REPLACE POINTER(AX) BY "AX OK TO COMPLETE TAKEOVER"; ACCEPT(POINTER(AX)); IF POINTER(AX) = "OK" FOR 2 THEN BEGIN % % The bits in RDB_TO_WARNINGS should already be set % correctly, so all that is needed is to call RDB_TAKEOVER % again. This is done at the top of the loop. If the % next call should fail, the results will be reported and % another ACCEPT will be needed to continue. END ELSE BEGIN WRITE (RMT, <"Takeover cancelled">); DONE:= TRUE; END; END

287 Programmatic Interfaces ELSE DONE:= TRUE; END; END UNTIL DONE; EOT: END. Using the RDB_INFO Entry Point What the RDB_INFO Entry Point Does The RDB_INFO entry point enables the extraction of RDB statistics. The information provided by the interface includes all that is currently provided by the Database Operations Center Remote Database Backup Status and Statistics screens. Declaration for the RDB_INFO Entry Point An ALGOL program declares this entry point: BOOLEAN PROCEDURE RDB_INFO (RDBINFO, DOC_MSG); ARRAY RDBINFO[0]; EBCDIC ARRAY DOC_MSG[0]; LIBRARY RDBSUPPORT; Returned Information of the RDB_INFO Entry Point Procedure The following table describes the information returned in the RDB_INFO array. Word Contents Description 0 Remote error flag When this word is 0, no error was encountered accessing remote host information. When this word is 1, an error was encountered accessing remote host information and a message is stored in the DOC_MSG array parameter. 1 Audit blocks transferring For ABW mode: When this word is 0, audit blocks are not being transmitted. When this word is 1, audit blocks are being transmitted

288 Programmatic Interfaces Word Contents Description 2-4 Primary host identification [2].[47:8] is the number of 8-bit EBCDIC characters representing the primary host name. POINTER (RDBINFO[2] +1 is the primary host name represented in 8-bit EBCDIC characters 5 Primary host audit transmission mode 6 Primary host audit transmission mode option 7 Primary host audit file number This word contains one of the following five values: 0 = NSC mode 1 = ABW mode 2 = AFS mode 3 = SCA mode 4 = AFM mode For ABW mode this word contains one of the following two values: 1 = Drop 2 = Operator intervention For AFS mode with BNA this word contains one of the following two values 1 = NFT transfer 2 = FTRapid transfer This word contains the current audit file number at the primary host. 8 Primary host ABSN number This word contains the current audit block serial number at the primary host. 9 Primary host ABSN timestamp This word contains the TIME (11) timestamp value of the current audit block serial number at the primary host Secondary host identification [10].[47:8] is the number of 8-bit EBCDIC characters representing the secondary host name. Word Contents Description POINTER (RDBINFO[10] +1 is the secondary host name represented in 8-bit EBCDIC characters

289 Programmatic Interfaces Word Contents Description 13 Secondary host audit transmission mode 14 Secondary host audit transmission mode option 15 Secondary host audit file number 16 Secondary host ABSN number 17 Secondary host ABSN timestamp This word contains one of the following five values: 0 = NSC mode 1 = ABW mode 2 = AFS mode 3 = SCA mode 4 = AFM mode For ABW mode this word contains one of the following two values: 1 = Drop 2 = Operator intervention For AFS mode with BNA this word contains one of the following two values 1 = NFT transfer 2 = FTRapid transfer This word contains the most recent audit file number received and written at the secondary host. This word contains the most recent audit block serial number received and written at the secondary host. This word contains the TIME (11) timestamp value of the most recent audit block serial number received and written at the secondary host. 18 Tracker audit file number This word contains the audit file number of the last applied audit block to the secondary database. 19 Tracker ABSN number This word contains the audit block serial number of the last applied audit block to the secondary database. 20 Tracker ABSN timestamp This word contains the TIME (11) timestamp value of the last applied audit block to the secondary database. 21 Tracker control record ABSN number 22 Tracker control record timestamp This word contains the audit block serial number containing the last applied control record to the secondary database. This word contains the TIME (106) timestamp value of the last applied control record to the secondary database. 23 Average audit block size This word contains the average number of words per logical audit block

290 Programmatic Interfaces Word Contents Description 24 Audit words generated This word contains the total number of audit words generated. 25 Average ACR wait time This word contains a value represented in multiples of microseconds that is computed by dividing the Total ACR wait time divided by the total number of sends. 26 Total ACR wait time This word contains a value that represents in multiples of microseconds the total wait time the Accessroutines waits for acknowledgments. 27 Total words sent In ABW mode, this word contains the total number of audit block words sent, plus any control words. 28 Average send time In ABW mode, this word contains a value represented in multiples of microseconds that is computed by dividing the total send time divided by the total number of sends.. 29 Total send time In ABW mode, this word contains a value that represents in multiples of microseconds the total time from the beginning of a send call until its acknowledgment is received. 30 Reserved for future Reserved for future. 31 Catchup state When this word is 0 there is no Catchup in progress of the secondary database When this word is 1 there is a Catchup in progress of the secondary database 32 Secondary dump in progress When this word is 0, there is no dump in progress of the secondary database. When this word is 1, there is a dump in progress of the secondary database, and Tracker is suspended. 32 Secondary dump in progress When this word is 0, there is no dump in progress of the secondary database. When this word is 1, there is a dump in progress of the secondary database and Tracker is suspended. 33 Clone state When this word is 0, a full clone operation is not required. When this word is 1 a full clone operation is required. When this word is 2 the clone state is unknown

291 Programmatic Interfaces Word Contents Description 34 Structure clone state When this word is 0, a structure clone operation is not required. When this word is 1, a structure clone operation is required. When this word is 2, the structure clone state is unknown. 35 Enable state When this word is 0, the remote database capability is disabled. When this word is 1, the remote database capability is enabled. 36 Total number of sends In ABW mode, this word contains the total number of audit blocks sent. 37 Primary host acknowledgement rate 38 Secondary host acknowledgement rate 39 Primary host port I/O timeout value 40 Secondary host port I/O timeout value Acknowledgement rate for the ABW mode. Acknowledgement rate for the ABW mode (for use after a takeover when this database becomes a primary database). Port I/O timeout value for the ABW mode. Port I/O timeout value for the ABW mode (for use after a takeover when this database becomes a primary database). Example Remote Database Backup INFO Application Program Text LIBRARY RDBSUPPORT (LIBACCESS = BYFUNCTION,FUNCTIONNAME = "RDBSUPPORT." ; BOOLEAN PROCEDURE RDB_INFO (RDBINFO, DOC_MSG); ARRAY RDBINFO[0]; EBCDIC ARRAY DOC_MSG[0]; LIBRARY RDBSUPPORT; $INCLUDE PROPERTIES="DATABASE/PROPERTIES" BOOLEAN RSLT; EBCDIC ARRAY DOC_MSG[0:500]; ARRAY RDBINFO[0:RDBINFOSZ-1]; RDBSUPPORT.LIBPARAMETER:= "(PROD)PRODDB ON PRODPK."; RSLT := RDB_INFO(RDBINFO, DOC_MSG);

292 Programmatic Interfaces Using the GET_PRIMARY_MODE Entry Point What the GET_PRIMARY_MODE Entry Point Does You can use the GET_PRIMARY_MODE entry point to determine the current audit transmission mode for transferring audit data from the current primary host to the current secondary host. This procedure can be called from either the primary or the secondary host. Declaration for the GET_PRIMARY_MODE Entry Point An ALGOL program declares this entry point: REAL PROCEDURE GET_PRIMARY_MODE ( ); LIBRARY RDBSUPPORT; Result Values of the GET_PRIMARY_MODE Entry Point Procedure The following table shows the audit transmission mode result values that are returned by the GET_PRIMARY_MODE entry point procedure. Value Meaning 0 (zero) NSC_MODE (not server capable) 1 ABW_MODE (audit block transmission) 2 AFS_MODE (audit file switch) 3 SCA_MODE (server capable) 4 AFM_MODE (audit file mirror) The audit transmission mode values are defined in the DATABASE/PROPERTIES file in the range described as follows: $ INCLUDE PROPERTIES = "*DATABASE/PROPERTIES" DEFINE NSC_MODE = 0 #, ABW_MODE = 1 #, AFS_MODE = 2 #, SCA_MODE = 3 #, AFM_MODE = 4 #; No error values are returned from the procedure. However, if an RDB control file does not exist, the value 0 is returned

293 Programmatic Interfaces Example GET_PRIMARY_MODE Application Program Text $ INCLUDE PROPERTIES = "*DATABASE/PROPERTIES" LIBRARY RDBSUPPORT (LIBACCESS = BYFUNCTION, FUNCTIONNAME = "RDBSUPPORT."); REAL PROCEDURE GET_PRIMARY_MODE ( ); LIBRARY RDBSUPPORT; REAL M; RDBSUPPORT.LIBPARAMETER := "(TEST)RDBDB ON TESTPACK. "; M := GET_PRIMARY_MODE (); Related Information Topics For information about... Refer to... RDB control file Section 5 Accessing the current state of audit transfers Section 7 Accessing cumulative Remote Database Statistics Section 7 Interpreting Remote Database Statistics Section 7 Using the SET_RDB_MODE Entry Point What the SET_RDB_MODE Entry Point Does The SET_RDB_MODE entry point enables you to change the current audit transmission mode of your Remote Database Backup-enabled database to another mode. Declaration for the SET_RDB_MODE Entry Point BOOLEAN PROCEDURE SET_RDB_MODE (WHICH_HOST, AUDITMODE, MODEOPT); VALUE WHICH_HOST, AUDITMODE, MODEOPT; REAL WHICH_HOST, AUDITMODE, MODEOPT; LIBRARY RDBSUPPORT; Result Values of the SET_RDB_MODE Entry Point Procedure This procedure can be called only from the primary host. All mode changes go into effect at the next audit file switch unless there is a change to AFM_MODE; this change takes place immediately. Note: An audit file switch occurs either when the current audit file being generated by the database is full and is closed by the database, or when the current audit file is closed manually by entering the SM AUDIT CLOSE Visible DBS command to the database

294 Programmatic Interfaces If an error occurs, the Boolean result returned is true. If the result is true, then the result is an error result word with the lower bit on to flag the error. You can use the GET_RDB_MESSAGE entry point procedure to retrieve the message text associated with the error value. Some general error categories returned by this procedure include the following: RDB control file not resident Log-in failures Not requested at the primary host Distribution errors Not networking Specifying Values for WHICH_HOST, AUDITMODE, and MODEOPT You must supply the values of the WHICH_HOST, AUDITMODE, and MODEOPT parameters when the audit transmission mode is changed. The WHICH_HOST parameter specifies whether the audit transmission mode change affects the transfer of audit data from the primary host to the secondary host or changes the audit transmission mode for the secondary host, which takes effect when it becomes the primary host. The following table shows the valid values for the WHICH_HOST parameter. If one of these values is not provided, an error is returned. Value RDB_SECONDARYV (1) RDB_PRIMARYV (2) Meaning The mode change is specified for audit transmission from the secondary host to the primary host. The mode change is specified for audit transmission from the secondary host to the primary host. The audit transmission mode values for the WHICH_HOST parameter are defined in the DATABASE/PROPERTIES file in the range described as follows: $INCLUDE PROPERTIES ="*DATABASE/PROPERTIES" DEFINE % RDB_STATUS RDB_SECONDARYV = 1 #, RDB PRIMARYV = 2 #; The AUDITMODE parameter specifies the audit transmission mode that will take effect on the specified host. The MODEOPT parameter specifies the error-handling option parameter selected when the chosen mode is ABW_MODE or the file transmission option selected when the chosen mode is AFS_MODE

295 Programmatic Interfaces The audit transmission mode values for the AUDITMODE and MODEOPT parameters are defined in DATABASE/PROPERTIES in the range described as follows: $ INCLUDE PROPERTIES="*DATABASE/PROPERTIES" DEFINE NSC_MODE = 0 #, ABW_MODE = 1 #, AFS_MODE = 2 #, SCA_MODE = 3 #, AFM_MODE = 4 #, ABW_DROP_V = 1 #, ABW_OPERATOR_V =2 #, AFS_NFT_V = 1 #, AFS_RAPID_V = 2 #; The following table shows the valid values for the AUDITMODE parameter. Value Meaning 0 (zero) NSC_MODE (not server capable) 1 ABW_MODE (audit block transmission) 2 AFS_MODE (audit file switch) 3 SCA_MODE (server capable) 4 AFM_MODE (audit file mirror) The following table shows the valid values for the MODEOPT parameter when AUDITMODE has the value ABW_MODE. Value Meaning 1 ABW_DROP_V (default) 2 ABW_OPERATOR_V The following table shows the valid values for the MODEOPT parameter when AUDITMODE has the value AFS_MODE and the network service is BNA. Value Meaning 1 AFS_NFT_V (default) 2 AFS_RAPID_V In both cases, if the value is not one of the described values, the MODEOPT parameter is set to the default value for the selected mode

296 Programmatic Interfaces Example SET_RDB_MODE Application Program Text This example assumes that the network service is BNA. PROCEDURE P(DBTITLE); ARRAY DBTITLE[*]; BEGIN LIBRARY RDBSUPPORT(LIBACCESS=BYFUNCTION,FUNCTIONNAME ="RDBSUPPORT."); $INCLUDE PROPERTIES = "*DATABASE/PROPERTIES" $INCLUDE PROPERTIES = "*DATABASE/PROPERTIES" REAL PROCEDURE GET_PRIMARY_MODE(); LIBRARY RDBSUPPORT; BOOLEAN PROCEDURE GET_RDB_MESSAGE (RSLT, MSG); VALUE RSLT; REAL RSLT; EBCDIC ARRAY MSG [0]; LIBRARY RDBSUPPORT; BOOLEAN PROCEDURE SET_RDB_MODE (WHICH_HOST, AUDITMODE, MODEOPT); VALUE WHICH_HOST, AUDITMODE, MODEOPT; REAL WHICH_HOST, AUDITMODE, MODEOPT; LIBRARY RDBSUPPORT; TRUTHSET TERMS("."48"00"); EBCDIC ARRAY MYMSG[0:1023]; EBCDIC ARRAY DBPARAM[0:1023]; REAL M; BOOLEAN MYRSLT; REAL RSLT = MYRSLT; % set the RDBSUPPORT library to link based on the % database title passed in as a parameter REPLACE DBPARAM[0] BY POINTER (DBTITLE[0]) UNTIL IN TERMS, "."; REPLACE RDBSUPPORT.LIBPARAMETER BY DBPARAM[0]; % toggle the mode between ABW and AFS mode IF (M := GET_PRIMARY_MODE()) = AFS_MODE THEN MYRSLT := SET_RDB_MODE(RDB_PRIMARYV, ABW_MODE, ABW_DROP_V) ELSE MYRSLT := SET_RDB_MODE(RDB_PRIMARYV, AFS_MODE, AFS_NFT_V); IF MYRSLT THEN BEGIN DISPLAY ("ERROR calling SET_RDB_MODE"); IF REAL (GET_RDB_MESSAGE (RSLT, MYMSG)) GEQ 0 THEN DISPLAY (MYMSG) ELSE DISPLAY ("Error retrieving SET_RDB_MODE result"); END ELSE BEGIN IF M = AFS_MODE THEN DISPLAY ("RDB PRIMARY AUDIT MODE SET TO ABW_MODE") ELSE DISPLAY ("RDB PRIMARY AUDIT MODE SET TO AFS_MODE");

297 Programmatic Interfaces DISPLAY ("MODE SWITCH WILL OCCUR AT THE NEXT AUDIT FILE SWITCH"); END; END. Related Information Topics For information about... Refer to... Audit file switch Enterprise Database Server Utilities Operations Guide Audit transmission modes Sections 2 and 5 Causing an audit file switch Enterprise Database Server Utilities Operations Guide Setting up audit transmission modes Sections 2, 3, and 5 Using AFS mode with a nonusercoded database Section 5 Using the GET_RDB_MESSAGE Entry Point What the GET_RDB_MESSAGE Entry Point Does The GET_RDB_MESSAGE entry point is used to return the message text associated with a valid error result. If the result parameter (RSLT) is a valid Remote Database Backup error result, the message parameter (MSG) contains the text of the message associated with the error, terminated with a null character (48 00 ). Valid error results are returned only from failed calls to valid entry points in the RDB support library. Unexpected results can occur if the result parameter is not a valid entry point value. If the GET_RDB_MESSAGE entry point returns an error, the result returned is a Boolean representation of the result of a MESSAGESEARCHER statement, as defined in the ALGOL Programming Reference Manual, Vol. 1. Declaration for the GET_RDB_MESSAGE Entry Point An ALGOL program declares the entry point: BOOLEAN PROCEDURE GET_RDB_MESSAGE ( RSLT, MSG ); VALUE RSLT; REAL RSLT; EBCDIC ARRAY (MSG)[0]; LIBRARY RDBSUPPORT;

298 Programmatic Interfaces The RSLT parameter should be the value returned from any entry point in the RDB support library. The MSG parameter contains the text of a message if the RSLT parameter is a properly formatted Remote Database Backup error. Example GET_RDB_MESSAGE Application Program Text BEGIN LIBRARY RDBSUPPORT (LIBACCESS = BYFUNCTION, FUNCTIONNAME = "RDBSUPPORT."); BOOLEAN PROCEDURE GET_RDB_MESSAGE ( RSLT, MSG ); VALUE RSLT; REAL RSLT; EBCDIC ARRAY MSG[0]; LIBRARY RDBSUPPORT; BOOLEAN T; BOOLEAN MYRSLT; REAL RSLT = MYRSLT; EBCDIC ARRAY MYMSG [0:1023]; RDBSUPPORT.LIBPARAMETER := "(TEST)RDBDB ON TESTPACK."; IF NOT T := GET_RDB_MESSAGE (RSLT, MYMSG) THEN DISPLAY (MYMSG) ELSE CASE REAL(T) OF BEGIN 1: DISPLAY ( MYMSG ); % message returned in SYSTEMLANGUAGE format ELSE: DISPLAY("Bad RDB error result"); END; END

299 Section 14 SYSTEM/RDBOPS This section describes the RDBOPS command line utility that supports the following tasks: INITIALIZE creates a Remote Database Backup control file and updates this file with complete primary and secondary host configuration options; this process reads the CONFIG file. MODIFY updates the RDB control file at both hosts with the configuration options read from the CONFIG file. ENABLE performs a Remote Database Backup ENABLE operation. ACKNOWLEDGE accepts an AUDIT FILE NUMBER as input and performs a Remote Database Backup ACKNOWLEDGE operation. DISABLE performs a Remote Database Backup DISABLE operation. TAKEOVER performs a Remote Database Backup takeover. STATUS retrieves, displays, and prints status and statistical information. Running RDBOPS There are two methods of running the RDBOPS command. The first method requires that the CONFIG file be file-equated to an RDBOPS configuration file. The run statement is as follows: RUN SYSTEM/RDBOPS ("<db statement> <ops command>"); FILE CONFIG = <configuration file>; The second method to run the RDBOPS command does not require file equation. The run statement for this method is as follows: RUN SYSTEM/RDBOPS ("<db statement> <ops command>") Where <db statement> identifies the database name and location of the control file. <ops command> INITIALIZE MODIFY ENABLE DISABLE ACKNOWLEDGE <audit file number> OVERRIDE TAKEOVER OVERRIDE

300 SYSTEM/RDBOPS STATUS The following table describes the elements of the <ops command> syntax diagram: Option INITIALIZE MODIFY ENABLE DISABLE Description This task creates the RDB control file that controls how the Remote Database Backup system operates. The RDB control file contains information that controls both database and Remote Database Backup system behavior at the primary and secondary hosts. The RDBOPS command uses information from the database control file and the CONFIG file to create the RDB control file. You can only run this command at the primary host. This task updates the RDB control file at each host using information from the CONFIG file. You can only run this command at the primary host. This task enables the Remote Database Backup system. You can only run this command at the primary host. This task disables the Remote Database Backup system. You can only run this command at the primary host. ACKNOWLEDGE This task acknowledges receipt of audit files at the secondary host. The OVERRIDE option enables the task to continue without confirmation following warning messages. TAKEOVER STATUS This task performs a Remote Database Backup takeover. If the hosts are communicating, a role change can occur at both hosts. If the hosts are not communicating, only the role of the local host can be changed. The OVERRIDE option enables the task to continue without confirmation following warning messages. This task displays prints status and statistical information about the Remote Database Backup system. Information is dynamically accessed from both hosts. Related Information Topics For information about... Refer to... INITIALIZE task ENABLE task Section 5 TAKEOVER task Section 6 MODIFY task DISABLE task ACKNOWLEDGE task Section

301 SYSTEM/RDBOPS For information about... Refer to... STATUS task Section 7 <db statement> Utilities Operations Guide RDBOPS Configuration File The RDBOPS Configuration File is a file you equate to CONFIG when running SYSTEM/RDBOPS. This file contains RDB attribute information necessary to maintain an RDB database. This file must contain information for every attribute listed in the following figure of a sample. The following template is an image of the TEMPLATE/RDBOPS/CONFIG file that is used to create a CONFIG file for input to the INITIALIZE and MODIFY commands. WARNING When using the TCP/IP network service instead of BNA, passwords will be visible in clear text in the RDBOPS CONFIG file. Therefore, this file must be secured or the passwords should be removed from the file when it is not in use. If neither is possible nor practical, then use the Database Operations Center instead of the RDBOPS INITIALIZE and MODIFY commands. % This Configuration File is specifically for input to the % SYSTEM/RDBOPS program. % % Copy this template file as a local file that you can tailor with % database-specific information. % % EXAMPLE: % COPY TEMPLATE/RDBOPS/CONFIG AS RDB/CONFIG/INIT % % User-required specifications are marked below using <...> notation. % User-required specifications must be completed for all primary % and secondary host attributes of the config file. % % Product defaults are provided for many specifications. Defaults % can always be replaced by user specifications. % % An example CONFIG file with completed input is provided at the end % of this file. % % Complete documentation and example usage of this CONFIG file is % provide in the Remote Database Backup Planning and Operations Guide. % % Examples: % RUN SYSTEM/RDBOPS("DB=(PROD)PRODDB ON DBPACK INITIALIZE");

302 SYSTEM/RDBOPS % FILE CONFIG = (PROD)RDB/CONFIG/INIT ON DBPACK % RUN SYSTEM/RDBOPS("DB=(PROD)PRODDB ON DBPACK MODIFY"); % FILE CONFIG = (PROD)RDB/CONFIG/MOD ON DBPACK % % Beginning of CONFIG options. % Replace all <...> tokens with actual configuration options: DB_NAME <database name> CF USERCODE <usercode> OR * NETWORK_SERVICE 0 % <network service option> values: % BNA = 0, the default value % TCP/IP = 1 KEY_CONTAINER <key container name> % <network service option> % delete if using BNA % optional for TCP/IP PRI_HOSTNAME <host name> PRI_CF_FAMNAME <family name> PRI_AUDIT_FAMNAME <family name> PRI_DUPAUDIT_FAMNAME <family name> PRI_AUDIT_ALTFAMNAME <family name> PRI_DUPAUDIT_ALTFAMNAME <family name> PRI_RDBSERVER_FILE <file title> PRI_ACKRATE 10 % <integer> PRI_SYNC_RESTART_INTERVAL 100 % <integer> PRI DELAY_AUDIT_REMOVAL <boolean> PRI AUDITTRANSFER MODE 1 % <mode option> % <mode option> values: % NSC = 0 % ABW = 1 % AFS = 2 % SCA = 3 % AFM = 4 PRI_ERROR_HANDLING 1 % <error handling option> % <error handling option> values for ABW mode: % DROP = 1 % OPERATOR = 2 PRI_AFS_TRANSFER 1 % <file transfer option for BNA> % <file transfer option> values for AFS mode: % NFT = 1 % FTRAPID = 2 PRI_AFM_COPYAUDIT <boolean> PRI_FTRAPID_TITLE OBJECT/RAPID ON DISK % <file title> PRI_PORTIO_TIMEOUT 60 % <integer> PRI_TCPIP_UC <usercode> % delete if using BNA PRI_TCPIP_PWD <password> % delete if using BNA SEC_HOSTNAME <host name> SEC_CF_FAMNAME <family name> SEC_AUDIT_FAMNAME <family name> SEC_DUPAUDIT_FAMNAME <family name> SEC_AUDIT_ALTFAMNAME <family name> SEC_DUPAUDIT_ALTFAMNAME <family name> SEC_RDBSERVER_FILE <file title> SEC_ACKRATE 10 % <integer> SEC_SYNC_RESTART_INTERVAL 100 % <integer> SEC_AUDITTRANSFER_MODE 1 % <mode option> % <mode option> values:

303 SYSTEM/RDBOPS % NSC = 0 % ABW = 1 % AFS = 2 % SCA = 3 % AFM = 4 SEC_ERROR_HANDLING 1 % <error handling option> % <error handling option> values for ABW mode: % DROP = 1 % OPERATOR = 2 SEC_AFS_TRANSFER 1 % <file transfer option for BNA> % <file transfer option> values for AFS mode: % NFT = 1 % FTRAPID = 2 SEC_AFM_COPYAUDIT <boolean> SEC_FTRAPID_TITLE OBJECT/RAPID ON DISK % <file title> SEC_PORTIO_TIMEOUT 60 % <integer> SEC_TCPIP_UC <usercode> % delete if using BNA SEC_TCPIP_PWD <password> % delete if using BNA % END OF CONFIG FILE INPUT % % Example CONFIG file used as input to SYSTEM/RDBOPS for a database % using BNA for networking: % % DB_NAME PRODDB % CF_USERCODE PROD % PRI_HOSTNAME HOSTPROD % PRI_CF_FAMNAME DBPACK % PRI_AUDIT_FAMNAME AUDITPK % PRI_DUPAUDIT_FAMNAME 2AUDITPK % PRI_AUDIT_ALTFAMNAME DISK % PRI_DUPAUDIT_ALTFAMNAME PACK % PRI_RDBSERVER FILE *SYSTEM/RDBSERVER ON DISK % PRI_ACKRATE 16 % PRI_SYNC_RESTART_INTERVAL 100 % PRI_DELAY_AUDIT_REMOVAL TRUE % PRI_AUDITTRANSFER_MODE 1 % <mode option> % <mode option> values: % NSC = 0 % ABW = 1 % AFS = 2 % SCA = 3 % AFM = 4 % PRI_ERROR_HANDLING 1 % <error handling option> % <error handling option> values for ABW mode: % DROP = 1 % OPERATOR = 2 % PRI_AFS_TRANSFER 1 % <file transfer option> % <file transfer option> values for AFS mode: % NFT = 1 % FTRAPID = 2 % PRI_AFM_COPYAUDIT TRUE % PRI_FTRAPID_TITLE OBJECT/RAPID ON DISK % <file title> _ % PRI_PORTIO_TIMEOUT 60 % <integer> % SEC_HOSTNAME HOSTDR

304 SYSTEM/RDBOPS % SEC_CF_FAMNAME DBPACK % SEC_AUDIT_FAMNAME AUDITPK % SEC_DUPAUDIT_FAMNAME 2AUDITPK % SEC_AUDIT_ALTFAMNAME DISK % SEC_DUPAUDIT_ALTFAMNAME PACK % SEC_RDBSERVER_FILE *SYSTEM/RDBSERVER ON DISK % SEC_ACKRATE 10 % <integer> % SEC_SYNC_RESTART_INTERVAL 100 % <integer> % SEC_AUDITTRANSFER_MODE 1 % <mode option> % <mode option> values: % NSC = 0 % ABW = 1 % AFS = 2 % SCA = 3 % AFM = 4 % SEC_ERROR_HANDLING 1 % <error handling option> % <error handling option> values for ABW mode: % DROP = 1 % OPERATOR = 2 % SEC_AFS_TRANSFER 1 % <file transfer option> % <file transfer option> values for AFS mode: % NFT = 1 % FTRAPID = 2 % SEC_AFM_COPYAUDIT TRUE % SEC_FTRAPID_TITLE OBJECT/RAPID ON DISK % <file title> % SEC_PORTIO_TIMEOUT 60 % <integer> Figure Sample template of the TEMPLATE/RDBOPS/CONFIG file Examples: Example 1: To initialize a Remote Database Backup system, complete a CONFIG file and save it as RDB/CONFIG/INIT/PRODDB ON DBPACK: RUN SYSTEM/RDBOPS("DB=(PROD)PRODDB ON DBPACK INITIALIZE"); FILE CONFIG = RDBOPS/CONFIG/INIT/PRODDB ON DBPACK The following is a sample RDB/CONFIG/INIT/PRODDB that uses BNA: DB NAME PRODDB CF USERCODE BOB PRI HOSTNAME PRODHOST PRICE FAMNAME DBPACK PRI_AUDIT_FAMNAME AUDPACK PRI DUPAUDIT FAMNAME DUPAUDPACK PRI_AUDIT_ALTFAMNAME AUD2PACK PRI DUPAUDIT ALTFAMNAME DUPAUD2PACK PRI_RDBSERVER_FILE *SYSTEM/RDBSERVER ON DISK PRI ACKRATE 10 PRI SYNC RESTART INTERVAL 100 PRIIDELfi_AUDIT_TEMOVAL false PRI AUDITTRANSFER MODE 1 % <mode option> values: % NSC = 0 % ABW = 1 % AFS = 2 % SCA =

305 SYSTEM/RDBOPS % AFM = 4 PRI ERROR HANDLING 1 % <error handling option> values for ABW mode: % DROP = 1 % OPERATOR = 2 PRI_AFS_TRANSFER 1 % <file transfer option for BNA> % <file transfer option> values for AFS mode: % NFT = 1 % FTRAPID = 2 PRI_AFM_COPYAUDIT false PRI FTRAPID TITLE OBJECT/RAPID ON DISK PRI PORTIO TIMEOUT 60 SEC HOSTNAME DRHOST SEC CF FAMNAME DBPACK SEC_AUDIT _FAMNAME AUDPACK SEC DUPAUDIT FAMNAME DUPAUDPACK SEC_AUDIT_ALTFAMNAME AUD2PACK SEC DUPAUDIT ALTFAMNAME DUPAUD2PACK SEC RDBSERVEi FILE *SYSTEM/RDBSERVER ON DMTEST SEC ACKRATE 15 SEC SYNC RESTART INTERVAL 100 SEC AUDITTRANSFERMODE 1 % <mode option> % <mode option> values: % NSC = 0 % ABW = 1 % AFS = 2 % SCA = 3 % AFM = 4 SEC ERROR HANDLING 1 % <error handling option> % <error handling option> values for ABW mode: % DROP = 1 % OPERATOR = 2 SEC_AFS_TRANSFER 1 % <file transfer option for BNA> % <file transfer option> values for AFS mode: % NFT = 1 % FTRAPID = 2 SEC AFM COPYAUDIT false SEC FTRAPID TITLE OBJECT/RAPID ON DISK % <file title> SEC PORTIO TIMEOUT 60 % <integer> Example 2: To enable the RDB capability, execute the following command: RUN SYSTEM/RDBOPS("DB=(PROD)PRODDB ON DBPACK ENABLE") Example 3: To modify the audit transfer mode of a Remote Database Backup system, complete a CONFIG file and save it as RDB/CONFIG/MODIFY/PRODDB/AUDITTRANSFER ON DBPACK: RUN SYSTEM/RDBOPS("DB=(PROD)PRODDB ON DBPACK MODIFY"); FILE CONFIG = RDB/CONFIG/MODIFY/PRODDB/AUDITTRANSFER ON DBPACK The following is a sample RDB/CONFIG/MODIFY/PRODDB/AUDITTRANSFER that uses BNA:

306 SYSTEM/RDBOPS DB NAME PRODDB CF USERCODE BOB PRI HOSTNAME PRODHOST PRI CF FAMNAME DBPACK PRI_AUDIT _FAMNAME AUDPACK PRI DUPAUDIT FAMNAME DUPAUDPACK PRI_AUDIT_ALTFAMNAME AUD2PACK PRI DUPAUDIT ALTFAMNAME DUPAUD2PACK PRI RDBSERVEi FILE *SYSTEM/RDBSERVER ON DISK PRI PACKRATE 16 PRI SYNC RESTART INTERVAL 100 PRIIDELfi_AUDIT_TEMOVAL false PRI AUDITTRANSFER MODE 2 % <mode option> values: % NSC = 0 % ABW = 1 % AFS = 2 % SCA = 3 % AFM = 4 PRI ERROR_HANDLING 1 % <error handling option> values for ABW mode: % DROP = 1 % OPERATOR = 2 PRI_AFS_TRANSFER 1 % <file transfer option for BNA> % <file transfer option> values for AFS mode: % NFT = 1 % FTRAPID = 2 PRI AFM COPYAUDIT false PRI FTRAPID TITLE OBJECT/RAPID ON DISK PRI PORTIO TIMEOUT 60 SEC HOSTNAME DRHOST SEC CF FAMNAME DBPACK SEC_ AUDIT _FAMNAME AUDPACK SEC DUPAUDIT FAMNAME DUPAUDPACK SEC_AUDIT_ALTFAMNAME AUD2PACK SEC DUPAUDIT ALTFAMNAME DUPAUD2PACK SEC RDBSERVEi_FILE *SYSTEM/RDBSERVER ON DMTEST SEC_ACKRATE 10 SEC SYNC RESTART INTERVAL 100 SEC AUDITTRANSFEi MODE 2 % <mode option> % <mode option> values: % NSC = 0 % ABW = 1 % AFS = 2 % SCA = 3 % AFM = 4 SEC ERROR HANDLING 1 % <error handling option> % <error handling option> values for ABW mode: % DROP = 1 % OPERATOR = 2 SEC_AFS_TRANSFER 1 % <file transfer option for BNA> % <file transfer option> values for AFS mode % NFT = 1 % FTRAPID = 2 SEC AFM COPYAUDIT false SEC FTRAPID TITLE OBJECT/RAPID ON DISK % <file title>

307 SYSTEM/RDBOPS SEC PORTIO TIMEOUT 60 % <integer> Example 4: To acknowledge the receipt of audit 5 at the secondary host and override any confirmation, execute the following command: RUN SYSTEM/RDBOPS("DB=(PROD)PRODDB ON DBPACK ACKNOWLEDGE 5 OVERRIDE") Example 5: To disable the Remote Database Backup capability, execute the following command: RUN SYSTEM/RDBOPS("DB=(PROD)PRODDB ON DBPACK DISABLE") Example 6: To perform a takeover to configure HOSTDR as the primary host and automatically override any confirmation warnings, execute the following command: RUN SYSTEM/RDBOPS("DB=(PROD)PRODDB ON DBPACK TAKEOVER HOSTDIR OVERRIDE") Example 7: To access dynamic status and statistical information, execute the following command: RUN SYSTEM/RDBOPS("DB=(PROD)PRODDB ON DBPACK STATUS") Example 8: To modify the timeout value of a Remote Database Backup system, complete a CONFIG file and save it as RDB/CONFIG/MODIFY/PRODDB/TIMEOUT ON DBPACK: RUN SYSTEM/RDBOPS("DB=(PROD)PRODDB ON DBPACK MODIFY"); FILE CONFIG = RDB/CONFIG/MODIFY/PRODDB/TIMEOUT ON DBPACK The following is a sample RDB/CONFIG/MODIFY/PRODDB/TIMEOUT that uses BNA: DB NAME PRODDB CF USERCODE BOB PRI HOSTNAME PRODHOST PRI CF FAMNAME DBPACK PRI_AUDIT_FAMNAME AUDPACK PRI DUPAUDIT FAMNAME DUPAUDPACK PRI_AUDIT_ALTFAMNAME AUD2PACK PRI DUPAUDIT ALTFAMNAME DUPAUD2PACK PRIIRDBSERVER_FILE *SYSTEM/RDBSERVER ON DISK PRI ACKRATE 10 PRI SYNC RESTART INTERVAL 100 PRIIDELfi_AUDIT_TEMOVAL false PRI AUDITTRANSFER MODE 1 % <mode option> values: % NSC = 0 % ABW = 1 % AFS = 2 % SCA = 3 % AFM = 4 PRI ERROR HANDLING 1 % <error handling option> values for ABW mode: % DROP = 1 % OPERATOR = 2 PRI_AFS_TRANSFER 1 % <file transfer option for BNA>

308 SYSTEM/RDBOPS % <file transfer option> values for AFS mode: % NFT = 1 % FTRAPID = 2 PRI _ AFM _COPYAUDIT false PRI FTRAPID TITLE OBJECT/RAPID ON DISK PRI PORTIO TIMEOUT 10 SEC HOSTNAME DRHOST SEC CF FAMNAME DBPACK SEC_AUDIT _FAMNAME AUDPACK SEC DUPAUDIT FAMNAME DUPAUDPACK SEC_ AUDIT _ALTFAMNAME AUD2PACK SEC DUPAUDIT ALTFAMNAME DUPAUD2PACK SEC RDBSERVEi_FILE *SYSTEM/RDBSERVER ON DMTEST SEC ACKRATE 10 SEC_SYNC_RESTART_INTERVAL 100 SEC AUDITTRANSFER MODE 1 % <mode option> % <mode option> values: % NSC = 0 % ABW = 1 % AFS = 2 % SCA = 3 % AFM = 4 SEC_ERROR_HANDLING 1 % <error handling option> % 4 <error handling option> values for ABW mode: % DROP = 1 % OPERATOR = 2 SEC_AFS_TRANSFER 1 % <file transfer option for BNA> % <file transfer option> values for AFS mode: % NFT = 1 % FTRAPID = 2 SEC AFM COPYAUDIT false SEC FTRAPID TITLE OBJECT/RAPID ON DISK % <file title> SEC PORTIO TIMEOUT 60 % <integer>

309 Appendix A Sample Clone WFL Job In This Appendix This appendix contains a sample WFL job for a full clone operation. Sample Full Clone WFL Job The following code is a sample full clone WFL job for a database named RDB that uses BNA. Documentation that explains the job is contained in the lines of code that begin with percent signs (%). However, the documentation does not appear in actual WFL jobs that are generated on your system. In this example: DMTEST is the database usercode. PRIMHOST is the primary host. DMSII is the pack on the primary host containing the database files. SECHOST is the secondary host. DBPACK is the pack on the secondary host containing the database files. SYSPACK is the pack on the secondary host containing the code files. AUDITPACK is the pack on the secondary host containing the audit files. BEGIN JOB CLONEDB/RDB; INTEGER JOBNUM, JOBNUMORZERO; BOOLEAN DMCONTROLUPDATED; TASK T; COPY (DMTEST)DESCRIPTION/RDB FROM DMSII(PACK,HOSTNAME=PRIMHOST) TO DBPACK(PACK, HOSTNAME=SECHOST); COPY (DMTEST)DMSUPPORT/RDB FROM DMSII(PACK,HOSTNAME=PRIMHOST) TO DBPACK(PACK, HOSTNAME=SECHOST); COPY (DMTEST)RECONSTRUCT/RDB FROM DMSII(PACK,HOSTNAME=PRIMHOST) TO DBPACK(PACK, HOSTNAME=SECHOST); T (STATUS = NEVERUSED); T (SW1 = TRUE); % % The initial steps of the clone task require resetting the status % of the current secondary database (if present) and ensuring that A 1

310 Sample Clone WFL Job % the family for the DMSUPPORT library is correct. % RUN *SYSTEM/DMCONTROL ON SYSPACK("*")[T]; FILE DASDL(KIND=DISK, TITLE=(DMTEST)DESCRIPTION/RDB ON DBPACK); FILE CF(KIND=DISK, TITLE=(DMTEST)RDB/CONTROL ON DBPACK); FILE CFOLD(KIND=DISK, TITLE=(DMTEST)RDB/CONTROL ON DBPACK);?DATA RESETCLONED, DMSUPPORT FAMILY = DBPACK? IF T(VALUE) EQL 1 THEN ABORT ("DMCONTROL:(DMTEST)RDB" & ": DMSUPPORT FAMILY UPDATE FAILED.") ELSE DMCONTROLUPDATED := TRUE; JOBNUM := MYJOB(MIXNUMBER); % % A restart point is created here to minimize the amount % of code that must be executed in the event that the % system should incur a halt/load while the clone WFL % job is running. % ON RESTART, BEGIN COPY (DMTEST)DESCRIPTION/RDB FROM DMSII(PACK,HOSTNAME=PRIMHOST) TO DBPACK(PACK, HOSTNAME=SECHOST); COPY (DMTEST)DMSUPPORT/RDB FROM DMSII(PACK,HOSTNAME=PRIMHOST) TO DBPACK(PACK, HOSTNAME=SECHOST); COPY (DMTEST)RECONSTRUCT/RDB FROM DMSII(PACK,HOSTNAME=PRIMHOST) TO DBPACK(PACK, HOSTNAME=SECHOST); DMCONTROLUPDATED := FALSE; JOBNUMORZERO:=JOBNUM; GO TO ENABLEONTASKFAULT; END; ENABLEONTASKFAULT: ON TASKFAULT, BEGIN WAIT("DMUTILITY:(DMTEST)RDB: CLONE FAILED" & " - OK TO RESTART, DS TO TERMINATE", OK); DMCONTROLUPDATED := FALSE; IF FILE RDB/HLDUMPINFO/#STRING(JOBNUM,*) IS RESIDENT THEN JOBNUMORZERO:=JOBNUM; GO TO RUNCLONE; END; RUNCLONE: IF NOT DMCONTROLUPDATED THEN BEGIN T (STATUS = NEVERUSED); T (SW1 = TRUE); RUN (DMTEST)SYSTEM/DMCONTROL ON SYSPACK("*")[T]; FILE DASDL(KIND=DISK, TITLE=(DMTEST)DESCRIPTION/RDB ON DBPACK); FILE CF(KIND=DISK, TITLE=(DMTEST)RDB/CONTROL ON DBPACK); FILE CFOLD(KIND=DISK, TITLE=(DMTEST)RDB/CONTROL ON DBPACK);?DATA A

311 Sample Clone WFL Job DMSUPPORT FAMILY = DBPACK? IF T(VALUE) EQL 1 THEN ABORT ("DMCONTROL:(DMTEST)RDB" & ": DMSUPPORT FAMILY UPDATE FAILED.") END; % % SYSTEM/ DMUTILITY is used to create the secondary database from a % dump of the database. In this example, database files that are % on the pack DMSII on the primary system are being created on the % secondary system pack named DBPACK. The dump being used is a % disk file dump named RDB/DUMP, which resides on the pack DBPACK. % T (STATUS = NEVERUSED); RUN *SYSTEM/DMUTILITY ON SYSPACK("*")[T]; TASKVALUE = -JOBNUMORZERO;?DATA DB = (DMTEST)RDB ON DBPACK TAPECLONE = (PACKNAME = DMSII) AS (DMTEST) = ON DBPACK, = AS (DMTEST) = FROM DUMP/RDB ON DBPACK? IF T ISNT COMPLETEDOK THEN ABORT ("DMUTILITY:(DMTEST)RDB: CLONE FAILED."); ON TASKFAULT; ON RESTART; T (STATUS = NEVERUSED); T (SW1 = TRUE); % % If all the preceding steps have completed without error, the clone % operation is basically complete. All that remains is to set the % status of the database to cloned and update the pack name % specifications for Enterprise Database Server files that % are specified in the database % DASDL source file. % RUN *SYSTEM/DMCONTROL ON SYSPACK("*")[T]; FILE DASDL(KIND=DISK, TITLE=(DMTEST)DESCRIPTION/RDB ON DBPACK); FILE CF(KIND=DISK, TITLE=(DMTEST)RDB/CONTROL ON DBPACK); FILE CFOLD(KIND=DISK, TITLE=(DMTEST)RDB/CONTROL ON DBPACK);?DATA DMSUPPORT FAMILY = DBPACK, ACCESSROUTINES FAMILY = SYSPACK, RECOVERY FAMILY = SYSPACK, DATARECOVERY FAMILY = SYSPACK, RECONSTRUCT FAMILY = DBPACK, REORGANIZATION FAMILY = DBPACK, DMCONTROL FAMILY = SYSPACK, DMUTILITY FAMILY = SYSPACK, COPYAUDITPRIWFL FAMILY = SYSPACK, COPYAUDITSECWFL FAMILY = SYSPACK, AUDITFAMILY = AUDITPACK, FAMILY DMSII = DBPACK, SETCLONED? IF T(VALUE) EQL 1 THEN ABORT ("DMCONTROL:(DMTEST)RDB" & ": FAMILY CHANGES FAILED."); DISPLAY "(DMTEST)RDB: CLONE COMPLETED OK"; END JOB A 3

312 Sample Clone WFL Job Related Information Topics For information about... Refer to... Clone operation while configuring the Remote Database Backup system Full clone operation while managing the Remote Database Backup system Section 5 Section 8 Structure clone operation Section 9 A

313 Appendix B Resource Assessment Forms In This Appendix This appendix contains forms you can use to record your resource descriptions and calculations during your resource assessment: System Resource Description Form Database Description Form Primary Host Database Applications List Form Primary Host Nondatabase Applications List Form Secondary Host Applications List Form Network Description Form Audit Generation Rate Form Applications Activity Form System Resource Description Form Network node name Site location Style, model Memory Database disk configuration Communications processors B 1

314 Resource Assessment Forms Name Date Database Description Form Database name Primary host Secondary host DASDL options DASDL parameters Name Date B

315 Resource Assessment Forms Primary Host Database Applications List Form Database name Application names Critical update Critical report Noncritical update Noncritical report Name Date Primary Host Nondatabase Applications List Form Application names Critical B 3

316 Resource Assessment Forms Application names Noncritical Name Date Secondary Host Applications List Form Application names Critical Noncritical B

317 Resource Assessment Forms Application names Name Date Network Description Form Network Component Model Capacity Existing Utilization Utilization with Remote Database Backup Name Date B 5

318 Resource Assessment Forms Audit Generation Rate Form Database name Message size (bytes) Message size of file transfer product Time Period Audit Generation Rate (Bytes per Second) Audit Generation Rate (Messages/Second) Start End Peak Average Peak Average Name Date B

319 Resource Assessment Forms Applications Activity Form B 7

320 Resource Assessment Forms B

321 Appendix C Methods of Measuring Resource Utilization In This Appendix This appendix contains information on the tools you can use to measure existing utilization of your resources, including Database activity Audit generation rate Audit block size Tools to Measure Database Activity Introduction To generate graphic and numeric representations of the transaction profiles of the databases you want to establish in the Remote Database Backup environment, you can use the following two Visible DBS commands. Command AUDIT PROCESSOR TIMES AUDIT ANALYZE AFN Purpose Switches on or off the accumulation of processor usage information. Each time you use the command an audit file switch occurs. Generates a report of average and peak audit generation rates by analyzing the audit file specified by the AFN. When the AUDIT PROCESSOR TIMES command was turned on during the creation of the audit file, this command also produces a report of processor usage. AUDIT PROCESSOR TIMES Command You can use the AUDIT PROCESSOR TIMES command with any database, at any time, inside or outside of the Remote Database Backup environment. When you are assessing your database activity, consider switching on the collection of processor usage information and leaving it on for a time period that would provide you with a profile of your normal database activity C 1

322 Methods of Measuring Resource Utilization For example, if your site operates 5 days a week and every 24-hour period is similar, then switch on the processor usage collection for any 24-hour period. If, however, there is one day of the week when your database is always more heavily used than any other, collect the processor usage information for that specific peak time period as well as for a time period that represents the normal database activity. AUDIT ANALYZE AFN Command The AUDIT ANALYZE AFN command analyzes a given database audit file and produces a report that shows the amount of audit information generated during a specific period of time. This information is presented in the form of a bar chart (refer to Figure C 1, Part 1). The syntax for the AUDIT ANALYZE AFN command is SM AUDIT ANALYZE AFN <integer> INTERVAL = <integer> The AFN integer is the number of the audit file to be analyzed. The interval integer is optional and designates the time, in seconds, for each report interval. The default value is 60 seconds. Because the AUDIT ANALYZE AFN command works on an entire audit file, the audit file can be generated at one time and analyzed at another, perhaps during periods of less activity, or off hours. In contrast, Enterprise Database Server statistics must be run in real time. The AUDIT ANALYZE AFN command requires that the database be running in order to issue the command to the database stack. If you use the AUDIT ANALYZE AFN command without the AUDIT PROCESSOR TIMES command, the report that is produced contains audit generation information only. You cannot analyze The current audit file for any database An audit file at the secondary host that has not been tracked AUDIT ANALYZE AFN Command Report Figure C 1, Parts 1 and 2, shows the two sections of the report created by the AUDIT ANALYZE AFN command. The bar chart portion of the report (refer to Figure C 1, Part 1) makes it very easy to identify the peak and average audit generation rates and thereby to determine the network capacity required to sustain the Remote Database Backup communications level. Because the processor usage information was also requested by having the AUDIT PROCESSOR TIMES command on, the audit generation information is followed by the processor usage analysis (refer to Figure C 1, Part 2). This processor usage information is presented in tabular form and is broken down by the time interval specified in the command. Other columns in the table contain processor usage (in seconds) and the percentage of the interval time for each of the following: C

323 Methods of Measuring Resource Utilization Enterprise Database Server inquiry operations Enterprise Database Server update operations Code other than Enterprise Database Server code (for example, application code) Enterprise Database Server I/O utilization is also reported in this table. The I/O percentage can be greater than 100 percent if multiple I/Os are in progress. The figures reported in the DMS UPDATE column approximate the amount of processor time required to apply audits to the secondary database. UNISYS MicroA AUDIT ANALYSIS VERSION (TEST)TESTDB/AUDIT4 ON DISK Audit created on a MicroA, BLOCK ZERO TIMESTAMP: 2/20/96 9:36 TIME AUDIT BITS/SECOND (* = 10,000) 09:12: ********** 09:12: ******** 09:12: ******** 09:12: ********* 09:12: ********* 09:12: ********* 09:13: ********* 09:13: ********* 09:13: ****** 09:13: ****** 09:13: **** 09:13: ***** 09:14: ******* 09:14: ******** 09:14: ********** 09:14: ********* 09:14: ********* 09:14: ******* 09:15: ******* 09:15: ****** 09:15: ********* 09:15: ********** 09:15: ********* 09:15: ********* 09:16: ********* 09:16: ******** 09:16: ********** 09:16: ******** 09:16: ******** 09:16: ********* 09:17: ********** 09:17: ********* 09:17: ********** 09:17: ********* 09:17: ******** 09:17: * PAGE AVERAGE ******** TOTAL WORDS OF AUDIT ANALYZED: (Actual command: SM AUDIT ANALYZE AFN 4 INTERVAL = 10) C 3

324 Methods of Measuring Resource Utilization Figure C 1. Sample Output from the AUDIT ANALYZE AFN Command (Part 1) Figure C 2. Sample Output from the AUDIT ANALYZE AFN Command (Part 2) Related Information Topics C

325 Methods of Measuring Resource Utilization For information about... Refer to... AUDIT ANALYZE AFN command AUDIT PROCESSOR TIMES command Enterprise Database Server statistics Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Tools to Obtain an Audit Generation Rate Introduction To obtain an audit generation rate, you can use one or more of the following tools: Enterprise Database Server statistics report AUDIT ANALYZE AFN command Count of audit files Enterprise Database Server Statistics Report To generate Enterprise Database Server statistics information in real time as the database creates its audit files, set the STATISTICS option for your database in the DASDL source file and access the statistics printout to determine how much audit data was generated during the statistics-gathering interval. You must gather statistics reports for several intervals to establish peak and typical throughput requirements. The statistics indicate how much audit information is generated in terms of the number of audit blocks and the average audit block size (in words). To estimate network throughput requirements, perform the following procedure. Step Action 1 Convert the average audit block size from words to bytes per second by multiplying by 6. 2 Multiply the result of step 1 by the number of blocks. 3 Divide the result of step 2 by the time in seconds. Enterprise Database Server statistics provides only an average rate during any statisticsgathering period. Frequent use of short statistics-gathering intervals is required to identify peak periods of audit generation C 5

326 Methods of Measuring Resource Utilization AUDIT ANALYZE AFN Command Refer to the explanation and example of the AUDIT ANALYZE AFN command earlier in this appendix. Count of Audit Files To determine an average generation rate by a count of audit files, perform the following procedure. Step Action 1 For a specific time period, count the number of complete audit files listed in the system summary log (SUMLOG). The time period can be one day or a combination of several shorter periods to obtain a more detailed set of averages. 2 Calculate the number of bytes per file based on the attributes of one complete audit file. 3 Multiply the result of step 1 by the result of step 2. Tools to Obtain an Audit Block Size You can obtain an average or optimal audit block size by using one or more of the following tools: Enterprise Database Server statistics report You can use the average audit block size number in the Enterprise Database Server statistics report as your audit block size. PRINTAUDIT program By sampling results from the PRINTAUDIT program, you can estimate the distribution of or at least get an approximate idea of the sizes of audit blocks actually generated by your database. The result of such a sampling is more useful than the average block size. Related Information Topics For information about... Refer to... AUDIT ANALYZE command AUDIT PROCESSOR TIMES command Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Audit transmission modes Sections 1, 2, 3, 4, and 5 C

327 Methods of Measuring Resource Utilization For information about... Refer to... Enterprise Database Server statistics PRINTAUDIT program Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide C 7

328 Methods of Measuring Resource Utilization C

329 Appendix D Operational Considerations for Mirrored Audit This appendix provides procedures to perform when using mirrored audit from the EMC Corporation. These procedures include Setting up shared disks on ClearPath hosts for EMC mirrored disks Recovering from a corrupted pack label on target packs Changing audit file transmission modes - Changing the audit file transmission mode from ABW to AFM - Changing the audit file transmission mode from AFM to ABW - Changing the audit file transmission mode from AFS to AFM - Changing the audit file transmission mode from AFM to AFS - Changing the audit file transmission mode from SCA to AFM Performing a planned takeover in AFM mode Restoring the original Remote Database Backup configuration following a planned takeover Performing an unplanned takeover in AFM mode Restoring the original Remote Database Backup configuration following an unplanned takeover Remote Database Backup System Environment Figure D 1 shows an example of the Remote Database Backup system environment and how it works with disk subsystems. The Remote Database Backup system at Server1 contains four applications. Applications number 1 and 2 are read/write capable, application 3 is read-only capable, and application 4 is the DMUTILITY program, which performs the QUIESCE function. The Remote Database Backup system at Server2 contains three applications numbered 5 through 7. Each of these applications is read-only capable. Application 7 is the DMUTILITY program, which performs the QUIESCE function. In the disk subsystems, D1 represents a disk containing data files that are written to and read by the Remote Database Backup system at Server1. A1 represents a disk containing audit files written to and read by the Remote Database Backup system at Server D 1

330 Operational Considerations for Mirrored Audit There is a spare disk, SPARE1, available to either Server1 or Server2. A physically mirrored copy of A1 is read by the Remote Database Backup system at Server2 and is called A2. Figure D 1. Remote Database Backup System Environment and How It Works with Disk Subsystems Setting Up Shared Disks on ClearPath Hosts for EMC Mirrored Disks It is necessary to configure the EMC source and target disks that are attached to the source and target hosts. Within an EMC disk subsystem, the source disk is the disk that is configured as a mirrored source using the Symmetrix Remote Data Facility (SRDF). This disk is read/write capable. Within an EMC disk subsystem, the target disk is the disk that is configured as a mirrored target using the SRDF. This disk is read-only capable. The source host is a ClearPath host that is attached to a source disk of an EMC subsystem in an SRDF environment, while the target host is a ClearPath host that is attached to a target disk of an EMC subsystem in an SRDF environment. D