Tips Tricks to Speed NW BI 2009 (1)

8/2/2019 Tips Tricks to Speed NW BI 2009 (1)

http://slidepdf.com/reader/full/tips-tricks-to-speed-nw-bi-2009-1 1/56

© 2009 Wellesley Information Services. All rights reserved.

20 technical tips and tricks

to speed SAP NetWeaverBusiness Intelligence query,report, and dashboard

performance

Dr. Bjarne Berg



2

What We‘ll Cover …

• Introduction• Performance Issues & Tips

MultiProviders and PartitioningAggregatesQuery Design & CachingHardware & Servers

• Designing for PerformanceInfoCubes and DSOs

• BI- Accelerator Sizing and ImplementationManagement and Costs

• EarlyWatch Reports• Wrap-up



3

In this session we will cover the top 20 must-do technicalperformance tricks to help you optimize SAP NetWeaver BIreporting for your end users.

We will look at performance modeling of InfoCubes, how

to improve memory utilization by caching and how to usediagnostics to analyze performance issues.

We will also explore best practices on how to develop andmanage aggregates and MultiProviders, and see what theBI- Accelerator (BIA) can do for your organization.

Finally, we will look at how to analyze EarlyWatch reportsfrom Solution Manager 4.0 so they become actionable.

In this session.



4

Capacity and Scalability Is the Top Concern for Your CxO

• Don‘t under size your global BI system

Spend adequate funding on hardware, memory, processing power and disk space

7.03

7.21

7.31

7.51

7.62

7.65

7.887.9

7 7.25 7.5 7.75 8

Difficult for end users to learn or use

Danger of distributing outdated data

Too many Business Intelligence tools in use

Data Integration

Security

Determining ROI

Server & Desktop processing capacityOverall System Performance and capacity

Source: Intel, SAP & Business Week"Seizing the BI Opportunity" 2006.

A survey of 353 top C-level officers in large companies, reportedthat the top BI concern was the scalability of their solutions.



5





BI- Accelerator Sizing and ImplementationManagement and Costs




6

Problem: To reduce data volume in each InfoCube,

data is partitioned by Time period.A query now have to search in all InfoProviders to findthe data (i.e. billing docs from 2007). This is very slow.

Solution: We can add ―hints‖ to guide the query execution. In theRRKMULTIPROVHINT table, you can specify one or severalcharacteristics for each MultiProvider which are then used topartition the MultiProvider into BasicCubes.

If a query has restrictions on this characteristic, the OLAP processor is already

checked to see which part cubes can return data for the query. The datamanager can then completely ignore the remaining cubes.

An entry in RRKMULTIPROVHINT only makes sense if a few attributes of thischaracteristic (that is, only a few data slices) are affected in the majority of, or

the most important, queries (SAP Notes: 911939. See also: 954889 and 1156681).

Tip 1: MultiProviders and Hints

2002 2003 2004 2005 2006 2007 2008



7

Tip 2: The Secret about MultiProviders & Parallel Processing

• To avoid an overflow of the memory, parallel processing iscancelled as soon as the collected result contains 30,000 rowsor more and there is at least one incomplete sub process

The MultiProvider query is then restarted automatically and processed

sequentiallyWhat appears to be parallel processing corresponds to sequentialprocessing plus the preceding phase of parallel processing up to thetermination

• Generally, it‘s recommended that you keep the number of InfoProviders of a MultiProvider to no more than 10. However,even at 4-5 large InfoProviders you may experience performancedegradation.



8

MultiProviders and Parallel Processing (cont.)

• Consider deactivating parallel processing for those queries that

are MultiProvider queries and have large result sets (and ‗hints‘cannot be used).

