Industry Leading BI Performance With System i and DB2 for i5/os Using BI on SAP NetWeaver. Susan Bestgen System i ERP SAP team

Transcription

1 Industry Leading BI Performance With System i and DB2 for i5/os Using BI on SAP NetWeaver Susan Bestgen System i ERP SAP team

2 SAP product offerings have been available on the IBM System i TM platform since 1996 with availability of SAP R/3 on release V3R6 of the AS/400. From its inception, SAP and IBM teams have worked cooperatively to provide a solution which leverages the advantages of System i: architected integration of system components, simple system administration, low total cost of ownership, and competitive hardware components. Critical to the success of SAP offerings on System i is the integrated database, DB2 for i5/os TM. Cooperative development has enabled SAP solutions on System i to take advantage of unique performance and functional features of DB2 for i5/os. Likewise, DB2 for i5/os has continually delivered enhancements to satisfy requirements and improve performance specifically for SAP products. Many of these product specific enhancements have the extra benefit of improving other solutions and database performance in general. A highlight of this collaboration is the industry leading 1 performance in BI (Business Intelligence) of the SAP BW (Business Information Warehouse) and BI-D (Business Intelligence Datamart) benchmarks on System i with DB2 for i5/os. Certified 2 results include: Ten #1 certifications in 2 years #1 in SAP BW in 4-way, 8-way and 16-way configurations #1 in SAP BI-D in 4-way and 8-way configurations This paper will provide a brief introduction to the SAP NetWeaver TM Business Intelligence solution as implemented on System i and its BW and BI-D benchmarks. It will also discuss the technology features, many of which are patented, of DB2 for i5/os that contribute to its performance success in the Business Intelligence technology segment in general and specifically to SAP. BI Overview BI refers to applications, tools and technologies which are used to gather, provide access to, and analyze data and information about operations of a company. BI systems help companies make better business decisions by providing a comprehensive view of the data needed to make these decisions, such as sales, production, and internal operations. BI designs typically involve a large number of interrelated tables which must be joined together and summarized via queries to generate the desired business content. These 1 Industry leading at time of publication of this paper. 2 Official certifications can be viewed at and Page 2 of 23

3 designs are often called star or snowflake schemas, due to the way the data within the tables interrelate visually. In general, a central file at the center of the design (the fact table) joins to multiple dimension tables, thus creating the star schema. If some of the dimension tables join to other tables, this is referred to as a snowflake schema (Figure 1). As business content grows, the number of files, size of the files, and the complexities of queries that retrieve relevant data from the business content grow in size and complexity. Therefore, factors such as system stability, database maintenance and administration and query performance are key considerations when choosing a database platform on which to build a BI solution. Dimension Table Dimension Table Fact Table Dimension Table Dimension Table Dimension Table Dimension Table Dimension Table Fact Table Dimension Table Star schema Dimension Table Figure 1: Star and snowflake schemas Snowflake schema Page 3 of 23

4 BI in SAP NetWeaver The current SAP BI solution is a component of SAP NetWeaver 2004s 3, an application builder platform for integrating business processes across various systems, databases and sources (Figure 2). BI in SAP Netweaver enables data integration from across the enterprise and beyond and transforms it into business information. It supports data warehousing, business intelligence, business planning, measurement and management, and other BI services. SAP NetWeaver PEOPLE INTEGRATION Multi channel access Portal Collaboration Composite Application Framework INFORMATION INTEGRATION Business Knowledge Mgmt Intelligence Master Data Mgmt PROCESS INTEGRATION Integration Business Broker Process Mgmt APPLICATION PLATFORM Life Cycle Mgmt J2EE ABAP DB and OS Abstraction - DBSL SAP NetWeaver TM Figure 2. SAP NetWeaver DB2 for i5/os DB2 for i5/os is one of many integrated components in System i. It is often one of the best kept secrets of System i. Because it comes pre-installed and is started and stopped with the machine, most System i users are DB2 for i5/os users and are not 3 SAP initially introduced Business Intelligence capabilites with its SAP BIW (Business Information Warehouse) offering. SAP BIW has also been referred to as SAP BW. Further references in this paper to the SAP BI offering will use the current naming of BI in SAP NetWeaver. Page 4 of 23

