Quickly Move Your SAP BW System to SAP HANA Using the Database Migration Option Tool: Q&A with Dr. Berg

by Dr. Berg

April 30, 2015

The Database Migration Option (DMO) tool has been available for more than a year, and it substantially helps companies automate their migration from traditional SAP BW systems to BW on HANA. How can you use this tool to move your legacy databases to HANA in a more automated way, for a smoother transition to HANA? 

Dr. Bjarne Berg, ComeritReview our one-hour online Q&A on the DMO tool with BI Expert author Dr. Bjarne Berg and his COMERIT colleagues Rob Frye, Jesper Christensen, and Joe Darlak.  In addition to questions on sizing and time estimates for HANA migration, minimizing downtime and performance issues, and challenges for implementations using the DMO tool, they shared their expertise and answers to readers' specific questions, including: 

  • What are licensing and other requirements for the DMO tool? How do we access SUM/DMO and the HANA Migration Cockpit?
  • What is the key difference between inline, DMO and PCA migration?
  • Is the DMO tool recommended for Unicode conversion only to HANA?
  • Can we use the DMO tool for multi-tenant databases?
  • What are difference between inline, DMO and PCA migration?
  • Will we need an Application Server layer when running BW on HANA?
  • Should we upgrade our 3.x dataflows to BW 7.x before a move to BW on HANA? 
  • What are performance differences between BI Accelerator and HANA?
  • Can we stream tables real-time from ECC to BW on HANA -- without impacting ECC performance?



Welcome to the live chat about the Database Migration Option (DMO) tool and migration to SAP HANA. Our panelists today are Dr. Bjarne Berg, Rob Frye, Jesper Christensen and Joe Darlak  of COMERIT. Jesper Christensen and Joe Darlak are co-authors of SAP BW: Administration and Performance Optimization. Rob Frye, Joe Darlak, and Dr. Berg co-authored The SAP BW to HANA Migration Handbook.  BI Expert managing editor, M.S. Hein, is our moderator today for this live chat.

M.S. Hein: Thanks for joining us today for our Q&A! Our panelists are BI Expert author and HANA 2015 speaker Dr. Bjarne Berg, and his COMERIT colleagues Rob Frye, Jesper Christensen, and Joe Darlak. They are here for the next hour to take your questions on SAP’s Database Migration Option tool, and share tips and advice based on their recent experiences with SAP HANA migrations. Thanks for joining us today! 

Rob Frye:  Hello everyone! We're excited about the opportunity to answer your questions today. We look forward to an informative Q&A.

Joe Darlak:  Hello everyone!

Jesper Christensen:  Hi everyone. Thanks for joining.

Dr. Berg: Hi Guys and Gals, let’s get started.


NOTE: In this edited version of the Q&A, we’ve grouped questions into BW-to-HANA Migration Best Practices, DMO Uses and Features, and HANA Sizing and Performance.

BW and HANA Migration Best Practices & How-Tos

Comment From Chris

Are there any metrics that can be used to gauge the amount of time required to perform the migration? If there is an outage required for the migration, what can be done to minimize the duration ahead of time?

Jesper Christensen: This depends heavily on the hardware you have in place on the source DB host as well as on the Primarily Application Server (PAS). Based on our experience you can migrate somewhere between 100-1500gb of database size per hour.


Comment From Kathy

In your experience, where were the most issues experienced? Unicode migration? Upgrade of the BW system? DMO?

Dr.Berg:  Hi Kathy,

We don't see many issues in the Unicode conversion. It seems to take some time on larger systems, but is really almost “problem-free.”
The BW upgrade can be more labor intensive, based on how old your BW system is. For example, if you are going from BW 3.5, you have to convert your security, Unicode and queries and possible data flows, and that can take some time.
The DMO itself always results in some unknowns you did not expect and which you have to address. That is why we insist on a production dry-run before we start touching the production box. However, overall we think the DMO is a great tool that, combined with a solid runbook, works rather well.


Comment From chaitu

Can you go into detail about the migration process?

