IBM Technical Brief. IBM System z9 ziip Measurements: SAP OLTP, BI Batch, SAP BW Query, and DB2 Utility Workloads. Authors:

Transcription

1 IBM Technical Brief IBM System z9 ziip Measurements: SAP OLTP, BI Batch, SAP BW Query, and DB2 Utility Workloads Authors: Seewah Chan Veng K. Ly Mai N. Nguyen Howard E. Poole Michael R. Sheets Akira Shibamiya Document Owner: Michael R. Sheets IBM Americas EAS Advanced Technical Support Version: 1.00 Date: October 2, 2006 Filename: SAP_zIIP_System z.pdf Copyright IBM Corporation 2006 All Rights Reserved

2 TABLE OF CONTENTS 1 INTRODUCTION REMINDERS TRADEMARKS FEEDBACK ACKNOWLEDGEMENTS WORKLOAD AND MEASUREMENT BACKGROUND SAP OLTP Workload BI Batch Workload SAP BW Query Workload DB2 Utilities Workload CONFIGURATIONS Hardware System and Software Environment MEASUREMENT RESULTS SAP OLTP Workload BI Batch Workload SAP BW Query Workload DB2 Utilities Workload ANALYSIS SAP OLTP Workload BI Batch Workload SAP BW Query Workload...21 Copyright IBM Corporation 2006 All Rights Reserved Page 2 of 28

3 9.4 DB2 Utilities Workload CONCLUSIONS REFERENCES TABLES Table 1: SAP BW Query Workload Steps...6 FIGURES Figure 1: SAP OLTP Configuration...9 Figure 2: BI Batch Configuration...10 Figure 3: SAP BW Query Configuration...11 Figure 4: ziip Effects - SAP OLTP...20 Figure 5: ziip Effects - BI Batch...21 Figure 6: ziip Effects - SAP BW Query...22 Figure 7: ziip Effects - DB2 Utilities Load Table...23 Figure 8: ziip Effects - DB2 Utilities Load Partition...24 Figure 9: ziip Effects - DB2 Utilities Reorg Tablespace...24 Figure 10: ziip Effects - DB2 Utilities Reorg Partition...25 Figure 11: ziip Effects - DB2 Utilities Rebuild Index...25 Figure 12: ziip Effects - DB2 Utilities Rebuild Logical Partition of a Non-Partitioning Index and Reorg Index...26 Copyright IBM Corporation 2006 All Rights Reserved Page 3 of 28

4 1 Introduction IBM recently introduced the System z9 Integrated Information Processor (ziip) as a specialty engine to help improve resource utilization and lower the cost of portions of eligible workloads. ziips require at least DB2 for z/os V8, a z9 system, z/os 1.6, and, for maximum exploitation in an SAP environment, DB2 Connect. They can also imply specific application software levels such as in the case of SAP. ziips are especially intended for data serving workloads. More information about ziips and data serving can be found at [1, 2]. More information about DB2 for z/os V8 can be found at [3, 4, 5]. This paper describes some measurements done in IBM s Laboratories utilizing z9 ziip hardware and software. Four types of DB2 V8 workloads were measured: SAP OLTP exploiting Distributed Relational Database Architecture (DRDA using DB2 Connect) Business Intelligence (BI) batch direct attached SAP BW query exploiting DRDA DB2 Utility The purposes of these measurements were to: test these functions quantify the degree of redirect to ziips in different environments see if there are any CP costs 2 Reminders Neither this document nor any part of it may be copied or reproduced in any form or by any means or translated into another language, without the prior consent of the IBM Corporation. IBM makes no warranties or representations with respect to the content hereof and specifically disclaims any implied warranties of merchantability or fitness of any particular purpose. IBM assumes no responsibility for any errors that may appear in this document. The information contained in this document is subject to change without any notice. IBM reserves the right to make any such changes without obligation to notify any person of such revision or changes. IBM makes no commitment to keep the information contained herein up to date. 3 Trademarks SAP, R/3, and all SAP product and service names mentioned herein are trademarks or registered trademarks of SAP AG in Germany and several other countries around the world. IBM, IBM ^, iseries, pseries, xseries, zseries, DB2, Universal Database, z/os, z/vm, DB2, Enterprise Storage Server, TotalStorage, FICON, ESCON, and PR/SM are trademarks or registered trademarks of the International Business Machines Corporation in the United States and other countries. Other products may be trademarks or registered trademarks of their respective companies. 4 Feedback Please send comments or suggestions for changes to msheets@us.ibm.com Copyright IBM Corporation 2006 All Rights Reserved Page 4 of 28

