Quick Tips: 22 Ways to Boost BEx Query Performance

by Catherine Roze, Consultant, IBM Business Consulting Services BEx,Reporting,BEx Analyzer,Performance You don't necessarily have to leave the responsibility for query performance to your technical team. These tips could save you a great deal of trouble and make you a hero with your end users. Query performance is an important factor for any user who wants fast results. Query performance management need not be the exclusive domain of the technical BW team. True, query performance begins with data modeling of the InfoCube and ODS objects, but it doesn't end there. Power users and query designers can exercise a number of techniques to optimize the performance of BW Business Explorer (BEx)-based queries. What follows is a series of practical tips and techniques to do that. I amassed them through personal experience, research, and other BW practitioners. Some of them will not only improve query performance, but will produce better result sets as well.1 Some of the tips that I will give you come with trade-offs. I've presented these query optimization tips and techniques22 in allaccording to the following levels:

At query and workbook level At query definition level (key figures, characteristics and attributes, and other query techniques) Process and general recommendations

Note! The secret to query performance is to keep the number of result sets at a minimum. This reduces the amount of data selected from the database and avoids unnecessary database processing and data-transfer operations. Clearly, the data-transfer speed increases when the size of the result set decreases. As a rule of thumb, SAP recommends that you keep the maximum result set within a BEx query to 10,000 records.

Query- and Workbook-Level Optimization Tips and Techniques

1.

Avoid complex queries that offer everything for every user. When a query becomes complex, go back to the basics and consider breaking it into multiple queries. You can also achieve the same result as the complex query by presenting the results in several worksheets of the same workbook. You might also consider linking several worksheets/workbooks using the report/report interface, a functionality in SAP BW (and R/3), to link reports for drill-down reporting. Note that this will improve query execution, but might increase development and administration overhead for the query. Avoid using queries to produce large reports. As opposed to mainframe and operational reports, SAP BW is not aimed at providing large reports with a great number of details. Rather, BW is designed for OLAP (on-line analytical processing)e.g., interactive slice-and-dice analysis. Users often print large reports solely to analyze exceptions such as what products or clients have a profit margin of less than 10 percent. Therefore, an exception report might better serve their needs than a large report. This might require a cultural change and might take education on the part of the user. If large reports do have to be produced, leverage the BW reporting agent to generate batch reports. These batch reports may be scheduled to run outside of business hours to minimize load during peak hours. You might also want to look for reports that are available in the operational system (R/3) to meet the reporting requirements. Another option would be to use third-party tools such as Crystal Reports to generate, publish, and print large tabular reports. Save the query results in a workbook and refresh the data when needed. This strategy will prevent the same data from being unnecessarily fetched from the InfoCubes multiple times. This is especially relevant for queries produced for a large number of users and that do not require up-to-the-minute information. Minimize the number of graphical objects such as charts and maps used in the workbook. The number of graphical elements saved in the workbook has a significant impact on resources and query run time. Let the end user create graphs as needed locally. Select the right read mode. Three query read modes in BW determine the amount of data to be fetched from a database:

2.

3.

4.

5.

6.

Read all data (all data is read from a database and stored in user memory space) Read data during navigation (data is read from a database only on demand during navigation) Read data during navigation and when expanding the hierarchy

Reading data during navigation minimizes the impact on the R/3 database and

application server resources because only data that the user requires will be retrieved. For queries involving large hierarchies with many nodes, it would be wise to select Read data during navigation and when expanding the hierarchy option to avoid reading data for the hierarchy nodes that are not expanded. Reserve the Read all data mode for special queriesfor instance, when a majority of the users need a given query to slice and dice against all dimensions, or when the data is needed for data mining. This mode places heavy demand on database and memory resources and might impact other SAP BW processes and tasks. A query read mode can be defined either on an individual query basis or as a default for new queries using the query monitor (transaction RSRT). Process and General Optimization Tips and Techniques 7. Test new queries in the development system before running them in the production system. By leveraging the BW landscape, you will not impact the production system with less-than-optimal query definitions before they are fully tested and optimized. This might not be an option if the data needed to test and validate the query is only available in the production system. If the same data is available in both the ODS and InfoCube, use the ODS rather than the InfoCube to define the query. If your goal is to do tabular reporting (no slicing and dicing, no OLAP) rather than using the InfoCube (OLAP query), leverage the ODS objects. Since the ODS object is based on a two-dimensional database structure, the number of database table joins will be minimal and the query will execute efficiently. If the same query can be written from the original InfoCube (InfoProvider), avoid MultiProvider (MultiCube) queries. MultiProvider (MultiCube) queries require additional database table joins to read data compared to those queries against standard InfoCubes (InfoProviders), and you should therefore use them only when you have no other option. Avoid queries against remote InfoCubes. Since a remote InfoCube is not managed within BW, but rather stored in the source system, executing a query against a remote InfoCube will require additional communication and processing, thereby negatively impacting reporting performance compared to queries against objects stored in BW. If they have to be used, remote cubes will typically perform better if a small amount of data is in the remote InfoCube and a small number of users has access to it. If Web reporting is available, use Web Reports rather than BEx Analyzer. Web reporting applications create less network overhead than BEx Analyzer, and using Web Reports typically results in better performance than BEx-based

