migration to hana part 2

8/9/2019 Migration to HANA Part 2

http://slidepdf.com/reader/full/migration-to-hana-part-2 1/48

SAP Innovation Summer CampCome with a Curiosity – Leave with a Plan

July 12 - 13, 2012 | SAP Americas HQwww.sap.com/sapsummercamp



© 2012 SAP AG. All rights reserved. 2

Disclaimer

This presentation outlines our general product direction and should not be relied onin making a purchase decision. This presentation is not subject to your licenseagreement or any other agreement with SAP. SAP has no obligation to pursue anycourse of business outlined in this presentation or to develop or release anyfunctionality mentioned in this presentation. This presentation and SAP's strategy

and possible future developments are subject to change and may be changed bySAP at any time for any reason without notice. This document is provided without awarranty of any kind, either express or implied, including but not limited to, theimplied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP assumes no responsibility for errors or omissions in thisdocument, except if such damages were caused by SAP intentionally or grosslynegligent.



Infrastructure TrackSAP HANA and Cloud Enabled Com put ing Center




Agenda

Migration to HANA Part 2 - Critical Aspects of a BW Migration to SAP HANA

Migration Methods - Classic vs. Downtime Minimized vs. Greenfield

BW Migration Preparation Activities – Data Volume Reduction, Internal/ExternalDependencies, Software Versions, Unicode Conversion…

Post Migration Changes - Optimizing BW for SAP HANABoundary Conditions to Consider – Peak volume periods, Parallel Projects,Business Downtime vs. System Availability…

Additional Considerations – Operational Readiness, Performance Management



Migration Methods




Migration MethodsCommon Migration Approaches

Summary• A full copy of the database is migrated from the source

to target• Common for systems with resident transactional data

(e.g. ECC, CRM…)

Advantage• Provides nearly an identical system• Minimal impact on functional teams

Disadvantage• Depending on the DB size, the downtime can be extensive

System Migration Data or Content Migrationto a New Installation

Database BDatabase ADatabase BDatabase A

Repository Repository

Customizing

Application Data1:1

Repository

Customizing

Application Data

Repository

Customizing

Application Data

TransportedCustomizing

Application Data

Summary• Installation of a new system on the targeted platform, and

manual migration of data• Less common, but possible for systems without resident

transactional data (PI, BW, & EP)

Advantage• Provides an opportunity to correct design issues• Reduced database size, as selected data will be migrated

Disadvantage• Increased effort to deploy


http://slidepdf.com/reader/full/migration-to-hana-part-2 7/48© 2012 SAP AG. All rights reserved. 7

Starting point: BW 7.0x (+ optional add-ons)

Downtime MinimizedApproach

ProcedureCloning of delta queues

System copy of productive BWsystem and rename of copy

Upgrade (if required) andmigration of copy to BW 7.31 onSAP HANA

Reconnect to source systemswithout new initialization

Parallel operation for short time

Common DriversFurther upgrades or otherdowntime intensive preparationsrequired

Downtime is limitingfactor

B

Classic Approach

ProcedureUpgrade (if required) and OS/DBmigration leveraging much of theexisting infrastructure in the targetenvironment

Common DriversRequirement to reuse existinghardware in the targetinfrastructure

No requirement for parallel

operationDowntime is not a limiting factor

A

Parallel ImplementationApproach

ProcedureNew installation of BW 7.31 onHANA

Objects are transported from oldto new BW

Content migration

Data must be loaded from sourcesystems to BW on SAP HANA

Common DriversRedesign of data model or otherapplication changes required

C

Migration MethodsSAP BW on HANA Overview



Step 6: Database migration and Unicode conversion

Step 4: Upgrade to 7.31 and SEM 7.36

Step 3: Dual-stack split to separate BW ABAP and BW Java stacks

Step 2: Oracle upgrade from version 10 to 11 (BW only released for Oracle 11)

Step 1: OS upgrade from HP-UX 11.23 to HP-UX 11.31

Migration MethodsExample Migration Scope

Starting point: Non-Unicode BW 7.00 with SEM 6.00on HP-UX 11.23 and Oracle 10.2

