Part 1  |  Part 2

This is the first of a two-part article that focuses on the new DB2 UDB Version 8 from a performance perspective. While our article will be useful for even the most up-to-date Version 8 users, it is geared towards teams that are still on the DB2 UDB Version 7.2 release. In this article, we will specifically cover the performance benefits of DB2 UDB Version 8 from a transactional perspective; in Part 2, we’ll detail the performance benefits from a decision support perspective, and describe some important other enhancements as well.

Some of the reasons other than performance why customers have moved to the DB2 UDB Version 8 release include:

• New DB2 editions that provide significant cost savings (all DB2 servers now include free copies of DB2 Everyplace/MobilityOnDemand, there is a new low-cost DB2 Express edition, and so on)
• A host of autonomic and self-managing features that free up a database administrator’s time spent performing routine tasks, and that implement a management-by-exception model for problem identification and resolution
• Broad support for your choice of data access API (JDBC, SQLJ, ADO.NET, and so on), and your choice of development tooling (Visual Studio.Net®, Eclipse®, WebSphere Studio Application Developer®, and so on)
• Built-in federated access to relational and non-relational data sources
• Built-in XML support
• 64-bit computing and seamless 32-bit client to 64-bit server connectivity
• Near elimination of offline maintenance operations with utilities that can run online (table and index reorganization, load operations, and so on)

Although we can’t cover all the Version 8 transactional performance enhancements in this article, we will cover:

• Page cleaning enhancements
• Logger enhancements
• DB2 Common Client
• Stored procedure enhancements
• Java enhancements
• Type 2 indexes (pseudo deletion of index keys)

Page Cleaning Enhancements

Page cleaning enhancements in Version 8 have been delivered in multiple stages (some at the generally available Version 8.1 release, and others through FixPaks or updates up to and including DB2 UDB Version 8.1.6).

In DB2 UDB Version 7, a page cleaner (although asynchronous to the agent) would issue a synchronous write request to the set of pages that it needed to write out to disk. In contrast to this approach, DB2 UDB Version 8 automatically enables the use of Asynchronous Input/Output (A-I/O) for page cleaning activities on AIX®, Solaris®, and Windows®.

Let’s clarify that last paragraph as it is sometimes a source of confusion for some database administrators (DBAs). In DB2 V7 and DB2 V8, asynchronous processing for page cleaning and prefetching activities was always used. Although a simplification of the engine architecture, agents makes requests for data, and two separate processes exist (one for each activity) to service them. What’s new in DB2 V8 is the A-I/O enablement of the page cleaning process — kind of a like a double level of asynchronous activity. The primary benefits of the new A-I/O enhancement is a new and more efficient operating system interface for handling writes in a page cleaner.

Why this emphasis on page cleaners? The obvious reason is that reducing “bottlenecks” is beneficial from a performance perspective. But the main reason that page cleaning is so important is that this is the way that databases handle large writes and ensure that there are clean pages in the buffer pool for prefetchers to populate. If the algorithm that drives page cleaning is “off,” or misfires, you could end up with “dirty steals” from the buffer pool. The overheard and code path length associated with finding victim pages because of this and hardening them to disk before bringing in the new data to satisfy an agent’s request for data means poor performance.

Efficient page cleaning ensures that when new pages enter the buffer pool, old ones don’t need to be purged. In fact, this is how DB2 achieves such a highly scaled, evenly balanced throughput rate: the page cleaners are always trying to stay ahead of pages that are being modified or coming into the system by writing out pages that are ready to be made durable on disk. A-I/O helps to efficiently drive this process.

DB2 UDB “Stinger” and its support for the 2.6 kernel will deliver A-I/O for Linux®-based DB2 servers through a registry variable, because not all Linux distributions have support for A-I/O. IBM Corp. is also considering adding A-I/O to DB2 for HP-UX on IPF in the future. (In DB2 UDB Version 8, DB2 is available for HP-UX running on the PA-RISC architecture. In DB2 UDB Version 8.1.4, we extended our HP-UX support to include support for the Intel® Itanium® chip set.)

A-I/O in DB2 UDB Version 8 delivers significant transactional benefits. This feature also implies the need for fewer page cleaners, because they now operate more efficiently.

