Defend your Turf – DB2 Technical Advantages over OracleChris EatonIBMSession Code: D10Nov 10, 2010 11:00 – 12:00 | Platform: DB2 for Linux, UNIX, Windows

Abstract:Do you work for an organization that has multiple database management systems? Do you find yourself battling other groups that want to use Oracle (and you know DB2 is the best choice for this deployment)? Join Chris as he will help arm you to defend your turf. Discussion will be completely technical in nature (no marketing hype) to show you the DB2 technical advantage over Oracle.

1

Agenda

• DB2 features for leading OLTP and Warehouse performance

• DB2 scalable infrastructure for scale up and scale out

• Manageability and autonomic computing advantages

• High availability advantages with DB2

Objective 1: DB2 features for leading OLTP and Warehouse performanceObjective 2: DB2 scalable infrastructure to scale up and scale outObjective 3: Manageability and Autonomic Computing advantageObjective 4: High Availability advantages with DB2

DB2 Features for Leading OLTP Performance

• Better performance = lower costs• DB2 consistently delivers ~15% better performance• Advanced features for OLTP Performance

• Tight OS integration• Better logging throughput• Threaded architecture for lower context switch costs and

lower per agent memory costs

OLTP Advantages for Performance

Transactional Performance

• DB2 has been a leader in transactional performance longer than all other vendors combined

• On equivalent platforms, DB2 consumes less resources and delivers approx 15% better performance

Days of leadership from January 1, 2003 to September 20, 2010.

DB2 Outperforms Oracle by 16% in Apples to Apples Comparison

• Both on exactly the same server (8way 1.9GHz p5 570)• DB2 leads in performance by 16% over Oracle

0

50000100000

150000200000

250000300000

350000

400000450000

tpmC

DB2 vs Oracle on 8way p570

DB2 Oracle

16% Faster

Results current as of May 10,2010Check http://www.tpc.org for latest results DB2 on 8way p5 570: 429,899 tpmC, $4.99 /tpmC, Availability 09/30/2004

Oracle on 8way p5 570; 371,044 tpmC, $5.26 /tpmC, Availability 09/30/2004

It is not very often that you get an Apples to Apples comparison where two database vendors run their benchmarks on the exact same hardware. This result is dated (using DB2 v8 against Oracle 10g) however it shows that on exactly the same hardware, DB2 delivered 16% better performance than Oracle. In fact you would need 10 CPUs of Oracle to match the performance of 8 CPUs of DB2 on this class of server.

% wait

% cpu

Migration

Database Server Load Post Migration for Real Customer

DB2

Technology Driving Performance Advances on Power • Process Exploitation

• Deep exploitation of Simultaneous Multi Threading (SMT)• Fully threaded DB2 engine• NUMAtization of DB2 resources to align with system architecture

• Memory Exploitation• Autonomic exploitation of POWER features such as larger page sizes• Support for AIX multi page support that includes 64KB, 16MB and 16GB AIX page sizes• Co-operative Caching

• Storage Exploitation• Exploits Asynchronous I/O and Scatter / Gather I/O, as well as AIX CIO and DIO interfaces • End-to-End I/O Priorities

• Enablement for POWER6/POWER7 features (Decimal Floating Point, Storage Keys)

• Deep integration with AIX APIs

• Exploits xlC capabilities for optimal performance using Profile Directed Feedback

• And many, many more …

What makes DB2 on IBM Power such a performance powerhouse? Deep technology exploitation! IBM employees working together in the hardware, operating system, compiler and database development teams collaborate to not only deliver leading edge technology but to exploit it up the stack for even greater results working together.

• Logging can be the most critical factor in high volume OLTP

• TPC-C proves that DB2 has a more efficient logger• DB2 logged less than ½ that of Oracle and SQL Server• DB2 logged 1/8th the amount of Oracle RAC

• DB2 9.7 = 2.25KB of log per transaction• Oracle 11gR2 = 4.9KB of log per transaction• Oracle 11gR2 RAC = 19KB of log per transaction• SQL Server 2005 = 6.0KB of log per transaction

• Reduced logging = increased performance

Efficient I/O for Logging

