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

Transcription

1 unisys ClearPath Enterprise Servers Remote Database Backup Planning and Operations Guide ClearPath MCP 14.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 is commercial computer software or hardware documentation developed at private expense. 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 ClearPath are registered trademarks of Unisys Corporation in the United States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders.

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 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 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 iii

4 Contents 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 Preparations for Using a Nonusercoded Database 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 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 Enabling the Remote Database Backup System iv

5 Contents 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 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 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 Deleting the Host Information Record for the Secondary Host v

6 Contents 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 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 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 vi

7 Contents 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-I/O Timeout Errors Resolving Updating and Reorganization Problems Resolving Tape Audit Failures 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 vii

8 Contents Appendix B. Resource Assessment Forms System Resource Description Form... B 2 Database Description Form... B 3 Primary Host Database Applications List Form... B 4 Primary Host Nondatabase Applications List Form... B 5 Secondary Host Applications List Form... B 6 Network Description Form... B 7 Audit Generation Rate Form... B 8 Applications Activity Form... B 9 Appendix C. Methods of Measuring Resource Utilization Tools to Measure Database Activity... C 2 Tools to Obtain an Audit Generation Rate... C 7 Tools to Obtain an Audit Block Size... C 9 Appendix D. Operational Considerations for Mirrored Audit Remote Database Backup System Environment... D 2 Setting Up Shared Disks on ClearPath Hosts for EMC Mirrored Disks... D 4 Recovering from a Corrupted Pack Label on Target Packs... D 6 Changing Audit File Transmission Modes... D 6 Disabling the Remote Database Backup System... D 8 Performing a Planned Takeover in AFM Mode... D 9 Restoring the Original Remote Database Backup Configuration Following a Planned Takeover... D 10 Performing an Unplanned Takeover in AFM Mode... D 13 Restoring the Original Remote Database Backup Configuration Following an Unplanned Takeover... D 14 Index... 1 viii

9 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 image of the TEMPLATE/RDB/CONFIG file C 1. Sample Output from the AUDIT ANALYZE AFN Command (Part 1)... C 4 C 1. Sample Output from the AUDIT ANALYZE AFN Command (Part 2)... C 5 D 1. Remote Database Backup System Environment and How It Works with Disk Subsystems... D ix

10 Figures x

11 Tables 1 1. Audit Transmission Modes Effects of the Open Options on Database Availability xi

12 Tables xii

13 Section 1 Overview of the Remote Database Backup System Purpose Audience Prerequisites Conventions This guide provides the information necessary to understand the Remote Database Backup capability. The primary audience for this guide is the database personnel responsible for administrative and supervisory day-to-day database operations. System administrators and computer operators are a secondary audience. Anyone using this guide should be familiar with basic Enterprise Database Server concepts. You should have extensive experience in using Enterprise Database Server utilities. Lastly, you should have experience with creating and updating an Enterprise Database Server database. References to additional information contained in other books or sections of this guide are listed at the end of each subsection under the heading Related Information Topics. All screens referred to in this document are part of Database Operations Center. This document uses the following abbreviations: Kbps (kilobits per second) KBps (kilobytes per second) Mbps (megabits per second) MBps (megabytes per second)

14 Documentation Updates 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

15 What s New? What s New? This guide provides changes and information specific to the current release as shown in the following table: Section 2 Section 3 Section 8 Section 12 Section 13 Section 14 Location New Or Revised Information Updated text for ABW and AFM Transmission Mode References to Network Control Facility (NCF) removed Note added to Full Clone Tasks subheading to address NSC New topic added: STRUCTURECLONE Required Following Successful STRUCTURECLONE Update to Catchup Does Not Run After Mode Change from SCA to ABW subsection to include NSC Update to GET_RDB_MESSAGE Application Program Text example New RDBOPS section added

16 What Remote Database Backup Can Do for You 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. 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 four audit transmission modes enables you to choose the means of audit transfer between hosts that best suits your needs. 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

17 Roles of Databases and Hosts in a Remote Database Backup System 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 Primary Secondary Function 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 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

18 Roles of Databases and Hosts in a Remote Database Backup System 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

19 Configurations of Remote Database Backup Systems 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

20 Configurations of Remote Database Backup Systems 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

21 Configurations of Remote Database Backup Systems 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

22 Configurations of Remote Database Backup Systems 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 Configurations of Remote Database Backup Systems 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

24 Basic Remote Database Backup Hardware and Software Requirements 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. Hardware/Software Hardware Memory MCP/AS 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 must be installed on both the primary and secondary hosts. Hardware and software sufficient to handle Remote Database Backup traffic and other traffic between the primary and secondary hosts and BNA services. 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

25 Basic Remote Database Backup Hardware and Software Requirements 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. 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

26 Audit Trail Synchronization 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? 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

27 Audit Trail Synchronization 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 Manual for additional information about the shared disk feature. 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. 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

28 Audit Trail Synchronization 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. 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. AFS also uses the network for the transmission of control information. Goal: Periodic synchronization. Best case: To within one completed audit file. 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. SCA also uses the network for the transmission of control information. Goal: Periodic synchronization, completely under user control. Best case: To within one completed audit file. 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. Under the NSC mode, Remote Database Backup does not use the network if one exists. Goal: Periodic synchronization, completely under user control. Best case: To within one completed audit file

29 Audit Trail Synchronization 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. 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

30 Audit Trail Synchronization 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 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

31 The Next Step More About Audit Transmission Modes 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

32 The Next Step More About Audit Transmission Modes

33 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 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

34 Audit Block (ABW) Transmission Mode 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 Benefits The ABW mode Transmits audit data to the secondary host block by block as 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 capacity and disk speed and capacity must 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. 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

35 Audit Block (ABW) Transmission Mode 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 BNA 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. 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 higher up 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

36 Error-Handling Options for the ABW Mode 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. 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

37 Error-Handling Options for the ABW Mode Related Information Topics For information about... Refer to... Catchup Section 4 Port-I/O timeout function Section 4 View Remote Auditing Status screen Sectioned audit files View Remote Auditing Statistics screen Section 7 Enterprise Database Server Utilities Operations Guide DASDL Programming Reference Manual Section 7 Takeovers Section

38 Error-Handling Options for the ABW Mode 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. 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

39 Error-Handling Options for the ABW Mode 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. Action to Be Taken Stop sending audits to the secondary host. Retry communications. Syntax for AX Command <mix number> AX D <mix number> AX R 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

40 Audit File Mirror (AFM) Transmission Mode 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 Requirements 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. 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. 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

41 Audit File Mirror (AFM) Transmission Mode Benefits 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. 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

42 Audit Transmission Modes (AFS, SCA, and NSC) 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

43 Audit Transmission Modes (AFS, SCA, and NSC) 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. Description Benefits 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. Remote Database Backup uses either the NFT or FTRapid file transfer product to transfer the audit file under the AFS mode. 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. 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. 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

44 Audit Transmission Modes (AFS, SCA, and NSC) Remote Database Backup reinitiates failed audit transfers at the next audit file switch, as shown in the following table: When the following audit unit fails... Nonsectioned audit file Sectioned audit file Several audit files Remote Database Backup reinitiates... The audit file Remaining audit file sections in parallel All audit files in parallel

45 Audit Transmission Modes (AFS, SCA, and NSC) Server Capable (SCA) Mode Goal Description Benefits 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. 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. 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

46 Audit Transmission Modes (AFS, SCA, and NSC) Not Server Capable (NSC) Mode Goal Description Benefits 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. 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. 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 Sectioned audit files Section 7 Enterprise Database Server Utilities Operations Guide DASDL Programming Reference Manual

47 Audit Transmission Mode Options 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 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. 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

48 Audit Transmission Mode Options 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 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 Event Midnight Midnight to 10 p.m. 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) Changing audit transmission modes Section 4 Section 8 Synchronization levels Sections 1 and 3 Takeovers Section

49 Impact of the Block Transmission Mode on Resources Impact of the Block Transmission Mode on Resources General Impact Some primary database performance degradation is possible when you use ABW mode for high-transaction-rate databases. The existence and the amount of degradation is dependent on Remote Database Backup configuration Volume of audits 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

50 Impact of the Block Transmission Mode on Resources 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. 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 Configuring a Remote Database Backup system Duplicate audit trails Sections 5 and 8 Section 5 DASDL Programming Reference Manual Network transmission rates Section 3 Remote Database Backup acknowledge task Section 8 Tracker Sections 4 and

51 Impact of the File Transmission Modes on Resources 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. 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

52 Impact of the File Transmission Modes on Resources Impact of the AFS Mode on Resources Summary Benefits The AFS audit file transmission mode provides Automatic immediate transfer of audit files by way of NFT or FTRapid 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. 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. 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

53 Impact of the File Transmission Modes on Resources 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 TRANSFER RED 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. 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

54 Impact of the File Transmission Modes on Resources 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 Tape Network Effect on Network Resources 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. 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

55 Impact of the File Transmission Modes on Resources 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

56 The Next Step Selecting Options and System Resources for Your Goals 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. Section 3 of this guide leads you through the steps required to analyze how a Remote Database Backup system can work in your environment

57 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

58 Overview of the Process 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

59 Identifying Your Goals for Remote Database Backup 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

60 Identifying Your Goals for Remote Database Backup 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

61 Identifying Your Goals for Remote Database Backup 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 Remote Database Backup is also useful as a component of a comprehensive disaster recovery system that provides a continuous processing environment

62 Identifying Your Goals for Remote Database Backup 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

63 Identifying Your Goals for Remote Database Backup Establishing Performance Requirements Introduction Establishing your performance requirements for Remote Database Backup enables you to 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

64 Selecting Audit Transmission Modes to Meet Your Goals 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. 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

65 Selecting Audit Transmission Modes to Meet Your Goals 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. 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

66 Describing Your Resources 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

67 Describing Your Resources Application Descriptions 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

68 Introduction to Gathering Data to Calculate Utilization 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

69 Introduction to Gathering Data to Calculate Utilization 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, 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

70 Introduction to Gathering Data to Calculate Utilization 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 Measuring Tools 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. 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. 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

71 Introduction to Gathering Data to Calculate Utilization 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

72 Introduction to Gathering Data to Calculate Utilization 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 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

73 Gathering Data on Existing Network Utilization 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

74 Gathering Data on Future Network Utilization with Remote Database Backup 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 Component Network links Communications processors Recommended Utilization 80 percent of the signaling rate 80 percent of processor utilization 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

75 Gathering Data on Future Network Utilization with Remote Database Backup 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. 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

76 Gathering Data on Future Network Utilization with Remote Database Backup 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. 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>

77 Gathering Data on Future Network Utilization with Remote Database Backup 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 the hosts and a network are not available for testing, you must measure the audit generation rate and then estimate the utilization. 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

78 Gathering Data on Future Network Utilization with Remote Database Backup 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> = <byte s per time period> 4 To obtain the utilization value in bytes per second, perform the following calculations: a. Convert the time period into seconds. b. 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. 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, you can use either the NFT or FTRapid product. For the SCA and NSC modes, you can use NFT, FTRapid, 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, 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

79 Gathering Data on Future Network Utilization with Remote Database Backup 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

80 Gathering Data on Future Network Utilization with Remote Database Backup 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 error-handling 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

81 Gathering Data on Future Network Utilization with Remote Database Backup 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: 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

82 Gathering Data on Host Processor Utilization 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

83 Gathering Data on Host Processor Utilization 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 per centage> = <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. 5 To obtain a total for all utilization of the primary host, use the following formula: <total database utilization> + <total nondatabase utilization> = <total uti lization> 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

84 Calculating the Total Secondary Host Processor Utilization 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. 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 fo r 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

85 Calculating the Total Secondary Host Processor Utilization 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. 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 u tilization 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

86 The Next Step Preparing to Configure a Remote Database Backup System 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

87 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

88 Overview of Preparation Tasks 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. 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

89 Checking on the Remote Database Backup Installation 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. 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) Screen Design Facility Plus (SDF Plus) run-time software (included with the Remote Database Backup software)

90 Checking on the Remote Database Backup Installation 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 RDBSUPPORT N/A Code files that provide the Remote Database Backup functions DBCENTER SERVER N/A Files that provide the screens, error messages, and help information for Data Base 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 *SYTEM/RDBSUPPORT ON DISK + LOCKED The effects of this procedure are documented in the ClearPath Enterprise Servers System Commands Operations Reference Manual. 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

91 Checking on the Remote Database Backup Installation Preparations for Using a Nonusercoded Database 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

92 Checking on the Remote Database Backup Installation 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

93 Checking on the Remote Database Backup Installation 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: "<database name> has the Open/OLTP option set which may result in partial or missing global transactions."

94 Checking on the Remote Database Backup Installation Related Information Topics For information about... Refer to... Enterprise Application Environment databases Establishing the Remote Database Backup and SDF Plus libraries Hardware and memory information Job queues and queue attributes Open Distributed Transaction Processing Remote Database Backup installation SDF Plus Task attributes Section 11 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 SDF Plus Installation and Operations Guide Task Attributes Reference Manual

95 Understanding Remote Database Backup Software Understanding Remote Database Backup Software Remote Database Backup Software Components In addition to a standard database management system (such as the Enterprise Database Server) and the SDF Plus run-time libraries, the Remote Database Backup system consists of three specialized files. These files are Database Operations Center RDB server code file RDB support library Database Operations Center Database Operations Center is the menu-driven user interface for defining, installing, and maintaining a Remote Database Backup system. 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. 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

96 Understanding Remote Database Backup Software Before the migration to Database Operations Center, these tasks were performed by the RDB utility. The following table lists the RDBUTILITY screen and Database Operations Center screen that is now taking its place. RDBUTILITY Screen Remote Database Backup Utility in RDBUTILITY Host Information Record Details in RDBUTILITY Creating and Updating Host Information Records in RDBUTILITY Audit File Transmission Mode in RDBUTILITY Enable the RDB Capability in RDBUTILITY Clone Database in RDBUTIITY Guard File Pack Information in RDBUTILITY Code File Pack Information in RDBUTILITY Initiating the Clone Task in RDBUTILITY RDB Status Report in RDBUTILITY Change Host Type in RDBUTILITY RDB Statistics Report in RDBUTILITY Manual Audit File Transfer in RDBUTILITY Creating and Updating Host Information Records in RDBUTILITY Clone Database Structures in RDBUTILITY Database Operations Screen Select the Remote Database Backup option from the Tools menu to select the task you want to perform. Create, Modify, or View Host Information Create, Modify, or View Host Information Select the Audit File Transmission Mode Enable the Remote Auditing Capability Clone the Database Part of the Clone the Database series of screens if you select the Define Guard File Family Location check box. Part of the Clone the Database series of screens Part of the Clone the Database series of screens View Remote Auditing Status Report Perform a Host Takeover or Type Change View Remote Auditing Statistics Acknowledge the Manual Transfer of Audit Files Create, Modify, or View Host Information Clone Specific Structures

