How do you properly prepare your SAP NetWeaver BWsystems for an SAP HANA migration? What specific checks, tools, and sizing techniques can help?
Dr. Bjarne Berg, a speaker at BI 2013 and co-author of the book SAP HANA: An Introduction, took questions from his readers and Insider Learning Network members on March 7, moderated by Bridget Kotelly, BI 2013 conference producer.
The questions on preparing and sizing BW in preparation for SAP HANA covered topics such as InfoCubes, HANA Views, HANA architecture & the relationship between BW and HANA, data cleanup with HANA, along with Berg's top list of 300 (yes, 300!) key HANA notes.
Bridget Kotelly: Welcome to today’s Forum!
I’m very pleased to have Dr. Bjarne Berg of Comerit here, monitoring the forum thread & taking your questions on migrating SAP BW to SAP HANA.
For those who don’t know Dr. Bjarne Berg, he is a BI expert, author, consultant, professor, and long-time speaker at our BI conferences. He’ll be in Las Vegas at BI 2013, in just a few weeks presenting a number of sessions on BW, HANA, and dashboard performance.
Berg is also the co-author, with IBM’s Penny Silvia, of the bestselling book, SAP HANA: An Introduction.
Welcome, Dr. Berg!
tomSikora: Past inquiry has stated that info objects are implemented in HANA as "flat tables". That is, (for instance cubes) are loaded into single table that have the facts a
nd dimension as one record with the data duplicated at the detail level.
- Is there, therefore, redundancy of data if (since) BW is not structured as master-fact (with or without the notion of a mart)?
- When are BW transformations to become HANA views - so that the stored data manipulation becomes virtual and maintains its detail storage uniqueness?
- Are the "standard content" extractors evolving to use SLT (and become real-time)?
- How can native HANA applications easily use data loaded from BW extractors (master and transactional)?
- Why use Data Services if DB Connect works? (Transformation realized, but is that enough justification?)
- Is there cause to actually load data into a physical table to be used by subsequent views as opposed to simply create it as a virtual table via a view? (The philosophy of interim physical table in HANA.)
Dr. Berg: Hi Tom,
Lots of great questions here. Some of it depends somewhat on whether you have optimized your InfoCubes.
Dimensions in InfoCubes are actually not stored the same way as in ‘traditional ICs’, instead the cubes are ~flattened. The core of the new SAP HANA-optimized InfoCube is that when you assign characteristics and/or key figures to dimensions, the system doesn’t create any dimension tables except for the package dimension. Instead, the master data identifiers (SIDs) are simply written in the fact table, and the dimensional keys (DIM IDs) are no longer used, resulting in faster data read execution and data loads.
In short, dimensions become logical units instead of physical data tables. The logical concept of “dimensions” is used only to simplify the query development in BEx Query Designer.
nvert existing InfoCubes, simply go to the program RSDRI_CONVERT_CUBE_TO_INMEMORY and select the InfoCubes you want to convert. After the conversion to SAP HANA, optimized InfoCubes are maintained in the SAP HANA database’s column-based store and are assigned a logical index (CalculationScenario).
For the HANA Views, these are easy to build on reportable DSOs, but somewhat harder for Infocubes where you may have 50-70 table joins for large cubes with 16 dims. So the preferred way to access data in BW on InfoCubes are still through BEx queries. But some views can also be built on DSOs (may require more work for links to masterdata).
For ‘standard’ SLT extractors, some exists, but there is no massive rewriting of the existing PI plugins. There are however, work underway for RDS and mart solutions.
For “How can native HANA applications easily use data loaded from BW extractors (master and transactional)?” You will have to become somewhat creative. I would look at DSOs, OpenHub and possibly queries.
You can also create your own ‘native’ DSOs that you feed using standard BW functionality (these are basically simple tables anyway). With optimized DSOs you get the same benefits as ‘native’ HANA Tables.
The cool thing is that you can also ‘optimize’ you existing DSOs. When converting exiting DSOs, you can either convert them automatically using Transaction RSMIGRHANADB, or you can do this manually in the Data Warehousing Workbench. This migration doesn’t require any changes to pro-chess chains, MultiProviders, queries, or data transformations.
For Data Services, take a look at my deck from TechEd conference and you will see why Data Services is a better tool.
So lots of great questions here, Hope this answer most of them
BridgetKotelly: Berg, I see some early posts, so I'll let you get to those first, but I would like to make sure you address architecture basics with HANA.
When you talk about “HANA migration” with a running BW system, are there scenarios where you see companies running BW moving data completely off of BW and onto HANA? We still see questions from some conference attendees about where BW ends and HANA begins.
Dr. Berg: There are basically 3 options for moving BW to HANA:
1. Migrate your entire SAP NetWeaver BW system to SAP HANA.
2. Set up a new SAP NetWeaver BW system (with an SAP HANA database) alongside your existing BW system and use that new BW environment for particularly challenging or new requirements. This is known as a side-by-side or sidecar installation, and often requires a partial migration of BW transaction data and complete replication of most master data.
3. Implement a BW system for the first time, and then run SAP HANA for it.
In option 1 and 2 you can also include optimized Infocubes, DSOs and “HANA hints” on transformations and lookups, or leave these as-is for now.
For those starting out I would look at these key notes:
- 1639744: Heterogeneous System Copy NetWeaver 7.30 to HANA target DB,
- 1657994: SAP BW 7.30 powered by HAN
A - Special SP06
- 1715048: BW 7.30 new features for installation or migration.
A bit more on relationship between BW and HANA:
I would think of HANA as a database and BW as the 'brains' to manage data, model and presenting data in a meaningful way to users.
A question that comes up often is: Is BW dead? Why not use HANA instead of BW?
As of January 10, 2013, SAP said it supported the deployment of their ERP Business Suite on HANA. The solution requires enhancement pack 6 for SAP ERP version 6.0 and ABAP AS version 7.4, which was made available at the same time.
This raises many questions about the future of traditional On-Line Transaction processing (OLTP) and separate On-Line Analytical Processing (OLAP) such as data warehouses. Is there really a need to separate the reporting from the transaction processing?
The answer depends on the time horizon you are planning on. In the short run, there are simply too many valuable models in BW, APO, Business Planning and Consolidation (BPC), Integrated Planning (IP) and all the other DW-based tools to throw them all away. However, these tools also have several Achilles’ heels: they are not truly real-time and require separate infrastructure and data movements.
In January, SAP's Vishal Sikka wrote in his blog: “With the collapse of OLTP and OLAP in one platform, there is a massive simplification on the way.” There is naturally a lot riding on this vision and a substantial amount of development must take place to organize the data in the OLTP system in a way that is designed for reporting.
I can see that some operational version of this can be done in th
e future through separate HANA reporting tables in the ERP system (much like what we used to have with EIS, SIS, LIS in the early days of ERP), or by creating views on the data using HANA Studio, XS or other tools.
However, for the foreseeable future, I believe SAP BW provides an integrated platform for model-driven analysis on data that needs to be preserved at the time of transaction, integrated with external data, and which contains the corporate ‘memory’ of what happened in the past. So, the vision of an integrated BI and ERP system on the same platform is just that; a vision. Technically, it is not possible to install BW and ERP on the same HANA system today.
There are a lot of people wanting to skip the model-driven approach and go straight to ERP for analytics and BI. For those it is important to be reminded that there is a reason why the models were built in the first place. It was to simplify reporting and provide a business view to cleansed, integrated and often transformed transactional data to provide meaning. This is not found in a transactional table.
So we may get there, as Vishal stated in his blog, but there still a long way to go.
SAP BW is still an integral part of the data warehouse landscape for many years to come, and with HANA there are even more benefits to keep it around a while longer.
baudouindupriez: We will implement BW on HANA this year (HW scheduled for June). We will have two HANA boxes with a three-BW system landscape (Dev on HANA-dev, QAS on HANA-dev, Prod on HANA-prod).
I am wondering if the HANA settings have to be transported or must be done in each systems -- knowing that we are advised to start the migration with our production system
and then roll it back to QAS and finally Dev?
Dr. Berg: Hi baudouindupriez
Good questions. SAP has created a great pre-check program that you should run to check if your BW system is ready to go to HANA. I wrote a blog about this a couple of weeks ago where I show some examples from the latest release.
The tool was written by Marc Bernard from SAP Canada and he did a great job on automating these checks. I know he is working on adding more functions to the tool (see comments at the bottom of the blog), but the current release 2.04 has all the key elements already.
If you are planning a BW to HANA migration, this program is a must…
After running this program, you will get a list of what needs to be done for a BW to HANA migration
1. Is it possible to eliminate the Application layer using HANA?
2. What are the operating system versions does HANA device come in?
3. Let’s say that I migrate my whole database now to HANA. After couple of years, due to space contraints, I want to migrate some unused infocubes to the DB2 database. Is it possible? If so, what are the high-level steps to be followed?
Dr. Berg: Hi Balaji,
1. First, yes, that is possible, but not realistic with a BW system. There is simply too much to rebuild, so the app layer stays with BW.
2. The only OS for HANA at the DB level is Linux.
3. For too much data, I would use NLS instead of moving cubes to
DB2 (both are supported and possible).
naveen ketha: When implementing BW on HANA, customers have a decision to make whether to choose BW on HANA edition or Enterprise Edition. Do you see significant ROI or value to go for Enterprise Edition when compared to just BW on HANA edition?
I know answer to above question depends on many factors, but based on your experience, what’s the trend you are seeing with customers and why?
Dr. Berg: The key is actually what you get when buying HANA. While HANA is sold as an appliance, there are many software components installed. These vary a bit depending on what edition of HANA you bought (platform, enterprise and extended enterprise with sybase components).
I would recommend the enterprise edition to most clients and only the platform to companies who don't want items such as data services. So the default should be 'enterprise'.
For example, there are over 40 different software components from SAP alone. This includes clients, lifecycle management components and the software inside the main editions (platform and enterprise). The main list of components includes:
- HANA unified installer (BC-HAN-SL-STP)
- Software Update Manager (BC-HAN-UPD)
- HANA database installation (BC-DB-HDB-INS)
- HANA database upgrade (BC-DB-HDB-UPG)
- HANA Direct Extractor Connection (BC-HAN-DXC)
- Data Services: ETL-based (EIM-DS)
- HANA Load Controller: log-based (BC-HAN-LOA)
- Landscape Transformation (SLT): trigger-based (BC-HAN-LTR)
- Sybase Replication Server: log-based (BC-HAN-REP)
- HANA database (BC-DB-HDB)
- HANA database engine (BC-DB-HDB-ENG)
- HANA database persistenc
- HANA database interface (BC-DB-HDB-SYS)
- HANA database/DBA cockpit (BC-DB-HDB-DBA)
- HANA DB Porting (BC-DB-HDB-POR)
- HANA Backup and Recovery (BC-DB-HDB-BAC)
- Host agent (BC-CCM-HAG)
- HANA CCMS (BC-DB-HDB-CCM)
- HANA Clients (JDBC/ODBC) (BC-DB-HDB-CLI)
- HANA Integration with R (BC-DB-HDB-R)
- HANA SQL scripts (BC-DB-HDB-SCR)
- MDX engine: Microsoft Excel client (BC-DB-HDB-MDX)
- HANA Studio - Information Modeler (BC-HAN-MOD)
- Information Composer (BC-HAN-3DM)
- HANA UI toolkit (BC-HAN-SRC)
- HANA Text and Search features (BC-DB-HDB-TXT)
- HANA Direct extraction connector (BC-DB-HDB-DXC)
- HANA Security and User Mgmt (BC-DB-HDB-SEC)
- HANA Application Services (BC-DB-HDB-XS)
- HANA Advanced functions library (BC-DB-HDB-AFL)
- HANA Predictive analysis library (BC-DB-HDB-AFL-PAL)
- HANA Sales & Operations Planning (BC-DB-HDB-AFL-SOP)
- HANA Planning Engine (BC-DB-HDB-PLE)
- BI Platform (BI-BIP-CMC, BI-BIP)
- Web Intelligence (BI-RA-WBI)
- Dashboard Designer (BI-RA-XL)
- Crystal reports (BI-RA-CR, BI-BIP-CRS)
- BusinessObjects Explorer (BI-RA-EXP)
- Information Design Tool (for universes) (BI-BIP-IDT)
- Microsoft Excel add-in (BI-RA-AO-XLA)
Balaji Rajendran: Could you provide backup/restore documentation for SAP HANA database?
Dr. Berg: Hi Balaji,
HANA can have synchronous backups between your production system and the backup storage. You can even have a standby system that receives dat
a continuously and use this as a ‘warm’ standby system that is ready to kick in if the primary system goes down for any reason.
Finally, you can have standby hosts ready to take over is a host inside your system has issues. The latter is referred to as fault tolerance recovery
There are two basic ways of backing up data in HANA: There is the traditional file backup that has been supported since version 1.0 and the newer BACKINT application programming interface (API) that provides support for certified 3rd party vendors.
Since this feature is found only in service pack 5, some older installations may be required to apply this to take advantage of the backup and restore features of other vendor solutions.
Since many backup features are now automated, you no longer need to run the program “ALTER SYSTEM RECLAIM LOG” after every backup to check that log segments were removed. Instead, you set ena-ble_auto_log_backup to “yes” and the log_mode to “normal”.
This is a long topic, deserving much more details than we can cover in this Forum. Right now, I am working on adding even more detail recommendations for settings of the 4 basepaths for the backups, so stay tuned (or see me at the “ask-the expert” session at BI 2013).
Bridget Kotelly: For those who have never been to our BI conferences , we always have an "Ask-the-Expert" session where you can meet in person with speakers to ask your specific questions.
At BI 201
3 this year, Dr. Berg will be there Wednesday, March 20th, 6:15 - 7 pm.
Berg: [Responding to reader David’s question on getting started with HANA]
There are many ways to get started. You can read my book :-) join me at my session at BI 2013, or start reading SAP notes and Guides.
There are hundreds of notes relating to SAP HANA and the releases. However, for those starting out, I recommend downloading and reading core 9 notes that will get you started. This includes:
- 1514967 SAP HANA: Central Note
- 1018839 Admin (HANA)
- 1514966 Sizing SAP HANA Database
- 1523337 SAP HANA Database: Central Note
- 1598623 Security
- 1599888 SAP HANA: Operational Concept
- 1637145 SAP BW on HANA: Sizing SAP HANA Database
- 1729988 SAP BW Check for HANA Migration
- 1736976 Sizing of BW (Using an ABAP Report)
RonaldKonijnenburg: Lately I see vivid discussions on hot, cold, semi hot, lukewam (and everything in between) data.
Any tips on how to determine what is the most optimal mix (required for good sizing)?
Dr. Berg: Hi Ronald,
The question is 'what can you afford'. I am working on a very large HANA project now, where we keep 72TB of data on Near-Line Storage
(NLS) and 'only' 36TB on the BW system.
We are moving the 36TB to HANA, but leaving the 72TB back on NLS and saving quite a stash of money by doing so.
I am very much in favor of a cleaned BW system and NLS for non-hot/lukewarm (?) :-) data. However, it all depends on how you have partitioned the data and how many need access to old data.
If you have hundreds of those users, the size of the NLS system has to be large and the savings may be minimal.
But for most, NLS and BW on HANA should be the future (BTW: SAP now also has its own NLS solution based on IQ).
RonaldKonijnenburg: Thanks! Guess a good solid review of the BW statistics should give a good starting point.
Thanks again. Picked up quite a bit of new info.
Bridget Kotelly: Thanks again to all who joined us today - and for sharing your questions!
A big thanks to Berg not only for taking these questions but for all that great info.
And again, I invite you to meet Dr Berg in person at BI 2013 in Las Vegas. He'll be at Ask-the-Experts, answering attendee questions one-on-one, as well as presenting a far more detailed session on this BW for HANA topic, plus sessions on benchmarking BI , dashboard sizing and BEx tools.
Follow me @BridgetKotelly for the latest updates on the conference. Hope to see you in Las Vegas!