5 even aware of it. The self-maintaining and self-optimizing features of DB2 for i5/os (detailed later in the Innovation section) allow the database to perform well for general use without a database administrator, which makes it an ideal platform on which to implement SAP NetWeaver applications. The architecture of System i (Figure 3) consists of the user interface and higher level operating system layer, a technology independent machine interface (MI), and system licensed internal code (SLIC), which interfaces with the firmware and hardware. In V5R2, DB2 for i5/os introduced a major database upgrade which is termed SQE (SQL Query Engine). This new engine was written to exploit the architecture of System i to enable improved performance of SQL (Structured Query Language) queries. Whereas the preexisting (and still fully functional) CQE (classic query engine) optimization resides above the MI, much of SQE s optimization work and new statistics manager reside in SLIC. This provides faster performance and access to more powerful hardware interfaces, giving SQE the tools to optimize and implement SQL queries with improved performance. This design has also enabled a suite of state-of-the-art query performance analysis tools. A query dispatcher is the initial step for query optimization for both CQE and SQE, and it determines which queries are candidates for SQE and routes work accordingly. SQL queries are candidates for optimization by SQE. SAP NetWeaver queries are written in SQL and thus fall into this category. Therefore, further reference to DB2 for i5/os in this article implies functional and performance features of release V5R4 SQE and will be referred to as DB2. System i5 Higher-level functions exposed to users and applications based on SLIC services Graphical user interface Database interfaces and functions Technology Independent Machine Interface System Licensed Internal Code (SLIC) Process control Resource management Integrated SQL-compliant database Security enforcement Network communications File systems Storage management Java Virtual Machine (JVM) Other primitives System i5 64-bit POWER DB2 for i5/os and SQE High level language programs Interactive query tools System level data access APIs Query Dispatcher Query Optimizer Technology Independent Machine Interface System Licensed Internal Code (SLIC) Integraged Query Engine: Query Optimizer Query Primitives Statistics Manager System i5 64-bit POWER System i5 and DB2 for i5/os - Integrated by Design Page 5 of 23

6 SAP NetWeaver using DB2 Figure 3. System i5 and DB2 for i5/os SAP NetWeaver contains both common and platform specific components for database access in both 2 and 3 tier environments. The platform specific code in SAP NetWeaver for the supported database products is named DBSL (database shared library). Each platform specific DBSL interfaces with the database product using SQL through a protocol mutually agreed upon between SAP and the database vendor. In the case of i5/os, DBSL interfaces with DB2 using system APIs for extended dynamic remote SQL (Figure 4). These APIs are integrated with the SQL component of DB2, which invokes the query dispatcher for optimization and implementation of the queries. This interface protocol has been in use since the introduction of SAP R/3 on AS/400 release V3R6. With the initial release of the product, many functional and performance enhancements were added to the remote extended dynamic APIs specifically for SAP NetWeaver. Since then, additional APIs and enhancements to existing APIs have been consistently delivered each release to support new SAP functions and continued performance gains. DB2 is truly optimized for SAP NetWeaver, from the API interface to the System Licensed Internal Code. Application System i Server SAP NetWeaver PEOPLE INTEGRATION Database Multi channel access Composite Application Framework Portal Collaboration INFORMATION INTEGRATION Business Knowledge Mgmt Intelligence Master Data Mgmt PROCESS INTEGRATION Integration Business Broker Process Mgmt APPLICATION PLATFORM Life Cycle Mgmt Database components: Extended Dynamic Remote SQL APIs Query Dispatcher Query Optimizer Technology Independent Machine Interface System Licensed Internal Code (SLIC) Integraged Query Engine: Query Optimizer Query Primitives Statistics Manager J2EE ABAP DB and OS Abstraction - DBSL System i5 64-bit POWER Figure 4. Sap NetWeaver and DB2 for i5/os Page 6 of 23