97 Understanding Remote Database Backup Software 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 file one 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: <database name>/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 on the primary host and you transmit the Monitor 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

98 Understanding Remote Database Backup Software 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 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 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

99 Understanding Remote Database Backup Software Figure 4 1. How Remote Database Backup Components Work Together for the ABW Mode

100 Understanding Remote Database Backup Software 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> 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

101 Understanding Remote Database Backup Software 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

102 Understanding Remote Database Backup Software 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. 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>

103 Understanding Remote Database Backup Software 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. 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

104 Understanding Remote Database Backup Software 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. 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

105 Understanding How Remote Database Backup Uses Port Files 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. 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

106 Understanding How Remote Database Backup Uses Port Files 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. 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

107 Understanding More About the ABW Mode 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. Primary Host ACR_PORT Port File Secondary Host Accessroutines ACR Port I/O Task Network Audit Server Task Tracker Task RDB Support Library Primary Database Audit File Audit File Secondary Database 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

108 Understanding More About the ABW Mode The actual order of the previously mentioned events is 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

109 Understanding More About the ABW Mode 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. 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

110 Understanding More About the ABW Mode 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

111 Understanding More About the ABW Mode 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

112 Understanding More About the ABW Mode 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 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

113 Integrating Remote Database Backup into Your Security Setup 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 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

114 Integrating Remote Database Backup into Your Security Setup 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. 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

115 Integrating Remote Database Backup into Your Security Setup Related Information Topics For information about... Refer to... Guard files MP command Security administration DASDL Programming Reference Manual Security Operations Guide System Commands Reference Manual Security Administration Guide

116 Preparing Personnel to Run the Remote Database Backup System 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 Troubleshooting Recovery and reorganization in a Remote Database Backup environment

117 Reviewing DASDL Source Files 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. 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

118 Reviewing DASDL Source Files 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: 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

119 Reviewing DASDL Source Files 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. 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

120 Designating Usercodes and Packs 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 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. Nonusercoded Databases In a Remote Database Backup environment, for nonusercoded databases, 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

121 Designating Usercodes and Packs 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. 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

122 Designating Usercodes and Packs 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. 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

123 Designating Usercodes and Packs 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 Security Administration Guide

124 Ensuring Database File Availability on the Secondary Host 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. 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>);

125 Ensuring Database File Availability on the Secondary Host 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. 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

126 I/O Timeout Value for the Ports 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: 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

127 I/O Timeout Value for the Ports 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. This program can be written so that it automatically restarts the system following a system halt/load. Related Information Topics For information about... Refer to... Port files Setting the port-i/o timeout value Understanding How Remote Database Backup Uses Port Files earlier in this section Sections 5 and

128 Influencing Tracker Performance 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

129 Influencing Tracker Performance 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 3. 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

130 Influencing Tracker Performance 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. 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)

131 Influencing Tracker Performance 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. 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

132 Influencing Tracker Performance 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 8 Visible DBS commands Enterprise Database Server Utilities Operations Guide

133 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 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 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

134 Configuration Tasks 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. 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. Order of Tasks The database can be open during all configuration 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

135 Defining Your Remote Database Backup System 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. RDB Control File Information The following table provides some information about the RDB control file. Information Item Where to initialize Name Location Explanation On the host containing the database Note: Database Operations Center designates the initializing host as the primary host. <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. Procedure 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 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

136 Defining Your Remote Database Backup System 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

137 Enabling the Remote Database Backup System 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: Procedure 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. 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. Related Information Topics For information about... Refer to... Defining a host information record Deleting a host information record Defining the Database Characteristics for the Secondary Host earlier in this section Section

138 Cloning the Database on the Secondary Host Cloning the Database on the Secondary Host Introduction Clone Tasks 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. 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 3. Identifying database file locations 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 Identifies the secondary host packs on which the database software files reside 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 6. Selecting the method of running the clone operation Provides the secondary host titles for the DMCONTROL and DMUTILITY code files Selects one of three methods of running the clone operation, and optionally initiates the operation

139 Cloning the Database on the Secondary Host Making the Required Database Files Available on the Secondary Host What the Task Does Required Files 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. 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. 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

140 Cloning the Database on the Secondary Host Procedure 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. To make the required database files available on the secondary host, perform the following procedure. 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: 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 Notes: 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 close 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

141 Cloning the Database 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 Library maintenance Section 8 DASDL Programming Reference Manual Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide 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 Administration Guide Security Center Help

142 Cloning the Database on the Secondary Host 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 PACKA PACKB Secondary Host PACKB PACKA 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 PACKA PACKB X Secondary Host X PACKA PACKB

143 Cloning the Database on the Secondary Host 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 Providing a dump of the database Ordering a dump for a clone operation Section 8 Enterprise Database Server Utilities Operations Guide DASDL Programming Reference Manual Enterprise Database Server Utilities Operations Guide DASDL Programming Reference Manual Section 4 Section

144 Cloning the Database on the Secondary Host 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 Procedure 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. To designate the pack names for the database files, use Database Operations Center

145 Cloning the Database on the Secondary Host Related Information Topics For information about... Refer to... Accessroutines 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 DASDL Programming Reference Manual 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

146 Cloning the Database on the Secondary Host Specifying Pack Names for Database Guard Files on the Secondary Host What the Task Does Procedure 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. To specify pack names for guard files on the secondary host, use the series of Clone screens. 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

147 Cloning the Database on the Secondary Host Providing the Titles of the DMCONTROL and DMUTILITY Code Files on the Secondary Host What the Task Does Procedure 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. To provide the titles of the DMCONTROL and the DMUTILITY code files on 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 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

148 Cloning the Database on the Secondary Host 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 a WFL job and optionally saves the job. 3 Creates a WFL job and saves 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. If you save the WFL job, the job restarts automatically if a problem occurs. You also might be able to reuse the WFL job 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. You can perform other tasks from this session while the WFL job is running

149 Cloning the Database on the Secondary Host Advantages of Creating a WFL Job and Saving It Methods 2 and 3 provide you with a WFL job that, if saved (method 2), gives you the following advantages: Clone WFL Job 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. By default, the clone WFL job is called WFL/CLONEDB/<database name>/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

150 Cloning the Database on the Secondary Host 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

151 Verifying the Remote Database Backup System Verifying the Remote Database Backup System Introduction Procedures After the clone operation completes, you should verify that it has been successful and that the Remote Database Backup system is functioning properly. 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

152 Verifying the Remote Database Backup System 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. 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

153 Starting the Secondary Database After a Clone Operation Starting the Secondary Database After a Clone Operation Conditions of Starting 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: XE " 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 that accesses the database runs at the secondary host 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 native file transfer (NFT) 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

154 Starting the Secondary Database After a Clone Operation 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. 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 Monitor 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

155 Starting the Secondary Database After 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 Monitor 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 Monitor screen has changed to the value of the audit file you acknowledged. 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

156 Starting the Secondary Database After a Clone Operation

157 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

158 Overview of a Takeover 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. 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

159 Overview of a Takeover 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

160 Performing Takeover Tasks 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 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

161 Performing Takeover Tasks 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. 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

162 Performing Takeover Tasks 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

163 Performing Takeover Tasks 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: Procedure 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. 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

164 Performing Takeover Tasks 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

165 Performing Takeover Tasks <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

166 Performing Takeover Tasks 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: AN ATTEMPT WAS MADE TO SEND AUDIT TO A PRIMARY

167 Performing Takeover Tasks 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. 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

168 Performing Takeover Tasks 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

169 Performing Takeover Tasks 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 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

170 Managing the Transaction Server Synchronized Recovery Managing the Transaction Server Synchronized Recovery Introduction Procedure 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. 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. 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 Job queues and queue attributes Sections 2, 3, 4, and 5 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

171 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

172 Overview of Remote Database Backup Monitoring 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. 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

173 Overview of Remote Database Backup Monitoring 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

174 Accessing Messages 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 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

175 Accessing the Current State of Audit Transfers Accessing the Current State of Audit Transfers When To Do This Task Access the current audit transfer information to determine whether 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

176 Accessing the Current State of Audit Transfers When to Display Remote Database Backup Auditing Status Information Procedure 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 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

177 Accessing the Current State of Audit Transfers 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. Current Primary Host Audit Information Information Item Primary host Current AFN, ABSN, Timestamp Audit transmission mode Explanation 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

178 Accessing the Current State of Audit Transfers Current Secondary Host Audit Information Information Item Secondary host Received AFN, ABSN, Timestamp Applied AFN, ABSN, Timestamp Control record applied ABSN, Timestamp, Date Audit transmission mode Explanation 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 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

179 Accessing the Current State of Audit Transfers The following audit records are control records. Control Record Mnemonic DBSI DBST BCP ECP RECOV SPT FILEDC STRDC 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. 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

180 Accessing Cumulative Remote Database Backup Statistics 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. 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

181 Accessing Cumulative Remote Database Backup Statistics 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. 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

182 Accessing Cumulative Remote Database Backup Statistics 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)

183 Accessing Cumulative Remote Database Backup Statistics 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

184 Interpreting Remote Database Backup 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. 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

185 Interpreting Remote Database Backup Statistics 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. 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

186 Accessing Database Statistics on Remote Database Backup Performance 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

187 Accessing Database Statistics on Remote Database Backup Performance 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

188 Accessing Database Statistics on Remote Database Backup Performance

189 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 Deleting the host information record for the secondary host 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

190 Interdependencies 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: <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

191 Audit File Accumulation 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

192 Acknowledgment of Audit Files 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

193 Acknowledgment of Audit Files 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: If you send an acknowledgment of an audit file before the file is available on the secondary host, Tracker waits with a NO FILE condition 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 Procedure 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 automatically acknowledges the files between the number of the last audit file applied to the secondary database and the number of the last audit file manually acknowledged. 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. 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

194 Acknowledgment of Audit Files 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 View Remote Auditing Status screen information Sectioned audit files Sections 2, 3, 4, and 5 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

195 Viewing and Updating Host Information Records 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 Names of the primary and secondary hosts Pack names of the essential database files Title of the RDB server code file 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 Procedure 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.) 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

196 Viewing and Updating Host Information Records Related Information Topics For information about... Refer to... Acknowledgment rate Sections 2, 4, and 5 Deleting a host information record Modifying a host information record Remote Database Backup configuration procedures Deleting the Host Information Record for the Secondary Host later in this section 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

197 Viewing and Updating Host Information Records Viewing a Host Information Record What the Task Does Procedure You can examine the host information records for the primary and secondary host. Optionally, you can also view the audit transmission mode setting for either host. You can perform this task from the primary host or the secondary host. 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 Viewing a host information record Sections 2, 3, 4, and 5 Database Operations Center Help

198 Viewing and Updating Host Information Records 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 Procedure 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. To modify a host information record, use the Host screen from the primary host

199 Viewing and Updating Host Information Records 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

200 Viewing and Updating Host Information Records Deleting the Host Information Record for the Secondary Host What the Task Does This task removes the host information record for the secondary host from the RDB control file. As a consequence of this removal, the Remote Database Backup system for the database is automatically disabled. The listing of the database control file includes CF REMOTE AUDITING = DISABLED Note: You cannot remove the host information record for the primary host by using this task. Reason for Performing This Task Procedure You perform this task when you want to change the secondary host in the Remote Database Backup system. An alternative to this task is to disable the Remote Database Backup system. To restore the Remote Database Backup system after either task, you must reenable the Remote Database Backup system. Note: If you remove the RDB control file from either the primary host or the secondary host, then you must reconfigure the Remote Database Backup system. To delete the host information record for the secondary host, use the Host screen from the primary host. Related Information Topics For information about... Refer to... Deleting host information records Disabling the Remote Database Backup system Modifying a host information record Database Operations Center Help Disabling the Remote Database Backup System later in this section Modifying a Host Information Record earlier in this section RDB control file Section

201 Changing the Audit File Transmission Mode 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. 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

202 Changing the Audit File Transmission Mode When the Change Takes Effect Procedure 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. 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. 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 View Remote Auditing Statistics screen Section 5 Section 7 Takeovers Sections 6 and

203 Cloning the Database on the Secondary Host 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 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

204 Cloning the Database on the Secondary Host 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. 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

205 Cloning the Database on the Secondary Host 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

206 Cloning the Database on the Secondary Host Related Information Topics For information about... Refer to... Catchup Section 4 Clone sample program Appendix A Cloning the database Section 5 Database Operations Center Help Database dumps Disabling the Remote Database Backup system Ordering a dump for a clone operation Enterprise Database Server Utilities Operations Guide Disabling the Remote Database Backup System later in this section Section 10 Providing a dump of the database Section 4 QUIESCE command Reenabling the Remote Database Backup system View Remote Auditing Status screen data Starting the secondary database after a clone operation Enterprise Database Server Utilities Operations Guide Reenabling the Remote Database Backup System later in this section Section 7 Section 5 Structure clone operation Section 9 Tape encryption keys Security Administration Guide Security Center Help Tracker Section 4 WFL jobs Ordering a dump for a clone operation WFL Reference Manual Section

207 Disabling Tracker 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 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

208 Disabling Tracker 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

209 Disabling 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. 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 PROD4 519 Ctrl All 1 (ACCT) (ACCT)DMSUPPORT/CTRLDB ON PROD4 515 Ctrl All 2 (ACCT) (ACCT)CTRLDB/RDBSUPPORT Results of Disabling Tracker Figure 8 1. Sample Output from the LIBS Command 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

210 Disabling Tracker 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. 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

211 Disabling 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

212 Performing an Offline Dump of the Secondary Database 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

213 Performing an Offline Dump of the Secondary Database 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. 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

214 Performing an Offline Dump of the Secondary Database Procedure 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. 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. 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");

215 Performing Replication of the Secondary Database 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. 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

216 Performing Replication of the Secondary Database 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

217 Disabling the Remote Database Backup System 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. 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

218 Disabling the Remote Database Backup System 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 Remote Database Backup configuration procedures Tape encryption keys Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Reenabling the Remote Database Backup System later in this section Section 5 Security Administration Guide Security Center Help

219 Reenabling the Remote Database Backup System 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 either by the disable operation or by deleting a host information record. 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 Deleting a host information record Disabling the Remote Database Backup system Enabling the Remote Database Backup system Making the required database files available on the scondary host Troubleshooting enable operation problems Section 5 Deleting the Host Information Record for the Secondary Host earlier in this section Disabling the Remote Database Backup System earlier in this section Section 5 Section 5 Section

