The SAP® BW to

HANA Migration

Handbook

Rob Frye Joe Darlak

Dr. Bjarne Berg

TABLE OF CONTENTS

5

Table of Contents

Preface 7

1 Introduction to DMO 9

1.1 Strategies for migrating to SAP HANA 10

1.2 Bringing it all together with DMO 18

1.3 Navigating this book 19

1.4 Reading the book 22

2 Planning the migration 23

2.1 Business case 23

2.2 Staffing 31

2.3 Sizing the migration 34

2.4 Budgeting 41

2.5 Program milestones 44

3 Hardware, optimization, and SAP

BusinessObjects integration 55

3.1 Hardware 55

3.2 Optimization 59

3.3 What is BI self-service? 65

3.4 BusinessObjects integration, mobilization, and connection 66

4 BW cleanup 79

4.1 The BW cleanup 12 step-program 80

4.2 Minimizing database size 87

4.3 Housekeeping made easy 87

4.4 Before upgrade task list 89

TABLE OF CONTENTS

6

5 Prerequisites for DMO 93

5.1 Required BW version and service packs 93

5.2 General prerequisites 94

5.3 Unicode conversion 104

5.4 Security conversion 124

5.5 BEx WAD templates 126

5.6 BW on HANA migration checklist 128

6 The DMO migration 129

6.1 Step-by-step instructions 129

6.2 Post-migration tasks 158

6.3 Sample DMO task list 164

7 HANA performance monitoring 225

7.1 Performance monitoring in HANA Studio 225

7.2 Performance monitoring in SAP BW 229

7.3 Performance monitoring dashboard 237

8 Summary 245

8.1 Things to remember 246

8.2 Farewell and good luck! 248

A About The Authors 250

B Index 253

C Disclaimer 257

23

2 Planning the migration

In the introduction, we discussed the benefits of the

DMO process over other options for migrating to SAP

HANA. In this chapter, you will learn more about the

business case for migrating to SAP HANA, as well as

the items that you must consider when planning for

the DMO approach.

In Chapter 1, we examined the history of data migrations

and began to build the case for choosing the DMO op-

tion for your company’s migration from BW to HANA. In

this chapter, we will look at several benefits you can use

in building your business case for SAP HANA. We will

also look at some sample staffing plans, hardware sizing

and planning examples, budgeting, and milestones. This

information is provided as a baseline to assist you in

planning for your company’s DMO process.

2.1 Business case

There are several reasons for migrating your SAP BW

system to SAP HANA. The most important reasons are

those that provide the greatest advantage to your busi-

ness. The reasons that provide the most impact include:

Superior performance with a smaller database

footprint

More agile development and simpler mainte-

nance

Landscape simplification and real-time reporting

PLANNING THE MIGRATION

24

These benefits drive a lower total cost of ownership

(TCO), and they can be achieved by migrating without

reimplementation or disruption to your existing land-

scape or reporting scenarios. Keep reading to take a

closer look at the reasons for choosing SAP HANA.

2.1.1 Superior performance with a smaller database footprint

Just by migrating your existing system to SAP HANA you

will achieve superior data loading and query perfor-

mance. On average, BW queries are at least nine times

faster compared to the same queries in an SAP BW

system not running on HANA.

SAP HANA is fast

Based on data gathered from our pro-

jects to date, SAP HANA executes que-

ries 9-23 times faster (16 times on aver-

age) than other databases. So the mini-

mum expected performance improvement is around

nine times faster for queries in HANA.

The increased speed of data access from external tools

is also improved. For example, a database with 1.2 bil-

lion rows of data returned aggregated results in BO Ex-

plorer in around 4.5 seconds. One study published by

SAP found that Web Intelligence reports loaded approx-

imately 12 times faster.

It can be difficult to quantify this speed improvement in

terms of financial savings. Let’s look at a simple exam-

ple.

PLANNING THE MIGRATION

25

SAP product availability matrix

For a complete list of version require-

ments for SAP BW on HANA, check the

SAP product availability matrix (PAM) for

each tool to ensure connectivity for exist-

ing data sources. http://scn.sap.com/DOC-8693

Let’s assume that there are 2,000 query executions per

day and the average time is 20 seconds in the legacy

database. The total time spent waiting for query results is

over 11.1 hours per day. With SAP HANA, the wait time

is 1.2 hours per day, which is a saving of 9.9 hours per

day, or 2,376 hours per year!

Even data loads into traditional InfoCubes and DSOs are

around twice as fast (at least) as loading data into a

traditional BW system. This means you can load data

twice as many times per day as you did before migrating

to SAP HANA and still have more spare time in your load

window!

The database size for BW on HANA is significantly

smaller than the size required in traditional BW and BWA

systems. The speed of the in-memory SAP HANA calcu-

lation engine allows super-fast aggregation of data and

faster access to raw data, so there is no need to pre-

calculate aggregates or invest in obsolete hardware for

the BW Accelerator (BWA). SAP HANA is also a colum-

nar database which allows for significant compression

compared to relational databases. Generally, a com-

pression factor of 3-5 times is expected for most tables

