Agfa says “Yes” to HANA - SAP Eventssapevents.be/cubis/presentations/20160202_BW on... · Agfa...

Agfa says “Yes” to HANA :

The PoC and the 1st migration to HANA in 4 months

Eric Van Kerckhoven – BI Project Manager @ Agfa

Gunther Van Eyck – BI Consultant @ Cubis

Gianluca Liberato – BI Consultant @ Cubis

ContactCubisLeuvensesteenweg 613 1930 Zaventem

T: +32 (0)2 751 77 97F: +32 (0)2 757 90 61

www.cubis.beinfo@cubis.be

@cubissolutionswww.facebook.com/cubis.be

Jeroen RoosenManaging-Partner

+32 (0)478 94 93 72jeroen.roosen@cubis.be@jeroen_cubis

Wim Van WuytswinkelManaging-Partner

+32 (0)477 91 74 26wim.vanwuytswinkel@cubis.be@wimvw77

Agenda

Agfa PoC Migration

Agfa-Gevaert Group

Parent Company CC and GSS

Agfa-Gevaert GroupBelgian

CompaniesAgfa-Gevaert NV

Agfa Healthcare NVAgfa Graphics NV

GSSAgfa ICSGlobal HR/Purchasing/Logistics

CC = Corporate CenterGSS = Global Shared Services

Technology Optimization: For Graphics, Healthcare and Specialty Products alike, Agfa ICS drives optimization to the

enterprise by aligning our client’s technology and operations strategies. Our professionals endeavor to improve client technological

capacities while cultivating operational efficiency, effective service delivery and optimal cost savings.

World’s first large-area flexible OLED

Graphics HealthCare Specialty Products

BI on HANA@Agfa

• First PoC to see whether SAP HANA is a solution

• Then migrate BI-platform to HANA

Scope : Speed up

• Cubis

• Exertum

• Cubis

• Exertum

• Agfa

PoC Projects

HANAScope@Agfa

SAP systems DB replacement– All Agfa ICS SAP systems with Oracle are in scope– Priority (burning platform, major roll-in’s or not, …)– To HANA, To Sybase OR stay on dedicated Oracle machine

New and future functionality of SAP– HANA-LIVE?– Simple finance?– S4HANA?– …

POC

PoCOverview

Strategy Scope Workflow Challenges Results

PoCStrategyClear Requirements --What do we want to “proof”?

Replacing Oracle with HANA should make the performance of end-user reports significantly better!

Tangible Results --How will we measure success/failure?Move an entire Agfa domain to a separate PoC environment

• real-world data • real-world queries

Efficient Process --Can we “run simple”?Core-team of Cubis/Exertum consultants, @Agfa and @PoC-environmentMake use of our expertise w.r.t. the Agfa BW systems

Easy to quickly make progress / adapt to unforeseen ‘bumps’ in the road Limited involvement of Agfa personnel needed (requirement)

PoCScope

• 18h daily load

• Fast growing volumes

Healthcare BW System

• 300 million lines

• 26 sources

• 8 source-systems

• Daily ‘full’ loads (24/7)

• 30min+ runtimes• 90+% DB-time• High complexity• High level of

detail (for calculations)

Sales Funnel Domain 4 specific (KPI) reports

PoCWorkflow

Create PoCenvironment

Perform tests and analyze results

Copy Agfa datato PoCenvironment

.CSV filesOpenHub (APD for MD)

SAP transport system (K-files & R-files)

Copy Agfa data model to PoC environment

Present results to Agfa

PoCChallengesTime constraints

– Initial estimate of 25 mandays

– Estimate for reduced requirements of 14 mandays

– Lead time of only 2 weeks (12 working days) available

Bigger Data bigger challenges

– How to get 240GB of data from ‘A’ to ‘B’?

– How to load (or even open) 12GB .CSV files?

One of us actually picked up a hard-drive at Agfa,

drove to Brussels, and delivered it at our

datacenter

PoCResults

75 Million

Records read

700.000 cells transferred

6,4x Workbook

performance all-in

20xWorkbook performance excl. frontend & network

Future Proof

records x2 = negligible

MIGRATION

MigrationReason