The following chart illustrates the benefit of using A-I/O for page cleaning activities.

DB2 UDB Version 7.2 is used here as a baseline for comparison, and its values have been set to 100.

Even Better Page Cleaning?

Since the release of DB2 UDB Version 8, the Toronto software development laboratory has been working with new algorithms (for DB2 operations like page cleaning) that are better suited for high-end online transaction processing (OLTP). In DB2 UDB Version 8.1.4, a new registry variable, DB2_USE_ALTERNATE_PAGE_CLEANING, was introduced so that users could leverage some of the performance benefits that these new algorithms deliver with respect to page cleaning. To use this registry variable, you must be running DB2 in an environment that supports A-I/O.

When DB2_USE_ALTERNATE_PAGE_CLEANING is set to ON, there is an algorithmic change to the frequency, intensity, and pace with which DB2 invokes page cleaning. Today’s algorithm looks for log sequence number (LSN) gaps and dirty page steals before firing off page cleaners. When large buffer pools are used, we have seen periods of low page cleaning activity followed by periods of heavy cleaning, and then low page cleaning activity again. The new algorithm helps to smooth out page cleaning activity and keeps it at a lower overall intensity level.

This more aggressive method of page cleaning renders the CHNGPGS_THRESH database configuration parameter irrelevant, because this parameter will no longer control page cleaning activity.

Performance enhancing features like the alternate page cleaning algorithm are not enabled by default in DB2 during their preliminary introduction phase. For example, the hash join algorithm was optionally enabled via a registry variable in DB2 Version 6 and DB2 Version 7 — in DB2 Version 8, it is now part of the join strategies available to the optimizer by default.

This new page cleaning method has been evaluated under steady-state, high-volume OLTP workload environments and has yielded positive results. Like other new performance features (for example, the hash join algorithm in DB2 V7), the alternate page cleaning mechanism is implemented in a manner in which it can optionally be used without impacting existing deployments. We recommend that you explore this alternative page cleaning in a test environment and verify its benefits before deploying on a production system.

Logger Enhancements

In DB2 UDB Version 8, the logger was split into two separate processes: db2loggw (for log write activities) and db2loggr (for other activities, such as undo and recovery work). This is a key performance enhancement, because the logger is the single point of coordination across all database activities. For this reason, there are transactional benefits if DB2 can isolate the log writing process and make it as fast and efficient as possible.

Consider, for example, an environment that has thousands of agents and connections. All of these activities are working independently of one other and are being multiplexed by the operating system scheduler. Of course, these agents are performing transactions on behalf of applications, and this activity generates log records whenever any modifications to the data are made. These log modifications are passed through a single log that has to assemble them, serialize them, and write them out as efficiently as possible; that is why it’s important to have a dedicated writing process for the logger.

Another Version 8 performance enhancement is that dual logging is now asynchronous, a change that is designed to minimize the overhead once associated with this feature.

In DB2 UDB Version 7, dual logging was enabled through the DB2NEWLOGPATH2 registry variable, and serialized; in Version 8, it is enabled through the MIRRORLOGPATH database configuration parameter, and is asynchronous with the primary log file.

Other Version 8 logging enhancements include:

• More flexibility in the naming path conventions used for dual logging (you no longer have to follow the path of the primary log files)
• Infinite logging support, so that an active unit of work can span the primary and archive logs (effectively allowing a transaction to use an infinite number of log files)
• Increased size of the total active log space from 32 GB to 256 GB

With these enhancements, DB2 UDB Version 8 is able to sustain very high logging rates using conventional disk technology. We’ve seen Version 8 logging rates surpass the 34 MB/second mark; think about how much data needs to be modified every second to generate this type of logging!

The DB2 SAP 3-tier S/D benchmark (using a single partition on a single 32-way SMP pSeries690®) had a logging rate of approximately 34.5 MB/second. If you used the database partitioning feature (DPF), you could scale this metric up over however many partitions you have. For example, you could have a cluster of P690s and achieve this logging rate on every partition.

DB2 Common Client

The DB2 Common Client (or simply common client) represents a huge architectural change between Version 7 and Version 8. The good news is that you’re going to benefit from this new feature, even if you don’t know anything about it, when you migrate to Version 8. (In other words, you don’t need to do anything except migrate your DB2 clients and servers to Version 8 to realize the performance benefits of the common client.)