7 Joint development effort is evident in SAP NetWeaver DBSL, which has been designed to capitalize on unique features of the DB2 API interface. Some of the special functions DBSL has implemented include: SQL Statement Direct Map: A 1-1 relationship between SAP NetWeaver Application SQL and SQL Persistent Statements in Packages on the database server provides a fast find and execute path. SQL DA reuse: The SQL DA (SQL Descriptor Area) defines different information based on the statement operation being performed. Typically, this data is validated by the database each time a statement is executed. For open, fetch and execute statements, performance can improved by reusing the DA without validation. DBSL assures the DA is unchanged when one of these operations is repeated on the same statement and then requests DA reuse to improve response time of these operations. Cursor Tracking for reuse of open data paths: Once the database has already optimized and executed a query, it can maintain a fast path to run the query again. DBSL has a method to retain this information and instruct the database to use this fast path to execute the query on subsequent runs. Special hint syntax in the SAP NetWeaver SQL language is recognized by the DBSL and converted to DB2 control interfaces which can give optimizer hints for improved performance (for example, optimize for a single execution of this query instead of the possibility of multiple runs). Dynamic SQL Statement composition (Table Expressions): Generic SQL Statements from BI in SAP NetWeaver are specialized by the DBSL driver dynamically, which results in less time spent in application logic. 2-Tier Direct Drive: SAP NetWeaver configurations can run 2 tier (a presentation manager connected to a single server which runs both application and database work) or 3 tier (one presentation manager, one application server and one database server). In the 2 tier environment, DBSL is optimized for i5/os calls directly into the database engine to avoid communication overhead. Blocked insert: SAP NetWeaver utilizes the blocked insert functionality of DB2 and bundles insert requests into a block of rows instead of inserting a single row at time. DB2 - Innovation for function and performance DB2 s integration into i5/os and its tight coupling with the other integrated components of the operating system, combined with innovative technology, yields a database that boasts many high performance, self-managing features. In addition, the collaboration between SAP and IBM to deliver and continually improve the SAP NetWeaver Page 7 of 23

8 application suite on System i has resulted in functional and performance improvements in DB2 in each release since V3R6 to optimize it for SAP NetWeaver. The following list of DB2 functional and performance features showcase technology that makes this database an ideal basis for running SAP NetWeaver in general and for gaining superior performance of BI applications. Some of the features are further categorized as: *Automated Management*: Capabilities which allow the system to manage itself, reducing the need for a database administrator (DBA) to perform maintenance features that are common to many other database platforms. *Automated Tuning*: System self-management of resources for improved performance or query optimizer advances which rewrite queries or add indexes with no DBA intervention for query tuning. *Patented Technology*: Features that have been awarded patents for their innovative technology and design. *Advanced SQL*: Functions of SQL which may have more robust features or higher limits than competitive database offerings. Automatic database, integrated by design *Automated Management* *Automated Tuning* DB2 is embedded in i5/os. There is no need to install the database, start or stop the database, worry about what memory it will reside in, carve out buffer pools or define memory areas. Simply by turning on System i, these tasks have been accomplished. System Managed Database Objects *Automated Management* *Automated Tuning* Most database platforms are separate products from the operating system they run on. Consequently, they must have a method to define and control the database objects (tables, indexes, views, etc.), and manage the space these objects reside in, which is usually referred to as a tablespace. i5/os employs a single level store concept, where storage of all objects on the System i is maintained and managed by the system. There is no defined space for database objects; as long as system storage is available it can be used for database objects. The system automatically determines where tables and indexes reside on storage, manages object growth, and balances the spread of data, which eliminates the need for an administrator to plan and maintain the storage requirements of the database. If the system has multiple storage devices (physical drives or other), system controlled storage can also lead to better performance by spreading the data across multiple physical devices. This can improve performance by allowing parallel data access. Page 8 of 23