Dr. Berg:  Hi Chaitu,
We are using a 108 page runbook internally on the last dozen projects and also have a 631 item checklist, so that would require a lot of writing to answer a very open-ended question. Joe, Rob and I actually wrote a book on this as a step-by-step DMO migration handbook.

Comment From Sudhir Makkar

Is having two migration cycles in the sandbox a best practice or rule of thumb when it comes to migrating to BW on HANA from Oracle DB?

Jesper Christensen: We recommend that there should always be at least 3 migration cycles before the production system is migrated. One of these migrations should be performed on a recent copy of the production system. For larger and more complex migrations we recommend up to 6 test migrations before production is migrated.

Comment From Sudhir Makkar: Thanks, Jesper.


Comment From Phil

Hi, For a BW version already on NW7.4 SP09, no BW version upgrade is required. But a Unicode conversion is required. Would you still recommend use of the DMO tool for a combined Unicode Conversion and migration to BW on HANA, or not please? Or would you instead recommend a standard separate Conversion then Upgrade? Can you please give reasons for your advice?
Joe Darlak:  Yes, Phil. We still recommend the DMO tool. A Unicode conversion requires a DB export and import and so does a DB migration to HANA. The DMO tool allows you to complete both with a single export and a single import.

All New Content for October on the SAP Customer IT Hub!
Get quick and easy access to the wealth of knowledge, resources, tools, support and services that are available to all SAP customers.

Comment From J.D.

How do I get access to the HANA migration cockpit?

Rob Frye:  That’s a good question. Use SAP Note 1909597 to download the ABAP code and instructions needed to install the SAP NetWeaver BW Migration Cockpit for SAP HANA. Then use the SE38 transaction code from the SAP Front-end GUI to install and activate the cockpit. Once it’s installed and activated, you can execute the program from the ABAP editor.


Comment From Gopal

We are on BW 7.3 SP5. If we migrate the BW to HANA, can the same HANA system be used to combine data from external systems in the HANA studio? Or is it just a DB for BW alone?

Dr.Berg:  Hi Gopal,

With OpenODS in BW 7.4 and enhanced compositeProviders, you can combine BW and non-BW data and access it in views, as DSOs and use it as 'merged' data without needing to move the data to BW.


Comment From Gopal

Are there any incentives or credits for moving from BWA to HANA?

Dr. Berg:  Not really, unless you wrote that into the contract when you bought BWA (i.e., licensing). However, in benchmark tests we did for a real project in Europe on 78 queries, we found that the average on Oracle 11.2g and BWA, vs. HANA, the Oracle/BWA averaged 45.2 seconds for queries and the HANA tool 15.1 seconds (3 times faster). This is mainly due to the fact that most calculations are now done in memory in HANA, while BWA is predominantly only speeding up the fetch of data.

Comment From Gopal: Thanks, Dr. Berg.

Comment From Ian Fahsi

The BI Accelerator was also an in-memory setup! What's the difference in performance between HANA and BI Accelerator?

Dr. Berg: Please see the answer I gave Gopal.


Comment From Gopal

We are on BPC 10.0. If we migrate to BW on HANA, can we make use of HANA optimized InfoCubes for BPC, or is it restricted to regular InfoCubes since it involves write-back?

Jesper Christensen:  Hi Gopal, You can make use of HANA optimized infocubes for BPC cubes as well once the migration is complete.


Comment From Kathy

What is considered a "large" and a "complex" migration cycle?

Rob Frye:  This is a complicated question that we've touched on a bit in other responses. In very broad, very general terms, migrations of more than 10 TBs, and especially those requiring numerous functional areas and environments are considered large (or even extra-large). This is a question that's really too broad to give a definitive answer without more information, so make sure you pick a good implementation partner to help you plan your projects appropriately. Good, but complicated, question!


Comment From Raj

What are the options if we are still on BW 7.0 SP10? Do we need to upgrade to BW 7.4 or is there an alternate step for HANA readiness?

Dr. Berg:  Hi Raj,

