Downtime-Optimized DMO: Introduction: Using SUM 2.0 SP 12 and Higher

Downtime-Optimized DMO: Introduction
Using SUM 2.0 SP 12 and higher
October 2021
Cloud and Lifecycle Management, SAP SE
Boris Rubarth, Product Manager, CLM
PUBLIC
Downtime-Optimized DMO (1-pager)
Reducing the technical downtime: migrate large application tables in uptime
Technical downtime of a database migration (DMO run of SUM) scales with database size
➢ Downtime-optimized DMO approach moves migration of selected large application tables to uptime
➢ A delta replay mechanism ensures that any uptime changes (by end users) are considered
See SAP Note for DMO about Prerequisites and Restrictions

© 2021 SAP SE or an SAP affiliate company. All rights reserved. ǀ Downtime-optimized DMO introduction | Attachment to SAP Note 2547309 2
Agenda
Introduction Motivation, procedure overview
Project Considerations Table selection, impact analysis
How to Enable the feature, monitor the replication
Architecture Illustration of relevant steps
Downtime-Optimized DMO: Motivation
▪ Technical downtime of Database Migration Option (DMO) of SUM scales with database size
▪ Optimization of DMO is possible and recommended
▪ For specific projects, further downtime reduction may be required
Downtime-Optimized DMO migrates selected large application tables already in uptime
➢ Technical downtime is reduced significantly
➢ Delta on table content (end user activity) is considered by SUM
➢ Approach is generally available with SUM 2.0 (with SP 06 and higher),

for a migration targeting Suite-on-HANA as well as for a system conversion to SAP S/4HANA
Downtime-Optimized DMO
Procedure overview
Standard DMO of SUM
Uptime Business Downtime
Shadow Repository Migration of

application tables
Migration part Update part

Downtime
reduced
Downtime-optimized DMO of SUM
Shadow Repository Migration of large Migration of remaining

application tables application tables
Sequence
Delta depends on
Initial migration
user change rate
Uptime
delta migration
Downtime final
delta migration
Remaining
tables migration
Downtime-optimized DMO of SUM
Shadow Repository Migration of

Migration of large remaining
application tables application tables
Trigger are set in MAIN SHD RUN
Agenda
Agenda
Project considerations
Table selection
Impact analysis
Downtime-Optimized DMO: Project Considerations (1/2)
▪ Recommended Sequence is
▪ Run standard DMO with optimizations
▪ Determine large tables for uptime migration
▪ Run downtime-optimized DMO on copy of PRD
▪ (optional) Run downtime-optimized DMO on PRD until end of uptime, determine change rate on selected tables, reset
▪ Start downtime-optimized DMO on PRD, using one weekend for initial data transfer, following weekend for downtime
▪ Note
▪ SUM uses its own delta record and replay technology (CRR), no DMIS AddOn is required
▪ Hardware requirements: the additional shadow instance is used on the PAS host
Downtime-Optimized DMO: Project Considerations (2/2)
Additional activities compared to standard DMO project:

➢ Determination of large application tables to be migrated
➢ Estimation of change rate and possible replication rate
➢ Impact analysis
➢ SLT Trigger considerations: trigger to be re-established on target; (MaxDB as source: trigger can’t remain)
➢ Monitoring of table replication
➢ If tables are specified that can’t be replicated, an error is displayed, and the table name has to be removed from the list
Agenda
Table selection
Impact analysis
Downtime-Optimized DMO: How to select tables for uptime migration
➢ Downtime-optimized DMO allows to migrate selected application tables already in uptime
➢ Table names have to be provided to SUM in plain text file
➢ Manual selection would use table size as criterion, but:

➢ Migration duration is not always linear to table size
➢ SUM restrictions apply: not all tables can be chosen, e.g. BASIS tables are not suitable
➢ Change rate is relevant: tables with high change rate shall not be selected,
as replication may not be fast enough to work against change rate
=> Use a report to cover these aspects, described on following slides
Report RSUPGBA_DODMO_SELECT for table selection
Estimated
Create text file containing
downtime
names of selected tables
reduction
Shows if table is suitable
Migration duration Change rate

as criterion is shown
Providing Information to Report RSUPGBA_DODMO_SELECT
Migration duration
➢ File SUM/abap/doc/analysis/MIGRATE_DT_DUR.XML
Table sizes From standard
▪ File SUM/abap/log/EUMIGRATEDTSIZES.LOG DMO run on SBX
Tables anyhow migrated in uptime (undergoing R3trans import)