9 Applications such as BI in SAP NetWeaver may have tens of thousands of objects in a data collection. System managed database objects save time and expense and improve system availability, which are all critical in managing enterprise resources. Join up to 1000 table members *Advanced SQL* BI applications must manage large numbers of potentially very large tables. The underlying database platform must, at a functional level, be able to process any query generated by the BI application. It is possible for a BI application based on a snowflake schema to generate a join query over hundreds of tables. Some of those tables may be partitioned (each member constitutes one table member). Consequently, DB2 supports up to 1000 table members in order to process the most complex of BI query requests. Blocked fetch and insert *Advanced SQL* Queries may fetch or insert just a single row, or the result may be multiple rows. The interface between SAP NetWeaver s database unique component, DBSL, and DB2 is tailored to implement multi-row operations in as few requests as possible to optimize fetch and insert performance. For fetch operations, the DBSL may request that the database return as many records which will fit into a block. This block size is set by DBSL to 128K for both fetch and update operations. Built in, automatic statistics * Patented Technology * *Automated Tuning* *Automated Management* DB2 includes a cost based query optimizer. The optimal method for accessing data is determined by deriving the cost of several different optimization strategies and picking the lowest cost strategy as the optimal access method. Cost based optimizers rely on statistics, such as the number of rows in a table or cardinality of values for a particular column in a table. Accurate and timely database statistics are necessary for query optimizers to accurately estimate the number of rows which will be processed, which heavily influences the final query implementation plan. While collecting statistics is a manual process for many database products, DB2 implements an automatic, hybrid statistics collection that is always online and up to date. Statistics are maintained in indexes, and they are also kept at the table level for columns where no indexes already exist. Statistics are automatically refreshed without maintenance overhead to the insert/update/delete operation. The automated nature of database statistics in DB2 not only eliminates administrator intervention in keeping the statistics up to date, but it also guarantees the query optimizer has the most up-to-date information on which to base its calculations - which is critical for deriving the best performing query plan. For large BI join queries, this can result in a query that runs in minutes instead of hours. Maintained Temporary Index (MTI) * Patented Technology * *Automated Tuning* Page 9 of 23

10 Another innovative feature of the DB2 optimizer is the autonomic capability to create indexes, which can be described as the ability of DB2 to tune itself. The query engine watches query requests and learns if performance could be improved with system created temporary indexes, called MTIs (Maintained Temporary Index). MTIs do a great job of covering the middle ground of table sizes where an index can provide real value without demanding the considerable investment in processing time necessary to create a permanent index. These indexes can be shared between queries and jobs that benefit from their use, and they are automatically deleted when they are no longer needed. Lookahead Predicate Generation * Patented Technology * *Automated Tuning* Lookahead Predicate Generation (LPG) is a powerful strategy for minimizing query processing and maximizing query performance. Minimizing or even eliminating the reading and processing of unnecessary data is the key to good performance because I/O operations are relatively slow operations. DB2 includes innovative optimization techniques which allow the query to be rewritten to include optimizer generated local selection predicates. These predicates are inferred from relationships defined via join selection in multi-table (join) queries. In applications such as BI in SAP NetWeaver, joins of large files with many join criteria are common. LPG can greatly reduce response time in ad-hoc queries by rewriting the query to minimize the processing of the large amounts of data in BI tables. A detailed description of LPG can be found in the article The Power and Magic of LPG. Materialized QueryTables * Patented Technology * *Advanced SQL* Materialized query tables (MQTs - also referred to as automatic summary tables or materialized views) can greatly improve the performance of BI queries. This is done by precomputing and storing results of a query in the materialized query table. The database engine can use these results instead of recomputing them for a user specified query. The query optimizer will look for any applicable MQTs and can choose to implement all or part of the query using an MQT, provided this is a faster implementation choice. Since BI queries often join many large files and summarize the results, MQTs can provide significant performance improvements for queries that are frequently run. DB2 has additional patented technology to improve the use of MQTs. If selection is built into the MQT to improve performance and reduce its size, the query engine has the ability to perform fuzzy matching - it will compare the actual host variable values in the query to the selection values in the defined MQT to determine if the MQT can be used for the query. Page 10 of 23