220 Using Visible DBS Commands in the Remote Database Backup Environment 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. 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 Structure Change Structure Status Commands That CANNOT be Run Audit Analyze Audit Close Audit Processor Times Status Reorg 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

221 Using Visible DBS Commands in the Remote Database Backup Environment 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 AUDIT BLOCKSIZE CONTROLPOINT OVERLAYGOAL SYNCPOINT SYNCWAIT Takes effect immediately for the primary database 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 Takes effect immediately for the secondary 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

222 Using Visible DBS Commands in the Remote Database Backup Environment

223 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

224 DASDL Updates in the Remote Database Backup Environment 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. 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

225 DASDL Updates in the Remote Database Backup Environment 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. 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

226 DASDL Updates in the Remote Database Backup Environment 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. 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

227 DASDL Updates in the Remote Database Backup Environment 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 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

228 DASDL Updates in the Remote Database Backup Environment 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. 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

229 DASDL Updates in the Remote Database Backup Environment 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. 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

230 DASDL Updates in the Remote Database Backup Environment 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

231 DASDL Updates 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

232 DASDL Updates in the Remote Database Backup Environment 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 Code files DMCONTROL program DMSUPPORT library DMUTILITY program Reorganization Section 4 DASDL Programming Reference Manual DASDL Programming Reference Manual Enterprise Database Server Utilities Operations Guide 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

233 Tracker and the Reinitialization of an Existing Structure 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 initializati on. 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

234 Reorganizations 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. 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 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

235 Reorganizations in the Remote Database Backup Environment 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 Reorganization open options Reorganizing a database Enterprise Database Server Utilities Operations Guide Procedure to Perform an Audited Reorganization later in this section Section 8 Enterprise Database Server Utilities Operations Guide DASDL Programming Reference Manual

236 Reorganizations in the Remote Database Backup Environment 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 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

237 Reorganizations in the Remote Database Backup Environment 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 OFFLINE 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. Prohibits access to the database structures involved in the reorganization, but allows access to other structures during the reorganization process. Prevents record-level auditing but provides for state change records. 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. Generates minimal audit overhead. Enables the structure cloning of reorganized structures at the secondary host

238 Reorganizations in the Remote Database Backup Environment 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. 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

239 Reorganizations in the Remote Database Backup Environment 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. Reorganization Run from DASDL Specifications for the Control File 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 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 Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide Section 8 Tracker Sections 4 and

240 Reorganizations in the Remote Database Backup Environment 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 Partially audited BUILDREORG Open Options Required None Optional: INQUIRYONLY, EXCLUSIVE, PREVERIFY OFFLINE Process That Applies Changes to the Secondary Database Tracker 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

241 Reorganizations 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 1. 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. 2. Perform a structure clone operation on the secondary host. 3. Bring up inquiry or update programs on the primary host

242 Reorganizations in the Remote Database Backup Environment 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. 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

243 Reorganizations in the Remote Database Backup Environment 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. 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

244 Reorganizations in the Remote Database Backup Environment 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 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 FI LES, YOU MUST WFL MODIFY THE RDBSUPPORT CODEFILE AS DESCRIBED IN THE INSTAL LATION 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

245 Reorganizations in the Remote Database Backup Environment Step Action 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. 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

246 Reorganizations in the Remote Database Backup Environment 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. 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

247 Reorganizations in the Remote Database Backup Environment Related Information Topics For information about... Refer to... Cloning a database Sections 5 and 8 Modifying the RDB support library for a nonusercoded database Section

248 Reorganizations in the Remote Database Backup Environment 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 2. Providing Enterprise Database Server code file information 3. Selecting the method of running the clone operation 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 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

249 Reorganizations in the Remote Database Backup Environment Structure Clone Under the ABW Mode Procedure 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. 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. 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

250 Reorganizations in the Remote Database Backup Environment Examples of Offline Reorganizations with Structure Clones Assume the following DASDL specification: DI DATA SET (F1 NUMBER (6); F2 NUMBER (7); F3 NUMBER (7); F4 ALPHA (6); F5 NUMBER (7); ); S1 SET OF D1 KEY F1; S2 SET OF D1 KEY F2; S3 SET 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 <secon dary pack name> FROM <dump name>"); RUN RECONSTRUCT/<database name>;

251 Reorganizations in the Remote Database Backup Environment Example 2 Add the following new set to the DASDL description: S4 SET OF D1 KEY F5; 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 S1 is a set, 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 <sec ondary 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

252 Reorganizations in the Remote Database Backup Environment 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. 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

253 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

254 Types of Recovery in the Remote Database Backup Environment 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 Reconstruct Copy from an offline dump 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. 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

255 Rebuild Recovery 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. 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

256 Rollback Recovery 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. 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

257 Halt/Load and Abort Recovery 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. 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

258 Halt/Load and Abort Recovery 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

259 Reconstruct Recovery 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

260 Reconstruct Recovery 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

261 Reconstruct Recovery 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

262 Copying Database Structures from an Offline Dump 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. 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

263 Restoring Lost or Corrupt Database Files 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

264 Restoring Lost or Corrupt Database Files 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. 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

265 Restoring Lost or Corrupt Database Files 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 DMSUPPORT library Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide RDB control file Section 5 Updating code file titles and structure locations Section

266 Restoring Lost or Corrupt Database Files

267 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

268 Finding the Information You Need 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 familiar administrative tasks, such as recovery, reorganization, backup, and analysis, from a Windows environment, as well as maintain database schemas

269 Finding the Information You Need 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 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 Topic 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

270 Secondary Database Functions 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: 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)

271 Hints for Successful Enterprise Application Environment Operations 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. 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

272 Hints for Successful Enterprise Application Environment Operations 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 Recovery Takeovers 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 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. 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 6. 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 Backup-capable 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

273 Hints for Successful Enterprise Application Environment Operations 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

274 Hints for Successful Enterprise Application Environment Operations

275 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-I/O timeout errors Updating and reorganization Failures with tape audit

276 Minimizing Problems 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. 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

277 Resolving Operational Problems with Database Operations Center 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 8. 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 communicati on 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. 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 in formation. 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

278 Resolving Operational Problems with Database Operations Center 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. Ret ransmit to enable the destination host. 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. Retrans mit 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

279 Resolving Operational Problems with Database Operations Center 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 (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

280 Resolving Operational Problems with Database Operations Center 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 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

281 Resolving Operational Problems with Database Operations Center 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. 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

282 Resolving Operational Problems with Database Operations Center 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. 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

283 Resolving Operational Problems with Database Operations Center The following message appears: The RDB control file on the secondary host may be corrupt. You should qui t 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 NO 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. 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

284 Resolving Operational Problems with Database Operations Center 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

285 Resolving Takeover Problems 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: 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-primary-database 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-primary-database 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

286 Resolving Takeover Problems Step Action 5 Clone the database. 6 Perform the following optional actions: a. Determine the extent of lost transactions, if any. b. 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). 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

287 Resolving Takeover Problems 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 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

288 Resolving Primary Database Problems 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

289 Resolving Primary Database Problems 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. 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 error-handling 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 >

290 Resolving Primary Database Problems 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 error-handling routine to handle the result of the open operation. To retry the operation immediately, enter AX RETRY or AX RETRY 0. 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. 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

291 Resolving Primary Database Problems 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, 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 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

292 Resolving Secondary Database Problems 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. 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

293 Resolving Secondary Database Problems 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 Situation A manual recovery at the primary host, such as a rebuild or rollback, can result in the removal of audit records from the audit trail. If the audit records that were removed have already been applied to the secondary database, the secondary database requires a reclone operation. 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

294 Resolving Secondary Database Problems 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: DMOPENERROR 73 Situation Move the DMSUPPORT library to the pack designated in the database control file. Run SYSTEM/DMCONTROL to change the DMSUPPORT library pack location. 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)

295 Resolving Secondary Database Problems 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: 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

296 Resolving Secondary Database Problems 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.) 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

297 Resolving Secondary Database Problems NO FILE <database name>/control Message Situation The system displays the following message: <mix number> NO FILE <database name>/control ON <primary database control fi le 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>)

298 Resolving Secondary Database Problems 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 Solution Recompile the program on the secondary host

299 Resolving Secondary Database Problems 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

300 Reestablishing Synchronization 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: Initiation by the primary database An inquiry program

301 Reestablishing Synchronization 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

302 Resolving Tracker Problems 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

303 Resolving Tracker Problems 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: 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 Images 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

304 Resolving Tracker Problems NO FILE Condition Under the SCA and 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 with a NO FILE condition on the absent audit file. Solution Perform the following procedure. 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 with a NO FILE condition on 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

305 Resolving Miscellaneous Problems 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. 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

306 Resolving Port-I/O Timeout Errors Resolving Port-I/O Timeout Errors 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. 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

307 Resolving Port-I/O Timeout Errors 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. 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

308 Resolving Port-I/O Timeout Errors 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

309 Resolving Port-I/O Timeout Errors 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. 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

310 Resolving Port-I/O Timeout Errors 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 Nonusercoded Database Situation When opening a nonusercoded database, 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

311 Resolving Updating and Reorganization Problems 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: <structure name>/fixup on DISK (or other pack name) One of the following actions has occurred: 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

312 Resolving Updating and Reorganization Problems 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. 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

313 Resolving Updating and Reorganization Problems 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. 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

314 Resolving Tape Audit Failures 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. 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

315 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

316 Establishing the Link to the RDB Support Library 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>";

317 Using the Takeover Entry Point 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

318 Using the Takeover Entry Point 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. 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

319 Using the Takeover Entry Point 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. 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]

320 Using the Takeover Entry Point 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])

321 Using the Takeover Entry Point Description of PARAMS Array Information The values returned in each field of the PARAMS array are explained in the following table. Field VERSION_WORD WARNINGS RECLONE STCLONE DS ALREADY_PRIMARY BNA_DOWN 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

322 Using the Takeover Entry Point Field OVERRIDE_REQD WARN_HOST Explanation 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. 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. OVERRIDE_OK OPTIONS 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

323 Using the Takeover Entry Point Field IMMEDIACY WARN_HOSTNAME (A) WARN_HOSTNAME_LEN P_WARN_HOSTNAME_TEXT OLTP_DB Explanation 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. 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

324 Using the Takeover Entry Point 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. 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

325 Using the Takeover 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] #,

326 Using the Takeover Entry Point 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 = #; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 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

327 Using the Takeover Entry Point 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 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

328 Using the Takeover Entry Point 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 ELSE DONE:= TRUE; END; END UNTIL DONE; EOT: END

329 Using the RDB_INFO Entry Point 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 Monitor 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;

330 Using the RDB_INFO Entry Point 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. 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 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 this word contains one of the following two values 1 = NFT transfer 2 = FTRapid transfer 7 Primary host audit file number 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. POINTER (RDBINFO[10] +1 is the secondary host name represented in 8-bit EBCDIC characters

331 Using the RDB_INFO Entry Point Word Contents Description 13 Secondary host audit transmission mode This word contains one of the following five values: 0 = NSC mode 1 = ABW mode 2 = AFS mode 3 = SCA mode 4 = AFM mode 14 Secondary host audit transmission mode option For ABW mode this word contains one of the following two values: 1 = Drop 2 = Operator intervention For AFS mode this word contains one of the following two values 1 = NFT transfer 2 = FTRapid transfer 15 Secondary host audit file number This word contains the most recent audit file number received and written at the secondary host. 16 Secondary host ABSN number This word contains the most recent audit block serial number received and written at the secondary host. 17 Secondary host ABSN timestamp 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 This word contains the audit block serial number containing the last applied control record to the secondary database. 22 Tracker control record timestamp 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. 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

332 Using the RDB_INFO Entry Point Word Contents Description 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. 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)

333 Using the RDB_INFO Entry Point 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);

334 Using the GET_PRIMARY_MODE Entry Point 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 PERPERTIES = "*DATABASE/PERPERTIES" 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. Example GET_PRIMARY_MODE Application Program Text $ INCLUDE PROPERTIES = "*DATABASE/PERPERTIES" û LIBRARY RDBSUPPORT (LIBACCESS = BYFUNCTION, FUNCTIONNAME = "RDBSUPPORT.");

335 Using the GET_PRIMARY_MODE Entry Point 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 Accessing cumulative Remote Database Statistics Interpreting Remote Database Statistics Section 7 Section 7 Section

336 Using the SET_RDB_MODE Entry Point 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 GET_RDB_MESSAGE (RSLT, MSG); VALUE WHICH HOST, AUDITMODE, MODEOPT; REAL WHICH HOST, % RDB_PRIMARYV = 2 : from primary -> secondary % RDB_SECONDARY = 1 : from secondary -> primary AUDITMODE, % NSC_MODE = 0 % ABW_MODE = 1 % AFS_MODE = 2 % SCA_MODE = 3 % AFM_MODE = 4 MODEOPT; % if AUDITMODE = ABW_MODE (default = ABW_DROP_V) % ABW_DROP_V = 1 AFS_RAPID_V = 2 % if AUDITMODE = AFS_MODE (default = AFS_NFT_V) 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 := SET_RDB_MODE(RDB_PRIMARYV, ABW_MODE, ABW_DROP_V)

337 Using the SET_RDB_MODE Entry Point 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") DISPLAY ("MODE SWITCH WILL OCCUR AT THE NEXT AUDIT FILE SWITCH"); END; END. Result Values of the SET_RDB_MODE Entry Point Procedure The following table shows the audit transmission mode result values that are returned by the SET_RDB_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) 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. 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

338 Using the SET_RDB_MODE Entry Point 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

339 Using the SET_RDB_MODE Entry Point 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. 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. 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

340 Using the SET_RDB_MODE Entry Point Example SET_RDB_MODE Application Program Text BEGIN BOOLEAN PROCEDURE SET_RDB_MODE (WHICH_HOST, AUDITMODE, MODEOPT); VALUE WHICH HOST, AUDITMODE, MODEOPT; REAL WHICH_HOST, % RDB_PRIMARYV = 2 : from primary -> secondary % RDB_SECONDARYV = 1 : from secondary -> primary AUDITMODE, % NSC_MODE = 0 % ABW_MODE = 1 % AFS_MODE = 2 % SCA_MODE = 3 % AFM_MODE = 4 MODEOPT; % if auditmode = ABW_MODE (default = ABW_DROP_V) % ABW_DROP_V = 1 ABW_OPERATOR_V = 2 % if auditmode = AFS_MODE (default = AFS_NFT_V) % AFS_NFT_V = 1 AFS_RAPID_V = 2 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,RODEOPT); 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() NEQ ABW_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

341 Using the SET_RDB_MODE Entry Point 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"); 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"); 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 Setting up audit transmission modes Using AFS mode with a nonusercoded database Enterprise Database Server Utilities Operations Guide Sections 2, 3, and 5 Section