In very high volume transactional systems the logger can quickly become the bottleneck. DB2 (and other RDBMSs) can do most of the work a transaction requires completely in memory (updates occur in the buffer pool in memory, authorizations and access plans are all cached in memory, etc.). However there is one thing that cannot happen in memory. Whenever a transaction performs a COMMIT the information that tells the RDBMS how to redo that transaction (i.e. the log information) must be flushed to disk. If the committed transaction is not recorded in the log files on disk then it would be possible to lose committed transactions. Therefore all database servers write records to the log files whenever a user commits a transaction.

In order to achieve very high concurrency and high throughput, it is essential that the logger be as efficient as possible since these I/Os can quickly become the bottleneck (since disk access is significantly slower than memory access).

There is a very strong proof point that demonstrates DB2 has a much more efficient logger than our competitors. TPC-C is an industry standard transaction processing benchmark that all major database vendors participate in. Each vendor runs their own benchmarks to try to demonstrate they have the best RDBMS. DB2 comes out on top more often than any other database vendor (but more on that later). One interesting thing to note about TPC-C is that one of the requirements of the benchmark is that you also publish how much log space you consume during the benchmark run. By comparing the log space consumed (and knowing that this standard benchmark requires every vendor to run the exact same transactions over and over again) we can compare the efficiency of the 3 database vendor’s loggers. The most current TPC-C

DB2 9.5 - Memory Simplification• AIX threading greatly simplifies DB2’s memory model – one

big flat address space• Lower memory footprint

db2wdog

db2sysc

db2wdog

db2sysc

db2agentUserdb2agent db2loggw

db2cart

db2pcln

BufferPool

LogBuffer

Logs

db2dlock

db2pfchr

Control FileContainers

UserUser db2agent

db2loggr

One of the reasons for the ease of use enhancements with respect to configuration parameters on the previous slide is that in DB2 9.5 the engine is a threaded architecture on UNIX and Linux as well as on Windows. This means that every DB2 “process” in previous releases is now run as an operating “thread” within a single DB2 process (db2sysc). The blue rectangle above represents the single DB2 process and the blue ovals within it are all now DB2 threads. The benefit is that DB2 now has one large shared memory address space to which all working threads in DB2 can access. There is no separate agent private memory and database shared memory. Instead, all of the memory is shared (under the database shared memory) and therefore DB2 can now automate the allocation of memory more easily and with a greater impact on the overall throughput of the system by allocating memory where it is needed most.

DB2 Features for Leading Warehouse Performance

Warehouse Advantages in I/O reduction

• MDCs delivers smart scan for subsets of data• Partitioned tables and DPF further reduce data scanning• Compression reduces I/O requirements• Scan Sharing tops it off by intelligently sharing I/O

Large Scans Result in I/O Wait

The key to DB2 performance is in reducing the I/O bottleneck in most data warehouses. Take for example a simple SMP solution with one large server connected to a large storage array. By default if I want to find the sum of all sales for a certain product in the month of February, I would have to either rely on index keys to find those products. But, even in that case the amount of data can be so large that a brute force table scan may be the best access path. Oracle and others try to solve this problem by performing “big block I/O” whereby they try to read large quantities of data pages in one I/O in order to improve performance. However the problem is still the I/O throughput is not sufficient. Consider the above example where the red triangles are the records you are looking for. Because they are scattered throughout the table DB2 (or Oracle) needs to scan every page in a sequential fashion in order to find the rows it’s looking for. This is very inefficient.

DB2 Database Partitioning Feature = Divide I/ODatabase Partition 1 Database Partition 2 Database Partition 3

Unique

The fist solution to this problem is to scale out the database so that you have more scanners running in parallel. Using DB2’s database partitioning feature (DPF) you can divide the database into a set of smaller partitions where each database partition is managing a subset of the entire database (and therefore a subset of the table).By doing this, the scan in the previous example now runs 3 times as fast because each server is only scanning 1/3rd of the data.

January

February

March

Add Range Partitioning to Reduce Amount of ScanDatabase Partition 1 Database Partition 2 Database Partition 3

Now on top of this database partitioning scheme you can also add table partitioning (by range). This allows the table to be broken down by month (for example) so that the amount of data being scanned is again reduced. Taking the previous example, we can now scan only 1/9th of the data because we are only looking for February sales. By combining DPF and table partitioning, there is less data returned to the servers and all servers are processing that lower amount in parallel.

January

February

March

Add MDC to Further Reduce ScanDatabase Partition 1 Database Partition 2 Database Partition 3