5 5 Acknowledgements The authors would like to recognize the contributions of Gopal Krishnan and Terry Purcell. 6 Workload and Measurement Background As part of IBM s continuous testing and measuring of its products, we wanted to investigate the effects of running different workloads with and without ziips. We did not tune these measurements as one might for a benchmark. Initially we started this effort utilizing prototype hardware and software. But the results shown here represent the final designs and implementation. 6.1 SAP OLTP Workload One of the workloads we measured was SAP AG s mysap Database Server doing OLTP type work. We used DB2 Connect to utilize DRDA connected to external AIX SAP application servers submitting work to a DB2 database server from AIX SAP application servers. For this set of measurements, we used a standard Sales and Distribution (SD) workload. However, we did not run the SAP Sales and Distribution Standard Application Benchmark. While there may be some similarity in business functions performed, the measurements we did were stress tests not SAP certified benchmarks. 6.2 BI Batch Workload We also looked at a unique BI batch workload that was run direct attached. That is, there was no use of DRDA. The native SQL came from a script run in the same z/os as DB2. We used a specially developed query set. While this set is based on field experience and observation of customer environments, it was not intended to represent typical customer queries. Rather it was intended to be complex, challenging, and stressful to DB2. It exhibits higher query parallelism than most customers will experience. While the SAP application is not used, SAP BW data, structure, tables and database are. The query load was run against an SAP BW database with F fact table and dimension tables. The queries are run as a locally attached (via DSNTEP4, not DRDA) job. It is a single stream where each query is run sequentially. There are 79 queries, with three additional environmental settings: set SQLID=SAPR3, set current degree=any, and set current timestamp. There is a mixture of CPU bound queries and I/O bound queries. The F fact table was manually partitioned via DB2 to get more parallelism increasing the ziip redirect. It is important to note that the partitioning scheme mirrors that provided by SAP for the F fact table. After partitioning the F fact table, the DB2 Explain tool indicates 57 of the 79 queries are parallel. Copyright IBM Corporation 2006 All Rights Reserved Page 5 of 28

6 6.3 SAP BW Query Workload This third workload employs multiple streams (or multiple concurrent users) submitting queries to DB2 database server via DRDA from AIX SAP application servers. Each user submits three queries per loop (see Table 1 below). These queries result in ten SQL select statements. Each loop has nine of these selects going against F table and one going against the Operational Data Store (ODS) table. About 500+ SAP aggregates are used to provide better average response time. The ODS is a non-star schema type table. In terms of CPU time, the ODS query dominates. Since SAP aggregates are not supported for ODS, the DB2 Materialized Query Table (MQT) provides effective aggregate functions. Further, partitioning of the MQTs reduces the average response time to sub-second. The result is that this workload has very short-running queries that are less complex than the above BI Batch Workload s 79 queries. Step Operation 1 Query 1: Select a year 2 Within the year, drill down to a specific country 3 Within the country, drill down to a specific sales organization 4 Within the sales organization, drill down to distribution channel 5 Within the distribution channel, drill down to type, version, and material number 6 Change material number and customer number 7 Start new query including formulas 8 Query 2: Perform an ODS query limited to customer, distribution channel, sales organization 9 Query 3: Similar to query 1 for country, sales organization, and distribution channel 10 Within this query, expand to material level two 11 Expand to level three Table 1: SAP BW Query Workload Steps We did not run the SAP BW Standard Application Benchmark. While there may be some similarity in business functions performed, the measurements we did were stress tests not SAP certified benchmarks. 6.4 DB2 Utilities Workload The fourth set of workload runs are related to DB2 V8 Utilities [6]. DB2 build index processing in the Load, Reorg, and Rebuild Index utility can be redirected to ziip in DB2 for z/os V8. These measurements were conducted to understand the performance characteristics of Build index redirect, such as the percentage of redirect CPU time of Load table, Load partition, Reorg tablespace, Reorg partition, Rebuild Index, and Reorg Index with different number of indexes as well as the additional cost of redirect. We also had the opportunity with these measurements to test the ProjectCPU function to see what costs that might have. All of these measurements involved a non-compressed table with 20 million rows with 10 partitions and 1, 2, or 6 indexes. Note that some customers have some tables that are much larger such as SAP customers. Copyright IBM Corporation 2006 All Rights Reserved Page 6 of 28