You could go to BW 7.3, but I don't recommend it. BW 7.4 is the first release that takes full advantage of HANA. To use all the functions of the BW HANA Migration Cockpit, you have to be on 7.0 SP32 or higher, but we prefer enhancement pack 1 or higher. The DMO versions have their own prerequisites.


Comment From chaitu

Do you have any tips on migration execution?

Joe Darlak: Hi Chaitu. When migrating large databases, or on projects with tight timelines or in-place migrations, you need to plan on 3-4 Basis resources with OS/DB migration experience to work shifts round the clock to monitor the migration processes. Otherwise, one issue may derail your entire timeline and increase your outage duration. This 24/7 migration monitoring operation may also be necessary for your pre-production system and dry run migration cycles, so be sure to plan ahead.


Comment From Kathy

We're currently on BW 7.3 using a lot of 3.X data updates via transfer rules/update rules. Is it a requirement to upgrade these to transformations when upgrading to BW 7.4 with HANA?

Jesper Christensen: Hi Kathy,
No, it is not a requirement to update all data flows to 7.x before the migration. 3.x dataflows are supported in BW 7.40 and we have migrated several systems with 3.x data flows to BW 7.40 without any issues.


Comment From Kathy

Based upon the output from the BW on HANA sizing tool, should the result be implemented as is or doubled?

Rob Frye: The validity of the recommendations using this tool can vary widely, based on the detail and accuracy of the information you provide when using it. Remember that choosing the highest precision will cause the calculations to take much longer. For example, runtimes of 30-60 minutes, or even several hours, are not uncommon with a 10 TB database and 12 parallel processors.
In most cases, the low or medium precision options are good enough to give you an accurate baseline. As I've mentioned in previous responses, the help of a good implementation partner is pretty important to get the best results. Thanks for the question.


Comment From Dana

What does typical staffing look like for a HANA migration project?

Dr.Berg: It depends on the risk aversion and the size of the test teams. We currently are doing a HANA migration with 2 people from us and 2 from the client. That is a pure-technical migration (no optimization), on a 3 TB BW system with 4 environments.
Another mid-sized one we are doing (7TB) there are 4 from us, and 3 from the client plus 5 functional part-time testers. On a very large complex one (over 30TB), we had a team of 11 total and 14 part-time testers).
These projects ranged from 11 weeks to 30 weeks. The driving force of this was how much functional optimization we did, or if it was a pure 'lift-and-shift' database migration only.


Comment From Ian Fahsi

If I understand correctly, HANA has its own DB feature. So there is no need to pay for any Oracle or MS SQL DB licenses anymore.  And thus no more Oracle DBA or SQL DBA! :-)

Rob Frye: Yes, you can store your data solely in the HANA database. What many companies find is that, in spite of the initial investment costs in hardware and licensing, over the long-term, HANA has a lower total cost of ownership than traditional BW implementations. Thanks for the excellent question!


Comment From Pradeep Gopalakris

Is there an option to stream tables real-time from ECC (Oracle) to BW (HANA DB) without impacting the ECC system performance? Currently we use Oracle GoldenGate to stream tables from ECC (Oracle) to BW (Oracle) and HANA is not listed in the supported databases for Oracle GoldenGate at the moment.

Jesper Christensen: This is a great question. SAP HANA Enterprise edition includes license to use SAP landscape transformation (SLT). This provides the capability to replicate data from the Oracle ECC system to BW or HANA. It requires that the DMIS add-on is installed on the ECC system. This is what is used for HANA sidecar solutions like COPA on HANA, etc.


Comment From Angie

Are there any issues with old BPS content? Could these be migrated, too?

Jesper Christensen: Hi Angie, BPS is really an outdated part of a BW system. It is however still support in BW 7.3 and 7.4 but it does not make use of any HANA optimizations like Integrated Planning and BPC. I would recommend redevelopment of the BPS content using either BW-IP or BPC to get the full advantage of HANA. You can find more information in SAP note 1666756.


Comment From Gopal

Can Integrated Planning and BPC be used side by side in BW 7.4?

Rob Frye: Hi Gopal. According to SAP, BW integrated planning and BPC become one in BW 7.4 on HANA with the same software lifecycle and harmonized modeling environments. Good question.


