For UNIX Systems

Nonstop Database

HiRDB Version 9

Disaster Recovery System Configuration and Operation Guide

3000-6-464(E)

Contents

Notices

Preface

Part 1: Overview

1. Overview of Real Time SAN Replication

1.1 About Real Time SAN Replication

1.2 Importing data to the remote site

1.2.1 All synchronous method

1.2.2 All asynchronous method

1.2.3 Hybrid method

1.3 Characteristics of the individual processing methods

1.4 Prerequisite platforms and products

Part 2: All Synchronous Method, All Asynchronous Method, and Hybrid Method

2. Points to Consider when Designing a System

2.1 Selecting a protection mode (not applicable to the all asynchronous method)

2.2 Points to consider when setting up a HiRDB environment

2.2.1 Items that must be the same for the main site and the remote site

2.2.2 Items to be changed at the remote site

2.2.3 Specifying system definition operands

2.3 Points to consider when setting up a RAID Manager environment

2.4 Points to consider when creating HiRDB file system areas

2.4.1 File classifications

2.4.2 Notes on creating HiRDB file system areas

2.4.3 HiRDB file system area configuration examples

2.5 Points to consider when designing volumes

2.5.1 Points to consider when designing paired volumes

2.5.2 Points to consider when designing paired logical volumes

2.5.3 Points to consider when designing paired logical volume groups

2.5.4 Paired volume configuration examples

2.5.5 System configuration example

3. Building a System

3.1 Building a disaster recovery system

3.2 Tasks required to build a disaster recovery system

3.2.1 Building the RAID Manager environment

3.2.2 Building the HiRDB environment at the main site

3.2.3 Checking the HiRDB configuration at the main site

3.2.4 Taking control over the paired logical volume groups (transfer control from the main site to the remote site)

3.2.5 Checking the status of paired logical volume groups at the remote site

3.2.6 Building the HiRDB environment at the remote site

3.2.7 Checking the HiRDB configuration at the remote site

3.2.8 Taking control over the paired logical volume groups (transfer control from the remote site to the main site)

3.2.9 Checking the status of the paired logical volume groups at the main site

4. Operations at the Main Site

4.1 HiRDB startup method

4.2 Notes on operation when using the hybrid method

4.2.1 When database updates must be synchronized between the main site and the remote site

4.2.2 Notes on initializing a database

4.3 Notes on executing RAID Manager commands

5. Switching Over to the Remote Site

5.1 Switching to the remote site

5.1.1 Ways to switch sites

5.1.2 Site switchover methods that can be used while the main site is running

5.1.3 Site switchover methods that can be used when a disaster occurs at the main site

5.1.4 Results of switching sites to perform maintenance

5.1.5 Results of switching sites in the event of a disaster

5.2 Switching sites to test disaster preparedness

5.3 Switching sites to perform maintenance

5.4 Switching sites in the event of a disaster

5.5 Transaction information file

6. Error Handling

6.1 HiRDB's actions when an error occurs during update copy

6.2 Collecting synchronization point dumps (when using the hybrid method)

6.3 Error-handling methods

6.4 Handling of failure to link to RAID Manager

6.5 Handling when paired logical volume group names are missing from the RAID Manager configuration definition

6.6 Handling of route errors

6.7 Handling of errors on the primary volume

6.8 Handling of errors on the secondary volume

6.9 Handling a disaster at the main site that occurred while it was recovering from an error

7. Changing the Pair Logical Volume Configuration

7.1 Situations requiring changes in the paired logical volume configuration

7.2 Adding a paired logical volume group

7.3 Adding a paired logical volume to an existing paired logical volume group

7.4 Changing the name of a paired logical volume group

7.5 Moving a paired logical volume to a new paired logical volume group

7.6 Moving a paired logical volume to an existing paired logical volume group

7.7 Deleting a paired logical volume

8. Relationships to Other Facilities

8.1 Facilities that require special attention

8.2 Notes on using the inner replica facility

8.3 Notes on using the system switchover facility

8.3.1 Standby system switchover facilities

8.3.2 Standby-less system switchover (1:1) facility

8.3.3 Standby-less system switchover (effects distributed) facility

8.3.4 Setting up cluster software

8.3.5 Standby system operation

8.4 Notes on using the security audit facility

8.5 Notes on using the automatic log unloading facility

8.6 Notes on using the facility for monitoring the free area for system log files

8.7 Notes on using a shared table (applicable only to the hybrid method)

Appendixes

A. Examples of System and Configuration Definitions

A.1 Hybrid method

B. Sample Shell Program

C. Notes on Updating HiRDB

C.1 When using the all synchronous, all asynchronous, or hybrid method

Index

[Trademarks]

All Rights Reserved. Copyright (C) 2011, Hitachi, Ltd.

Notices

Relevant program products

List of program products:
For the Red Hat Enterprise Linux AS 4 (AMD64 & Intel EM64T), Red Hat Enterprise Linux ES 4 (AMD64 & Intel EM64T), or Linux 5 (AMD/Intel 64) operating system:

P-9W62-3592 HiRDB Server Version 9 09-01

This edition of the manual is released for the preceding program products, which have been developed under a quality management system that has been certified to comply with ISO9001 and TickIT. This manual may also apply to other program products; for details, see Before Installing or Readme file (for the UNIX version, see Software Information or Before Installing).

Trademarks

ActiveX is either a registered trademark or a trademark of Microsoft Corporation in the United States and/or other countries.
AIX is a trademark of International Business Machines Corporation in the United States, other countries, or both.
AIX 5L is a trademark of International Business Machines Corporation in the United States, other countries, or both.
AMD is a trademark of Advanced Micro Devices, Inc.
CORBA is a registered trademark of Object Management Group, Inc. in the United States.
DataStage, MetaBroker, MetaStage and QualityStage are trademarks of International Business Machines Corporation in the United States, other countries, or both.
DB2 is a trademark of International Business Machines Corporation in the United States, other countries, or both.
HACMP is a trademark of International Business Machines Corporation in the United States, other countries, or both.
HP-UX is a product name of Hewlett-Packard Company.
IBM is a trademark of International Business Machines Corporation in the United States, other countries, or both.
Itanium is a trademark of Intel Corporation in the United States and other countries.
Java is a registered trademark of Oracle and/or its affiliates.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Microsoft, and Excel are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
Microsoft Access is a registered trademark of Microsoft Corporation in the U.S. and other countries.
Motif is a registered trademark of the Open Software Foundation, Inc.
MS-DOS is a registered trademark of Microsoft Corp. in the U.S. and other countries.
ODBC is Microsoft's strategic interface for accessing databases.
OLE is the name of a software product developed by Microsoft Corporation and the acronym for Object Linking and Embedding.
Oracle and Java are registered trademarks of Oracle and/or its affiliates.Other company and product names mentioned in this document may be the trademarks of their respective owners.Throughout this document Hitachi has attempted to distinguish trademarks from descriptive terms by writing the name with the capitalization style used by the manufacturer, or by writing the name with initial capital letters. Hitachi cannot attest to the accuracy of this information. Use of a trademark in this document should not be regarded as affecting the validity of the trademark.
OS/390 is a trademark of International Business Machines Corporation in the United States, other countries, or both.
PowerHA is a trademark of International Business Machines Corporation in the United States, other countries, or both.
Red Hat is a trademark or a registered trademark of Red Hat Inc. in the United States and other countries.
Sun is either a registered trademark or a trademark of Oracle and/or its affiliates.
Sun Microsystems is either a registered trademark or a trademark of Oracle and/or its affiliates.
UNIFY2000 is a product name of Unify Corp.
UNIX is a registered trademark of The Open Group in the United States and other countries.
VERITAS is a trademark or registered trademark of Symantec Corporation in the U.S. and other countries.
Visual Basic is a registered trademark of Microsoft Corp. in the U.S. and other countries.
Visual C++ is a registered trademark of Microsoft Corp. in the U.S. and other countries.
Visual Studio is a registered trademark of Microsoft Corp. in the U.S. and other countries.
Windows is either a registered trademark or a trademark of Microsoft Corporation in the United States and/or other countries.
Windows NT is either a registered trademark or a trademark of Microsoft Corporation in the United States and/or other countries.
Windows Server is either a registered trademark or a trademark of Microsoft Corporation in the United States and/or other countries.
Windows Vista is either a registered trademark or a trademark of Microsoft Corporation in the United States and/or other countries.
X/Open is a registered trademark of The Open Group in the U.K. and other countries.
X Window System is a trademark of X Consortium, Inc.

Restrictions

Information in this document is subject to change without notice and does not represent a commitment on the part of Hitachi. The software described in this manual is furnished according to a license agreement with Hitachi. The license agreement contains all of the terms and conditions governing your use of the software and documentation, including all warranty rights, limitations of liability, and disclaimers of warranty.
Material contained in this document may describe Hitachi products not available or features not available in your country.
No part of this material may be reproduced in any form or by any means without permission in writing from the publisher.
Printed in Japan.

Issued

Dec. 2011: 3000-6-464(E)

Copyright

All Rights Reserved. Copyright (C) 2011, Hitachi, Ltd.

Preface

This manual describes the disaster recover system for HiRDB Version 9 Nonstop Database.

Intended readers

This manual is intended for users who configure or operate HiRDB Version 9 (hereafter referred to as HiRDB) with a disaster recovery system.

Readers of this manual must have the following:

A basic understanding of how to manage HP-UX or AIX systems

Knowledge of RAID Manager, TrueCopy, and Universal Replicator

Knowledge of HiRDB configuration and operation

Organization of this manual

This manual is organized into the following parts and appendixes:

1. Overview

Part 1 provides an overview of real-time SAN replication.

2. All Synchronous Method, All Asynchronous Method, and Hybrid Method

Part 2 explains how to design, build, and operate a system using the all synchronous method, the all asynchronous method, and the hybrid method.

A. Examples of System and Configuration Definitions

Appendix A provides examples of HiRDB and RAID Manager system definitions appropriate for implementing a disaster recovery system.

B. Sample Shell Program

Appendix B explains how to execute a sample shell program that displays volume attributes and statuses of paired logical volume groups.

C. Notes on Updating HiRDB

Appendix C provides important information about updating HiRDB.

Related publications

This manual is part of a related set of manuals. The manuals in the set are listed below (with the manual numbers):

HiRDB

For UNIX Systems HiRDB Version 9 Description (3000-6-451)#

For UNIX Systems HiRDB Version 9 Installation and Design Guide (3000-6-452(E))

For UNIX Systems HiRDB Version 9 System Definition (3000-6-453(E))

For UNIX Systems HiRDB Version 9 System Operation Guide (3000-6-454(E))

For UNIX Systems HiRDB Version 9 Command Reference (3000-6-455(E))

HiRDB Version 9 UAP Development Guide (3020-6-456(E))

HiRDB Version 9 SQL Reference (3020-6-457(E))

HiRDB Version 9 Messages (3020-6-458(E))

For UNIX Systems HiRDB Version 9 Staticizer Option Description and User's Guide (3000-6-463)#

HiRDB Version 9 XDM/RD E2 Connection Facility (3020-6-465)#

HiRDB Version 9 Batch Job Accelerator (3020-6-468)#

For UNIX Systems HiRDB Version 9 Memory Database Installation and Operation Guide (3020-6-469)#

HiRDB Version 9 XML Extension (3020-6-480)#

HiRDB Version 9 Text Search Plug-in (3020-6-481)#

HiRDB Version 8 Security Guide (3020-6-359)#

HiRDB Datareplicator Version 8 Description, User's Guide and Operator's Guide (3020-6-360(E))

HiRDB Datareplicator Extension Version 8 (3020-6-361)#

HiRDB Dataextractor Version 8 Description, User's Guide and Operator's Guide (3020-6-362(E))

For UNIX Systems HiRDB First Step Guide (3000-6-254)#

In references to HiRDB Version 9 manuals, this manual omits the phrases for UNIX systems and for Windows systems. Refer to either the UNIX or Windows HiRDB manual, whichever is appropriate for your platform.

#: This manual has been published in Japanese only; it is not available in English.

Organization of HiRDB manuals

The HiRDB manuals are organized as shown below. For the most efficient use of these manuals, we recommend that they be read in the order shown below, going from left to right.

Conventions: Abbreviations for product names

This manual uses the following abbreviations for product names:

Full name or meaning
Abbreviation

HiRDB Server Version 9
HiRDB/Single Server
HiRDB or HiRDB Server

HiRDB/Parallel Server

HiRDB/Developer's Kit Version 9
HiRDB/Developer's Kit
HiRDB Client

HiRDB/Developer's Kit Version 9 (64)

HiRDB/Run Time Version 9
HiRDB/Run Time

HiRDB/Run Time Version 9 (64)

HiRDB Advanced High Availability Version 9
HiRDB Advanced High Availability

HiRDB Accelerator Version 8
HiRDB Accelerator

HiRDB Accelerator Version 9

HiRDB Non Recover Front End Server Version 9
HiRDB Non Recover FES

HiRDB Staticizer Option Version 9
HiRDB Staticizer Option

HiRDB Disaster Recovery Light Edition Version 9
HiRDB Disaster Recovery Light Edition

HiRDB Text Search Plug-in Version 9
HiRDB Text Search Plug-in

HiRDB XML Extension Version 9
HiRDB XML Extension

HiRDB Datareplicator Version 8
HiRDB Datareplicator

HiRDB Dataextractor Version 8
HiRDB Dataextractor

HiRDB Adapter for XML - Standard Edition
HiRDB Adapter for XML

HiRDB Adapter for XML - Enterprise Edition

HiRDB Control Manager
HiRDB CM

HiRDB Control Manager Agent
HiRDB CM Agent

Hitachi TrueCopy
TrueCopy

Hitachi TrueCopy Asynchronous

Hitachi TrueCopy basic

Hitachi TrueCopy Software

TrueCopy

TrueCopy Asynchronous

TrueCopy remote replicator

Hitachi Universal Replicator Software
Universal Replicator

Universal Replicator

JP1/Automatic Job Management System 3
JP1/AJS3

JP1/Automatic Job Management System 2

JP1/Automatic Job Management System 2 - Scenario Operation
JP1/AJS2-SO

JP1/Cm2/Extensible SNMP Agent
JP1/ESA

JP1/Cm2/Extensible SNMP Agent for Mib Runtime

JP1/Cm2/Network Node Manager
JP1/NNM

JP1/Integrated Management - Manager
JP1/Integrated Management or JP1/IM

JP1/Integrated Management - View

JP1/Magnetic Tape Access
EasyMT

EasyMT

JP1/Magnetic Tape Library
MTguide

JP1/NETM/Audit - Manager
JP1/NETM/Audit

JP1/NETM/DM
JP1/NETM/DM

JP1/NETM/DM Manager

JP1/Performance Management
JP1/PFM

JP1/Performance Management - Agent Option for HiRDB
JP1/PFM-Agent for HiRDB

JP1/Performance Management - Agent Option for Platform
JP1/PFM-Agent for Platform

JP1/Performance Management/SNMP System Observer
JP1/SSO

JP1/VERITAS NetBackup BS v4.5
NetBackup

JP1/VERITAS NetBackup v4.5

JP1/VERITAS NetBackup BS V4.5 Agent for HiRDB License
JP1/VERITAS NetBackup Agent for HiRDB License

JP1/VERITAS NetBackup V4.5 Agent for HiRDB License

JP1/VERITAS NetBackup 5 Agent for HiRDB License

OpenTP1/Server Base Enterprise Option
TP1/EE

Virtual-storage Operating System 3/Forefront System Product
VOS3/FS
VOS3

Virtual-storage Operating System 3/Leading System Product
VOS3/LS

Virtual-storage Operating System 3/Unific System Product
VOS3/US

Extensible Data Manager/Base Extended Version 2
XDM Basic Program XDM/BASE E2
XDM/BASE E2

XDM/Data Communication and Control Manager 3
XDM Data Communication Management System XDM/DCCM3
XDM/DCCM3

XDM/Relational Database
Relational Database System XDM/RD
XDM/RD
XDM/RD

XDM/Relational Database Extended Version 2
Relational Database System XDM/RD E2
XDM/RD E2

VOS3 Database Connection Server
DB Connection Server

Oracle WebLogic Server
WebLogic Server

DB2 Universal Database for OS/390 Version 6
DB2

DNCWARE ClusterPerfect (Linux Edition)
ClusterPerfect

JavaTM
Java

Microsoft(R) Office Excel
Microsoft Excel or Excel

Microsoft(R) Visual C++(R)
Visual C++ or C++ language

PowerHA for AIX, V5.5
PowerHA

PowerHA SystemMirror V6.1

HP-UX 11i V2 (IPF)
HP-UX or HP-UX (IPF)

HP-UX 11i V3 (IPF)

AIX 5L V5.2
AIX 5L
AIX

AIX 5L V5.3

AIX V6.1
AIX V6.1

Linux(R)
Linux

Red Hat Enterprise Linux AS 4 (AMD64 & Intel EM64T)
Linux AS 4
Linux

Red Hat Enterprise Linux AS 4 (x86)

Red Hat Enterprise Linux ES 4 (AMD64 & Intel EM64T)
Linux ES 4

Red Hat Enterprise Linux ES 4 (x86)

Red Hat Enterprise Linux 5.1 Advanced Platform (x86)
Linux 5.1

Red Hat Enterprise Linux 5.1 (x86)

Red Hat Enterprise Linux 5.1 Advanced Platform (AMD/Intel 64)

Red Hat Enterprise Linux 5.1 (AMD/Intel 64)

Red Hat Enterprise Linux 5.2 Advanced Platform (AMD/Intel 64)
Linux 5.2

Red Hat Enterprise Linux 5.2 (AMD/Intel 64)

Red Hat Enterprise Linux 5.3 Advanced Platform (AMD/Intel 64)
Linux 5.3

Red Hat Enterprise Linux 5.3 (AMD/Intel 64)

Red Hat Enterprise Linux 5.4 Advanced Platform (AMD/Intel 64)
Linux 5.4

Red Hat Enterprise Linux 5.4 (AMD/Intel 64)

Red Hat Enterprise Linux AS 4 (AMD64 & Intel EM64T)
Linux (EM64T)

Red Hat Enterprise Linux ES 4 (AMD64 & Intel EM64T)

Red Hat Enterprise Linux 5.1 Advanced Platform (AMD/Intel 64)

Red Hat Enterprise Linux 5.1 (AMD/Intel 64)

Red Hat Enterprise Linux 5.2 Advanced Platform (AMD/Intel 64)

Red Hat Enterprise Linux 5.2 (AMD/Intel 64)

Red Hat Enterprise Linux 5.3 Advanced Platform (AMD/Intel 64)

Red Hat Enterprise Linux 5.3 (AMD/Intel 64)

Red Hat Enterprise Linux 5.4 Advanced Platform (AMD/Intel 64)

Red Hat Enterprise Linux 5.4 (AMD/Intel 64)

Red Hat Enterprise Linux 5.1 Advanced Platform (x86)
Linux 5 (x86)
Linux 5

Red Hat Enterprise Linux 5.1 (x86)

Red Hat Enterprise Linux 5.1 Advanced Platform (AMD/Intel 64)
Linux 5 (AMD/Intel 64)

Red Hat Enterprise Linux 5.1 (AMD/Intel 64)

Red Hat Enterprise Linux 5.2 Advanced Platform (AMD/Intel 64)

Red Hat Enterprise Linux 5.2 (AMD/Intel 64)

Red Hat Enterprise Linux 5.3 Advanced Platform (AMD/Intel 64)

Red Hat Enterprise Linux 5.3 (AMD/Intel 64)

Red Hat Enterprise Linux 5.4 Advanced Platform (AMD/Intel 64)

Red Hat Enterprise Linux 5.4 (AMD/Intel 64)

turbolinux 7 Server for AP8000
Linux for AP8000

Microsoft(R) Windows NT(R) Workstation Operating System Version 4.0
Windows NT

Microsoft(R) Windows NT(R) Server Network Operating System Version 4.0

Microsoft(R) Windows(R) 2000 Professional Operating System
Windows 2000

Microsoft(R) Windows(R) 2000 Server Operating System

Microsoft(R) Windows(R) 2000 Datacenter Server Operating System

Microsoft(R) Windows(R) 2000 Advanced Server Operating System

Microsoft(R) Windows(R) 2000 Advanced Server Operating System
Windows 2000 Advanced Server

Microsoft(R) Windows Server(R) 2003, Standard Edition
Windows Server 2003 Standard Edition
Windows Server 2003

Microsoft(R) Windows Server(R) 2003, Enterprise Edition
Windows Server 2003 Enterprise Edition

Microsoft(R) Windows Server(R) 2003, Standard x64 Edition
Windows Server 2003 Standard x64 Edition

Microsoft(R) Windows Server(R) 2003, Enterprise x64 Edition
Windows Server 2003 Enterprise x64 Edition

