SAP HANA

Lesson learned on production implementations

November 2014

Introduction

Why HANA?

Sizing

Lessons learned from customer

case-study

Wrap-up

Questions

CRM

ECC

BWCOMPUTERS

TABLETS

SMART PHONES

HANAA

SAP HANA PlatformROWS COLUMNS

CONSUMERS

(ODATA,HTML5…)

XS ENGINE

BO TOOLS

VIEWS

Why customers choose HANA

SIZING

SAP produced clear method for sizing SAP HANA based environments:

• decision tree,

• SAP Notes,

• scripts,

• formulas ,

• Hana Quicksizer tool.

This still raises some questions:

• any pitfalls?

• what is really sized?

• are optimized objects from the SAP BW application taken into account?

• what are the results?

The path to the box

S

I

Z

I

N

G

B

A

S

I

S

Initial Migration

X = n

Y = mZ = µ

Quick

Sizer

Result

Sizing

Report

Since sept 2014

SIZING

Sizing tools - results & remarks

SAPS TOT RAM TOT SAPS DB RAM DB SAPS AS RAM AS DBSIZE

HANA 5 ans 330 000 35 694 592 75 000 35 221 504 250 000 474 112 28 646

HANA 2 ans 330 000 35 567 616 75 000 35 095 562 250 000 473 088 28 561

NON HANA 280 000 527 360 25 000 53 248 250 000 474 112 57 267

SAPS TOT RAM TOT SAPS DB RAM DB SAPS AS RAM AS DBSIZE

HANA 5 ans 29 000 47 608 832 5 800 47 546 368 23 000 62 464 38 677

HANA 2 ans 29 000 19 030 016 5 800 18 968 576 23 000 61 440 15 437

NON HANA 25 000 68 608 2 000 6 144 23 000 62 464 77 328

User based sizing (50 000 High activity users)

Throughput sizing (Year: 100 Mio Obj. @ 100 items / Peak 1 hour: 100 KObj. @ 100 items)ECC FI

ECC FI

(Unités RAM: MB / DBSIZE: GB)

SAPS TOT RAM TOT SAPS DB RAM DB SAPS AS RAM AS DBSIZE

HANA 98 000 4 210 688 N/A 4 034 560 98 000 177 152 4 022

Non Hana 160 000 221 184 31 000 44 032 130 000 178 176 23 966

Initial sizing w/o planning functionsBW

• AS sizing result is the same for both Quicksizers

• => Hana-optimized transactions not taken to account

• Data retention time has a huge impact on the RAM sizing result

Qu

icks

izer

Scri

pts

• A couple of remarks:• A lot of updates (plenty of versions producing different results)• First sizing results were incorrect• => The results have to be “reworked” to allow margin of error.

SIZING

Application server sizing

Scenario:• Wall at 30 m• 3 balls• 1 x 54 years old player• Health: OK

Migration to HANA

withDB time / 3

Scenario:• Wall at 10 m• 3 balls• 1 x 54 years old player• Heart attack

CPU’ssaturated

=> SAP stuck

Hardware options: beef up application servers:• Add CPUs (Several 54 years old players)• Change CPU technology (replace with one 18 year old player)

! The only available option for user activity!

Customize: limit activity :• Decrease batch parallelization. Ex:

• Variant configuration• Settings in OMIQ (MRP)

