Introduction Sizing Your HANA System HANA Hardware Options Pre-Steps for BW to HANA Migration Four BW to HANA Migration Options Staffing a HANA Migration Project Creating a Budget for your HANA Migration Project On-Going Support Tasks and Staff Required A Milestone Example Wrap-Up .
SAP HANA, as of 2013, can be used as the in-memory database for BusinessSuite, BW and SAP’s BusinessOne Solution
SAP has released a new ABAP based tool that generates a report significantly better sizing fro SAP BW than using just the QuickSizer above. This program takes into consideration existing database compression, different table types and also include the effects of non-active data on the HANA system.
The higher precision you run the estimate at the longer the program is going to run.
To increase speed, you can also suppress analysis tables with less than 1 MB size.
With 14 parallel processors and 8Tb data warehouse, it is not unusual to see 45-75 minutes run time.
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.
After you have downloaded and installed the program, and-selected the parameters above, you can go to SE38 and run SDF/HANA_BW_SIZING as a background job.
The output is stored in the file you specified and the file can now be email emailed to hardware vendors for sizing input and hardware selection.
This program is attached to SAP Note: 1736976 on SAP Marketplace
A T-shirt model is a quick way to get some basic ideas on what a system may look like.
While very inaccurate for sizing, it provides basic information for those just staring considering SAP HANA
The number of processors are largely driven by the number of users and usage patterns. Serious consideration should be made before buying hardware.
There are currently 7 different certified HANA hardware vendors with 13 different products.
Some boxes can be used as single nodes with others are intended for scale-out solutions for large multi-node systems
In this box, we are see the inside of an IBM x3950 HANA system.
The system basically consists of memory, disk, processors and network cards
The hardware vendor will install, connect and to a health check on your system before handing it over to you. A 3-year service plan is also normally required.
SAP has a checklist tool for SAP NetWeaver BW powered by HANA (thanks Marc Bernard).
In this tool, SAP provided automatic check programs for both the 3.5 version and the 7.x version of BW. These are found in SAP Note: 1729988.
In version 2.x of this tool, hundreds of checks are done automatically in the BW system. This includes platform checks on database and application and system information.
There are even basis checks for support packs, ABAP/JAVA stacks, Unicode, BW releases, and add-ons to your system.
The idea of the checklist tool from SAP 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..
You can save significant amounts of work by doing a cleanup effort before you start your HANA migration or a BW upgrade project.
For example, a international company had a BW system with over 108 TB, with only 36TB in the production box and the remaining data on their Near-Line Storage (NLS) solution.
This cleaned BW system saved them potentially millions of dollars in hardware and HANA licensing costs.
It is not unusual to reduce a BW system size by 20-30% during a clean up effort.
This will still provide access to the data for the few users who infrequently need to see this old data. You will also be able to query it when BW is on HANA, but it does not need to be in-memory.
A major decision before you start is to determine which of these options your want to pursue. We will now take a quick look at each of them
Functionally, you have the same system and this approach is therefore the fastest and most common.
How much additional optimization effort you are willing to undertake depends on the resources available and how fast you have to complete the migration.
While more costly, this approach allows you to keep the old system around and minimize risks of the HANA migration. The outage required is also minimal and can be done over a weekend functional area by functional area.
After testing, you can switch the users over to the new BW HANA box and de-commission the old BW.
For many organization a migration of their BW systems to HANA (technical migration), followed by a later functional optimization is the most common approach (so far).
Raw data size: 2.7 TB
Duration: 14 weeks
Risk aversion: Medium
Other usage: IP
This organization is using BWA and will be retiring it as part of the HANA migration
Raw data size: 5.6 TB
Duration: 18 weeks
Risk aversion: HIGH
Other usage: None
Raw data size: 38TB
Duration: 5 mos
Risk aversion: HIGH
Other usage: APO, IP,
This assumes minimal additional functional optimization
There are a set of items you need to budget for. From a system perspective you will need to consider:
Give at least two vendors your sizing estimate and ask for quotes.
Make sure your hardware vendor include 3-years support in your purchase
Plan and budget for any BW upgrades required before going to HANA (7.3)
Do the pre-steps BW cleanup we outlined earlier as soon as possible and then the formal sizing effort, before requesting a hardware quote.
This example quote is for a mid-sized 512 GB memory box with 4 x 10 cores CPUs and 7 TB disks based on Hewlett-Packard's high-end DL-980 Box.
Including all services and support agreements, this quote is only $150,000
Certified HANA vendors such as HP, IBM, Dell, Cisco, NEC, Hitachi and Fujitsu has dedicated staff to help you get a detailed quote in matter of days.
This is example is a quote for a smaller 128 GB Memory Box with 2 x 10 cores is based on Dell’s R910 platform for a HANA sidecar usage for less then $40,000 (including tax!)
Most of the smaller HANA systems from the other vendors are similarly prices and depends on the number of boxes you buy, existing discount agreements and the size of the deals you are requesting.
Expect competitive bids for larger systems and similar vendor pricing for similar capabilities
Remember to budget for HANA training for your employees before the project starts
Class schedules are found at: training.sap.com
On average plan for $3,000 to $6,000 to train each team member on average plus travelling costs.
When staffing your HANA project, don’t schedule the start date before you get your staff. You want the best resources, not whoever is available.
Major on-going support tasks consists of:
While most tasks are similar to the old relational database systems, the way we do this is quite different. Make sure your HANA support staff is onboarded early and trained before cut-over to production of your migration project.
The staffing roles required is normally:
- One basis resource for system admin and monitoring for every
4-5 environments (do you need 24-hours support?)
- One resource, part-time, for security, roles and access
maintenance (depends on number of users)
- One BW resource for monitoring loads, issues and fixes (could
be part-time role in small and mid-sized organizations)
The support of HANA is actually easier than the traditional basis support. Most functions are done in a single interface and many of the tasks are significantly simplified due to the inherent performance of HANA.
First we clean the BW system, size the box and do the health check we covered earlier in this session.
Then we order hardware and get the vendor to install the hardware.
Be prepared for 4-6 weeks lead time for hardware delivery
While waiting for hardware, upgrade BW, apply SPS and execute training
Start with refreshing the sandbox from the development environment.
Migrate the Sandbox carefully and spend time on testing.
Do not rush this part of the project and document all activities (create a migration script of all activities)
Plan ‘contingency’ time for any delays and do a cut-over on the weekend.