7 7 Configurations 7.1 Hardware System z DB Server: These measurements were done on a two different IBM System z9 Enterprise Class systems. The SAP OLTP, BI Batch, and SAP BW Query measurements were done on a z9 S with four ziips configured and a total of 128 GB installed. That is, the regular CPs and ziip CPs were in the same book. This is the maximum number of ziips that can be configured on this model. The DB server resided on a z/os LPAR with 4 dedicated CPs plus 4 ziips and 16 GB central memory. The base measurements without ziip were done with the ziip processors varied offline. The DB2 V8 Utility measurements were done on a z9 S partition with four CPs and a total of 8 GB of storage. Initial runs were made without ziips configured. Later two ziips were configured and varied online. More ziips could have been configured on this model. The ziip CPs were not necessarily in the same book as the regular CPs. Each of these systems had the requisite service levels installed to support ziips. Customers should consult their local IBM representative or [7] to make sure they have the proper service levels on their system. Database DASD: The SAP OLTP and BI Batch workload measurements used one Enterprise Storage server (ESS or Shark) Model 800 ( ) with a total of 8 FICON attachments to the System z. The was a Turbo I model with 16 8-packs of 15K RPM 36.4GB drives. The actual capacity was volumes. It had 16 GB regular cache, 2 GB non-volatile storage (NVS) and 8 short wave FICON ports. Additionally there were 8 ESCON ports. However, ESCON was not used for these runs. The 8 FICON ports were connected via two MCDATA FICON directors to the z The host used FICON Express4, however, this Model 800 used only 2 Gbps per port. We exploited the new Modified Indirect Data Address Word (MIDAW) CCW function for improved I/O responsiveness. The SAP BW Query measurements used one dual frame IBM TotalStorage server Model DS8300 ( /92E) with a total of eight FICON attachments to the System z. The /92E coupled unit has 48 8-packs of 15K RPM 73 GB drives. The actual capacity was volumes. It had 128 GB regular cache, 4 GB non-volatile storage (NVS) and 32 long wave FICON ports. However, only eight FICON ports were used for the test and they were direct connected to the z The host used FICON Express4, however, this DS8300 used only 2 Gbps per port. We exploited the new Modified Indirect Data Address Word (MIDAW) CCW function for improved I/O responsiveness. DB2 V8 Utility measurements used one ESS Model 800 ( ) with 4 FICON Express2 attachment to the System z. The was a Turbo I model. The database and workload were spread on 34 volumes with additional 14 volumes for workfiles. There were 16GB regular cache, 2 GB non-volatile storage and eight short wave FICON ports. Copyright IBM Corporation 2006 All Rights Reserved Page 7 of 28

8 pseries Application Servers: The SAP OLTP workload used three p690s each with GHz processors and 128 GB of memory. No pseries servers were used with the BI Batch workloads. The SAP BW Query workload used one p570 with GHz processors and one p690 with GHz processors - each has 128 GB of memory. No pseries servers were used with the DB2 V8 Utility workloads. pseries Presentation Servers: The SAP OLTP workload used one p620 with four 600 MHz processors and 4 GB of memory. No pseries servers were used with the BI Batch workloads. The SAP BW Query workload used one p630 with four 1.0 GHz processors and 8 GB of memory as well as one p55a with four 1.9 GHz processors and 32 GB of memory. No pseries servers were used with the DB2 V8 Utility workloads. Network: Gigabit Ethernet networks were used for all network connections. Each of the p690/p570 application servers was connected to the z9-704 via OSA-Express2 adapter. Below are conceptual views of the configurations used. SAP OLTP is shown in Figure 1 Business Intelligence (BI) is shown in Figure 2 SAP BW Query is shown in Figure 3 DB2 Utility is similar to Figure 2 Copyright IBM Corporation 2006 All Rights Reserved Page 8 of 28