11 Additional information on MQT use can be found in the article Creating and using materialized query tables (MQT) in IBM DB2. Encoded Vector Indexes * Patented Technology * *Advanced SQL* Encoded vector indexes (EVIs) are a powerful tool for providing fast data access in decision support and query reporting environments like BI. EVIs are a complementary alternative to existing index objects (binary radix tree structure - logical file or SQL index) and are a variation on bitmap indexing. Because of their compact size and relative simplicity, EVIs provide for fast scans of a table and can also be processed in parallel. If the query optimizer decides to use an EVI to process record selection in the query, the database engine uses the vector to build the dynamic bitmap (or a list of selected row ids) that contains one bit for each row in the table, with the bit being turned on for each selected row. Like a bitmap index, these intermediate dynamic bitmaps (or lists) can be anded and ored together to satisfy an ad hoc query. For queries requesting grouping or distinct values, the symbol table within the EVI contains the distinct values for the specified columns in the key definition, along with a count of the number of records in the base table that have each distinct value. The symbol table in effect contains the grouping results of the columns in that key. Therefore, queries involving grouping or distinct on the columns in that key are potential candidates for a technique that uses the symbol table directly to determine the query result. Grouping functions are commonly used in BI reporting queries. In many cases, performance of BI queries can be improved by creating the appropriate EVIs. Additional information on EVI indexing can be found in the article Indexing and Statistics Strategies for DB2 UDB for iseries. Index Anding / Oring * Patented Technology * DB2 has the ability to use multiple indexes to satisfy multiple selection criteria in a single query. This technique is referred to as index anding and oring. For example, if a user wants to see sales data for a certain region during a certain time period, EVIs can be defined over the region column and the quarter column of the database. When the query runs, the database engine builds dynamic bitmaps using the two EVIs and then ands the bitmaps together to produce a bitmap that contains only the relevant rows for both selection criteria. This anding capability drastically reduces the number of rows that the server must read and test. Built in optimization information * Patented Technology* *Automated Tuning* The end result of query optimization is a plan which is used to access data in the most efficient manner. Collection and analysis of query optimization plan data is essential to improve query performance. DB2 utilizes a plan cache for nearly all SQL queries run on the system. It contains not only the implementation method used to access data for a given query, but also allows Page 11 of 23

12 this plan to be shared by other systems jobs running the query. In addition, it automatically stores a wealth of information about the optimization of the query and provides advice for ways to improve the query performance. This automatic collection of data eliminates the need to manually gather analysis data or rerun a query to determine how it is implemented. It is also used to generate statistics for future optimizations. Coupled with a powerful graphical tool called Visual Explain, available with i5 Navigator, it becomes easy to determine high use queries, long running queries, or queries which might benefit from additional tuning. Visual Explain * Patented Technology * The Visual Explain tool with i5 Navigator creates a query graph that illustrates the implementation of an SQL query statement. Robust capabilities of the graphical representation of the query plan include: Representation of the DB objects and data structures Representation of the query methods and implementation strategy Advice on indexes Highlighting of specific query rewrites Highlighting of expensive methods The paper 5 Essential Ways to Use iseries Navigator Visual Explain provides additional information on Visual Explain. Index advisor * Patented Technology* *Automated Tuning* The availability of the right index can greatly improve query performance. DB2 Index Advisor, combined with i5 Navigator, can simplify the task of building the best indexes for queries that have been run in DB2. The index advisor catalog is created from DB2 plan cache information, which continually provides up-to-date information on what indexes are being advised by the query optimizer. This catalog is externalized in i5 Navigator and provides point and click features to list, and optionally create, indexes recommended by the optimizer to improve query performance. Once created, the indexes are automatically maintained and balanced by the database as data is added and removed from the underlying table. Additionally, the indexes are automatically protected from any unexpected failures with System Managed Access Path Protection (SMAPP). The index advisor also indicates which advised indexes have been created as MTIs. This information helps further hone in on indexes that are most useful. One can continue to let the optimizer maintain the existence of these indexes as MTIs or take ownership of them by creating a permanent index based on the advice. i5 Navigator also shows which indexes already exist over the table to simplify the decision on which (if any) additional indexes to create. Additional information can be found in the article 5 Essential Ways to Use iseries Navigator - SQL Plan Cache. Page 12 of 23