Comment From Kathy

What is the typical delay between migrating Development to HANA before migrating the Production environment to HANA?

Dr.Berg: We try to do this as soon as possible so that transport freezes are as short as possible. On some projects we have done this in as little as 2-3 weeks, while others have required substantially more time...


Comment From Gopal

Are there any limitations on the data extracted using ODP data sources in BW 7.4? I read in some articles in SCN that it is suitable for small amounts of data and it's not intended to replace BW, something that handles large amounts of data. Does this change with BW on HANA? If yes, what's the data limit?

Dr. Berg: Hi Gopal,

Great question!! Yes Operational Delta Queues an ODP is intended for faster data loads by grabbing smaller datasets multiple times per day. For batch loading, they also work, but you will have to monitor how large these data queues become. There are some debate on SCN on how big is 'too big', but it depends on record length and datatypes as well as the number of records.
For now, I would use standard BW loads for very large nightly batch jobs, and target the ODP loads for higher frequency and smaller data sets.


Comment From Guest

And what are "HANA-optimized" InfoCubes?

Rob Frye: In traditional InfoCubes, a star schema is created with a fact table, with transactional data in the center and Dimension tables with characteristics connected to the fact table. In HANA-optimized InfoCubes, this process is handled differently. In essence, the dimension tables are no longer created separately as tables in physical space. Instead, a semantic layer is created to provide the same logical structure as in a traditional star schema, without the need to replicate the data into new physical tables.

You can optimize your InfoCubes in HANA through the BW Administrator Workbench, or by using a program delivered by SAP called RSDRI_CONVERT_CUBE_TO_INMEMORY. Using the workbench will require you to manually convert each InfoCube, but the program will allow you to select all the InfoCubes you’d like to convert, and it will usually complete the work within 20 minutes or so. Users can even continue to query the existing InfoCubes during the conversion process, but you’ll need to suspend any data loads during the conversion process.

SAP has more information about SAP HANA-optimized InfoCubes here. Thanks for the question, and I'm sorry for the "wall of text" response!


Comment From Sean

What is MCOS vs. MCOD?

Rob Frye: MCOD stands for multiple components, one database. MCOS stands for multiple components, one system. Depending on the size and complexity of your implementation, you may not need to purchase separate hardware for sandbox and development environments. Instead, you can consider MCOD/MCOS implementations to reduce the costs for hardware and licensing.
 SAP Note 1666670 includes more information about planning for your SAP BW on HANA landscape. SAP Note 1661202 includes information about using multiple applications with a single HANA system. SAP Note 1681092 describes the options for multiple databases on one HANA system. 


Comment From Gopal

Can we do reporting on BW on HANA using third-party reporting tools like Cognos?

Dr. Berg: Yes, you can access HANA views using ODBC, JDBC, or DBSQL directly (you can generate views from DSOs and ICs). You can also access BW queries via MDX as well. Think of HANA as a wide open database that supports SQL scripts and views from a database layer, and from an application layer, it is the BW system that provides access. MDX has been available for a long time and is somewhat slower due to the metatags “overhead,” but the interface is still supported and most third-party tools have this as an option (including Cognos).

Comment From Gopal: Thanks, Dr. Berg.


Comment From Guest

What are "HANA optimized" DSOs?

Dr. Berg: That is a legacy functionality that only applies to BW 7.3. In BW 7.4 we do NOT use them whatsoever, and actually reconvert them back to normal DSOs if any HANA optimized DSOs were created in BW 7.3. See more info in SAP NOTE: 1849498.


DMO Features, Uses, & Benefits


Comment From Junaid

What is the best way to demonstrate the DMO to a potential customer? Do we need licenses at this stage?

Joe Darlak:   No license is required to use the DMO tool—this is included by default with the Software Update Manager (SUM) tool. However, in order to demo a migration, you will need to invest in HANA hardware and perhaps even HANA licenses. You should discuss this with your SAP account manager.


Comment From chaitu

Is there any disadvantage to using the DMO option to migrate BW on SAP HANA?