Unique

Next we can add Multi Dimensional Clustering into the mix which allows DB2 to store data on disk in an organized fashion such that all the red triangle rows are in the same contiguous set of blocks on disk. DB2 is aware of this layout and will therefore only scan data pages that qualify to the query. In this example we have cut the scan down to only reading ½ of the February data because DB2 knows that it does not need to scan the purple triangle pages.Compared to the original SMP example, each server in this case is only scanning 1/18th of the original data and therefore the results should be returned at least 18 times faster.

January

February

March

Compression Reduces I/O by a factor of FourDatabase Partition 1 Database Partition 2 Database Partition 3

Unique

The final piece of the I/O challenge is to store more data in fewer data pages. In DB2 this is accomplished with unique compression capabilities that allow up to 80% compression of the data. As well DB2 9.7 adds similar compression for indexes and temp tables. By storing more data on fewer pages, DB2 is able to scan those pages up to 4 times quicker.

January

February

March

Compression Reduces I/O by a factor of FourDatabase Partition 1 Database Partition 2 Database Partition 3

Unique

As you can see there is much less data to scan and therefore query performance is improved in addition to the storage savings you achieve from compression. Add to that the fewer spindles that need to be purchased and powered/cooled, and you can see that compression can add significant cost savings.

January

February

March

Plus DB2 Automatically Parallelized ScansDatabase Partition 1 Database Partition 2 Database Partition 3

Although not previously mentioned, since it’s inception, DB2 has striped data within a table across multiple drives internally (separate from file systems striping the data). In the examples shown thus far we have shown scanning one disk and then the next. In reality, DB2 will scan both disks simultaneously using prefetcher agents to accomplish this task thus improving the parallelism of the system.

Row Compression Using a Compression Dictionary

• Dictionary contains repeated information from the rows in the table• Compression candidates can be across column boundaries or

within columns

L4N5R4ONTWhitby82475500Katsopoulos

L4N5R4ONTWhitby56105510Zikopoulos

Postal_CodeProvinceCitySalaryDeptName

Dictionary

WhitbyONTL4N5R402……

opoulos01

L4N5R4Katsopoulos 500 82475 Whitby ONT …L4N5R4ONTWhitby56105510Zikopoulos

Kats (01) 500 82475 (02)(02) …56105510Zik (01)

Uniqueto DB2