9 ziip Measurements: SAP OLTP Configuration w/ 16 8-packs of 15K RPM 36.4 GB drives. 16 GB regular cache + 2 GB non-volatile storage (NVS) Capacity: volumes Enterprise Storage Server: ( ) Two MCDATA FICON Directors 8 FICON connections 8 FICON connections Hardware: DB2 v8 Database Server: One z/os LPAR w/ 4 dedicated CPs plus 4 ziips, 16 GB central memory Software: zos DB2 v8.1 GA Z9-704 (2094) 128 GB Gigabit Ethernet Switch 3 p690 Application Servers (Each) GHz processors/128 GB memory - AIX SAP Kernel DB2 Connect v8.1 FixPak 9 1 p620 (4 600 MHz processors/4 GB memory) Presentation Server Figure 1: SAP OLTP Configuration Copyright IBM Corporation 2006 All Rights Reserved Page 9 of 28

10 ziip Measurements: BI Batch Configuration w/ 16 8-packs of 15K RPM 36.4 GB drives. 16 GB regular cache + 2 GB non-volatile storage (NVS) Capacity: volumes Enterprise Storage Server: Model 800 ( ) 8 FICON connections Two MCDATA FICON Directors 8 FICON connections Hardware: DB2 v8 Database Server: One z/os LPAR w/ 4 dedicated CPs plus 4 ziips, 16 GB central memory Software: zos DB2 v8.1 GA Z9-704 ( ) 128 GB Workstation Batch Job Submission: BI Parallel Queries Figure 2: BI Batch Configuration Copyright IBM Corporation 2006 All Rights Reserved Page 10 of 28

11 ziip Measurements: SAP BW Query Configuration /92E w/ 48 8-packs of 15K RPM 73 GB drives. 128 GB regular cache + 4 GB non-volatile storage (NVS) Capacity: volumes IBM TotalStorage Server Model DS8300: ( /92E) 8 FICON direct connections Hardware: DB2 v8 Database Server: One z/os LPAR w/ 4 dedicated CPs plus 4 ziips, 16 GB central memory Software: zos DB2 v8.1 GA BW 3.5 database Z9-704 ( ) 128 GB Gigabit Ethernet Switch 2 p620 (4 CPs) Presentation Servers p GHz processors/8 GB RAM p55a GHz processors/32 GB RAM Each w/ - SAP standard BW benchmark driver 2 Application Servers p GHz processors/ 128 GB RAM P GHz processors/ 128 GB RAM Each w/ - AIX SAP Kernel 6.40 w/ FDPR - DB2 Connect v8.1 FixPak 11 Figure 3: SAP BW Query Configuration Copyright IBM Corporation 2006 All Rights Reserved Page 11 of 28

12 7.2 System and Software Environment z/os MVS z/os release DB2 V8.1 GA with PTFs UK16616 and UK At the time this paper was written these were the most up to date DB2 implementation for Parallel Query and DB2 Utility ziip exploitation. DB2 Connect: V8.1 FixPak 9 Because the ziip environment continues to evolve, customers should consult their local IBM representative, [8], and DB2 Information APAR II14219 to make sure they have the proper service levels on their system. AIX AIX: 5.2 SAP Application Levels NetWeaver 04 SR1 BW 3.5 SP15 SAP disp + work information SAP kernel release 6.40 kernel make variant 6.40 compiled on AIX A4A4C00 compiled for 64 BIT compile time Feb :40:10 update level 0 patch number 58 source id Copyright IBM Corporation 2006 All Rights Reserved Page 12 of 28