342 Using the GET_RDB_MESSAGE Entry Point 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 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; 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

343 Using the GET_RDB_MESSAGE Entry Point 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

344 Using the GET_RDB_MESSAGE Entry Point

345 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. ACKNOWLEDGEMENT accepts an AUDIT FILE NUMBER as input and performs a Remote Database Backup ACKNOWLEDGEMENT 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 a 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

346 SYSTEM/RDBOPS <ops command> INITIALIZE MODIFY ENABLE DISABLE ACKNOWLEDGEMENT <audit file number> OVERRIDE TAKEOVER <new primary host name> OVERRIDE STATUS The following table describes the elements of the <ops command> syntax diagram: Option INITIALIZE MODIFY ENABLE DISABLE ACKNOWLEDGEMENT TAKEOVER STATUS 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. This task acknowledges receipt of audit files at the secondary host. The OVERRIDE option enables the task to continue without confirmation following warning messages. This task performs a Remote Database Backup takeover. The new primary host must be input. 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

347 SYSTEM/RDBOPS Related Information Topics For information about... Refer to... INITIALIZE task ENABLE task Section 5 TAKEOVER task Section 6 MODIFY task DISABLE task ACKNOWLEDGEMENT task Section 8 STATUS task Section 7 <db statement> Utilities Operations Guide The following figure is an image of the TEMPLATE/RDB/CONFIG file that is used to create a CONFIG file for input to the 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/RDB/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"); % 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:

348 SYSTEM/RDBOPS DB_NAME <database name> CF_USERCODE <usercode> OR * 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> % <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> 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: % 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 =

349 SYSTEM/RDBOPS SEC_AFS_TRANSFER 1 % <file transfer option> % <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> % END OF CONFIG FILE INPUT % % Example CONFIG file used as input to SYSTEM/RDBOPS: % % 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 10 % 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 NFT % <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 % 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>

350 SYSTEM/RDBOPS Examples: % 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 image of the TEMPLATE/RDB/CONFIG file 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 = RDB/CONFIG/INIT/PRODDB ON DBPACK Example 2: To enable the RDB capability, execute the following command: RUN SYSTEM/RDBOPS("DB=(PROD)PRODDB ON DBPACK ENABLE") Example 3: To modify a Remote Database Backup system configuration, complete a CONFIG file and save it as RDB/CONFIG/MODIFY/PRODDB ON DBPACK: RUN SYSTEM/RDBOPS("DB=(PROD)PRODDB ON DBPACK MODIFY"); FILE CONFIG = RDB/CONFIG /MODIFY/PRODDB ON DBPACK 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")

351 SYSTEM/RDBOPS 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 HOSTDR OVERRIDE") Example 7: To access dynamic status and statistical information, execute the following command: RUN SYSTEM/RDBOPS("DB=(PROD)PRODDB ON DBPACK STATUS")

352 SYSTEM/RDBOPS

353 Appendix A Sample Clone WFL Job In This Appendix This appendix contains a sample WFL job for a full clone operation A 1

354 Sample Full Clone WFL Job Sample Full Clone WFL Job The following code is a sample full clone WFL job for a database named RDB. 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. BEGIN JOB CLONEDB/RDB; INTEGER JOBNUM, JOBNUMORZERO; BOOLEAN DMCONTROLUPDATED; TASK T; 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 % 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 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 A

355 Sample Full Clone WFL Job 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 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 Enterprise Database Server on the primary system are being cr eated 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]; A 3

356 Sample Full Clone WFL Job 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, 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. 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

357 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 B 1

358 System Resource Description Form System Resource Description Form Network node name Site location Style, model Memory Database disk configuration Communications processors Name Date B

359 Database Description Form Database Description Form Database name Primary host Secondary host DASDL options DASDL parameters Name Date B 3

360 Primary Host Database Applications List Form Primary Host Database Applications List Form Database name Application names Critical update Critical report Noncritical update Noncritical report Name Date B

361 Primary Host Nondatabase Applications List Form Primary Host Nondatabase Applications List Form Application names Critical Noncritical Name Date B 5

362 Secondary Host Applications List Form Secondary Host Applications List Form Application names Critical Noncritical Name Date B

363 Network Description Form Network Description Form Network Component Model Capacity Existing Utilization Utilization with Remote Database Backup Name Date B 7

364 Audit Generation Rate Form 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

365 Applications Activity Form Applications Activity Form B 9

366 Applications Activity Form B

367 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 C 1

368 Tools to Measure Database Activity 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. 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. C

369 Tools to Measure Database Activity 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: 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 C 3

370 Tools to Measure Database Activity 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) Figure C 1. Sample Output from the AUDIT ANALYZE AFN Command (Part 1) C

371 Tools to Measure Database Activity Figure C 1. Sample Output from the AUDIT ANALYZE AFN Command (Part 2) C 5

372 Tools to Measure Database Activity Related Information Topics 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 C

373 Tools to Obtain an Audit Generation Rate 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 statistics-gathering period. Frequent use of short statistics-gathering intervals is required to identify peak periods of audit generation. AUDIT ANALYZE AFN Command Refer to the explanation and example of the AUDIT ANALYZE AFN command earlier in this appendix C 7

374 Tools to Obtain an Audit Generation Rate 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. C

375 Tools to Obtain an Audit Block Size 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 Enterprise Database Server statistics PRINTAUDIT program Enterprise Database Server Utilities Operations Guide Enterprise Database Server Utilities Operations Guide C 9

376 Tools to Obtain an Audit Block Size C

377 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 D 1

378 Operational Considerations for Mirrored Audit 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 Server1. There is a spare disk, SPARE1, available to either Server1 or Server2. A physically mirrored copy of D1 is read by the Remote Database Backup system at Server2 and is called D2. D

379 Operational Considerations for Mirrored Audit Figure D 1. Remote Database Backup System Environment and How It Works with Disk Subsystems D 3

380 Operational Considerations for Mirrored Audit 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. To configure the EMC source and target disks, perform the following steps. Step Action 1 Ensure that mirroring of both source and target disks within the EMC disk subsystem is functioning properly with established Symmetrix Remote Data Facility (SRDF) links. You can verify this through the EMC ControlCenter (ECC). 2 If the disk family has shared status, you need to disable this status. Enter the following operator display terminal (ODT) command on the source host: SHARE - <family name> 3 Enter the following ODT command on the source host to specify the name of the new pack: RC PKnn NAME <new name> OLDNAME <old name> For the variable nn, use the pack unit number. 4 Enter the following ODT command on the target host to specify the name of the new pack. Use the same <new name> parameter that you used in step 3. RC PKnn NAME <new name> OLDNAME <old name> For the variable nn, use the pack unit number. The pack unit numbers nn for both hosts in steps 3 and 4 are the matched pack units that are mirrored through the SRDF disk subsystem. For example, PKnn at the source host in step 3 is mirrored to PKnn at the target host in step 4. 5 If you encounter a WRITE LOCKOUT error on the target host, the target host pack needs to be made write capable. To make this pack write capable, enter MODE PKnn IO For the variable nn, use the pack unit number. D

381 Operational Considerations for Mirrored Audit In order for both hosts to share the same pack, you must activate the SHARE disk option as follows. Step Action 1 On the target host, enter the following command: CLOSE PKnn Then, enter FREE PKnn For the variable nn, use the pack unit number. 2 On the source host, enter the following command: FAMILYACCESS LOCAL <family name> Then, enter SHARE + <family name> LEVEL = 2 3 Enter the following ODT command on the target host: ACQUIRE PKnn For the variable nn, use the pack unit number. To test the host and to ensure that the SHARE disk option in conjunction with the EMC mirroring capability is working properly, perform the following steps on each host. Step Action 1 Copy a file to the source disk using CANDE. Within an EMC disk subsystem, the source disk is the disk that is configured as a mirrored source using the SRDF. This disk is read/write capable. 2 Verify that the same file is present on the target disk. 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. 3 Remove the file from the source disk. 4 Verify that the file is also removed from the target disk D 5

382 Operational Considerations for Mirrored Audit Recovering from a Corrupted Pack Label on Target Packs The target disk on the target host is read-only capable until a target takeover is executed through the EMC ControlCenter (ECC). Therefore, attempting to write to a target disk can cause the pack label to become corrupted. This corruption causes the host not to recognize this pack unit. If the label becomes corrupted, terminate all applications accessing the pack with the corrupted label. Then enter the following commands on the target host to restore the original pack label: CLOSE PKnn FREE PKnn ACQUIRE PKnn Changing Audit File Transmission Modes Changing the Audit File Transmission Mode from ABW to AFM To change the audit file transmission mode from ABW to AFM, perform the following steps. Step Action 1 Synchronize the audits and databases at both hosts. 2 Close the databases at both hosts. 3 Run the SYSTEM/DMCONTROL program at both hosts to perform the family name change. Then run Database Operations Center to record the family name change of each host. 4 Use the COPYAUDIT file to copy the current audit file to the new location on the primary as well as the secondary host. The audit file should then be removed from the old location at both hosts. 5 Resume database activity. D

383 Operational Considerations for Mirrored Audit Changing the Audit File Transmission Mode from AFM to ABW To change the audit file transmission mode from AFM to ABW, perform the following steps. Step Action 1 Ensure that the databases on both hosts are synchronized. 2 Close the databases at both hosts. 3 Run the SYSTEM/DMCONTROL program at both hosts to perform the family name change. Then run Database Operations Center to record the family name change for each host. 4 Use the COPYAUDIT file to copy the current audit file to the new location on the primary as well as the secondary host. The audit file should then be removed from the old location at both hosts. 5 Resume database activity. Changing the Audit File Transmission Mode from AFS to AFM To change the audit file transmission mode from AFS to AFM, perform the following steps. Step Action 1 Close the databases at both hosts. 2 Synchronize the audit files and databases at both hosts by copying the current partial audit file from the primary host to the secondary host. Run Database Operations Center to initiate an audit file acknowledgment. 3 Run the SYSTEM/DMCONTROL program at both hosts to perform the family name change. Then run Database Operations Center to record the family name change of each host. 4 Copy the current audit file to the new mirrored location at the primary host. 5 Run the Database Operations Center to change the mode to AFM. 6 Resume database activity D 7

384 Operational Considerations for Mirrored Audit Changing the Audit File Transmission Mode from AFM to AFS To change the audit file transmission mode from AFM to AFS, perform the following steps. Step Action 1 Ensure that the databases on both hosts are synchronized. 2 Close the databases at both hosts. 3 Run the SYSTEM/DMCONTROL program at both hosts to perform the family name change. Then run Database Operations Center to record the family name change of each host. 4 Use the COPYAUDIT file to copy the current audit file to the new location on the primary as well as the secondary host. The audit file should then be removed from the old location at both hosts. 5 Run Database Operations Center to change the mode to AFS. 6 Resume database activity. Changing the Audit File Transmission Mode from SCA to AFM To change the audit file transmission mode from SCA to AFM, perform the following steps. Step Action 1 Close the databases at both hosts. 2 Copy all audit files from the primary host to the secondary host if the files are not present on the secondary host. 3 Perform an audit file acknowledgment of the current audit file on the secondary host to synchronize the databases on both hosts. 4 Run the SYSTEM/DMCONTROL program at both hosts to perform the family name change. Then run Database Operations Center to record the family name change of each host. 5 Copy the current audit file to the new mirrored location at the primary host. 6 Resume database activity. Disabling the Remote Database Backup System When Remote Database Backup is configured in AFM mode followed by an RDB DISABLE or RESTORE operation that results in Remote Database Backup being in a DISABLE state, perform the following tasks at the remote host: Step Action 1 Discontinue (DS) the running database. 2 Remove the database control file. 3 Remove the TRACKERINFO file. D

385 Operational Considerations for Mirrored Audit Performing a Planned Takeover in AFM Mode Performing a planned takeover in AFM mode is significantly different from performing a planned takeover in other Remote Database Backup audit transfer modes because the takeover is not completely automatic. Instead, certain manual steps must be performed. The following steps are necessary to successfully perform a planned takeover in AFM mode. Step Action 1 Close the databases on both hosts, and synchronize the databases. 2 Verify that Tracker is not running at the secondary host. 3 Ensure that the transfer mode from the current secondary host to the current primary host is SCA or AFM. This action is necessary because after a takeover the reverse mirroring of the EMC disk subsystem is not available and therefore the source pack cannot mirror audits in reverse direction. 4 Set up the packs on both hosts as follows: a. Perform a target takeover on the source disk, which contains audits from the primary database. Perform this takeover using the EMC ControlCenter (ECC) that has Symmetrix Manager running on it. As a result of the takeover, the source disk becomes read-only capable, and the target disk becomes read/write capable. b. Enter both of the following ODT commands at the source (primary) host: CLOSE PKnn FREE PKnn Note: The source host is a ClearPath host that is attached to a source disk of an EMC disk subsystem in an SRDF environment. The variable nn represents the pack unit number of the source disk that contains the primary audits. If you use the ODT command P PK, you cannot see the source pack at the primary host. The source pack becomes visible again when you enter the ODT command ACQUIRE. c. Enter the following ODT command at the target (secondary) host: SHARE TAKEOVER <target pack name> Note: A target host is a ClearPath host that is attached to a target disk of an EMC disk subsystem in an SRDF environment. The target pack name is the pack, or family name, that contains mirrored audits on the secondary host. d. Enter the following ODT command at the target (secondary) host for a task related to a shared takeover that is in the waiting entry: <mix number> OK The mix number is associated with a job name called Job SHARE TAKEOVER family name. The family name is the target pack name or source pack name, depending upon the pack for which the SHARE TAKEOVER command is issued. The following message appears at the target (secondary) host: <target host name> is now the master host for family <target pack name> D 9

386 Operational Considerations for Mirrored Audit Step Action 5 Perform a takeover from either the primary or the secondary host using Database Operations Center. Note: If the transfer mode between the new target (primary) host and the new source (secondary) host is AFM, the following occurs. As soon as you perform a planned takeover using Database Operations Center, Tracker displays the message REQUIRES PK <audit pack name> <audit file> on the source (secondary) host. Tracker waits for the audit pack on the new secondary host until you restore the original Remote Database Backup configuration through another takeover. 6 Update the new target (primary) host in SCA or AFM mode. During this SCA or AFM mode processing, the new source (secondary) database is unaffected. You can keep updating the new target (primary) database until you decide to restore the original Remote Database Backup configuration. This restoration procedure is discussed later in this appendix. Restoring the Original Remote Database Backup Configuration Following a Planned Takeover After a planned takeover, the old source (primary) database falls behind as the new target (primary) database is updated. This occurs because no reverse mirroring is available within the SRDF system. Another planned takeover is necessary to restore the original Remote Database Backup host configuration. You must complete the following procedures to restore the original Remote Database Backup configuration: Perform a disk reconfiguration. Synchronize the databases on both hosts. Perform a planned takeover. D