➢ File SUM/abap/var/ALLTABU.DAT
Table statistics (change rate like updates, inserts, deletes)
➢ File SUM/abap/save/ZDIMPANA.ZIP (created by a different report, see later)
For a system conversion only: specific tables can’t be selected as anyhow handled in uptime
➢ File SUM/abap/mem/SFIN_TABLES.DMP
➢ dynamically determined after standard conversion run
Report RSUPGBA_DODMO_SELECT
▪ RSUPGBA_DODMO_SELECT delivered with SAP BASIS 7.53 SP 1
▪ RS_DODMO_SELECT delivered with SUM toolimport
Run standard DMO (Conversion) procedure on SBX, then

• If target is SAP_BASIS 7.53 FPS1 or higher, use RSUPGBA_DODMO_SELECT
• If target SAP_BASIS < 7.53 FPS1: use RS_DODMO_SELECT (before dialog REQUPFINAL, since deleted afterwards)
Statistics file ZDIMPANA.ZIP
Created by report ZRSUPG_IMPACT_ANALYSIS_EXPORT
➢ Create report and transport report to PRD

(follow SAP Note 2402270) Report
ZRSUPG_IMPACT_ANALYSIS_EXPORT
➢ Run report and export table statistics from PRD
PRD
SUM/abap/save/ZDIMPANA.ZIP
RSUPGBA_DODMO_SELECT SBX
➢ Import file for Table selection report

RSUPGBA_DODMO_SELECT on SBX
Tables not supported in scenario DMOCRR
In case you (manually select and) specify a

table that is not allowed, SUM will throw an
error. You will have to remove the table name
from the cached SUM file
SUM/abap/mem/DMOCRRTABLES.LST
manually then
Agenda
Table selection
Impact analysis
Impact Analysis (1/2)
Why Impact Analysis is relevant
Downtime-optimized DMO includes additional activities: table content is migrated during uptime
➢ Changes on these tables (by end-user activities) must be recorded via triggers
This can result in the consequence:

➢ Change recording increases the daily database growth
To avoid business impact on your production system, it is necessary to estimate in advance how
much additional database space will be required. The Impact Analysis approach provides an
estimation for this.
SAP Note 2402270 - Export of Table Statistics for SUM Impact Analysis
SAP Note 2481983 - SUM Impact Analysis for downtime-optimized DMO
Impact Analysis (2/2)
HowTo execute the Impact Analysis
Procedure:
Report
➢ Create report and transport report to PRD ZRSUPG_IMPACT_ANALYSIS_EXPORT
(SAP Note 2402270)
➢ Run report and export table statistics from PRD PRD
➢ Use table statistics for DMO run on SBX SUM/abap/save/ZDIMPANA.ZIP

(SAP Note 2481983)
➢ Analyze log file provided by SUM

(examples provided in SAP Note 2481983) Software Update Manager SBX
Phase
RUN_IMPACT_ANALYSIS_DODMO
SUM/abap/log/IMPANAUPG.<SID>
Agenda
Choosing the scenario
Check status on end of uptime
Link to CRR Control Center, the

replication monitor section
in SUM Utilities (see next page)
Replication monitoring and configuration
Part of SUM Utilities section
SUM 2.0 SP 06 (and higher): Replication based on TMP instance and R3load
SUM uses one approach for replication for

• downtime-optimized DMO (targeting a Suite-on-HANA system)
• downtime-optimized Conversion (targeting SAP S/4HANA)
Non-cluster tables are replicated by an additional instance (TMP instance)
Cluster tables are replicated by R3load mechanism

New kernel versions 7.53 are no longer cluster-aware, can’t read clusters.
R3load is used for cluster table replication, even for lower target releases like Suite-on-HANA
New with SUM 2.0 SP 08 (and higher):
▪ Only tables that require collision handling are replicated by ABAP (so tables that get an import)
▪ All other tables are replicated with R3load
Agenda
Downtime-Optimized DMO: Procedure Start
PAS Host
PAS
Source PRD Instance
Kernel
SUM
SUM is started
TGT Kernel
Legende
PRD REP Target

Release
Application Data
Source
Release
Source DB Host SAP HANA DB Host
Downtime-Optimized DMO: Shadow repository
PAS Host
PAS
Source
Uptime:
Kernel
SUM Shadow repository
is created on the target database
SHD Instance
TGT Kernel
PRD REP SHD REP

Application Data

