Embed Size (px)
Citation preview
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
@cubissolutionswww.facebook.com/cubis.be
Jeroen RoosenManaging-Partner
+32 (0)478 94 93 [email protected]@jeroen_cubis
Wim Van WuytswinkelManaging-Partner
+32 (0)477 91 74 [email protected]@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