• Limit the RFCs• 7.3x tune rfc_min_wait_dia_wp• 7.4x tune rdisp/scheduler/*/max_quota

Remark: No matter who is pushing the wall…. The problem is the same with Exadata..

SIZING

Application server sizing

AS DB

Processing time :• Total elapse : 1:00 • AS Time: 50%• DB Time: 50% • Think time: 0% !

Three users begin to enter 100 billing

documents at 10:26

Scenario:

1000 SAPS

1000 SAPS AS in 1 hour

Migration to HANA

withDB Time / 3

Three users (now powered by HANA)

begin to enter 100 billing documents at

10:26

Scenario:

Processing time :• Total elapse : 00:40• AS Time: 75%• DB Time: 25% • Think time: 0% !

1000 SAPS

1000 SAPS AS in 40 minutes

SIZING

Customer caseCUSTOMER CASE

– Business

• Sporting goods retail chains

• Sporting goods manufacturing

• Present in 21 countries

• 360 stores

• Turnover: $9.38 billion

– SAP Landscapes

• Retail: 2 ECC + 1 BW

• HR: 1 ECC + 1 BW

BW landscape

CUSTOMER CASE

– Usage

• Retail reporting on BEx

• Users : 3,000 Named / 1,500 Connected every Monday morning

OS DB MIGRATION

UPGRADE

+

SOU

RC

E

TAR

GET

6 Tb 1.2 Tb

BW landscape

CUSTOMER CASE

– Landscape configuration

• Production on dedicated box (scale out)

• DR, Quality and Development on secondary site

Production DR

QA

DEV

SECONDARY SITEPRIMARY SITE

STORAGE REPLICATION (GPFS)

– Implementation planning

BW landscape

CUSTOMER CASE

Kick OffDevelopment

MigrationFunctional

ProjectProduction Migration

User Acceptance

Production (new)

HA

NA

Q3 2013Q2 2013Q1 2013 Q4 2013 Q1 2014 Q2 2014

Production

OR

AC

LE

Dual Run

Licenses acquisition

Switch to new HANA Production

ECC landscape

CUSTOMER CASE

– Usage

• Module : Retail

• Users : 1,600 named / 1,000 connected each month

• Activity : 270 million SAP steps / month

OS DB MIGRATION

UPGRADE

+

SOU

RC

E

TAR

GET

5 .7 Tb 1.2 Tb

SLO for Production

ECC Landscape

CUSTOMER CASE

– Landscape configuration

SECONDARY SITEPRIMARY SITE

DEV

Production

Production

DEV

DEV

DEV

DEV

DEV

QA

QA

QA

QA

QA

QA

DR

DEV

DEV

QA

QA

QA

Pre-

Prod

HANA REPLICATION

DRPre-

Prod

– Implementation planning

ECC Landscape

CUSTOMER CASE

KickOff Landscape

Upgrade

Functional Project User Acceptance

Production (new)

HA

NA

Q3 2013Q2 2013 Q4 2013 Q1 2014 Q2 2014

Production

OR

AC

LE

24 hours downtime

Switch to new HANA Production

Q3 2014

Technical Acceptance

Stress test

Downtime:24 Hours

– Incidents, disruption and downtime

week week week week week week week week week week week

Post Go Live

CUSTOMER CASE

13 14 15 16 17 18 19 20 21 22 23GO LIVE

Inci

den

ts

Disruption:49 Hours

– Root cause breakdown

Post Go Live

CUSTOMER CASE

HANA Error

Human Error

Custom Queries

Hardware

ECC & 3rd Party

– Root cause breakdown

Post Go Live

CUSTOMER CASE

Custom Queries

Complex selection criteria

Symptom: high CPU consumption

Impact: system unavailable

Solution: limit usable CPU per query

Across large tables

Symptom: high memory consumption

Impact: memory overflow / database crash

Solution: limit usable memory (SP8)

Extensive testing is highly recommended beforethe Go Live to define relevant CPU and memorylimits.

– Root cause breakdown

Post Go Live

CUSTOMER CASE

AS/DB SAPS ratio changes

Symptom: high CPU Usage on ECC

Solution: increase available SAPS on the

Application side

Schedulers

Symptom: workload increased

Impact: application less stable

Solution: increase resources for the scheduler

With HANA there’s no database bottleneck Allconnected systems must interact faster Thewhole HANA ecosystem must be stress-tested.

ECC & 3rd Party

– Root cause breakdown

Post Go Live

CUSTOMER CASE

Hardware stability

Symptom: hardware failures, firmware and

driver issues

HANA has a low tolerance for hardware latencyand hardware failures.Every firmware, driver and OS patch must bevalidated through OSS support.

Hardware

SUPPORT PORTAL

– SAP: single point of contact

Communication channel

COMMUNICATION

ABAP

HARDWARE

O.S

HANA

Technical Layers Support Centers

Application Support

HANASupport

– Root cause breakdown

Post Go Live

CUSTOMER CASE

HANA errors / stability

Hana is still a young product but SAP is

improving it continuously:

SP6: Q1 2013 - 16 revisions

SP7: Q3 2013 - 8 revisions

SP8 : Q2 2014 - 3 revisions

Hana revisions are delivered every 2 or 3 months by SAP.It is recommended to perform 2 updates per year.

HANA Error

– Support pack update

REVISION

Update strategy

RECOMENDATIONS

SP 7

SP 8

REV 70 REV 71 REV 72 REV 73 REV 74

REV 80 REV 81 … REV 8x

REV 74.01 … REV 74.0x

DSP(Datacenter Service Point)

Support: 3 months

REVISION MAINTENANCE REVISION

– Support pack update

REVISION

Update strategy

RECOMENDATIONS

SP 7

SP 8

REV 70 REV 71 REV 72 REV 73 REV 74

REV 80 REV 81 … REV 8x

REV 74.01 … REV 74.0x

DSP(Datacenter Service Point)

Support: 3 months

REVISION MAINTENANCE REVISION

– BW performance comparisons

HANA performance

PERFORMANCES

PERFORMANCE RATIO MINIMUM MAXIMUM AVERAGE

Non-Optimized DATA LOADS 0.33 13 1.06

OPTIMIZED DATA LOADS 1.28 44 3.3

QUERIES 1 31 2.3

– Custom programs

• re-write queries

• re-engineer code

– BW: to optimize fully

• transfer rules must be converted from 3.x to 7.x (DTP)

• info-cubes must be converted to a “Hana Optimized" mode

• transformation finder: detect info-providers with duplicated data

• routine analyzer: look for optimization point in routine code and other process-

chain steps

– Table partitioning

• list the most demanding queries on biggest tables

• adapt partitioning keys regarding the queries

Functional work

PERFORMANCES

Goal: transfer the workload from

the ABAP stack to the Database

– Notes on sizing

• 1514966 - SAP HANA 1.0: Sizing SAP In-Memory Database

• 1872170 - Suite on HANA memory sizing report

• 1736976 - Sizing Report for BW on HANA

– Notes on table partitioning

• 2012533 – Not yet released

– Upgrade and maintenance strategy

• 2021789 - SAP HANA Revision and Maintenance Strategy

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

• 1892593 - Preparing Support Services for SAP HANA Scenarios

• 1948334 - SAP HANA Database Update Paths for Maintenance Revisions

Wrap-up and additional information

WRAP-UP

Thank you for your participation!Any questions?