Year of the Upgrade - tips and tricks for a BI upgrade

[Former Member]

Following on from my last blog "2010, The year of the upgrade", I've decided to include some more detail on some of the SAP products I'm seeing being upgraded most right now.

I'm going to start with BW, and the upgrades I'm seeing most of so far this year are BW 3.x to 7.0. Because the BW 7.2 release has now been postponed until BW 7.3, which is projected to go into RampUp in H1 2010, there is even more of an impetus to upgrade to 7.0 now and consider 7.3 in future.

I think there are a few good drivers to this:

1) I think that BW 7.0 came of age in 2009. It matches the stability of the 3.x product set and new features are being introduced without reducing platform stability. With this comes the EOL for BW 3.x and the maturity of the upgrade tools including the CUC.

2) The BOBJ acquisition has now got a fairly stable roadmap, and SAP NetWeaver BW is well and truely part of the future vision of Business Intelligence. The BEx toolkit support has been extended and the Pioneer product will be built out on top of BW. This is especially relevant to customers who are using Webi on top of BW 3.x because it is a tacit admission that the SAP Integration Kit layer isn't going to replace the RFC platform that BEx users for the middleware layer.

3) Ss we come out of recession, organisations want better line of sight BI through the organisation, and as a result they are looking to invest in the BI platform. Upgrades are often forming the first phase of a larger BI investment.

4) Many BW 3.x platforms are built on ageing hardware and are slow. I'll talk in some more detail later on about how BW 7.0 can resolve performance problems.

If you are considering an upgrade then you first need to understand the drivers for the upgrade as this will affect your strategy.

1) Performance

If performance is your largest driver then the benefits of BW 7.0 are unlikely to disappoint.

a) The Business Warehouse Accelerator (BWA, formarly known as BIA) is the silver bullet for many organisations and in large data warehouses can be the single reason to upgrade. If you use transaction ST03N and look at the BW Workload, you can see where the time is spent in a BW query. If it is spent at the database level then BWA can help you. It's not uncommon for database time to be 90% of total. If however the time is spent in the OLAP or front end then you should consider BWA more carefully and how your queries are written.

b) BW Request Archiving

Every time you perform some sort of BW data load (PSA/DSO/Cube etc.) then you write to the BW request tables like RSMONMESS. If you go to DB02 then select the "Largest Tables" option (depends on your DB platform) then look out for large tables starting in RS. It is not unusual for these tables to become very large (80Gb is the largest I have seen a RS table).

This can also be visible by the BW data loads slowing down. If you run a ST05 trace then you will see large numbers of hits to the RS tables which are taking a long time. BW7 permits these large tables to be archived in transaction SARA which can dramatically improve performance.

Note 706478 - Preventing Basis tables from increasing considerably

c) BW7 data objects

It is possible to rewrite your data flows using BW7 concepts such as DSOs and Transformations. This typically speeds up data flows by 25%, although if your loads use poor quality ABAP routines then you can do things like move ABAP code into the start routine and get even large performance increases. For long running data loads, this can be much appreciated.

d) BW 7.0 tools for performance

7.0 brings a number of tools that can benefit performance and they are well documented. Especially if you run queries by characteristic 0CALMONTH or 0FISC_PER, can you get the benefits of online repartitioning. Similarly the online remodelling capabilities are neat for remodelling InfoProviders on the fly.

e) Hardware

Last but not least is hardware. If you are planning to upgrade BW and it is on old hardware then there is the opportunity to purchase new hardware at the same time. BW system copies can be performed at the same time as the upgrade and performance can be much improved, whilst keeping within hardware support.

2) Support

If moving back into support is your largest concern then there are a few obvious points.

a) Support for BW 7.0

BW 7.0 is currently set to be supported until 31.12.2015 wtih extended support until 31.12.2017. Support for BW 7.3 has not yet been announced but general availability is likely to be some time in 2011, which means that there is an expectation that support would be beyond 2015.

b) Support for Gui components

SAPGui 6.40 went out of support some time ago and 7.10 is the current version. However even given this, 7.10 is built on Visual Studio 2005 which goes out of support in April 2011.

Even still, SAPGui 6.20 remains in support until 31.12.2010 although it is not supported in BW 7.0.

Therefore SAPGui 7.20 is coming which is built in Visual Studio 2008 and will therefore go out of support in April 2013. Planned shipment is in March 2010. 7.20 provides support for Office 2010 and Windows 7, although 7.10 does already provide support for Windows 7 on the latest version.

See Note 147519 - Maintenance strategy / deadlines 'SAP GUI' for more details.

b) Hardware / DB Support

BW 7.0 supports a wide range of hardware components. Some 32-bit platforms are conditionally supported but my recommendation if you are running 32-bit hardware is to always migrate to 64-bit hardware.

On Oracle and MSSQL this is straightforward - the database files are compatible on most hardware platforms.

Oracle 9i is no longer supported on BW 7.0 and therefore you must upgrade to Oracle 10g before upgrading BW, which is supported until 31.07.2011. Oracle 11g support is coming, planned for H1 2010.

MSSQL is relatively flexible on BW 7.0, although I would strongly recommend running Windows 2008 x64 (not R2!) and MSSQL 2008, because of the row level compression capabilities that it provides - see Note 991014 - Row Compression/Vardecimal on SQL Server.

Linux, HP-UX, Solaris and AIX support is fairly flexible and in most cases not very different to BW 3.x in support terms. Hardware support is

3) New Projects

People talk a lot about building a "Platform for the Future" and this is a phrase that I personally really enjoy. It is not uncommon for a BW upgrade to be as a precursor to a future body of work.

Given this it is not unusual to plan out 3 workstreams - an infrastructure workstream which will build out the hardware (and migrate the database), an upgrade workstream which will perform the in-place upgrade, and a project workstream which will take advantage of this.

The benefit of this is that by using a POC approach, the 3 workstreams can be run in parallel, with a technical cutover (infrastructure and upgrade) shortly preceding the project go-live.

Conclusion

The BW 7.0 upgrade is a well documented and stable process that can be performed as a pure technical upgrade with little or no change to business process whilst providing excellent non-functional benefits.

This can provide a challenge in term of getting internal funding for such and upgrade and this article gives some ideas of how the functional and non-functional benefits of such an upgrade can be put together to create a business case.