Target State: SAP NetWeaver BW 7.31 Powered By SAP HANA



Migration MethodsOption A: Classic Heterogeneous Migration Approach 1/2

OverviewFor the classic approach no System Copy or otherparallel set up is required. The migration and otherrequired steps (e.g. Upgrade to BW 7.31) isperformed directly in DEV, QAS and PRD system.This approach typically requires significantdowntime for the productive system.

The downtime duration depends on the size of theDB and the full scope of the project, specifically thecomplexity and number of additional steps (e.g.upgrade, Unicode conversion, etc.). As a rule ofthumb, the migration throughput from a traditional

DB to SAP HANA is roughly 150 – 250 Gb/h.This system migration approach, from the point ofview of hardware, interfaces, and overallcomplexity, is the simplest migration method.

The fallback solution to the original system ispossible only via restore.



ERP 6.0SCM 7.0 …. Source systems forextraction to BW

RDBMS

D e l t a Q u e u e

( o r i g )

D e l t a

Q u e u e

( o r i g )

D e l t a

Q u e u e

( o r i g )

BW

1. Start uptime activities of the classicalupgrade

A

Migration MethodsOption A: Classic Heterogeneous Migration Approach 2/2

RDBMS

BW ABAP BW Java

Initial Environment*BW 7.00/SEM 6.00

RDBMS

BW 7.31 /SEM 7.36

Upgradeof BW

ABAPSystem

SAP HANA

BW ABAP

BW 7.31 /SEM 7.36

BW 7.00/SEM 6.00

BW ABAP

SybaseASE

BW Java

BW 7.31/SEM 7.36

Migration ofBW ABAPDB to SAP

HANA

Target Environment

3. Ramp-down of production use on theinitial environment

2. Start of the business downtime

4. Execution of downtime phases of theclassical upgrade

5. Post-upgrade and pre-migration / Unicodeconversion steps

8. New Installation of BI Java (Sybase ASEcan be used)

6. Migration conversion to SAP HANA andUnicode

9. Ramp-up process to reinstate productiveoperations, including delta queue

processing

7. Post migration / Unicode conversionsteps

Interim State

*Note: The initial environment is no longer available following the migration other than

via a restore.



Migration MethodsOption B: Downtime Minimized via Delta Queue Cloning 1/3

Overview The migration and other required steps are performedon a full system copy of the production system,resulting in parallel productive systems (for apredefined period of time).

Depending on the underlying infrastructure, thedowntime of this approach could be less than onehour (e.g. the availability of storage technologies likesplit mirror). However, depending on the adopted usecases within BW (e.g. non-standard extractionobjects - Planning Cubes), there may be the need tohave a short, content specific, downtime might be

required for synchronization.Within this approach, the SID and hostname of theBW system on SAP HANA will differ from the existingBW environment, resulting in some effort foradjusting connectivity (SAP GUI, Interfaces, etc.).




Overview – ContinuedFor most of the business BW scenarios the parallel operations on the two productivesystem is feasible. Only some exceptional business processes (e.g. retraction to ECC orCRM) are restricted to run in only one production system.

This system migration approach, from the point of view of hardware, interfaces, andoverall complexity, is higher compared to other alternatives.

SAP recommends to run parallel operations only for a limited time, of approximately 2 - 4weeks. Operating these systems for a longer period of time increases the risk of thesetwo systems falling out of sync with one another for certain inbound activities (e.g. userinput).

SAP recommends to run parallel operations only for a limited time, of approximately 2 - 4

weeks. Operating these systems for a longer period of time increases the risk of thesetwo systems falling out of sync with one another for certain inbound activities (e.g. userinput).

Delta queue cloning is only available for NetWeaver 7.x based source systems.

Special consideration may be needed for fast growing delta queues (e.g. 5 millionrecords/day) during the migration activities, and post migration parallel operations

performance.




RDBMS

D e l t a Q u e u e

( o r i g )

D e l t a

Q u e u e

( o r i g )

D e l t a

Q u e u e

( o r i g )

BW

D e l t a

Q u e u e

( C l o n e )

D e l t a

Q u e u e

( C l o n e )

D e l t a