Here is an example to illustrate the compression. Here we may have a table of employees last names, departments, salaries, and addresses.Illustrated here is the fact that DB2 can compress substrings of a column (for example just a part of someone's name like ‘opoulos’) and that it can also compress data across column boundaries (like City and Province and Postal_Code) all into one symbol. The blue row shows the data before compression while the bottom row with yellow text shows the data after compression

• Non technically speaking• How many people in your department share the same birthdate?• How many people in your entire company share the same birthdate?• DB2 looks at a much large population of data and therefore finds more

patterns to compress

• In a research paper on compression written by Oracle engineers they state:“Due to its global optimality of compression a table-wide dictionary approach can result in high compression factors.”

Key DB2 advantages over Oracle

VLDB 2003 http://wwwdb.informatik.uni-rostock.de/vldb2003/papers/S28P01.pdf

“Row-level compression is a revolutionary development that will leave Oracle and Microsoft green with envy”.

DB2Oracle

60% (3x better)18%ORDERS

58% (1.5x better)38%LINEITEM

Compression RatioTable

If you look at Oracle from a non technical example, it would be like asking your audience “How many of you have a birthdate of June 15?” Likely you will get no one raising their hand in a small to medium size crowd. Why? Because you are looking at a small domain of data (one room worth). However if you asked “How many people in this company have a birthdate of June 15?” you will likely find thousands of people have the same birthdate. Why? Because there are a finite number of possible birthdates and so that pattern repeats itself often if you have a large sample size. The same is true for transactional data…if you look at a small sample size (one page of data) you won’t find as many repeating patterns as if you looked at the entiretransactions for the company.

In fact, in a research paper, two Oracle engineers wrote “Due to its global optimality of compression a table-wide dictionary approach can result in high compression factors”. This proves IBM’s value proposition that the DB2 9 compression capability delivers higher compression and therefore better performance and better value. The link at the bottom of this chart is from the Oracle Engineers research paper on this subject.

• Multiple algorithms for automatic index compression

• Automatic compression for temporary tables

• Intelligent and automatic LOB and XML compression

DB2 9.7 Compression Enhancements

Of course DB2 is not standing still in the area of storage savings either. Storage costs continue to be a concern for customers and so the latest release of DB2 9.7 (codenamed Cobra) delivers even more storage savings.

Two examples of this are in the area of index compression and TEMP table compression. In DB2 9.7, you can not only be able to compress tables but DB2 will also provide automatic compression for indexes as well. In fact there are a number of ways to compress indexes based on the type of index and the data distribution within that index. DB2 will be able to examine the index data and automatically chose from a set of compression algorithms that provides an optimal compression for the index.Similarly DB2 will automatically compress temporary data. This can be a huge savings for data warehouse applications where large sorts and large intermediate result sets can consume a significant amount of storage. In DB2 9.7, temporary tables used for sorting and intermediate query results will automatically be compressed if they consume a significant amount of storage thus saving you even more on your storage costs.

• For indexes, Oracle stores a single entry for every key/rid pair• Even for duplicate keys, Oracle still stores one index key for every rid• DB2 stores one key followed by a rid list• DB2 index storage is much more efficient

• Compression in DB2 makes indexes even smaller• DB2 has more compression algorithms for index compression than Oracle

DB2 Index Storage More Efficient

PhoneNumberLastName

416-444-9898Eaton

416-444-1234Eaton

905-555-9191Easton

905-555-4321Easton

905-555-1234Easton

Easton

Eaton

Eaton

Oracle Index Page

Easton

Easton

Index Key RID

Eaton

Easton

Index Key RID List

DB2 Index Page Phone Book Table

In Oracle the index pages contain key/rid pairs. That is, every index entry contains the column value (key) and the row id in the table for that given column value. If the index is not unique then you will find duplicate key values in a given index page. Oracle will store the duplicates over and over again in the index page. DB2 has a much more efficient index page structure. For duplicate keys, DB2 stores the key just once followed by a list of row ids that correspond to that key. This can result in an index that is an order of magnitude smaller in DB2 than in Oracle (even before any compression algorithms are applied).

Another advantage with DB2 is that, as previously shown, DB2 supports both rid list compression and prefix compression. Oracle only supports prefix compression. As well the prefix in Oracle is fixed when you create the index. It is defined as a fixed column or set of columns. With DB2 9.7 the prefix size is dynamic and can change from one row to the next in order to deliver optimal compression. With DB2 the prefix can be a column, a set of columns or a substring of a column and DB2 will decide what prefix to use for each individual key (or set of keys) on the page.

• DB2 delivers superior compression through additional capabilities not available in 11gR2

Competitive Comparison to Oracle

25

Scan Sharing• Multiple similar SQL statements can share a single

table scan• Table scans start at the current location of a previous scan

to form “scan groups”• Once the group scan finishes, individual scans “wrap” to

read missed data• Allows separate queries to use the same I/O

• Benefits• Reduce overall I/O bandwidth consumption• Improve buffer pool hit ratios by preventing page

victimization within a scan

Scan Sharing is the ability of a scan to use the buffer pool pages of another scan. Scan sharing is useful in situations where the system might not be not optimally tuned or the system might be I/O bound. Scan sharing is particularly effective in environments with applications that perform scans such as table scans or MDC block index scans of large tables.

On the left we see two statements that each do their own scans of the data, because scan sharing is not turned on. On the right (with scan sharing) statement 2 starts at time t1, after statement 1 has been running for some period of time. They can then share the scan from that point forward, and once that scan is done, DB2 will go back and rescan the rows that the scan had processed before statement 2 started piggy backing on the scan. So only a small percentage of the data is scanned twice, vs. all of the data scanned twice in previous releases of DB2.

Multiple Scanners pre 9.7

User 1 Scans Data

User 2 Scans Data

Buffer Pool

Pages may wrapin the buffer pool

Rereading pages previously evicted

Here is how scans work prior to DB2 9.7. If user 1 starts scanning a table, then it must read all of the pages in the table.

A second user that is scanning the same table, will re-read the pages, even if the scan for user 1 is still running.

Reread onlymissing pages

Multiple Scanners in 9.7

User 1 Scans Data

User 2 Scans Data

Buffer Pool

Start scan 2 at current

position of scan 1

With scan sharing, the table scan for user 2 will start where the current scan for user 1 is, and once that hits the end of the table, it will wrap around and start from the beginning of the table, reading in the pages that it skipped over initially.

DB2 scalable infrastructure for scale up and scale out

DB2 Architecture Maps to POWER7 For Scale-Up

• POWER7 – massive number of threads per server• Requires sophisticated software to exploit

• DB2 threaded engine built to scale on large multi core servers• Requires sophisticated virtualization to consolidate

• DB2 autonomics “play nice” and “reacts automatically” in virtualized, dynamic environments

• Requires advanced workload management to meet SLAs• DB2 and AIX tightly integrated WLM to deliver the resources where they

are needed most• Requires advanced diagnostics to help lower administration costs

for customers with massive levels of concurrency• The blue stack helps resolve problems faster with integrated diagnostics

• Requires integrated high availability• If any part of the solution fails, DB2 and PowerHA respond more rapidly to

provide business continuity

This chart talks specifically about the consolidation capabilities that POWER7 is known for and how DB2 is designed to exploit the POWER7 architecture like no other software on the market today.

Transparent Application Scaling - OLTP Scale Out

• Scalability without application or database partitioning• Centralized locking and real global buffer pool with RDMA access results

in real scaling without making application cluster aware• Sharing of data pages is via RDMA from a true shared cache

• not synchronized access via process interrupts between servers)• No need to partition application or data for scalability