Rob Frye:  Quite the contrary. There are several advantages to using DMO for your BW to HANA migration. If needed, you can combine several separate projects into one DMO project. For example, some companies did not complete a security or Unicode conversion with their move to BW 7.0, because it was not required. With DMO, those can be combined into the overall migration process, so there's no need to separately plan, budget, and staff multiple projects. The migration, upgrade to BW 7.4, Unicode conversion, and security conversion can all be completed in one project. Thanks for the question.


Comment From Guest

Based on the implementations done so far using DMO, what are common problem areas encountered during migration and after go live?

Dr.Berg: I think we have seen it all — from failed motherboards on large scale-out systems, slow network (recommended 10GB) between servers, hardware falling of trucks (literally :-) and periodic network cable failures (really hard to pin down).
Most of the software issues we find we see in the sandbox migration, when we copy DEV to SB and run the runbook for the first time. The common issues are older designs and incorrect settings in BW, as well as the need for SP or enhancement packages before we can progress.
We strongly recommend a dry-run of production so that these can be found and addressed before we touch PROD. To do so, we copy PROD to QA and do at least one dry-run, and often 2 if we see significant issues.
Unfortunately, the issues we encounter are often a function of how old the BW system is and how much development has been done over the last 16-17 years.


Comment From Ken

What is the current version of DMO?

Rob Frye:  The latest version of DMO is included with SUM (Software Update Manager) 1.0, SP 13.


Comment From Guest

How do I get access to SUM/DMO?

Joe Darlak:  That’s a great question! You should start by downloading the DMO guide called “Database Migration Option (DMO) of SUM for SUM 1.0 SP13”, as well as the guide “Update of SAP Systems Using Software Update Manager 1.0 SP13” from the SAP Marketplace. (Find those guides at -> Software Logistics Toolset 1.0 -> Documentation -> System Maintenance.) See SAP Note 1813548 for details, including prerequisites for using DMO for your migration and other important information.

To download SUM, go to the SAP support page and log in with your SAP Marketplace ID. Choose the INSTALLATIONS AND UPGRADES link, then A-Z ALPHABETICAL LIST OF MY PRODUCTS. Click S, then SL TOOLSET, and then SL TOOLSET 1.0. Click the INSTALLATION link and the ADD TO DOWNLOAD BASKET to make the installation package available for download through your SAP Download Manager program.


Comment From Matt

When is the next version of DMO scheduled for release?

Rob Frye: These usually come out about once every three months, so we expect a new version sometime in June or July. 


Comment From SerkanTumer

Is there any limitation as far as the data size when using DMO?

Dr.Berg:  Hi Serkan,

We just finished a 60TB migration in December and also a 38TB migration last year. The only issue might be the time it takes to export the data files from the old BW system to the new BW on HANA system. We normally see 150-200 GB/ per hour, but with a little performance tuning by parallel loads, adding indexes and splitting tables, we have also been able to increase this data transfer to as much as 580 GB/hour.


Comment From Guest

Can this tool be used to migrate SAP BPC content from a BW on SQL landscape to a BW on HANA landscape? Or should UJBR be used to back up from one and restore to the other? Specifically, I am referring to BPC 10.0 to BPC 10.1, for classic/standard content.

Jesper Christensen: This is a great question. For BPC based on NetWeaver it is possible to migrate using DMO. DMO does require that at least an SP update is executed for one software component, so an upgrade from BPC 10.0 to 10.1 is supported with DMO.
Another option is to migrate the appset using UJBR export/import if you do a clean install of a NetWeaver BPC 10.1 system.


Comment From Guest

I read in SAP note 1813548 that the DMO option is not supported for HANA multitenant database. The only option to migrating to HANA multitenant database is to use the classical migration tool. Is there any workaround aside from using DMO to migrate to a single system HANA database and then migrate to multitenant database?

Jesper Christensen:  Correct, Migration using DMO is not supported if the target HANA system is setup as a multitenant DB. You could migrate to a single tenant DB first and then switch on the multi-tenant DB functionality afterwards on the HANA instance. Great question!


Comment From SerkanTumer