Q u e u e

( C l o n e )

1. Cloning of delta queue in source systems

4. Classic upgrade of cloned system

7. Process cloned delta queues

3. System copy of BW ABAP system

2. Synchronization of cloned delta queues

5. Migration of data into SAP HANA

B


RDBMS

BW ABAP BW Java

Initial Environment

Interim State

On Temporary HardwareBW 7.00/SEM 6.00

RDBMS

BW 7.31/SEM 7.36

U p g r a d e

SAP HANA

BW ABAP

BW 7.31/SEM 7.36BW 7.00/

SEM 6.00

RDBMS

BW ABAP

BW 7.00/SEM 6.00

BW ABAP

SybaseASE

BW Java

BW 7.31/SEM 7.36

Migration toSAP HANA

SystemCopy

6. New Installation of BI Java (Sybase ASEcan be used)

Parallel Productive

Environment



Migration MethodsOption C: Parallel Implementation / Greenfield Approach 1/3

Overview The upgrade and/or migration of the originalproduction system is not required. This approach onlyrequires a fresh installation of a BW 7.31 on HANAsystem.

Customer BW objects can be transitioned from theold landscape to the new system landscape as ameans of a content migration.

The BW data model can be redesigned, authorizationconcept changes, and other adjustments can bechanged for the new BW system. In-memoryoptimized objects can be used as the default for newobjects.No significant business downtime is required for thesystem, however there maybe certain restrictions tospecific content as it is transitioned to the newinstallation.




Overview – ContinuedIndividual business processes can be enabled as they become available. Initially, thebusiness processes in the new SAP HANA system can run in parallel to the originalscenario. After a predetermined period of time the contents in the former environmentcan be decommissioned.

Usually the new BW system will have a new hostname and SID, which will need to bedistributed to end-users.

The overall project effort is higher than for the other migration methods.

Fallback solution to the original system is very simple, because the old BW system isrunning in parallel for a predetermined period of time.




RDBMS

D e l t a q u e u e

B W 1

BW1

D e l t a q u e u e

B W 2

D e l t a q u e u e

B W 2

C


RDBMS

BW ABAP BI Java

New Installation of BW 7.31 on HANABW 7.00/SEM 6.00

SAP HANA

BW ABAP

BW 7.31/SEM 7.36

BW 7.00/SEM 6.00

SybaseASE

BW Java

BW 7.31/SEM 7.36

Initial Environment

BW2

D e l t a q u e u e

B W 1

Transports and Adjustments

Initial Loads are required



Migration Methods Approach Comparison*

Sample Evaluation

A. Classic B. DowntimeMinimized

C. ParallelImplementation

Business Downtime Potentially Significant Minimal Minimal

Fallback Effort (if required) Long Immediate Minimal

Interim HardwareRequirements

Lowest Highest Moderate

Interface Complexity Moderate Highest Lowest

Support for Testing and

Risk MitigationModerate Easiest Moderate

Certified MigrationSpecialist Required

Yes Yes No

*Note: This is a generic comparison of the three approaches and should be evaluatedagainst the specific requirements of your business.



BW Migration PreparationActivities




BW Migration Preparation ActivitiesSummary of Key Requirements

Requirements for the Migration to SAP HANAData Volume Reduction (optional)

Supported Source Database Platforms

Add-On Restrictions

Dual-Stack Split (if dual-stack source system)

Requirements that can be Included in the Scope of the Migration*

BW on either SAP NetWeaver 7.3 or SAP Enhancement Package 1 forNetWeaver 7.3 (also known as 7.31)

Transition to the new BW authorization concept (Role Based Analysis)

Unicode Converted System

Resource Requirements

Certified and Experienced Migration Specialist Required

*Note: If not already completed.




BW Migration Preparation ActivitiesData Volume Reduction (Optional)

Effectively housekeeping helps to speed up migration processDeletion of PSA, Change log tables, AggregatesClean-up of administration tablesNo database indexes needed

Highly recommended as prerequisite

Example: Customer live project:

SAP HANA compression factor: 5.8*

*Note: Results will vary depending on the specific customer situation and project scope.