Microsoft(R) Windows Server(R) 2003 R2, Standard Edition
Windows Server 2003 R2

Microsoft(R) Windows Server(R) 2003 R2, Enterprise Edition

Microsoft(R) Windows Server(R) 2003 R2, Standard x64 Edition

Microsoft(R) Windows Server(R) 2003 R2, Enterprise x64 Edition

Microsoft(R) Windows Server(R) 2003 R2, Standard x64 Edition
Windows Server 2003 R2 x64 Editions

Microsoft(R) Windows Server(R) 2003 R2, Enterprise x64 Edition

Microsoft(R) Windows Server(R) 2003, Enterprise Edition (64-bit version)
Windows Server 2003 (IPF)

Microsoft(R) Windows Server(R) 2008 Standard
Windows Server 2008 Standard
Windows Server 2008

Microsoft(R) Windows Server(R) 2008 Enterprise
Windows Server 2008 Enterprise

Microsoft(R) Windows Server(R) 2008 R2 Standard (x64)
Windows Server 2008 R2

Microsoft(R) Windows Server(R) 2008 R2 Enterprise (x64)

Microsoft(R) Windows Server(R) 2008 R2 Datacenter (x64)

Microsoft(R) Windows Server(R) 2008 Standard (x64)
Windows Server 2008 (x64)

Microsoft(R) Windows Server(R) 2008 Enterprise (x64)

Microsoft(R) Windows Server(R) 2003, Standard x64 Edition
Windows Server 2003 x64 Editions
Windows (x64)

Microsoft(R) Windows Server(R) 2003, Enterprise x64 Edition

Microsoft(R) Windows Server(R) 2003 R2, Standard x64 Edition

Microsoft(R) Windows Server(R) 2003 R2, Enterprise x64 Edition

Microsoft(R) Windows(R) XP Professional x64 Edition
Windows XP x64 Edition

Microsoft(R) Windows Server(R) 2003, Enterprise Edition (64-bit version)
Windows Server 2003 (IPF)
Windows(IPF)

Microsoft(R) Windows(R) XP Professional x64 Edition
Windows XP x64 Edition
Windows XP

Microsoft(R) Windows(R) XP Professional Operating System
Windows XP Professional

Microsoft(R) Windows(R) XP Home Edition Operating System
Windows XP Home Edition

Microsoft(R) Windows Vista(R) Home Basic
Windows Vista Home Basic
Windows Vista

Microsoft(R) Windows Vista(R) Home Premium
Windows Vista Home Premium

Microsoft(R) Windows Vista(R) Ultimate
Windows Vista Ultimate

Microsoft(R) Windows Vista(R) Business
Windows Vista Business

Microsoft(R) Windows Vista(R) Enterprise
Windows Vista Enterprise

Microsoft(R) Windows Vista(R) Home Basic (x64)
Windows Vista (x64)

Microsoft(R) Windows Vista(R) Home Premium (x64)

Microsoft(R) Windows Vista(R) Ultimate (x64)

Microsoft(R) Windows Vista(R) Business (x64)

Microsoft(R) Windows Vista(R) Enterprise (x64)

Microsoft(R) Windows(R) 7 Home Premium
Windows 7

Microsoft(R) Windows(R) 7 Professional

Microsoft(R) Windows(R) 7 Enterprise

Microsoft(R) Windows(R) 7 Ultimate

Microsoft(R) Windows(R) 7 Home Premium (x64)
Windows 7 (x64)

Microsoft(R) Windows(R) 7 Professional (x64)

Microsoft(R) Windows(R) 7 Enterprise (x64)

Microsoft(R) Windows(R) 7 Ultimate (x64)

Single server
SDS

System manager
MGR

Front-end server
FES

Dictionary server
DS

Back-end server
BES

Windows Server 2003 and Windows Server 2008 may be referred to collectively as Windows Server. Windows 2000, Windows XP, Windows Server, Windows Vista, and Windows 7 may be referred to collectively as Windows.

The hosts file means the hosts file stipulated by TCP/IP (including the /etc/hosts file).

This manual also uses the following acronyms:

Acronym | Full name or meaning
ACK | Acknowledgement
ADM | Adaptable Data Manager
ADO | ActiveX Data Objects
ADT | Abstract Data Type
AP | Application Program
API | Application Programming Interface
ASN.1 | Abstract Syntax Notation One
BES | Back End Server
BLOB | Binary Large Object
BMP | Basic Multilingual Plane
BOM | Byte Order Mark
CD-ROM | Compact Disc - Read Only Memory
CGI | Common Gateway Interface
CLOB | Character Large Object
CMT | Cassette Magnetic Tape
COBOL | Common Business Oriented Language
CORBA(R) | Common ORB Architecture
CPU | Central Processing Unit
CSV | Comma Separated Values
DAO | Data Access Object
DAT | Digital Audio Tape
DB | Database
DBM | Database Module
DBMS | Database Management System
DDL | Data Definition Language
DF for Windows NT | Distributing Facility for Windows NT
DF/UX | Distributing Facility/for UNIX
DIC | Dictionary Server
DLT | Digital Linear Tape
DML | Data Manipulate Language
DNS | Domain Name System
DOM | Document Object Model
DS | Dictionary Server
DTD | Document Type Definition
DTP | Distributed Transaction Processing
DWH | Data Warehouse
EUC | Extended UNIX Code
EX | Exclusive
FAT | File Allocation Table
FD | Floppy Disk
FES | Front End Server
FQDN | Fully Qualified Domain Name
FTP | File Transfer Protocol
GUI | Graphical User Interface
HBA | Host Bus Adapter
HD | Hard Disk
HTML | Hyper Text Markup Language
ID | Identification number
IP | Internet Protocol
IPF | Itanium(R) Processor Family
JAR | Java Archive File
Java VM | Java Virtual Machine
JDBC | Java Database Connectivity
JDK | Java Developer's Kit
JFS | Journaled File System
JFS2 | Enhanced Journaled File System
JIS | Japanese Industrial Standard code
JP1 | Job Management Partner 1
JRE | Java Runtime Environment
JTA | Java Transaction API
JTS | Java Transaction Service
KEIS | Kanji processing Extended Information System
LAN | Local Area Network
LDAP | Lightweight Directory Access Protocol
LIP | loop initialization process
LOB | Large Object
LRU | Least Recently Used
LTO | Linear Tape-Open
LU | Logical Unit
LUN | Logical Unit Number
LVM | Logical Volume Manager
MGR | System Manager
MIB | Management Information Base
MRCF | Multiple RAID Coupling Feature
MSCS | Microsoft Cluster Server
MSFC | Microsoft Failover Cluster
NAFO | Network Adapter Fail Over
NAPT | Network Address Port Translation
NAT | Network Address Translation
NIC | Network Interface Card
NIS | Network Information Service
NTFS | New Technology File System
ODBC | Open Database Connectivity
OLAP | Online Analytical Processing
OLE | Object Linking and Embedding
OLTP | On-Line Transaction Processing
OOCOBOL | Object Oriented COBOL
ORB | Object Request Broker
OS | Operating System
OSI | Open Systems Interconnection
OTS | Object Transaction Service
PC | Personal Computer
PDM II E2 | Practical Data Manager II Extended Version 2
PIC | Plug-in Code
PNM | Public Network Management
POSIX | Portable Operating System Interface for UNIX
PP | Program Product
PR | Protected Retrieve
PU | Protected Update
RAID | Redundant Arrays of Inexpensive Disk
RD | Relational Database
RDB | Relational Database
RDB1 | Relational Database Manager 1
RDB1 E2 | Relational Database Manager 1 Extended Version 2
RDO | Remote Data Objects
RiSe | Real time SAN replication
RM | Resource Manager
RMM | Resource Manager Monitor
RPC | Remote Procedure Call
SAX | Simple API for XML
SDS | Single Database Server
SGML | Standard Generalized Markup Language
SJIS | Shift JIS
SNMP | Simple Network Management Protocol
SNTP | Simple Network Time Protocol
SQL | Structured Query Language
SQL/K | Structured Query Language / VOS K`
SR | Shared Retrieve
SU | Shared Update
TCP/IP | Transmission Control Protocol / Internet Protocol
TM | Transaction Manager
TMS-4V/SP | Transaction Management System - 4V / System Product
UAP | User Application Program
UOC | User Own Coding
VOS K | Virtual-storage Operating System Kindness
VOS1 | Virtual-storage Operating System 1
VOS3 | Virtual-storage Operating System 3
WS | Workstation
WWW | World Wide Web
XDM/BASE E2 | Extensible Data Manager / Base Extended Version 2
XDM/DF | Extensible Data Manager / Distributing Facility
XDM/DS | Extensible Data Manager / Data Spreader
XDM/RD E2 | Extensible Data Manager / Relational Database Extended Version 2
XDM/SD E2 | Extensible Data Manager / Structured Database Extended Version 2
XDM/XT | Extensible Data Manager / Data Extract
XDS | Extended Data Server
XFIT | Extended File Transmission program
XML | Extensible Markup Language

Log representations

The OS log is referred to generically as syslogfile. syslogfile is the log output destination specified in /etc/syslog.conf. Typically, the following files are specified as syslogfile.

OS | File
HP-UX | /var/adm/syslog/syslog.log
Solaris | /var/adm/messages or /var/log/syslog
AIX | /var/adm/ras/syslog
Linux | /var/log/messages

Conventions: Diagrams

This manual uses the following conventions in diagrams:

Conventions: Fonts and symbols

The following table explains the fonts used in this manual:

Font
Convention

Bold
Bold type indicates text on a window, other than the window title. Such text includes menus, menu options, buttons, radio box options, or explanatory labels. For example:

From the File menu, choose Open.

Click the Cancel button.

In the Enter name entry box, type your name.

Italics
Italics are used to indicate a placeholder for some actual text to be provided by the user or system. For example:

Write the command as follows:
copy source-file target-file

The following message appears:
A file was not found. (file = file-name)

Italics are also used for emphasis. For example:

Do not delete the configuration file.

Code font
A code font indicates text that the user enters without change, or text (such as messages) output by the system. For example:

At the prompt, enter dir.

Use the send command to send mail.

The following message is displayed:
The password is incorrect.

The following table explains the symbols used in this manual:

Symbol
Convention

|
In syntax explanations, a vertical bar separates multiple items, and has the meaning of OR. For example:
A|B|C means A, or B, or C.

{ }
In syntax explanations, curly brackets indicate that only one of the enclosed items is to be selected. For example:
{A|B|C} means only one of A, or B, or C.

[ ]
In syntax explanations, square brackets indicate that the enclosed item or items are optional. For example:
[A] means that you can specify A or nothing.
[B|C] means that you can specify B, or C, or nothing.

...
In coding, an ellipsis (...) indicates that one or more lines of coding are not shown for purposes of brevity.
In syntax explanations, an ellipsis indicates that the immediately preceding item can be repeated as many times as necessary. For example:
A, B, B, ... means that, after you specify A, B, you can specify B as many times as necessary.

Conventions: KB, MB, GB, and TB

This manual uses the following conventions:

1 KB (kilobyte) is 1,024 bytes.

1 MB (megabyte) is 1,024² bytes.

1 GB (gigabyte) is 1,024³ bytes.

1 TB (terabyte) is 1,024⁴ bytes.

Conventions: Version numbers

The version numbers of Hitachi program products are usually written as two sets of two digits each, separated by a hyphen. For example:

Version 1.00 (or 1.0) is written as 01-00.

Version 2.05 is written as 02-05.

Version 2.50 (or 2.5) is written as 02-50.

Version 12.25 is written as 12-25.

The version number might be shown on the spine of a manual as Ver. 2.00, but the same version number would be written in the program as 02-00.

1. Overview of Real Time SAN Replication

This chapter explains how to set up and operate a Real Time SAN Replication system, a disaster recovery system designed for fast recovery from large-scale disasters such as earthquakes and fires.

Organization of this chapter

1.1 About Real Time SAN Replication

1.2 Importing data to the remote site

1.3 Characteristics of the individual processing methods

1.4 Prerequisite platforms and products

1.1 About Real Time SAN Replication

Organization of this section

(1) Functional overview

(2) Files targeted for update copy

(3) Synchronous copy and asynchronous copy

(1) Functional overview

Even if a disaster, such as an earthquake or fire, makes it difficult to physically recover the system you normally use, you can continue operations by switching to a secondary system that has been prepared at a remote location. The system environment that allows you to do this is called Real Time SAN Replication (RiSe). The site where the system you normally use is located is called the main site, and the remote site where the secondary system is located is called the remote site.

Data at the main site and the remote site is kept on a Hitachi disk array system, and if a change is made to the data at the main site, the TrueCopy or Universal Replicator feature of the Hitachi disk array system is used to import the changed data to the remote site (update copy).

The following figure provides an overview of Real Time SAN Replication.

Figure 1-1 Overview of Real Time SAN Replication

Explanation

Normally, operations are performed using the HiRDB system at main site. When a file at the main site is updated, the updated content is copied to the remote site (update copy). Update copy keeps the data at the main site and the remote site synchronized.

If a large-scale disaster, such as an earthquake or fire, occurs at the main site, making it impossible to quickly restore the system at the main site, you can continue operations by restarting HiRDB at the remote site.

Reference note

Update copy is automatically performed by TrueCopy or Universal Replicator. TrueCopy and Universal Replicator copies data directly between linked Hitachi disk array systems without going through the hosts.

RAID Manager is an optional program product for Hitachi disk array systems and provides commands for controlling and operating TrueCopy and Universal Replicator.

(2) Files targeted for update copy

Update copy targets the files listed below. Whenever these files are updated, the updated information is copied to the same files at the remote site.

Database files (HiRDB files in RDAREAs)

System log files

Synchronization point dump files

Status files

(3) Synchronous copy and asynchronous copy

Update copy processing can be classified into synchronous copy and asynchronous copy. The table below shows the characteristics of synchronous copy and asynchronous copy.

Table 1-1 Characteristics of synchronous copy and asynchronous copy

Item | Synchronous copy | Asynchronous copy
Processing method | Updating at the main site is completed after updating at the remote site is completed (updating at the main site waits for updating at the remote site to be completed). | Updating at the main site is completed without waiting for updating at the remote site to be completed.
Data integrity between the main site and the remote site | Data at the main site always matches the data at the remote site. | Data loss might occur. Consequently, data at the main site might not match the data at the remote site.
Impact on performance# | Transaction processing performance is slowed. The amount of slowing is proportional to the distance between the sites. | There is no impact on performance.

#: Based on the theoretical performance of TrueCopy and Universal Replicator

1.2 Importing data to the remote site

This section explains how data from the main site is imported to the remote site. Real Time SAN Replication provides three processing methods for importing data. Because how you set up and operate your system differs depending on the data import method, the HiRDB administrator must select one of the following methods depending on the system that is being used:

All synchronous method

All asynchronous method

Hybrid method

Organization of this section

1.2.1 All synchronous method

1.2.2 All asynchronous method

1.2.3 Hybrid method

1.2.1 All synchronous method

If you use the all synchronous method, update copying to the remote site is performed using synchronous copy. With synchronous copy, the main site is updated after updating at the remote site is completed (updating at the main site waits for updating at the remote site to be completed). Therefore, when you use the all synchronous method, content updated at the main site is always imported into the remote site. Therefore, even if a disaster abnormally terminates the HiRDB system at the main site, you can continue services by restarting HiRDB at the remote site and be assured that your HiRDB system is in the state that it was in immediately before the abnormal termination.

However, when a file (update-copy target files) is updated at the main site, the main site waits until that update is imported to the remote site. Consequently, transaction performance at the main site may be adversely impacted.

The figure below provides on overview of the all synchronous method. The table that follows shows the processing method used for copying the update to the remote site (using the all synchronous method).

Figure 1-2 Overview of the all synchronous method

Table 1-2 Processing method used for update copying to the remote site (using the all synchronous method)

Files copied to the remote site | Processing method used for update copying
Database files | Synchronous copy
System files | System log files
Synchronization point dump files
Status files

1.2.2 All asynchronous method

If you use the all asynchronous method, update copy to the remote site is performed using asynchronous copy. With asynchronous copy, because the main site is updated without waiting for updating at the remote site to be completed, there is no impact on the transaction performance at the main site.

However, the possibility exists that the updated content of the files at the main site (update-copy target files) might not be imported to the remote site. Consequently, if a disaster abnormally terminates the HiRDB system at the main site and HiRDB is restarted at the remote site, its state at restart might differ from the state that it was in immediately before the abnormal termination. With the all asynchronous method, therefore, continuity of a service that was running on the main site cannot be guaranteed after restart.

The figure below provides on overview of the all asynchronous method. The table that follows shows the processing method used for copying the update to the remote site (using the all asynchronous method).

Figure 1-3 Overview of the all asynchronous method

Table 1-3 Processing method used for update copying to the remote site (using the all asynchronous method)

Files copied to the remote site | Processing method used for update copying
Database files | Asynchronous copy
System files | System log files
Synchronization point dump files
Status files

1.2.3 Hybrid method

If you use the hybrid method, update copying to the remote site is performed as described below.

Update copying of database files is performed using asynchronous copy.

Update copying of system files is performed using synchronous copy.

Information necessary for database recovery, such as system log files, is copied using synchronous copy to guarantee that it is imported to the remote site. Therefore, even if a disaster abnormally terminates the HiRDB system at the main site, the HiRDB system at the remote site can be restarted in the state that it was in immediately before the abnormal termination. The hybrid method is often considered the best processing method for large systems.

Recoverable database files are copied using asynchronous copy, thereby reducing the impact on transaction performance compared to using the all synchronous method.

Reference note

While the hybrid method possesses the advantages of both the all synchronous and all asynchronous methods, it is more difficult to operate than the other methods. For details about the differences in operation, see the following sections:

2. Points to Consider when Designing a System

4.2 Notes on operation when using the hybrid method

Automatic extension of RDAREAs in Table 4-5 Operations that require the databases to be re-synchronized

4.2.2 Notes on initializing a database

6. Error Handling

8.7 Notes on using a shared table (applicable only to the hybrid method)

The figure below provides on overview of the hybrid method. The table below shows the processing method used for update copying to the remote site (using the hybrid method).

Figure 1-4 Overview of the hybrid method

Table 1-4 Processing method used for update copying to the remote site (using the hybrid method)

Files copied to the remote site | Processing method used for update copying
Database files | Asynchronous copy
System files | System log files | Synchronous copy
Synchronization point dump files
Status files

1.3 Characteristics of the individual processing methods

You must consider which of the Real Time SAN Replication processing methods you will use: the all synchronous, all asynchronous, or hybrid method. The table below describes the characteristics of these processing methods.

Table 1-5 Characteristics of the all synchronous, all asynchronous, and hybrid methods

Main classification | Sub-classification | Real Time SAN Replication processing method
All synchronous method | All asynchronous method | Hybrid method
Location of HiRDB files | Synchronous pair volume | Applicable | Not applicable | Applicable
Asynchronous pair volume | Not applicable | Applicable | Applicable
SMPL pair volume | Not applicable | Not applicable | Not applicable
Data loss#1 | Does not occur | Can occur | Does not occur
Transaction processing performance | Performance deterioration caused by having to wait for update copying | Occurs | Does not occur | Occurs
Performance comparison#2 | 44 | 100 | 88
Cost | Initial installation | Somewhat high | High | High
Operation | High | High | High
Combination with other facilities | Facilities that cannot be concurrently executed | None | None | None
Effects when UAP or SQL is executed in the no-log mode or pre-update log acquisition mode | None | None | Transaction performance deteriorates.#3
Operation | Operation of HiRDB at the disaster recovery site | Runs only when a disaster occurs | Runs only when a disaster occurs | Runs only when a disaster occurs
Operation procedures | Simple | Simple | Somewhat complex

#1

If updated data is not correctly imported to the remote site due to an error or an operational mistake by a HiRDB administrator, data loss might occur, or it might not be possible to restart HiRDB at the remote site.

#2

Approximate relative value, where 100 indicates the transaction performance when Real Time SAN Replication is not used. This assumes an environment with 1-Gbps communication speed and a site-to-site transfer distance of 1,500 km. Note that the relative value depends on the attenuation rate between the main site and the remote site.

#3

For details, see 4.2 Notes on operation when using the hybrid method.

1.4 Prerequisite platforms and products

Organization of this section

(1) Prerequisite platforms

(2) Prerequisite products

(1) Prerequisite platforms

One of the following platforms is required. You must use the same platform at the main site and the remote site.

Red Hat Enterprise Linux AS 4 (AMD64 & Intel EM64T)

Red Hat Enterprise Linux ES 4 (AMD64 & Intel EM64T)

Linux 5 (AMD/Intel 64)

(2) Prerequisite products

To use Real Time SAN Replication, Hitachi disk array system series products are required. The table below shows the required products. These prerequisite products must be installed at both the main site and the remote site.

Table 1-6 Prerequisite products

Device name of Hitachi disk array system
Real Time SAN Replication processing method
Required Hitachi disk array system

All synchronous method
All asynchronous method
Hybrid method

9500V
Y#1
N
N

Hitachi TrueCopy basic

RAID Manager

9900V
Y
Y
Y

Hitachi TrueCopy

Hitachi TrueCopy Asynchronous#2

RAID Manager

Adaptable Modular Storage (AMS)
Y
N
N

TrueCopy remote replication

RAID Manager

Network Storage Controller (NSC)
Y
Y
Y

TrueCopy

TrueCopy Asynchronous#2

RAID Manager

Universal Storage Platform (USP)
Y
Y
Y

TrueCopy

TrueCopy Asynchronous#2

RAID Manager

Virtual Storage Platform (VSP)
Y
Y
Y

TrueCopy

Universal Replicator

RAID Manager

Legend:

Y: Can be used

N: Cannot be used

#1

Cannot be used with 9530V.

#2

Required if you use the all asynchronous or hybrid method.

2. Points to Consider when Designing a System

This chapter explains the points to consider when designing a system.

Organization of this chapter

2.1 Selecting a protection mode (not applicable to the all asynchronous method)

2.2 Points to consider when setting up a HiRDB environment

2.3 Points to consider when setting up a RAID Manager environment

2.4 Points to consider when creating HiRDB file system areas

2.5 Points to consider when designing volumes

2.1 Selecting a protection mode (not applicable to the all asynchronous method)

If you choose the all synchronous or hybrid method, you must select a protection mode. A protection mode specifies what HiRDB does when synchronous copy to the remote site fails. The table below shows the criteria for selecting a protection mode.

Note that you specify the selected protection mode in the pd_rise_fence_level operand.

Table 2-1 Criteria for selecting a protection mode

Protection mode
What HiRDB does when synchronous copy fails
Advantage
Disadvantage

data
Stops updating at the main site (updating of the volume containing the file for which synchronous copy failed).
Integrity is always maintained between the main site and the remote site.
An error at the remote site impacts part, or all, of the main site. Most critically, when a link failure occurs between the main site and the remote site, none of the volumes at the main site can be updated. In some cases, this results in the HiRDB system at the main site terminating abnormally.

never
Continues updating at the main site.
Transactions at the main site continue even when a synchronous copy error occurs.
The following may occur until the error is eliminated and integrity can be restored between the main site and the remote site.

The HiRDB system at the remote site cannot be restarted.

Some data may be lost during site switchover.

Furthermore, because the remote site may not be able to detect that a failure has occurred, the integrity of the applicable paired logical volume groups must be monitored and guaranteed.

Reference note

Asynchronous copy always operates in the never protection mode.

2.2 Points to consider when setting up a HiRDB environment

This section explains the points to consider when setting up a HiRDB environment.

Organization of this section

2.2.1 Items that must be the same for the main site and the remote site

2.2.2 Items to be changed at the remote site

2.2.3 Specifying system definition operands

2.2.1 Items that must be the same for the main site and the remote site

You must configure a HiRDB system at both the main site and the remote site. The following items must be the same for the main site and the remote site:

Versions of HiRDB and related program products

HiRDB administrator's environment (user ID, group ID, and environment variables)

Absolute path name of the HiRDB directory

HiRDB system definition settings#

Absolute path names of HiRDB files

#

For the operands described in 2.2.2 Items to be changed at the remote site, their values must be changed at both the main site and the remote site.

Note

HiRDB does not check whether these items match between the main site and the remote site. If these items do not match, correct operation of HiRDB cannot be guaranteed.

Reference note

For the HORCMINST operand, specify RAID Manager's instance number. For this operand, the same value must be specified at the main site and the remote site.

2.2.2 Items to be changed at the remote site

The standard host name of the HiRDB system at the main site and the standard host name of the HiRDB system at the remote site must be changed. To do so, change the values specified for the system definition operands listed in the following table at both the main site and the remote site.

Table 2-2 Operands whose value must be changed at the main site and the remote site

Operand name | Operand description | Specification value at the remote site
-x option of the pdunit operand | Specify the host name of the server machine on which the unit was defined or its FQDN. | Specify the host name at the remote site or its FQDN.
-c option of the pdunit operand | Specify the host name of the secondary system or its FQDN. | Specify the host name of the secondary system at the remote site or its FQDN.
-x option of the pdstart operand | Specify the host name specified in the -x option of the pdunit operand or its FQDN. | Specify the host name at the remote site or its FQDN.
-m and -n options of the pdstart operand | If you are using the multi-connection address facility, specify the host name of the front-end server to which the HiRDB client connects, or its FQDN.
pd_hostname operand | Specify the standard host name of the server machine on which the unit was defined. | Specify the standard host name at the remote site.

Note

HiRDB does not check whether the values of these operands differ between the main site and the remote site. If the values of these operands are the same, correct operation of HiRDB cannot be guaranteed.

2.2.3 Specifying system definition operands

Organization of this subsection

(1) Operands to be specified

(2) Operands subject to restrictions

(1) Operands to be specified

The following table shows the operands you must specify when using Real Time SAN Replication.

Table 2-3 Operands that you must specify

Operand name | Real Time SAN Replication processing method
All synchronous method | All asynchronous method | Hybrid method
pd_rise_use | Y | Y | Y
pd_rise_pairvolume_combination | sync | async | hybrid
pd_rise_fence_level | data or never# | Omitted | data or never#
pd_rise_disaster_mode | Omitted | Omitted | normal
HORCMINST | RAID Manager's instance number

#: Specifies the protection mode to be used.

(2) Operands subject to restrictions

The table below shows the operands that are subject to restrictions when Real Time SAN Replication is used. If you do not observe these restrictions, the KFPS01896-E error message is output when the pdconfchk command is executed or HiRDB is started.

Table 2-4 System definition operands subject to restrictions

Operand name | Restriction
pd_mode_conf | Specify MANUAL1 or MANUAL2.
pd_dbsync_point | When using the hybrid method, specify sync or omit this operand. When using the all synchronous or all asynchronous method, there are no restrictions.
pd_hostname | Cannot be omitted. Specify the standard host name of the main site or the remote site.

2.3 Points to consider when setting up a RAID Manager environment

This section explains the points to consider when setting up a RAID Manager environment. For details about setting up a RAID Manager environment, see the RAID Manager documentation.

Organization of this section

(1) RAID Manager administrator

(2) Instance

(3) RAID Manager's command execution environment

(1) RAID Manager administrator

For HiRDB to send queries to RAID Manager, you must assign RAID Manager administrator privileges to the HiRDB administrator.

(2) Instance

The paired volumes on which the update copy target files are located must be operated as a single instance. Although you can specify any number for the instance number, if the system is combined with ShadowImage (HOMRCF), specify a number that is different from the instance number used for ShadowImage. Specify the instance number in the HORCMINST operand. When doing this, specify the same number at the main site and the remote site.

(3) RAID Manager's command execution environment

For HiRDB to issue a RAID Manager command to query the state of TrueCopy or Universal Replicator, you must set up the environment so that a RAID Manager command issued from HiRDB can function as a TrueCopy or Universal Replicator command.

2.4 Points to consider when creating HiRDB file system areas

This section explains the points to consider when creating HiRDB file system areas.

Organization of this section

2.4.1 File classifications

2.4.2 Notes on creating HiRDB file system areas

2.4.3 HiRDB file system area configuration examples

2.4.1 File classifications

In Real Time SAN Replication, a concept called file classification specifies a classification that is determined by a combination of a HiRDB file system area type and a HiRDB file. The following table shows the file classifications used in Real Time SAN Replication.

Table 2-5 File classifications used in Real Time SAN Replication

HiRDB file system area type# | Specification of the -k option of the pdfmkfs command | File classification
HiRDB file system area for RDAREAs | DB | DB
HiRDB file system area for shared RDAREAs | SDB | DB
HiRDB file system area for system files | System log files | SYS | LOG
Synchronization point dump files | SPD
Unit status files | USTS
Server status files | SSTS

#

There is no classification for any HiRDB file system area file that is not described above (for example, unload log files).

2.4.2 Notes on creating HiRDB file system areas

Note the following when creating HiRDB file system areas:

Create the HiRDB file system areas for storing update-copy target files (HiRDB file system area for RDAREAs and HiRDB file system area for system files) as character special files.

When using the pdfmkfs command to create the HiRDB file system areas described in Table 2-5, specify DB, SDB, or SYS for the -k option. Do not specify SVR for the -k option or omit this option.

If you are using the all synchronous or hybrid method, create separate HiRDB file system areas for the following system files:

HiRDB file system area for system log files

HiRDB file system area for synchronization point dump files

HiRDB file system area for unit status files

HiRDB file system area for server status files

If you are using the all synchronous or hybrid method on a HiRDB/Parallel Server, make sure only a single server (or unit) uses any particular HiRDB file system area. In addition, make sure that only a single updatable back-end server uses any particular HiRDB file system area for shared RDAREAs.

Note

HiRDB does not check whether these conditions are satisfied. If these conditions are not satisfied, correct operation of HiRDB cannot be guaranteed.

2.4.3 HiRDB file system area configuration examples

This subsection provides configuration examples of a HiRDB file system area when the all synchronous or hybrid method is used on a HiRDB/Parallel Server.

Organization of this subsection

(1) Correct example

(2) Incorrect examples

(1) Correct example

Explanation

File classifications are the same and the same servers are used.

(2) Incorrect examples

Explanation

Different servers (DS and BES1) are used.

Explanation

Different servers (BES1 and BES2) are used.

Explanation

Different file classifications (LOG, SPD, and SSTS) are used.

Explanation

An audit trail file, which does not have a classification, is present.

2.5 Points to consider when designing volumes

This section explains the points to consider when designing volumes.

Organization of this section

2.5.1 Points to consider when designing paired volumes

2.5.2 Points to consider when designing paired logical volumes

2.5.3 Points to consider when designing paired logical volume groups

2.5.4 Paired volume configuration examples

2.5.5 System configuration example

2.5.1 Points to consider when designing paired volumes

The following table lists the points to consider when designing paired volumes that store update-copy target files.

Table 2-6 Points to consider when designing paired volumes

Item | Points to consider
Association with HiRDB file system areas | Allocate a single paired volume to each HiRDB file system area (do not use LVM to create a single logical volume (LV) from multiple paired volumes and store HiRDB file system areas on that LV).
Capacity | The capacity of a paired volume must be equal to or greater than the capacity of the associated HiRDB file system area.
Total count | Number of HiRDB file system areas to be update-copied + reserve count

Note

HiRDB does not check whether these conditions are satisfied. If these conditions are not satisfied, correct operation of HiRDB cannot be guaranteed.

2.5.2 Points to consider when designing paired logical volumes

Following the RAID Manager documentation, assign paired logical volumes to paired volumes.

2.5.3 Points to consider when designing paired logical volume groups

Organization of this subsection

(1) Naming rules

(2) Correspondence with paired logical volumes

(3) Configuration example

(1) Naming rules

Assign names to paired logical volume groups according to the naming rules described in the following table.

Table 2-7 Naming rules for paired logical volume groups

File classification
Real Time SAN Replication processing method

All synchronous or hybrid method
All asynchronous method

DB
aaaa_bb....bb_DB
aaaa_ALL
Assign a single paired logical volume group to all file classifications.

LOG
aaaa_bb....bb_LOG

SPD
aaaa_bb....bb_SPD

USTS
aaaa_cccc_USTS

SSTS
aaaa_bb....bb_SSTS

Legend:

aaaa: HiRDB identifier

bb....bb: Server name

cccc: Unit identifier

(2) Correspondence with paired logical volumes

In the all synchronous and hybrid methods, if paired logical volumes are designed correctly, the file classifications of the files located in the paired logical volumes, and the units and servers that use these files, will all be identical. If file classifications, or the units or servers used, are different, check the notes in 2.4.2 Notes on creating HiRDB file system areas.

(3) Configuration example

Place the update-copy target files (HiRDB file system area) on a paired logical volume group (paired logical volume). The following figure shows a configuration example of file locations using the all synchronous or hybrid method.

Figure 2-1 File location configuration example

Legend:

HRD1: HiRDB identifier

UNT1: Unit identifier

sds1: Server name

RD: User RDAREA file

MAST: Master directory RDAREA file

DDIC: Data dictionary RDAREA file

LOG: System log file

SPD: Synchronization point dump file

SSTS: Server status file

USTS: Unit status file

Hint

Generate a paired logical volume group for each server (or unit) that uses file classifications and files.

Position update-copy target files in a paired logical volume group in which the file classification matches the server (or unit) that uses files.

You cannot position files whose file classification does not match the server that uses files in the same paired logical volume group.

Correspondence relationship

A paired logical volume group consists of multiple paired logical volumes.

Each paired logical volume corresponds to a single paired volume.

Each paired volume corresponds to a single HiRDB file system area.

Multiple files can be stored in a single HiRDB file system area.

2.5.4 Paired volume configuration examples

Figure 2-2 through Figure 2-4 show paired volume configuration examples when Real Time SAN Replication is used on a HiRDB/Single Server.

Items common to Figures 2-2 through 2-4

HiRDB identifier: HRD1

Unit identifier: UNT1

Server name: sds1

MASTER: Master directory RDAREA

DDIC: Data dictionary RDAREA

DDIR: Data directory RDAREA

USER: User RDAREA

LOG_nx: System log file
n: Indicates a generation between 1 and 6. x: A and B indicate system A and system B files, respectively.

SPD_nx: Synchronization point dump file
n: Indicates a generation between 1 and 6. x: A and B indicate system A and system B files, respectively.

USTS_nx: Unit status files
n: Indicates a generation between 1 and 6. x: A and B indicate system A and system B files, respectively.

SSTS_nx: Server status files
n: Indicates a generation between 1 and 6. x: A and B indicate system A and system B files, respectively.

LUnn: Pair volume name
n: A number (1 through 16) indicating that paired volume names having the same number are formed into a paired volume.

The meanings of the items in the figure are as follows:

Figure 2-2 Paired volume configuration example (all synchronous method)

Figure 2-3 Paired volume configuration example (all asynchronous method)

Figure 2-4 Paired volume configuration example (hybrid method)

2.5.5 System configuration example

The following figure shows an example of a system configuration when the hybrid method is used (for a HiRDB/Single Server).

Figure 2-5 Example of a system configuration when the hybrid method is used (for a HiRDB/Single Server)

Legend:

DB: Database file

LOG: System log file

SPD: Synchronization point dump file

USTS: Unit status file

SSTS: Server status file

3. Building a System

This chapter explains how to build a disaster recovery system.

Organization of this chapter

3.1 Building a disaster recovery system

3.2 Tasks required to build a disaster recovery system

3.1 Building a disaster recovery system

The following figure shows the procedure for building a disaster recovery system.

Figure 3-1 Procedure for building a disaster recovery system

Note:

The numbers in the above figure correspond to the item numbers in 3.2 Tasks required to build a disaster recovery system.

3.2 Tasks required to build a disaster recovery system

This section explains the tasks required to build a disaster recovery system.

Organization of this section

3.2.1 Building the RAID Manager environment

3.2.2 Building the HiRDB environment at the main site

3.2.3 Checking the HiRDB configuration at the main site

3.2.4 Taking control over the paired logical volume groups (transfer control from the main site to the remote site)

3.2.5 Checking the status of paired logical volume groups at the remote site

3.2.6 Building the HiRDB environment at the remote site

3.2.7 Checking the HiRDB configuration at the remote site

3.2.8 Taking control over the paired logical volume groups (transfer control from the remote site to the main site)

3.2.9 Checking the status of the paired logical volume groups at the main site

3.2.1 Building the RAID Manager environment

Organization of this subsection

(1) RAID Manager's config file

(2) Starting the RAID Manager instances

(3) Generating paired logical volume groups

(1) RAID Manager's config file

Specify the paired logical volume groups in the RAID Manager's config file (HORCM_CONF). The following table shows the items that are associated in the RAID Manager's config file.

Table 3-1 Items associated in RAID Manager's config file

Item name | RAID Manager's config file (HORCM_CONF)
Pair logical volume | HORCM_DEV dev_name parameter
Pair logical volume group | HORCM_DEV dev_group parameter

(2) Starting the RAID Manager instances

Start the RAID Manager instances, built in (1) RAID Manager's config file, at both the main and remote sites. To start the RAID Manager instances, use RAID Manager's horcmstart command. For details about the horcmstart command, see the RAID Manager documentation.

(3) Generating paired logical volume groups

Using RAID Manager's paircreate command, generate paired logical volume groups. During this process, specify the volume at the main site in the P-VOL operand. For details about the paircreate command, see the RAID Manager documentation.

The fence level (the value of the -f option) you specify when executing the paircreate command differs depending on the Real Time SAN Replication processing method (the value of the pd_rise_pairvolume_combination operand) and the protection mode (the value of the pd_rise_fence_level operand). The following table shows these relationships.

Table 3-2 Fence level to be specified when executing the paircreate command

Real Time SAN Replication processing method (value of the pd_rise_pairvolume_combination operand) | Protection mode (value of the pd_rise_fence_level operand) | Pair logical volume group name | Fence level (value of the -f option of the paircreate command)
sync | data | aaaa_bb....bb_DB | data
aaaa_bb....bb_LOG
aaaa_cccc_USTS
aaaa_bb....bb_SSTS
aaaa_bb....bb_SPD
never | aaaa_bb....bb_DB | never
aaaa_bb....bb_LOG
aaaa_cccc_USTS
aaaa_bb....bb_SSTS
aaaa_bb....bb_SPD
async | -- | aaaa_ALL | async
hybrid | data | aaaa_bb....bb_DB | async
aaaa_bb....bb_LOG | data
aaaa_cccc_USTS
aaaa_bb....bb_SSTS
aaaa_bb....bb_SPD
never | aaaa_bb....bb_DB | async
aaaa_bb....bb_LOG | never
aaaa_cccc_USTS
aaaa_bb....bb_SSTS
aaaa_bb....bb_SPD

Legend:

aaaa: HiRDB identifier

bb....bb: Server name

cccc: Unit identifier

--: Not applicable

The consistency group you specify when creating an asynchronous paired volume also differs depending on the Real Time SAN Replication processing method (the value of the pd_rise_pairvolume_combination operand). The following table shows this relationship.

Table 3-3 Consistency group (value of the -f option) to be specified when executing the paircreate command

Real Time SAN Replication processing method (value of the pd_rise_pairvolume_combination operand) | Pair logical volume group name | Consistency group ID (value of the -f option of the paircreate command)
sync | There is no asynchronous paired volume.
async | aaaa_ALL | Assign all HiRDB paired logical volume groups inside the HiRDB system to the same consistency group.
hybrid | aaaa_bb....bb_DB | Assign individual paired logical volume groups to different consistency groups.

Legend:

aaaa: HiRDB identifier

bb....bb: Server name

An example of creating a paired logical volume group is described below. The following system configuration is assumed.

HiRDB identifier: HRD1

Unit identifier: UNT1

Server name: sds1

System definition example

set pd_system_id = HRD1
set pd_rise_use = Y
set pd_rise_pairvolume_combination = hybrid
set pd_rise_fence_level = data
pdunit -u UNT1 -x host1 -d "/opt/HiRDB_S"
pdstart -t SDS -s sds1 -u UNT1

paircreate command execution example (executed from the main site)

paircreate -g HRD1_sds1_DB -f async -vl
paircreate -g HRD1_sds1_LOG -f data -vl
paircreate -g HRD1_UNT1_USTS -f data -vl
paircreate -g HRD1_sds1_SSTS -f data -vl
paircreate -g HRD1_sds1_SPD -f data -vl

3.2.2 Building the HiRDB environment at the main site

Build the HiRDB system at the main site. For details about how to build a HiRDB system, see the HiRDB Version 9 Installation and Design Guide.

Note

Make sure that the correspondence between HiRDB file system areas and the paired volumes is correct. If there is a mistake, you might loose data or you may not be able to restart HiRDB at the remote site.

The following table describes the operands related to Real Time SAN Replication. For a description of individual operands, see the manual HiRDB Version 9 System Definition.

Table 3-4 Operands related to Real Time SAN Replication

Operand name
Description or notes

pd_rise_use
Specifies whether to use Real Time SAN Replication.

pd_rise_pairvolume_combination
Specifies the Real Time SAN Replication processing method.

pd_rise_disaster_mode
If the Real Time SAN Replication processing method is set to hybrid, this operand specifies whether to maintain data integrity by synchronizing the main site with the remote site.

pd_rise_fence_level
Specifies the processing to be performed by HiRDB if an error occurs that causes the synchronous coping of data to the volumes at the remote site (transfer of all or part of the HiRDB files) to fail (specifies a fence level).

HORCMINST
Specifies the instance number of the RAID Manager that defined the paired logical volume.

pd_mode_conf
Specify MANUAL1 or MANUAL2 when Real Time SAN Replication is to be used (specify Y for the pd_rise_use operand). If you specify AUTO for this operand when Y is specified for the pd_rise_use operand, an error occurs during the HiRDB startup process.

pd_dbsync_point
Specify sync when you specify Y for the pd_rise_use operand and hybrid for the pd_rise_pairvolume_combination operand.

pd_rdarea_open_attribute
Note the following if you specify SCHEDULE for this operand:

When the Real Time SAN Replication processing method is set to hybrid, at least 2 seconds of overhead per transaction occurs when a transaction terminates.

When the Real Time SAN Replication processing method is set to hybrid, the system waits for the database to be synchronized with the remote site. At least number of RDAREAs accessed x 2 seconds of overhead might occur when a transaction terminates.

pd_spool_cleanup_interval_level
pd_spool_cleanup_level
The transaction information file, created when Real Time SAN Replication is being used, will be deleted based on the value specified for this operand.

pd_hostname
This operand must be specified when you use Real Time SAN Replication. Specify the main site's standard host name in the main site's pd_hostname operand, and specify the remote site's standard host name in the remote site's pd_hostname operand.

3.2.3 Checking the HiRDB configuration at the main site

After you have finished setting up RAID Manager's environment and setting up the environment for the HiRDB system at the main site, execute the pdconfchk and pdrisechk commands to check the configuration of the HiRDB system at the main site.

Note that there are items that these commands cannot check. Therefore, the HiRDB administrator must manually check the items that cannot be checked by these commands. The following table lists the HiRDB configuration items, and indicates whether they can or cannot be checked by these commands.

Table 3-5 HiRDB configuration items and whether they can or cannot be checked by the commands

Item | Check item | Checked by the command?
pdconfchk | pdrisechk
1 | Whether the required operands are specified | Y | Y
2 | Whether the RAID Manager configuration file is correctly specified | N | N
3 | Whether the RAID Manager instance number is correct#1 | N | N
4 | Whether the RAID Manager instance has started#2 | N | N
5 | Whether all paired logical volume groups that require update copy are present | N | Y#3
6 | For the volume attribute of the paired logical volume group in item 5, whether the site that executed the pdrisechk command is set to P-VOL | N | Y
7 | For the pair status of the paired logical volume group in item 5, whether the site that executed the pdrisechk command is set to PAIR | N | Y
8 | Whether the fence level of the paired logical volume group in item 5 satisfies the specification indicated in Table 3-2 Fence level to be specified when executing the paircreate command | N | Y
9 | Of the paired logical volume groups in item 5, whether the asynchronous paired volume has correctly set up a consistency group according to the rules described in Table 3-3 Consistency group (value of the -f option) to be specified when executing the paircreate command) | N | N
10 | Whether all HiRDB files are present | Y#4 | N
11 | Whether the HiRDB files are located in the correct paired logical volume group according to the rules described in 2.5.3(1) Naming rules | N | N

Legend:

Y: Can be checked

N: Cannot be checked. Must be manually checked by the HiRDB administrator.

#1

If the instance number (HORCMINST) of the RAID Manager that you specify in HiRDB points to another existing instance, items 5 through 9 are not correctly checked.

#2

If the instance corresponding to the instance number (HORCMINST) of the RAID Manager that you specify in HiRDB is not active, items 5 through 9 are not correctly checked.

#3

If you are using a floating server (back-end server for fetching data) and the KFPS04680-E error message is output, indicating that there is no paired logical volume group that corresponds to the HiRDB file in which RDAREAs are located, ignore it.

#4

N (cannot be checked) if the -n option is specified.

3.2.4 Taking control over the paired logical volume groups (transfer control from the main site to the remote site)

Using RAID Manager's horctakeover command, take control over the paired logical volume groups in which the update-copy target files are located at the remote site. During this process, the volume attributes at the remote site are set to P-VOL. Use the command to take control over all paired logical volume groups. For details about the horctakeover command, see the RAID Manager documentation.

An example of taking control over paired logical volume groups is shown below. The following system configuration is assumed.

HiRDB identifier: HRD1

Unit identifier: UNT1

Server name: sds1

System definition example

set pd_system_id = HRD1
set pd_rise_use = Y
set pd_rise_pairvolume_combination = hybrid
set pd_rise_fence_level = data
pdunit -u UNT1 -x host1 -d "/opt/HiRDB_S"
pdstart -t SDS -s sds1 -u UNT1

horctakeover command execution example (executed from the remote site)

horctakeover -g HRD1_sds1_DB -t 10000
horctakeover -g HRD1_sds1_LOG
horctakeover -g HRD1_UNT1_USTS
horctakeover -g HRD1_sds1_SSTS
horctakeover -g HRD1_sds1_SPD

3.2.5 Checking the status of paired logical volume groups at the remote site

After you have taken control over the paired logical volume groups, use RAID Manager's pairvolchk command to check the status of the paired logical volume groups. If the attribute and status of the paired logical volume groups at the remote site are P-VOL and PAIR, respectively, after the takeover, the takeover was successful. For details about the pairvolchk command, see the RAID Manager documentation.

3.2.6 Building the HiRDB environment at the remote site

Build the HiRDB system at the remote site. For details about how to build a HiRDB system, see the HiRDB Version 9 Installation and Design Guide.

Note

Make sure that the correspondences between HiRDB file system areas and the paired volumes are correct.

At the remote site, certain HiRDB files (with file classifications DB, USTS, SSTS, LOG, and SPD) will be created when the files on the main site are copied and synchronized. Therefore, do not create these files at the remote site.

For details about the operands related to Real Time SAN Replication, see Table 3-4 Operands related to Real Time SAN Replication. For an explanation of individual operands, see the manual HiRDB Version 9 System Definition.

3.2.7 Checking the HiRDB configuration at the remote site

After you have finished building a HiRDB environment at the remote site, execute the pdconfchk and pdrisechk commands to check the configuration of the HiRDB system at the remote site. Note that there are items that these commands cannot check. Therefore, the HiRDB administrator must manually check the items that are not checked by these commands. For details, see Table 3-5 HiRDB configuration items and whether they can or cannot be checked by the commands.

3.2.8 Taking control over the paired logical volume groups (transfer control from the remote site to the main site)

Using RAID Manager's horctakeover command, take control over the paired logical volume groups in which the update-copy target files are located at the main site. During this process, set the volume attributes at the main site to P-VOL. Use the command to take control over all paired logical volume groups. For details about the horctakeover command, see the RAID Manager documentation.

3.2.9 Checking the status of the paired logical volume groups at the main site

After you have taken control over the paired logical volume groups, use RAID Manager's pairvolchk command to check the status of the paired logical volume groups. If the attribute and status of the paired logical volume groups at the main site are P-VOL and PAIR, respectively, after the takeover, the takeover was successful. For details about the pairvolchk command, see the RAID Manager documentation.

4. Operations at the Main Site

This chapter explains how to perform operations at the main site during normal operation.

Organization of this chapter

4.1 HiRDB startup method

4.2 Notes on operation when using the hybrid method

4.3 Notes on executing RAID Manager commands

4.1 HiRDB startup method

This section explains how to start the HiRDB system at the main site.

Organization of this section

(1) Procedure for starting the HiRDB system at the main site

(2) Checking the status of paired logical volume groups

(1) Procedure for starting the HiRDB system at the main site

The procedure for starting the HiRDB system at the main site follows:

Procedure

Start the instance of RAID Manager that is being used by HiRDB.

Check the status of paired logical volume groups. For details about how to check them, see 4.1(2) Checking the status of paired logical volume groups.

Execute the pdstart command to start the HiRDB system at the main site.

Note

Do not execute the pdstart command using the system startup initialization command (for example, /sbin/rc) provided for each platform.

(2) Checking the status of paired logical volume groups

Before starting the HiRDB system at the main site, check the volume attribute and pair status of the paired logical volume groups. Depending on their combination, it may not be possible to start HiRDB or to switch to the remote site. Use the following procedure to check whether it is possible to start HiRDB and to switch to the remote site.

Procedure

Check the volume attribute and pair status of the paired logical volume groups. Check each paired logical volume group, and determine whether it is possible to start the HiRDB system at the main site and to switch to the remote site, using the information in Table 4-1. Do this for all paired logical volume groups.

Using the information in Table 4-2, determine whether it is possible to start the HiRDB system at the main site.

Using the information in Table 4-3, determine whether it is possible to switch to the remote site.

For details about the corrective action to take if it is not possible to start the HiRDB system at the main site or to switch to the remote site due to an error, see 6. Error Handling.

Table 4-1 Whether it is possible to start the HiRDB system at the main site and whether it is possible to switch to the remote site

Real Time SAN Replication processing method | Protection mode | Volume attribute | Pair status | Whether each paired logical volume group's HiRDB can be started | Whether each paired logical volume group can be switched to the remote site
All synchronous or hybrid method | data | SMPL | None | Prohibited | N
S-VOL | Any | Prohibited | A
P-VOL | COPY | Possible#3 | N
PSUE | Not possible | Y#1
PSUS | Prohibited | N
PAIR | Possible | Y#1
never | SMPL | None | Possible | N
S-VOL | Any | Prohibited | A
P-VOL | COPY | Possible | N
PSUE | Possible | N
PSUS | Possible | N
PAIR | Possible | Y#1
All asynchronous method | -- | SMPL | None | Possible | N
S-VOL | Any | Prohibited | A
P-VOL | COPY | Possible | N
PSUE | Possible | Y#2
PSUS | Possible | N
PAIR | Possible | Y#2

Legend:

--: Not applicable

Pair status:

None: No pair status is assigned.

Any: Any pair status is assigned.

Whether each paired logical volume group's HiRDB can be started:

Possible: The HiRDB system at the main site can be started.

Not possible: The HiRDB system at the main site cannot be started.

Prohibited: HiRDB must not be started because of the combination of the volume attribute and pair status.

Whether each paired logical volume group can be switched to the remote site:

Y: Can be switched to the remote site.

A: Already switched to the remote site.

N: Switching to the remote site may not be successful.

#1: No data loss occurs.

#2: Data loss occurs.

#3: If the hybrid method is used, HiRDB can be started only when the database pair status is PAIR.

Table 4-2 Starting the HiRDB system at the main site

Whether each paired logical volume group's HiRDB can be started#1 | Whether HiRDB can be started when combined
Possible | Not possible | Prohibited
Yes | Yes | Yes | Prohibited
No | Not possible#2
No | Yes | Prohibited
No | Possible
No | Yes | Yes | Prohibited
No | Not possible
No | Yes | Prohibited

Legend:

Possible: The HiRDB system at the main site can be started.

Not possible: The HiRDB system at the main site cannot be started.

Prohibited: HiRDB must not be started because of the combination of the volume attribute and pair status.

#1

Same as Whether each paired logical volume group's HiRDB can be started in Table 4-1 Whether it is possible to start the HiRDB system at the main site and whether it is possible to switch to the remote site

#2

If you shut down a paired logical volume group that cannot be started, you man then be able to start HiRDB.

Table 4-3 Whether it is possible to switch to the remote site

Whether each paired logical volume group can be switched to the remote site# | Whether it is possible to switch to the remote site when combined
Y | A | N
Yes | Yes | Yes | N
No | N
No | Yes | N
No | Y
No | Yes | Yes | N
No | A
No | Yes | N

Legend:

Y: Can be switched to the remote site.

A: Already switched to the remote site.

N: Switching to the remote site may not be successful.

#

Same as Whether each paired logical volume group can be switched to the remote site in Table 4-1 Whether it is possible to start the HiRDB system at the main site and whether it is possible to switch to the remote site

4.2 Notes on operation when using the hybrid method

This section explains operation details applicable when using the hybrid method.

Organization of this section

4.2.1 When database updates must be synchronized between the main site and the remote site

4.2.2 Notes on initializing a database

4.2.1 When database updates must be synchronized between the main site and the remote site

If you perform any of the operations described in Table 4-4 or Table 4-5 when using the hybrid method, the data that was updated during that operation cannot be recovered from the system log file. Therefore, the databases on the main site and the remote site need to be re-synchronized. HiRDB performs the actual synchronization process, but the resulting overhead causes the processing time for the operations described in Table 4-4 or Table 4-5 to be longer than normal. Furthermore, if the KFPS04680-E error message is output when performing these operations, data recovery cannot be guaranteed for the RDAREAs updated by these operations after switching sites. Table 4-4 shows the commands that require the databases to be re-synchronized and Table 4-5 shows the operations that require the databases to be re-synchronized.

Table 4-4 Commands that require the databases to be re-synchronized

Command name | Option | Command description | Overhead | RDAREA for which data recovery is not guaranteed if the KFPS04680-E message is output
pdhold | -s | Synchronization hold | 2 (seconds for each RDAREA specified in the -r option) | RDAREA specified in the -r option
-c | Command hold and closure
pdclose | -- | RDAREA closure
pdrels | -- | RDAREA hold release
pdorbegin | -r | Committing an online-reorganized database | 2 (seconds for each RDAREA specified in the -r option) | RDAREA specified in the -r option
-s | 2 (seconds for each RDAREA specified in the -s option) | RDAREA of the server specified in the -s option
-t | 2 (seconds for each RDAREA storing the table specified in the -t option) | RDAREA storing the table specified in the -t option
pdorend | When the -s option is omitted | Reflection processing of online reorganization | 2 (seconds for each RDAREA that is in the online reorganization hold state) | RDAREA that is in the online reorganization hold state
-s | 2 (seconds for each RDAREA that is in the online reorganization hold state out of the RDAREAs of the server specified in the -s option) | RDAREA that is in the online reorganization hold state out of the RDAREAs of the server specified in the -s option

Legend:

--: All options apply.

Table 4-5 Operations that require the databases to be re-synchronized

Operation | Overhead | RDAREA for which data recovery is not guaranteed if the KFPS04680-E error message is output
Commit or rollback | Updating using HiRDB Text Search Plug-in | 2 (seconds for each updated RDAREA) | User LOB RDAREAs targeted for updating
Updating of BLOB data
Updating using pre-update log acquisition mode or no-log mode | User RDAREAs and user LOB RDAREAs targeted for updating
Updating of shared RDAREAs | Shared RDAREAs targeted for updating
Updating of RDAREAs whose open attribute is SCHEDULE | User RDAREAs and user LOB RDAREAs targeted for updating
DISCONNECT | Updating of shared RDAREAs | Shared RDAREAs targeted for updating
Execution of definition SQL on shared table# | 2 seconds | Shared RDAREA on which definition SQL is executed
Execution of LOCK TABLE with lock mode specification on shared table# | Shared RDAREA on which LOCK TABLE is executed
Automatic extension of RDAREAs | 2 (seconds for each operation) | RDAREA for which automatic extension is executed

#: Applicable to a HiRDB/Parallel Server, but not to a HiRDB/Single Server.

4.2.2 Notes on initializing a database

The pdinit command, which you execute to initialize a database, updates the master directory RDAREA without outputting an update log. Therefore, after normal termination of the pdinit command and before starting online transactions, execute the pairsyncwait command (with the -g aaaa_bb....bb_DB -t 600 options specified) on the paired logical volume group that stores the RDAREAs used by the single server or dictionary server. Confirm that the command terminates normally with DONE. The following figure shows the procedure for initializing a database.

Figure 4-1 Procedure for initializing a database

4.3 Notes on executing RAID Manager commands

You use RAID Manager commands to perform operations on paired logical volume groups. A separate RAID Manager command is executed for each paired logical volume group. When executing RAID Manager commands, you must observe the conditions stated for each command as described in the RAID Manager documentation.

Organization of this section

(1) Executability of RAID Manager commands

(2) Period during which switchover to the remote site cannot be guaranteed

(1) Executability of RAID Manager commands

Whether a specific RAID Manager command can be executed depends on whether HiRDB is running. The following tables show the executability of RAID Manager commands.

Table 4-6 Executability of RAID Manager commands (1 of 2)

Command name | Function | Executability of RAID Manager command
When HiRDB is running | When HiRDB is stopped
horcmshutdown | Stop RAID Manager | D | Y
horctakeover | Take control over paired logical volume groups | N | Y
paircreate | Generate a paired logical volume group | D | Y#
pairsplit | Split a paired logical volume group | D | Y#
pairresync | Re-synchronize a paired logical volume group | D | Y#

Legend:

Y: Can be executed.

D: Differs depending on the condition. For details, see Table 4-7.

N: Cannot be executed.

#

Following command execution, switchover to the remote site cannot be guaranteed for a period of time. For details, see 4.3(2) Period during which switchover to the remote site cannot be guaranteed.

Table 4-7 Executability of RAID Manager commands (2 of 2)

Real Time SAN Replication processing method | Protection mode | Executability of RAID Manager command
All synchronous method | data | N
never | Y#
All asynchronous method | -- | Y#
Hybrid method | data | N
never | Y#

Legend:

Y: Can be executed.

N: Cannot be executed.

--: Not applicable

#

Following command execution, switchover to the remote site cannot be guaranteed for a period of time. For details, see 4.3(2) Period during which switchover to the remote site cannot be guaranteed.

(2) Period during which switchover to the remote site cannot be guaranteed

Following the execution of certain RAID Manager commands, a period occurs during which switchover to the remote site cannot be guaranteed. The following table shows the period during which switchover to the remote site cannot be guaranteed.

Table 4-8 Period during which switchover to the remote site cannot be guaranteed following RAID Manager command execution

Command name | Period during which switchover to the remote site cannot be guaranteed
Start | End
horcmshutdown | Immediately following command execution | Until RAID Manager restarts and enables a synchronization point
paircreate | Until the status of the paired logical volume group for which the command was executed becomes PAIR
pairsplit
pairresync

5. Switching Over to the Remote Site

This chapter explains how to switch over from the main site to the remote site, or from the remote site to the main site.

Organization of this chapter

5.1 Switching to the remote site

5.2 Switching sites to test disaster preparedness

5.3 Switching sites to perform maintenance

5.4 Switching sites in the event of a disaster

5.5 Transaction information file

5.1 Switching to the remote site

The explanations in this chapter assume that you are switching over from the main site to the remote site. To switch over from the remote site to the main site, replace main site with remote site in all of the explanations.

Organization of this section

5.1.1 Ways to switch sites

5.1.2 Site switchover methods that can be used while the main site is running

5.1.3 Site switchover methods that can be used when a disaster occurs at the main site

5.1.4 Results of switching sites to perform maintenance

5.1.5 Results of switching sites in the event of a disaster

5.1.1 Ways to switch sites

There are several ways to switch sites. The following table describes these methods.

Table 5-1 Site switchover methods

Site switchover method | Description | Can the devices at the main site be stopped (after switching sites)? | Can sites be switched again (immediately after switching sites)?
Switching sites to test disaster preparedness | Operation switches to the remote site while the main site is still running. | Prohibited | Yes
Switching sites to perform maintenance | Used to run operations at the remote site only. For example, used when temporarily stopping update copy while performing device maintenance at the main site. | Yes | No
Switching sites in the event of a disaster | Used when a disaster occurs at the main site and operations cannot continue there. | -- (Shut down by a disaster) | No

Legend: --: Not applicable

Note

When switching sites to perform maintenance or in the event of a disaster, data loss might occur or switching sites might not be possible depending on the specification of the Real Time SAN Replication processing method and the protection mode. For details, see 5.1.4 Results of switching sites to perform maintenance or 5.1.5 Results of switching sites in the event of a disaster.

5.1.2 Site switchover methods that can be used while the main site is running

The following table shows the site switchover methods that can be used while the main site is running.

Table 5-2 Site switchover methods that can be used while the main site is running

No.
Site switchover method
Main site
Remote site
Route

Server machine
Hitachi disk array system
Server machine
Hitachi disk array system

1

Switching sites to test disaster preparedness

Switching sites to perform maintenance#

Normal operation
Normal operation
Normal operation
Normal operation
Normal operation

2
Switching sites to perform maintenance#
Error
Normal operation
Normal operation
Normal operation

3
Normal operation
Error
Normal operation
Normal operation

4
Error
Normal operation
Normal operation
Normal operation
Error

5
Normal operation
Error
Normal operation
Normal operation

6
Error
Error
Normal operation
Normal operation

7
Normal operation
Normal operation
Normal operation
Normal operation

8
Normal operation
Normal operation
Normal operation
Error
--

9
Error
Normal operation
Normal operation
Error

10
Normal operation
Error
Normal operation
Error

11
Error
Error
Normal operation
Error

12
Cannot be switched over
Normal operation
Normal operation
Error
Normal operation

13
Normal operation
Error
Error
Normal operation

14
Error
Normal operation
Error
Normal operation

15
Error
Error
Error
Normal operation

16
--
--
Error
Error

17
--
--
Disaster
Disaster

18
--
Paired
--
Paired

Legend:

Normal operation: A state in which neither an error nor a disaster has occurred, and indicates that all devices are functioning normally.

Error: An error has occurred in one or more of the devices.

Error in the Route column means that all transmission of Hitachi disk array system data has stopped between the sites.

Paired: Indicates that the Hitachi disk array system's paired logical volumes are being generated or re-synchronized.

Disaster: Indicates that none of the devices at the site are functioning because of a disaster.

--: Normal operation, Error, Paired, or Disaster

#: The detailed results of switching sites to perform maintenance are described in 5.1.4 Results of switching sites to perform maintenance.

5.1.3 Site switchover methods that can be used when a disaster occurs at the main site

The following table shows the site switchover methods that can be used when a disaster occurs at the main site.

Table 5-3 Site switchover methods that can be used when a disaster occurs at the main site

No. | Site switchover method | Main site | Remote site | Route
Server machine | Hitachi disk array system | Server machine | Hitachi disk array system
1 | Switching sites in the event of a disaster# | Disaster | Disaster | Normal operation | Normal operation | Normal operation
2 | Disaster | Disaster | Normal operation | Normal operation | Error
3 | Disaster | Disaster | Normal operation | Error | --
4 | Cannot be switched over | Disaster | Disaster | Error | --
5 | Disaster | Disaster | Disaster | Disaster
6 | Disaster | Disaster | -- | Paired

Legend:

Normal operation: A state in which neither an error nor a disaster has occurred, and indicates that all devices are functioning normally.

Error: An error has occurred in one or more of the devices.

Error in the Route column means that all transmission of Hitachi disk array system data has stopped between the sites.

Paired: Indicates that the Hitachi disk array system's paired logical volumes are being generated or re-synchronized.

Disaster: Indicates that none of the devices at the site are functioning because of a disaster.

--: Normal operation, Error, Paired, or Disaster

#: The detailed results of switching sites in the event of a disaster are described in 5.1.5 Results of switching sites in the event of a disaster.

5.1.4 Results of switching sites to perform maintenance

The following table shows the results of switching sites to perform maintenance.

Table 5-4 Results of switching sites to perform maintenance

Processing method
Protection mode
Results of switching sites to perform maintenance

No restriction
Restricted

Can be switched over without data loss#1
Can be switched over with data loss#1
Data inconsistency; cannot be restarted

All synchronous method
data
1 to 11
--
--

never
1 to 3
4 to 11#3
4 to 11#3
8 to 11#3

All asynchronous method
--
1
2 to 11#3
2 to 11#3
8 to 11#3

Hybrid method
data
1 to 2
3 to 11#2
--
3 to 11#2

never
1 to 2
3#2
4 to 11#2, 3
4 to 7#2, #3
8 to 11#2, #3
3 to 7#2
8 to 11#3

Legend:

1 to 11: Correspond to numbers in Table 5-2 Site switchover methods that can be used while the main site is running.

--: Not applicable

#1

Includes a restart failure accompanying a volume error.

#2

Limited to cases in which no error occurred during the operations explained in 4.2 Notes on operation when using the hybrid method.

#3

The result varies depending on the scope of the error.

5.1.5 Results of switching sites in the event of a disaster

The following table shows the results of switching sites in the event of a disaster.

Table 5-5 Results of switching sites in the event of a disaster

Processing method
Protection mode
Results of switching sites in the event of a disaster

No restriction
Restricted

Can be switched over without data loss#1
Can be switched over with data loss#1
Data inconsistency; cannot be restarted

All synchronous method
data
1 to 3
--
--

never
1
2 to 3#3
2 to 3#3
2 to 3#3

All asynchronous method
--
1 to 3#3
1 to 3#3
--

Hybrid method
data
1 to 3#2
--
1 to 3#2

never
1#2
2 to 3#3
2 to 3#3
1#2
2 to 3#3

Legend:

1 to 3: Correspond to numbers in Table 5-3 Site switchover methods that can be used when a disaster occurs at the main site.

--: Not applicable

#1

Includes a restart failure accompanying a volume error.

#2

Limited to cases in which no error occurred during the operations explained in 4.2 Notes on operation when using the hybrid method

#3

The result varies depending on the scope of the error.

5.2 Switching sites to test disaster preparedness

This section explains the procedure for switching sites to test disaster preparedness.

Procedure

The details of each step are described below.

Organization of this section

(1) Normally terminating the HiRDB system at the main site

(2) Checking the status of paired logical volume groups

(3) Taking control over paired logical volume groups

(4) Changing the value specified for the remote site's pd_rise_disaster_mode operand

(5) Starting the HiRDB system at the remote site

(1) Normally terminating the HiRDB system at the main site

Use the pdstop command to normally terminate the HiRDB system at the main site.

Note

If normal termination fails, do not attempt to switch sites to test disaster preparedness. Refer to the error message that was output when you tried to terminate HiRDB and eliminate the cause of the error. Then try to normally terminate HiRDB again.

(2) Checking the status of paired logical volume groups

Use either of the following methods to check the status of all paired logical volume groups:

Executing the pairvolchk command

Executing a shell program that internally executes the pairvolchk command

For an example of a shell program that does this, see Appendix B. Sample Shell Program.

Note

If there is a paired logical volume group whose pair status is not PAIR, take the necessary steps to change the pair status to PAIR. If even one paired logical volume group has a pair status that is not PAIR, do not attempt to switch sites to test disaster preparedness.

(3) Taking control over paired logical volume groups

Use the horctakeover command to take control over all paired logical volume groups. If the takeover fails, refer to RAID Manager's error log to eliminate the cause of the takeover failure. Then, re-execute the takeover.

If Swap-Takeover was successful for all paired logical volume groups (the return value of the horctakeover command is 1), execute the pairvolchk command on each paired logical volume group to check its pair status. If Swap-Takeover was successful for all paired logical volume groups and the pair status of all paired logical volume groups is PAIR, you can proceed to switch sites to test disaster preparedness.

(4) Changing the value specified for the remote site's pd_rise_disaster_mode operand

Change the value specified for the remote site's pd_rise_disaster_mode operand to normal.

Reference note

Because the default value of the pd_rise_disaster_mode operand is normal, you do not need to do anything if the pd_rise_disaster_mode operand was omitted.

(5) Starting the HiRDB system at the remote site

Use the pdstart command to start the HiRDB system at the remote site. If the KFPS05210-I message is output and the HiRDB start processing finishes, switching sites to test disaster preparedness is complete.

If HiRDB does not start, refer to the error message that is output during the HiRDB start processing, eliminate the cause of the error, and then restart HiRDB.

5.3 Switching sites to perform maintenance

This section explains the procedure for switching sites to perform maintenance.

Procedure

Note

When you switch from the main site (the remote site) to the remote site (the main site) so that you can perform maintenance on the main site (the remote site), the integrity of the data on the site being maintained cannot be guaranteed after the switchover. Therefore, you cannot immediately switch back from the remote site (the main site) to the main site (the remote site). Before you can switch sites again, both of the following conditions must be satisfied:

The status of all paired logical volume groups must be set to PAIR

The value of the pd_rise_disaster_mode operand must be changed to normal (default value) and HiRDB must be restarted

The details of each step are described below.

Organization of this section

(1) Checking whether you can switch between sites

(2) Checking whether the HiRDB system at the main site is stopped

(3) Take control over paired logical volume groups

(4) Changing the value specified for the remote site's pd_rise_disaster_mode operand

(5) Starting the HiRDB system at the remote site

(1) Checking whether you can switch between sites

Check whether all of the conditions listed below are satisfied. If not, you cannot switch sites to perform maintenance.

The site switchover method in 5.1.2 Site switchover methods that can be used while the main site is running is either Switching sites to test disaster preparedness or Switching sites to perform maintenance.

The result of switching sites to perform maintenance in 5.1.4 Results of switching sites to perform maintenance is either Can be switched over without data loss or Can be switched over with data loss.

HiRDB is running with normal (default value) specified in the pd_rise_disaster_mode operand.

(2) Checking whether the HiRDB system at the main site is stopped

Check whether the HiRDB system at the main site is stopped. If not, use the pdstop command to terminate HiRDB normally. If normal termination fails, do not attempt to switch sites to perform maintenance. Refer to the error message that was output when terminating HiRDB, eliminate the cause of error, and then terminate HiRDB normally again.

If you are using the hybrid method, normal termination might not be possible. In this case, use the pdstop -f command to forcibly terminate HiRDB. For cases in which HiRDB cannot be normally terminated, see 6.2 Collecting synchronization point dumps (when using the hybrid method).

(3) Take control over paired logical volume groups

Use the horctakeover command to take control over all paired logical volume groups. If the takeover fails, refer to RAID Manager's error log to eliminate the cause of the takeover failure. Then, re-execute the takeover.

If Swap-Takeover, SVOL-Takeover, and SVOL-SSUS-Takeover were successful for all paired logical volume groups (the return value of the horctakeover command is 1, 2, or 5), execute the pairvolchk command on each paired logical volume group to check the paired logical volume status. If Swap-Takeover, SVOL-Takeover, and SVOL-SSUS-Takeover were successful for all paired logical volume groups, you can proceed to switch sites to perform maintenance.

(4) Changing the value specified for the remote site's pd_rise_disaster_mode operand

Change the value specified for the remote site's pd_rise_disaster_mode operand to alone. If the pd_rise_disaster_mode operand was omitted, you must specify it.

(5) Starting the HiRDB system at the remote site

Use the pdstart command to start the HiRDB system at the remote site. If the KFPS05210-I message is output and the HiRDB start processing finishes, switching sites to perform maintenance is complete.

If HiRDB cannot be started, refer to the error message that was output during HiRDB start processing, eliminate the cause of error, and then restart HiRDB.

5.4 Switching sites in the event of a disaster

This section explains the procedure for switching sites in the event of a disaster.

Procedure

Note

When you switch sites because of a disaster at the main site (the remote site) to the remote site (the main site), the integrity of the data at the main site (the remote site) cannot be maintained after the switch. Therefore, you cannot immediately switch back from the remote site (the main site) to the main site (the remote site). To be able to switch sites again, both of the following conditions must be satisfied:

The status of all paired logical volume groups must be set to PAIR.

The value of the pd_rise_disaster_mode operand must be set to normal (default value) and HiRDB must be started.

The details of each step are described below.

Organization of this section

(1) Checking the status of paired logical volume groups

(2) Taking control over paired logical volume groups

(3) Changing the value specified for the remote site's pd_rise_disaster_mode operand

(4) Starting the HiRDB system at the remote site

(1) Checking the status of paired logical volume groups

Use either of the following methods to check the status of all paired logical volume groups:

Executing the pairvolchk command

Executing a shell program that internally executes the pairvolchk command

For details about a sample shell programs that will do this, see Appendix B. Sample Shell Program.

Whether you can switch sites in the event of a disaster is determined based on the status of paired logical volume groups and the protection mode. Refer to the table below to see whether you can switch sites in the event of a disaster.

If you cannot switch sites due to a disaster, HiRDB cannot be restarted at the disaster recovery site, and you will need to use the backup data to recover the database. You will also need to re-create all system files.

Table 5-6 Whether you can switch sites in the event of a disaster

Processing method | Protection mode | Status of paired logical volume groups | Whether you can switch sites in the event of a disaster
All synchronous method | data | There is a paired logical volume group whose status is COPY. | N#2
There are no paired logical volume groups whose status is COPY. | Y
never | There is a paired logical volume group whose status is COPY. | N#2
There is a paired logical volume group whose status is PSUE or PSUS. | Y#1
There are no paired logical volume groups whose status is COPY, PSUE, or PSUS.
All asynchronous method | -- | There is a paired logical volume group whose status is COPY. | N
There are no paired logical volume groups whose status is COPY. | Y
Hybrid method | data | There is a paired logical volume group whose status is COPY. | N#2
There are no paired logical volume groups whose status is COPY. | Y
never | There is a paired logical volume group whose status is COPY. | N#2
There is a paired logical volume group whose status is PSUE or PSUS among the paired logical volume groups in which system files are created. | Y#1
There are no paired logical volume groups whose status is COPY and there are no paired logical volume groups whose status is PSUE or PSUS among the paired logical volume groups on which system files are created.

Legend:

Y: You can switch sites in the event of a disaster.

N: You cannot switch sites in the event of a disaster.

--: Not applicable

#1

It may not be possible to start HiRDB after switching sites. For details, see 5.1.5 Results of switching sites in the event of a disaster.

#2

You can switch sites and run at a reduced capacity by skipping the paired logical volume group that satisfies this condition by specifying it in the pd_start_skip_unit operand.

(2) Taking control over paired logical volume groups

Use the horctakeover command to take control over all paired logical volume groups. If the takeover fails, refer to RAID Manager's error log to eliminate the cause of the takeover failure. Then, re-execute the takeover.

If Swap-Takeover, SVOL-Takeover, or SVOL-SSUS-Takeover was successful for all paired logical volume groups (the return value of the horctakeover command is 1, 2, or 5), you can switch sites in the event of a disaster.

(3) Changing the value specified for the remote site's pd_rise_disaster_mode operand

Change the value specified for the remote site's pd_rise_disaster_mode operand to alone. If the pd_rise_disaster_mode operand was omitted, you must specify it.

(4) Starting the HiRDB system at the remote site

Use the pdstart command to start the HiRDB system at the remote site. When the KFPS05210-I message is output and HiRDB start processing finishes, switching sites because of a disaster is complete.

If HiRDB cannot be started, refer to the error message that was output during HiRDB start processing, eliminate the cause of the error, and then restart HiRDB.

5.5 Transaction information file

When Real Time SAN Replication is used, the information you need to check the database recovery status is output to a transaction information file each time HiRDB is restarted (no transaction information file is created for the units of a recovery-unnecessary front-end server). The name of the transaction information file is described below.

File name: $PDDIR/spool/pdtrninf/pdriserecover.HiRDB-server-name.YYYYMMDDhhmmss
YYYY: Year, MM: Month, DD: Day, hh: Hour (24-hour notation), mm: Minutes, ss: Seconds

This file generally uses no more than 600 kilobytes of disk space per server. The maximum number of transactions that can be displayed is 2 x (value of the pd_max_users operand#1, #2) + 7.

#1

For a back-end server, use the value of the pd_max_bes_process operand instead. For a dictionary server, use the value of the pd_max_dic_process operand instead.

#2

If the pd_max_reflect_process operand is specified, add the value specified for it.

File output format

RiSe recovery information
TRNGID  TRNBID  STATUS  TIME                                    PDCLTAPNAME XID
AA....AA BB....BB CC....CC DDDD/EE/FF GG:HH:II JJJJ/KK/LL MM:NN:OO PP....PP   QQ....QQ

AA....AA: Global identifier of the transaction to be recovered

BB....BB: Branch identifier of the transaction to be recovered

CC....CC: Completion type of the transaction to be recovered

COMMIT: Commit

ROLLBACK: Rollback

PREPARE: Secure state

COMPLETE(C): Already committed

COMPLETE(R): Already rolled back

If the completion type is COMMIT, ROLLBACK, or PREPARE, it means that the transaction has not completed executing at the remote site.

If the completion type is COMMIT or ROLLBACK, it means that that transaction was recovered (with the completion type shown in STATUS) during restart processing at the remote site due to one of the following reasons:
The transaction was not completed at the main site.
The transaction was completed at the main site but that information did not reach the remote site.
For these transactions, compare the completion type, the value of PDCLTAPNAME, and the start and end times with a SQL trace that you collected using whatever tool you have available to do this, and re-execute the UAP (or execute a utility) as needed to re-update the missing data.

If the completion type is PREPARE and the transaction is not completed even after a restart, complete it by referring to Actions when there is an undetermined transaction in the HiRDB Version 9 System Operation Guide.

DDDD: Start year for the transaction to be recovered

EE: Start month for the transaction to be recovered

FF: Start day for the transaction to be recovered

GG: Start hour for the transaction to be recovered

HH: Start minute for the transaction to be recovered

II: Start second for the transaction to be recovered

JJJJ: End year for the transaction to be recovered

For COMMIT, ROLLBACK, or PREPARE, 9999 is displayed.

KK: End month for the transaction to be recovered

For COMMIT, ROLLBACK, or PREPARE, 99 is displayed.

LL: End day for the transaction to be recovered

For COMMIT, ROLLBACK, or PREPARE, 99 is displayed.

MM: End hour for the transaction to be recovered

For COMMIT, ROLLBACK, or PREPARE, 99 is displayed.

NN: End minute for the transaction to be recovered

For COMMIT, ROLLBACK, or PREPARE, 99 is displayed.

OO: End second for the transaction to be recovered

For COMMIT, ROLLBACK, or PREPARE, 99 is displayed.

PP....PP: value specified in PDCLTAPNAME the transaction to be recovered

QQ....QQ: XID value for the transaction to be recovered

This information is not output for a utility or if the connected client is not an X/Open-compatible application.

Output example

Explanation

In this example, transactions indicated by [1] have been completely executed while the transactions indicated by [2] will be recovered with the completion type indicated in STATUS when the remote site is restarted. For each transaction, compare the completion type, the value of PDCLTAPNAME, and the start and end times with a SQL trace that you create using whatever application you have for doing this, and separate the applications that have executed completely from those applications that will be completed through rollback or through recovery to identify the recovered content.

If any transactions were started after the transaction with the earliest end time that is in the information file for recovered transactions, and no information for these transactions is output to this file, all such transaction were completed with rollback.

6. Error Handling

This chapter explains error handling.

Organization of this chapter

6.1 HiRDB's actions when an error occurs during update copy

6.2 Collecting synchronization point dumps (when using the hybrid method)

6.3 Error-handling methods

6.4 Handling of failure to link to RAID Manager

6.5 Handling when paired logical volume group names are missing from the RAID Manager configuration definition

6.6 Handling of route errors

6.7 Handling of errors on the primary volume

6.8 Handling of errors on the secondary volume

6.9 Handling a disaster at the main site that occurred while it was recovering from an error

6.1 HiRDB's actions when an error occurs during update copy

If an error occurs during update copy, what HiRDB does differs depending on the Real Time SAN Replication processing method and the protection mode. The following table shows HiRDB's actions when an error occurs during update copy.

Table 6-1 HiRDB's actions when an error occurs during update copy

Error type
Processing method
Protection mode
HiRDB's action at the main site
Switching sites in the event of a disaster

Failure to link to RAID Manager
All synchronous method or all asynchronous method
data, never
Continues online operations.
Correct operation cannot be guaranteed.

Hybrid method
data
Continues online operations. However, a synchronization point dump is not collected (the KFPS02178-E message is output). Normal start, normal termination, and planned termination will also fail.

never
Continues online operations. However, the KFPS02178-E message is output each time a synchronization point dump is collected.

Paired logical volume group name is missing from the RAID Manager configuration definition
All synchronous method or all asynchronous method
data, never
Continues online operations.
Correct operation cannot be guaranteed.

Hybrid method
data
Continues online operations. However, if the paired logical volume group name in which RDAREAs are created is missing, the server that uses the applicable paired logical volume group cannot collect synchronization point dumps (the KFPS02178-E message is output).
Normal start, normal termination, and planned termination will also fail.

never
Continues online operations. However, the KFPS02178-E message is output each time a synchronization point dump is collected.

Route error
All synchronous method
data
Because data cannot be updated, HiRDB (or a unit in HiRDB/Parallel Server) terminates abnormally.
Recovers to the latest point in time.

never
Continues online operations.
Correct operation cannot be guaranteed.

All asynchronous method
--
Recovers to the point in time when the route error occurred.

Hybrid method
data
Because the system file data cannot be updated, HiRDB (or a unit in HiRDB/Parallel Server) terminates abnormally.
Recovers to the latest point in time.#

never
Continues online operations. However, the KFPS02178-E message is output each time a synchronization point dump is collected.
Correct operation cannot be guaranteed.

Primary volume error
All synchronous method
data, never
Shuts down the files created on the primary volume on which the error occurred.
Recovers to the latest point in time, except for the shut-down file.

All asynchronous method
--
Recovers to the point in time when the error on the primary volume occurred.

Hybrid method
data

If an error occurred on the primary volume belonging to the paired logical volume group in which the system files or RDAREAs are created, HiRDB shuts down the files created on the primary volume in which the error occurred.

If an error occurred on the primary volume belonging to the paired logical volume group in which RDAREAs are created, the server that uses the applicable paired logical volume group cannot collect synchronization point dumps (the KFPS02178-E message is output).
Normal start, normal termination, and planned termination will also fail.

Recovers to the latest point in time, except for the shut-down file.#

never
Shuts down the files created on the primary volume on which the error occurred. If an error occurred on a primary volume belonging to the paired logical volume group in which RDAREAs are created, the server that uses the applicable paired logical volume group outputs the KFPS02178-E message each time a synchronization point dump is collected.

Secondary volume error
All synchronous method
data
Shuts down the files created on the secondary volume on which the error occurred.
Recovers to the latest point in time, except for the shut-down files.

never
Continues online operations.
Correct operation cannot be guaranteed.

All asynchronous method
--
Recovers to the point in time when the error on the secondary volume occurred.

Hybrid method
data

If an error occurred on the secondary volume belonging to the paired logical volume group in which RDAREAs are created, online operations continue. However, the server that uses the applicable paired logical volume group cannot collect synchronization point dumps (the KFPS02178-E message is output). Normal start, normal termination, and planned termination will also fail.

If an error occurred on the secondary volume belonging to the paired logical volume group in which the system files are created, HiRDB shuts down the files created on the secondary volume on which the error occurred.

Recovers to the latest point in time, except for the shut-down files.#

never
Continues online operations. If an error occurred on the secondary volume belonging to the paired logical volume group in which RDAREAs are created, the server that uses the applicable paired logical volume group outputs a KFPS02178-E message each time a synchronization point dump is collected.
Correct operation cannot be guaranteed.

Legend:

--: Not applicable

#

Excludes situations in which the operations explained in 4.2 Notes on operation when using the hybrid method are being performed.

6.2 Collecting synchronization point dumps (when using the hybrid method)

Organization of this section

(1) Collecting synchronization point dumps when using the hybrid method

(2) What HiRDB does when the collection of a synchronization point dump stops at the main site

(1) Collecting synchronization point dumps when using the hybrid method

When you use the hybrid method, the updated data on all paired logical volume groups used by the server that collects the synchronization point dump is collected in the dump so that the database at the remote site can be recovered from the synchronization point as well. If an update copy error occurs in the paired logical volume group in which RDAREAs are created and the protection mode is data and the status of the paired logical volume group is not PAIR, the updated data for all paired logical volume groups cannot be synchronized, and so the collection of synchronization point dumps is stopped, and the KFPS02178-E message is output.

The following table shows how synchronization point dumps are collected when using the hybrid method.

Table 6-2 How synchronization point dumps are collected when using the hybrid method

Protection mode | Status of the paired logical volume group in which RDAREAs are created | Collection of synchronization point dump at the main site | Switching sites after a synchronization point dump is collected at the main site
data | PAIR | Completes the dump. | You can switch sites without data discrepancies.
Not PAIR | Stops the dump.
never | PAIR | Completes the dump.
Not PAIR | In normal start, because data discrepancies occur, switching sites is prohibited. In restart, because HiRDB cannot be started, switching sites cannot be executed.

(2) What HiRDB does when the collection of a synchronization point dump stops at the main site

The following table what HiRDB does when the collection of a synchronization point dump stops at the main site.

Table 6-3 What HiRDB does when the collection of a synchronization point dump stops at the main site

Process timing
Start or termination type
What HiRDB does after the collection of synchronization point dump stops at the main site
Action you need to take when the error occurs

During startup processing

Normal startup

Database initialization start

Forced normal startup

Outputs the abort code Pstj14j and stops HiRDB startup processing.
Change the status of the paired logical volume group in which the RDAREAs used by the applicable server are created to PAIR and then restart HiRDB.

Restart
Continues HiRDB startup processing.
Change the status of the paired logical volume group in which the RDAREAs used by the applicable server are created to PAIR and then collect a synchronization point dump by executing the pdlogsync command.

Restart following planned termination

During termination process
Normal termination
Stops HiRDB termination processing, outputs the abort code Pstj14k, and abnormally terminates HiRDB (or a unit for HiRDB/Parallel Server).
Change the status of the paired logical volume group in which the RDAREAs used by the applicable server are created to PAIR, restart HiRDB (or the unit), and then terminate HiRDB normally.

Planned termination
Change the status of the paired logical volume group in which the RDAREAs used by the applicable server are created to PAIR, restart HiRDB (or the unit), and re-execute planned termination of HiRDB.

Forced termination
Continues HiRDB termination processing.
No action required

During operation
--
Continues processing.
Change the status of the paired logical volume group in which the RDAREAs used by the applicable server uses are created to PAIR and then collect a synchronization point dump by executing the pdlogsync command.

Legend:

--: Not applicable

6.3 Error-handling methods

This section explains how to handle errors that may occur when you use Hitachi's disk array subsystem. The following table shows error-handling methods and the figure that that follows shows an error analysis flow chart.

Table 6-4 Error-handling methods

Error type | Error message | Error-handling method
Failure to link to RAID Manager | Reason code ERRORRETURN[EX_ATTHOR] of the KFPS04680-E message is displayed. | For details about how to handle this error, see 6.4 Handling of failure to link to RAID Manager.
Missing specification of paired logical volume group name from the RAID Manager configuration definition | Reason code ERRORRETURN[EX_ENOGRP] of the KFPS04680-E message is displayed. | For details about how to handle this error, see 6.5 Handling when paired logical volume group names are missing from the RAID Manager configuration definition.
Communication error between MCU and RCU | Reason code ERRORRETURN[EX_INVVOL] of the KFPS04680-E message is displayed. | For details about how to handle this error, see 6.6 Handling of route errors.
Primary volume error | Reason code ERRORRETURN[EX_INVVOL] of the KFPS04680-E message is displayed. | For details about how to handle this error, see 6.7 Handling of errors on the primary volume.
Secondary volume error | Reason code ERRORRETURN[EX_INVVOL] of the KFPS04680-E message is displayed. | For details about how to handle this error, see 6.8 Handling of errors on the secondary volume.

Figure 6-1 Error analysis flow chart

6.4 Handling of failure to link to RAID Manager

Either of the following causes will result in a failure to link to RAID Manager:

The RAID Manager process has not been started.

An invalid value is specified for the HORCMINST operand.

If the link fails because of the first cause, start RAID Manager by executing the horcmstart command with the proper value specified for the HORCMINST operand.

If the link fails because of the second cause, check the instance number used in the configuration definition file and, if necessary, change the value of the HORCMINST operand to the correct instance number.

6.5 Handling when paired logical volume group names are missing from the RAID Manager configuration definition

Check whether a correct paired logical volume group name is specified in RAID Manager's configuration definition file. If a nonexistent paired logical volume group name was entered, either change RAID Manager's configuration definition to the correct paired logical volume group name or generate a paired logical volume group to match the one in the definition.

6.6 Handling of route errors

This section describes the procedure for handling route errors.

Procedure

Note: The numbers to the left of the process boxes correspond to the item numbers in the following explanation:

Stops the application server and interrupts the online transaction.

Forcibly terminate HiRDB.

Change the value of the pd_rise_disaster_mode operand to alone.

Split all paired logical volume groups by executing the pairsplit command (with the -S option specified).

Restart HiRDB. After the restart, do not update the database that is being used with online transactions.

Terminate HiRDB normally.

Execute the pdcopy command to make a backup of each system.
For details about how to make backups, see the HiRDB Version 9 System Operation Guide.

Copy the backup files made in step 7 to the remote site.

Contact the person responsible for maintaining the Hitachi disk array subsystems, determine the cause of the route error, and take the appropriate corrective action.

Execute the pairesync command to re-synchronize the paired logical volume groups.

Execute the pairevtwait command (with the -s pair option specified) on the paired logical volume groups specified in the pairesync command executed in step 10, and wait until a termination code of 0 is returned.

Change the value of the pd_rise_disaster_mode operand to normal.

Start HiRDB.

Collect a synchronization point dump by executing the pdlogsync -d sys -w command and wait until validation is completed. For HiRDB/Parallel Server, execute the pdlogsync -d sys -w command on all servers.

6.7 Handling of errors on the primary volume

This section describes the procedure for handling errors on the primary volume.

Procedure

Note: The numbers to the left of the process boxes correspond to the item numbers in the following explanation:

Stops the application server and interrupts online transactions.

Execute the pdhold -c command to shut down and close all RDAREAs created in the paired logical volume group in which the error occurred. Also, execute the pdlogcls and pdstscls commands to close all system files created in the paired logical volume group in which the error occurred.

Forcibly terminate HiRDB.

Change the value of the pd_rise_disaster_mode operand to alone.

Execute the pairsplit command (with the -S option specified) to split all paired logical volume groups.

Restart HiRDB.

Terminate HiRDB normally.

Contact the person responsible for maintaining the Hitachi disk array subsystems, determine the cause of the error on the primary volume, and take the appropriate corrective action.

Since an error that prevents HiRDB from restarting has occurred, recover the database from the backup and the unload log files. For details about how to recover a database, see the HiRDB Version 9 System Operation Guide. Also, create new system files to replace all of the system files that had been created on the primary volume on which the error occurred.

From the backup and the unload log files, recover all RDAREAs that were created on the primary volume on which the error occurred. For details about how to recover a database, see the HiRDB Version 9 System Operation Guide. Also, create new system files to replace all of the system files that had been created on the primary volume on which the error occurred.

Execute the pdcopy command to make a backup of each system.
For details about how to make backups, see the HiRDB Version 9 System Operation Guide.

Copy the backup files made in step 11 to the remote site.

Execute the paicreate command to create a paired logical volume group.

Execute the pairevtwait command (with the -s pair option specified) on the paired logical volume group specified in the paircreate command executed in step 13, and wait until a termination code of 0 is returned.

Change the value of the pd_rise_disaster_mode operand to normal.

Start HiRDB. If HiRDB startup fails, see When HiRDB does not start in the HiRDB Version 9 System Operation Guide and take the appropriate corrective action.

Collect a synchronization point dump by executing the pdlogsync -d sys -w command and wait until validation is completed. For HiRDB/Parallel Server, execute the pdlogsync -d sys -w command on all servers.

Execute the pdrels -o command to release and open all RDAREAs created in the paired logical volume group in which the error occurred. Also, execute the pdlogopen and pdstsopen commands to open all system files created in the paired logical volume group in which the error occurred.

6.8 Handling of errors on the secondary volume

This section describes the procedure for handling errors on the secondary volume.

Procedure

Note: The numbers to the left of the process boxes correspond to the item numbers in the following explanation:

Stops the application server and interrupts online transactions.

Forcibly terminate HiRDB.

Change the value of the pd_rise_disaster_mode operand to alone.

Executing the pairsplit command (with the -S option specified) to split all paired logical volume groups.

Restart HiRDB. After the restart, do not update the database being used by online transactions.

Terminate HiRDB normally.

Contact the person responsible for maintaining the Hitachi disk array subsystems, determine the cause of the error on the secondary volume, and take the appropriate corrective action.

From the backup and unload log files, recover all RDAREAs that were created in the paired logical volume group in which the error occurred. For details about how to recover a database, see the HiRDB Version 9 System Operation Guide. Also, create new system files for all of the system files that had been created in the paired logical volume group in which the error occurred.

Execute the pdcopy command to make a backup of each system.
For details about how to make backups, see the HiRDB Version 9 System Operation Guide.

Copy the backup files made in step 9 to the remote site.

Execute the paicreate command and generate a paired logical volume group.

Execute the pairevtwait command (with the -s pair option specified) on the paired logical volume group specified in the paircreate command executed in step 11, and wait until a termination code of 0 is returned.

Change the value of the pd_rise_disaster_mode operand to normal.

Start HiRDB.

Collect a synchronization point dump by executing the pdlogsync -d sys -w command and wait until validation is completed. For HiRDB/Parallel Server, execute the pdlogsync -d sys -w command on all servers.

Execute the pdrels -o command to release and open all RDAREAs created in the paired logical volume group in which the error occurred. Also, execute the pdlogopen and pdstsopen commands to open all system files created in the paired logical volume group in which the error occurred.

6.9 Handling a disaster at the main site that occurred while it was recovering from an error

If a disaster occurs at the main site during error recovery, do not start HiRDB at the remote site by using the standard procedure for switching sites in the event of a disaster. If you do, the operation of HiRDB and data consistency cannot be guaranteed. To run HiRDB at the remote site, you must recover the database from the backup.

7. Changing the Pair Logical Volume Configuration

This chapter explains how to change the paired logical volume configuration.

Organization of this chapter

7.1 Situations requiring changes in the paired logical volume configuration

7.2 Adding a paired logical volume group

7.3 Adding a paired logical volume to an existing paired logical volume group

7.4 Changing the name of a paired logical volume group

7.5 Moving a paired logical volume to a new paired logical volume group

7.6 Moving a paired logical volume to an existing paired logical volume group

7.7 Deleting a paired logical volume

7.1 Situations requiring changes in the paired logical volume configuration

If you change the system configuration of HiRDB, you may also have to change the configuration of paired logical volumes or paired logical volume group. The following table shows situations in which the configuration of paired logical volumes or paired logical volume group need to be changed.

Table 7-1 Situations requiring changes in the configuration of paired logical volumes or paired logical volume group

Changes to HiRDB system configuration
Change required to the configuration of paired logical volumes or paired logical volume group

Adding a unit

Adding a server

Moving a unit (adding a destination)

Moving a server (adding a destination)

Add a paired logical volume group. For a detailed procedure, see 7.2 Adding a paired logical volume group.

Adding or extending RDAREAs

Adding system files

Add a paired logical volume to an existing paired logical volume group. For a detailed procedure, see 7.3 Adding a paired logical volume to an existing paired logical volume group.

Changing a unit identifier

Changing a server name

Change the name of a paired logical volume group. For a detailed procedure, see 7.4 Changing the name of a paired logical volume group.

Transferring tables when adding a server

Migrating from HiRDB/Single Server to HiRDB/Parallel Server

Move a paired logical volume to a new paired logical volume group. For a detailed procedure, see 7.5 Moving a paired logical volume to a new paired logical volume group.

Transferring tables to another server
Move a paired logical volume to an existing paired logical volume group. For a detailed procedure, see 7.6 Moving a paired logical volume to an existing paired logical volume group.

Deleting a unit

Deleting a server

Moving a unit (deleting the source)

Moving servers (deleting the source)

Delete a paired logical volume that is no longer needed. For a detailed procedure, see 7.7 Deleting a paired logical volume.

7.2 Adding a paired logical volume group

This section describes the procedure for adding a paired logical volume group.

Procedure

Note: The numbers to the left of the process boxes correspond to the item numbers in the following explanation:

Terminate HiRDB normally by executing the pdstop command.

Execute the pdcopy command (with the -M x option specified) to make a backup of each system.
For details about how to make backups, see the HiRDB Version 9 System Operation Guide.

Copy the backup files made in step 2 to the remote site.

Execute the horcmshutdown command to stop RAID Manager.

Change RAID Manager's configuration definition. Specify the definition information for the paired logical volume group and paired logical volumes to be added.

Execute the horcmstart command to start RAID Manager.

Execute the paircreate command on the newly added paired logical volume group to generate it.

Execute the pairevtwait command (with the -s pair option specified) to check the result of generating the paired logical volume group. Confirm that the pair status of the newly added paired logical volume group is PAIR.

Start HiRDB by executing the pdstart command.

Collect a synchronization point dump by executing the pdlogsync command (with the -w option specified). Confirm that the command terminates normally. For HiRDB/Parallel Server, execute the pdlogsync command on all servers.

7.3 Adding a paired logical volume to an existing paired logical volume group

This section describes the procedure for adding a paired logical volume to an existing paired logical volume group.

Procedure

Note: The numbers to the left of the process boxes correspond to the item numbers in the following explanation:

Terminate HiRDB normally by executing the pdstop command.

Execute the pdcopy command (with the -M x option specified) to make a backup of each system.
For details about how to make backups, see the HiRDB Version 9 System Operation Guide.

Copy the backup files made in step 2 to the remote site.

Split the paired logical volume group to which the paired logical volume is to be added by executing the pairsplit command (with the -S option specified).

Execute the horcmshutdown command to stop RAID Manager.

Change RAID Manager's configuration definition. Specify the definition information for the paired logical volume to be added.

Execute the horcmstart command to start RAID Manager.

Execute the paircreate command on the paired logical volume group to which the paired logical volume was added and re-generate the paired logical volume group.

Execute the pairevtwait command (with the -s pair option specified) to check the results of generating the paired logical volume group. Confirm that the pair status of the paired logical volume group to which the paired logical volume was added is PAIR.

Start HiRDB by executing the pdstart command.

Collect a synchronization point dump by executing the pdlogsync command (with the -w option specified). Confirm that the command terminates normally. For HiRDB/Parallel Server, execute the pdlogsync command on all servers.

7.4 Changing the name of a paired logical volume group

This section describes the procedure for changing the name of a paired logical volume group.

Procedure

Note: The numbers to the left of the process boxes correspond to the following explanation:

Terminate HiRDB normally by executing the pdstop command.

Execute the pdcopy command (with the -M x option specified) to make a backup of each system.
For details about how to make backups, see the HiRDB Version 9 System Operation Guide.

Copy the backup files made in step 2 to the remote site.

Execute the horcmshutdown command to stop RAID Manager.

Change RAID Manager's configuration definition. Change the name of the paired logical volume group.

Execute the horcmstart command to start RAID Manager.

Start HiRDB by executing the pdstart command.

Collect a synchronization point dump by executing the pdlogsync command (with the -w option specified). Confirm that the command terminates normally. For HiRDB/Parallel Server, execute the pdlogsync command on all servers.

7.5 Moving a paired logical volume to a new paired logical volume group

This section describes the procedure for moving a paired logical volume to a new paired logical volume group.

Procedure

Note: The numbers to the left of the process boxes correspond to the item numbers in the following explanation:

Terminate HiRDB normally by executing the pdstop command.

Execute the pdcopy command (with the -M x option specified) to make a backup of each system.
For details about how to make backups, see the HiRDB Version 9 System Operation Guide.

Copy the backup files made in step 2 to the remote site.

Split the source paired logical volume group by executing the pairsplit command (with the -S option specified).

Execute the horcmshutdown command to stop RAID Manager.

Change RAID Manager's configuration definition.

Specify the definition information for the paired logical volume group to be added.

Change the paired logical volume group name of the paired logical volume being moved to the name of the newly added paired logical volume group.

Execute the horcmstart command to start RAID Manager.

Execute the paircreate command for the following paired logical volume groups:

Source paired logical volume groups

Destination paired logical volume groups

Execute the pairevtwait command (with the -s pair option specified) to check the results of generating the paired logical volume group. Confirm that the pair status of the paired logical volume groups at both the source and destination are PAIR.

Start HiRDB by executing the pdstart command.

Collect a synchronization point dump by executing the pdlogsync command (with the -w option specified). Confirm that the command terminates normally. For HiRDB/Parallel Server, execute the pdlogsync command on all servers.

7.6 Moving a paired logical volume to an existing paired logical volume group

This section describes the procedure for moving a paired logical volume to an existing paired logical volume group.

Procedure

Note: The numbers to the left of the process boxes correspond to the item numbers in the following explanation:

Terminate HiRDB normally by executing the pdstop command.

Execute the pdcopy command (with the -M x option specified) to make a backup of each system.
For details about how to make backups, see the HiRDB Version 9 System Operation Guide.

Copy the backup files made in step 2 to the remote site.

Execute the pairsplit command (with the -S option specified) to split the paired logical volume groups at both the source and destination.

Execute the horcmshutdown command to stop RAID Manager.

Change RAID Manager's configuration definition. Change the paired logical volume group name of the paired logical volume being moved to the name of the paired logical volume group at the destination.

Execute the horcmstart command to start RAID Manager.

Execute the paircreate command on the following paired logical volume groups:

Source paired logical volume groups

Destination paired logical volume groups

Execute the pairevtwait command (with the -s pair option specified) to check the results of generating the paired logical volume group. Confirm that the pair status of the paired logical volume groups at both the source and destination are PAIR.

Start HiRDB by executing the pdstart command.

Collect a synchronization point dump by executing the pdlogsync command (with the -w option specified). Confirm that the command terminates normally. For HiRDB/Parallel Server, execute the pdlogsync command on all servers.

7.7 Deleting a paired logical volume

This section describes the procedure for deleting a paired logical volume.

Procedure

Note: The numbers to the left of the process boxes correspond to the item numbers in the following explanation:

Terminate HiRDB normally by executing the pdstop command.

Execute the pdcopy command (with the -M x option specified) to make a backup of each system.
For details about how to make backups, see the HiRDB Version 9 System Operation Guide.

Copy the backup files made in step 2 to the remote site.

Execute the pairsplit command (with the -S option specified) to split the paired logical volume group containing the paired logical volume to be deleted.

Execute the horcmshutdown command to stop RAID Manager.

Change RAID Manager's configuration definition. Delete the configuration definition of the paired logical volume being deleted.

Execute the horcmstart command to start RAID Manager.

Execute the paircreate command on the paired logical volume group containing the paired logical volume being deleted.

Execute the pairevtwait command (with the -s pair option specified) to check the results of generating the paired logical volume group. Confirm that the pair status of the paired logical volume group containing the paired logical volume being deleted is PAIR.

Start HiRDB by executing the pdstart command.

Collect a synchronization point dump by executing the pdlogsync command (with the -w option specified). Confirm that the command terminates normally. For HiRDB/Parallel Server, execute the pdlogsync command on all servers.

8. Relationships to Other Facilities

This chapter explains the issues that the user must be aware of when using Real Time SAN Replication and other facilities at the same time.

Organization of this chapter

8.1 Facilities that require special attention

8.2 Notes on using the inner replica facility

8.3 Notes on using the system switchover facility

8.4 Notes on using the security audit facility

8.5 Notes on using the automatic log unloading facility

8.6 Notes on using the facility for monitoring the free area for system log files

8.7 Notes on using a shared table (applicable only to the hybrid method)

8.1 Facilities that require special attention

You must be careful when using Real Time SAN Replication at the same time as any of the facilities described in the following table. This table lists these facilities and provides related notes.

Table 8-1 Facilities that require special attention and related notes

Facility to be used
Notes

Inner replica facility
For notes on using the inner replica facility, see 8.2 Notes on using the inner replica facility.

HiRDB Datareplicator replication facility
Because the HiRDB Datareplicator environment cannot be inherited during a site switchover, the HiRDB Datareplicator replication facility cannot be used. To use the replication facility after you have switched the site for the source or target HiRDB, you must first initialize the HiRDB Datareplicator environment for both the source HiRDB and target HiRDB and then re-create the target HiRDB based on the source HiRDB.

System switchover facility
For notes on using the system switchover facility, see 8.3 Notes on using the system switchover facility.

Security audit facility
For notes on using the security audit facility, see 8.4 Notes on using the security audit facility.

Automatic log unloading facility
For notes on using the automatic log unloading facility, see 8.5 Notes on using the automatic log unloading facility.

System reconfiguration command
Note the following when using the system reconfiguration command (pdchgconf command):

Execute the system reconfiguration command when HiRDB is running at the main site.

You cannot use the system reconfiguration command to change the system definition at the remote site. You must change the system definition at the remote site manually after the system reconfiguration command has terminated normally at the main site.

Unlike with the pdconfchk command, the pdrisechk command cannot check the post-changed configuration before the system configuration is changed. Therefore, use the pdrisechk command to check the configuration of Real Time SAN Replication after the system reconfiguration command has been executed.

Statistical information collection
When the system is switched over from the main site to the remote site, the type of statistical information collected at the main site and statistics logs cannot be passed onto the remote site. Therefore, you must restart statistical information collection at the remote site.

Facility for monitoring free area for system log file
For notes on using the facility for monitoring free area for system log files, see 8.6 Notes on using the facility for monitoring the free area for system log files.

Automatic extension of RDAREAs (applicable only to the hybrid method)
When the hybrid method is used, the system waits to perform synchronization of the database at the remote site while automatic extension is being performed. An overhead of at least two seconds may occur each time automatic extension is performed.
For details about how to recover the database at the remote site when a pended synchronization of the database at the remote site fails, see 6. Error Handling.

Shared table (applicable only to the hybrid method)
For notes on using a shared table, see 8.7 Notes on using a shared table (applicable only to the hybrid method).

8.2 Notes on using the inner replica facility

This section provides notes on using the HORMCF or ShadowImage facility provided with the Hitachi disk array system with the inner replica facility.

Organization of this section

(1) Instance

(2) Pair logical volume configuration

(3) Switching sites

(1) Instance

See 2.3(2) Instance.

(2) Pair logical volume configuration

How you operate TrueCopy(or Universal Replicator) paired volumes and ShadowImage paired volumes differs depending on whether the disk on which the original RDAREA is located is joined to the disk on which the replica RDAREA is located.

The following table shows the combinations. Figure 8-1 and Figure 8-2 show paired volume configurations.

Table 8-2 Pair volume configuration combinations when the inner replica facility is being used

Disk join status | TrueCopy or Universal Replicator paired volumes (between the main site and the remote site) | ShadowImage paired volumes
Original RDAREA | Replica RDAREA
Joined | Paired | Unpaired | Paired
Not joined | Paired | Paired | Unpaired

Figure 8-1 Pair volume configuration when the disks are joined

Figure 8-2 Pair volume configuration when the disks are not joined

(3) Switching sites

When switching sites, depending on whether the disks containing the original RDAREAs are joined to the disks containing the replica RDAREAs, you either pair the individual TrueCopy(or Universal Replicator) or ShadowImage volumes or release their pairing.

When the disks are joined
Take control over the TrueCopy or Universal Replicator paired volumes without changing the ShadowImage paired volumes. During this process, set the paired volumes at the remote site to P-VOL.

When the disks are not joined
Release the ShadowImage paired volumes at the main site (by setting their pair attributes to SMPL) and take control over the TrueCopy or Universal Replicator paired volumes. During this process, set the paired volumes at the remote site to P-VOL and leave the pairing of the ShadowImage paired volumes at the remote site released (start HiRDB in the pairing released state).

Figure 8-3 shows the procedure for switching sites to test disaster preparedness when the inner replica facility is being used. Figure 8-4 shows the procedure for switching sites to perform maintenance when the inner replica facility is being used. Figure 8-5 shows the procedure for switching sites in the event of a disaster when the inner replica facility is being used.

Figure 8-3 Procedure for switching sites to test disaster preparedness when the inner replica facility is being used

Figure 8-4 Procedure for switching sites to perform maintenance when the inner replica facility is being used

Figure 8-5 Procedure for switching sites in the event of a disaster when the inner replica facility is being used

8.3 Notes on using the system switchover facility

When Real Time SAN Replication is used, because the HiRDB systems at the main and remote sites are independent from each other, you cannot simply switch between the systems at the main site and a remote site. Furthermore, using a system switchover facility and Real Time SAN Replication together increases the time it takes to switch systems.

The following subsections describe the paired logical volume groups you need to specify in RAID Manager's configuration definitions when a system switchover facility is used. The following explanations assume that you are using the hybrid method for all paired logical volume groups.

Organization of this section

8.3.1 Standby system switchover facilities

8.3.2 Standby-less system switchover (1:1) facility

8.3.3 Standby-less system switchover (effects distributed) facility

8.3.4 Setting up cluster software

8.3.5 Standby system operation

8.3.1 Standby system switchover facilities

Organization of this subsection

(1) 1-to-1 switchover configuration

(2) Mutual system switchover configuration (with different units in the same system)

(1) 1-to-1 switchover configuration

Set up the following paired logical volume groups on each of the server machines on which a primary or secondary unit is installed:

Pair logical volume groups to be used by the unit

Pair logical volume groups to be used by the server in the unit in 1 above

The following figure shows an example of the logical volume group setup.

Figure 8-6 Example of the logical volume group setup (for 1-to-1 switchover configuration)

Pair logical volume group specifications n the configuration definition of server machine 1

HRD1_UNT1_USTS
HRD1_sds1_DB
HRD1_sds1_LOG
HRD1_sds1_SPD
HRD1_sds1_SSTS

Pair logical volume group specifications n the configuration definition of server machine 2

HRD1_UNT1_USTS
HRD1_sds1_DB
HRD1_sds1_LOG
HRD1_sds1_SPD
HRD1_sds1_SSTS

(2) Mutual system switchover configuration (with different units in the same system)

Set up the following paired logical volume groups on each of the server machines that are configured for mutual system switchover:

Pair logical volume groups to be used by the primary units on the server machines

Pair logical volume groups to be used by the secondary units on the server machines

Pair logical volume groups to be used by the servers in the units in 1 and 2 above

The following figure shows an example of the logical volume group setup.

Figure 8-7 Example of the logical volume group setup (for mutual system switchover configuration)

Pair logical volume group settings in the configuration definition of server machine 1

HRD1_UNT1_USTS
HRD1_dic1_DB
HRD1_dic1_LOG
HRD1_dic1_SPD
HRD1_dic1_SSTS
HRD1_fes1_DB
HRD1_fes1_LOG
HRD1_fes1_SPD
HRD1_fes1_SSTS

HRD1_UNT2_USTS
HRD1_bes1_DB
HRD1_bes1_LOG
HRD1_bes1_SPD
HRD1_bes1_SSTS

Pair logical volume group settings in the configuration definition of server machine 2

HRD1_UNT1_USTS
HRD1_dic1_DB
HRD1_dic1_LOG
HRD1_dic1_SPD
HRD1_dic1_SSTS
HRD1_fes1_DB
HRD1_fes1_LOG
HRD1_fes1_SPD
HRD1_fes1_SSTS

HRD1_UNT2_USTS
HRD1_bes1_DB
HRD1_bes1_LOG
HRD1_bes1_SPD
HRD1_bes1_SSTS

8.3.2 Standby-less system switchover (1:1) facility

Set up the following paired logical volume groups on each of the server machines that is configured for standby-less system switchover (1:1):

Pair logical volume groups to be used by the units on the server machines

Pair logical volume groups to be used by the normal BESs of the units in 1 above

Pair logical volume groups to be used by the alternate BESs of the units in 1 above

Pair logical volume groups to be used by the units of the normal BESs associated with the alternate BESs on the server machines

The following figure shows an example of logical volume group setup.

Figure 8-8 Example of logical volume group setup (when the standby-less system switchover (1:1) facility is used)

Pair logical volume group settings in the configuration definition of server machine 1

HRD1_UNT1_USTS
HRD1_bes11_DB
HRD1_bes11_LOG
HRD1_bes11_SPD
HRD1_bes11_SSTS
HRD1_bes12_DB
HRD1_bes12_LOG
HRD1_bes12_SPD
HRD1_bes12_SSTS

HRD1_UNT2_USTS
HRD1_bes21_DB
HRD1_bes21_LOG
HRD1_bes21_SPD
HRD1_bes21_SSTS
HRD1_bes22_DB
HRD1_bes22_LOG
HRD1_bes22_SPD
HRD1_bes22_SSTS

Pair logical volume group settings in the configuration definition of server machine 2

HRD1_UNT1_USTS
HRD1_bes11_DB
HRD1_bes11_LOG
HRD1_bes11_SPD
HRD1_bes11_SSTS
HRD1_bes12_DB
HRD1_bes12_LOG
HRD1_bes12_SPD
HRD1_bes12_SSTS

HRD1_UNT2_USTS
HRD1_bes21_DB
HRD1_bes21_LOG
HRD1_bes21_SPD
HRD1_bes21_SSTS
HRD1_bes22_DB
HRD1_bes22_LOG
HRD1_bes22_SPD
HRD1_bes22_SSTS

8.3.3 Standby-less system switchover (effects distributed) facility

Set up all of the following paired logical volume groups on each of the server machines that are configured for standby-less system switchover (effects distributed):

Pair logical volume groups to be used by the units on the server machines

Pair logical volume groups to be used by the BESs that are set up in the HA group to which the units in 1 above belong

The following figure shows an example of the logical volume group setup.

Figure 8-9 Example of the logical volume group setup (when the standby-less system switchover (effects distributed) facility is used)

Pair logical volume group settings in the configuration definition of server machine 1

HRD1_UNT1_USTS
HRD1_bes11_DB
HRD1_bes11_LOG
HRD1_bes11_SPD
HRD1_bes11_SSTS
HRD1_bes21_DB
HRD1_bes21_LOG
HRD1_bes21_SPD
HRD1_bes21_SSTS

HRD1_bes31_DB
HRD1_bes31_LOG
HRD1_bes31_SPD
HRD1_bes31_SSTS

Pair logical volume group settings in the configuration definition of server machine 2

HRD1_UNT2_USTS
HRD1_bes11_DB
HRD1_bes11_LOG
HRD1_bes11_SPD
HRD1_bes11_SSTS
HRD1_bes21_DB
HRD1_bes21_LOG
HRD1_bes21_SPD
HRD1_bes21_SSTS

HRD1_bes31_DB
HRD1_bes31_LOG
HRD1_bes31_SPD
HRD1_bes31_SSTS

Pair logical volume group settings in the configuration definition of server machine 3

HRD1_UNT3_USTS
HRD1_bes11_DB
HRD1_bes11_LOG
HRD1_bes11_SPD
HRD1_bes11_SSTS
HRD1_bes21_DB
HRD1_bes21_LOG
HRD1_bes21_SPD
HRD1_bes21_SSTS

HRD1_bes31_DB
HRD1_bes31_LOG
HRD1_bes31_SPD
HRD1_bes31_SSTS

8.3.4 Setting up cluster software

In HiRDB's startup shell (package), specify the startup path for RAID Manager before the startup path for HiRDB.

8.3.5 Standby system operation

The following table shows, for each system switchover method, whether the instance of RAID Manager used by Real Time SAN Replication must be activated before starting the standby system and before switching over the system.

Table 8-3 Whether RAID Manager needs to be activated on the standby system

System switchover method | Whether RAID Manager needs to be activated
Immediately before starting the standby system | Immediately before switching over the system
Standby system switchover facility | Monitor mode | Not required | Required
Server mode
User server hot standby | Required
Rapid system switchover facility
Standby-less system switchover (1:1) facility
Standby-less system switchover (effects distributed) facility

8.4 Notes on using the security audit facility

The table below shows how the audit trail to be used is inherited after switching sites. This varies depending on the logical unit in which the HiRDB file system area for the audit trail file specified in the pd_aud_file_name operand is created.

Table 8-4 How the audit trail following is inherited after switching sites.

Operation | HiRDB file system area for the audit trail file
Unpaired paired logical volume group | Paired paired logical volume group#
The audit trail file created at the main site is passed to the remote site | N | Y
The audit trail data collected at the main site is loaded at the remote site | N | Y

Legend:

Y: Can be executed.

N: Cannot be executed.

#

During pairing, specify either data or never for the fence level, depending on the protection mode you are using.

8.5 Notes on using the automatic log unloading facility

The table below shows how the unload log file to be used is inherited after switching sites. This varies depending on the type of the output destination directory for the unload log file that is specified in the pd_log_auto_unload_path operand.

Table 8-5 How the unload log file is inherited after switching sites

Operation | Type of output destination directory for the unload log file
UNIX file system | HiRDB file system area
Unpaired paired logical volume group | Paired paired logical volume group#
The unload log file created at the main site is passed to the remote site | N | N | Y
The system log file unloaded at the main site is uploaded at the remote site | N | N | N

Legend:

Y: Can be executed.

N: Cannot be executed.

#

During pairing, specify either data or never for the fence level, depending on the protection mode you are using.

8.6 Notes on using the facility for monitoring the free area for system log files

Care must be exercised when the system definition operands are specified as follows:

pd_rise_use=Y

pd_rise_pairvolume_combination=hybrid

pd_rise_fence_level=data

pd_rise_disaster_mode = normal (or this operand is omitted).

pd_log_remain_space_check=safe

Note

If the KFPS02178-E message is output after scheduling of new transactions has been suppressed with output of the KFPS01160-E message, synchronization points are no longer acquired, meaning that the percentage of free area for the system log files will always be below the warning value. In this case, perform the following procedure to correct the problem:

Procedure

Determine the why the KFPS02178-E message was output and take the appropriate corrective action.

Execute the pdlogsync command on all servers whose status is TRNPAUSE, collect synchronization point dumps, and increase the percentage of free area for the system log files to at least the warning value.

8.7 Notes on using a shared table (applicable only to the hybrid method)

If any of the SQL statements shown in the table below are executed on a shared table when the hybrid method of Real Time SAN Replication is used, the system waits for the database to be synchronized at the remote site. Therefore, an overhead of at least 2 seconds may occur for each SQL statement.

Table 8-6 SQL that causes the system to wait for synchronization to the remote site

Target SQL | Condition
LOCK TABLE | EXCLUSIVE mode
COMMIT | No condition
ROLLBACK
DISCONNECT
CREATE TABLE
CREATE INDEX
DROP TABLE
DROP INDEX
ALTER TABLE | Change in the number of segments reused

For details about how to recover the database at the remote site when a pended synchronization of the database at the remote site fails, see 6. Error Handling.

Appendixes

Organization of the appendixes

A. Examples of System and Configuration Definitions

B. Sample Shell Program

C. Notes on Updating HiRDB

Appendix A. Examples of System and Configuration Definitions

This appendix provides sample HiRDB system definition specifications and RAID Manager configuration definitions when using Real Time SAN Replication in a HiRDB/Single Server. Note that the hybrid method is assumed in these examples.

Organization of this section

A.1 Hybrid method

Appendix A.1 Hybrid method

This section describes the HiRDB system definitions, RAID Manager configuration definitions, and server machine and disk configurations when using the hybrid method of Real Time SAN Replication.

Organization of this subsection

(1) System common definition example

(2) Unit control information definition example

(3) Single server definition example

(4) RAID Manager configuration definition example

(5) Server and disk configurations

(1) System common definition example

Main site

# ALL RIGHTS RESERVED. COPYRIGHT (C) 1994, 2006, HITACHI, LTD.
# LICENSED MATERIAL OF HITACHI, LTD.
#*******************************************************************************
# pdsys : system common definition
#*******************************************************************************
set pd_system_id = HRD1         #HRD1:system-id(change your environment)
set pd_name_port = 22200        #22200:port-number(change your environment)
set pd_mode_conf = MANUAL2
set pd_max_users = 2
set pd_max_access_tables = 50
set pd_rise_use = Y
set pd_rise_pairvolume_combination = hybrid
set pd_rise_fence_level = data
set pd_rise_disaster_mode = normal
     :
pdunit -x HST1 -u unt1 -d /opt/HiRDB_S
pdstart -t SDS -s sds01 -x HST1
pdbuffer -a gbuf01 -n 20 -r rdmast,rddirt -w 20
pdbuffer -a gbuf02 -n 20 -r rddict -w 20
pdbuffer -a gbuf03 -n 100 -o -w 20
     :
putenv HORCMINST 10

Remote site

# ALL RIGHTS RESERVED. COPYRIGHT (C) 1994, 2006, HITACHI, LTD.
# LICENSED MATERIAL OF HITACHI, LTD.
#*******************************************************************************
# pdsys : system common definition
#*******************************************************************************
set pd_system_id = HRD1         #HRD1:system-id(change your environment)
set pd_name_port = 22200        #22200:port-number(change your environment)
set pd_mode_conf = MANUAL2
set pd_max_users = 2
set pd_max_access_tables = 50
set pd_rise_use = Y
set pd_rise_pairvolume_combination = hybrid
set pd_rise_fence_level = data
set pd_rise_disaster_mode = normal
     :
pdunit -x HST2 -u unt1 -d /opt/HiRDB_S
pdstart -t SDS -s sds01 -x HST2
pdbuffer -a gbuf01 -n 20 -r rdmast,rddirt -w 20
pdbuffer -a gbuf02 -n 20 -r rddict -w 20
pdbuffer -a gbuf03 -n 100 -o -w 20
     :
putenv HORCMINST 10

(2) Unit control information definition example

Main site

# ALL RIGHTS RESERVED. COPYRIGHT (C) 1994, 2006, HITACHI, LTD.
# LICENSED MATERIAL OF HITACHI, LTD.
# example definition of HiRDB/single server
#*******************************************************************************
# pdutsys : unit control information definition
#*******************************************************************************
#-------------------------------------------------------------------------------
# set form
#
set pd_unit_id = unt1               #unt1:unit-name(change your environment)
set pd_hostname = HST1
set pd_syssts_file_name_1 = "utsts1",\
                  "/opt/HiRDB_S/rdsys01/utsts1a","/opt/HiRDB_S/rdsys02/utsts1b"
set pd_syssts_file_name_2 = "utsts2",\
                  "/opt/HiRDB_S/rdsys03/utsts2a","/opt/HiRDB_S/rdsys01/utsts2b"
set pd_syssts_file_name_3 = "utsts3",\
                  "/opt/HiRDB_S/rdsys02/utsts3a","/opt/HiRDB_S/rdsys03/utsts3b"
set pd_syssts_initial_error = stop
set pd_syssts_singleoperation = stop
#set pd_syssts_last_active_file = utsts1
#set pd_syssts_last_active_side = A

Remote site

# ALL RIGHTS RESERVED. COPYRIGHT (C) 1994, 2006, HITACHI, LTD.
# LICENSED MATERIAL OF HITACHI, LTD.
# example definition of HiRDB/single server
#*******************************************************************************
# pdutsys : unit control information definition
#*******************************************************************************
#-------------------------------------------------------------------------------
# set form
#
set pd_unit_id = unt1               #unt1:unit-name(change your environment)
set pd_hostname = HST2
set pd_syssts_file_name_1 = "utsts1",\
                  "/opt/HiRDB_S/rdsys01/utsts1a","/opt/HiRDB_S/rdsys02/utsts1b"
set pd_syssts_file_name_2 = "utsts2",\
                  "/opt/HiRDB_S/rdsys03/utsts2a","/opt/HiRDB_S/rdsys01/utsts2b"
set pd_syssts_file_name_3 = "utsts3",\
                  "/opt/HiRDB_S/rdsys02/utsts3a","/opt/HiRDB_S/rdsys03/utsts3b"
set pd_syssts_initial_error = stop
set pd_syssts_singleoperation = stop
#set pd_syssts_last_active_file = utsts1
#set pd_syssts_last_active_side = A

(3) Single server definition example

The same at the main site and the remote site

# ALL RIGHTS RESERVED. COPYRIGHT (C) 1994, 2006, HITACHI, LTD.
# LICENSED MATERIAL OF HITACHI, LTD.
# example definition of HiRDB/single server
#*******************************************************************************
# sds01 : single server definition
#*******************************************************************************
     :
set pd_log_dual = Y
#set pd_log_singleoperation = N
set pd_sts_file_name_1 = "sts1",\
               "/opt/HiRDB_S/rdsys11/sts1a","/opt/HiRDB_S/rdsys12/sts1b"
set pd_sts_file_name_2 = "sts2",\
               "/opt/HiRDB_S/rdsys13/sts2a","/opt/HiRDB_S/rdsys11/sts2b"
set pd_sts_file_name_3 = "sts3",\
               "/opt/HiRDB_S/rdsys12/sts3a","/opt/HiRDB_S/rdsys13/sts3b"
set pd_sts_initial_error = stop
set pd_sts_singleoperation = stop
set pd_spd_dual = Y
     :
#   --- system log file ---
pdlogadfg -d sys -g log1 ONL
pdlogadfg -d sys -g log2 ONL
pdlogadfg -d sys -g log3 ONL
pdlogadfg -d sys -g log4 ONL
pdlogadfg -d sys -g log5 ONL
pdlogadfg -d sys -g log6 ONL
pdlogadpf -d sys -g log1 -a "/opt/HiRDB_S/rdsys21/log1a"\
                        -b "/opt/HiRDB_S/rdsys22/log1b"
pdlogadpf -d sys -g log2 -a "/opt/HiRDB_S/rdsys21/log2a"\
                        -b "/opt/HiRDB_S/rdsys22/log2b"
pdlogadpf -d sys -g log3 -a "/opt/HiRDB_S/rdsys21/log3a"\
                        -b "/opt/HiRDB_S/rdsys22/log3b"
pdlogadpf -d sys -g log4 -a "/opt/HiRDB_S/rdsys23/log4a"\
                        -b "/opt/HiRDB_S/rdsys24/log4b"
pdlogadpf -d sys -g log5 -a "/opt/HiRDB_S/rdsys23/log5a"\
                        -b "/opt/HiRDB_S/rdsys24/log5b"
pdlogadpf -d sys -g log6 -a "/opt/HiRDB_S/rdsys23/log6a"\
                        -b "/opt/HiRDB_S/rdsys24/log6b"
#   --- syncpoint dump file ---
pdlogadfg -d spd -g spd1 ONL
pdlogadfg -d spd -g spd2 ONL
pdlogadfg -d spd -g spd3 ONL
pdlogadpf -d spd -g spd1 -a "/opt/HiRDB_S/rdsys31/spd1a"\
                        -b "/opt/HiRDB_S/rdsys32/spd1b"
pdlogadpf -d spd -g spd2 -a "/opt/HiRDB_S/rdsys31/spd2a"\
                        -b "/opt/HiRDB_S/rdsys32/spd2b"
pdlogadpf -d spd -g spd3 -a "/opt/HiRDB_S/rdsys31/spd3a"\
                        -b "/opt/HiRDB_S/rdsys32/spd3b"

(4) RAID Manager configuration definition example

Main site

HORCM_MON
#ip_address  service   poll(10ms)  timeout(10ms)
HST1         horcm          1000            3000

HORCM_CMD
#dev_name
/dev/rdsk/c0t0d1

HORCM_DEV
#dev_group           dev_name    port#  TargetID  LU#
HRD1_unt1_USTS       hitdev1     CL1-A         1    1
HRD1_unt1_USTS       hitdev2     CL1-A         1    2
HRD1_unt1_USTS       hitdev3     CL1-A         1    3
HRD1_sds01_SSTS      hitdev4     CL1-A         1    4
HRD1_sds01_SSTS      hitdev5     CL1-A         1    5
HRD1_sds01_SSTS      hitdev6     CL1-A         1    6
HRD1_sds01_LOG       hitdev7     CL1-A         1    7
HRD1_sds01_LOG       hitdev8     CL1-A         1    8
HRD1_sds01_LOG       hitdev9     CL1-A         1    9
HRD1_sds01_LOG       hitdev10    CL1-A         1   10
HRD1_sds01_SPD       hitdev11    CL1-A         1   11
HRD1_sds01_SPD       hitdev12    CL1-A         1   12
HRD1_sds01_DB        hitdev13    CL1-A         1   13
HRD1_sds01_DB        hitdev14    CL1-A         1   14
HRD1_sds01_DB        hitdev15    CL1-A         1   15
HRD1_sds01_DB        hitdev16    CL1-A         1   16

HORCM_INST#dev_group             ip_address  service
HRD1_unt1_USTS         HST2      horcm
HRD1_sds01_SSTS        HST2      horcm
HRD1_sds01_LOG         HST2      horcm
HRD1_sds01_SPD         HST2      horcm
HRD1_sds01_DB          HST2      horcm

Remote site

HORCM_MON
#ip_address  service   poll(10ms)  timeout(10ms)
HST2         horcm          1000            3000

HORCM_CMD
#dev_name
/dev/rdsk/c0t0d1

HORCM_DEV
#dev_group           dev_name    port#  TargetID  LU#
HRD1_unt1_USTS       hitdev1     CL1-D         2    1
HRD1_unt1_USTS       hitdev2     CL1-D         2    2
HRD1_unt1_USTS       hitdev3     CL1-D         2    3
HRD1_sds01_SSTS      hitdev4     CL1-D         2    4
HRD1_sds01_SSTS      hitdev5     CL1-D         2    5
HRD1_sds01_SSTS      hitdev6     CL1-D         2    6
HRD1_sds01_LOG       hitdev7     CL1-D         2    7
HRD1_sds01_LOG       hitdev8     CL1-D         2    8
HRD1_sds01_LOG       hitdev9     CL1-D         2    9
HRD1_sds01_LOG       hitdev10    CL1-D         2   10
HRD1_sds01_SPD       hitdev11    CL1-D         2   11
HRD1_sds01_SPD       hitdev12    CL1-D         2   12
HRD1_sds01_DB        hitdev13    CL1-D         2   13
HRD1_sds01_DB        hitdev14    CL1-D         2   14
HRD1_sds01_DB        hitdev15    CL1-D         2   15
HRD1_sds01_DB        hitdev16    CL1-D         2   16

HORCM_INST
#dev_group  ip_address  service
#dev_group             ip_address  service
HRD1_unt1_USTS         HST1      horcm
HRD1_sds01_SSTS        HST1      horcm
HRD1_sds01_LOG         HST1      horcm
HRD1_sds01_SPD         HST1      horcm
HRD1_sds01_DB          HST1      horcm

(5) Server and disk configurations

The following figure shows the server and disk configurations for this sample definition.

Figure A-1 Server machine and disk configurations when using the hybrid method

Appendix B. Sample Shell Program

When running Real Time SAN Replication, you can use this sample shell program to display the volume attributes and statuses of paired logical volume groups.

Organization of this section

(1) Where to find the sample shell program

(2) Preparation

(3) Sample shell program execution

(1) Where to find the sample shell program

The sample shell program is stored under $PDDIR/bin. The file name is pdpairdsp.sh.

(2) Preparation

The following preparation is necessary to use the sample shell program.

Procedure

Because the sample shell program must be customized for each usage environment, copy the sample shell program located in $PDDIR/bin to the current directory from which you will execute it.

Customize the sample shell program. The shell variable in the sample shell program must be changed based on the usage environment. The following table shows the shell variable that you must change.

Shell name | Variable name | Value to be specified
pdpairdsp.sh | HORCMINST | Specify the value of the HORCMINST operand in the system common definition.

Before executing the sample shell, start the instance of the RAID Manager that is to be used by Real Time SAN Replication.

(3) Sample shell program execution

A HiRDB administrator who also has RAID Manager administrator privileges can execute the sample shell program. Enter the following command line to execute the sample shell program.

pdpairdsp.sh paired-logical-volume-group-name[ paired-logical-volume-group-name ...]

paired-logical-volume-group-name: Specify the name of the paired logical volume group to be the target when executing the sample shell.

To specify multiple paired logical volume group names, delimit them using single-byte spaces.

Appendix C. Notes on Updating HiRDB

This appendix explains things to be aware of when updating HiRDB. Here, updating HiRDB means both upgrading the HiRDB version and updating the HiRDB update version. For details about upgrading and updating HiRDB, see the HiRDB Version 9 Installation and Design Guide.

Organization of this section

C.1 When using the all synchronous, all asynchronous, or hybrid method

Appendix C.1 When using the all synchronous, all asynchronous, or hybrid method

Organization of this subsection

(1) Preparatory tasks before updating

(2) Update tasks

(1) Preparatory tasks before updating

The table below shows preparatory tasks and whether they must be performed before updating HiRDB at the main site and the remote site. For details about each task, see the HiRDB Version 9 Installation and Design Guide.

Table C-1 Whether preparatory tasks must be executed at the main site and the remote site

Preparation item before updating | Main site | Remote site
Checking for free space | Y | N
Backing up the system RDAREA | Y#1 | N#1
Canceling library sharing | Y | Y
Checking for memory capacity | Y | Y
Checking whether HiRDB is running | Y | N#2
Normally terminating HiRDB | Y | N#2
Checking the memory requirement | Y | Y
Checking the OS operating system parameters | Y | Y
Checking the total number of records in the system log file | Y | N
Backing up the files under the HiRDB directory | Y#3 | Y#3
Upgrading optional program product versions | Y | Y

Legend:

Y: Preparation is required.

N: Preparation is not required.

#1

Back up the system RDAREA at the main site. Copy the backup you made to the remote site before starting the update process.

#2

This operation is not required if HiRDB is running at the main site.

#3

Back up of the files under the HiRDB directory at both the main site and the remote site. The backup from the main site cannot be used at the remote site, and the backup from the remote site cannot be used at the main site.

(2) Update tasks

The table below shows the update tasks and whether they must be executed at the main site and the remote site. For details about each task, see the HiRDB Version 9 Installation and Design Guide.

Table C-2 Whether update tasks must be executed at the main site and the remote site

Update task | Main site | the remote site
Removing the earlier version of HiRDB | Y | Y
Installing the new version of HiRDB | Y#1 | Y#1
Registering the new version of HiRDB in the OS | Y#2 | Y#2
Modifying the HiRDB definitions | -- | --
Starting HiRDB | Y | N
Executing the pdvrup command | Y | N
Backing up the system RDAREA | Y | N#3

Legend:

Y: Task is required.

--: Perform the task as needed.

N: Task is not required.

#1

Install the same new version of HiRDB at both the main and remote sites. The HiRDBs being installed at the main and remote sites must match in version, revision, addressing mode, and update version code (XX-XX-XX: underlined part).

#2

Execute the pdvrup command at both main site and the remote site to register the new version of HiRDB in the OS. During this step, use the same character code at the main and remote sites.

#3

Back up the system RDAREA at the main site and copy the backup to the remote site before starting the update process.

Index

[A][C][D][E][F][G][H][I][K][L][M][N][O][P][R][S][T][U][V]

(A)

abbreviations for products

all asynchronous method

all synchronous method

asynchronous copy

automatic log unloading facility

automatic log unloading facility

(C)

combination with other facilities (characteristics of individual processing methods)

command, requiring databases to be re-synchronized

commit or rollback (operation, requiring databases to be re-synchronized)

config file

conventions

abbreviations for products

diagrams

fonts and symbols

KB, MB, GB, and TB

version numbers

cost (characteristics of individual processing methods)

(D)

data (criteria for selecting protection mode)

data loss (characteristics of individual processing methods)

database, procedure for initializing

definition SQL on shared table, execution of (operation, requiring databases to be re-synchronized)

diagram conventions

disaster recovery system

building

tasks required to build

DISCONNECT (operation, requiring databases to be re-synchronized)

(E)

error analysis flow chart

error-handling method

(F)

file classification

file output format (transaction information file)

font conventions

(G)

GB meaning

(H)

HiRDB

notes on updating

preparatory tasks before updating

update tasks

HiRDB configuration

checking, at main site

checking, at remote site

HiRDB configuration item, checked by commands

HiRDB Datareplicator replication facility

HiRDB environment

building, at main site

building, at remote site

points to consider when setting up

HiRDB file system area

configuration example of

points to consider when creating

HiRDB file, location of (characteristics of individual processing methods)

HiRDB system

procedure for starting, at main site

startup method of

whether it is possible to start, at main site

HiRDB system definition, example of

Hitachi disk array system

Hitachi disk array system

HORCM_CONF

HORCMINST (operand to be specified)

horctakeover command execution example (taking control over paired logical volume groups (main site to remote site))

hybrid method

notes on operation when using

(I)

inner replica facility

inner replica facility

procedure for switching sites in event of disaster when using

procedure for switching sites to perform maintenance when using

procedure for switching sites to test disaster preparedness when using

instance

(K)

KB meaning

(L)

LOCK TABLE with lock mode specification on shared table, execution of (operation, requiring databases to be re-synchronized)

(M)

main site

building HiRDB environment at

checking HiRDB configuration at

handling disaster at, occurred while it was recovering from error

items that must be same with remote site

procedure for starting HiRDB system at

whether it is possible to start HiRDB system at

MB meaning

(N)

never (criteria for selecting protection mode)

(O)

operand, to be specified

operation

characteristics of individual processing methods

requiring databases to be re-synchronized

(P)

paircreate command execution example (generating paired logical volume group)

paired logical volume

adding

change in configuration of

deleting

moving

moving

procedure for adding, to existing paired logical volume group

procedure for deleting

procedure for moving, to existing paired logical volume group

procedure for moving, to new paired logical volume group

paired logical volume group

adding

changing name of

checking status of

checking status of

checking status of

generating

pair logical volume group

naming rules for

paired logical volume group

procedure for adding

procedure for adding paired logical volume to existing

procedure for changing name of

procedure for moving paired logical volume to existing

procedure for moving paired logical volume to new

taking control over

taking control over

pair volume

configuration example of

paired volume

configuration example of (all asynchronous method)

configuration example of (all synchronous method)

configuration example of (hybrid method)

pair volume

points to consider when designing

pd_dbsync_point (operand subject to restrictions)

pd_hostname

operand subject to restrictions

operand to be changed at remote site

pd_mode_conf (operand subject to restrictions)

pd_rdarea_open_attribute (related operand)

pd_rise_disaster_mode (operand to be specified)

pd_rise_fence_level

operand to be specified

pd_rise_pairvolume_combination (operand to be specified)

pd_rise_use (operand to be specified)

pd_spool_cleanup_interval_level (related operand)

pd_spool_cleanup_level (related operand)

pdclose (command, requiring databases to be re-synchronized)

pdhold (command, requiring databases to be re-synchronized)

pdorbegin (command, requiring databases to be re-synchronized)

pdorend (command, requiring databases to be re-synchronized)

pdrels (command, requiring databases to be re-synchronized)

pdstart operand

-m and -n options of (operand to be changed at remote site)

-x option of (operand to be changed at remote site)

pdunit operand

-c option of (operand to be changed at remote site)

-x option of (operand to be changed at remote site)

prerequisite platform

prerequisite product

primary volume

handling of errors on

procedure for handling errors on

primary volume error (HiRDB's actions when error occurs)

processing methods, characteristics of individual

protection mode

criteria for selecting

(R)

RAID Manager

failure to link to (HiRDB's actions when error occurs)

handling of failure to link to

RAID Manager administrator

RAID Manager command

executability of

execution environment

RAID Manager configuration definition

paired logical volume group name is missing from (HiRDB's actions when error occurs)

RAID Manager configuration definition example (hybrid method)

RAID Manager environment

building

points to consider when setting up

RAID Manager instance, starting

RAID Manager's config file

RDAREA, automatic extension of

operation, requiring databases to be re-synchronized

Real Time SAN Replication

relationships to other facilities

remote site

building HiRDB environment at

checking HiRDB configuration at

importing data to

items that must be same with main site

items to be changed at

period during which switchover to, cannot be guaranteed

period during which switchover to, cannot be guaranteed (RAID Manager command)

whether it is possible to switch to

route error

handling of

HiRDB's actions when error occurs

procedure for handling

(S)

sample shell program

secondary volume

handling of errors on

procedure for handling errors on

secondary volume error (HiRDB's actions when error occurs)

security audit facility

security audit facility

server and disk configurations (hybrid method)

shared table

shared table

single server definition example (hybrid method)

site switchover method

used when disaster occurs at main site

used while main site is running

statistical information collection

switching sites

in event of disaster

in event of disaster, procedure for

in event of disaster, results of

to perform maintenance

to perform maintenance, procedure for

to perform maintenance, results of

to test disaster preparedness

to test disaster preparedness, procedure for

whether you can, in event of disaster

symbol conventions

synchronization point dumps, collecting

synchronous copy

system common definition example (hybrid method)

system configuration example

system definition example

generating paired logical volume group

taking control over paired logical volume groups (main site to remote site)

system definition operand subject to restrictions

system log file, facility for monitoring free area for

system log file, facility for monitoring free area for

system reconfiguration command

system switchover facility

system switchover facility

(T)

take control over

take control over

TB meaning

transaction information file

transaction processing performance (characteristics of individual processing methods)

TrueCopy

(U)

unit control information definition example (hybrid method)

update copy

file targeted for

when error occurs during

(V)

version number conventions

volume, points to consider when designing

Trademarks

ActiveX is either a registered trademark or a trademark of Microsoft Corporation in the United States and/or other countries.
AIX is a trademark of International Business Machines Corporation in the United States, other countries, or both.
AIX 5L is a trademark of International Business Machines Corporation in the United States, other countries, or both.
AMD is a trademark of Advanced Micro Devices, Inc.
CORBA is a registered trademark of Object Management Group, Inc. in the United States.
DataStage, MetaBroker, MetaStage and QualityStage are trademarks of International Business Machines Corporation in the United States, other countries, or both.
DB2 is a trademark of International Business Machines Corporation in the United States, other countries, or both.
HACMP is a trademark of International Business Machines Corporation in the United States, other countries, or both.
HP-UX is a product name of Hewlett-Packard Company.
IBM is a trademark of International Business Machines Corporation in the United States, other countries, or both.
Itanium is a trademark of Intel Corporation in the United States and other countries.
Java is a registered trademark of Oracle and/or its affiliates.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Microsoft, and Excel are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
Microsoft Access is a registered trademark of Microsoft Corporation in the U.S. and other countries.
Motif is a registered trademark of the Open Software Foundation, Inc.
MS-DOS is a registered trademark of Microsoft Corp. in the U.S. and other countries.
ODBC is Microsoft's strategic interface for accessing databases.
OLE is the name of a software product developed by Microsoft Corporation and the acronym for Object Linking and Embedding.
Oracle and Java are registered trademarks of Oracle and/or its affiliates.Other company and product names mentioned in this document may be the trademarks of their respective owners.Throughout this document Hitachi has attempted to distinguish trademarks from descriptive terms by writing the name with the capitalization style used by the manufacturer, or by writing the name with initial capital letters. Hitachi cannot attest to the accuracy of this information. Use of a trademark in this document should not be regarded as affecting the validity of the trademark.
OS/390 is a trademark of International Business Machines Corporation in the United States, other countries, or both.
PowerHA is a trademark of International Business Machines Corporation in the United States, other countries, or both.
Red Hat is a trademark or a registered trademark of Red Hat Inc. in the United States and other countries.
Sun is either a registered trademark or a trademark of Oracle and/or its affiliates.
Sun Microsystems is either a registered trademark or a trademark of Oracle and/or its affiliates.
UNIFY2000 is a product name of Unify Corp.
UNIX is a registered trademark of The Open Group in the United States and other countries.
VERITAS is a trademark or registered trademark of Symantec Corporation in the U.S. and other countries.
Visual Basic is a registered trademark of Microsoft Corp. in the U.S. and other countries.
Visual C++ is a registered trademark of Microsoft Corp. in the U.S. and other countries.
Visual Studio is a registered trademark of Microsoft Corp. in the U.S. and other countries.
Windows is either a registered trademark or a trademark of Microsoft Corporation in the United States and/or other countries.
Windows NT is either a registered trademark or a trademark of Microsoft Corporation in the United States and/or other countries.
Windows Server is either a registered trademark or a trademark of Microsoft Corporation in the United States and/or other countries.
Windows Vista is either a registered trademark or a trademark of Microsoft Corporation in the United States and/or other countries.
X/Open is a registered trademark of The Open Group in the U.K. and other countries.
X Window System is a trademark of X Consortium, Inc.