At a high level, the common client delivers significant performance improvements from a combination of:

• Reduced code path length
• Reduced number of in-memory transfers and context switches
• Large-scale optimization of the interface code used between clients and the DB2 engine
• Implementation of a high-performance interface called Distributed Relational Database Architecture (DRDA) — a standard that was invented and donated to the IT community by IBM

The following diagram shows a Visual Basic application interacting with a remote DB2 server before Version 8.

The application goes through a “pancake stack” of data access API layers, and finally exits onto the DB2RA (DB2 proprietary) wire-level protocol. To pass different operational instructions from ADO down to the wire-level protocol, the DB2 code must traverse a lengthy code path (the code path represents the chain of instructions that an application must execute to accomplish a task) and complete a number of memory transfers. Moving from the top of this stack to the bottom creates a performance overhead, which slows down most applications. Moreover, trying to identify a problem involves tracing the stack at different layers.

In DB2 UDB Version 8, the common client implementation starts out by replacing the proprietary DB2RA wire-level protocol with the DRDA protocol. Performance benefits come from a 90-degree rotation of the “pancake stack,” so that the data access APIs write directly to the wire and benefit from a vast reduction in the code path for various operations. This change leads to a significant performance improvement, along with a significant reduction in the CPU load for client and server applications.

The following chart illustrates performance improvements resulting from the common client architecture for an OLE DB application.

In DB2 UDB Version 7 and beyond, you can code an ADO/OLE DB application for your DB2 server using an OLE DB bridge (called MSDASQL) that is provided by Microsoft, or using DB2’s own native OLE DB provider (called IBMDADB).

On the right-hand side of the chart are the results of an OLE DB application fetching rows from a DB2 for Linux, UNIX, and Windows database. On the left-hand side is the same application and workload going through a DB2 Connect gateway to a backend DB2 for z/OS data store.

The 32,000-row fetch using Version 7 isn’t very impressive. Note also that the native DB2 OLE DB provider didn’t yield a significant benefit over Microsoft’s bridge — this was due to the “pancake” architecture of the old (Version 7) client.

Now look at the Version 8 results for the same fetch. You’ll notice a two- to three-fold performance improvement, and that the performance benefit of the DB2 OLE DB provider is significant when compared to the Microsoft OLE DB bridge.

Aside from being extremely fast, DB2 UDB Version 8 (as of Version 8.1.4) closes all the “gaps” in the OLE DB interface with support for updateable cursors, scrollable cursors, distributed transactions, and so on. As of Version 8.1.5, there is really no reason to use the OLE DB bridge provided by Microsoft. Version 8 also delivers a native .NET managed provider written in C# (but talking about that would require another article).

The following chart shows a sample of the relative reduction in the code path for client-side operations (again, we are using a baseline of 100 percent for DB2 UDB Version 7). For example, a Blocked Fetch took 18 percent fewer instructions to complete in Version 8 than this operation required in Version 7; this represents an 18 percent reduction in the code path for this operation.

The following chart shows a sample of server-side code path reduction in DB2 V8.

What about the performance results that come from this range? The common client delivers major performance improvements for applications (especially local ones). We’ve seen reductions in request overheard times ranging from 10 — 45 percent or more.

The other benefit of using DRDA as the wire protocol is that it eliminates considerations for 32-bit and 64-bit interconnectivity. If you are a mainframe shop, you likely already know a lot about DRDA, thanks to DB2 Connect®. In DB2 UDB “Stinger” we are adding the ability to encrypt data flows across the entire DB2 family.

If you intend to maintain a mixed DB2 UDB Version 7 and Version 8 environment, we strongly recommend the following strategy when migrating a Version 7 server to Version 8:

1. Migrate the Version 7 server to a Version 8 32-bit instance. (If you are running a 64-bit version of a DB2 Version 7 database, then just migrate the database to DB2 Version 8.)
2. Migrate the DB2 clients to Version 8.
3. Upgrade your database server to a DB2 UDB Version 8 64-bit instance if you want to leverage the benefits of this type of addressing.

Stored Procedure Enhancements