13 8 Measurement Results During the course of this effort many measurement runs were done. Some were to get familiar with the environment and the workload. Some were for tuning. Some were for experimentation with different designs and implementations. It is beyond the scope of this paper to show them all. Listed below are the measurement results selected as utilizing the final design/implementation and the most useful, given the time constraints of this effort. The DB2 accounting information, shown in the BI Batch results, is from DB2 Performance Expert for z/os. More information is at [9]. 8.1 SAP OLTP Workload No ziip ziip Runid S60508G2 S60508G1 # of SD users 4,104 4,104 # of regular CPs 4 4 # of ziip Processors 0 4 Regular CP busy % % % ziip CP busy % 0.00% % Total CP busy % % % ETR ms/tr ms/tr regular CP ms/tr ziip Av response time (sec) ITR (based on CPs) Copyright IBM Corporation 2006 All Rights Reserved Page 13 of 28

14 8.2 BI Batch Workload No ziip ziip Runid S60719W3 S60719W2 # of regular CPs 4 4 # of ziip Processors 0 4 Batch elapsed time (from job output) Batch CPU time (regular CP from job output) 4,347 4,282 2,196 1,123 DB2 acctg: Elapsed time (class 1) 4, ,278.4 CPU time (class 2) 2, Parallel Task CPU time (class 2) 1, IIPCP CPU (class1) 1, IIP CPU time (class 1) 0 1,079.7 Batch CPU - class 2 CPU time WLM info for batch Service Class: CPU (sec) IIP (sec) CPU - IIP (sec) SAP BW Query Workload No ziip ziip Runid S60719P2 S60720P1 # of BW users # of regular CPs 4 4 # of ziip Processors 0 4 Regular CP busy % % % ziip CP busy % 0.00% % Total CP busy % % % ETR ms/tr ms/tr regular CP ms/tr ziip Av response time (sec) ITR (based on CPs) Copyright IBM Corporation 2006 All Rights Reserved Page 14 of 28

15 8.4 DB2 Utilities Workload 1. Load Table 6 indexes No ziip No ziip ziip Elapsed time (sec) Total CPU time (sec) IIPCP CPU time (sec) IIP CPU time (sec) indexes No ziip No ziip ziip Elapsed time (sec) 116 No 120 Total CPU time (sec) 136 Measurement 117 IIPCP CPU time (sec) 0 Data 0 IIP CPU time (sec) 0 Available 27 1 index No ziip No ziip ziip Project CPU No Yes Elapsed time (sec) 100 No 103 Total CPU time (sec) 70 Measurement 60 IIPCP CPU time (sec) 0 Data 0 IIP CPU time (sec) 0 Available Load Partition 6 indexes No ziip No ziip ziip Elapsed time (sec) Total CPU time (sec) IIPCP CPU time (sec) IIP CPU time (sec) indexes No ziip No ziip ziip Copyright IBM Corporation 2006 All Rights Reserved Page 15 of 28

16 Elapsed time (sec) 28 No 30 Total CPU time (sec) 27 Measurement 11 IIPCP CPU time (sec) 0 Data 0 IIP CPU time (sec) 0 Available 18 1 index No ziip No ziip ziip Elapsed time (sec) 10 No 10 Total CPU time (sec) 7.2 Measurement 6.0 IIPCP CPU time (sec) 0 Data 0 IIP CPU time (sec) 0 Available Reorg Tablepsace 6 indexes No ziip No ziip ziip Elapsed time (sec) Total CPU time (sec) IIPCP CPU time (sec) IIP CPU time (sec) indexes No ziip No ziip ziip Elapsed time (sec) 242 No 246 Total CPU time (sec) 124 Measurement 107 IIPCP CPU time (sec) 0 Data 0 IIP CPU time (sec) 0 Available 27 1 index No ziip No ziip ziip Elapsed time (sec) 239 No 244 Total CPU time (sec) 94 Measurement 86 IIPCP CPU time (sec) 0 Data 0 IIP CPU time (sec) 0 Available 15 Copyright IBM Corporation 2006 All Rights Reserved Page 16 of 28