compared to Oracle, for example. The speed of the SAP

HANA database also eliminates the need to build In-

foCubes in SAP BW and hence, eliminates additional

data. This allows your company to spend less on licens-

PLANNING THE MIGRATION

26

ing and lowers the total cost of owning an SAP BW on

HANA system.

SAP HANA licensing

SAP HANA licensing is paid only on the

production database, which saves costs

if you have many non-production sys-

tems in your landscape.

2.1.2 More agile development and simpler maintenance

Before SAP HANA, SAP BW systems relied on the Lay-

ered Scalable Architecture (LSA) to provide acceptable

performance for data loading and query executions. LSA

defined best practices for moving data through several

staging or persisted data warehouse layers before mak-

ing the data available for reporting in the enterprise data

warehouse (EDW). See Figure 2.1 for an example of

LSA in a traditional BW system.

LSA is a robust and valuable design, but it can be ex-

pensive to design, implement, and maintain, both from a

development perspective and from a database volume

perspective. In addition, the fact that there are multiple

data staging layers introduces latency in moving data

from the acquisition layer to the report and visualization

layers, thus delaying consumption of data by end users.

With SAP BW 7.4 on HANA, the LSA architecture is re-

placed with LSA++. Recommended for SAP HANA only,

LSA++ is an updated design and architecture standard

which can be used to simplify your EDW architecture.

See Figure 2.2 for an example of the LSA++ architec-

ture.

PLANNING THE MIGRATION

27

Figure 2.1: LSA example

Figure 2.2: LSA++ example

INDEX

253

B Index

A ADR tables 114

ASCS 146

ASU Toolbox 140, 148

B BDCP table 106

BEx WAD templates 126

BI housekeeping 139

BI self-service 65

BOBJ 68

Analysis 72

BusinessObjects

Explorer 72

Crystal Reports 74

Dashboards 68

Design Studio 75

Lumira 76

Web Intelligence 70

Budgeting 41

Continued support 43

Training 42

Business case 23

BusinessObjects 66

BW 7.4 authorization

objects

RSHAAP 126

RSHAOT 126

S_RS_HCPR 126

S_RS_ODSP_H ODP

126

S_RS_ODSV 126

BW cleanup 80

C CLUR4 105

D Database backup 145

DBACOCKPIT 157

DBTABLOG 113

DD_NAMETAB_DELETE

123

DD_SHOW_NAMETAB

123

DTP objects 83

E Environment planning

Development

environment 49

Production

environment 52

QA environment 50

G Greenfield 10

INDEX

254

H HANA DB backup 155

Hardware 55

Scale out 57

Scale up 56

I ICNV 101

L Layered Scalable

Architecture 26

LSA 26

LSA++ 26, 64

M Matchcode IDs 108

Migration checklist 128

MIGTIME analysis 151

Milestone plan 45

N Near-line storage 85

NLS 85

O Offline DB backup 148

Open transports 141

Optimization 59

ABAP 64

Data flow 64

InfoCube 65

InfoCubes 60

P Performance monitoring

Dashboard 237

DBACOCKPIT 229

HANA Studio 225

Planning

Onboarding and setup

46

Post-migration 158

Prerequisites 93

Primary application server

156

Q QCM tables 115

R RADNTLANG 116

RDA daemons 148

RSBATCHDATA 85

RSCP0126 105

RSCPINST 110

RSEC_MIGRATION 126

S SAP Host Agent 131

SAP kernel update 101

SAP NetWeaver BW

Migration Cockpit 38

SAP_BW_BEFORE_UPG

RADE task list 89

SAP_BW_HOUSEKEEPI

NG task list 88

SAP_DROP_TMPTABLE

S 114

INDEX

255

SDBI_CLUSTER_CHECK

106

SE16 108

SE38 105, 110

Security conversion 124

Sizing 34

Rule-of-thumb sizing

36

SAP BW on HANA

automated sizing

tool 38

T-shirt sizing model 35

SMLT 108

SNOTE 100

SPAM 102

SPAU 100

SPDD 100

SPUMG 115, 117

Staffing 31

Large & very large

projects 33

Medium projects 32

Small projects 31

Statistical cube data 81

Step-by-step instructions

129

SUM for DMO 132

Support Package

Manager 102

T Task list 164

Access management

167

Cutover 224

Delta queue cloning

180

Export preparation 195

Hardware provisioning

165

Homogenous database

copy 181

Housekeeping 189

PCA installation 174

PCA preparation 176

Post-copy 183

Post-migration 216

Source BW preparation

168

Unicode preparations

171

Upgrade preparation

202

Upgrade with DMO

208

TBATG 101

TCP0I 108

TCPDB 108

TERM_DELETE_INCOR

RECT_CHARSET 111

Time Analyzer 151

Transaction remote

function call 85

tRFC 85

TWTOOL01 109

U UCCHECK 105

UMG_ADD_DOWNTIME_

STEP 123

INDEX

256

UMG_SHOW_UCTABS

123

Unicode 117

Nametabs 122

Unicode conversion 104

V VER_CLUSTR 105

W Write-optimized DSOs 84