Stored procedures (SPs) are critical for reducing the need to traverse the client-server interface. In its simplest form, an SP can be thought of as a package of SQL that resides on the server and interacts with the client on the server side (they can be much more than this, but to keep it simple, we’ll leave it at that).

There are many changes in DB2 UDB Version 8 that make SPs run faster. Some of these changes include reduced storage requirements, reduced context switches, and a trusted execution model that has been extended from being solely Java SPs in Version 7 to SQL-based SPs in Version 8. This means that in Version 8, these SQL PL procedures get a performance boost because they run as part of the address space and not in a newly spawned process. C-based SPs in Version 8 still run in fenced mode.

DB2 UDB “Stinger” will be the first commercially available database to support Common Language Runtime (CLR)-based procedures. In addition to this, DB2 UDB “Stinger” removes the requirement for a C compiler to build SQL PL SPs.

The Version 8 common client (detailed in the previous section) helps the performance of SPs as well. Using this new streamlined and efficient architecture, SPs can more quickly be called and return results between a client and a server.

DB2 UDB Version 8 delivers a very significant change to the run-time environment used for Java SPs, too. In Version 7, each time a JDBC-based Java SP was invoked, DB2 would initialize and start a Java virtual machine (JVM) to host and execute the external code. This had a serious impact on performance and resource consumption, because multiple invocations of Java SPs meant multiple JVMs.

In Version 8, the JVM is multithreaded and can be shared across various Java SPs. And you now have the option to define a Java SP as threadsafe, in which case, it will run in a single fenced-mode process. This allows resource sharing of the JVM, and in general, reduces the amount of context switching for users that run large numbers of fenced-mode routines.

The new Version 8 threading model not only delivers the benefit of a significant decrease in resource consumption, but it also dramatically improves performance. You should be aware that in Version 8, SQLJ-based Java SPs are still single threaded, but as you can see in the chart below, they, too, perform better.

The following chart shows the improved performance of SPs running in Version 8 compared to Version 7. Once again, DB2 UDB Version 7.2 is used as a baseline for comparison, and its values have been set to 100.

Java Enhancements

In addition to the Java enhancements for SPs detailed in the previous section, DB2 UDB Version 8 delivers a complete technology refresh of its Java drivers (which are partly responsible for the tremendous performance gains). In Version 7, Java developers could leverage either a Type 2 (sometimes called an app) driver or a Type 3 (sometimes called a net) driver. (These drivers still exist and are supported in DB2 V8.)

Version 8 introduces a new driver called the DB2 Java Common Client (JCC) — although it is often referred to as the universal driver, because it shares a common code base across most of the entire DB2 family. This single driver can implement both Type 2 and Type 4 connections.

The new JCC driver offers improved performance and scalability, and is the focus of ongoing development in Java connectivity. DB2 UDB Version 8 also delivers plug-ins for WebSphere Studio Application Developer, and the Eclipse environment (topics for a future article).

The following chart shows the improvement in JDBC performance in Version 8 compared to Version 7. Again, DB2 UDB Version 7.2 is used as a baseline for comparison, and its values have been set to 100.

You can also see this kind of performance boost in the IBM SPECJApp results, using WebSphere to drive transactions through a DB2 UDB Version 8 Type 4 driver.

DB2 UDB “Stinger” will deliver Java Transaction API (JTA) support for the Type 4 implementation of the JCC, as well as key features such as enhanced JDBC 3.0 support and J2EE 1.4 certification.

Type 2 Indexes (Pseudo Deletion of Index Keys)

DB2 UDB Version 8 includes a major upgrade to its indexing technology, with new support for Type 2 (T2) indexes (just like DB2 for z/OS) that deliver better performance and concurrency. In fact, most of the online utilities for planned maintenance in Version 8 (and those that are on the way) rely on this new index type.

In Version 7, database administrators (DBAs) only had access to Type 1 (T1) indexes. These indexes still exist in Version 8, and there is no requirement to drop and then recreate (or convert) these indexes to the T2 format (unless, of course, you want to take advantage of their efficiency and the features that they support).

Although it is beyond the scope of this article to cover T2 indexes in detail, it should be noted that one of the key properties of a T2 index is the behavior of deleted keys. When a key is deleted from a table with a T2 index, the deleted key is simply marked for deletion, not actually deleted (the physical deletion takes place synchronously later; more about that in a moment).