With SAP BW 3.0B SP14 (SAP BW 3.1 SP8 and later versions, you can changethe default value of 30,000 rows — refer to SAP Notes 629541, 622841, 607164,

and 630500.

• A larger number of base InfoProviders is likely to result in ascenario where there are many more base InfoProviders thanavailable dialog processes, resulting in limited parallelprocessing and many pipelined sub-queries

You can also change the number of dialogs (increase the use of parallel processing)in RSADMIN by changing the settings for QUERY_MAX_WP_DIAG.



9





• BI- Accelerator Sizing and ImplementationManagement and Costs




Aggregates

•

Aggregates are much less used by the SAP installation base thantraining and common sense should dictate.

• The interface to build the summary tables (aggregates) are intuitiveand easy to master, but few are taking real advantage of them.

• Even among those that are using aggregates, many have poorlydefined solutions & seldom monitor the usage, thereby limiting thebenefits of this simple technology.

To avoid poor definition and usage, aggregates shouldbe developed after the system has been in production

for a while and real user statistics are captured.



Tip 3: Building aggregates is easy – Propose from statistics

• Select the run time of queries

to be analyzed (e.g., 20 sec)• Select time period to

be analyzedOnly those queries executed inthis time period will be reviewedto create the proposal

This example shows how tobuild aggregates by usingsystem statistics to generateproposalsNote: To make this work, the BWstatistics must be captured.



Correct Aggregates Are Easy to Build – Propose from Query

We can also create proposalsfrom the Query user statistics .

To make this work, arepresentative number of queries must be executed togather the statistics to optimizefrom.

We can also create

proposals for aggregatesbased on individual queriesthat are performing poorly.



Tip 4: Reduce the number of overlapping Proposals

High valuation and high usage is what we are looking for. This indicates high reduction

of records in aggregate and high benefits to users ..

We reduce the overlapping proposalsby optimizing them.This may reduce the proposals from 99to less than a dozen

When using 3 rd party query tools and ODBC to query directly into theDSO, you are bypassing the OLAP Processor. Therefore, you cannot

accurately performance tune the system using aggregates (statistics),

nor will the 3rd party tool benefit from aggregates .



Activate the aggregate

1. Click on Jobs tosee how theprogram isprogressing

The process of turning 'on' the

aggregates is simple



Fill aggregate with summary data




• Introduction• Performance Issues & TipsMultiProviders and Partitioning

AggregatesQuery Design & CachingHardware & Servers






Tip 5: Use the Right Read Mode for Queries

Select the right read mode. Three query read modes in

BW determine the amount of data to be fetched from adatabase:

1. Read all data (all data is read from a database and stored in usermemory space)

2. Read data during navigation (data is read from a database onlyon demand during navigation)

3. Read data during navigation and when expanding the hierarchy

Reading data during navigation minimizes the impact onthe application server resources because only data thatthe user requires will be retrieved.

Source: Catherine Roze,



Tip 6: Query read mode for large hierarchies

For queries involving large hierarchies with many nodes, it would

be wise to select Read data during navigation and whenexpanding the hierarchy option to avoid reading data for thehierarchy nodes that are not expanded.

Reserve the Read all data mode for special queries —for instance,

when a majority of the users need a given query to slice anddice against all dimensions, or when the data is needed for datamining. This mode places heavy demand on database andmemory resources and might impact other SAP BW processesand tasks.

A query read mode can be defined either on an individual querybasis or as a default for new queries using the query monitor (transaction RSRT).

Source: Catherine Roze



19

Tip 7: Condition & Exceptions

Minimize conditions-and-exceptions reporting. Conditions &

exceptions are usually processed by the SAP applicationserver. This generates additional data transfer betweendatabase and application servers.

If conditions and exceptions have to be used, the amount of data to beprocessed should be minimized with filters. When multiple drill-downsare required, separate the drill-down steps by using free characteristicsrather than rows and columns.

This strategy results in a smaller initial result set, and therefore faster query processing and data transport as compared to a query where allcharacteristics are in rows.

This strategy does not reduce the query result set. It just separatesthe drill-down steps. In addition to accelerating query processing, it

provides the user more manageable portions of data.Source: Catherine Roze,



20

Some Performance settings for Query Execution

This decides how many records are readduring navigation .

Examine therequest statuswhen readingthe InfoProvider

New in 7.0 BI:OLAP Engine canread deltas into thecache. Does notinvalidate existingquery cache.

Displays the level of statistics collected.

Turn off/on parallelprocessing

When will thequery program beregenerated based

on databasestatistics



21

Tip 8: Filters

Leverage filters as much as possible. Using filters contributes toreducing the number of database reads and the size of the result set,thereby significantly improving query runtimes.

Filters are especially valuable when associated with ―bigdimensions‖ where there is a large number of characteristics such ascustomers and document numbers.

If large reports have to be produced, leverage the BExBroadcaster to generate batch reports and pre-deliver

them each morning to their email, PDF or printer.



22

Tip 8: Use RSRT Transaction to examine slow queries

P1 of 3



23

Look for patterns and see the performance details

P2 of 3

In this real case, aggregateswas needed for those cubes

flagged…



24

Real Example: This system has issues with the Oracle DB

P3 of 3

Work with the basis teamto research the settingsand the Oracle issues.

Focus on SAP notes andthe index issue.

The RSRT and RSRVcodes are a gold mine for debugging and analyzing

slow queries.



25

Look at the query details for each slow query

Notice the yellow flag for the 6 basecubes in the MultiProvider and theyellow flag for the 14 free chars.

(Note: no hints were used in this MultiProvider,which led to very poor performance).

You can also trace the front-end datatransfers and OLAP performance by using

RSTT in SAP 7.0 BI (RSRTRACE in BW 3.5)



26

Tip 9: Use the BEx Broadcaster to Pre-Fill the Cache

Distribution Types

You can increase query speed by broadcastingthe query result of commonly used queries to

the cache.

Users do not need to execute the query fromthe database. Instead the result is already inthe system memory (much faster).



27

Tip 10: Debugging Queries - RSRT

Here you can execute the queryand see each breakpoint, thereby

debugging the query and seewhere the execution is slow.

Worth a try: Try running slowqueries in debug mode with

parallel processing deactivatedto see if they run faster..



28

Tip 11: Upgrade to AS-Java service pack 14 asap.

In service pack 14 we find several performance improvementsincluding:- Better Java execution and performance

- Increased OLAP cache abilities (Enhanced Cluster table -BLOB)

In 7.0 BI at all service packs upto number 14, it is also impossible topopulate the OLAP cache by broadcasting query views. If you useearlier service packs, you may be forced to create many differentqueries to provide this performance.

The implementation of service pack 14 is highlyrecommended by SAP for these performance reasons. When

implemented the Java execution will also improve.

C k i#of

Q iBaseline4/18/08

SP 14(4/21/08)

Improve



29

A Real Example

This company saw a39% decrease in Query

execution time after implementing SP-14.

They had 38 cockpitsand 82 queries that

improved substantially

without any further changes..

Cockpit Queries 4/18/08 (4/21/08) mentExpense Query for Detailed program 1 145 9 94%Financial dashboard expense (actual vs. target) 7 150 18 88%Financial dashboard [expense] 2 70 12 83%Financial dashboard [non-earnings] 2 42 13 69%Expense Query for Detailed org objective 1 31 10 68%Financial dashboard [workforce costs] 6 50 17 66%Expense Query for Detailed 1 36 14 61%Capital Query for Detailed work type 1 22 9 59%

Financial performance 9 43 21 51%Workforce financials 9 29 16 45%Expense query for detailed 1 16 9 44%Balance Query for Detailed program 1 14 8 43%Balance Query for Detailed cost element 1 14 8 43%Balance Query for Detailed MWC 1 14 8 43%Non-earnings Query for Detailed org objective 1 14 8 43%Financial dashboard (other balance) 7 29 17 41%Balance query for organization detailed 1 13 8 38%

Balance Query for Detailed work type 1 13 8 38%Non-earnings Query for Detailed cost element 1 13 8 38%Capital Query for Detailed cost element 1 14 9 36%Labor query for detailed org 1 14 9 36%Standard costs variance detailed report 1 20 13 35%Financial dashboard (non-earnings) 7 30 20 33%Non-earnings Query for Detailed program 1 12 8 33%Balance Query for Detailed org objective 1 13 9 31%Capital Query for Detailed MWC 1 14 10 29%Non-earnings query for organization detailed 1 12 9 25%

Non-earnings Query for Detailed work type 1 12 9 25%Financial dashboard [workforce cost] 2 23 18 22%Capital Query for Detailed org objective 1 15 12 20%Financial dashboard [other balance sheet] 2 21 17 19%Labor query for detailed cost element 1 12 10 17%Expense Query for Detailed cost element 1 13 11 15%PCC Expense Query for detailed 1 14 12 14%Headcount detail fin-DB 1 15 13 13%Capital - Actual Vs. Target 7 24 22 8%Financial dashboard capital trend 2 13 12 8%Non-earnings Query for Detailed MWC 1 13 13 0%

Average 27.95 12.03 39%



30

1. When Restrictive Key Figures (RKF) are included in a query, conditioning is done for each of them during query execution. This is very time consuming and a high number of RKFs can seriously hurt query performance

Recommendation: Reduce RKFs in the query to as few as possible. Also, definecalculated & RKFs on the Infoprovider level instead of locally within the query. Why?:

Good: Formulas within an Infoprovider are returned at runtime and held in cache.Bad: Local formulas and selections are calculated with each navigation step.

2. Line item dimensions are basically fields that are transaction oriented and therefore,

once flagged as a ‗line item dimension‘, is actually stored in the fact table. Thisresults in faster query access (no table join).

Tip 12: Restrictive Key Figures & Line Item Dimensions

Explore the use line item dimensions for fields

that are frequently conditioned in queries.



31

Problem: Calculated Key Figures (CKF) are computed

during run-time, and a many CKFs can slow down thequery performance.

Solution: Many of the CKF can be done during data loads & physicallystored in the InfoProvider. This reduces the number of computations andthe query can use simple table reads instead. Do not use total rows whennot required (this require additional processing on the OLAP side).

Problem: Sorting the data in reports with large result sets can be timeconsuming.

Solution: Reducing the number of sorts in the default view can improvethe report execution & provide the users with data faster.

Tip 13: Reducing the Query processing time

PS! Reducing the text in query willalso speed up the processing some.



32

Web templates in SAP BI can becomereally large. Since they contain bothscripts and Cascading Stylesheets(CSS), the code can become reallycomprehensive.

To reduce the CSS, you can try severalcompression tools that may help youlimit the overall size of your webtemplates.

There are no lack of free tools available,

and the quality varies. Therefore youmust remember to test, test and test….(but the benefits can also be great).

Compression tools for CSS and Java scripts can reduce the overall web template size. If you have thousands of users, this can be a ‘life saver’’

Tip 14: Make your web templates Smaller

CSSTidy



33


• Introduction•

Performance Issues & TipsMultiProviders and PartitioningAggregatesQuery Design & CachingHardware & Servers


BI- Accelerator Sizing and ImplementationManagement and Costs EarlyWatch Reports

Wrap-up



34

Tip 15: Is the Memory Cache Is Set Too Low?

Cache has a system default of 100 MB for local and 200 MB for globalcache. This may be too low for a system that can be optimized viabroadcaster .

The Cache is not used when a query contains a virtual keyfigure or virtual characteristics, or when the query is

accessing a transactional DSO, or a virtual InfoProvider

Review the settings with theBasis team and look at theavailable hardware.

Use the transaction codeRSCUSTV14 in SAP NetWeaver BI to increase the cache. Focusparticularly on the global cache.



35

Tip 15: Monitor and adjust Cache Size

To monitor the usage of the cache, use transaction code RSRCACHE

and also periodically review the analysis of load distribution usingST03N – Expert Mode

The size of OLAP Cache is physically limited by the amountof memory set in system parameter rsdb/esm/buffersize_kb.The settings are available in RSPFPAR and RZ11.

Source: V. Rudnytskiy, 2008



36

Tip 16: The Right OLAP Cache Persistence Settings

CACHE OLAP Persistence settings

Note When What t-code

Default Flatfile

Change the logical fileBW_OLAP_CACHE wheninstalling the system (notvalid name) FILE

Optional Cluster table Medium and small result setsRSR_CACHE_DBS_IXRSR_CACHE_DB_IX

OptionalBinary Large Objects(blob) Best for large result sets

RSR_CACHE_DBS_BLRSR_CACHE_DB_BL

SP 14

Blob/ClusterEnhanced (new inSAP 7.0 BI)

No central cache directory orlock concept (enqueue). Themode is not available bydefault.

SetRSR_CACHE_ACTIVATE_NEWRSADMIN VALUE=x

Source: SAP AG 2008.



37

Monitor Memory Usage – Do you need more?

Roll memory was never maxed out inthe period 12/23/07 through 1/27/08

Paging memory was never maxed outin the period 12/23/07 through 1/27/08

Extended memory was never maxed out inthe period 12/23/07 through 1/27/08

Only 3GB of 9 GB of Heap memory was everused in the period 12/23/07 through 1/27/08



38


• Introduction•


•

Designing for Performance InfoCubes and DSOs





Tip 17: Avoid Outdated Indexes and Database statistics

Database statistics are used by the optimizer to route queries. Outdatedstatistics leads to performance degradation. Outdated indexes can leadto very poor search performance in all queries where conditioning isused (i.e. mandatory prompts).

For high volume Infocubes, or cubes that have a high number of users, thepercentage used to build the DB stats can be increased from the default 10%

to 20%. This may yield more accurate query routing and better queryperformance (consider this especially for cubes with ‗old data‘ partitioned)

Name Tech-Nm Object Indexes DB stats% used to

create statsVendor history closed XFIAP_C10 Infocube 10%AR customer XFIAR_C10 Infocube 10%FIAR line items 0FIAR_C03 Infocube 10%

FIAR Payment history 0FIAR_C05 Infocube 10%FIAR: Transaction data 0FIAR_C02 Infocube 10%Multicube AR&billing XSDARBIL Infocube n/a n/a n/aBilling cube custom for AR trade XSDBILITM Infocube 10%Sales contract cube - anticipated billing XSDCN_C10 Infocube 10%Service orders - ZSLM ZCSCBZSLM Infocube 10%Performance cube ZCSCBPER Infocube 10%Headcount and personnel actionas ZHRPA_C02 Infocube 10%Cycle count XMMWM_C10 Infocube 10%MM LIO interface infocube XLIO_C01 Infocube 10%

Material aging ZMMCBMAAG Infocube 10%Lead time cube ZMMLTCUBE Infocube 10%



Tip 18: Avoid replicating the transaction system in SAP BI

It is tempting to load cross-reference tables and do lookups inside SAP BI instead of extending extractors. This creates DSOs that cannot be queried efficiently withoutmany table joins. In this example, ¼ of all DSOs contains less than 9 fields, & sixhave less than 4.

Programs that can help you monitor

the system design:1. SAP_ANALYZE_ALL_INFOCUBES2. ANALYZE_RSZ_TABLES3. SAP_INFOCUBE_DESIGNS

As much logic as possible should be moved to the extraction,and needed data fields should be denormalized and stored in

logically organized ODSs and Infocubes.

f



41

InfoCube Design & Indexes

When you flag a dimension as “high cardinality” SAP BI

will use a b-tree index instead of a bit-map index.This can be substantially slower if the high cardinalitydoes not exist in the data in general (star-joins cannot beused with b-trees).

Info Cube Line Itemdims

DIM 1 DIM 3 DIM 6 DIM 8

CBBL_CB02 0 H

CBPD_CB06 0 H

CBPR_CB11 0 H

CBPR_CB18 0 HCBSV_CB01 0 H

CBSV_CB02 0 H

Validate the high-cardinality of the data and reset the flag if

needed – this will give a better index type and performance



42


• Introduction•


•

Designing for PerformanceInfoCubes and DSOs



l



43

TIP 19: Use BI Accelerator ASAP

The SAP BIAccelerator makesquery response time50-10,000 faster.

You use processchains to maintain

the HPA engine after each data load

HP, Sun and IBM have standard solutions ranging from $32K to $250K+ that can be installed and

tested in as little as 2-4 weeks (+ SAP license fees)

SAPBW

Anytool

32 Gb Blades are nowcertified by SAP (July 2008)

H d SAP BIA W k?



44

Currently, the BIA performs aggregation and data selectionfor the query, all other processing is done by the OLAPanalytical engine. (this means that 99% of the previousrecommendations in this session still holds true)…

SAP BIA is not used when the result set exceeds 3 million records(max. default). When the result set is less, the data is sent as onelarge data package to the application server (need fast network).

In the next SAP NetWeaver release the BIA will handle more of theanalytics processing such as “top

-5 products sales” which is

currently done in the OLAP analytical engine.

How does SAP BIA Work?

You get BIA sizing estimates by running the SAP program available in SAP Note: 917803

P f B h k f BIA



45

BIA Currently reads data from InfoCubes. DSOs & InfoObjects

are still read from base/physical tables (even

when the InfoObject is indexed as part of master data).

Performance Benchmarks for BIA

BIA’s strength resides inits near-linear scalability.

Performance is measuredin terms of:

1. BIA index creation time2. Multi-user throughput per hr.3. Average report response time4. Average number of records

touched by each report.

H d E l



46

The BIA should be sized for critical applications. Most companies use BIA only for Production, while others have a complete landscape

Hardware Example

Environment Area Recommended size IBM example*Production Blade servers 14 Blades BladeCenter HS21 -8853G6UProduction Memory 2x8 GB (2x4) DDR2 total 16 GB 39M5797

Production Processors 2 x Quad Core Intel Xeon Processor 2 x Quad Core Intel Xeon ProcessorProduction Processor speed 3.00 GHz+ 3.00 GHzProduction Network cards 2 x Gigabit Cisco cards 32R1760Production External storage Dedicated disks (500 GB+) DS-4800Production File system General Parallel file system (GPFS) GPFSProduction Chassis 14 blades capacity H-series (rack-mount/9U) 88524XUQA Blade servers 14 Blades BladeCenter HS21 -8853G6UQA Memory 2x8 GB (2x4) DDR2 total 16 GB 39M5797

QA Processors 2 x Quad Core Intel Xeon Processor 2 x Quad Core Intel Xeon ProcessorQA Processor speed 3.00 GHz+ 3.00 GHzQA Network cards 2 x Gigabit Cisco cards 32R1760QA External storage Dedicated disks (500 GB+) DS-4800QA File system General Parallel file system (GPFS) GPFSQA Chassis 14 blades capacity H-series (rack-mount/9U) 88524XUDevelopment Blade servers 4 Blades BladeCenter HS21 -8853G6UDevelopment Memory 2x8 GB (2x4) DDR2 total 16 GB 39M5797

Development Processors 2 x Quad Core Intel Xeon Processor 2 x Quad Core Intel Xeon ProcessorDevelopment Processor speed 3.00 GHz+ 3.00 GHzDevelopment Network cards 2 x Gigabit Cisco cards 32R1760Development External storage Dedicated disks (300 GB+) DS-4800Development File system General Parallel file system (GPFS) GPFSDevelopment Chassis 14 blades capacity H-series (rack-mount/9U) 88524XU



Wh t W ‘ll C



48


• Introduction•


•



EarlyWatch ReportsWrap-up

Ti 20 SAP S l ti M E l W t h R t A G t!



49

Tip 20: SAP Solutions Manager - EarlyWatch Reports Are Great!

• EarlyWatch reports provide asimple way to confirm how your system is running and to catchproblems

A ―goldmine‖ for systemrecommendations

• Run them periodically & read thedetails

• This is a real EarlyWatch reportfrom a mid-sized company thathas been running SAP BW for the

last four yearsOn a large global project, system issuescan be hard to pin-down without accessto EarlyWatch reports. The monitoringreports allows you to tune the systembefore the user community gets access

and complaints arise.

EarlyWatch Performance Info



50

EarlyWatch Performance Info

1 Performance IndicatorsThe following table shows the relevant performance indicators in various system areas.

Area Indicators Value Trend

System Performance Active Users 18 downHardware Capacity Max. CPU Utilization on DB Server 74 % steadyMax. CPU Utilization on Appl. Server 74 % steady

Database Space Management DB Size 355.52 GB steadyLast Month DB Growth 118.63- GB steady

Query Performance Avg. Total Runtime of the BW Queries 11.5 s downAvg. Database Runtime of the BW Queries 8.0 s steady

1 Performance OverviewThe performance of your system was analyzed with respect to the average response times and totalworkload. We did not detect any major problems that could affect the performance of your system.

The following table shows the average response times for various task types:

Task type DialogSteps

Avg. Resp.Time in ms

Avg. CPUTime in ms

Avg. WaitTime in ms

Avg. LoadTime in ms

Avg. DBTime in ms

Avg. GUITime in ms

DIALOG +RFC

195240 3253.3 728.7 1.8 2.5 1110.9 6.3

UPDATE 5 984.2 28.2 26.0 15.2 585.4UPDATE2 48 133.2 17.1 0.7 3.3 80.8BATCH 59288 11599.3 2091.2 0.6 8.5 5772.6HTTP 257762 693.5 183.7 4.4 2.2 405.0

1.1 Current WorkloadThe following table lists the number of current users (measured from our workload analysis) in your system.

Users Low Activity Medium Activity High Activity Total UsersMeasured in System 98 11 7 116

In a 24-hour operational systems

due to time-zones, you will haveless time to react and fix issues.

Therefore, early detection of system issues are critical to thesuccess of a global project.

Earl Watch Reports Finds Oracle fi es



51

EarlyWatch Reports – Finds Oracle fixes

In this real example, we can the EarlyWatch report identified that the

system was several Oracle notes are behind that needed to beapplied to optimize DB performance.

Before this was done, this system took 24 to 26 minutes to executesome queries.

SAP Notenumber

Description

841728 Oracle 10.2.0: Composite note for problems and workarounds871096 Oracle Database 10g: Patch sets/Patches for 10.2.0

871735 Current Patchset for Oracle 10.2.0850306 Oracle Critical Patch Update Program1021454 Oracle Segment Shrinking may cause LOB corruption.

952388 Kernel <= 6.40:UNIX error due to 9i Client software

EarlyWatch Reports Finds Backup Problems



52

EarlyWatch Reports – Finds Backup Problems

In this real example,

the EarlyWatchreport identified thatthere were no validbackups for almostone month.

0.1 Backup FrequencyWhen we checked the backup log files, we detected that your backup strategy does not follow the SAP backuprecommendations.

In the time period from 09.01.2008 to 05.02.2008 , we noticed the following problems:- There was no successful backup on Friday 01.02.2008- There was no successful backup on Thursday 31.01.2008- There was no successful backup on Wednesday 30.01.2008- There was no successful backup on Tuesday 29.01.2008- There was no successful backup on Monday 28.01.2008There are 5 working days without successful backup this week.

- There was no successful backup on Friday 25.01.2008- There was no successful backup on Thursday 24.01.2008- There was no successful backup on Wednesday 23.01.2008- There was no successful backup on Tuesday 22.01.2008- There was no successful backup on Monday 21.01.2008There are 5 working days without successful backup this week.

- There was no successful backup on Friday 18.01.2008- There was no successful backup on Thursday 17.01.2008- There was no successful backup on Wednesday 16.01.2008- There was no successful backup on Tuesday 15.01.2008- There was no successful backup on Monday 14.01.2008There are 5 working days without successful backup this week.

- There was no successful backup on Friday 11.01.2008- There was no successful backup on Thursday 10.01.2008- There was no successful backup on Wednesday 09.01.2008There are 3 working days without successful backup this week.

There is no successful backup at all for this period.

What We‘ll Cover



53


• Introduction•


•



EarlyWatch ReportsWrap-up



54

7 Key Points to Take Home• Use best practices for query design before you start massive hardware

performance tuning efforts.

• Plan for growth – what is the plan when you have 200,500, 1000+ users?

• Start with aggregates (poor man‘s BIA), thereafter go with caching.

• Monitor the system usage- do you need more app servers, memory, HW?

• Check database statistics and indexes and keep them up to date.

• If you are building an Enterprise Data Warehouse, plan and budget for aBIA installation.

• EarlyWatch reports are a tool to live (and ‗die‘) by. Use the report beforeyou have performance issues.

Resources



55

Presentations, tutorials & articles

www.Comerit.net

SAP SDN Community web page for Business Intelligence Performance

Tuning https://www.sdn.sap.com/irj/sdn/bi-performance-tuning

ASUG407 - SAP BW Query Performance Tuning with Aggregates byRon Silberstein (requires SDN or Marketplace log-on). 54 min movie .https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/media/uuid/d9fd84ad-0701-0010-d9a5-ba726caa585d

Large scale testing of SAP BI Accelerator on a NetWeaver Platformhttps://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b00e7bb5-3add-2a10-3890-e8582df5c70f

Resources

Your Turn!



Your Turn!

How to contact me:Dr. Bjarne Berg

[email protected]

Documents

Tips Tricks to Speed NW BI 2009 (1)