Healthcare BW system is already beyond it’s capacity– Daily load takes 18h hours, often not ready for business-hours

– Several ‘DB-intensive’ reports run 20 minutes

(on specific optimized aggregates!)

– Amount of data is growing fast

• Almost all data needs to be kept (long-running projects)

• Monthly snapshots for comparisons

Migration Overview

Scenario Upgrade/Migration Pre-requisites Testing/Issues Results

Migrationscenario

BD5

BW 7.30 SP08Dual stack

Oracle Linux 5

Oracle 11.2.0.3Solaris 11

BQ5

BW 7.30 SP08Dual stack

Oracle Linux 5

Oracle 11.2.0.3Solaris 11

BP5BW 7.30 SP08Dual stack

Oracle Linux 5

Oracle 11.2.0.3Solaris 11

Dual Stack system

Landscape Before

Migrationscenario

BDE

BW 7.30 SP08Java stack

Oracle Linux 6

Oracle 11.2.0.3Solaris 11

BQE

BW 7.30 SP08Java stack

Oracle Linux 6

Oracle 11.2.0.3Solaris 11

BPE

BW 7.30 SP08Java stack

Oracle Linux 6

Oracle 11.2.0.3Solaris 11

BD5

BW 7.40 SP10Abap stack

RHEL 7

HANA Revision 96SuSe 11

BQ5

BW 7.40 SP10Abap stack

RHEL 7

HANA Revision 96SuSe 11

BP5

BW 7.40 SP10Abap stack

RHEL 7

HANA Revision 96SuSe 11

Java Stack system

ABAP Stack system

3 HANA Appliances, each:1 Tb RAM

4*2 Tb non-SSD

800 Gb SSD

4 cpu sockets * 16 cores 2.5 GHz

Landscape After

Migrationsteps

Dual stack split– Java application servers on Oracle Linux 6

– Java remains SAP BW 7.30 SP08

– Database for Java stack remains Oracle 11.2.0.3

Creation Contingency system (BC5)– Copy from Development system (BD5)

– ABAP stack only

– Used for emergency fixes

Refresh BQ5– Copy from Production system (BP5)

– Provide most recent data to test

Go-LiveBP5

April Mei

Juni

AgustusJuli

Appliances ordered

BD5 Dual stack split&Migrate to RedHat

Appliances installedin the datacenter

HP prepares Virtual server

BD5 SUM / DMOon Revision 95

BQ5 Dual stack split&Migrate to RedHat

BQ5 SUM / DMOon Revision 96

BP5 Dual stack split&Migrate to RedHat

BP5 SUM / DMOon Revision 96

2015

Migration Overview

Upgrade/Migration

MigrationSUM/DMO

SUM/DMO procedure:

– Based on known tool SUM

– Database migration and SAP upgrade are combined

– Only database server is changed

– Original database is kept, can be reactivated as fallback at reset

MigrationSUM/DMO

SUM/DMO at AGFA:

– Netweaver 7.3 SPS8 7.4 SPS10

– ORACLE 3.8 TB HANA 480 GB (rev 96)

– Technical downtime for production of 20h

Migration Overview

Pre-requisites

MigrationPre-requisite tasks• We first only performed the “upgrade” task lists, but it needed to be the

“upgrade+migrate” (SUM/DMO) task lists (ASU Toolbox)• We also needed some tasks from the non-DMO upgrade list• FYI: We were already using the new ‘analysis authorizations’ concept

MigrationPre-requisite tasks

MigrationPre-requisite tasks

MigrationPre-requisite tasks