387 Operational Considerations for Mirrored Audit Performing a Disk Reconfiguration The following steps describe how to perform a source (secondary) host takeover. Step Action 1 Close the new target (primary) database. 2 Set up the packs on both hosts as follows: a. Perform a source takeover on the source disk, which contains audits from the old primary database. Perform this takeover using the EMC ControlCenter (ECC) that has Symmetrix Manager running on it. As a result of the takeover, the source disk becomes read/write capable, and the target disk becomes read-only capable. The communication link status between the volumes changes to the ready condition. The source takeover through the EMC ControlCenter (ECC) resumes synchronization of both the target and source packs. Wait for synchronization of the packs to complete. b. Enter both of the following ODT commands at the target (primary) host: CLOSE PKnn FREE PKnn The variable nn represents the pack unit number of the new target (primary) disk that contains the current primary audits. c. Enter the following ODT command at the source (secondary) host: ACQUIRE PKnn The variable nn represents the pack unit number of the source disk that contains the old primary audits. In AFM mode, as soon as the ACQUIRE command is complete, Tracker starts processing the audits on the pack and applies them to the secondary database. d. Enter the following ODT command at the source (secondary) host: SHARE TAKEOVER <source pack name> The source pack name is the pack, or family name, on the source host that contains audits. e. Enter the following ODT command at the source (secondary) host: <mix number> OK The following message appears at the source (secondary) host: <source host name> is now the master host for family <source pack name> 3 Enter the following ODT command at the new target (primary) host: ACQUIRE PKnn The variable nn represents the pack unit number containing the current primary audits D 11

388 Operational Considerations for Mirrored Audit Synchronizing the Databases on Both Hosts Before performing a takeover using Database Operations Center, you must synchronize the databases on both hosts. The synchronization for the source and target packs is complete, but the secondary audits need to be applied to the database. Two types of synchronization methods are allowed: the Tracker-only method and the clone-only method. Tracker-Only Method The Tracker-only method can be performed using the SCA or the AFM mode. In SCA mode, ensure the current audits are in the database. Then perform an audit file acknowledgment of the current audit file on either the primary or secondary host. In AFM mode, ensure the current audits are in the database. It is not necessary to perform an audit file acknowledgment on the current audit file. As soon as the ACQUIRE command completes, Tracker automatically processes the audits on the pack and applies them to the secondary database. Clone-Only Method Use the following steps to perform the clone-only method. Step Action 1 Perform an offline dump of the new target (primary) database. 2 Reclone the source (secondary) database from the target (primary) database dump. This step synchronizes both databases. Performing a Planned Takeover With both databases closed and synchronized, the takeover can be performed from either the target (primary) or source (secondary) host using Database Operations Center. Step Action 1 Start updating the new target (primary) database. 2 Open the database on the new source (secondary) host. This action brings up Tracker on that host. At this point you have recovered the original Remote Database Backup configuration and have started processing in AFM mode. D

389 Operational Considerations for Mirrored Audit Performing an Unplanned Takeover in AFM Mode A situation might occur in which the primary database becomes corrupted in AFM mode. If this corruption occurs, you must perform a takeover to continue processing using the new primary database. Step Action 1 Perform a takeover using Database Operations Center. 2 If Database Operations Center displays the following message, enter Y: <database name> is open update on <primary host name> and will be terminate d if you choose to continue - <Y> This action causes the primary database and all application programs to abort. The Tracker on the secondary host continues to run. 3 Set up the packs on both hosts as follows: a. Enter both of the following ODT commands at the source (primary) host: CLOSE PKnn FREE PKnn The variable nn represents the pack unit number of the source disk that contains the primary audits. If you use the ODT command P PK, you cannot see the source pack at the primary host. The source pack becomes visible again when you enter the ODT command ACQUIRE. b. Enter the following ODT command at the target (secondary) host: SHARE TAKEOVER <target pack name> The target pack name is the pack, or family name, that contains mirrored audits on the secondary host. c. Enter the following ODT command at the target host for a task related to a shared takeover that is in the waiting entry: <mix number> OK The mix number is associated with a job name called Job SHARE TAKEOVER <family name>. The family name is the target pack name or source pack name, depending upon the pack for which the SHARE TAKEOVER command is issued. The following message appears at the target (secondary) host: <target host name> is now the master host for family <target pack name> 4 Update the new target (primary) host in SCA or AFM mode. During this SCA or AFM mode processing, the new secondary host is unaffected because of the absence of audit transfer to the secondary host and because of the absence of reverse mirroring capability through the SRDF system. You can continue updating the new target (primary) database until you decide to restore to the original Remote Database Backup configuration. (The restoration procedure is discussed later in this appendix.) D 13

390 Operational Considerations for Mirrored Audit Restoring the Original Remote Database Backup Configuration Following an Unplanned Takeover After an unplanned takeover, the old source (primary) database falls behind as the new target (primary) database is updated. This occurs because no reverse mirroring is available within the SRDF system. A planned takeover is necessary to restore the original Remote Database Backup host configuration. You must complete the following steps to restore the original Remote Database Backup configuration: Perform a disk reconfiguration. Synchronize the databases on both hosts. Perform an unplanned takeover. D

391 Operational Considerations for Mirrored Audit Performing a Disk Reconfiguration The following steps describe how to perform a source (secondary) host takeover. This is performed through ECC to synchronize the mirrored audit packs. Step Action 1 Close the new target (primary) database. 2 Set up the packs on both hosts as follows: a. Perform a source takeover on the source disk, which contains audits from the old primary database. Perform this takeover using the EMC ControlCenter (ECC) that has Symmetrix Manager running on it. As a result of the takeover, the source disk becomes read/write capable, and the target disk becomes read-only capable. The communications link status between the volumes changes to the ready condition. The source takeover through the EMC ControlCenter (ECC) resumes synchronization of both the target and source packs. Wait for synchronization of the packs to complete. b. Enter both of the following ODT commands at the target (primary) host: CLOSE PKnn FREE PKnn The variable nn represents the pack unit number of the new target (primary) disk that contains the current primary audits. c. Enter the following ODT command at the source (secondary) host: ACQUIRE PKnn The variable nn represents the pack unit number of the source disk that contains the old primary audits. In AFM mode, Tracker starts processing the audits on the pack and applies them to the secondary database. d. Enter the following ODT command at the source (secondary) host: SHARE TAKEOVER <source pack name> The source pack name is the pack, or family name, on the source host that contains audits. e. Enter the following ODT command at the source (secondary) host: <mix number> OK The mix number is associated with a job name called Job SHARE TAKEOVER <family name>. The family name is the target pack name or source pack name, depending upon the pack for which the SHARE TAKEOVER command is issued. The following message appears at the source (secondary) host: <source host name> is now the master host for family <source pack name> 3 Enter the following ODT command at the new target (primary) host: ACQUIRE PKnn The variable nn represents the pack unit number containing the current primary audits D 15

392 Operational Considerations for Mirrored Audit Synchronizing the Databases on Both Hosts Before performing a takeover using Database Operations Center, you must synchronize the databases on both hosts. The synchronization for the primary and secondary packs is complete, but the secondary audits need to be applied to the database. Two types of synchronization methods are allowed: the Tracker-only method and the clone-only method. Tracker-Only Method In SCA mode, ensure the current audits are in the database. Then perform an audit file acknowledgment of the current audit file on either the primary or secondary host. Tracker becomes present on the source (secondary) host and the DMRECOVERY program is invoked. This program starts because, prior to the first unplanned takeover, the original primary database aborted in the transaction state. Tracker waits until the halt/load recovery process completes. If the DMRECOVERY program runs into problems and aborts with a failed to synchronize audits message, use the clone-only method to synchronize the databases. Clone-Only Method Use the following steps to perform the clone-only method. Step Action 1 Perform an offline dump of the new target (primary) database. 2 Reclone the source (secondary) database from the target (primary) database dump. This step synchronizes both databases. Performing an Unplanned Takeover With both databases closed and synchronized, the takeover can be performed from either the target (primary) or source (secondary) host using Database Operations Center. Step Action 1 Start updating the new source (primary) database. 2 Open the database on the new target (secondary) host. This action brings up Tracker on that host. At this point you have recovered the original Remote Database Backup configuration and have started processing in AFM mode. D

393 Index A abort recovery, 10-2, 10-5, 10-6 recovery process, 10-5 aborted reorganization, 9-13 ABSN (See audit block serial number) ABW mode, 2-2 acknowledgment rates, 2-3 ACR server task during audit file transmission, 4-22 automatic audit synchronization process, 4-25 Catchup and Catchup-server under, 4-16 Catchup fails to run after change from SCA mode, characteristics, 2-2 description, 4-21 Catchup process, 4-24 port-i/o timeout value for, 4-23 when the primary database opens for update, 4-23 duplicate audit files and, 2-18 effect on synchronization level, 1-16 error-handling options, 2-4 Drop the secondary, 2-6 impact on system resources, 3-9 Operator intervention, 2-7 errors during audit file transmission description, 2-4 some causes of errors, 2-4 estimating future network utilization with Remote Database Backup, 3-24 flow of audit block images under (figure), 4-21 goal of, 2-2 impact on resources, 2-17 audit block acknowledgments and, 2-17 measuring network utilization rate, 3-25 preliminary measurements for existing network utilization, 3-19 processing DASDL updates under, 9-4 sectioned audit files, 4-14 structure clone, 9-27 Tracker does not run after a successful clone operation, using alternately with AFS mode, 2-15 using alternately with other modes, 2-15 accessing cumulative Remote Database Backup statistics, 7-10 effect of start time on statistics, 7-11 explanation of Remote Database Backup statistical information, 7-11 purpose of Remote Database Backup statistics, 7-10 when Remote Database Backup statistics are updated, 7-11 when to access Remote Database Backup statistics, 7-10 current state of audit transfers, 7-5 Remote Database Backup report information, 7-5 database statistics on Remote Database Backup performance, 7-16 messages, 7-4 immediate feedback on system functioning, 7-4 secondary database, 4-38 ACKNOWLEDGEMENT command, 14-2 acknowledging audit files acknowledgment task, 8-5 acknowledgment, description of, 8-4 audit file number (AFN) to acknowledge, 8-5 circumstances under which manual acknowledgment is needed, 8-4 acknowledgment rates, 2-3 ACR server task, 4-11 under ABW mode, 4-22 ACR_PORT port file audit synchronization process and, 4-25 characteristics of, 4-20 under ABW mode, 4-21 adding new structures data set and its associated sets, 9-8 set to an existing data set, Index 1

394 Index subset to an existing data set, 9-9 AFM mode, 2-8 audit file copy and removal, 2-8 effect on synchronization level, 1-14, 1-16 performing an unplanned takeover, D-13 requirements, 2-8 AFN (audit file number), 7-7, 8-5 AFS mode, 2-11 duplicate audit files and, 2-20 effect on synchronization level, 1-15, 1-16 file transfer products, 1-15, 1-16, 2-11 impact on resources, 2-20 manual synchronization of audit files under, 5-22 NFT failure, preliminary measurements for existing network utilization, 3-21 processing DASDL updates under, 9-5 procedure to use when the update level does not change, 9-6 procedure to use when the update level increases, 9-5 using alternately with ABW mode, 2-15 using alternately with other modes, 2-15 ALGOL declaration for takeover entry point, 13-4 example program for takeover entry point, ALREADY_PRIMARY subfield of PARAMS parameter, 13-7 ALTERNATE audit trail specification secondary host and, 4-31 application access to the secondary database, ensuring, 4-38 application phase of Tracker process, 4-42 application program, runs on the primary host but not on the secondary host, Applications Activity Form, B-9 applications, describing, 3-11 attribute error when catchup is running, AUDIT ANALYZE AFN command, C-2 as a tool for measuring resource utilization, 3-16, C-2, C-7 report generated from, C-3 sample output of (figure), C-4, C-5 audit block images, flow of under ABW mode (figure), 4-21 audit block serial number (ABSN), 7-7 current ABSN does not match received ABSN, valid audit block and, 4-26 audit block size calculating, 3-20 tools to obtain, C-9 audit block write mode (See ABW mode) audit block, valid for audit synchronization, 4-26 audit file copy and removal, 2-8 audit file mirror mode (See AFM mode) audit file number (AFN), 7-7, 8-5 audit file switch mode (See AFS mode) audit file transfer, stops at the secondary host, audit file transmission modes, 2-1, 2-10 (See also audit transmission modes) alternating between, 2-15 audit block write (ABW), 2-2 ACR server task, 4-22 Catchup and Catchup-server under, 4-16 audit file mirror (AFM), 2-8 audit file switch (AFS), 2-11 benefits in relation to resources, 2-19 Catchup fails to run after change from SCA to ABW, changing, 8-13 change apparently not successful, when the change takes effect, 8-14 degree of audit synchronization and (table), 1-16 description, 1-16 determining future network utilization for AFS, SCA, and NSC modes, 3-24 effect on synchronization level, 1-14 impact on resources, 2-19 not server capable (NSC), 2-14 risk to data under, 2-10 server capable (SCA), 2-13 audit files acknowledging acknowledgment task, 8-5 acknowledgment, description of, 8-4 audit file number (AFN) to acknowledge, 8-5 circumstances under which manual acknowledgment is needed, 8-4 actions if the audit pack on the primary host becomes full, 8-3 count of, C-8 duplicate in Remote Database Backup, 1-12 manual synchronization under AFS, SCA, and NSC modes, 5-22 received AFN value, 5-22 required by Tracker, 5-22 sectioned, 4-11, 4-14 audit synchronization, 4-26 Index