• Resulting in lower administration and application development costs

• Distributed locking in RAC results in higher overhead and lower scalability• Oracle RAC best practices recommends

• Fewer rows per page (to avoid hot pages)• Partition database to avoid hot pages• Partition application to get some level of scalability• All of these result in higher management and development costs

As previously mentioned, the critical success factor for scalability in an active-active cluster is to ensure that when a transaction requests a piece of data, it can get that data with the lowest amount of latency. With DB2 pureScale, by centralizing data that is of interest to more than one member in the cluster, and by accessing that data using RDMA in an interrupt free processing environment, you can see near linear scalability even out to dozens of nodes.

More importantly, you do not need to design your application to be cluster aware. There is no need to route transactions that access the same data pages to a single node.

In practice, this is not the case with Oracle RAC. There are many stories on the internet, and in published books on Oracle RAC that tell customers to avoid hot pages being passed between nodes by using one of the methods described in the last 4 bullets of the above slide. These methods require costly DBA and application developer interventions, as well as potential application rework as the size of the cluster changes.

Agent on Member 1 wants to read page 5011. db2agent checks local buffer pool: page not found2. db2agent performs Read And Register (RaR) RDMA call directly into

CF memory– No context switching, no kernel calls. – Synchronous request to CF

3. CF replies that it does not have the page (again via RDMA)4. db2agent reads the page from disk

Group Buffer Pool

CF

Buffer Pool

Member 1

What Happens in DB2 pureScale to Read a Page

db2agent

1

2

3

4501 501

PowerHA pureScale

This slide illustrates the advantage of DB2 pureScale for very efficient access to data. A comparison to Oracle RAC will follow in the next section. The steps listed above show you how DB2 pureScale communicates with the CF to declare its intent to access a data page. Steps 2 and 3 are the critical success factors to DB2 pureScale efficiency. That is, when there is a need to communicate with the centralized CF, that communication uses RDMA. Essentially, the process on member 1 writes directly into the memory of the CF with its request. This is done without going through the IP socket stack, without context switching and in many cases without having to yield the CPU (the round trip communication time between the two servers can be as little as 15 microseconds).

The Advantage of DB2 Read and Register with RDMA1. DB2 agent on Member 1 writes directly into CF memory with:

• Page number it wants to read• Buffer pool slot that it wants the page to go into

2. CF either responds by writing directly into memory on Member 1:• That it does not have the page or• With the requested page of data

• Total end to end time for RAR is measured in microseconds• Calls are very fast, the agent may even stay on the CPU for the response

Much more scalable, does not require locality of data

db2agent CF thread

Direct remote memorywrite with request

I don’t have it, get it from disk

I want page 501. Put into slot 42

of my buffer pool.Direct remote memorywrite of response

Member 1 CF

1, Eaton, 10210, SW2, Smith, 10111, NE3, Jones, 11251, NW

To dive deeper into the “secret sauce” let’s look at exactly how the member communicates with the CF.