BW Migration Preparation ActivitiesData Volume Reduction (Optional) – Customer Example

40% are used for PSA and change log

High potential for reducing DB sizeby data deletion / housekeeping

More Information :https://cookbook.experiencesaphana.com/deploying-bw-on-hana/preparation/system-housekeeping

https://cookbook.experiencesaphana.com/deploying-bw-on-hana/preparation/system-housekeeping













BW Migration Preparation ActivitiesSupported Source Database Platforms

Supported Source DatabasePlatforms

IBM DB2 LUW 9.7

MaxDB 7.8

DB2 for i61, 7.1DB2 for z/OS V9, V19

MS SQL Server 2008

Oracle 11.2

MaxDB 7.8

MaxDB 7.9*SybaseASE 15.7*

*Note: Specific to the migration of SAP NW BW 7.31 systems.

Kernel Requirements

Database-dependent parts: R3load patchlevel(PL): 219

DBSLLIB PL: 219

Database-independent parts: disp+work PL 219

More Information:SAP Note: Note 1600929 - SAP BW powered by SAP HANA DB: Information

RDBMS SAPHANA

https://service.sap.com/sap/support/notes/1600929









BW Migration Preparation Activities Add-On Restrictions

This restriction does not apply to thefollowing:

– In the area of SEM-BW, the component SEM-BCS 6.34 is available as of now and supports

the productive use of SAP NetWeaver BusinessWarehouse 7.3 powered by SAP HANA. Formore details, see SAP Note 1648413.

– The components VIRSANH and GRCPINW ofthe SAP GRC Access Control Solution arereleased.

– The components ST-A/PI and ST-PI are

released. – SBOP PC 10.0 FOR SAP NW is released. Formore details please see SAP Note 1676242 .

– SPM 3.0 is supported on SAP BW 7.30 onHANA. For details please see SAP Note1718152 .

Business Content Add-OnRestriction:

SAP POS Data Management on SAPBusiness Warehouse powered by SAP

HANA – In the BI Content Releases 7.35 and 7.36 on

SAP Business Warehouse powered by SAPHANA (SAP BW 7.3 SP05 and HANA 1.0SP03), there may be restrictions with regard tothe processing, compression, and size of theTLOG data table for users of the POS Inbound

Processing Engine (PIPE) as the centralcomponent of SAP POS Data Management. – For more information, see Note 1648861 - SAP

POS DM on SAP Business Warehouse poweredby SAP HANA .

“Fornow, all products and components of the SAP Business Suite are notreleased for BW 7.30 SP5 (and higher) powered by SAP HANA DB .”

More Information:

SAP Note: Note 1600929 - SAP BW powered by SAP HANA DB: Information
























BW Migration Preparation ActivitiesDual-Stack Split

SAP Business Suite 7i2011 will be the last SAP Business Suite release with Dual-Stacksupport.

Only in a very few cases is Dual-Stack still required (SAP Solution Manager & SAPNetWeaver Process Integration).

Dual-stacks are not supported for SAP NetWeaver BW on SAP HANA, therefore the Javastack must be separated from the ABAP stack. Currently SAP HANA does not support theJava-only stack for the SAP NetWeaver Data Warehousing (aka BW) use case.

The dual-stack split tool can be used to transition the Java stack either into a MCODscenario or onto a separate database.

SAP recommends you to move away from Dual-Stack systems wherever possible.

SAP NetWeaver BW Supported Scenarios

The dual-stack split tool can be used for dual-stack SAPNetWeaver BW systems on the following releases:

SAP NetWeaver 7.0 SP14 or higher

SAP NetWeaver 7.0 including Enhancement Package 1






BW Migration Preparation ActivitiesDual-Stack Split – Process Flow Keep DB (High-Level Overview)

ABAP

Step 1

Export Source SystemExport source JavasystemFile System: SDM,

KernelDisable Java instance onthe source system.

Step 4

Remove Java Add-Infrom Dual Stack System

Remove SCS Instance

Adjust profile parameter

Restart instance service

Cleanup of J2EEdirectory

Step 3

Reconfigure SystemConnectivity

Reconfigure SLD

