/IT/Project Management
Deciding to add SAP NetWeaver BW Accelerator is a major step for organizations. Although the benefits include much faster query performance, you need to ensure that you fully plan your project. Find out how to approach the initial phases of an SAP NetWeaver BW Accelerator implementation, including project preparation, blueprint, and realization. In addition, learn some tasks you can carry out before go-live to get the most out of the implementation.
Key Concept
There are key issues and considerations to take into account when implementing the accelerator. The accelerator appliance is not a “plug and play” hardware device. You need to integrate it into and maintain it in your existing SAP NetWeaver BW environment.
If your organization is considering implementing SAP NetWeaver BW Accelerator, now might be the best time to do so, despite the uncertainties in the current economy. Survival in the fast pace of world markets and a fierce economic climate require adapting to swift changes and competition. As such, your viability and competitiveness may depend on how quickly and correctly you can analyze data and make fast business decisions. SAP NetWeaver BW Accelerator (or the accelerator) is available to help enhance the analytic capabilities and productivity of SAP NetWeaver BW customers.
Note
As of the writing of this article, the name for SAP NetWeaver BI has changed. It is now SAP NetWeaver BW. SAP NetWeaver BI Accelerator has also changed to SAP NetWeaver BW Accelerator.
What follows are the critical steps, undocumented tips, and lessons learned from multiple successful customer implementations of SAP NetWeaver BW Accelerator. This article applies to SAP NetWeaver BW Release 7.0 and SAP NetWeaver BW Accelerator (Revision 49). It assumes that you are already familiar with all fundamental concepts of SAP NetWeaver BW and the accelerator. Detailed technical instructions related to the accelerator installation are outside the scope of this article.
The content is organized based on the SAP project methodology and its five critical phases: project preparation, business blueprint, realization, final preparation, and go-live and support. This article spans phases from project preparation to blueprint and realization. Table 1 provides an overview of the key activities and milestones during an accelerator project implementation.
- Budgeting
- Value proposition
- Project team and staffing
- Architecture dependencies
- Infrastructure dependencies
- Configuration dependencies
|
- Scoping
- Fit analysis
- Landscape
- Sizing
- Building team expertise
- Technical optimization (optional)
|
- Changes to process chains
- Changes to data model and queries
- Changes to authorization
- Other dependencies
- Initial indexing
- Testing
- Support model
- Change management procedure
|
|
Table 1 |
Key activities and milestones during an accelerator project implementation |
Project Preparation
The implementation of the accelerator is like any other SAP project in that it requires thorough planning, proper skills, and (no surprise) funding while commanding architecture and infrastructure dependencies.
Budgeting. Funding is the first critical step during project preparation. The key costs to consider when budgeting for the accelerator are the recurring and one-time costs:
- Recurring costs for the software licensing, accelerator maintenance and support, and infrastructure backbone (e.g., network connection)
- One-time costs for the hardware as well as the labor and consulting services required for the accelerator implementation project
Value proposition. An important consideration is that the accelerator implementation is a business project, not an IT project. This means that the budget has to come from the business and requires a return on investment (ROI) analysis to justify the value proposition. The accelerator value proposition revolves around three main benefits:
- Gains from business benefits, including increased user productivity due to the improved query performance , more timely information, and enhanced usability to perform analysis not possible before
- Savings in the total cost of ownership (TCO) of the SAP NetWeaver BW system due to minimized load on BW hardware, including reduced CPU and database space requirements
- Reduced IT labor cost to analyze, maintain, and monitor performance optimization (e.g., the accelerator minimizes or eliminates database performance tuning such as aggregates maintenance)
SAP provides a tool for calculating the costs and benefits a company can expect by deploying the accelerator. The tool is available to organizations from their SAP account executives.
Project team and staffing. During the preparation phase, you need to assemble a project team and assign resources to the accelerator project. A typical organization’s concern is that the accelerator requires additional staff to maintain and optimize it. Our experience shows that most organizations require assistance during the planning and implementation of the accelerator, but do not require additional full-time equivalents (FTEs) after implementation. The additional maintenance that the accelerator requires is minimal and can be distributed to the existing BW team.
During planning and implementation, an SAP NetWeaver BW Accelerator project requires a project manager to plan and coordinate activities involving the infrastructure team, Basis specialists, the BW functional team, a hardware vendor engineer, and a consultant with experience in SAP NetWeaver BW Accelerator implementations.
Architecture dependencies. The accelerator has no dependencies on which database, operating system, or hardware the SAP NetWeaver BW system is running. However, keep in mind that an accelerator implementation has some technical prerequisites. The accelerator is based on standard blade server technology. The accelerator software runs on the SUSE Linux operating system only. Many large organizations have IT architecture standards that might not include the aforementioned technologies. You cannot include the accelerator in your infrastructure before your IT architecture team approves Linux or blades for the accelerator.
Infrastructure dependencies. It may come as a surprise, but a sufficient network bandwidth and a minimal number of hops are required for optimum accelerator performance as a result of the communication required between SAP NetWeaver BW and the accelerator. The network between SAP NetWeaver BW and the accelerator must be 1 Gbit/sec or faster and should be dedicated to handle only this traffic. To guarantee and support optimal accelerator performance, SAP requires that the accelerator blades be in the same subnet as SAP NetWeaver BW and that this subnet be used exclusively for the accelerator.
Configuration dependencies. Another prerequisite for the accelerator is the SAP NetWeaver BW software version. Depending on your current system configuration, you might have to update or upgrade SAP NetWeaver BW before you can implement the accelerator. You must implement the latest SAP Notes relevant to the accelerator and make sure that you have the latest accelerator revision and BW Support Package.
The accelerator currently requires SAP NetWeaver BW 7.0 Service Package 9 at the minimum. If you are using an earlier version of SAP NetWeaver BW, then you must upgrade your platform first. Each SAP NetWeaver BW Support Package has a minimum accelerator revision level required. For more information, refer to SAP Note 1148111 (“BIA Revision / BI Support Package – Compatibility”).
Note
Certified third-party front-end tools using published SAP interfaces also benefit from the accelerator because the front-end tools communicate with the analytic engine, which decides whether the system reads data from the accelerator or from database tables. The only exception is that the SAP BusinessObjects Polestar does not use the MDX protocol and the analytic engine. It communicates directly with the accelerator to explore the indexed SAP NetWeaver BW data. To support this scenario, the SAP NetWeaver BW software must be Release 7.0, Enhancement Pack 1, Service Package 2 at a minimum. The latest Service Package is recommended. For more information about SAP BusinessObjects Polestar, refer to
www.sap.com/solutions/sapbusinessobjects/large/intelligenceplatform/bi/search-navigation/polestar/index.epx.
Blueprint
Now that business and IT have approved your SAP NetWeaver BW Accelerator implementation, you can decide what data you want to index in the accelerator, which develops into the accelerator sizing and landscape exercises.
Scoping. Proper accelerator scoping is a critical exercise because it has to be initially sized and ordered based on this information. When scoping an accelerator project, there are two approaches for selecting the InfoCubes that you want to index into the accelerator:
- Select the high-priority queries and InfoCubes. This is the “pay only for what is important” approach.
- “Let’s go with everything,” no matter the size or the business priority of the InfoProvider. The most important InfoCubes might already represent 90% to 95% of the overall volume of data, so why not include the remaining 5% to 10%? An additional argument for this approach is to ensure consistent experience — users become accustomed to fast query responses for accelerator-indexed InfoCubes. Low query performance for non-accelerator-indexed InfoCubes might generate end-user frustration and additional calls to the BW support team.
Note
One of the least known accelerator benefits is its ability to boost the performance of real-time InfoCubes and planning applications such as Business Planning and Simulation (BW-BPS) or BI Integrated Planning (BI-IP). In particular, the accelerator can significantly improve the SAP NetWeaver BW read time of the planning function execution. In one of the proof of concepts, the accelerator contributed to reducing the time from eight hours to one hour for a planning function executed as a nightly batch job. Remember that in planning mode, real-time InfoCubes require asynchronous roll-ups for closed requests. You can set this in the InfoCube properties using the “Roll-up data in the aggregate automatically” option.
Fit analysis. Although many companies end up with the second approach (index all InfoCubes) when scoping the accelerator, that approach still requires a review and fit analysis of the InfoCubes and queries initially selected. When deciding what InfoCubes to index into the accelerator, it is important to review the InfoCubes and queries to analyze where the accelerator can help and where it might not help based on the accelerator’s technical functions and limitations of the current software release. The accelerator fit for your InfoCubes and queries should be carefully considered based on the scenarios provided in Table 2.
Tiny InfoCubes
|
If one of the InfoCubes you want to index contains only a few thousand records, adding this data from the accelerator does not provide any significant performance benefit to the queries from that small InfoProvider. Instead, it penalizes all other queries because of the increase in the overhead on the SAP NetWeaver BW to the accelerator connection.
|
Sources of data other than InfoCubes
|
The accelerator does not currently work with sources of data other than InfoCubes. Consequently, you cannot create accelerator indexes for DataStore objects (DSOs), InfoSets, Virtual Providers, and InfoObjects as InfoProviders.
|
MultiProviders
|
One of the common misunderstandings with the accelerator is that the queries built on MultiProviders work with the accelerator indexes. As of the current version, the BW Administrator Workbench does not provide the option to maintain accelerator indexes when you right-click a MultiProvider. (A MultiProvider is just an aggregation of data from different InfoProviders.) As long as all the underlying InfoCubes are indexed in the accelerator, the MultiProvider queries that read data from the base InfoCubes benefit from the accelerator indexes as well.
|
InfoSets
|
InfoSets do not use the accelerator. If a given InfoCube is set up to only read through InfoSet queries, then indexing this InfoCube in the accelerator is not justified.
|
InfoCubes with zero record elimination
|
When InfoCube fact tables are compressed with zero records elimination, running queries with the accelerator could lead to different or unexpected query results compared to database query results. For such InfoCubes, indexing in the accelerator is not recommended to ensure optimal performance.
|
Virtual key figures
|
The accelerator may lead to different results when used for queries that contain virtual key figures that are not well defined. For more information and examples, refer to SAP Note 1143411 (“BWA, virtual key figures and characteristics”). If you want to deactivate the accelerator for queries with virtual key figures, refer to SAP Note 1149760 (“Do not use BWA index for queries with virtual key figures”).
|
|
Table 2 |
Scenarios in which you cannot (or should not) use the accelerator |
Landscape. Key landscape considerations for the accelerator include:
- The production SAP NetWeaver BW Accelerator instance can be connected to only one production SAP NetWeaver BW instance. If your organization has multiple production SAP NetWeaver BW systems, each of them require a separate accelerator system.
- You pay for the SAP licenses only for the production SAP NetWeaver BW Accelerator (i.e., the accelerator connected to the production SAP NetWeaver BW system).
- High availability configuration with extra backup blades is optional but highly recommended by SAP. Note that the memory of the backup blades is not included in SAP’s accelerator license calculations.
- Similar to aggregate definitions, no transports are associated with the accelerator indexes’ creation and maintenance. Note that transports of process chains from development to production may be required if these objects are not created directly in production.
- You cannot share the accelerator hardware (e.g., rack, blades, and storage) with any other system.
Note
A minority of companies chooses to go live with only one accelerator. This accelerator connects sequentially to all SAP NetWeaver BW instances in the landscape at some point in the project. With only one accelerator in the landscape, that system is first connected to the development or test environments where the IT and business tests are executed. After all the tests are successfully completed and the accelerator is ready for production roll-out, the same accelerator is reconnected to the production SAP NetWeaver BW server. Although this strategy is sufficient for initial roll-out projects, we strongly recommend that you add a pre-production accelerator system as soon as your budget allows for testing purposes and to minimize risks on your productive system. For instance, it is critical to test new Support Packages and features, such as package- wise data read, in pre-production before moving them to the production system.
Sizing. For optimal query performance, it is critical to adequately size the accelerator hardware, including the total available memory, total number of CPU cores, and storage unit size. Adequate sizing prevents you from loading too much data into the accelerator and ensures optimal performance. The hardware required depends on the number and size of the InfoCubes that you plan to index in the accelerator as determined by the scoping exercise. The accelerator system should not be undersized to ensure that it is prepared for data growth and future scope additions.
You can use Quick Sizer to capture sizing information for SAP NetWeaver BW Accelerator. Go to https://service.sap.com/quicksizer for more information. Most of the data captured for the accelerator sizing is the same as for the SAP NetWeaver BW sizing. SAP also provides a program that analyzes an InfoCube and estimates the memory consumption of the accelerator index. For more information, refer to SAP Note 917803 (“Estimating the memory consumption of a BIA index”).
As a rule of thumb, you should base the sizing of the blades on a 50% memory use to allow enough memory for high user activity, large data requests, temporary indexes (e.g., for hierarchy node selections), and for processing SAP NetWeaver BW query requests. After the initial implementation, it is important for the Basis team to monitor the accelerator resources because resizing is required if additional data and InfoProviders are indexed or more users are running queries against the accelerator.
Building team expertise. Your BW functional and Basis teams need to gain experience in the administration and support of this new technology. The best strategy for accelerator training is a combination of formal education delivered through standard SAP courses or knowledge transfer by experienced consultants, as well as hands-on practice with accelerator index creation, maintenance, and deletion in your pre-production accelerator. If your organization acquired only one accelerator system, the least risky approach to practice with the accelerator is to create a copy of several productive InfoCubes and let the BW team test the accelerator indexes using those test InfoCubes.
Technical optimization (optional). You can implement the accelerator based on your existing SAP NetWeaver BW applications. It does not require redesign of your data model or configuration. Although some modeling guidelines might become less relevant, SAP recommends that you continue to follow best practices for data modeling and data management to achieve optimal accelerator query performance.
In some cases, you may want to consider some back-end or front-end technical optimization to achieve optimal performance. The decision to include technical optimization work into your accelerator implementation project affects staffing and budget, but is certainly worth considering. The sidebar “Technical Optimization Techniques” provides an overview of the technical optimization techniques that may bring optimal accelerator performance.
Realization
You have obtained funding for the accelerator project, gone through the purchasing process, and your SAP NetWeaver BW Accelerator hardware is now delivered, installed, and connected successfully.
The fact that the accelerator is connected to your SAP NetWeaver BW system does not yet mean that queries are running faster. After the accelerator indexes are created and filled with data, the analytic engine can start using the accelerator for fast data selection and aggregation. Building the accelerator indexes is a relatively easy process, although there are a number of steps required to successfully roll out SAP NetWeaver BW Accelerator to your users in a controlled fashion.
Changes to process chains. The accelerator is not just a piece of hardware that provides additional memory for boosting query performance. It also requires integration with the SAP NetWeaver BW data flow to ensure that the data in the accelerator indexes is correct and in sync with the database. One of the critical points for optimal accelerator performance is understanding how data is filled initially in the accelerator and how updates of transactional and master data on the SAP NetWeaver BW side flow into the accelerator.
The key point to understand is that data updates to the accelerator happen during the roll-up and change run processes, similar to the aggregate update process. It is important to keep the data update process in mind to guarantee proper updates of the accelerator indexes and correct accelerator query results. After identifying the InfoCubes you want to index in the accelerator, you need to review the existing process chains for these InfoCubes and determine if the process chain already has a roll-up step at the end (the roll-up step is there already if the InfoCubes had aggregates). If aggregates were not built for a given InfoCube and you create an accelerator index for this InfoCube, then you need to add the roll-up step in the associated process chain. If it is not already in place, you may also want to add notification of roll-up errors in process chains related to the roll-up process because that process is critical to optimal accelerator performance.
If you are using the delta feature for the indexes for some of the InfoCubes that are included in the accelerator, you may want to modify the existing process chains or add a process chain to schedule the merging of the delta indexes and a periodic full rebuild of these accelerator indexes for optimal performance.
If you maintain and transport your process chains from development to production, you need to select the check box End Process Successfully If No Aggregates Exist in the roll-up step’s variant. This setting prevents the process chain from failing in environments in which the accelerator may not be connected to SAP NetWeaver BW.
Note
Most organizations reported change run times of less than a minute on average. The associated change run is fast due to the fact that only master data has to be updated to the accelerator index (no transactional data is updated during the change run process).
Changes to data model and queries. The accelerator should fit seamlessly into your existing SAP NetWeaver BW environment. When activating the accelerator for the selected InfoCubes, you do not need to change the data model (InfoCubes and DataSources) or the queries (in contrast to the obligatory changes in process chains). For future developments, SAP recommends continuing to follow best practices for data modeling.
One common misconception is that you have to design the accelerator indexes much like you have to design standard SAP NetWeaver BW aggregates. That is not the case — no design decision is needed with regards to what data to include in the accelerator index. You either index an InfoCube into the accelerator or you do not.
Changes to authorization. The accelerator administration and support require minimal adjustments to the existing authorizations. The main authorization prerequisite is that you must create new technical roles for the accelerator administration. These roles are responsible for creating, maintaining, and deleting accelerator indexes. Also, the authorization object for the accelerator indexes is the same as the authorization object for aggregates.
- The roles include all accelerator-related transactions and programs, such as RSDDBIAMON (SAP NetWeaver BW Accelerator maintenance monitor) and TREXADMIN (TREX administration tool) or program RSDDTREX_INDEX_DELETE to delete accelerator indexes. Access to the critical accelerator transactions RSDDBIAMON and TREXADMIN should be available only to the Basis team. These authorizations are controlled by field RSADMWBOBJ = 'BIA_ZA' in authorization object S_RS_ADMWB.
We recommend that you carefully review and decide who has access to these new accelerator technical roles because of the impact that accelerator index management may have on your system.
Other dependencies. Other dependencies may exist with the accelerator. For instance, if you use Analysis Process Designer (APD), it is important to keep in mind that APD queries can be very large and could affect SAP NetWeaver BW and the accelerator system performance negatively. You may want to disable the accelerator for APD because the system typically executes APD queries in the background and APD performance has lower priority compared to SAP NetWeaver BW query performance. For more information, refer to SAP Note 1231794 (“APD: Using the BWA to read InfoProvider data”).
Initial indexing. The initial indexing in the accelerator usually takes a long time depending on the underlying data model and the power of the available hardware. As a rule of thumb, index build times should be between one and three million rows per minute. Indexing data in your test landscape should involve analysis of data volumes in the InfoCubes combined with the tuning of accelerator parameters to achieve optimal performance during initial indexing.
Similar to delta data loads, you can set up accelerator indexes as delta accelerator indexes to minimize the time needed to add new data into the accelerator index with each data load, as opposed to a full index that requires a full merge. You can adjust the accelerator index type after the initial accelerator go-live as part of the maintenance and fine tuning of the system. As shown in Figure 1, you can turn the settings on or off in transaction RSDDBIAMON2 under the menu BI Accelerator > Index Settings > Set Delta Index > Change property of delta indexes.
As with delta data requests, you should use delta accelerator indexes only for frequent data loads with small requests relative to InfoCube size. For example, do not use delta accelerator indexes for InfoCubes with a full load. To guarantee optimal results, avoid delta indexes for InfoCubes that include loads with the option to delete overlapping requests.
Tip!
As a word of caution, you should avoid performing the initial accelerator index creation during heavy data load or reporting periods. Weekends may be the optimal time for initial indexing. Also, avoid running accelerator index creation and filling jobs in parallel to avoid locks on shared master data and system overload.
Testing. Thorough testing is critical for an accelerator project’s success and to minimize risks to the queries in your productive SAP NetWeaver BW systems. For best results, be sure that your tests include performance, data correctness, user acceptance, regression, integration, and authorization. Table 3 provides the key tests recommended during an accelerator implementation.
Performance test
|
A performance test assesses and quantifies the query performance improvements achieved with the accelerator. The performance test may also help in identifying the rare cases in which the accelerator did not boost query performance significantly. It can also highlight other potential areas for performance improvement, such as query optimization or accelerator tuning.
|
You can execute performance tests through a benchmark test consisting of running selected queries and measuring query runtimes (including navigations such as drill-downs) before and after the accelerator implementation. You should select the slowest queries or queries with a runtime of more than a minute.
|
Data correctness test
|
It is critical to test the data correctness in the accelerator indexes to prevent situations in which results may differ between accelerator queries executed and queries run from the database.
For this test, query results are compared for a number of queries before and after you implement the accelerator.
|
During the data correctness test, you can temporarily disable the accelerator for a given InfoCube or query to provide the query results before you implement the accelerator. To disable the accelerator for an InfoCube, go to the BIA Monitor (transaction RSDDBIAMON) and then go to Index Settings > Switch On/Off BIA Indexes for Queries. To disable the accelerator for a single query, refer to SAP Note 1161525 “Do not use BIA for queries: Setting the NOHPA indicator.”
|
User acceptance testing
|
User acceptance test (UAT) refers to the testing your organization performs.
|
The UAT for the accelerator can comprise a subset of the performance and data correctness tests.
|
Regression testing
|
Regression testing confirms that the configuration changes made for the accelerator do not adversely affect the existing functionality of the SAP NetWeaver BW system (e.g., process chains and SAP Notes applied)
|
Regression test scenarios should include the nightly data load process as well as any custom development that may insert, update, or delete data directly against standard SAP tables, including customizing, master, and transaction data tables. Such custom development may negatively affect the accuracy of the data in accelerator indexes and compromise the accuracy of the accelerator queries.
For example, if you developed a custom ABAP program to directly update the SID table for navigational attributes (/bic/x... ), such updates completely bypass the logic to alert the accelerator in case of master data changes.
|
Integration testing
|
Integration testing verifies that the accelerator works as designed and integrates with other functions without causing problems in any integrated areas. It is especially important to test the accelerator’s effect on other integrated areas such as the Strategic Enterprise Management (SEM) Management Cockpit, BW-BPS, and APD.
|
Keep in mind that APD queries can be very large and could affect system performance negatively (with or without the accelerator). If possible, you should test APD queries in the test environment — as long as the data volumes in the test environment are indicative of the data volumes in production.
|
Authorization test
|
The authorization test confirms that the proper roles and access are in place for the accelerator. In the context of the accelerator, the authorization test is limited to the SAP NetWeaver BW and accelerator development and support team because the accelerator does not require or affect the end users’ access.
|
The authorization test should basically verify that the SAP NetWeaver BW and accelerator development and support team can access the accelerator transactions required to perform accelerator administration and maintenance, and cannot access critical accelerator transactions that may be reserved for the Basis team (e.g., RSDDBIAMON and TREXADMIN).
|
|
Table 3 |
Key tests recommended during an accelerator implementation |
Support model. When preparing SAP NetWeaver BW Accelerator for production use, be sure to update your SAP NetWeaver BW support model.
- Train the super users and IT call center about how the accelerator affects end- user experience. Explain how to answer common questions or when (and where) to escalate potential accelerator issues.
- Define a clear split of responsibilities between application, Basis, and infrastructure support. For example, monitoring the accelerator memory use is one of the most important tasks for the Basis team to guarantee optimal accelerator performance.
- Define standard operating procedures for the accelerator. For example, you should have a clearly defined procedure for scenarios in which the accelerator may be down for maintenance.
- Define a distribution list for alerts sent from the accelerator automatically
Change management procedure. Minimal change management is required for end users because the accelerator does not affect the look and feel of the reports. However, it is critical to update your change management procedure to ensure that the SAP NetWeaver BW development team understands the impact of adding InfoCubes or making changes to InfoCubes that are indexed within the accelerator. For example:
- Adding navigational attributes or key figures to an InfoCube indexed in the accelerator results in the deactivation of the BW index. This requires either an adjustment or a full rebuild of the accelerator index.
- InfoCubes created after you implement the accelerator are not automatically added to the accelerator. If the queries in these new InfoCubes require an additional performance boost from the accelerator, then you need to index these InfoCubes into the accelerator and update the associated process chains accordingly.
- Data changes, additions, archiving, or deletions from InfoCubes may require roll-up or merging of the delta accelerator index.
Getting Started
You now understand the critical steps and lessons learned when implementing the SAP NetWeaver BW Accelerator, and you should be well equipped to start planning for that project. As with any SAP project, keep in mind that each organization has unique requirements and configuration that may necessitate additional considerations in the context of the accelerator. For instance, when reading high data volumes within the accelerator, various options can be implemented, including activating "Package-Wise Read" to ensure all data can be read without memory overflow and activating "Formula Element Selections (FEMS) compression" to eliminate redundant data in query results on the accelerator side and reduce query data transfer costs.
Note that the factors that affect the complexity and duration of your accelerator project may include:
- Methodology and approach used
- Complexity of the SAP NetWeaver BW applications and landscape (e.g., APD or BW-BPS)
- Organization complexity
- Data quality
- Number and skills of resources
- Involvement of an experienced SAP NetWeaver BW Accelerator resource
- Number and complexity of queries
- Concurrence with other projects, such as BW development projects and SAP ERP Central Component (SAP ECC) or SAP NetWeaver BW upgrades
- Number of users
The accelerator supplements traditional performance optimization techniques — such as aggregates and information broadcasting — but does not replace them. Although some technical optimization techniques become less relevant with the accelerator, several techniques can lead to even better query performance with the accelerator indexed InfoCubes or easier accelerator index maintenance. Applicable optimization techniques with the accelerator include housekeeping and data management, query optimization, logical partitioning, and calculations and transformations optimization.
Housekeeping and data management. You can implement SAP NetWeaver BW Accelerator independently of other performance optimization techniques. However, before you implement the accelerator, you may want to consider other housekeeping or performance optimization activities, such as deleting unused queries or archiving historical data. In most organizations, reports are run on the most current data and very rarely use data that is more than two or three years old. Rather than unnecessarily loading SAP NetWeaver BW with data that is seldom used, it is generally beneficial to archive some of the historical data. This results in faster accelerator indexes creation, shorter change runs, and significantly improved query performance. T he stability and performance of the accelerator may be negatively affected and queries may be terminated if the accelerator is overloaded.
Query optimization. You may want to consider a review and optimization of the key queries. Keep in mind that the accelerator improves database time but not OLAP or front-end time. It might be beneficial to target query optimization efforts at queries with high OLAP or front-end time. If at all possible, you should try to avoid or minimize the use of OLAP-intensive operations such as sorting, formula calculation before aggregation, exception aggregation, top-n or bottom-n, zero suppression in query properties, and conditions-and-exceptions reporting. You may also want to test and adjust the query read modes if applicable.
Process chains optimization. Because process chains play a critical role in the maintenance of the accelerator indexes, you should also review and update the process chains before implementing the accelerator. If your batch window does not complete in a timely fashion before the start of the business day or is prone to failures, you may want to optimize your extraction to make sure that extraction and update of data to the accelerator occurs before the start of the business day. The accelerator should not significantly add time to your daily batch window in terms of the change run, but it will require time and system resources for the update (roll-up) of its indexes. You may also want to review all existing process chains for other optimization opportunities (e.g., ensure that database statistics are periodically updated and move data loads to weekly rather than daily if applicable).
Calculations and transformations optimization. Based on the current internal capabilities, the accelerator is not used for calculations. The analytic engine performs all query calculations, such as formulas or query conditions, after the selected and aggregated data is returned from the accelerator. You can achieve significant improvement with the accelerator by moving the calculation of key figures out of the query designer and into transformations to take place during data loads. The drawback of using this technique is the loss of flexibility when modifying these calculations. Consequently, the best candidates to move from calculated key figures into regular key figures are enterprise business-approved KPIs because those formulas are unlikely to change.
Note
You might have heard that the next release of the accelerator (7.2) will have more built-in analytics functionalities. The new features are not related to calculations, but to functionalities that could reduce the amount of data transferred from the accelerator back to the analytic engine, such as query conditions evaluation or unit and currency conversions.
Logical partitioning. Logical partitioning is a widely used technique to improve query performance in SAP NetWeaver BW without the accelerator. With logical partitioning, multiple dialog work processes are executed in parallel on different database tables. With the accelerator in place, this partitioning approach may no longer be required. Because the accelerator has built-in parallel capabilities, it is more beneficial for it to get one request from SAP NetWeaver BW and then manage parallel data reads and aggregation internally, rather than trying to manage multiple parallel requests. You should analyze the application of this optimization technique against detailed requirements for and against logical partitioning as highlighted in Table A.
Multiple InfoCubes
|
You cannot combine data distributed across multiple InfoCubes due to authorization requirements into a single DataStore
|
Data logically partitioned by years
|
Data logically partitioned by years does not necessarily need to be combined into only one InfoCube. This decision can be made based on an analysis of what years the users most often query. In most scenarios, more than 90% of the reports are against current and previous years. If that is the case, then you can combine only the most recent data into a single InfoCube and index it in the accelerator. All previous years may remain in separate InfoCubes that do not require accelerator indexes.
|
Deletion of requests
|
The deletion of requests from an InfoCube indexed in the accelerator does not delete data from the fact index in the accelerator. Instead, it only deletes the request ID from the package dimension index in the accelerator. If a request is deleted in SAP NetWeaver BW, the query results are still correct, but the physical fact index contains some unused data.
The impact of multiple request deletions from InfoCube is accelerator query performance degradation. The only way to improve this performance is to do a complete accelerator index rebuild for the InfoCubes with multiple request deletions.
The best practice is to create a separate InfoCube as a target for InfoPackages with active deletion of overlapping requests (full loads of transactional data). With this design, you need to rebuild accelerator indexes only for this InfoCube, which is much faster.
|
|
Table A |
Scenarios for and against logical partitioning |
|
Catherine Roze
Catherine Roze is a senior BI consultant with more than seven years of full life cycle experience in SAP reporting and SAP NetWeaver BW with special focus on SAP NetWeaver BW enterprise reporting, performance optimization, and SAP NetWeaver BW Accelerator. A seasoned BI professional, she has contributed to more than 15 SAP NetWeaver BW implementation projects for Fortune 500 companies. Catherine holds an MBA and MS (industrial technology) and is the author of SAP BW Certification: A Business Information Warehouse Study Guide.
You may contact the author at cmroze@yahoo.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.

Vitaliy Rudnytskiy
Vitaliy Rudnytskiy is a senior SAP NetWeaver BW consultant with Hewlett-Packard Enterprise Services. He has more than nine years of experience in SAP and non-SAP data warehousing and business intelligence. His strategic focus is SAP NetWeaver BW enterprise architecture. During the last three years Vitaliy contributed to more than 25 installations of SAP NetWeaver BW Accelerator in USA, Canada, Mexico, Germany, and Singapore. Vitaliy presented at multiple conferences and he is the top contributor to the SAP NetWeaver BW Accelerator forum on the SAP Community Network (SCN). Vitaliy holds a degree in computer science from Wroclaw University of Technology, Poland. Vitaliy expresses his thanks to colleagues Jens Doerpmund, Hans Blok, and Sarah Plunkett for their review and feedback.
Vitaliy will be presenting at the upcoming SAPinsider HANA 2017 conference, June 14-16, 2017, in Amsterdam. For information on the event, click
here.
You may contact the author at vitaliy.rudnytskiy@hp.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.