17 4. Reorg Partition 6 indexes No ziip No ziip ziip Elapsed time (sec) Total CPU time (sec) IIPCP CPU time (sec) IIP CPU time (sec) indexes No ziip No ziip ziip Elapsed time (sec) 37 No 39 Total CPU time (sec) 24 Measurement 10 IIPCP CPU time (sec) 0 Data 0 IIP CPU time (sec) 0 Available 17 1 index No ziip No ziip ziip Elapsed time (sec) 24 No 24 Total CPU time (sec) 9.4 Measurement 8.5 IIPCP CPU time (sec) 0 Data 0 IIP CPU time (sec) 0 Available Rebuild Index 6 indexes No ziip No ziip ziip Elapsed time (sec) Total CPU time (sec) IIPCP CPU time (sec) IIP CPU time (sec) indexes No ziip No ziip ziip Copyright IBM Corporation 2006 All Rights Reserved Page 17 of 28

18 Elapsed time (sec) 66 No 71 Total CPU time (sec) 100 Measurement 78 IIPCP CPU time (sec) 0 Data 0 IIP CPU time (sec) 0 Available 29 1 index No ziip No ziip ziip Elapsed time (sec) 22 No 22 Total CPU time (sec) 50 Measurement 48 IIPCP CPU time (sec) 0 Data 0 IIP CPU time (sec) 0 Available Rebuild a logical partition of non-partitioning index 1 index No ziip No ziip ziip Elapsed time (sec) Total CPU time (sec) IIPCP CPU time (sec) IIP CPU time (sec) Reorg Index 1 index No ziip No ziip ziip Elapsed time (sec) Total CPU time (sec) IIPCP CPU time (sec) IIP CPU time (sec) Copyright IBM Corporation 2006 All Rights Reserved Page 18 of 28

19 9 Analysis Analysis of various aspects of these measurements was done. In some cases this analysis used standard Large Systems Performance Reference (LSPR) techniques and methodology [10]. It is assumed the reader is familiar with the terms therein, especially External Throughput Rate (ETR), Internal Throughput Rate (ITR) and the corresponding ratios (ETRR and ITRR). In this paper we defined ITR as being based on regular CP utilization. That is, it did not take into account ziip utilizations. 9.1 SAP OLTP Workload This workload exploited ziips due to its use of DRDA. There was no use of the ProjectCPU=Yes function. See DB2 Utilities Workload on page 22 for more information on this. There was enough ziip CPs so that all ziip eligible work was redirected. There were no stored procedures used. No DB2 accounting information was collected because of the volume of data generated by the tool for this workload. The results show several interesting items. Some are shown graphically in Figure 4 below. First, in the ziip case, the total milliseconds CP time per transaction was about 1% less. This indicates that ziip exploitation is about as efficient in terms of total CP time as non-ziip. Second, the response time of the ziip run was much better. This is due to the fact that the ziip measurement had a total of eight CPs of relatively low utilization compared to the non-ziip case which had only four total CPs at a much higher utilization. However, in both cases, the response time was sub-second. The regular CP busy time dropped to almost half. Similarly, ITR based on regular CPs about doubled. This reflects the fact that the configuration with ziips has about twice the throughput potential. Finally, the ziip measurement showed that 49.8% of the entire LPAR was redirected to the ziips. This includes both captured, uncaptured, and LPAR management times. However, this was not what we would expect of a typical production environment. More normal production environments should expect lower redirect percentages. See Conclusions on page 27. Copyright IBM Corporation 2006 All Rights Reserved Page 19 of 28