Reconfigure BW

Step 2

Install Target JavaSystem

Install target Javasystem

Rename Java DBSchema

Reconfigure UME

Export

I n s t a l l

JavaJava




BW Migration Preparation ActivitiesDual-Stack Split – Process Flow Move DB (High-Level Overview)

Java

ABAP

Step 1

Export Source SystemExport source JavasystemFile System: SDM,

KernelDB: Java Schema

Disable Java instance onthe source system.

Step 4

Remove Java Add-Infrom Dual Stack System

Remove SCS Instance

Adjust profile parameter

Restart instance service

Cleanup of J2EEdirectory

Drop Java schema

Step 3

Reconfigure SystemConnectivity

Reconfigure SLD

Reconfigure BW

Step 2

Install Target JavaSystem

Install target Javasystem

Reconfigure UME

Export

InstallJavaJava




BW Migration Preparation ActivitiesSAP NetWeaver 7.3 or SAP Enhancement Package 1 for NetWeaver 7.3

Required Software ReleaseSAP NetWeaver 7.3 or SAP EnhancementPackage 1 for NetWeaver 7.3 (recommended)is required for the migration of BW to SAPHANA.

Recommended Support Package Stack

• NetWeaver 7.3 – SPS 07 or higher

• NetWeaver 7.31 – SPS 04 or higher

More Information:

SAP Note: Note 1600929 - SAP BW powered by SAP HANA DB: Information

RECOMMENDATION: If an upgrade isnecessary based on the current software levels,it is highly recommended to bundle the upgradeand migration into a single software changemanagement release or project.










BW Migration Preparation ActivitiesSAP NetWeaver 7.3 or SAP Enhancement Package 1 for NetWeaver 7.3

Additional Upgrade Related Technology Facts and UpdatesThe transition from the 3.x role based authorization concept to the analysis authorizationconcept introduced with NW 7.0 is currently required. The authorization migration is possiblebefore or after the NW 7.3 upgrade. This is independent from the migration of the BWsystem to SAP HANA.The Java component BW Integrated Planner (BW-IP) modeler is redeveloped for BW 7.3x in

ABAP HTTP, so the Java Server will no longer be used for the BW-IP infrastructure in thefuture.What is the difference between SAP NetWeaver 7.0 EhP3 and SAP NetWeaver 7.3 EhP1?

SAP NetWeaver 7.0 EhP3Dual Stack*

AS ABAP

7.31

AS Java

7.0 EhP2

SAP NetWeaver 7.3 EhP1Dual Stack*

AS ABAP

7.31

AS Java

7.3 EhP1

*Note: The example of a dual-stack is for demonstration of the difference in the two versions, it is not a

recommended configuration for the NetWeaver Date Warehousing (aka BW) use case.




BW Migration Preparation Activities Authorization Concept Transition – Role Based to Analysis

In BW 3.x the authorization concept was role based, with NetWeaver 7.0 SAP introduceda new analysis authorization concept for BW.

With NetWeaver 7.3, SAP further refined the analysis authorization concept.

If upgrading to 7.31 it is mandatory to migrate from the 3.x concept to the 7.3 concept.SAP no longer supports the old reporting authorization concept and it is highly recommended tomigrate as soon as possible to the new concept.

A pilot note is being developed to support the use of the 3.x authorization concept only for NW 7.30.Not all functionality within 7.3x will be supported with the old 3.x authorization concept

SAP no longer supports the old reporting authorization concept and it is highlyrecommended to migrate as soon as possible to the new concept.

More Information:http://help.sap.com/saphelp_nw73/helpdata/en/45/5ae49cee142a50e10000000a11466f/frameset.htm

http://help.sap.com/saphelp_nw73/helpdata/en/45/5ae49cee142a50e10000000a11466f/frameset.htm

http://help.sap.com/saphelp_nw73/helpdata/en/45/5ae49cee142a50e10000000a11466f/frameset.htm




BW Migration Preparation ActivitiesUnicode Conversion

