OID Replication and Recovery from various failure situations (Doc ID 1087124.1)

Last updated on AUGUST 30, 2023

Applies to:

Goal

This document will describe the different scenarios where, for whatever reason, OID replicated environment is either completely or partially not functional. This might mean loss of data or logically corrupted data, or loss of OID node permanently or temporarily. Although word “recovery” is used, this does not necessarily mean the same as database recovery operation, although that can be part of the operations required. This article will cover both ASR Multi-Master Replication (referred as ASR in this article), and LDAP based Replication. Also, when applicable, differences between versions 10g and 11g are discussed.

1. Backups
Backup strategy is obviously important factor is the failure requires that some data is restored from a backup. With OID, the following backup strategies can be used:
• Database backup with or without archivelogs
• Database export/import
• No backup. Although this is not recommended, it is possible to recover from some situations using the data from other nodes, assuming there’s a node with good data. In this strategy, replicas act as backups for each others.
• LDIF file based backups, created with ldifwrite

2. Recovery
At this point, word recovery refers to data restore, using backups. Obviously, the available recovery options are dictated by the backup strategy. There are two different recovery scenarios:
• Complete Recovery (all lost data can be restored)
This is possible if there is a full database backup and database is running in archivelog mode, or if there is at least one node with good and up to date data.
• Incomplete Recovery
With all other backup strategies than those mentioned above, complete recovery is not normally possible. This is because backup is a snapshot from the time in the past, so there might have been changes in the data since the backup was taken.

It is obvious that in most cases complete recovery is the desired goal. Incomplete recovery may be needed if some data was mistakenly deleted, and there’s a need to get back to the point of time when that data was still available. Note, that like in all distributed systems, if incomplete recovery is required, the same operation needs to be performed on all nodes, otherwise data is inconsistent.

Solution

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.