How long does the upgrade/migrate process (without Unicode conversion) take for ~5TB database when using the DMO tool?

Rob Frye:  This is a deceptively simple-sounding question, and it really requires the stock consulting answer…it depends.
Rather than leave you hanging with that answer, let me clarify that a little.

The length of your HANA migration project will vary based on several factors, including the size and complexity of the source system, the number of functional areas that must be migrated and tested, the number of environments in your system landscape, and whether or not certain mandatory tasks, such as Unicode and security conversions, have been completed in previous projects.

In general, you can probably complete a small migration (5 TBs of data or less) with low complexity in roughly 12-14 weeks. Medium projects (5-10 TBs of data) with low to medium complexity will usually take 18-22 weeks. Large and extra-large projects (10 TBs of data or higher) with medium to high complexity and multiple functional areas may require 6-10 months to complete, or even longer.
Be aware that these are general guidelines, but the actual time will vary depending on too many factors to cover in one Q&A session… Thanks for the question!

Comment From SerkanTumer: Thank you.


Comment From Kathy

When executing the Migration Checklist, we received several items with a red status. Do all items with a red status need to be resolved before executing DMO?

Jesper Christensen: The items with RED status should generally be addressed before migration. Some of these — like failed data loads and failed DSO activations — can be ignored in non-production systems but must be addressed in production. Yellow items are not as critical, and will not cause serious issues post-migration.


Comment From Sudhir Makkar

What is the key difference between inline, DMO, and PCA migration from timeline, work effort standpoint?

Joe Darlak:  Sudhir, this is an excellent question. First, it is important to understand the migration approach and use of DMO are mutually exclusive. Let's cover the migration approaches first, then we'll cover how DMO fits in.

Depending on the size of the BW system, there are two basic approaches which can be followed:

1.    In-place migration

2.    Downtime-minimized migration

For smaller databases, usually less than 10 TB, the in-place migration is the simplest, most efficient and most economical approach.

In the downtime-minimized approach, a database copy of the system to be migrated is restored on interim hardware. It is the copy which is migrated to SAP HANA, thus minimizing the need for an outage in the original system.

To keep data loads in-sync with the original system, all delta queues are cloned using the SAP post-copy automation (PCA) tool, which is available with SAP Landscape Virtualization Management (LVM). Sync points are set before the database copy so data can be extracted from the cloned delta queues after the migration. When the data loads are caught up, users are then transitioned from the original system to the new system.

With a migration approach decided, it is time to dive into the detailed migration procedures available. The specific tactics employed to migrate an existing database to SAP HANA will depend on the other activities or factors which are part of the objective, such as:

•             Extra-large migration (legacy database > 50TB)

•      Upgrade to SAP BW 7.40

•      Unicode conversion

If the legacy database is larger than 50 TB then an XXL migration service from SAP may be worth consideration. The XXL migration service is a customer specific process tailored by SAP professionals for each customer’s needs.

To operate SAP BW on HANA, the minimum version required is version 7.30 SP05. The latest version of SAP BW is 7.40 SP10. If there is no need to perform an upgrade as part of the migration, then a classic OS/DB migration is the appropriate tactic.

However, if an upgrade to SAP BW 7.40 is also required (or an update to a later support pack if you are already on SAP BW 7.40) and/or a Unicode conversion is required, then a migration using DMO for SUM is the best tactic.

Comment From Sudhir Makkar: Thanks much, Joe, for detailed explanation.


Comment From Lovnish

If no upgrade of BW is involved, do you still advise using DMO instead of a classical migration (using SWPM) approach?

Jesper Christensen: SUM DMO requires at least one software component to be updated. A support package is enough so an upgrade is not required.
The benefit of using DMO is that the data migration is performed using memory pipes, which is also possible with SWPM but generally not used for most migrations. In addition DMO also provides a downtime minimized option (not for SAP BW tables), which can greatly minimize the downtime for the migration. See more details on this option here.


Comment From Sudhir Makkar

Does the migration process (using DMO) change based on hardware used — IBM gear or HP or third party — in terms of unforeseen issues, timeline, etc.?