Unicode and NetWeaver 7.3x BW on SAP HANASAP NetWeaver BW running on SAP HANA is required to be a Unicode enabled system. Ifthe existing SAP NetWeaver BW system has yet to be converted, it is recommended toperform the conversion during the database migration.The Combined Upgrade & Unicode Conversion (CU&UC) can be used with the followingscenarios:

– BI 7.0 (based on NW 7.0 or 7.01) from source releases BW 3.x – BW 7.30 from source releases BI 6.40, BI 7.0

All custom objects must be Unicode-enabled prior to the Unicode conversion.

More Information: SAP Note: 1051576 - Conversion of Single Code Page Systems to Unicode SAP Note: 928729 - Combined Upgrade & Unicode Conversion (CU&UC)

Non -Unicode Unicode

RECOMMENDATION: If an upgrade andUnicode conversion are necessary based onthe current state of the system, it is highlyrecommended to bundle all three activities intoa single software change management releaseor project.














BW Migration Preparation ActivitiesInterface Dependency Analysis

OverviewInterfaces is an area of concern for a BW on SAP HANA migration for several reasons:

– In the case of a single code page system, the system needs to undergo a Unicode conversion as a partof the migration process. Standard RFC interfaces can be enabled for Unicode by adjusting theparameter settings for the RFC connections in SM59. However other interfaces, especially those from3rd party vendors might need to be adjusted differently.

– If selecting the downtime minimized / cloned delta extractor migration approach it is important toinventory and analyze all interfaces:

o Inbound: Interfaces that write into BW in addition to the standard BW source systems.

o Outbound: Those interfaces that read from BW and persisting data outside of BW. It is especiallycritical to evaluate those interfaces where the data transfer is triggered from BW (e.g. Retractor).




BW Migration Preparation ActivitiesInterface Dependency Analysis – Outbound (Reporting)

1. Overall DependenciesFollowing the BW migration to SAP HANA, the new productive BW system could have a new SID and/orhostname. All outbound interfaces need to be inventoried during the project and adjusted accordinglyduring the migration process.

When a Unicode conversion is included in the scope of the migration project, it is important to test allinterfaces, using the various installed languages (if applicable), to validate that the connection is workingas intended.

SAP Business Suite

CRM SCM …

Other Outbound Channels

FlatFile …

Non-SAPDataWarehouses

SAP Frontend Tools

BEx Analyzer

BExWeb … BI 4.0

RFC RFC RFC HTTP RFC/HTTP

SAP Business Warehouse