If an agent on member 1 wants to read a page, that agent will write directly into the member of the CF telling the CF exactly what page it wants and even telling it what slot in its buffer pool that the page will go into on Member 1.

If the CF does not have the page, it writes a message right into the memory of Member 1 to indicate that it doesn’t have the page. If the CF does have the page, it writes the data page directly into memory on Member 1 without any context switching or IP stack calls.

• How far will it scale out?

• Take a web commerce type workload• Read mostly but not read only

• Don’t make the application cluster aware• No routing of transactions to members• Demonstrate transparent application scaling

• Scale out to the 128 member limit and measure scalability

Proof of DB2 pureScale Architecture Scalability

To demonstrate the scalability of DB2 pureScale, the lab set up a configuration comprised of 128 members (note that for server consolidation environments it is possible to put multiple members on an SMP server). A workload was created where the read to write ratios are typically 90:10. As well, to prove the scalability of architecture, the application has no cluster awareness. In fact the application updates or selects a random row and therefore every row in the database will be touched by all members in the cluster (we did this to show that locality of data is not as essential for scaling as with other shared disk architectures)

The Result

64 Members 95% Scalability

16 Members Over 95% Scalability

2, 4 and 8 Members Over 95% Scalability

32 Members Over 95% Scalability

88 Members 90% Scalability

112 Members 89% Scalability

128 Members 84% Scalability

Validation testing includes capabilities to be available in future releases.

The results of this 128 member test show that there is near linear scaling even out to 128 members in the cluster. Up to 64 members in the cluster, the scalability (compared to the 1 member result) is still above 95% and at 128 members the scalability was at 84%.

Note that this is a validation of the architecture and includes some capabilities under development that will not be in the December GA code.

Buffer CacheInstance 2

Buffer Cache

Oracle RAC - Single Instance Wants to Read a PageProcess on Instance 1 wants to read page 501 mastered by instance 2

1. System process checks local buffer pool: page not found2. System process sends an IPC to the Global Cache Service process to get

page 501– Context Switch to schedule GCS on a CPU– GCS copies request to kernel memory to make TCP/IP stack call

3. GCS sends request over to Instance 2– IP receive call requires interrupt processing on remote node

4. Remote node responds back via IP interrupt to GCS on Instance 15. GCS sends IPC to System process (another context switch to process request)6. System process performs I/O to get the page

system

1

23

4GCS GCS

5

6501

501

Instance 1

A pureScale example was shown in earlier in this presentation. In the case of RAC there is a much more costly infrastructure to read a data page.

A server process that wants to access a data page, for example page 501, will first check to see if that page is in its local buffer pool (step ). If this page is not found, the server process will send an inter-process communication (IPC) request to a GCS process in order to ask the master node for that data page ( ). This results in the server process yielding the CPU and the CPU performing a context switch to potentially re-establish the GCS process on the CPU to process the interrupt. High levels of context switching can be very costly to perform. The GCS process then sends an IP request to the master node for the data block being requested ( ). Because IP calls are processed in the operating system kernel, the GCS process has to copy the requested information into kernel memory and then execute expensive IP stack calls to push the request to the remote node. Even if an InfiniBand network is being used, Oracle still uses IP over InfiniBand or in some cases Reliable Datagram Sockets (RDS). Use of a socket protocol even over InfiniBand is costly due to processor interrupts, IP stack traversal, etc.

Next, the remote master GCS process will receive an interrupt and will be scheduled on the CPU to process the request. It will check to see if any other members have the page in its buffer cache. In this example, no member has the page so the GCS process will send an IP message back to the requester telling it to read the page from disk ( ). The GCS processes on the requesting node will be interrupted again to process the incoming IP request, and will in turn send an IPC interrupt ( ) to the server process to inform it that no other node in the cluster has the page. The server process will then read the page from disk into its own buffer cache ( ).

Scalability Differences

• Oracle RAC must lock a page whenever there is the intent to update that page

• DB2 pureScale must lock a page whenever rows are actually being changed on that page

• DB2 pureScale improves concurrency between members in a cluster which results in better scalability and less of a needfor locality of data

