DMO Methodology

By Ashwin Venugopal -

 




SAP Database Migration Option Methodology

DMO processing

The shadow repository (development components/target version for ABAP workbench) is created by Software Update Manager (SUM) until the downtime phase on the traditional database while the target database is created alongside the copied shadow repository and the SAP database connection is switched to the target database starting the downtime process.

After the migration of the application data including data conversion, the upgrade is finalized while the SAP system is running on the target database. The unmodified application data is retained by the source database which always allow a fallback.

Prerequisites

The following steps should be followed if you want to migrate an existing SAP system running on anyDB to a SAP HANA database:

  • Dual-Stack split
  • Unicode conversion (for versions prior to NetWeaver 7.5)
  • Database upgrade of anyDB
  • Upgrade of SAP software

  DMO "Cutover Week"

As DMO offers fallback option during any phase, beginning DMO up-processing at least one week before the cutover allows sufficient time for the shadow repository.

Backup should be done before any kind of downtime activities, but if there is an issue during uptime activities, a simple fallback approach to remove the shadow instance will do; which also means dropping the shadow instance schema from the source database. Hence, it is very important to execute multiple migration test cycles to sort out all the problems before the productive migration.

DMO with System Move

The application server driving the migration can be easily changed as a part of the process i.e. SUM started on on-prem application server and switched to an application server running in Azure with the the help of the option "Enable the migration with system move" which is available from SUM 1.0 SP21. Eventually, the whole SUM directory is copied to Azure where the import process can continue on the new/target application server.  

The comparison between the classical DMO and DMO with System Move Option is as follows:

Parameter

Classical DMO

DMO with System Move

Purpose/Use Case

In place upgrade and migration

Cloud/Azure-based migration

Downtime Optimization Flexibility

High

Medium

Cloud Migration

Technically possible (but not currently officially supported by SAP)

Yes

Target Servers

Same application server can be used to connect to SAP HANA after migration

New servers need to be built-in Microsoft Azure

Options for Data Transfer

Memory pipes

Filesystem dump

Filesystem dump

Can use sequential or parallel load options

  

  






Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Deployment (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 3, please click  here Microsoft Sentinel Content Hub Content in Microsoft Sentinel includes any of the following types: Data connectors offer log ingestion from different sources into Microsoft Sentinel. Parsers give log formatting/transformation into ASIM formats, supporting usage across various Microsoft Sentinel content types and scenarios. Workbooks provide monitoring, visualization, and interactively with data in Microsoft Sentinel, highlighting meaningful insights for users.  Analytics rules give alerts that point to relevant SOC actions via incidents.  Hunting Queries are used by SOC teams to proactively hunt for threats in Microsoft Sentinel. Notebooks help SOC teams in using advanced hunting features in Jupyter and Azure Notebooks. Watchlists support the ingestion of specific data for enhanced threat detection and reduced alert fatigue.  Playbooks and Azure Logic Apps Custom Connectors provide featu...
Read more