395 Index Catchup and, 4-17 port files and, 4-20 supplying those that Tracker requires, 5-23 audit generation rate calculating in bytes per second, 3-19, 3-22 messages per second, 3-20, 3-22 tools to obtain, C-7 Audit Generation Rate Form, B-8 AUDIT PROCESSOR TIMES command, C-2 as a tool for measuring resource utilization, C-2 sample output of (figure), C-5 when to use, C-2 Audit server task, 4-11, 4-14 audit synchronization (See also synchronization) ACR_PORT port file, 4-25 automatic, 4-25 conditions that initiate, 4-26 Catchup and Catchup-server and, 4-16, 4-25 definition of process, 4-25 sectioned audit files and, 4-26 Tracker and, 4-25 valid audit block definition, 4-26 audit trail automatic synchronization process, 4-25 secondary not synchronized, synchronization levels, 1-14 considerations, 1-18 effect during unplanned takeovers, 6-11 effect of audit file transmission modes on, 1-16 audit transfers, accessing the current state of, 7-5 audit transmission modes, 2-1 (See also audit file transmission modes) alternating between, 2-15 for disaster recovery, 3-8 options, 2-15 selecting to meet your goals, 3-8 audit transmission peak periods, handling, 2-20 audited database, requirement for Remote Database Backup, 1-12 audited reorganizations characteristics of, 9-18 procedure to apply to the secondary database, 9-22 procedure to manually transfer files, 9-24 procedure to perform, 9-20 automatic audit synchronization conditions that initiate, 4-26 for primary and secondary audit trails, 4-25 process for ABW mode, 4-25 what the process does, 1-17 automating a takeover, 13-3 Remote Database Backup operations, 13-2 average block size, calculating, 3-20 AX commands for Operator intervention error-handling option, 2-7 primary database program waits on, B basic Remote Database Backup hardware and software requirements, 1-12 block transmission mode impact on resources, 2-17 BNA_DOWN subfield of PARAMS parameter, 13-7 BUILDREORG utility open options EXCLUSIVE, 9-15 INQUIRYONLY, 9-15 OFFLINE, 9-15 PREVERIFY, 9-15 bytes per second, calculating audit generation rate in, 3-19, 3-22 C calculating audit block size, 3-20 audit generation rate in bytes per second, 3-19, 3-22 in messages per second, 3-20, 3-22 average block size, 3-20 optimal message size, 3-20 capabilities, Remote Database Backup-compatible databases, 1-4 capacity planning guidelines for network resources, 3-18 catchup attribute error received when running, Catchup, 4-16 as part of the audit synchronization process, 4-16, 4-25 CU_PORT port file and, Index 3

396 Index does not run after mode change from SCA to ABW, does not run after secondary host halt/load, flow of audit blocks (figure), 4-24 process under ABW mode, 4-24 sectioned audit files, 4-17 Catchup-server, 4-16 as part of the audit synchronization process, 4-16, 4-25 DMSUPPORT library location and, 4-31 changing audit file transmission modes, 8-13 audit transmission modes for mirrored audit, D-6 checking on the Remote Database Backup installation (See Remote Database Backup installation) clone operation, 5-15 availability of the secondary database for inquiry purposes after the clone operation, 5-18 database missing after, 12-6 DMSUPPORT library fails to initiate during, 12-6 full clone operation, 8-16 identifying pack names for database software files, 5-12 making the required database files available, 5-7, 8-16 methods of running, 5-16 advantages of creating a WFL job and saving it, 5-17 no response from RDBSERVER during, 12-8 providing the DMCONTROL and DMUTILITY code file titles, 5-15 selecting a method of running, 5-15, 8-18 factors affecting selection, 5-15 specifying dump information and pack names for database structures, 5-10, 8-17 specifying pack names for database guard files, 8-17 specifying pack names for database software files, 8-17 specifying the DMCONTROL and DMUTILITY code files, 8-17 starting the secondary database after, 5-21 Tracker does not run after successful operation under ABW mode, under ABW mode, Tracker does not run after successful, unexpected secondary host pack designations, 12-5 using a previous clone WFL job, 8-15 clone WFL job, 5-17 sample for full clone, A-2 using a previous clone WFL job, 8-15 cloning the database on the secondary host, 5-6, 5-15, 8-15 using a previous clone WFL job, 8-15 code files, file-searching order for finding, 4-36 communications errors, resolving frequent, communications processor utilization statistics, 3-24 components of a Remote Database Backup system, 1-4 configuration Remote Database Backup system examples multiple systems, 1-10 multiple systems with a single backup host, 1-9 one system, 1-7 two Remote Database Backup systems, 1-8 two systems, 1-11 configuration tasks, 5-2 (See also configuring a Remote Database Backup system; configuring a Remote Database Backup system, preparation for) cloning the database on the secondary host, 5-6 identifying pack names for database software files, 5-12 making the required database files available, 5-7 providing the DMCONTROL and DMUTILITY code file titles, 5-15 selecting a method of running the clone operation, 5-15 specifying dump information and pack names for database structures, 5-10 defining your Remote Database Backup system, 5-3 initializing the RDB control file, 5-3 enabling the Remote Database Backup system, 5-5 order of tasks, 5-2 verifying your Remote Database Backup system, 5-19 Index

397 Index configuring a Enterprise Application Environment database, primary sources of information for, 11-2, 11-3 configuring a Remote Database Backup system, 5-1 (See also configuration tasks; configuring a Remote Database Backup system, preparation for) order of tasks, 5-2 tasks, 5-2 cloning the database on the secondary host, 5-6 defining your Remote Database Backup system, 5-3 enabling the Remote Database Backup system, 5-5 verifying your Remote Database Backup system, 5-19 configuring a Remote Database Backup system, preparation for, 4-1 (See also configuration tasks; configuring a Remote Database Backup system) advantages of careful preparation, 4-2 tasks checking on the Remote Database Backup installation, 4-3 designating usercodes and packs, 4-34 ensuring database file availability on the secondary host, 4-38 integrating Remote Database Backup into your security setup, 4-27 manipulating the frequency of restart points, 4-44 overview, 4-2 port files, understanding, 4-19 preparing personnel to run the Remote Database Backup system, 4-30 Remote Database Backup software, understanding, 4-9 reviewing the DASDL source file, 4-31 setting the I/O timeout value for the ports, 4-40 configuring the replicated copy, 8-27 control record date and timestamp, 7-8 names of, 7-9 CONTROLPOINT option effect on Tracker restart points, 4-44 copy from an offline dump recovery, 10-2 copying database structures from offline dump, count of audit files, C-8 CU_PORT port file D characteristics, 4-20 fixed timeout value for, 4-40 DASDL descriptions, reviewing DMSUPPORT library, 4-31 guard files, 4-32 DASDL source file, reviewing, 4-31 importance of the DASDL source file to a Remote Database Backup system, 4-31 DASDL updates in the Remote Database Backup environment, 9-2 adding new structures, 9-8 data set and its associated sets, 9-8 set to an existing data set, 9-9 subset to an existing data set, 9-9 basic procedure, 9-2 processing under the ABW mode, 9-4 processing under the AFS, SCA, and NSC modes, when the update level does not change, 9-6 processing under the AFS, SCA, and NSC modes, when the update level increases, 9-5 replicating to the secondary host, conditions for, 9-3 data loss caused by disaster, 1-17 minimizing during disaster, 1-17 data set, adding a new, 9-8 database availability after a clone operation, 12-6 describing, 3-10 downtime, minimizing during disaster, 1-17 family locations, 10-12, partitioning structures in, 4-32 performing a takeover when corrupt, primary and secondary, working together under Remote Database Backup, 1-6 reorganizing in the Remote Database Backup environment, 9-1, 9-12 roles in a Remote Database Backup system, 1-5 statistics, generating, 7-16 updating in the Remote Database Backup environment, 9-1 database activity, tools to measure, C Index 5

398 Index Database Certification, runs on primary host but not on secondary host, Database Description Form, B-3 database equation for WFL job access to the secondary database, 4-38 database file availability on the secondary host, ensuring, 4-38 application access to the secondary database, ensuring, 4-38 dump of the primary database, providing, 4-39 specifying Enterprise Database Server code files in the DASDL source file, 4-38 Database Interpreter, runs on the primary host but not on the secondary host, <database name>/acr/portio, 4-14 <database name>/acrportio, 4-20 <database name>/audit/server, 4-11, 4-14 <database name>/catchup, 4-17 database name>/catchup/server/ <secondary host name>, 4-16 <database name>/rdb/agent, 4-16 <database name>/rdbsupport, 8-31 <database name>/tracker, 4-14 Database Operations Center, 4-9 troubleshooting, 12-3 database recovery, synchronization levels and, 1-17 database replication, 8-27 <database>/acrportio, 8-2 <database>/rdbsupport, 8-2 <database>/tracker, 8-2 dbatools, runs on primary host but not on secondary host, declaring RDB support library, 13-2 takeover entry point, 13-4 decrypting an encrypted dump tape, 4-39, 5-8, 8-16, 8-24 default job queue and nonusercoded databases, 4-5 defining your Remote Database Backup system, 5-3 initializing the primary and secondary hosts, 5-3 deleting the host information record for the secondary host, 8-12 describing applications, 3-11 databases requiring remote backup, 3-10 network resources, 3-11 system resources, 3-10 DISABLE command, 14-2 DISABLETRACKER option, 9-15 disabling the Remote Database Backup system, 8-27, 8-29 removing files from the secondary host after a disable operation, 8-30 taking a dump of the database after, 8-30 terminating secondary host tasks after a disable operation, 8-30 disabling Tracker, 8-19 checking Tracker status, 8-22 consequences, 8-19 difference between temporarily and permanently disabling Tracker, 8-20 DISABLETRACKER option during a reorganization, 9-15 procedure, 8-21 reasons for, 8-19 restarting Tracker after it has been permanently disabled, 8-22 after it has been temporarily disabled, 8-22 results of, 8-21 disaster as a relative term, 3-3 data loss, 1-17 database downtime, 1-17 recovery plan Remote Database Backup and, 1-4 disaster recovery aspects of, 3-4 assumptions about, 3-4 audit transmission mode options, 3-8 clarifying goals for, 3-4 situations where Remote Database Backup is useful, 3-5 discontinuing <database>/acrportio, 8-2 <database>/tracker, 8-2 SYSTEM/RDBSUPPORT, 8-2 DMCONTROL code file title, providing on the secondary host, 5-15 DMOPENERROR 0, DMOPENERROR 37, update level mismatch, DMOPENERROR 66, 12-16, DMOPENERROR 67, 12-7 DMOPENERROR 73, DMRECOVERY program, 10-5 Index

399 Index DMSUPPORT library, 4-31 failing to initiate during a clone operation, 12-6 location, Catchup-server and, 4-31 DMUTILITY code file title, providing on the secondary host, 5-15 DMUTILITY COPY command, DMUTILITY program, 10-7 Drop the secondary error-handling option description, 2-6 DS subfield of PARAMS parameter, 13-7 dump offline, of the secondary database, preparing for, 8-24 specifying information for on the secondary host, 5-10 DUMPDIR, runs on the primary host but not on the secondary host, duplicate audit files, 1-12 ABW mode and, 2-18 AFS mode and, 2-20 duplicate primary database, recovering from, E effects of the open options on database availability, 9-15 EMC mirrored audit operational considerations, D-1 source disk, D-4 source host, D-4 target disk, D-4 target host, D-4 EMC mirrored disks setting up shared disks on ClearPath hosts for, D-4 ENABLE command, 14-2 enable operation, not completing, 12-3 enabling the Remote Database Backup system, 5-5 Enterprise Application Environment Remote Database Backup facility, 11-6 Enterprise Application Environment, using in a Remote Database Backup environment, 11-1 configuring the Enterprise Application Environment database, primary sources of information for, 11-2, 11-3 database compatibility with Remote Database Backup, 1-4 hints for successful Enterprise Application Environment operations in a Remote Database Backup environment, 11-5 changing audit transmission modes, 11-5 cloning large databases, 11-5 pack mappings, 11-5 preventing update programs from accessing the secondary database, 11-6 recovery, 11-6 takeovers, 11-6 usercodes and passwords, 11-6 using the Enterprise Application Environment Remote Database Backup capabilities, 11-7 secondary database functions, 11-4 disaster recovery, 11-4 inquiry programs, 11-4 Enterprise Database Server code files, specifying in the DASDL source file, 4-38 Enterprise Database Server statistics report as tool to obtain audit block size, C-9 audit generation rate, C-7 entry point calling for a takeover, 13-4 GET_PRIMARY_MODE, GET_RDB_MESSAGE, in RDB support library, 13-3 SET_RDB_MODE, takeover, 13-3 example ALGOL program for, result values of, 13-4 selectively overriding program warnings, ERGO with Database Interpreter, runs on the primary host but not on the secondary host, error-handling options for the ABW mode, 2-4 Drop the secondary, 2-6 impact on system resources, 3-9 Operator intervention, 2-7 EXCLUSIVE option, Index 7

400 Index F family locations of databases, 10-12, fatal software error, file transfer impact on network resources in SCA and NSC modes, 2-22 impact on primary processor utilization, 2-22 impact on secondary processor utilization, 2-22 manual, 9-24 products for AFS mode, 1-15, 1-16, 2-11 file transmission modes, impact on resources, 2-19 file-searching order for finding code files, 4-36 forms Applications Activity Form, B-9 Audit Generation Rate Form, B-8 Database Description Form, B-3 Network Description Form, B-7 Primary Host Database Applications List Form, B-4 Primary Host Nondatabase Applications List Form, B-5 resource assessment, B-1 Secondary Host Applications List Form, B-6 System Resource Description Form, B-2 FTRapid file transfer product for AFS mode, 1-15, 1-16, 2-11 full clone operation, 8-16 (See also clone operation) making the required database files available, 8-16 selecting a method of running the clone operation, 8-18 specifying dump information and pack names for database structures, 8-17 specifying pack names for database software files, 8-17 specifying the DMCONTROL and DMUTILITY code files, 8-17 G gathering utilization data calculations for resource utilization, 3-12 calculations for several databases, 3-12 for future host processor utilization, 3-26 for future network utilization, 3-18 measuring tools, 3-14 recording results, 3-14 two-step process, 3-14 GET_PRIMARY_MODE entry point, GET_RDB_MESSAGE entry point, goals for Remote Database Backup disaster recovery, 3-4 primary host use, 3-6 selecting an audit transmission mode for, 3-8 guard files, 4-28 for the secondary host attaching, 4-28 defining access, 4-28 required read/write access, 4-28 setting up, 4-28 specifying, 4-28 lack of read/write access, location, changing, 9-7 guidelines for planning future host processor utilization, 3-26 planning future network resources, 3-18 using the primary host, 3-6 H halt/load recovery, 10-2, 10-5 on the secondary host, Catchup does not run after, hardware requirements, Remote Database Backup, 1-12 high availability reorganization procedure to perform, 9-21 host information record definition, 8-7 deleting for the secondary host, 8-12 modifying, 8-10 reasons for accessing, 8-7 viewing, 8-9 host processor resources ABW mode, impact on, 2-17 AFS mode, impact on, 2-20 audit file transmission modes, impact on, 2-19 gathering data on future utilization, 3-26 measuring secondary host utilization for remote backup, 3-28 for takeover purposes, 3-29 Index