What does this mean for performance? With respect to concurrency (which is one of the ways in which the value of performance is measured), it means more concurrent throughput and fewer locks (for example, never having to deal with next key locking issues again).

We want to emphasize that you do not need to convert your indexes after database migration from Version 7 to Version 8. We recommend that you carry out this conversion gradually when you are ready and have the time. You can implement a step-wise conversion plan, if you want; just keep in mind that all indexes on a specific table have to share the same index type.

A Higher-Level Look at Performance in DB2 UDB Version 8

There are many ways in which individuals measure performance, aside from benchmarking their own applications. One approach focuses on the Transaction Processing Performance Council’s (TPC®) standard benchmarks; namely, TPC-C® for OLTP applications, and TPC-H®, which measures decision-support performance at various scaling factors (100 GB, 300 GB, 1 TB, 3 TB, and 10 TB). Another approach attempts to identify the performance of databases through real-world application benchmarks such as SAP®, PeopleSoft®, and so on. Because we obviously can’t take each customer’s workload and benchmark the performance improvements that DB2 UDB Version 8 can deliver (although we certainly encourage you to do so), we’ll address both approaches with DB2 UDB Version 8 proof points.

The benchmarking world for transactional applications is a “leap-frog” environment. The leadership position is dynamic, and the competition is fierce. It is interesting to note that the TPC-C leadership position changed hands approximately six times in the last 12 months. Nevertheless, DB2 UDB has demonstrated consistent, long-term leadership across the various benchmarks.

The TPC-C Landscape

“TPC-C is an OLTP workload. It is a mixture of read-only and update-intensive transactions that simulate the activities found in complex OLTP application environments.”

-- Source: www.tpc.org

The workload used in the TPC-C benchmark is a moderately complex OLTP workload with heavy I/O. The application model is a wholesale supplier who is managing orders for an order entry system. The application’s workload consists of five transaction types with a pre-defined end-user interface.

The TPC-C benchmark is usually measured with two different metrics that appeal to different buyers in the information technology (IT) market. One group looks for performance: Which database can deliver the fastest results? The other group looks for price/performance: What vendor can deliver the most transactions at the lowest marginal cost?

At the time of writing, DB2’s story in relation to this benchmark is fantastic: DB2 UDB Version 8 has the lead in overall single system performance, as shown in the following chart.

The following figure shows the absolute best per/CPU performance results for each vendor, irregardless of final throughput:

Interesting to note here in this result is that DB2 result is on a 16-way server: again, this demonstrates some of the significant scaling power of the DB2 platform.

As DB2 leads the industry with the fastest single system TPC-C results ever recorded, it also holds the world record for price/performance, thereby demonstrating outstanding value, as shown in the following chart.

The Intermediate Software Vendor (ISV) Landscape

Some people who evaluate the performance of databases favor application benchmarks that model ERP, CRM, and SCM applications that are used to run their very ?real world? businesses. DB2 UDB Version 8 has leading results across a myriad of ISV benchmarks, including Baan®, PeopleSoft®, and SAP®.

The SAP Sales/Distribution (SAP S/D) benchmark is considered to be one of the most demanding benchmarks in the industry for evaluating the performance of ERP solutions. It can be configured in a 2-tier or 3-tier topology (the 3-tier setup is more “enterprise” representative). The workload simulates end users driving business transactions through dialog steps that must have an average response time of less than two seconds per dialog (it assumes a “user think time” of ten seconds between dialog steps).

The following chart shows the DB2 UDB Version 8 results for the SAP 3-tier S/D benchmark.

The SAP 3-tier S/D benchmark is representative of high-end OLTP. DB2:

• Processed 3,660 database transactions per second
• Executed 151,250 SQL statements per second
• Inserted 51,620 rows per second
• Logged 34.5 MB of information per second

DB2 has some very impressive results with the SAP 2-tier S/D benchmarks, too. As of the publication date of this article, the following figure illustrates the industry leading DB2 SAP results (in their respective CPU categories):

Notice the transaction-based near-linear scalability across the common SAP workload as more and more processors are added to the infrastructure. Quite simply, you double your processors, you double the number of supported users throughput.

Internal Transaction Benchmarks

