maxdb standby

4
8/12/2019 MaxDB Standby http://slidepdf.com/reader/full/maxdb-standby 1/4

Upload: annyxb

Post on 03-Jun-2018

227 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: MaxDB Standby

8/12/2019 MaxDB Standby

http://slidepdf.com/reader/full/maxdb-standby 1/4

Page 2: MaxDB Standby

8/12/2019 MaxDB Standby

http://slidepdf.com/reader/full/maxdb-standby 2/4

Table of content1 SAP MaxDB Standby Database

PUBLIC© 2014 SAP AG or an SAP affiliate company. All rights reserved.

Page 2 of 4

Page 3: MaxDB Standby

8/12/2019 MaxDB Standby

http://slidepdf.com/reader/full/maxdb-standby 3/4

  1 SAP MaxDB Standby Database

 

 An SAP MaxDB standby database uses a copy of the original production database on a second hardware system. It considerably imp roves the overall reliability

of the database service.

The following graphic shows the setup for an SAP MaxDB standby database:

SAP MaxDB Standby Database

Features

Setup overview

The original production database is copied to a second location. The work done in the original database is recorded in the log area. The log area is backedup and transferred to the second location and read in there to keep the standby database up to date.

Separation of standby system from production system

The standby system is best located at a remote site, since otherwise it might also be affected by whatever caused the production system to fail.

Standby database as a copy of original database

The standby database consists of a restored complete data backup and restored backup files of the log entries created at the primary site and moved to the

standby site. The standby database does not have to be an exact physical copy of the original database. Database name, directory structures, and file

names might be different.

 Recommendation

The structure of the original database can be different to the structure of the standby database. We recommend that the number and size of the log

volumes for both databases are the same.

Structural database changes

Changes to the structure of the original databases might affect the standby database. Certain changes can be applied on the standby database. A

discussion of potential problems with structural changes follows.Standby database runs in ADMIN state

Once the standby database has restored the complete backup of the original database, it is put in recovery mode and performs recovery steps. The

backup files of the log backups at the production site have to be shipped to the remote site and read in there using the database recovery mechanisms.

This performs a “redo” of all work done in the original database in the standby database by repeating all transactions that changed data. The standby

database always lags s lightly behind because the log area used by the original database needs to be shipped first.

 An accidental restart to operational state ONLINE invalidates the standby database.

What happens when the production database fails?

If the original production database becomes unavailable, the standby database has to be restarted to operational state ONLINE. When the original database

fails, some committed transactions might be lost, because the current log area that the original database was using at the time of the disaster might be

inaccess ible. The standby database can then only be recovered to the state reflected in the last saved backup file (log backup).

Before activating the standby database, always try to save the current log area in the original database, ship it to the standby site and apply it.

 Caution

Make sure that you immediately perform a backup of the standby database once it is in operational state ONLINE. If no backup is performed and

problems occur in the standby database, all work done since the activation is lost. This backup is also important to enable you to subsequently restorethe database at the production site.

What happens if the original database b ecomes available again?

If the original production site becomes available again, we recommend you not to use (that is, start) the original database. The reason for this is that it is

PUBLIC© 2014 SAP AG or an SAP affiliate company. All rights reserved.

Page 3 of 4

Page 4: MaxDB Standby

8/12/2019 MaxDB Standby

http://slidepdf.com/reader/full/maxdb-standby 4/4

impossible to apply newly made transactions from the now productive standby database to the original database. These transactions are lost when you

revert to the original configuration (see next point below).

Reverting to the original configuration

If the standby database is put into production operation due to a disaster, it should then be considered the production system. Once you have resolved the

disaster situation at the production site, you should use the former original database as standby database or you have to decide on how to switch back to the

original configuration, if that is desired.

Activities

When you plan to set up a standby database, note the following:

Structural database changes

 A data volume added to the original database is not automatically added to the standby database. However, you can add a data volume to the standby

database as follows:

1. Stop the log recovery in the standby database.

2. In operational state ADMIN, add the data volume to the standby database.

The fill level of the data area of the standby database can become too high if you forget to add data volumes in time, causing the recovery

process to abort.

3. Resume the recovery

 A log volume added to the original database does not affect the standby database. You can add the log volume to the standby database while it is in

operational state ADMIN.

Structural changes should not cause major problems. For more information, see the appropriate SAP MaxDB documentation.

Copy of backup files not automated

SAP MaxDB does not provide automated procedures to copy the saved log as backup files from the original database to the standby database. You have to

manage this yourself. For more information, see the link at the end of this section.

Recovery of standby database not automated

SAP MaxDB does not provide a mechanism to automatically start the permanent recovery of the standby database. For more information, see the link at theend of this section.

I/O errors and disk failures

I/O errors and disk failures on the standby database can cause an emergency shutdown. If this occurs, resolve the disk p roblems and reinitialize the

standby database.

Data corruption during transfer 

Compression utilities used to electronically transfer files from one computer to another might cause data corruption. Make sure that the data backups and the

backup files are transferred in such a way that no corruption or loss of files can occur.

More Information

SAP MaxDB: Replication and High Availability

PUBLIC© 2014 SAP AG or an SAP affiliate company. All rights reserved.

Page 4 of 4