401 Index SCA and NSC modes, impact on, 2-22 host roles in a Remote Database Backup system, 1-5 I I/O timeout value for the ports, 4-40 port-i/o timeout errors, responding to, 4-41 procedure for setting, 4-40 identifying pack names for database software files on the secondary host, 5-12 IMMEDIACY subfield T_O_DEFAULT (0) value, 13-9 T_O_END_OF_AUDIT (3) value, 13-9 immediate audit file transmission benefits in relation to resources, 2-19 impact on resources ABW mode, 2-17 AFS mode, 2-20 audit block acknowledgments, 2-17 audit file transmission modes, 2-19 SCA and NSC modes, 2-22 incompatibility of primary and secondary hosts, INITIALIZE command, 14-2 Inquiry, runs on the primary host but not on the secondary host, INQUIRYONLY option, 9-15 installation (See Remote Database Backup installation) K KEYEDIO files, incompatible with Remote Database Backup, 1-13 KEYEDIOII files, incompatible with Remote Database Backup, 1-13 L level of audit trail synchronization, 1-14 considerations, 1-18 effect of audit file transmission modes on, 1-14, 1-16 lost transactions, identifying, 6-6 M making the required database files available on the secondary host, 5-7 manual intervention for takeovers, 13-3 manual transfer of files, procedure for, 9-24 measuring tools, for resource utilization, 3-14 messages per second, calculating audit generation rate in, 3-20, 3-22 messages, accessing, 7-4 mirrored audit changing audit transmission modes, D-6 corrupted pack label, recovering from, D-6 operational considerations, D-1 performing an unplanned takeover in AFM mode, D-13 planned takeover in AFM mode, D-9 Remote Database Backup system environment, D-2 modes, audit transmission (See audit transmission modes; audit file transmission modes) MODIFY command, 14-2 modifying a host information record, 8-10 monitoring your Remote Database Backup system, 7-1, 7-2 accessing cumulative Remote Database Backup statistics, 7-10 effect of start time on statistics, 7-11 explanation of Remote Database Backup statistical information, 7-11 purpose of Remote Database Backup statistics, 7-10 when Remote Database Backup statistics are updated, 7-11 when to access Remote Database Backup statistics, 7-10 accessing database statistics on Remote Database Backup performance, 7-16 accessing messages, 7-4 immediate feedback on system functioning, 7-4 accessing the current state of audit transfers, 7-5 Remote Database Backup report information, 7-5 goals of, 7-2 how to get the most from, 7-2 interpreting Remote Database Backup statistics, Index 9

402 Index determining the network capacity for your database, 7-15 measuring the impact of network performance on primary database performance, 7-14 monitoring tools, 7-3 multiple primary hosts with a single backup host (figure), 1-9 multiple Remote Database Backup systems with multiple backup hosts (figure), 1-10 N Native File Transfer (NFT) failure under AFS mode, file transfer product for AFS mode, 1-15, 1-16, 2-11, 4-5 network capacity, determining for your database, 7-15 Network Description Form, B-7 network resources ABW mode impact on, 2-17 preliminary measurements, 3-19 ABW mode, estimating future utilization with Remote Database Backup, 3-24 AFS mode, impact on, 2-20 AFS, SCA, and NSC modes estimating future utilization, 3-24 measuring network utilization rate, 3-25 preliminary measurements, 3-21 audit file transmission modes, impact on, 2-19 communications processor utilization statistics, 3-24 describing, 3-11 file transfer impact on, 2-22 gathering data future utilization, 3-18 general impact of Remote Database Backup on utilization, 3-15 SCA and NSC modes, impact on, 2-22 network utilization rate measuring for AFS, SCA, and NSC modes, 3-25 NFT (See Native File Transfer) NFTINFOFILE file, 4-5 NO FILE <database name>/control message, NO FILE condition on a new structure, under the SCA and NSC modes, NO FILE SYSTEM/ACCESSROUTINES message, nonusercoded databases default job queue attributes and, 4-5 port file errors, preparations for, 4-5 not server capable mode (See NSC mode) NOZIP option, reconstruct recovery and, 10-8 NSC mode, 2-14 effect on synchronization level, 1-15, 1-16 impact on resources, 2-22 manual synchronization of audit files under, 5-22 means of file transfer, 2-22 NO FILE condition under, partial audit file message under, preliminary measurements for existing network utilization, 3-21 processing DASDL updates under, 9-5 procedure to use when the update level does not change, 9-6 procedure to use when the update level increases, 9-5 using alternately with other modes, 2-15 O offline dump of the secondary database, preparing for, 8-24 offline dump, copying database structures from, OFFLINE option, 9-15 offline reorganization examples, 9-28 procedure to perform, 9-21 one Remote Database Backup system (figure), 1-7 online reorganization handling the effects, 9-30 Open Distributed Transaction Processing, 1-13 Open Distributed Transaction Processing considerations for use with Remote Database Backup, 4-7 Open Distributed Transaction Processing considerations for use with Remote Database Backup, 4-7 Index

403 Index open options, effects on database availability (table), 9-15 OPEN PARTITIONS option, 4-32 operational considerations for mirrored audit, D-1 Operator intervention error-handling option AX commands for, 2-7 description, 2-7 optimal message size, calculating, 3-20 OVERRIDE_OK subfield of PARAMS parameter selective overriding, OVERRIDE_REQD subfield of PARAMS parameter, 13-8 overview Remote Database Backup system, 1-2 selecting Remote Database Backup options and system resources, 3-2 P pack label corrupted recovering from, D-6 pack names for database software files, identifying on the secondary host, 5-12 for database structures, specifying on the secondary host, 5-10 unexpected secondary host designations, 12-5 packs, designating (See usercodes and packs, designating) PARAMS parameter ALREADY_PRIMARY subfield, 13-7 BNA_DOWN subfield, 13-7 DS subfield, 13-7 OVERRIDE_OK subfield selective overriding, OVERRIDE_REQD subfield, 13-8 RECLONE subfield, 13-7 specifying values for, 13-5 STCLONE subfield, 13-7 VERSION_WORD field, 13-5, 13-7 WARN_HOST subfield, 13-8 WARNINGS field, 13-7 partial audit file message, under the SCA or NSC mode, partially audited reorganizations characteristics of, 9-19 partitioning database structures, 4-32 peak periods of audit transmission, 2-20 performance requirements, establishing, 3-7 performing replication of the secondary database, 8-27 planned takeover, 6-4, 6-7 (See also takeovers, performing; unplanned takeover) multiple takeovers, 6-6 nonusercoded database and, 4-34 restoring original remote database backup configuration following, D-10 terminating update programs, 6-4 transferring audit images, 6-4 planned takeover in AFM mode mirrored audit, D-9 planning guidelines future host processor utilization, 3-26 future network utilization, 3-18 port file errors with a nonusercoded database, port files, 4-19 ACR_PORT, characteristics, 4-20 CU_PORT, characteristics, 4-20 PORT, characteristics, 4-19 sectioned audit files and, 4-20 PORT port file characteristics, 4-19 fixed timeout value for, 4-40 port subfile state error, port-i/o timeout errors addressing frequent, causes, 4-41 responding to, 4-41 troubleshooting, port-i/o timeout value activating error-handling options under ABW mode, 2-4 setting for ABW mode, 4-23 system resources and, 3-9 preparation for configuring a Remote Database Backup system (See configuring a Remote Database Backup system, preparation for) prescanning phase of Tracker process, 4-42 PREVERIFY option, 9-15 primary and secondary hosts, initializing, 5-3 primary database component of a Remote Database Backup system, 1-4 CONTROLPOINT option, and frequency of restart points, 4-44 family location, Index 11

404 Index Open Distributed Transaction Processing and, 4-7 partitioning structures in, 4-32 performance, measuring the impact of network performance on, 7-14 performing a takeover when corrupt, programs wait on an AX command, recovering from a duplicate, resolving problems related to, role change during a takeover, 6-2 primary host, 3-6 component of a Remote Database Backup system, 1-4 general impact of Remote Database Backup on utilization, 3-15 guidelines for use of, 3-6 incompatibility with secondary host, performance, impact of ABW mode on, 2-17 shown as undefined by View Remote Auditing Status screen, Visible DBS change commands and, 8-32 Primary Host Database Applications List Form, B-4 Primary Host Nondatabase Applications List Form, B-5 primary processor utilization, file transfer impact on, 2-22 PRIMARY_HOSTNAME parameter, 13-5 PRINTAUDIT program identifying lost transactions and, 6-6 obtaining an audit block size with, 3-20, C-9 priority of RDB server tasks, 4-12 procedures adding a new data set and its associated sets, 9-8 adding a new set or subset to an existing data set, 9-9 audited reorganization, 9-20 applying to the secondary database, 9-22 calculating audit block size, 3-20 audit generation rate in bytes per second, 3-19, 3-22 audit generation rate in messages per second, 3-20, 3-22 average block size, 3-20 optimal message size, 3-20 Catchup, checking on, 5-19 cloning the database on the secondary host, 8-16 code file locations, changing, 9-7 code file names, changing, 9-7 DASDL updates in the Remote Database Backup environment, basic, 9-2 full clone operation, 8-16 guard file locations, changing, 9-7 guard file names, changing, 9-7 I/O timeout value for the ports, setting, 4-40 inquiry programs, testing, 5-20 measuring network utilization rate for AFS, SCA, and NSC modes, 3-25 secondary host activity, 3-27 secondary host processor utilization, 3-28, 3-29 messages, accessing, 7-4 offline reorganization, 9-21 processing a DASDL update under the ABW mode, 9-4 when the update level does not change, 9-6 when the update level increases, 9-5 programmatic takeover, rebuild recovery, 10-3 reestablishing the COMS TTRAIL after a takeover, 6-14 Remote Database Backup system reenabling, 8-31 verifying, 5-19 rollback recovery, 10-4 Tracker checking on, 5-19 disabling, 8-21 restarting after it has been permanently disabled, 8-22 restarting after it has been temporarily disabled, 8-22 transferring files manually after an audited reorganization, 9-24 update programs, testing, 5-20 programmatic interfaces, 13-1 Q questions about primary host use, 3-6 Quickfix process, 4-15 QUIESCE command performing additional database replication at the secondary host, 8-27 quiet points in a Tracker scan, 4-42 Index

405 Index R RDB CONTROL FILE ERROR RDB CONTROL FILE NOT RESIDENT message, RDB server code file, 4-11 not responding during a clone operation, 12-8 task, 4-11 RDB server tasks priority of, 4-12 RDB support library, 4-12 declaration in ALGOL program, 13-2 entry points, 13-2 establishing a link to, 13-2 modifying for a nonusercoded database, 4-6 RDB_TAKEOVER entry point, 13-4 read/write access, lack of for guard files, READONLY 1#2 error, REAPPLYCOMPLETED DASDL option, 4-31 rebuild recovery, 10-2, 10-3 received AFN value, starting the secondary database and, 5-22 reciprocal backup hosts for two Remote Database Backup systems (figure), 1-8 RECLONE subfield of PARAMS parameter, 13-7 RECONSTRUCT file, making available on the secondary host, 9-14 RECONSTRUCT program, 10-7 reconstruct recovery, 10-2, 10-7 performing on the primary database, 10-7 on the secondary database, 10-7 with the NOZIP option set, 10-8 recovering a database in the Remote Database Backup environment, 10-1 restoring lost or corrupted database files, types of recovery, 10-2 abort recovery, 10-2, 10-5, 10-6 copy from an offline dump, 10-2, halt/load recovery, 10-2, 10-5 rebuild recovery, 10-2, 10-3 reconstruct recovery, 10-2, 10-7 rollback recovery, 10-2, 10-4 recovery using DMUTILITY COPY command, recovery, Transaction Server synchronized managing after a takeover, 6-14 reenabling the Remote Database Backup system, 8-31 Remote Database Audit Statistics Visible DBS change command, 8-32 Remote Database Backup audit trail synchronization levels considerations, 1-18 effect during unplanned takeovers, 6-5 effect of audit file transmission modes on, 1-14, 1-16 audit transmission modes, 2-1 audited database requirement, 1-12 capabilities, 1-4 configuration examples, 1-7 description, 1-4 disaster recovery and, 3-5 general impact on network utilization, 3-15 on primary host utilization, 3-15 on resource utilization, 3-15 on secondary host utilization, 3-16 how databases work together under, 1-5, 1-6 identifying goals for, 3-3 integrating into your security setup, 4-27 KEYEDIO files incompatible with, 1-13 KEYEDIOII files incompatible with, 1-13 performance requirements, 3-7 purpose of, 3-3 selecting Remote Database Backup options and system resources for, 3-1 Remote Database Backup environment managing, 8-1 changing the audit file transmission modes, 8-13 cloning the database on the secondary host, 8-15 deleting the host information record for the secondary host, 8-12 disabling the Remote Database Backup system, 8-29 disabling Tracker, 8-19 interdependencies in the Remote Database Backup environment, 8-2 modifying a host information record, 8-10 reenabling the Remote Database Backup system, 8-31 viewing a host information record, Index 13

406 Index recovering a database in, 10-1 restoring lost or corrupted database files, types of recovery, 10-2 reorganizing a database in, 9-1, 9-12 updating a DASDL database in, 9-1, 9-2 using Enterprise Application Environment in, 11-1, 11-2 hints for successful Enterprise Application Environment operations, 11-5 secondary database functions, 11-4 Visible DBS commands in, 8-32 Remote Database Backup installation, 4-3 checklist, 4-3 files installed with Remote Database Backup, 4-4 verifying the installation, 4-4 Remote Database Backup messages, accessing, 7-4 Remote Database Backup operations, automating some, 4-18, 13-2 System Assistant, 4-18 Remote Database Backup options, selecting for your goals, 3-1 Remote Database Backup performance accessing database statistics on, 7-16 generating database statistics on, 7-16 Remote Database Backup report information, 7-5 control record date and timestamp, 7-8 current primary host audit information available, 7-7 current secondary host audit information available, 7-8 factors affecting the information available, 7-5 general database information available, 7-7 relationships between selected report values, 7-9 undefined primary host, when to display, 7-6 Remote Database Backup software, priority of RDB server tasks, 4-12 Remote Database Backup software, understanding, 4-9 automating some Remote Database Backup operations, 4-18, 13-2 System Assistant, 4-18 Catchup, 4-16 Catchup-server, 4-16 components, 4-9 Database Operations Center, 4-9 how the Remote Database Backup components work together for the ABW mode, 4-12 how Tracker and inquiry programs work together, 4-16 RDB server code file, 4-11 RDB support library, 4-12 Tracker, 4-14 Remote Database Backup statistical information database information, 7-12 interpreting, 7-14 determining the network capacity for your database, 7-15 measuring the impact of network performance on primary database performance, 7-14 network information, 7-13 Remote Database Backup system components, 1-4 configuration examples, 1-7 multiple systems, 1-10 multiple systems with a single backup host, 1-9 one system, 1-7 two systems, 1-8, 1-11 configuring, 5-1 cloning the database on the secondary host, 5-6 defining, 5-3 enabling, 5-5 tasks, 5-2 configuring, preparation for, 4-1 advantages of careful preparation, 4-2 tasks, overview, 4-2 database roles, 1-5 defining, 5-3 initializing the primary and secondary hosts, 5-3 disabling, 8-29 removing files from the secondary host after, 8-30 taking a dump of the database after, 8-30 terminating tasks on the secondary host after, 8-30 enabling, 5-5 host roles, 1-5 monitoring, 7-1, 7-2 accessing cumulative Remote Database Backup statistics, 7-10 Index