Joe Darlak: Makkar, great question. First, use only HANA suppliers and configurations which are certified by SAP and list in the PAM. If no hardware configuration listed in the PAM fits your needs (due to size constraints, etc.), you can request special certification from SAP, but you need to have the hardware in place before they can certify it.

Regardless of which supplier or configuration you choose, there is always the possibility some component of the hardware could fail. It is extremely important to test your actual production hardware prior to the production migration. We strongly recommend planning a "dry run" migration cycle — migrate a copy of production to the production hardware and "smoke test" the hardware to ensure there are no bad components which can affect performance or stability.


Comment From John

With nearly all calculations and processing moving to in-memory on HANA, is there any need for an App Server layer when running BW on HANA? And if the App layer is required, what would it be for?

Joe Darlak: John, this is a great question.
Last year, SAP introduced support for installing the ABAP Application Server on the HANA appliance. The limitations are:

• This only applies to single-node appliances (although a standby HA node is supported).

• There must be enough memory on the appliance to support the ABAP AS.

• The HANA revision must be SPS07 or higher.

• SAP BW must be 7.40 or higher.

So you can install ASCS/ERS/PAS on the HANA server and support an HA node. This is available as of SAP HANA SPS7 for single node installation and products based on SAP NetWeaver 7.4.

Please refer to SAP note 1953429 - SAP HANA and SAP NetWeaver AS ABAP on one Server.

Comment From John: Thanks Joe. So in essence you don't need AS ABAP when running BW on HANA?

Jesper Christensen: John, the AS ABAP is still required, but it can be installed on either the HANA node in a single node system or on a standby node in a scale-out HANA system.


Comment From John

If you have created a copy of your BW system via DMO and you need to sync the data and delta loads after the fact, how do you go about that?

Joe Darlak: John, If you choose a downtime-minimized migration approach, you will clone your delta queues using SAP Post-Copy Automation (PCA) on the source BW before taking a copy of it. PCA will clone the delta queues in all connected SAP systems and take a sync point.
After the DB copy of the source BW is restored to an interim BW system (different SID), you will connect to the cloned delta queues in all the source systems to extract only new data which was not extracted prior to the DB copy. You can easily keep both BW system in-sync this way.

After the interim BW system is connected to the cloned delta queues, then you will migrate it to HANA using SWPM (if no upgrade/update) or DMO (if upgrading/updating). The resulting target BW system on HANA will retain the same SID as the interim system and will still then be able to continue extracting from the cloned queues.

When all delta queues have been caught up in the HANA system, and results have been verified, you can decommission the original BW system and delete the original queues in the connected source systems.

HANA Migrations, Sizing, and Performance


Comment From chaitu

Any performance issues during migration?

Joe Darlak: Chaitu, there are many factors which impact performance during migration.

First, it is extremely important to test your actual production hardware prior to the production migration. We strongly recommend planning a "dry run" migration cycle — migrate a copy of production to the production hardware and "smoke test" the hardware to ensure there are no bad components that can affect performance or stability.

Second, network bandwidth between the source BW on the legacy database and the target BW on HANA should be 10Gbps or higher. If the systems do not share the same VLAN in your data center, this could also be a problem.

Third, the number of cores and memory capacity of your source BW will limit the export performance of the migration. If you adopt a downtime-minimized approach, be sure to size your interim hardware appropriately.

Comment From chaitu: Thanks, Joe Darlak.


Comment From Satya

After database migration, what % of performance improvement we can expect with database optimization technique for database size of 10TB?

Joe Darlak:  Satya, from our experience with BW databases of 10 TB, we see data loading performance improvements of up to 40% simply by migrating to HANA without any LSA optimization. From a reporting perspective, we see queries run 16X faster, on average.


Comment From Guest

Any advice on sizing the HANA system?

Jesper Christensen:  That’s another great question! There are several methods for sizing a HANA system, including the T-shirt sizing model and the rule-of-thumb sizing approach, but the preferred method (and the most accurate) is to use the SAP BW on HANA Sizing Tool, which is included in the SAP NetWeaver BW Migration Cockpit for SAP HANA. You can find the complete instructions for downloading the ABAP code for the migration cockpit in SAP Note 1909597.