20 Figure 4: ziip Effects - SAP OLTP 9.2 BI Batch Workload In this workload there was no use of DRDA. There was no use of the ProjectCPU=Yes function. See DB2 Utilities Workload on page 22 for more information on this. There was enough ziip CPs so that all ziip eligible work was redirected. In addition, there were no stored procedures used. This is because the batch application was directly attached to DB2 in the same z/os image. The exploitation of ziips in this particular workload came entirely from its use of parallel queries. Because this workload was batch, and therefore had relatively few transactions, we ran DB2 accounting. The results show several interesting items. Some are shown graphically in Figure 5: ziip Effects - BI Batch below. Once again, the total CPU time is virtually the same with and without ziips. In this case the total elapsed time was only slightly less with ziips. In contrast to the previous workload, which was CPU bound, this workload is dominated by waiting for database I/O. The regular CP busy fell 49% with ziips. From the DB2 accounting data, the No ziip run s IIPCP CPU estimate for ziip potential redirect was very close to the ziip run s IIP actual CPU time. Finally, the ziip measurements show that 49.04% of the entire LPAR was redirected to the ziips. Because this data is from WLM, it doesn t count uncaptured time. However, this was not what we would expect of a typical production environment. More normal production environments should expect lower redirect percentages. See Conclusions on page 27. Copyright IBM Corporation 2006 All Rights Reserved Page 20 of 28

21 Figure 5: ziip Effects - BI Batch 9.3 SAP BW Query Workload SAP BW environments have the potential to exploit ziips for two reasons. First, more recent SAP releases use DRDA. Further, SAP BW environments also have the potential to have Parallel Queries. There was no use of the ProjectCPU=Yes function. See DB2 Utilities Workload on page 22 for more information on this. There was enough ziip CPs so that all ziip eligible work was redirected. There were no stored procedures used. No DB2 accounting information was collected because of the volume of data generated by the tool for this workload. The results show several interesting items. Some are shown graphically in Figure 6: ziip Effects - SAP BW Query below. Again, in the ziip case, the milliseconds CPU per transaction was virtually the same - about 0.5% less. This indicates that ziip exploitation is about as efficient in terms of total CPU use as non-ziip. Second, the response time of the ziip run was 43% better. Again, like the SAP OLTP measurement, the ziip measurement had a total of eight CPs of relatively low utilization compared to the non-ziip case which had only four total CPs at a much higher utilization. The regular CP busy time dropped 46%. However, because with ziips there was more throughput, the ITR based on regular CPs doubled. This reflects the fact that the configuration with ziips has about twice the throughput potential. Finally, the ziip measurement showed that 50.1% of the entire LPAR was redirected to the ziips. This includes both captured, uncaptured, and LPAR management times. This is very close to the same redirect as the SAP OLTP workload. Normally one might expect BW with DRDA to get more redirect than regular SAP with DRDA. However, as mentioned in SAP BW Query Workload on page 6, this SAP BW Query workload consists of very short queries that get little opportunity to exploit ziips. Copyright IBM Corporation 2006 All Rights Reserved Page 21 of 28

22 However, these results are not what we would expect of a typical production environment. More normal production environments should expect lower redirect percentages. However, parallelism is more likely chosen when queries include partitioned tablespaces, and SAP BW provides the capability to partition both the F and E fact tables. Thus, customers do have the opportunity to increase the likelihood that their queries will run in parallel. See Conclusions on page 27. Figure 6: ziip Effects - SAP BW Query 9.4 DB2 Utilities Workload Shown graphically below in Figure 7, Figure 8, Figure 9, Figure 10, Figure 11, and Figure 12 are ratios of CPU, elapsed time, and regular CP busy of measurements with ziips relative to measurements without ziips for the utility measurements shown previously. The amount of redirect for this configuration is: 5 to 20% for Rebuild Index 10% to 20% for Load or Reorg of a partition with one index only, or Load of entire table, or Reorg of entire tablespace 40% for Rebuild Index of logical partition of non partitioning index 40% to 50% for Reorg Index 30% to 60% for Load or Reorg of a partition with more than one index Variations in percentage redirect for various utilities are primarily determined by the percentage of CPU time consumed by build index processing, which is redirected, to the total CPU time for a given utility. For example, Load or Reorg with more than one partition spends most of the CPU time in build index phase and consequently is in a position to gain the biggest redirect percentage, especially with more indexes. Copyright IBM Corporation 2006 All Rights Reserved Page 22 of 28