407 Index accessing database statistics on Remote Database Backup performance, 7-16 accessing messages, 7-4 accessing the current state of audit transfers, 7-5 goals of, 7-2 how to get the most from, 7-2 interpreting Remote Database Backup statistics, 7-14 monitoring tools, 7-3 overview, 7-2 overview, 1-2 preparing personnel to run the system, 4-30 preparing to configure, 3-30 reenabling, 8-31 roles of databases and hosts, 1-5 verifying, 5-19 Remote Database Backup system environment, D-2 Remote Database Backup takeovers, performing (See takeovers, performing; planned takeover; unplanned takeover) Remote Database Backup-agent, task, 4-16 reorganization aborted, 9-13 pack and family factors, 4-35 Tracker designation of restart points under, 4-45 waits while looking for a pack, reorganization open options EXCLUSIVE, 9-15 INQUIRYONLY, 9-15 OFFLINE, 9-15, 9-19 PREVERIFY, 9-15 reorganization problems, solving, reorganizing a database in the Remote Database Backup environment, 9-1, 9-12 audited reorganizations characteristics of, 9-18 procedure to apply to the secondary database, 9-22 procedure to manually transfer files, 9-24 procedure to perform, 9-20 comparing auditing options during, 9-18 considerations before, 9-12 deciding whether to perform tasks manually or automatically, 9-14 effects of BUILDREORG utility open options, 9-15 EXCLUSIVE, 9-15 INQUIRYONLY, 9-15 OFFLINE, 9-15, 9-19 PREVERIFY, 9-15 high availability reorganization, procedure to perform, 9-21 offline reorganization, procedure to perform, 9-21 partially audited reorganizations, characteristics of, 9-19 preparing for, 9-12 preparing for an offline dump of the secondary database, 8-24 restart data set, 9-19 structure availability, 9-16 replicating DASDL updates to the secondary host, conditions for, 9-3 report information, Remote Database Backup (See Remote Database Backup report information) required database files for the secondary host, 5-7 requirements, basic Remote Database Backup hardware and software, 1-12 resource assessment forms, B-1 resource utilization ABW mode, impact on, 2-17 AFS mode, impact on, 2-20 AFS, SCA, and NSC modes, determining future network utilization for, 3-24 AUDIT ANALYZE AFN command and, C-2, C-7 audit file transmission modes, impact on, 2-19 AUDIT PROCESSOR TIMES command and, C-2 calculations for several databases, 3-12 calculations to determine, 3-12 estimating future network utilization for ABW mode, 3-24 gathering data, 3-12 on future host processor, 3-26 on future network, 3-18 measuring network utilization rate, 3-25 measuring secondary host processor utilization for remote backup, 3-28 for takeover purposes, 3-29 preliminary measurements for existing network, 3-19, Index 15

408 Index process of calculating, 3-14 recording data about, 3-14 SCA and NSC modes, impact on, 2-22 tools to measure, 3-14 restart data set and reorganizing the database OFFLINE, 9-19 restart points CONTROLPOINT option, 4-44 designating, 4-45 governing the frequency of, 4-44 manipulating the frequency of, 4-44 manipulating the occurrence of for Tracker, 4-44 TRACKERFLUSHDB option, 4-44 ways to increase the occurrence of, 4-46 restarting Tracker after it has been permanently disabled, 8-22 after it has been temporarily disabled, 8-22 results of, 8-22 restoring lost or corrupted database files, procedures for database control file, 10-11, RDB control file, 10-11, restoring original Remote Database Backup configuration following a planned takeover, D-10 restoring original Remote Database Backup configuration following an unplanned takeover, D-14 roles of databases and hosts in a Remote Database Backup system, 1-5 rollback recovery, 10-2, 10-4 S SCA mode, 2-13 Catchup fails to run after change to ABW mode, effect on synchronization level, 1-15, 1-16 impact on resources, 2-22 manual synchronization of audit files under, 5-22 means of file transfer, 2-22 NO FILE condition under, partial audit file message under, preliminary measurements for existing network utilization, 3-21 processing DASDL updates under, 9-5 procedure to use when the update level does not change, 9-6 procedure to use when the update level increases, 9-5 using alternately with other modes, 2-15 screen View Remote Auditing Status, 7-5 secondary database application waits for Tracker quiet point, availability after the clone operation, 5-18 component of a Remote Database Backup system, 1-4 database equation using for WFL job access to, 4-38 ensuring application access to, 4-38 family location, 10-12, Open Distributed Transaction Processing and, 4-7 partitioning structures in, 4-32 performing a takeover when corrupt, performing an offline dump of, 8-24 performing replication of the, 8-27 Quickfix process and, 4-15 resolving problems related to, role change during a takeover, 6-2 role in a Remote Database Backup system, 1-5 starting after a clone operation, 5-22 actions that initiate Tracker, 5-21 audit files that Tracker requires, 5-22 conditions of starting, 5-21 manual synchronization under AFS, SCA, and NSC modes, 5-22 supplying the audit files that Tracker requires, 5-23 synchronizing the databases, 5-21 secondary host activity, measuring, 3-27 after a clone operation, 5-21 alternate audit trail location, 4-31 audit file transfer stops at, audit trail not synchronized, Catchup does not run after halt/load, cloning the database on, 5-6, 8-15 identifying pack names for database software files, 5-12 making the required database files available, 5-7 procedure, 8-16 providing the DMCONTROL and DMUTILITY code file titles, 5-15 selecting a method of running the clone operation, 5-15 Index

409 Index specifying dump information and pack names for database structures, 5-10 using a previous clone WFL job, 8-15 component of a Remote Database Backup system, 1-4 full clone operation procedure, 8-16 general impact of Remote Database Backup on utilization, 3-16 incompatibility with primary host, making the RECONSTRUCT file available on, 9-14 performance, impact of ABW mode on, 2-18 removing files from the secondary host after a disable operation, 8-30 replicating DASDL updates to, conditions for, 9-3 role in a Remote Database Backup system, 1-5 structure clone operation, 9-26 tasks and procedures, 9-26 terminating tasks on the secondary host after a disable operation, 8-30 Visible DBS change commands, 8-32 Secondary Host Applications List Form, B-6 secondary processor utilization, file transfer impact on, 2-22 sectioned audit files, 4-11, 4-14 ABW mode and, 4-14 audit synchronization, 4-26 Catchup and, 4-17 port files and, 4-20 security setup, integrating Remote Database Backup into, 4-27 goal of integration, 4-27 guard files for the secondary host, setting up, 4-28 why security problems occur, 4-27 selecting audit transmission modes to meet your goals, 3-8 method of running the clone operation, 5-15 Remote Database Backup options for your goals, 3-1 system resources for Remote Database Backup, 3-1 send time, 7-14 server capable mode (See SCA mode) set, adding to an existing data set, 9-9 SET_RDB_MODE entry point, software requirements, Remote Database Backup, 1-12 source disk, D-4 specifying dump information and pack names for database structures on the secondary host, 5-10 starting the secondary database after a clone operation actions that initiate Tracker, 5-21 audit files that Tracker requires, 5-22 conditions of starting, 5-21 manual synchronization under AFS, SCA, and NSC modes, 5-22 supplying the audit files that Tracker requires, 5-23 synchronizing the databases, 5-21 statistics report, Enterprise Database Server, C-7, C-9 statistics, generating database, 7-16 STATUS command, 14-2 STCLONE subfield of PARAMS parameter, 13-7 structure availability during reorganization, 9-16, 9-22 structure clone operation ABW mode, 9-27 after partially audited reorganization, 9-18 required after partially audited reorganization, 9-19 tasks and procedures, 9-26 verifying completeness, 9-27 WFL job tasks, 9-27 when required after takeover, 6-10 when to perform, 9-26 structures adding new, 9-8 data set and its associated sets, 9-8 set to an existing data set, 9-9 subset to an existing data set, 9-9 initialization of new, 9-11 subset, adding to an existing data set, 9-9 supplying the audit files that Tracker requires, 5-23 synchronization (See also audit synchronization) levels for Remote Database Backup audit trails, 1-14 AFS mode and, 1-15 considerations, 1-18 database recovery and, 1-17 SCA mode and, 1-15 Remote Database Backup automatic process, Index 17

410 Index resolving problems with resynchronization, System Assistant, 4-18 system messages, accessing, 7-4 System Resource Description Form, B-2 system resources calculating utilization for several databases, 3-12 calculations to determining utilization, 3-12 describing, 3-10 gathering data to calculate utilization, 3-12 general impact of Remote Database Backup on, 3-16 impact of ABW error-handling options, 3-9 impact of port-i/o timeout value on, 3-9 process of calculating utilization, 3-14 recording utilization data, 3-14 selecting for Remote Database Backup, 3-1 tools to measure utilization, 3-14 SYSTEM/RDBSUPPORT, 8-2 SYSTEMERROR 6, T T_O_DEFAULT (0) value of IMMEDIACY subfield, 13-9 T_O_END_OF_AUDIT (3) value of IMMEDIACY subfield, 13-9 TAKEOVER command, 14-2 takeover entry point, 13-3 calling, 13-4 declaring, 13-4 example ALGOL program for, result values, 13-4 selectively overriding program warnings, takeovers, performing, 6-1, 6-7 (See also planned takeover; unplanned takeover) automating, 13-3 considerations, 6-2 definition of a takeover, 6-2 duplicate primary database resolution of, managing Transaction Server synchronized recovery, 6-14 manual intervention for, 13-3 planned takeover, 6-4 mirrored audit, D-9 multiple takeovers, 6-6 terminating update programs, 6-4 transferring audit images, 6-4 structure clone and, 6-10 troubleshooting, unplanned takeover estimating transaction loss, 6-5 identifying lost transactions, 6-6 mirrored audit, D-13 synchronization levels and transaction loss, 6-5 Visible DBS commands and, 8-32 when a database is corrupted, when to do a takeover, 6-3 tape audit failures resolving, tape encryption, 4-39, 5-8, 8-16, 8-24 target disk, D-4 tools to measure database activity, C-2 to measure resource utilization, 3-14 to obtain an audit block size, C-9 to obtain an audit generation rate, C-7 TPS (Transaction Processing System), 1-13 Tracker, 4-14 application phase, 4-42 as part of the audit synchronization process, 4-25 checking Tracker status, 8-22 designation of restart points by, 4-45 disabling, 8-19 checking Tracker status, 8-22 consequences, 8-19 difference between temporarily and permanently disabling, 8-20 DISABLETRACKER option during a reorganization, 9-15 procedure, 8-21 reasons for, 8-19 results, 8-21 effect on View Remote Auditing Status screen, 7-5 flow of audit block images under ABW mode, 4-21 halt/load recovery and, 10-5 how Tracker and inquiry programs work together, 4-16 initialization of a new structure and, 9-11 interrupting for an offline dump of the secondary database, 8-25 manipulating the occurrence of restart points for, 4-44 prescanning phase, 4-42 problem solving, Index

411 Index quiet points in a prescan, 4-42 restart points and CONTROLPOINT option, 4-44 and TRACKERFLUSHDB option, 4-44 governing the frequency of, 4-44 ways to increase the occurrence of, 4-46 restarting after it has been permanently disabled, 8-22 after it has been temporarily disabled, 8-22 results, 8-22 secondary database application waits for, speed of performance, affecting, 4-42 stays in the mix, supplying required audit files for, 5-23 TRACKERQPFACTOR option, 4-42 under ABW mode, does not run after successful clone operation, TRACKERFLUSHDB option, 4-44 TRACKERQPFACTOR option, 4-42 transaction loss, unplanned takeover estimating during, 6-5 identifying lost transactions during, 6-6 Transaction Processing System (TPS), 1-13 Transaction Server synchronized recovery, managing after a takeover, 6-14 transfer of files, manual, procedure for, 9-24 transferring audit blocks to the secondary host AFM mode, 2-8 troubleshooting, 12-2 Catchup problems, clone operation, 12-5 Database Operations Center, 12-3 enable operation, 12-3 minimizing operational problems, 12-2 mode changes, port-i/o timeout errors, primary database problems, reorganization problems, secondary database problems, synchronization problems, takeover problems, tape audit failures, Tracker problems, updating problems, two Remote Database Backup systems sharing primary and secondary hosts (figure), 1-11 U unplanned takeover, 6-7 (See also planned takeover; takeovers, performing) effect of audit trail synchronization on, 6-11 estimating transaction loss, 6-5 identifying lost transactions, 6-6 nonusercoded database and, 4-34 restoring original Remote Database Backup configuration following, D-14 synchronization levels and transaction loss, 6-5 unplanned takeover in AFM mode mirrored audit, D-13 update level mismatch, DMOPENERROR 37, updating a DASDL database in the Remote Database Backup environment, 9-1, 9-2 updating problems, solving, usercoded databases, reorganizing, 9-17 usercodes and packs, designating, 4-34 code files, 4-36 file-searching order for finding, 4-36 nonusercoded databases, 4-5 pack and family factors, 4-35 planning usercodes and file locations, need for, 4-34 usercode factors, 4-34 usercodes, designating (See usercodes and packs, designating) V verifying your Remote Database Backup system, 5-19 checking on Catchup or Tracker, 5-19 testing inquiry and update programs, 5-20 VERSION_WORD field of PARAMS parameter, 13-5, 13-7 View Remote Auditing Statistics screen, 7-11 View Remote Auditing Status screen, 7-5 checking during a takeover, 6-5 current ABSN does not match received ABSN, designates primary host as undefined, viewing a host information record, 8-9 Visible DBS command Remote Database Audit Statistics, Index 19

412 Index Visible DBS commands CHANGE TRACKERFLUSHDB option and, 4-44 TRACKERQPFACTOR option and, 4-43 change commands, 8-32 in the Remote Database Backup environment, 8-32 secondary host and, 8-32 STATUS TRACKERFLUSHDB option and, 4-44 TRACKERQPFACTOR option and, 4-43 W wait time, 7-14 WARN_HOST subfield of PARAMS parameter, 13-8 WARNINGS field of PARAMS parameter, 13-7 WFL job for a full clone operation, sample, A-2 runs on primary host but not on secondary host, tasks for a structure clone operation:, 9-27 Index

413 .

414 2011 Unisys Corporation. All rights reserved. * *