For Business Suite on HANA sizing, see SAP Note 1872170.


Comment From Guest

With HANA, are there changes needed in ETL programs?

Rob Frye: Good question. Some transformations can actually be slower in HANA than in legacy BW systems. If you encounter these types of problems, you can improve the performance with HANA hints in the ABAP code (SAP Note 1662726) or by deleting the filter in the SQL Statement and executing the filter in the ABAP engine from unfiltered data returned by HANA (SAP Note 1740373). Thanks for the question!


Comment From Pradeep Gopalakris

Is there a performance impact on the ECC (Oracle) system when using SLT (DMIS add-on) to replicate data from the ECC system to HANA? If there is a performance impact, do we have an alternative solution?

Jesper Christensen: There is a slight performance impact, as the replication runs jobs to transfer the data to the SLT server. From our experience the impact has been minimal, as the transfer  is very quick and the amount of data records is limited if replications take place every 10 seconds.
In one project we analyzed the impact in detail; the impact was that less than 1% of the ECC system resources was used for replication.


Comment From Guest

Can we virtualize the hardware with a HANA implementation?

Rob Frye: The answer is, yes, there are several providers of HANA in the cloud such as Amazon Web Services, Virtustream, IBM, HP, and of course SAP with their HANA Enterprise Cloud Offering.


Dr. Berg: One quick note on performance:
For the past 7 months my team has been part of a very large HANA migration for a Fortune 100 company. This total migration moved almost 60TB of data into a BW 7.4 on HANA environment, which we then benchmarked against the legacy system. The previous system was standard BW 7.3 on Oracle. Comparing results between the systems provided us a clear indication of the HANA system benefits:

>> BW on HANA Query Performance vs. Oracle - 13.9 times faster

Over 75 queries were tested across 7 different business areas and we found that the HANA system was an average of 13.9 times faster than the legacy Oracle system. The average run time across all queries was brought down from 162 seconds on Oracle to just over 15 seconds on HANA.

Certain areas that were tested revealed improvements that well surpassed the average. We noted certain examples of very large queries taking over 10 minutes to run on Oracle that were executed in 1 second or less on HANA (nearly 700x faster).

The majority of the query performance came from the data manager which was 28x faster at query runtime when compared to Oracle. OLAP processing time was also cut in half on HANA.

>> BW on HANA Data Load Performance vs. Oracle - 52% faster

Several hundred data load jobs were also tested during this benchmark. No changes were made to the data loads going into the HANA environment.

We saw an overall performance increase of 52% for data loads into HANA vs. the Oracle environment. Significant improvements were found in the data activation portion of the loading process with some activations being performed over 250 times faster than their Oracle counterparts.

As an example, the financial stream realized an 85% improvement in total data load times with a large portion of that improvement coming from the data activation stage.

>> Summary

Overall these numbers represent a significant improvement across the board. The HANA system tested here outperformed the Oracle system in every metric we tested it against with some of the best results to date (Query performance that is 694x faster in some cases).


Rob Frye: Thanks so much for joining us today. We've really appreciated the opportunity to answer your questions.


M.S. Hein: Thanks to everyone for joining us. You can review this Q&A at any time. The chat replay will be posted here on Q&A page and I’ll alert you when the transcript is ready. For more from the COMERIT team, you can review Dr. Berg’s BI Expert articles, including “SAP HANA Performance Monitoring Using Design Studio”, with Michael Vavlitis, which is also included in the BI Experts anthology “Enhance Your BI Reporting Skills.”


Dr.Berg: Hi Guys, Thanks for joining. More step-by-step details are in our book on Amazon.

Joe Darlak: Thanks everyone for the great questions!

Jesper Christensen: Thanks to everyone that joined us today and good luck with your DMO migrations!

All New Content for October on the SAP Customer IT Hub!
Get quick and easy access to the wealth of knowledge, resources, tools, support and services that are available to all SAP customers.

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!