Best Practices for SAP BI using DB2 9 for z/OS - IBM Redbooks
Best Practices for SAP BI using DB2 9 for z/OS - IBM Redbooks
Best Practices for SAP BI using DB2 9 for z/OS - IBM Redbooks
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
11.5.1 Recommendations <strong>for</strong> configuration<br />
In summary, the primary objective of project Jupiter was to evaluate <strong>BI</strong><br />
Accelerator scalability. To ensure that no hardware resource constraints were<br />
encountered, we took a conservative approach with some of the hardware<br />
capacity planning. Since the scale of our test environment is several magnitudes<br />
larger than the 28 blades supported prior to our project, there was a high level of<br />
uncertainty about the scaling effects. As a result, a few hardware components<br />
were highly oversized. There<strong>for</strong>e, the configuration used in our project should not<br />
be used as a direct guideline <strong>for</strong> customer environments. See 11.5.2, “Help<br />
getting started” on page 252, <strong>for</strong> guidance.<br />
One exception was the <strong>BI</strong> Accelerator sizing used in our project. The general<br />
<strong>SAP</strong> rule-of-thumb <strong>for</strong> <strong>BI</strong> Accelerator sizing is to keep blade memory<br />
consumption by <strong>BI</strong> Accelerator indexes below 50% of the total memory on the<br />
blade servers. This is to ensure that sufficient memory is available on the blades<br />
to allow the query executions without ca<strong>using</strong> per<strong>for</strong>mance issues. We adhered<br />
to this general guideline <strong>for</strong> our <strong>BI</strong> Accelerator blade configuration. The fast<br />
consistent query response times achieved during our project have further<br />
validated this guideline.<br />
To minimize exposure to known problems, it is important to keep current with<br />
<strong>SAP</strong> support packs and the <strong>DB2</strong> maintenance level as identified in <strong>SAP</strong> notes<br />
364109 (<strong>DB2</strong> Put Levels) and 81737 (APAR List).<br />
It can be time-consuming to check that all required program temporary fixes<br />
(PTFs) listed in <strong>SAP</strong> Notes 364109 and 81737 have been applied to a z/<strong>OS</strong><br />
system. <strong>SAP</strong> provides a tool called automated PTF checker to facilitate the<br />
checking. Read <strong>SAP</strong> note 183311 <strong>for</strong> details.<br />
11.5.2 Help getting started<br />
To facilitate the <strong>BI</strong> Accelerator sizing process, <strong>SAP</strong> has provided an ABAP report<br />
that can be used to estimate the memory consumption of the <strong>BI</strong> Accelerator<br />
indexes. Refer to <strong>SAP</strong> Note 917803 <strong>for</strong> how to use this tool on the target <strong>BI</strong><br />
system. Though <strong>SAP</strong> <strong>BI</strong> 7.0 is required <strong>for</strong> the <strong>BI</strong> Accelerator, the tool can be run<br />
on the older <strong>SAP</strong> BW Releases 3.0, 3.1, and 3.5, as well as <strong>BI</strong> 7.0. Note that<br />
since the tool analyzes all cubes, it may run <strong>for</strong> a long time and there<strong>for</strong>e needs<br />
to be scheduled accordingly. Contact <strong>SAP</strong> if there is any issue with the report or<br />
in<strong>for</strong>mation in note 917803.<br />
252 <strong>Best</strong> <strong>Practices</strong> <strong>for</strong> <strong>SAP</strong> <strong>BI</strong> <strong>using</strong> <strong>DB2</strong> 9 <strong>for</strong> z/<strong>OS</strong>
Change language