Technical Articles
Tools to Support Migrating BW Systems to SAP HANA
The content of this blog has been move to SAP Note 1909597.
For more details, see “Tools from SAP BW/4HANA Product Management“.
Best,
Marc Bernard
@marcfbe
Read-only Alert
SAP Community Groups will be in read-only mode from 2AM EST/ 8AM CEST on Saturday April 1st until 2:15PM EST/8:15PM CEST Saturday April 1st. During this time no engagement activities will be available on SAP Community Groups.
Hi Marc,
if possible, could you please briefly comment on any of these resources and for which cases they'd be applicable?
Thanks,
Henrique.
Hi Henrique,
blogs about the tools are work in progress but you can find detailed documentation in the linked SAP Notes already.
Best,
Marc
SAP Customer Solution Adoption (CSA)
I know I do, I just wanted to say, politely, to increment your document because it is too poor right now. 😛
Hi,
See also the Blog
http://www.saphana.com/community/blogs/blog/2013/05/03/upgrade-and-migration--bw-on-hana
Best Regards Roland
Thank you Marc. It's good to follow your updates in one location !!
Regards,
Rajiv
Marc,
I have some questions on the details of how source DB compression is taken into account for the SAP HANA Sizing Program.
Background:
Client has SAP BW 7.0 EHP 1 on MS SQL server 2008 SP3 (Build: 2766 / 10.00.5500) running on MS Windows Server 2008 on Itanium platform.
The initial size of the database was 3TB which came down to 878 GB after two rounds of compression. First the database was compressed at page level which brought the size down to 1.6 TB and second compression was performed at row level that brought the data base to the current size (878 GB).
In the process of sixing for migration to BW on SAP HANA, the HANA sizing tool /SDF/HANA_BW_SIZING (Note: 1736976) reported the total size of 1.6 TB.
Questions:
1. Which compression did HANA sizing report took into consideration?
2. Does the HANA sizing report take both the DB compression steps into account while
calculating the target instance size?
3. Should the numbers reported by the HANA sizing report be extrapolated taking into
account the second compression or should the numbers reported by the sizing
report be considered as is?
4. How is the DB specific compression factor determined?
The key question is if we should consider the target instance size specification as is or should we extrapolate the proposed size of the instance to take into account the second DB Compression. If the latter is true, is there any guidance provided for
extrapolation of the target instance size.
Thanks.
Deepu
Hi Deepu,
1) The sizing program ignores the compression of the source database because it samples the actual data in an uncompressed format. So no matter how much the existing database is compressed the sizing result will be the same.
The program then applies a compression factor to each table which is based on the type of table (i.e. it's usage within BW) and an average factor that is based on customer experience with real BW on HANA systems.
2) See 1.
3) No. The result of the sizing program provide the total amount of physical memory for the SAP HANA appliance.
4) See 1.
In summary, you just need to run the program and do not have to do any other calculations.
Regards,
Marc
SAP Customer Solution Adoption (CSA)
Very informative - Thanks Marc !
Rama Shankar
Hi Marc,
thanks for these Tools.
Could we use them for a HANA migration + BW 7.5 upgrade?
BR
Loïc
Hi Loïc,
yes, all of the tools work with SAP BW 7.5 or upgrades to 7.5.
Best,
Marc
Product Management SAP HANA DW
OK great!
Thanks for the fast answer.
BR
Loïc
Hi Marc, Roland,
we have upgraded to BW7.5 recently followed by the migration to HANA.
We ran the the upgrade and the migration in classic mode without DMO.
But we have used the Tool ZBW_HANA_MIGRATION_COCKPIT for the pre- and post - checks, which in fact includes all the other tools / notes mentioned here.
The tool is very, very, useful and following all the discussions in scn, would have answered a lot of them.
From my point of view the Migration Cockpit should be the point of truth and should be the entry point in SCN for all necessary tasks related to upgrades and migrations.
But actually , all these information are a bit randomly distributed in scn.
Wouldn't it makes sense to have one scn page for the migration cockpit , which in detail explains all the steps offered in this tool?
Also , here some feedback rgd. the cockpit:
ASU Tool Box, should recognize the system version and should only provide the notes being valid.
ASU Tool Box, should be enhanced for HANA, like RS_BW_POST_MIGRATION, etc.
ASU Tool Box, should provided option to export a task list, after I have added my own tasks, and be able to import this list to another system.
HOUSEKEEPING Should explain why do I need to run housekeeping list SAP_BW_AFTER_MIGRATION against program RS_BW_POST_MIGRATION
ABAP Code Inspector, should have the check of the RANGE change from char to string before the upgrade to estimate the effort.
Checklist Tool, We have got a red flag for the connection check, while our connection string had 11 digits and the code is copying it to a 10 digit field, which raised the error, as the 10 digit connection could not be opened.
Regards, Ralf
Thanks for the feedback, Ralf!
I agree that the infos on SCN could be better organized. As you might already know, much is being moved to SAP.com and we will try to do a better job there.
I will pass on the feedback about ASU Tool Box. Housekeeping is always an optional (but recommended) task. Generally, we would like to automate this as much as possible but customers have different requirements as to what and how long certain data must be kept. RS_BW_POST_MIGRATION is sufficient for classical (non-DMO) migrations.
I don't understand the point about Code Inspector. Maybe you send me a message with more details.
You are right about the connection check. I will work on a fix for the next version.
Best,
Marc
Product Management SAP HANA DW