13 Symmetric Multiprocessing (SMP) and parallel I/O *Automated Tuning* Complex BI queries over large files can place high demands on I/O and CPU. Naturally, it makes senses to put multiple processors to work to satisfy the query request with the best use of system resources, which can greatly improve the query response time. DB2 uses its system integration to balance the use of system resources - both I/O and CPU - with other work being performed on the system, to determine the optimal use of multiple tasks to perform parallel I/O and SMP for complex queries. There are two types of parallel processing available on i5/os. The first is parallel I/O, and the second is the DB2 Symmetric Multiprocessing (SMP) program product. For parallel I/O processing, the database manager leverages the storage management component of the operating system to use multiple tasks, simultaneously, to bring data from auxiliary storage into memory for each query. Processing for the CPU is still done serially. SMP, which is an optional product that may be purchased, is the ability for database work to be serviced by multiple database tasks or threads running over multiple processors, where memory and disks are shared. SMP is normally configured to allow the database to determine the parallel processing degree. However, a specific degree of parallel processing can also be specified. Common Table Expressions (CTE) and Recursive Common Table Expressions (RCTE) *Advanced SQL* Common Table Expressions are defined as temporary views that are known only within the scope of a single SQL statement. They can be used as a substitute for a view when a permanent view object is not needed and can be referenced multiple times in the same query. They provide the ability to simplify complex queries and enable recursive queries. A Recursive Common Table Expressions (RCTE) is a CTE with the ability to reference itself. Some applications work with data that is recursive in nature. A Bill of Materials (BOM) application, for instance, works with the expansion of parts and its component subparts. For example, a chair might be made of a seat unit and a leg assembly. The seat unit might consist of a seat and two arms. Each of these parts can be further broken down into its subparts until there is a list of all the parts needed to build a chair. This type of query can be handled by using a recursive common table expression (RCTE). The use of a recursive query to facilitate the access of this hierarchical data can lead to a more elegant and better performing application. Enterprise applications such as SAP NetWeaver can leverage database functions like database enabled CTEs and RCTEs to simply their applications and allow the database to optimize performance. Data partitioning *Advanced SQL* Page 13 of 23