Besides validating in the marketplace through real customer solutions and standard benchmarks, we have run a number of performance comparisons between DB2 UDB Version 7 and Version 8 in the laboratory.

The following chart shows the significant boost in throughput that we have witnessed for OLTP-like transactions. Again, DB2 UDB Version 7.2 is used as a baseline for comparison, and its values have been set to 100.

In a sample of ERP applications that we support, we have seen benefits of between 3 and 25 percent resulting from a DB2 Version 8 migration alone.

What’s most interesting about the previous results is that they were achieved without taking advantage of any of the new features in DB2 Version 8; just performing the migration from DB2 Version 7 yielded these results.

Wrapping it Up

There are many reasons why an upgrade to DB2 UDB Version 8 makes a lot of sense. As you can see, Version 8 delivers a significant performance boost to your applications, mostly from transparent features that you can exploit by simply installing the Version 8 code. With even more features queued up for DB2 UDB “Stinger,” the time to move to DB2 UDB Version 8 couldn’t be better.

If you are an IBM® DB2 Universal Database for Linux®, UNIX, and Windows® (DB2 UDB) user, you are likely aware that the Version 7.2 release goes out of service on September 30, 2004. (Most of the current press coverage around DB2 is for the up-and-coming DB2 UDB “Stinger” release.) Although extended support contracts can be purchased, we think you’ve seen some good things that you can leverage in the Version 8 release of DB2 UDB — especially when it comes to performance.

We presented a lot of benchmarks as evidence for the scalability and throughput capabilities of DB2 UDB Version 8. It can be said that benchmarks come and go, but because many of these benchmarks were attained with key features and architectural changes to the product, you can count on improved performance with the DB2 UDB Version 8 release, and a whole lot more.

--

Berni Schiefer is a Distinguished Engineer and manager of the DB2 Universal Database Performance and Advanced Technology team. He has responsibility for DB2 performance, platform exploitation and autonomic computing. He joined IBM in 1985, and has worked on a wide range of database development projects — including SQL/DS and the Starburst experimental relational database at the IBM Almaden Research Laboratory — prior to working on DB2. His current focus is on introducing advanced technology into DB2 UDB, with particular emphasis on performance, autonomic computing, and the exploitation of next-generation computing architectures.

Paul C. Zikopoulos, BA, MBA, is an award-winning writer and speaker with the IBM Database Global Sales Support team. He has more than ten years of experience with DB2 UDB, and has written numerous magazine articles and books about it. Paul has co-authored the books: DB2 Version 8: The Official Guide, DB2: The Complete Reference, DB2 Fundamentals Certification for Dummies, DB2 For Dummies, and A DBA's Guide to Databases on Linux. Paul is a DB2 Certified Advanced Technical Expert (DRDA and Cluster/EEE) and a DB2 Certified Solutions Expert (Business Intelligence and Database Administration). You can reach him at paulz_ibm@msn.com.

Trademarks and Disclaimers

The views expressed in this article are those of the authors and not necessarily those of IBM. Features referred to in the DB2 “Stinger” release may or may not be present in its final availability. All benchmarks are internal tests and meant to represent the potential advantages that the new features outlined in this article could deliver – your mileage may vary.

All benchmarks referred to in this article are current as of the publication data of this article. Benchmark details are detailed in the accompanying External Benchmark Details section. For complete details, please visit each sponsor’s Web site.

DB2, DB2 Connect, DB2 Universal Database, IBM, are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both.

Microsoft and Windows are registered trademarks of Microsoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

TPC Benchmark, TPC-C, tpmC are trademarks of the Transaction Processing Performance Council. For further TPC-related information, please visit http://www.tpc.org/.

Other company, product, and service names may be trademarks or service marks of others.

External Benchmark Details

Please visit www.tpc.org for current TPC-C results.

TPC-C Price/Performance Leadership

DB2 UDB Express Edition on HP ProLiant ML350T03 (2.8GHz Intel Xeon w/512 K Cache) running Microsoft Windows Server 2003 Standard Edition; Metrics: 18,318 tpmC, $1.68/tpmC; Available: 04/14/2004.

Microsoft SQL Server 2000 Standard Ed. on Dell PowerEdge 2650 (Intel Xeon 3.2GHz/2MB L3 cache) running Microsoft Windows Server 2003 Standard Edition; Metrics: 22,052 tpmC, $1.85/tpmC; Available: 2/18/2004.