23 The ProjectCPU function in WLM enables estimation of how much redirect can occur as reported in IIPCP CPU time when ziip is not available. When ziip is available, there is no difference between ProjectCPU No and Yes. When there is no ziip processor but ProjectCPU is requested in order to estimate the potential redirect, or when ziip is present, a new execution unit switch from utility TCB to an enclave SRB will take place during index build phase of DB2 z/os Load, Reorg, and Rebuild Index for each block of index entries. This newly added processing to enable real or simulated CPU time redirect will typically result in less than 10% increase in the job total CPU time and elapsed time. Most of this added CPU time is actually redirected to ziip when available. This extra CPU and elapsed time tends to go up as the ratio of the number of ziips to the number of CPs goes down. In other words, increasing the ratio of the number of ziips to the number of CPs closer to one tends to result in less extra CPU and elapsed time and a maximized redirect percentage. Even including the ProjectCPU costs, we saw a net reduction in regular CP time. This ranged from 4% to 57% reduction. As one might suspect, more indexes result in more utility CPU time. All of the ziip measurements were with four regular CPs and two ziips. In all the six index measurements, the IIPCP CPU time indicates that there was some overflow to regular CPs and that these measurements could have exploited even more than two ziips. This set of measurements is not intended to represent customer environments. As mentioned earlier, some customers have some tables that are much larger. In some cases these customers have had to carefully plan when to do this sort of utility work. ziips might help this as well as possibly reduce the costs of this work. See Conclusions on page 27. Figure 7: ziip Effects - DB2 Utilities Load Table Copyright IBM Corporation 2006 All Rights Reserved Page 23 of 28

24 Figure 8: ziip Effects - DB2 Utilities Load Partition Figure 9: ziip Effects - DB2 Utilities Reorg Tablespace Copyright IBM Corporation 2006 All Rights Reserved Page 24 of 28

25 Figure 10: ziip Effects - DB2 Utilities Reorg Partition Figure 11: ziip Effects - DB2 Utilities Rebuild Index Copyright IBM Corporation 2006 All Rights Reserved Page 25 of 28

26 Figure 12: ziip Effects - DB2 Utilities Rebuild Logical Partition of a Non-Partitioning Index and Reorg Index Copyright IBM Corporation 2006 All Rights Reserved Page 26 of 28

27 10 Conclusions These measurements show exploitation of ziips in several environments. In all these measurements, the amount of redirect to ziips is more than any possible additional overheads due to ProjectCPU. In some cases there were very significant redirects. One was almost 60%. The number of ziips configured to a system is limited to less than or equal to the number of regular CPs configured on the system. But this is at a system level. Individual LPARs on that system can exploit more ziips than they have regular CPs. These measurements were run in a laboratory environment. We expect real customer DB2 systems would be running more functions related to the care and feeding of a production DB2 database. These functions can range from monitoring and tracing options to service and administrative programs such as DFHSM. These functions do not exploit ziips, and any environment using them will have their potential ziip redirect percentage of an LPAR diluted. Similarly, running application unrelated to DB2 can dilute observed redirect LPAR percentages. As such, customers should understand that these results are limited in scope. They should not be used for sizing. We expect that customer workloads will show different results. For an estimate of your workloads ziip exploitation potential, please contact your local IBM account team. 11 References [1] IBM Corp IBM System z9 Integrated Information Processor (IBM ziip): Frequently Asked Questions from [2] IBM Corp Why Data Serving on a Mainframe from ftp://ftp.software.ibm.com/common/ssi/rep_wh/n/zsw01811usen/zsw01811usen.pdf [3] IBM Corp DB2 UDB for z/os V8: Through the Looking Glass and What SAP Found There (SG ) or from [4] IBM Corp DB2 UDB for z/os Version 8: Everything You Ever Wanted to Know,... and More (SG ) or from [5] General information about DB2 UDB for z/os: [6] General information about DB2 Utilities Suite for z/os: [7] IBM Corp. [8] IBM Corp. Copyright IBM Corporation 2006 All Rights Reserved Page 27 of 28

28 [9] General information about DB2 Performance Expert for z/os on World Wide Web page: [10] IBM Corp Large Systems Performance Reference (SC ) or Copyright IBM Corporation 2006 All Rights Reserved Page 28 of 28