Downtime-Optimized DMO: Initial Transfer of Triggered Tables
PAS Host
PAS Uptime:
Source Initial transfer of
Kernel triggered tables
SUM
R3load R3load
TMP Instance
TGT Kernel
PRD REP SHD REP

Application Data Application Data

Downtime-Optimized DMO: Delta migration of triggered tables
PAS Host
PAS
Source
Kernel Uptime:
SUM Delta replication of
R3load R3load relevant tables
TMP Instance
ABAP
TGT Kernel
PRD REP SHD REP

* Secondary DB connection
Downtime-Optimized DMO: Remaining migration of triggered tables
PAS Host
PAS Downtime:
Source Remaining Delta
Kernel transfer of
SUM triggered tables
R3load R3load
TMP Instance
ABAP
TGT Kernel
PRD REP SHD REP


Downtime-Optimized DMO: Migration of remaining tables
PAS Host
PAS Downtime:
Source Non-triggered
Kernel application tables
SUM are migrated
R3load R3load
TMP Instance
TGT Kernel
PRD REP SHD REP


Downtime-Optimized DMO: Software Update
PAS Host
PAS
TGT
Kernel Downtime:
SUM Target kernel
for PRD instance
PRD REP SHD REP


Downtime-Optimized DMO: Procedure finished
PAS Host
Downtime:
PAS
TGT Application tables
Kernel are updated
SUM
Procedure finished
PRD REP PRD REP


Thank you.
Boris.Rubarth@sap.com

Downtime-Optimized DMO: Introduction: Using SUM 2.0 SP 12 and Higher

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Downtime-Optimized DMO: Introduction: Using SUM 2.0 SP 12 and Higher

Uploaded by

Copyright:

Available Formats

Downtime-Optimized DMO: Introduction

Using SUM 2.0 SP 12 and higher

See SAP Note for DMO about Prerequisites and Restrictions

Introduction Motivation, procedure overview

Project Considerations Table selection, impact analysis

How to Enable the feature, monitor the replication

Architecture Illustration of relevant steps

▪ Optimization of DMO is possible and recommended

▪ For specific projects, further downtime reduction may be required

Downtime-Optimized DMO migrates selected large application tables already in uptime

➢ Technical downtime is reduced significantly

➢ Delta on table content (end user activity) is considered by SUM

➢ Approach is generally available with SUM 2.0 (with SP 06 and higher),

Shadow Repository Migration of

Migration part Update part

Shadow Repository Migration of large Migration of remaining

Shadow Repository Migration of

Introduction Motivation, procedure overview

Project Considerations Table selection, impact analysis

How to Enable the feature, monitor the replication

Architecture Illustration of relevant steps

Introduction Motivation, procedure overview

Project Considerations Table selection, impact analysis

How to Enable the feature, monitor the replication

Architecture Illustration of relevant steps

Additional activities compared to standard DMO project:

➢ Estimation of change rate and possible replication rate

➢ Monitoring of table replication

Introduction Motivation, procedure overview

Project Considerations Table selection, impact analysis

How to Enable the feature, monitor the replication

Architecture Illustration of relevant steps

➢ Downtime-optimized DMO allows to migrate selected application tables already in uptime

➢ Table names have to be provided to SUM in plain text file

➢ Manual selection would use table size as criterion, but:

=> Use a report to cover these aspects, described on following slides

Shows if table is suitable

Migration duration Change rate

Tables anyhow migrated in uptime (undergoing R3trans import)

▪ RSUPGBA_DODMO_SELECT delivered with SAP BASIS 7.53 SP 1

▪ RS_DODMO_SELECT delivered with SUM toolimport

Run standard DMO (Conversion) procedure on SBX, then

➢ Create report and transport report to PRD

➢ Import file for Table selection report

In case you (manually select and) specify a

Introduction Motivation, procedure overview

Project Considerations Table selection, impact analysis

How to Enable the feature, monitor the replication

Architecture Illustration of relevant steps

This can result in the consequence:

➢ Run report and export table statistics from PRD PRD

➢ Use table statistics for DMO run on SBX SUM/abap/save/ZDIMPANA.ZIP

➢ Analyze log file provided by SUM

Introduction Motivation, procedure overview

Project Considerations Table selection, impact analysis

How to Enable the feature, monitor the replication

Architecture Illustration of relevant steps

Link to CRR Control Center, the

SUM uses one approach for replication for

Non-cluster tables are replicated by an additional instance (TMP instance)

Cluster tables are replicated by R3load mechanism

New with SUM 2.0 SP 08 (and higher):

▪ All other tables are replicated with R3load