BOBJ Universe(MDXData Mart Business Information

Consumer Services (BICS) Open Hub

RFC/HTTP

1

42 3 5




BW Migration Preparation ActivitiesInterface Dependency Analysis – Outbound (Reporting)

2. Retractions back to ECCWhen using the downtime minimized migration approach, with delta queue cloning and paralleloperations, only one “production” system can be configured to write data back to ECC. Therefore whensetting up such a parallel environment, it is necessary to switch off retraction in one of the two productionsystems, in order to avoid duplicate data in ECC. Typically at the beginning of the parallel operationsphase the old BW is chosen for the retraction. The retraction functionality is typically transitioned to thenew BW on SAP HANA system one week after the start of parallel operations. At which point theretraction processes in the process chains are disabled in the old BW system and enabled in the newly

migrated BW on SAP HANA.3. Data Exchange with SCM

In the case of SCM integrated scenarios with BW (e.g. forecast planning, extended warehousemanagement…), it is important to restrict data from being sent twice to SCM, when using the delta queuecloning and parallel operations migration approach.

4. FPN Dependencies Generally it is recommended to have producer and consumer portals on the same version. HavingConsumer Portal on a lower release compared to the Producer Portal could lead to problems andincompatibilities.

5. Non-SAP Data Warehouse(s) / Other DatabasesWhen selecting the approach to operate parallel BW systems, the transition of outbound interfaces toother data warehouse systems or databases needs to be carefully managed to ensure data is not beingduplicated in the receiving system(s). There are no means to manage data consistency to the targetenvironment when executing such an interface in parallel productive BW systems.




BW Migration Preparation ActivitiesInterface Dependency Analysis – Inbound (Extraction)

1. Overall DependenciesFollowing the BW migration to SAP HANA, the new productive BW system could have a new SID and/orhostname. All inbound interfaces need to be inventoried during the project and adjusted accordinglyduring the migration process.

When a Unicode conversion is included in the scope of the migration project, it is important to test allinterfaces, using the various installed languages (if applicable), to validate that the connection is workingas intended.

DIAGRFC/HTTP

SAP Business Warehouse

Open Hub

SAP Business Suite

ECC SCM …

Other Inbound Channels

FlatFile …

Direct UserInput

SAP Frontend Tools

IP BPC … BPS

BOBJ Universe(MDX

Data Mart Business InformationConsumer Services (BICS)

RFC RFC2

43

1

RFC RFC RFC




BW Migration Preparation ActivitiesInterface Dependency Analysis – Inbound (Extraction)

2. Planning activities via SEM-BPS or BW-IPBesides the standard BW source systems, inbound data to BW could also happen via SEM BusinessPlanning and Simulation (SEM-BPS) or BW Integrated Planning (BW-IP) using real-time InfoProviders. Inthe case of operating parallel BW systems, newly uploaded data by SEM-BPS or BW-IP must bemanually synchronized between the two production systems. This can be achieved by capturing the newplanning data in new, separate requests. These request can be transferred periodically between the twoBW production systems via the Data Mart interface. Automatic compression of closed request must beswitched off during the parallel operations phase.

3. Data Exchange with SCMIn some business processes SCM transfers data to BW via SCM specific function modules (push method)or SCM is configured to directly plan on Remote Cubes in BW. In this case the SCM interface is able tochange or insert data within BW. In the case of operating parallel productive BW systems, such aninterface cannot leverage the delta queue cloning. To address this, manually changed or inserted data inthe one BW production system must be separately synchronized with the second production system (e.g.via Data Mart).

4. Manual Input via Z-TransactionsIf users are able to change or input specific master data directly in the BW production system (e.g.hierarchies), these changes must be separately synchronized in the second production system, if theparallel production approach is selected.



Post Migration StepsOptimiz ing B W for SAP HANA




Post Migration StepsOptimization Techniques for SAP NetWeaver BW on SAP HANA

Optional Post Migration Optimization TechniquesIn addition to the traditional post migration activities of a BW system, there aresome optional steps that can be performed to further leverage the capabilities ofSAP HANA.

Following the migration to SAP HANA, the DSOs and InfoCubes remain as they were priorto the migration. However there is an option to optimize both of these object types for use

on a SAP HANA database. – Only InfoCubes of type Standard can be converted to SAP HANA-optimized InfoCubes. – Only DataStore Objects of type Standard can be converted to SAP HANA-optimized DataStores. – Standard DSOs are converted to SAP HANA-optimized DSOs only if the DSO is not part of a

HybridProvider or a Semantically-partitioned Object (SPO). – DataStore Objects with 3.x DataFlows can be converted only if the outbound dataflow is on SAP

NetWeaver BW 7.x technology. The inbound dataflow can be on 3.x or 7.x technology.

Further optimization can be achieved by evaluatingand remodeling classical DataFlows, at a laterpoint in time and based on the needs of thebusiness.

RDBMS SAPHANAMore Information:

SAP Note: 1665322 - Conversion for SAP HANA-optimized DataStore objects














Post Migration StepsIn-Memory Optimization

SAPBusinessObjects

4.0

ECC,SCM

BWSAP Extractors

Relational DB(ORCL, IBM, MSFT, SAP MaxDB)

BW Accelerat

or

HANA

Load OperationsDSO activation is much faster

Rollup, index deletion/creation are obsolete

OLAP Operations e.g. Top n

Planning Operations Disaggregations

Moving data intensiveoperations down to HANA

All existingcontent and

otherinvestments

are fullycompatible and

secured

BEx Reporting(Web/Excel)

(3.x/7.x)




Post Migration StepsSAP HANA-Optimized InfoCube – Architecture Overview

Facts

D

D

MD MD

MD

MD

F

E

Facts

MD

MD

MD

MD

F

Physical schema of BWInfoCubes tailored towardstraditional RDBMS

Conversion orNew*

* Activation from BI content alsocreates HANA-optimized InfoCube

More Information: https://www.experiencesaphana.com/docs/DOC-1363

In-Memory Optimized InfoCubestailored to HANA represent “flat”structures without Dimension / E tables

https://www.experiencesaphana.com/docs/DOC-1363







Post Migration StepsSAP HANA-Optimized InfoCube – Conversion

Transaction: RSMIGRHANADB ( program RSDRI_CONVERT_CUBE_TO_INMEMORY )

or from InfoCube maintenance:

Although the time required for the conversion process is minimal, it is recommended to convert the top10 largest InfoCubes as a part of the migration project.

After conversion InfoCubes work w/o disruption regarding data staging and querying (DB Changes aretransparent to the application).Conversion is executed as a Stored Procedure within HANA and therefore shows excellentperformance.Compression is not required for query performance but for large cubes it is recommended for loadperformance.

Conversion PerformanceLab result: 250 Million records in 4 minThe exact runtime depends onthe distribution of the data,number of fields, especially characteristics,and the hardware of the HANA appliance




Post Migration StepsSAP HANA-Optimized DataStore Object – Architecture Overview

Classical Architecture HANA-Optimized DataStore Object

Conversion

ChallengesData Activation RuntimeReporting Performance Secondary indexes SID handling




Post Migration StepsFurther Optimization - Reduction of Persistent Layers

InfoCubes required for:Non-disruptive approach whenmigrating to BW on HANANon-cumulative Key FiguresComplex business logic

(report specific)BW Integrated PlanningExternal write-interface(RSDRI)

Conclusion

There are scenarios where the InfoCube layer becomes obsolete – Less materialized data and simplification

Decision to be made scenario by scenario: Based on business and performance needs

More Information:https://cookbook.experiencesaphana.com/deploying-bw-on-hana/post-installation/conversion-of-standard-infocubes-and-dsos/

https://cookbook.experiencesaphana.com/deploying-bw-on-hana/post-installation/conversion-of-standard-infocubes-and-dsos/
























Boundary Conditions toConsider




Boundary Conditions to ConsiderCommonly Considered Questions

Business FocusedWhat are the most critical periods of time for system availability?

– Monthly, Quarterly, and Annual period end close activities – Seasonal peaks / Product Release Cycles

What is the longest acceptable business downtime window for a planned change event?

What business-driven projects are planned in (or around) the migration project?Is there a predefined maintenance calendar established with the business?Which business requirements need to be In-Memory optimized first?

Technically FocusedWhat other infrastructure changes are planned in (or around) the migration project?

– Datacenter, Network, Server and/or Storage – Operating System Patching, Upgrade, and/or Migration – Virtualization, High Availability, and/or Disaster Recovery

What other changes are planned for the overall SAP solution landscape? – Instance mergers or splits, new systems to be introduced, systems to be decommissioned – Proactive Software Maintenance (e.g. Support Package Stacks, Enhancement Packages, Upgrades)




Boundary Conditions to ConsiderBusiness Downtime Requirements – Options for Downtime Optimization

SAP R3load – Sequential Migration

Near Zero Downtime*

SAP Migration Monitor – Parallel Migration

SAP Distribution Monitor - Parallel Migration

*Not applicable for all SAP Products.



Additional Considerations




Migration to a SAP Database PlatformHolistic Approach Based on Proven Best Practices

One end-to-end methodology – implemented in SAP Solution Manager

Migration TasksArchitectureInfrastructure

OperationalReadiness

PerformanceScalability

ProjectManagement

Project Management Define, drive and control milestones and Q-gates

Architecture & Infrastructure Define the infrastructure and landscape architecture tofulfill requirements of the migration as well as theoperation after Go-Live

Migration Tasks Ensure that migration tasks are executed along aproven plan and approach and based on best practicesfor procedures and configurations

Performance & Scalability Ensure performance, throughput, scalability, availability.

Define the technical architecture and infrastructureOperational Readiness Ensure that procedures, tools and skills are adequateto run the new solution safely and efficiently



Thank you

Contact information:

F name MI. L nameTitle

AddressPhone number

migration to hana part 2

Documents