14 In BI applications, it is necessary to be able to store all necessary data without exceeding system limits on object (table) size, yet access this data efficiently. Data partitioning can be considered in installations with large amounts of data to address both of these issues. DB2 has a single table size limit of 1.0 TB (terabyte), which is much larger than many other database solutions. Thus, installations have additional flexibility in making the decision when, or if, to implement partitioned tables. Partitioning allows for data in a single table to be stored in multiple members, but the table appears as one object for data manipulation operations such as queries, inserts, updates, and deletes. The partitions inherit the design characteristics of the table on which they are based, including the column names and types, constraints, and triggers. Partitioning can allow for much more data to reside in a single table (each partition may contain up to the maximum table size) and also enhance the performance, recoverability, and manageability of your database. Each partition can be saved, restored, exported from, imported to, dropped, or reorganized independently of the other partitions. Additionally, partitioning allows for quickly deleting sets of records grouped in a partition, rather than processing individual rows of a nonpartitioned table. Literal Conversion to Parameter Marker *Advanced SQL* Parameter markers are place holders in an SQL statement for literal values which may or may not be available when a statement is prepared but which are known when the statement is executed. DB2 will automatically convert any literals specified in dynamic SQL (which includes the remote SQL APIs used by SAP NetWeaver) to parameter markers. This dramatically enhances statement reuse and improves overall query performance by allowing multiple SQL statements with different literals to map to the same database statement. Statement implementation details are located in the plan cache and reused for streamlined optimization and open processing. Additional capabilities / compatibilities The following features are supported by System i and worthy of mention due to their importance for SAP NetWeaver installations: Unicode Data types such as CHAR ASCII and CHAR EBCDIC are mainly suited to English and central European languages. With the globalization of business activities, applications must be able to accommodate many different languages. Unicode provides the solution by unifying different character sets. DB2 supports both ASCII and Unicode and allows easy upgrading of an existing SAP NetWeaver system to Unicode. SAP NetWeaver databases on Page 14 of 23

15 System i are built with a default database in Unicode. In a 3-tier environment, the application server can be either Unicode or ASCII. BI accelerator The SAP NetWeaver BI accelerator is defined by SAP as "a new appliance-like (integrated hardware and software) product - available as an optional add-on to BI in SAP NetWeaver - that offers performance improvements and query flexibility". BI accelerator is based on Intel processors and provides an alternative to SAP NetWeaver aggregates for improving the performance of both tuned and ad hoc queries. The SAP NetWeaver BI accelerator offering is available to System i installations running BI in SAP NetWeaver. As is the case for other platforms, BI accelerator improves application processing by offloading expensive BI queries from the database and/or application server (dependent on 2- or 3-tier configuration) to the BI accelerator. SAP NetWeaver Business Warehouse and Business Intelligence Benchmarks SAP has two benchmarks in the Business Intelligence application - BW (Business Warehouse) and BI-D (BI-Datamart). The BW benchmark measures both data load and query throughput, while BI-D measures only query throughput. The key measure of query throughput in each benchmark is the highest possible ds/hr (dialog steps per hour), which is an SAP measure of how much query processing the hardware platform, operating system and database can achieve at maximum utilization. Details of each of these benchmarks are outlined at (BW) and (BI-D). SAP Certified Benchmark Results Since 2004, System i has been certifying industry leading SAP BW and BI-D benchmark results. Advances in both hardware and software technology allow for continual improvements in certified benchmark results, which provides SAP NetWeaver users on System i the same performance advantages. In both benchmarks, database vendors have the flexibility to utilize any generally available optimization techniques and strategies to maximize the performance of loading the data (in the BW benchmark) and running the end user queries (in both the BW and BI-D benchmarks). At the time of publishing this paper, System i was the only hardware platform / database vendor to certify benchmark results for BI-D and maintained industry leading numbers for the 4, 8 and 16-way results in BW. System i demonstrates continued leadership and commitment to delivering industry-leading performance for BI solutions. The following charts summarize System i certifications in BI-D and BW. In the case of BW, competitive certifications are included for comparison. Complete details of all certified results are documented at (BW) and (BI-D). Page 15 of 23

16 BW Results System i has certified #1 BW results in 4 core, 8 core and 16 core configurations. The first certification in the fourth quarter of 2004 took leadership in the 4 core configuration. Two subsequent 4 core certifications widened leadership (1Q05) and the 3Q06 submission quickly countered to regain leadership after a certification by HP with Oracle (see Figure 5). I SAP BW 4 core Certifications dialog steps per hour HP/SQL Server 3Q03 System i/db2 4Q04 System i/db2 1Q05 HP/Oracle 3Q06 System i/db2 3Q06 Platform/DB/Certification Date Figure 5. System i 4 core certifications with SAP BW - Query Phase In the 8 core configuration, the first System i certification in 2Q05 easily outpaced the competition. When a competitive number was published by Fujitsu / Oracle in 4Q05, System i again responded to the challenge in 1Q06 by posting a new #1 certification that topped the competition by more than 35% (see Figure 6). Page 16 of 23