The key scalability difference between Oracle RAC and DB2 pureScale is that there is less communication with DB2 pureScale during transaction processing. What’s more, all communication is much more efficient (via RDMA). As well, when there are multiple nodes in the cluster that want to access the same data pages, DB2 allows greater levels of concurrency and only locks the page during the actual update of the row, not just with the intent to update the rows as is the case with Oracle RAC.

Manageability and autonomic computing advantages

• “Run in this mode” knob• Think about your microwavable

popcorn experience

• Automatically optimize DB2 for your applications

• Including POWER7 Optimizations

Workload Optimized Systems

“STMM in DB2 is rock solid, no matter how many transactions our customers throw at DB2 it just auto configures and hums along. We support hundreds of clients running DB2 with our product and the vast majority do not have on-staff DBAs. We have 4 DBAs that support these hundreds of installations of DB2. This would not be possible without the autonomics built into DB2.Generally, we just set it and forget it.”— Michael Petkau, Director of Development TMW Systems

39

Self-Tuning Memory Manager

• Revolutionary memory tuning system • Works on main database memory parameters

– Sort, locklist, package cache, buffer pools, and total database memory

• Hands-off online memory tuning• Requires no DBA intervention• Senses the underlying workload and tunes the memory based on

need• Can adapt quickly to workload shifts that require memory

redistribution• Adapts tuning frequency based on workload

As mentioned briefly on a previous slide, DB2 has a very advanced method for ensuring optimal performance by automatically managing database memory. In DB2, this feature is called the Self Tuning Memory Manager (STMM). This works on all the major memory consumers (bufferpools, sortheaps, locklist, and more). The way it works is that each memory area monitors itself to determine what benefit additional memory would have on overall performance of the system (in terms of milliseconds saved) for a given amount of additional memory. The STMM component monitors each of the memory areas on a regular basis and will then allocate additional memory to areas that are in most need (that is, which would produce the best performance gain) while at the same time ensuring that the memory on the entire system is not overly constrained. By doing so, DB2 can react to changes in workloads on a regular basis and tweak the database memory to ensure consumers are being satisfied.

40

0

1000000

2000000

3000000

4000000

5000000

6000000

7000000

0 10000 20000 30000 40000 50000 60000 70000

Time (in seconds)

Mem

ory

(in 4

K P

ages

)

STMM In Action Two Databases On The Same Box Unique to DB2Unique to DB2

One unique feature about the Self Tuning Memory Manager is that it allows for memory sharing across databases and even across instances running on the same server. The graphic above demonstrates this ability. The pink line represents the memory consumption for a workload running on one database. You can see that it adjusts itself initially and then reaches close to a steady state as it zones in on the optimal settings. Then just after the 20,000 second mark, another database is started. The blue line represents the memory consumption for the second database. You can see that it ramps up quickly to respond to the incoming workload and simultaneously the first database (purple line) gives up some of its memory in order to avoid overtaxing the server and to enable sharing between the two instances. The two databases consume roughly the same amount of memory because they are both running the same workload in this case. Note that the two databases could be in the same or in different instance (the results would be the same). At the 50,000 second mark on the graph the second database is stopped and you can see that the pink line quickly goes back to steady state optimal performance.

Solitaire Interglobal Survey of 400 IBM Power clients

Solitaire Interglobal Ltd Whitepaper: DB2 Performance on IBM System p® and System x®

High availability advantages with DB2

Steps Involved in DB2 pureScale Member Failure

1. Failure Detection

2. Recovery process pulls directly from CF:• Pages that need to be fixed• Location of Log File to start recovery from

3. Restart Instance performs redo and undo recovery

There are 3 things that occur during an instance failure at a high level1. Failure detection2. Pull pages that need to be fixed directly from CF memory3. Fix the pages

In each of these steps, DB2 pureScale has been optimized with the goal of getting these pages fixed and having them accessible in under 20 seconds (all the while the rest of the data in the database is completely available).

Failure Detection for Failed Member

• DB2 has a watchdog process to monitor itself for software failure• The watchdog is signaled any time the DB2 member is dying• This watchdog will interrupt the cluster manager to tell it to start recovery• Software failure detection times are a fraction of a second

• The DB2 cluster manager performs very low level, sub second heart beating (with negligible impact on resource utilization)

• DB2 cluster manager performs other checks to determine congestion or failure

• Result is hardware failure detection in under 3 seconds without false failovers

Failure detection was a large part of the investment that went into DB2 pureScale.

