SAP BI4 Upgrade Sizing and Virtualization Webcast Q&A

[TammyPowlas]

This is the Q&A notes I took from yesterday's SAP webcast in the chat log.  I edited them for clarification and removed the names.

The slides are here

Links provided by SAP:

Upgrade Site: http://www.sapbusinessobjectsbi.com/upgrade/plan-your-upgrade/#sthash.cqtKUj8s.dpbs

The SAP BI Virtualization site is at http://www.sap.com/bivirtualization

The full BI 4.1 Upgrade webinar series calendar (including previous webinar recordings) can be found at: http://scn.sap.com/docs/DOC-56308

BI Upgrade Collective Portal: http://www.sapbusinessobjectsbi.com/upgrade

Sizing site is Sizing and Deploying SAP BI 4 and SAP Lumira

Comments by SAP:

Sizing is definitely as much "art" as it is "science".

The main SAP BI Sizing site with additional resources can be found at http://www.sap.com/bisizing  - this includes a link to the sizing guide and the estimator

"Important in Virtualization is to inform the team managing the VM systems on the behaviour of BI.. (Spikey).. not that they reduce the allocations as the average load is not as expected".  Ensure you are using "reservations" and not "shares" - your IT team will not like that as an answer, but that's the official guidance from SAP. Also not having an overcommitment in Virtual CPU versus Physical CPUs.. this will for sure bring performance issues due to the nature how VM software works. The recommendation from SAP is to start planning scale out at 65% average utilization - Physical OR Virtual

Question & Answer (answers provided by SAP in the chat):

Q: The sizing estimator does not cover sizing for CMS and Audit database sizing. The Sizing Guide does talk about DB sizing, but the estimator is specifically for the BI processes.

A: These are depending on the usage of the system, DB configuration. i.e. if you audit by a deafult setting, there will be 13 events audited.. depending on the number of users and their activities an x number of rows will be added to the Audit DB..

A: For auditing a safe guideline = number of actions audited * the number of users * their number of reports opened by users, then depending on the DB, you have to validate the growth of a DB schema for the DB technology used.

CMS would be number of objects expected in the system (documents, folders, users, universes, schedules, instances etc) is the number of rows required in the CMS DB

Q: How do we provide sizing for end to end  BI server ,DB servers as well as FRS

A: A: very true, but each environment (and DB, and file system) are quite different, so this is where the progressive testing within your own environment comes in

Q: What are inbuilt tools that we shall be using before migration to make sure its smooth like reposcan

A: RepoScan, CMC-> Instances Schedule, Audit DB

Q:  Hello, could you please comment on a mixed environment of OS Linux and Windows? An example: a BO installation on Linux with CR& WebI, a new requirement to use Analysis for Office add-on which can run only on Windows based installations...

A:  We support heterogeneous landscapes, as long s the CMS processes are all running on the same OS+Patch level

Q: What should be the staring point before we start estimation? Is it number of user who are going to use the system for reporting?

A: The Sizing Guide has a methodology to follow - it includes the number of users, the type of users, and data size (and ofcourse application type).

A: understanding content being used is key in being successful in the upgrade

A: The Sizing Estimator does have it's limits - it's calculations are extrapolations of Lab Tests - which means after a certain point, the curve changes - for a large prod environment, there are too many variables for a simple calculator :-)/:-(

Q: can we use the "Analysis OLAP" row in the Sizing Estimator for sizing Design Studio as well?

A: in the sizing guide there is a special topic for Design Studio

A: Design Studio is different from AOLAP.. AOLAP does a lot more processing in the MDAS Process (hosted in APS).. Design Studio pushed more to the DB

A: For clustered / Large deployments, please work with experts in this topic.. estimator is based on a single system.. not understanding how the sizing works means a unstable deployment

Q: I haven't seen any sizing for Analysis for Office add-on. Is there any documentation? Scheduling is the topic. A scenario is to convert WB to an Analysis WB and schedule (pre-calculate) in background and distribute an Analysis WB by e-mail

A: What kind of sizing for AOffice do you need? BI server hardly does anything with it unless it is scheduled

Q: While upgrading a system and moving from one OS platform or repo DB vendor to another will sizing estimator play some role (considering no change in number of objects and usage)?

A: Sizing Estimator will not take into account the database you use for reporting or CMS.  The Sizing Guide will provide  additional  details on  what to do if your reporting db is BW

Q: What is strategy for upgrading BOE XIR2 when BI 4.1 will reside in a different domain?

A: can you clarify? Would changing the domain matter?

As long as the BI4.1 server can reach the other environment UMT will be able to address the upgrade.. additionally you can deploy a temp system that has connectivity to both domains and run a UMT from there (custom server install required in this temp box)

If I understand your question correctly, there shouldn't be any more performance impact than anything else going cross domain - you want to take a look at the network segments and ensure there is bandwidth between (i.e. if they are on different subnets, is there enough bandwidth at the router to  handle the traffic?"

Q: when upgrading from BI 4.0 to BI 4.1, do we need more memory?

A: typically no, however it is recommended to validate your systems usage and adjust sizing accordingly

Typically no, but depending on what SP you are upgrading from, there may be new services (post SP4 has additional clients), so you want to ensure they are either accounted for or disabled.

If you do it right, you're good to go.  If you don't follow the best practices, it will magnify any performance bottlenecks you have (which makes sizing even more important).

Q: what about sizing for Explorer ? does it cover in Sizing estimator ?

A:There is Sizing Guidance for Explorer at www.sap.com/bisizing

Q: I find VM BI 4 tends to choke when publications, because it is very CPU intense.  Do you find that as well

A: if you account for publications during sizing it should not "choke" up your system

Q: Does Analysis for MS Office affect Server performance? A:

A: Only if you schedule them on the BI platform

Opening Aoffice content in launchpad triggers the start of Aoffice..Server just has to send the file to the client

Q: Do this estimation techniques also gives the smooth performance for mobile Business Objects platform ?

A: Mobile consumption is just as any other user

With a minimal additional load on the WAS

Determine what type of reports the mobile users are using, add them in the sizing estimator

Q: Is there a best practice for number of rows in an Explorer?

A: It depends on the complexity - it is as much about the number of CELLs rather than rows.  We've seen customers with up to 1-3 million, but some see much lower.

At the end of the webcast SAP said the recording should be made available some time next week.