Browse Prior Art Database

Database hot standby as disaster recovery with remote copy function

IP.com Disclosure Number: IPCOM000033907D
Original Publication Date: 2005-Jan-04
Included in the Prior Art Database: 2005-Jan-04
Document File: 5 page(s) / 1M

Publishing Venue

IBM

Abstract

SAP wrote an API for the RunTimeEnvironmentHotStandbyStorage (RTEHSS) with the following aim, "This API tries to establish an abstract layer between the storage system used and the SAPDB liveCache database. It is used internally by the SAPDB liveCache runtime environment only. It can be expanded due to needs of any storage solution, that wants to support liveCache HotStandby." [SAP description, RTEHSSDraft.pdf] The API considers that two database servers are connected to one storage subsystem. This consideration is not adequate to also cover disaster recovery aspects. Therefore two storage systems are required. This invention describes in detail how the existing API could be used to implement a disaster recovery solution for two sides. A extension to three and more sides could be implemented easily using the same structures. Other storage subsystems than IBM TotalStorage products, could also be used if they support the functionality SAP is requesting within their API.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 33% of the total text.

Page 1 of 5

Database hot standby as disaster recovery with remote copy function Database hot standby as disaster recovery with remote copy functionDatabase hot standby as disaster recovery with remote copy function Database hot standby as disaster recovery with remote copy function

Disclosed is a program which enhances the SAP MaxDB / liveCache hot standby API to enable a disaster recovery solution for MaxDB / SAP liveCache hot standby systems. This could be realized with remote copy functions of a storage device which keeps a pair of volumes (source and target) synchronized and allows read access to the target.

1.1 Description of the API:

    The Base of the HotStandby system is a fail over system, consisting of several (at least two) physically separated database server with a storage system that is physically shared between the instances. The controlling instance of the fail over system is used to detect the fail over situation and perform the operations needed to redirect client connections. The MaxDB Hot Standby implementation is based on two or more separated database servers that access a single storage system [2]

    Each database server must have an own unique network address. The network connection switch is not part of MaxDB but must be solved by third party software. The data volumes are separated, but the log volume is shared. Only the master has read write access to the log volume, the standby nodes have read only access. The functional layout is shown in Figure 1.

Application

Application

service name

service name

master

master

liv e C a c h e liv e C a c h e liv e C a c h e liv e C a c h e

liv e C a c h e liv e C a c h e liv e C a c h e liv e C a c h e

standby

standby

         Data After Images

         Data After Images

liv e C a c h e liv e C a c h e liv e C a c h e liv e C a c h e

liv e C a c h e liv e C a c h e liv e C a c h e liv e C a c h e

managed by HA Software

managed by HA Software

libhss libhss

libhss libhss

Cluster

Cluster

continuous

continuous

restore log

restore log

 Data Volumes Log Volumes Data Volumes

 Data Volumes Log Volumes Data Volumes

Storage System

Storage System

Figure 1: logical configuration of the standard hot standby system

    To support this API, a separate software library is required. This is a deliverable by a third party (e.g. storage vendor). The lib will convert the API calls into storage specific function calls. The different layers are shown in Figure 2.

1

[This page contains 2 pictures or other non-text objects]

Page 2 of 5

SAP liveCache / MaxDB

RTEHSS API

Storage specific library

 Storage subsystem

Figure 2: software layer for hot standby system

    The typical layout of the standard implementation is shown in Figure 3. The two nodes are using a storage area network for data transfer. The TCP/IP network is used for managing the storage system.

TCP/IP Network

TCP/IP Network

Node A

 AIX 5L MaxDB 7.5

Node A

 AIX 5L MaxDB 7.5

MaxDB 7.5

MaxDB 7.5

Cluster HACMP

Cluster HACMP

Node B

 AIX 5L MaxDB 7.5

Node B

 AIX 5L MaxDB 7.5

Storage Ar...