Software failure in a DB2 pureScale environment has been architected to be caught in a fraction of a second and to begin the driving of recovery processing within that second. Hardware failure is a more difficult challenge, but thanks to some innovative techniques, DB2 pureScale has built in a set of algorithms that can detect node failures in as little as 3 seconds without false failovers.

When we talk about having the rows available again within 20 seconds of a failure, we mean from the time the failure occurred, not the time the failure was detected. Other vendors may exclude this time to give better numbers but from an end user this time is critical and so we include it.

Steps involved in a RAC node failure

1. Node failure detection

2. Data block remastering

3. Locking of pages that need recovery

4. Redo and undo recovery

Unlike DB2 pureScale, Oracle RAC does not centralize lock or data cache

In Oracle there are a similar set of steps to recover from a filed instance. However the middle two are where things are very different when compared to DB2 pureScale:

1. Node failure detection2. Global lock remastering3. Lock pages that need recovery4. Fix those pages

The biggest difference is that with DB2 pureScale there is centralized locking so there is no need to remaster global locks. Also pureScale does not need to find the pages to lock (it is already aware of the pages that need to be fixed).

With RAC – Access to GRD and Disks are Frozen

• Global Resource Directory (GRD) Redistribution

No more I/Ountil pages that need recovery are locked

No Lock Updates

GRD GRD

Instance 1 failsInstance 1 Instance 2 Instance 3

I/O Requests are Frozen

GRD

In Oracle RAC, each data page (called a data block in Oracle) is mastered by one of the instances in the cluster. Oracle employs a distributed locking mechanism and therefore each instance in the cluster is responsible for managing and granting lock requests for the pages that it masters. In the event of a node failure, the data pages for the failed node become momentarily orphaned while RAC goes through a lock redistribution process to assign new ownership of these orphaned pages to the surviving nodes in the cluster. This is called Global Resource Directory (GRD)reconfiguration and while this is occurring, any request to read a page, as well as any request to lock a page, is momentarily frozen. Applications can continue to process on the surviving nodes, however, during this time, they cannot perform any I/O operations or request any new locks. This results in many applications experiencing a freeze as shown in this slide.

With RAC – Pages that Need Recovery are Locked

GRD GRD

Instance 1 fails

I/O Requests are Frozen

Instance 1 Instance 2 Instance 3

Recovery Instance reads log of failed node

Recovery instance locks pages that need recovery

x

xx

xx x

redo log redo log redo log

GRD Must read log andlock pages beforefreeze is lifted.

The second step in the Oracle RAC node recovery process is to lock all the data pages that need recovery. This must be done before the GRD freeze described earlier is released. If an instance was allowed to read a page from disk before the appropriate page locks were acquired, the update from the failed instance could be lost. The recovery instance performs a first pass read of the redo log file from the failed instance and locks any pages that need recovery as shown in Figure 2. This may require a significant number of random I/O operations as the log file, and potentially the pages that need recovery, may not be in the memory of any of the surviving nodes.

The GRD freeze is lifted and the stalled applications can continue processing only after all these I/O operations are performed by the recovery instance and the appropriate pages are locked. Depending on the amount of work that the failed node was doing at the time of the failure, this process can take from tens of seconds up to as much as a minute before it completes. This GRD freeze and the fact that I/O operations cannot be performed during this period or new lock requests granted, is documented in several published books on Oracle RAC.

CF

Central Lock Manager

DB2 pureScale – No Freeze at All

Member 1 failsMember 1 Member 2 Member 3

No I/O Freeze

CF knows what rows on these pages had in-flight updates at time of failure

x

xx

xx x

xx

xx x x

CF always knowswhat changes are

in flight

In comparison, DB2 pureScale environments require no global freeze in the cluster. The CF is aware at all times which pages would need recovery should any member fail. If a member fails, all other members in the cluster can continue to run transactions and perform I/O operations. Only requests to access pages that need recovery will be blocked while the recovery process cleans up from the failed member as shown on this slide (and the process is likely to happen from memory).

Summary

• DB2 has several technical advantages

• Better performance results in lower costs

• Better storage utilization results in lower costs

• Easier to manage means more focus on business needs

• Higher availability and transparent scalability allows you to meet your SLAs

Chris EatonIBMceaton@ca.ibm.comD10Defend your Turf – DB2 Technical Advantages over Oracle

50