8.

9.

10.

11.

queries. 12. If using the BEx Analyzer, launch it from the Windows menu rather than from within the SAP BW menu (or via transaction code). Microsoft Excel, BEx, and the SAP BW front end are memory-intensive applications. You will achieve better memory management through Windows system management if the BEx Analyzer is initiated by Windows (through the SAP front-end menu or a shortcut created on your desktop) rather than by the SAP BW front end (SAPGUI). Tune your PC for hardware and software optimization. Your query performance issues might be the symptom of a sub-optimal software or hardware configuration on your machine. Contact your local help desk for memory optimization (for example, adjusting virtual memory and page size). Your performance issues might also be resolved by adding memory to your system or replacing your machine with a faster one.

13.

Query Definition-Level Optimization Tips and Techniques 14. Leverage calculated key figures rather than formulas. As compared to formulas that are evaluated during query execution, calculated key figures are pre-calculated and their definitions are stored in the metadata repository for reuse in queries. The incorporation of business metrics and key performance indicators as calculated key figures, such as gross profit and return on investment (which are frequently used, widely understood, and rarely changed), improve query performance and ensure that calculated key figures are reported consistently by different users. Note that this approach improves query runtime performance but slows InfoCube or ODS object update time. As a rule of thumb, if multiple and frequently used queries use the same formula to compute calculated fields, use calculated key figures instead of formulas. Minimize the number of restricted key figures (RKFs) used in the query. RKFs result in additional database processing and complexity in retrieving the query result and therefore should be avoided when possible. Use characteristics as free characteristics rather than in rows and columns. Minimize the use of characteristics in rows and columns to avoid increasing the amount of details in the initial query result. The more details in the initial query result, the larger the result set will be and the more unlikely that an aggregate will be found. Rather, use the characteristics required for navigation as free characteristics that can be used for drill-down. This strategy will accomplish the same goals, since different users typically have different preferences in terms of the order and contents of the drill-downs. When multiple drill-downs are required, separate the drill-down steps by

15.

16.

17.

using free characteristics rather 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 all characteristics are in rows. Note that this strategy does not reduce the result set that the user obtains from the query. It just separates the drill-down steps. In addition to accelerating query processing, this has the advantage of improving the presentation to the user by providing more manageable portions of data. 18. Leverage characteristics or navigational attributes rather than hierarchies. Using a hierarchy requires reading temporary hierarchy tables and creates additional overhead compared to characteristics and navigational attributes. Therefore, characteristics or navigational attributes result in significantly better query performance than hierarchies, especially as the size of the hierarchy (e.g., the number of nodes and levels) and the complexity of the selection criteria increase. If hierarchies are used, minimize the number of nodes to include in the query results. Including all nodes in the query results (even the ones that are not needed or blank) slows down the query processing. The not assigned nodes in the hierarchy should be filtered out, and you should use a variable to reduce the number of hierarchy nodes selected. Leverage filters as much as possible. Using filters contributes to reducing the number of database reads and the size of the result set, thereby significantly improving query runtimes. Filters are especially valuable when associated with big dimensions where there is a large number of characteristics such as customers and document numbers. Minimize conditions-and-exceptions reporting. Conditions and exceptions are usually processed by the SAP application server that generates additional data transfer between database and application servers. If conditions and exceptions have to be used, the amount of data to be processed should be minimized with filters. Minimize the number of reusable structures in the query. Reusable structures are predefined selection and layout criteria for rows and columns that may be reused in other queries and often contain a combination of key figures, characteristics, and formulas. They suffer from limitations similar to those of RKFs and formulas in terms of reporting performance, and you should therefore avoid them when possible. Note that this strategy improves query execution but might increase development and administration.

19.

20.

21.

22.

Applying these 22 tips and techniques should resolve the majority of your query performance issues. As a last resort, if you are still experiencing performance issues, then I suggest that you visit your technical team and the SAP Service Marketplace Web site

(http://service.sap.com), as well as database, hardware, and system software documentation. I'll leave you with one more piece of advice that won't improve BEx query performance, but might make your life a little easier: Provide education and training to your users and share some of these tips with themfor example, avoid large reports. You should also strive to manage your users' expectations. Explain to them what level of performance they can reasonably expect and what can and cannot be done to improve performance without major redesign and investment. They will then be better positioned to avoid creating unnecessary query loads and help you identify when a real performance problem occurs.

Depending on your circumstances, some of these tips and techniques might not apply