Summary:
In business continuity, solution is mainly designed based on , RTO (Recovery time objective) and RPO (Recovery Point Objective) criterias. What about the integrity of business data between integrated systems especially in complex application environments? At this point, In addition to these criterias, RCO (Recovery Consistency Objective) ,which defines a measurement for the consistency of distributed business data within interlinked systems after a disaster incident, must be taken into consider.
In SAP environments systems are integrated and data exchanged between like CRM-ERP-BI-PI systems. In case of a recovery situation not the single system but the whole environment data consistency becomes an issue. This is also mentioned in SAP Note “434647 - Point-in-time recovery in an SAP system group”
In the case of a point-in-time recovery, you must weigh up the following factors: · Consistency within the system to be restored · Consistency between the system to be restored and all remaining systems in the landscape · Loss of data in the systems that are part of the landscape Basically, there are three variants of a point-in-time recovery for systems in a system landscape and each of these has different effects on the amount of data that is lost or the number of inconsistencies. a) Point-in-time recovery only in the affected system: If you use this variant, only the affected system is reset to a previous version. In this variant, the number of inconsistencies is at its highest; however, the amount of data lost is restricted to one system. You may also be able to recover the missing data from the data in the other components. b) Point-in-time recovery for all components that are part of the system landscape: All components in the landscape are reset to the same version. In this variant, only a few inconsistencies remain and this is because the system clocks do not run to exactly the same time on the different computers. The amount of data lost is higher than in the first variant and there is no option to restore the data from the other components. c) Importing a consistent backup of the entire landscape (if this exists): In this variant, you import a consistent backup of the entire system landscape. However, to do this, you must have created this type of backup at some time before the cause of the error. Since this time is generally not just before the cause of the error, the amount of data lost is greatest in this variant but no inconsistencies exist between the systems. |
As defined in option b) , if data loss tolerable all the systems can be opened at same time in sake of consistency.
In this whitepaper, we will discuss about same point in time opening of disaster SAP systems which are replicated with Oracle data guard.
Clock difference :
To overcome time differences between integrated systems and disaster systems a central NTP can be configured for all systems.
Figure 1:Time synchronization between SAP environment
Oracle Data Guard Same Point In Time Opening Options:
Option 1: Delayed applied + Forward point in time recovery:
Oracle data guard configuration parameters allows delayed application of transferred redologs at standby database. Offline redologs transferred to standby without waiting, but they are hold until the delay time passes. This configuration ensures, the standby database data comes after a specified delay time. This delay time can be configured for all systems. In case of disaster, all systems can be recovered to a determined time by using already transferred (but not applied because of delay time) redologs. Delay option is specified in log_archive_dest_2 parameter.
alter system set log_archive_dest_2='service="TST_ODM"','ARCH SYNC NOAFFIRM delay=120 OPTIONAL max_failure=600 reopen=30 register' scope=spfile; |
Let’s clear this with an example. In this example there are three systems ERP,CRM and PI. Configured delay time is two hours. Disaster occurred at 15:00 o’clock.
System | Last transferred | Last Applied |
ERP | 14:30 | 13:00 |
PI | 14:55 | 13:00 |
CRM | 14:50 | 13:00 |
Here the lowest last transferred system is ERP. So all systems can be restored until 14:30 and can be opened at 14:30 using oracle point in time recovery commands.
recover STANDBY database until time '2012-07-19:14:30:00'; |
Figure 2: Delayed applied standby same time opening with roll forward recovery
Option 2: Real Time Apply + Flashback recovery:
By enabling flashback at standby side, it can be possible to rewind all standby databases in same point time. In this configuration transferred redologs are applied as soon as they arrived to standby side. Flashback feature allows database to be rewind within a specified retention window. DB_FLASHBACK_RETENTION_TARGET parameter specifies the upper limit (in minutes) on how far back in time the database may be flashed back. Prereqs of this option:
- Real time apply :Dataguard must be configured with LGWR method and standby redologs.
- Flashback must be enabled at standby side. Enough disk space must be provided according to retention time and database log generation rate.
In this configuration , our systems in previous example would behave like in Figure 3. The oldest data time would be in SAP ERP system at 14:30. Since other two systems data are ahead of this system they needed to be rewind same point in time with ERP. This can be achieved by flashback command.
Figure 3: Real time apply same time opening with flashback recovery
Adding Standby redo logs:
The size of the current standby redo log files must exactly match the size of the current primary database online redo log files. For example, if the primary database uses two online redo log groups whose log files are 200K, then the standby redo log groups should also have log file sizes of 200K.
Minimally, the configuration should have one more standby redo log file group than the number of online redo log file groups on the primary database.
ALTER DATABASE ADD STANDBY LOGFILE GROUP 21 ( '/oracle/TST/origlogA/standby/log_g21m1.dbf', '/oracle/TST/mirrlogA/standby/log_g21m2.dbf' ) SIZE 50M BLOCKSIZE 512; |
LGWR Method with maximum performance mode:
Oracle 10g without compression alter system set log_archive_dest_2='service="BSP_ODM"','LGWR ASYNC NOAFFIRM OPTIONAL max_failure=600 reopen=30 register' scope=both; Oracle 11g with compression alter system set log_archive_dest_2='service="BSP_ODM"','LGWR ASYNC COMPRESSION=ENABLE NOAFFIRM OPTIONAL max_failure=600 reopen=30 register' scope=both; |
Starting real time apply at standby database:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; |
Enabling Flashback:
alter system set DB_RECOVERY_FILE_DEST_SIZE=50G; alter system set db_recovery_file_dest='/oracle/TST/oraflash; alter database flashback on; alter system set db_flashback_retention_target=120; |
Rewinding database to a specified point in time with flashback command
FLASHBACK DATABASE TO TIMESTAMP to_timestamp('2012-07-19 14:30:00', 'YYYY-MM-DD HH24:MI:SS'); |
- SAP Managed Tags:
1 Comment