17 SAP BW 8 core Certifications dialog steps per hour HP/ SQL Server 3Q03 System x/ DB2 UDB 2Q04 System i/ DB2 2Q05 System i/ DB2 4Q05 Platform/DB/Certification Date Fujitsu/ Oracle 4Q05 System i/ DB2 1Q06 Figure 6. System i 8 core certifications with SAP BW - Query Phase Finally, in the 16 core BW environment, System i took leadership with the 2Q06 certification of 437,760 dialog steps per hour in the query phase, a number that has not yet been challenged (Figure 7). Page 17 of 23

18 SAP BW 16 core Certifications dialog steps per hour Unisys/SQL Server 2Q Fujitsu/Oracle 1Q06 Platform/DB/Certificaiton Date System i / DB2 2Q06 Figure 7. System i 8 core certifications with SAP BW - Query Phase BI-D Results In the BI-D benchmark, System i is the only platform to certify results. The first certification in 1Q07 established 4 core leadership, and was quickly followed with an 8 core certification in 2Q07. The latest 4 core certification (in 2Q07 as well) was based on P6 hardware technology and improved the previous 4 core results by over 78%, again demonstrating the commitment to deliver hardware and software performance improvements and value to System I (Figure 8). Page 18 of 23

19 System i/db2 SAP BI-Datamart Certifications dialog steps per hour Q07 4 core 2Q07 8 core 3Q07 4 core Figure 8. System i Certifications with SAP BI-D Conclusion Partnership, commitment, performance, reliability, scalability, innovation, integration, cost effectiveness, minimal database administration... System i with DB2 for i5/os delivers on all counts with its collaborative effort to deliver outstanding results running BI in SAP NetWeaver. In a business environment that is constantly changing, the platform on which critical business decisions are made must be the foundation. System i with DB for i5/os was designed to meet the challenge starting 12 years ago, leads the industry today, and is committed to delivering for the future. Page 19 of 23

20 Page 20 of 23

21 For More Information 5 Essential Ways to Use iseries Navigator - SQL Plan Cache avigator SQL_Plan_Cache.html 5 Essential Ways to Use iseries Navigator Visual Explain avigator Visual_Explain.html Creating and using materialized query tables (MQT) in IBM DB2 for i5/os Indexing and Statistics Strategies for DB2 UDB for iseries The Power and Magic of LPG Reviewing DB2 for i5/os query optimizer and database engine feedback mechanisms SAP NetWeaver Business Intelligence Star Schema Join Support within DB2 for i5/os - Version Page 21 of 23

22 About the Author Susan Bestgen has worked for IBM Rochester for 19 years. She began her career in database development, focussing on query optimization. For the past 11 years she has worked on the IBM ERP team. She helped with the initial product port of SAP to System i, designing and implementing functional and performance enhancements to the database interface. She currently works on benchmarking and performance of System i with SAP NetWeaver. Acknowledgments The author would like to thank the following people for their technical and editorial comments: IBM Rochester: Rob Bestgen, DB2 for i5/os SQE Chief Architect Michael Cain, DB2 for i5/os Center of Competency Chair Kolby Hoelzle, i5/os Development, SAP on System i Ron Schmerbauch, i5/os Development, SAP on System i Steve Tlusty, i5/os Development, SAP on System i IBM Germany Eric Kass, i5/os Development, SAP on System i Anja Winkler, SAP BI Consultant, SAP NetWeaver BI on System i SAP Germany Dorothea Rink, Senior Developer, Sap NetWeaver on System i Axel Stein, Development Architect, Sap NetWeaver BI on System i Page 22 of 23

23 Page 23 of 23