• Some extra tools exist (http://scn.sap.com/docs/DOC-40984)

– We used them specifically for finding ABAP-related changes

Migration Overview

Testing/Issues

MigrationTestingTests

– All BEx workbooks were opened and refreshed

• For a list of important workbooks, we checked the numbers before and after the upgrade

– The most important process chains were run

– IP functionality was checked thoroughly, as we heard this could be impacted and we have a lot of specific IP reports

14 issues

– 9 found during testing

– 5 found when already live

BW 7.4 Issue HANA Issue

Stricter rules 5 N/A

BUG’s 3 2

Agfa specific cases 4 0

Total 12 2

MigrationOSS Notes39 notes to resolve Upgrade/Migration issues

– during ASU Toolbox

– during Testing

39 notes for using HANA-optimized objects

– Imported after actual upgrade

MigrationIssuesBW 7.4 - Stricter rules

– ABAP changes

MigrationIssues

BW 7.4 - Stricter rules– Creation of records without proper counter in start/end-routine

MigrationIssues

BW 7.4 - Stricter rules (continued)– BEx option “Calculation Before Aggregation” Luckily we have exception aggregation on multiple objects now

MigrationIssues

BW 7.4 - Stricter rules (continued)– Cube with DB-partitioning and an inconsistent time-dimension

• e.g. 0CALMONTH = filled, 0CALDAY <> filled

• Optimal solution is fixing the time-dimension

• Instead, because of the huge amounts of data, we chose to use parameter “RSDD_PARTITION_ALLOW_TIM_INCONS” in RSADMIN

MigrationIssues

BW 7.4 - BUG’s– Values with a hyphen (-) treated as a range in BEX query selections

– BEX error “Client out-of-memory” for reports with large result sets

• Due to CHAR250 extension (more memory used for same amount of objects)

• OSS-note 2201034 can partially fix this

• It’s better to re-consider the report design (e.g. why more than 30.000 rows visible?)

– Incorrect displaying of decimals (Key figures)• OSS-note 2094848

MigrationIssues

HANA - BUG’s– HANA-indexes not OK when activating a cube under a multicube

• Do not use the ‘ignore’ option from OSS note 1955263!

(transports will work, but you get weird behavior in the reports)

• Run program “RSDDB_LOGINDEX_CREATE” instead

– Occasional dump in FM “RSSM_GET_TIME”

• The FM checks the alignment of the timestamps between the application servers and DB

• OSS note 2149600

MigrationIssues

• Integrated Planning - Executing Planning Functions

Migration Overview

Results

MigrationResults

Most queries run under 1 or 2 seconds

– 30 minute queries reduces to less than 30 seconds (without aggregates !)

– Business can now (finally) quickly check the reports and run them for different filter-values in a matter of minutes

Daily load goes from 18 hours to 6 hours

– business users have their data on time

– No more nightly support for the BI team (for now, only HE)

Monthly snapshot load goes from 24 hours to 6 hours

– Business can start their forecast 1 day earlier and thus have 1 extra day to complete it

Loads from the Healthcare BW system towards other systems had to be adjusted because the HE system was finished too early!

Migration Manual ImprovementsBEX

– The “repair” function made a huge difference for the client-time of certain workbooks

– Non-standard query settings in RSRT were removed

– Optimizing the filter-range for IP functions (e.g. ‘only perform on changed data’ option)

Loads (still several hours ‘won’)– Custom ABAP tuning– HANA optimized Cubes (only in specific

cases)– DTP package size

MigrationTODOConvert all cubes to HANA-optimized cubes

Investigate HANA-optimized transformations

Experiment with HANA-views (HANA-studio)

Investigate on new 7.4 options

– Long(er) info-objects (CHAR250)

– IP in-line comments

MigrationLessons Learned

All-in-all, the actual upgrade went smoothly

The results were very well received, and align with expectations

For BW it’s “business as usual” after the upgrade

Testing, testing, testing

1

2

3

4

A higher SP might diminish the large amount of OSS Notes5

Migration User Reaction

“... thanks for informing, indeed the already used reports are very fast !!!”

“The result of this is "very" significant - makes me happy (and less stressed) to run reports again :-)Thanks to all who made this happen.”

“It is working now and definitely faster.”

“Speed is much improved!” !

SummaryProject4 months lead-time

– +-100 man days for BACC team– Take your time for the pre-requisites– A lot of time needed for testing on DEV/QUA

(low data quality, leftovers from testing, …)

4 different teams involved– Timing & Availability– Who does what?– Communication

Business-involvement– Development Freeze– Business testing– Go-live procedure

• Loading-stop vs system-downtime

Dependencies with other projects– 3 projects (1 kept developing via contingency system)– 5 changes– 2 tickets

Questions...

Thank You