Download presentation
Presentation is loading. Please wait.
Published byChester Gilmore Modified over 9 years ago
1
Produced by Wellesley Information Services, LLC, publisher of SAPinsider. © 2015 Wellesley Information Services. All rights reserved. Top 10 Lessons Learned from Large SAP BW to SAP HANA Migrations Dr. Bjarne Berg Comerit
2
1 In This Session, You Will Learn: Sizing and technical preparation best practices How to select the best hardware options for your needs Using the direct database migration (DMO) tool to streamline upgrade and migration The Top 10 lessons learned from large HANA migration projects We will also look at possible hardware architectures to leverage your investments
3
2 Introduction – Dr. Bjarne Berg
4
3 What We’ll Cover Background Sizing your HANA system Hardware options and cheaper alternatives Using DMO for you migration Top 10 lessons learned from large SAP HANA implementations Wrap-up
5
4 SAP Business Suite on HANA For the last two years, SAP has supported SAP Business Suite on HANA This means that you can install a new ERP system on HANA or migrate your existing system to HANA to take advantage of the simpler architecture, as well as the significant performance benefits of HANA Since January 2013 companies have started to install or are moving their ERP systems to HANA, and it is becoming increasingly common To see what is supported from an ERP standpoint, take a look at SAP Note 1774566 (SAP Business Suite powered by SAP HANA – Restrictions); a list of pre-checks and more details is available at http://tinyurl.com/pm82orw http://tinyurl.com/pm82orw
6
5 Pre-Steps — Analyze BW Readiness Your should run this program well in advance of the actual migration The tool is essential to the planning phase to understand the tasks that are required for migrating to SAP HANA This tool does not replace the upgrade tasks in the DMO
7
6 Pre-Steps — Analyze BW Readiness (cont.) You should run this program well in advance of the actual migration This tool does not replace the upgrade tasks in the SUM, which we will examine in Part 2 of the session in more detail
8
7 Pre-Steps — Analyze BW Readiness (cont.) The tool is essential to the planning phase to understand the tasks that are required for migrating to SAP HANA
9
8 Pre-Steps — Analyze BW Readiness (cont.) The idea of the checklist tool is that you run it several times throughout the project Once before you start, then periodically as you resolve issues and upgrade requirements, and then finally when the system has been migrated to HANA The checklist tool also has specific checks for the HANA system that can help you identify any issues before turning over the system to end users
10
9 What We’ll Cover Background Sizing your HANA system Hardware options and cheaper alternatives Using DMO for you migration Top 10 lessons learned from large SAP HANA implementations Wrap-up
11
10 HANA Sizing Tool for Existing BW Implementations Using the BW Automated Sizing tool in the Migration Cockpit
12
11 HANA Sizing Tool for Existing BW Implementations (cont.) SAP has released an updated tool that generates a report significantly better for sizing SAP BW than using the QuickSizer. This tool should be used by all existing BW implementations for sizing (QuickSizer is only for new implementations). This program takes into consideration existing databases, table types, and includes the effects of non-active data on the HANA system With 8 parallel processors and 10 TB database, it is not unusual to see 4-5 hours runtime The higher precision you run the estimate at, the longer the program is going to run To increase speed, you can suppress analysis tables with less than 1 MB size
13
12 Since timeouts are common when running the sizing program, you can temporarily change the parameter in rdisp/max_wprun_time to 0 in BW transaction RZ11. Finally, you estimate the growth for the system as a percentage or as absolute growth. This program is referenced in SAP Notes 1909597 and 1736976 on the Service Marketplace
14
13 System Characteristics and Size Reduction — Another Real Example On the master node alone, the top 5 statistics and batch tables account for 147 GB of data in the current BW system, and will reduce the HANA system by 98 GB if cleaned up If the statistical cubes are cleaned up, additional significant HANA size savings can be achieved. Just the top 5 stats tables can save over 6 GB of HANA space. Cleanup of the BW system should be done as pre-steps in the HANA migration
15
14 SAP QuickSizer for HANA There are three versions of the tool for each version of SAP HANA SAP’s QuickSizer for SAP HANA is available at http://service.sap.com/quicksizer * http://service.sap.com/quicksizer The last is for those who want to use SAP HANA as a standalone platform for in- memory data (i.e., using SAP Data Services to load data to) The second QuickSizer version is for SAP HANA on SAP BW The QuickSizer for the Business Suite allows you to size for specific modules * Requires login credentials to the SAP Service Marketplace
16
15 SAP QuickSizer for New BW HANA Implementations In TABLE 3, you estimate how many records will be loaded to SAP BW periodically. In this example, we’re estimating that 279,994,355 records will be loaded each day between noon and 1pm. In SAP Note 1637145, SAP BW on HANA: Sizing SAP In-Memory Database, there are programs you can run on SAP BW to get good sizing numbers The shell script for this is located in the file get_size.zip, which should be extracted and executed along with the file load_RowStore_List.SQL for size input to TABLE 4 The exception to this approach is the IBM DB2 database on the z/OS. For this combination, there is an ABAP program instead. NOTE: The QuickSizer should only be used for new HANA implementations and not for migration of existing systems
17
16 This SAP HANA sizing example calls for 1.6 TB of memory Because we’re unlikely to get this in a single server node, we’ll have a multi- node system SAP QuickSizer for HANA — Output In this case, SAP HANA for BW will deploy the master data, ABAP system tables, and row store data on the master node. The other connected server node(s) will contain the InfoCubes and DSOs.
18
17 Rule-of-Thumb Approach to Sizing HANA — Memory Memory can be estimated by taking the current system size and running the programs in “get_size.zip” in SAP Note 1637145 to get row and column store sizes for your system The 50 GB is for HANA services and caches. The 1.5 is the compression expected for row store tables, and the 4 is the compression expected for column store tables. The 2-factor refers to the space needed for runtime objects and temporary result sets in HANA. Finally, the term “existing DB compression” is to account for any compression already done in your system (if any). Memory = 50 GB + [ (rowstore tables footprint / 1.5) + (colstore tables footprint * 2 / 4) ] * Existing DB Compression Remember, these are quick rules of thumb, so don’t rely on them for finalized budgeting and hardware purchases
19
18 Rule-of-Thumb Approach to Sizing HANA — Disk The next item you need is disk space, which can be estimated by the following: In this example, you need 4 x 710 GB disk for the persistence layer and about 710 GB for the logs. This equals around 3.5 TB (don’t worry, disk space of this size is now almost “cheap”). The persistence layer is the disk that keeps the system secure and provides for redundancy if there are any memory failures, so it’s important not to underestimate this Disk for persistence layer = 4 Memory Disk for the log = 1 Memory Remember, these are quick rules of thumb, so don’t rely on them for finalized budgeting and hardware purchases
20
19 Rule-of-Thumb Approach to Sizing HANA — CPU The CPUs are based on the number of cores that you include. For example, 10 core CPUs now exist (depending on when you bought your system). If you have a single node with 4 x 15 cores, you will have 60 cores and can handle 300 active users on that hardware node and quite a larger number of named users. CPU = 0.2 CPU cores per active user Remember, these are quick rules of thumb, so don’t rely on them for finalized budgeting and hardware purchases
21
20 Summary of BW HANA Sizing Approaches Approach Quality of EstimateEffort Required T-Shirt Sizing Sort of “OK”Very Low Rule of Thumb Better Low SAP QuickSizer Much better (new implementations only) High Sizing for BW program Excellent (for existing BW systems) Moderate/Low Work with your preferred vendor before ordering your hardware or finalizing your budgets SAP Note 1736976 (ABAP report to help with BW on HANA Sizing) SAP Note 1909597 (SAP BW Migration Cockpit for SAP HANA) SAP Note 1729988 (SAP BW Checklist for Migration) SAP Note 11855041 (Sizing the Master node)
22
21 Sizing for Business Suite on HANA SAP has created a program for sizing HANA for Business Suite: This should be used for all HANA migration projects of ERP/ECC/Business Suite
23
22 Sizing for Business Suite on HANA (cont.) Some vendors have also created their own sizing programs, which also include hardware prices
24
23 QuickSizer for Business Suite on HANA – New implementations only For New Business Suite implementations, you can use QuickSizer and send the results to SAP for further processing
25
24 QuickSizer for Business Suite on HANA (cont.) This is the input screen where you enter the number of expected transactions by module. You are also asked to enter estimated changes and new records as well as operating times of your system. Here you get the size in SAPS, as well as memory and disk requirements
26
25 Sizing a Standalone HANA System — Output This is the input screen Here you get the size in SAPS, as well as memory and disk requirements
27
26 What We’ll Cover Background Sizing your HANA system Hardware options and cheaper alternatives Using DMO for you migration Top 10 lessons learned from large SAP HANA implementations Wrap-up
28
27 Some Hardware Options for HANA There are many certified HANA hardware vendors with over a dozen different products
29
28 New Hardware Options for HANA Some boxes can be used as single nodes, while others are intended for scale-out, scale-up solutions for large, multi-node systems
30
29 HANA Cloud Options
31
30 Business Suite — Landscape Deployment Planning Virtualization MCOS MCOD Technical Co-Deployment Deployment Scenario HANA DBs Multiple One DB Schema Multiple One Availability Supported for DEV & QA systems Defined by: White List 1661202 for BW White List 1826100 for Suite Business Suite components SCM and/or SCM co-deployed with ERP Source: SAP SE, 2015
32
31 What We’ll Cover Background Sizing your HANA system Hardware options and cheaper alternatives Using DMO for you migration Top 10 lessons learned from large SAP HANA implementations Wrap-up
33
32 Direct Migration Option (DMO) During the upgrade from BW 3.x to version 7.0, many companies decided not to complete Unicode conversions, security conversion, and other recommended steps Since these are now required for BW 7.4 and subsequent migrations to HANA, some companies are planning first to do the upgrade and then do a migration project. That is a mistake! With the new Direct Migration Option tool, you can accomplish both the 7.4 upgrade and the HANA migration in one step DMO is a key option in the Software Update Manager (SUM) for those with older, out-of-date BW systems that want to migrate to HANA
34
33 Creating a DMO Migration Runbook The best way to approach this is to start with the sandbox system and create a runbook with step-by-step lists on how each problem and software task are created. It is not unusual to have a 90-100 page word document with screenshots and documentation at the end of this first migration. The “runbook” is the key to success. You should build on this when you migrate to the Development and then the QA and the Production systems. DMO started supporting Unicode conversions at the end of 2013 and is now available Speed is not important in the first sandbox migration. The creation of a repeatable process is far more important.
35
34 A 108 Step Example of a DMO Migration Runbook There are many repertory task you must do before the actual migration In steps 1, 2, and 3, we are reviewing the latest notes and setting up user and system access In step 4.2, you must request a migration key
36
35 A 108 Step Example of a DMO Migration Runbook (cont.) For those doing a Unicode conversion, there are many additional steps. We first need to check what is already in-place. Thankfully, SAP provides programs to help you with these to check the config. You can get this report by running the report UCCHECK and seeing the installed languages in the source system by using the transaction SMLT
37
36 A 108 Step Example of a DMO Migration Runbook (cont.) The next major step is to extract the files needed for the migration. Here you will need the migration keys you obtained in step 4.2.
38
37 A 108 Step Example of a DMO Migration Runbook (cont.) If you are working with a BW system that is not heavily used or one that has lots of processing capacity, you can minimize the downtime by using a “shadow system” during the upgrade If you use a shadow system (option 2/3), the system will be copied (not the data) and many of the upgrade tasks will happen on this “shadow system” while the real system is still running Only in the later stages is the system unavailable to the users while the configuration and data are moved to SAP HANA This minimizes the downtime of the system
39
38 A 108 Step Example of a DMO Migration Runbook (cont.) Now we have to tell the DMO what system we are coming from and what system we want to migrate to
40
39 A 108 Step Example of a DMO Migration Runbook (cont.) It is now time to check inside SAP HANA Studio that the BW schema has been created by DMO. You find this under “users” in the HANA navigator. We also have to decide what support packages we want to include in the upgrade. Normally we pick the latest and ignore the equivalent SPs.
41
40 A 108 Step Example of a DMO Migration Runbook (cont.) Since the “shadow system” is created, no more changes to the configuration or settings in the existing BW system can occur after this stage NOTE: Users can still access the system
42
41 A 108 Step Example of a DMO Migration Runbook (cont.) If we want to make changes to the shadow instance, we can do that by logging on as user DDIC and changing the system setting using the transaction code SE06 We can now make changes directly using the transaction code SPDD
43
42 A 108 Step Example of a DMO Migration Runbook (cont.) After the tables have been created in the HANA system, you can reorganize them This allows you to load balance the HANA system even further before completing the migration of the data from BW to HANA This is not a required step for most systems
44
43 A 108 Step Example of a DMO Migration Runbook (cont.) We now have to lock down the system and stop all jobs and access
45
44 A 108 Step Example of a DMO Migration Runbook (cont.) Before we proceed any further and start migrating the data, we should complete a full backup of the system
46
45 A 108 Step Example of a DMO Migration Runbook (cont.) We are now in the lockdown and downtime phase. The instance is running as a “remote host” and we will start moving data to the new system.
47
46 A 108 Step Example of a DMO Migration Runbook (cont.) Before we provide users and developers access to the new system and start testing, you should run another backup of the system so that valuable time can be saved if you have to revert back to a pervious system
48
47 A 108 Step Example of a DMO Migration Runbook (cont.) At this stage, the users can access the new system and start the testing of the migration. We normally have both technical and functional testers involved in this phase.
49
48 A 108 Step Example of a DMO Migration Runbook (cont.) We are now ready to access the HANA system and all post-processing tasks have been completed The next step is to start the development migration using the runbook
50
49 What We’ll Cover Background Sizing your HANA system Hardware options and cheaper alternatives Using DMO for you migration Top 10 lessons learned from large SAP HANA implementations Wrap-up
51
50 Lesson #1: Buy Hardware Early The typical lead time for the basic HANA appliances is as little as 4-8 weeks However, for large scale environments or multi-node environments, the lead times can sometimes be as long as 10-14 weeks This is particularly true for virtualized systems managed by a third- party who has to set them up, configure backup, and learn the new technology Get a small team on site early for planning, budgeting, and sizing and hold off staffing all team members from the business until you get a confirmed hardware delivery date
52
51 Lesson #2: Get the Right Team Members While there are many with basic certifications in HANA, the pool of qualified experienced resources is limited Great HANA resources are most likely working on another project already So, if you want the best, be prepared to give your implementation partner several weeks lead time Do you want “who is available” or “ who should be available” on your project? Be prepared to give your implementation partner longer lead times than usual.
53
52 Lesson #3: Include Training for Your Staff There are a lot of “myths” and beliefs about HANA that you have to address early Before you start the project, make sure your implementation partner has a formal written training plan on how they will provide knowledge transfer Include your support staff and Basis people in all project discussions from the first planning session Many are “fearful” of a new technology and are unsure how this will change their work. You should provide real demos and workshops early so that everyone knows what is happening and how HANA will change their day-to-day jobs.
54
53 Lesson #4: Hardware Sizing Should Include Growth Some customers forget that sizing would be for 3 years out and not based on current system size alone You should have a sizing estimate that includes new projects, data growth, and data retention policies, as well as periodic scheduled clean-up activities Funding for hardware is sometimes easier in a project mode, and many companies plan for 30-50% more capacity as part of the initial rollout if they can afford it
55
54 Lesson #5: “Master-Node” Size Some hardware vendors want to maximize the number of processes available to the users. They can do this by using multiple smaller nodes with many processors in each. The drawback is that all of your row and master data stores may not fit on the small node as you grow. Pay very careful attention to the row stores’ sizes and the master data growth when buying hardware. You don’t want to have to upgrade shortly after go-live.
56
55 Lesson #6: Create an Ecosystem of Experts Having access to the best and brightest within SAP, consulting firms, and industry experts is key when issues or questions arise These people are very busy and are often engaged on many projects as “supporters” Formally assign a team of 2-3 experts to come in and meet with your team a few times during the project planning and execution. Make sure these project advisors are hands-on and that they can act as technical go-to resources for your team if questions arise.
57
56 Lesson #7: Think BIG A HANA implementation should not be treated as a replacement project. It is an enabler … Plan ahead on what you are going to do with the new technology, e.g., mobile, forecasting, planning, BI dashboards, customer and vendor-facing analytics, market basket analysis, stratification, data visualization, etc. Early in the project, create a 2-3 year strategic plan that demonstrates to the leadership what you are going to do with this new technology. Present it as new capabilities, not just how fast it is …
58
57 Lesson #8: Plan for Reporting and System Consolidation After go-live, you should have planned for how you are going to migrate all reporting and management analytics onto HANA and away from datamarts and standalone expensive systems that are not integrated into the long-term vision You will most likely have to do some “selling” to your fellow employees, and be prepared to give them “free access” to your HANA system HANA is not just for BW or Business Suite. It is an enterprise platform for integrated analytical and data processing. You can give developers access to your system and they can build their own Agile marts inside HANA, even if they don’t want to use BW.
59
58 Lesson #9: Near-Line Storage Can Save Millions Removing data that is not needed on a daily basis from your system and placing it on near-line storage instead of in-memory can save you millions In one project, a customer took his system from 112 TB to 38 TB by simply moving data to near-line storage (NLS) An Asian firm took a 3.8 TB BW system to “only” 900 GB after cleanup and an NLS implementation There are many NLS solutions available that can save you big bucks by reducing the need for multi-node, multi-terabyte HANA systems. Take a serious look at SAP IQ solution for NLS. It is tightly linked with HANA already.
60
59 Lesson #10: Save Money with MCOD and MCOS You may not need separate hardware for sandbox and development environments Using Multiple Components One Database (MCOD) and/or Multiple Components One System (MCOS), you can simplify the number of hardware environments you need SAP BW on SAP HANA SAP Finance and Controlling Accelerator for the material ledger ERP operational reporting with SAP HANA SAP Finance and Controlling Accelerator: Production Cost Planning SAP Rapid Marts SAP COPA Accelerator SAP Operational Process Intelligence SAP Cash Forecasting SAP Application Accelerator/Suite Accelerator Smart Meter Analytics In addition to custom-developed datamarts, all items above can run in an MCOD setup (see SAP Note 1666670 for more details)
61
60 What We’ll Cover Background Sizing your HANA system Hardware options and cheaper alternatives Using DMO for you migration Top 10 lessons learned from large SAP HANA implementations Wrap-up
62
61 Where to Find More Information www.sap-press.com/sap-hana_3687/ Bjarne Berg and Penny Silvia, SAP HANA: An introduction 3 rd Ed (SAP PRESS). www.saphana.com/welcome SAP’s main page for all SAP HANA-related information www.saphana.com/community/try SAP HANA Marketplace http://scn.sap.com/community/bw-hana SAP BW powered by SAP HANA Community
63
62 7 Key Points to Take Home There are programs to do pre-readiness checks for an ERP and BW system for migration to HANA A BW Migration Cockpit is now available to assist in the tasks There are currently seven different certified HANA vendors, and many options for small, medium, and large systems — Make sure you get a competitive bid Budgeting should include HANA training and system cleanup, as well as support staff required or reorganized Many HANA projects can be done in a matter of a few weeks; only very large systems may require 4-7 months HANA is becoming mainstream with hundreds of customers; you should get there ASAP! HANA systems with fewer nodes are easier to manage; so scale-up is simpler than scale- out HANA systems
64
63 Your Turn! How to contact me: Dr. Berg bberg@comerit.com
65
64 Disclaimer SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by SAP SE.
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.