TPC-C Performance Leadership

Refer to the full disclosure for the Oracle result at 1,008,144 tpmC.
Refer to the full disclosure for the DB2 result at 1,025,486 tpmC.
Refer to the full disclosure for the SQL Server result at 786,646 tpmC.

SAP S/D Leadership

These benchmarks fully comply with SAP's issued benchmark regulations and have been audited and certified by SAP.

Details regarding these benchmarks are available upon request from SAP AG.

1. The SAP SD standard 4.6C application benchmark performed on August 17, 2002 by IBM in Beaverton. OR, USA, was certified with the following data: 47008 benchmark users; 99%/90%/90%/25% CPU utilization (DB/dia/upd/enq). OS: AIX 5.1; RDBMS: DB2 UDB v7.2 FP7; R/3 release: 4.6C; 6228 Gb total disk space; Database Server: IBM pSeries Enterprise Server Model p690, 32-processor SMP, Power4, 1.3ghz, 24 MB L2 cache, 64 GB main memory. 13 Dialog/Update servers: IBM pSeries p690, 32-processors SMP, Power 4, 1.3ghz, 24 MB L2 cache, 64 GB main memory. 1 Msg/Enq: IBM pSeries Enterprise Server Model p690, 8-processors SMP LPAR, Power4, 1.3ghz, 6MB L2 cache, 16 GB main memory. (cert #2002046).

2. The SAP SD standard 4.6C application benchmark performed on September 14, 2002 by IBM in Beaverton. OR, USA, was certified with the following data: 47528 benchmark users; 96%/91%/91%/26% CPU utilization (DB/dia/upd/enq). OS: AIX 5.1; RDBMS: DB2 UDB v8.1; R/3 release: 4.6C; 6228 Gb total disk space; Database Server: IBM pSeries Enterprise Server Model p690, 32-processor SMP, Power4, 1.3ghz, 24 MB L2 cache, 64 GB main memory. 13 Dialog/Update servers: IBM pSeries p690, 32-processors SMP, Power 4, 1.3ghz, 24 MB L2 cache, 64 GB main memory. 1 Msg/Enq: IBM pSeries Enterprise Server Model p690, 8-processors SMP LPAR, Power4, 1.3ghz, 6MB L2 cache, 16 GB main memory. (cert #2002052).

3. The SAP SD standard 4.6B application benchmark performed on November 16th,2000 by Fujitsu-Siemens in Fuerth, Germany, was certified with the following data: 23000 SD benchmark users;1.73 average dialog response time; 96%/60%/64%/22% CPU utilization (DB/dia/upd/enq). OS: DB server: Solaris 8, App server: RedHat Linux 6.1; RDBMS: Oracle 8.1.6; R/3 release: 4.6B; 1344 Gb total disk space; Database Server: Fujitsu-Siemens Primepower 2000, 64-processor SMP, Sparc 64 450 MHz, 8 MB L2 cache, 64 GB main memory. 161 Dialog/Update servers: Fujitsu-Siemens Primergy H400, 4-processors Pentium III Xeon 700 MHz, 1 MB L2 cache, 4 GB main memory; 1 Msg/Enq: Fujitsu-Siemens Primergy N800, 8-processor Pentium III Xeon 700 MHz 2 MB L2 cache, 8 GB main memory (cert #2000029)

4. The SAP SD standard 4.6C application benchmark performed February 21,2002 by Unisys in Mission Viejo, CA,USA was certified with the following data: 26000 benchmark users;93%/60%/68%/31% CPU utilization (DB/dia/upd/enq). OS: MS Windows 2000 DC Server LE; RDBMS: SQL Server 2000;R/3release 46C;1500gb total disk space; Database Server: Unisys Es9000, 32-processor SMP, Pentium III 900mhz,2mb L2, 12gb main memory. 99 Dialog/Update servers: Unisys eAction Es5085 8 processor Pentium III 700/900mhz, 2mb L2, 4GB main memory; 1 msg/enq: Unisys eAction Es5085 8 processor Pentium III 900mhz, 2mb L2, 4GB main memory (cert #2002007). For more information, see the official list of SAP benchmark results.