Buffer Pool Tuning for DB2

Buffer Pool Tuning for DB2
TBRUG – May 2012 Buffer Pool Tuning for DB2 Warren Hawkins Principal Software Consultant

DB2 Dynamic Buffer Pool Management Agenda
Storage in the 64 bit “z” world Virtual storage in DB2 Buffer Pool Basics Dynamic Buffer Pool Tuning Static Buffer Pool Tuning Summary

Storage in the 64 bit “z” world
And Now - The BEAM 64 bits - 16EB 24 bits - 16MB 32 bits - 4GB 31 bits - 2GB 49 bits - 512TB The Line The Bar Wasted Below the Line Above the Line Reserved For System User Area Above the Bar (note: not to scale!!) You can now address 8.6 Billion times as much storage… Another way of looking at it: If you can transfer 2GB in 1 second, Then 16EB would take over 272 years!

Time for a vocabulary review… Kilobyte =210 bytes ~103 (actually 1024) Megabyte = ~106 (a million bytes) Gigabyte = ~109 Terabyte = ~1012 (a million megabytes) Petabyte = ~1015 Exabyte = ~1018 (a million terabytes) Zettabyte = ~1021 Yottabyte = ~1024 (a million exabytes)

If we compare improvements over the past 10+ years: Virtual storage 2GB  16EB x 8 billion DB Size GB  20 TB ? x 100 Real Storage 8GB  1 TB (LPAR) x 128 CPU mips  17,802 mips (LPAR) x 48 I/O time ms  2-3ms x 10-15 As always, it is having to do I/O that really slows things down DB2 uses Virtual Storage to reduce I/O and improve performance Eliminating as much synchronous I/O as possible is the key Lower elapsed time & lower CPU for same work Higher through-put

DB2 Virtual Storage DB2 V8 & Beyond
DB2 v8, 9, and 10 exploit 64 bit architecture Each release providing more exploitation Virtual storage constraints dramatically reduced No more hiperspace or dataspace workarounds Many storage pools moved “above the bar” Buffer pools EDM pool split up and now mostly ATB Dynamic Statement Cache DBD pool Skeleton CT and PT pool Part of the CT and PT pool (new in v10) RID pool, Sort pool, other areas moved Above The Bar Local statement cache (new in v10) Some storage areas still below the bar DB2 10 reportedly has moved almost 90% of their storage usage ATB Real storage now the constraint (system paging) And is likely to be for a long time

Virtual Storage in DB2 Tuning Buffer Pools
Tuning DB2 storage usage starts with the buffer pools The biggest storage consumer Usually the biggest performance impact DB2 allows quite a bit of page-set segregation Across 80 buffer pools 4K BPs 8K BPs 16K BPs 32K BPs BP0 BP8K0 BP32K BP16K0 BP49 BP32K9 BP8K9 BP16K9 DBM1 50 10 10 10

Buffer Pool Tuning - Questions to Ask
What kind of workloads do you support? Mostly Static; very predictable Mostly Dynamic; not predictable Buffer Pools Should there be more of them? Are they configured right for the workloads? Are there more I/O delays than necessary? Is DB2 suffering system paging delays? Am I using all the resources I have available? Efficiently? Wasting any? Is Prefetch working well? How about SORT?

Buffer Pool Tuning Considerations
Tuning DB2 Buffer Pools involves many considerations, including Segregating pagesets into separate pools based upon Data sharing Object type (table, index, workfile, LOB, system object) Sequential vs random access Update level Activity level Object size Object importance or priority Sizing the pools adequately Setting the thresholds appropriately

Tuning DB2 Buffer Pools Things to consider
The more data is segregated into different pools, the more your storage is divided up, and the more you risk having fluctuations in workload cause one pool to become over committed while another is near idle. A compromise between segregation and complexity is required. Higher complexity can result in better potential performance, but may also require more diligent monitoring to ensure that all sizing is correct and no rogue applications are causing problems.

Dynamic Buffer Pool tuning
Automobile technology as an analogy Over the last few decades car performance has increased significantly through such enhancements as Cruise control Anti-lock brakes Active suspension systems Positive traction systems All of these features represent automatic adjustments to tune performance to changing conditions And the improvements can be dramatic

Dynamic Buffer Pool tuning
Storage tuning in DB2 has similar challenges Whether your buffer pools are roughly configured or highly tuned, real performance will vary with workload fluctuations Depending on the setup and nature of the fluctuations the performance impact can be dramatic Rogue workloads Environment changes such as night versus day Weekends Month ends

Dynamic Buffer Pool Tuning
Dynamic tuning can be defined as real-time configuration changes in response to workload demands. Details are fairly simple If real performance is being impacted (as determined by synchronous IO counts), consider adjusting pool sizes and thresholds in order to reduce the number of sync I/Os Execution is a bit more complicated Only increase if storage is available, and if there is no significant paging Onset of significant paging would suggest that decreases are needed Management of sequential steal thresholds depends on objectives when random and sequential workloads collide favor random or sequential?

Buffer Pool Tuning Metrics We Like
SYNC I/O - this is I/O that makes an application wait. Always for a single page per I/O. ASYNC I/O - this is I/O done ahead of time by DB2, multiple pages, so that hopefully the application won’t have to wait. This is PREFETCH I/O. PgRds/Sec - Page Reads per second. Pages read by SYNCIO and ASYNCIO per second. This represents the “arrival rate” of new pages into the pool. Residency Time – The size of a pool in pages divided by the arrival rate yields the minimum number of seconds that a page in remain in a pool. System Hit Ratio - The ratio of the number of getpages resolved without read I/Os (synchronous or prefetch) to the total number of getpages. In this calculation, prefetched pages are subtracted from the hit count whether they are actually used or not. Note that this number can actually go negative. Application Hit Ratio - The ratio of the number of getpages resolved without synchronous read I/Os to the total number of getpages. In this calculation, prefetched pages are NOT subtracted from the hit count since application waits have been avoided. Getpages Delayed - The percentage of getpages that were delayed because of synchronous read I/O

Dynamic Buffer Pool tuning – Scenario 1
Here is an example of a simple pool increase in response to workload change Storage is available to make the increase We run a workload once without making any changes Controlled system Use Display Bufferpool commands before and after to document the getpages and sync I/O activity. Then run the same workload again and this time make size changes in response to degrading performance metrics Compare the final sync I/O counts from both runs

We start with a clean buffer pool on a V8 DB2 (controlled access) STC DSNB401I *DECO BUFFERPOOL NAME BP49, BUFFERPOOL ID 49, USE COUNT 0 STC DSNB402I *DECO BUFFER POOL SIZE = 1000 BUFFERS 524 ALLOCATED = TO BE DELETED = IN-USE/UPDATED = BUFFERS ACTIVE = STC DSNB406I *DECO PGFIX ATTRIBUTE CURRENT = NO PENDING = NO PAGE STEALING METHOD = LRU STC DSNB404I *DECO THRESHOLDS VP SEQUENTIAL = 10 DEFERRED WRITE = 10 VERTICAL DEFERRED WRT = 5, 0 PARALLEL SEQUENTIAL =59 ASSISTING PARALLEL SEQT= 9 STC DSNB408I *DECO NO DETAIL STATISTICS AVAILABLE FOR BUFFER POOL BP49 STC DSN9022I *DECO DSNB1CMD '-DIS BPOOL' NORMAL COMPLETION And run a workload that completes in about 10 minutes

On completion of the run STC DSNB401I *DECO BUFFERPOOL NAME BP49, BUFFERPOOL ID 49, USE COUNT 3 STC DSNB402I *DECO BUFFER POOL SIZE = 1000 BUFFERS 740 ALLOCATED = TO BE DELETED = IN-USE/UPDATED = BUFFERS ACTIVE = STC DSNB406I *DECO PGFIX ATTRIBUTE CURRENT = NO PENDING = NO PAGE STEALING METHOD = LRU STC DSNB404I *DECO THRESHOLDS VP SEQUENTIAL = 10 DEFERRED WRITE = 10 VERTICAL DEFERRED WRT = 5, 0 PARALLEL SEQUENTIAL =59 ASSISTING PARALLEL SEQT= 9 STC DSNB410I *DECO CUMULATIVE STATISTICS SINCE 15:24:21 MAY 2, 2007 STC DSNB411I *DECO RANDOM GETPAGE = SYNC READ I/O (R) = SEQ. GETPAGE = SYNC READ I/O (S) = DMTH HIT = PAGE-INS REQUIRED =

We again start with a clean buffer pool on a V8 DB2 (controlled access) STC DSNB401I *DECO BUFFERPOOL NAME BP49, BUFFERPOOL ID 49, USE COUNT 0 STC DSNB402I *DECO BUFFER POOL SIZE = 1000 BUFFERS 020 ALLOCATED = TO BE DELETED = IN-USE/UPDATED = BUFFERS ACTIVE = STC DSNB406I *DECO PGFIX ATTRIBUTE CURRENT = NO PENDING = NO PAGE STEALING METHOD = LRU STC DSNB404I *DECO THRESHOLDS VP SEQUENTIAL = 10 DEFERRED WRITE = 10 VERTICAL DEFERRED WRT = 5, 0 PARALLEL SEQUENTIAL =59 ASSISTING PARALLEL SEQT= 9 STC DSNB408I *DECO NO DETAIL STATISTICS AVAILABLE FOR BUFFER POOL BP49 STC DSN9022I *DECO DSNB1CMD '-DIS BPOOL' NORMAL COMPLETION And run the same workload

Several minutes into the test we notice a performance problem and issue a command to adjust the sequential steal threshold STC DSNB522I *DECO VPSIZE FOR BP49 HAS BEEN SET TO 3500 STC DSN9022I *DECO DSNB1CMD '-ALTER BPOOL' NORMAL COMPLETION © Copyright 4/16/2019 BMC Software, Inc.

On completion of the run STC DSNB401I *DECO BUFFERPOOL NAME BP49, BUFFERPOOL ID 49, USE COUNT 3 STC DSNB402I *DECO BUFFER POOL SIZE = 3500 BUFFERS 547 ALLOCATED = TO BE DELETED = IN-USE/UPDATED = BUFFERS ACTIVE = STC DSNB406I *DECO PGFIX ATTRIBUTE CURRENT = NO PENDING = NO PAGE STEALING METHOD = LRU STC DSNB404I *DECO THRESHOLDS VP SEQUENTIAL = 10 DEFERRED WRITE = 10 VERTICAL DEFERRED WRT = 5, 0 PARALLEL SEQUENTIAL =59 ASSISTING PARALLEL SEQT= 9 STC DSNB410I *DECO CUMULATIVE STATISTICS SINCE 14:59:54 MAY 2, 2007 STC DSNB411I *DECO RANDOM GETPAGE = SYNC READ I/O (R) = 3933 SEQ. GETPAGE = SYNC READ I/O (S) = DMTH HIT = PAGE-INS REQUIRED =

The results Without adjustments RANDOM GETPAGE = SYNC READ I/O (R) = SEQ. GETPAGE = SYNC READ I/O (S) = With adjustments RANDOM GETPAGE = SYNC READ I/O (R) = SEQ. GETPAGE = SYNC READ I/O (S) = This is pretty much what we would expect from increasing the buffer pool size It works, without surprises

Of course if we’ve optimized our resources, then we have already assigned all the available storage to something. We cannot increase a pool under stress without incurring paging. But are all the pools under stress? In this example we have two pools; one is under-utilized while the other is suddenly over-stressed by an unusual influx of workload. As before, we run the scenario twice, once leaving everything static, and once allowing changes to be made.

We start with 2 clean buffer pools on a V8 DB2 (controlled access) STC DSNB401I *DECO BUFFERPOOL NAME BP25, BUFFERPOOL ID 25, USE COUNT 0 STC DSNB402I *DECO BUFFER POOL SIZE = 500 BUFFERS 555 ALLOCATED = TO BE DELETED = IN-USE/UPDATED = BUFFERS ACTIVE = STC DSNB406I *DECO PGFIX ATTRIBUTE CURRENT = NO PENDING = NO PAGE STEALING METHOD = LRU STC DSNB404I *DECO THRESHOLDS VP SEQUENTIAL = 10 DEFERRED WRITE = 75 VERTICAL DEFERRED WRT = 18, 0 PARALLEL SEQUENTIAL =55 ASSISTING PARALLEL SEQT= 5 STC DSNB408I *DECO NO DETAIL STATISTICS AVAILABLE FOR BUFFER POOL BP25 STC DSN9022I *DECO DSNB1CMD '-DIS BPOOL' NORMAL COMPLETION STC DSNB401I *DECO BUFFERPOOL NAME BP49, BUFFERPOOL ID 49, USE COUNT 0 STC DSNB402I *DECO BUFFER POOL SIZE = 6000 BUFFERS 562 ALLOCATED = TO BE DELETED = IN-USE/UPDATED = BUFFERS ACTIVE = STC DSNB406I *DECO PGFIX ATTRIBUTE CURRENT = NO PENDING = NO PAGE STEALING METHOD = LRU STC DSNB404I *DECO THRESHOLDS VP SEQUENTIAL = 10 DEFERRED WRITE = 10 VERTICAL DEFERRED WRT = 5, 0 PARALLEL SEQUENTIAL =59 ASSISTING PARALLEL SEQT= 9 STC DSNB408I *DECO NO DETAIL STATISTICS AVAILABLE FOR BUFFER POOL BP49 And run a workload that completes in about 10 minutes

On completion of the run STC DSNB401I *DECO BUFFERPOOL NAME BP25, BUFFERPOOL ID 25, USE COUNT 4 STC DSNB402I *DECO BUFFER POOL SIZE = 500 BUFFERS 783 ALLOCATED = TO BE DELETED = IN-USE/UPDATED = BUFFERS ACTIVE = STC DSNB406I *DECO PGFIX ATTRIBUTE CURRENT = NO PENDING = NO PAGE STEALING METHOD = LRU STC DSNB404I *DECO THRESHOLDS VP SEQUENTIAL = 10 DEFERRED WRITE = 75 VERTICAL DEFERRED WRT = 18, 0 PARALLEL SEQUENTIAL =55 ASSISTING PARALLEL SEQT= 5 STC DSNB410I *DECO CUMULATIVE STATISTICS SINCE 23:48:25 MAY 1, 2007 STC DSNB411I *DECO RANDOM GETPAGE = SYNC READ I/O (R) = 65200 SEQ. GETPAGE = SYNC READ I/O (S) = DMTH HIT = PAGE-INS REQUIRED = ... STC DSNB401I *DECO BUFFERPOOL NAME BP49, BUFFERPOOL ID 49, USE COUNT 3 STC DSNB402I *DECO BUFFER POOL SIZE = 6000 BUFFERS 800 ALLOCATED = TO BE DELETED = IN-USE/UPDATED = BUFFERS ACTIVE = STC DSNB406I *DECO PGFIX ATTRIBUTE CURRENT = NO PENDING = NO PAGE STEALING METHOD = LRU STC DSNB404I *DECO THRESHOLDS VP SEQUENTIAL = 10 DEFERRED WRITE = 10 VERTICAL DEFERRED WRT = 5, 0 PARALLEL SEQUENTIAL =59 ASSISTING PARALLEL SEQT= 9 STC DSNB410I *DECO CUMULATIVE STATISTICS SINCE 23:47:02 MAY 1, 2007 STC DSNB411I *DECO RANDOM GETPAGE = SYNC READ I/O (R) = 1065 SEQ. GETPAGE = SYNC READ I/O (S) = DMTH HIT = PAGE-INS REQUIRED =

We again start with a clean buffer pool on a V8 DB2 (controlled access) STC DSNB401I *DECO BUFFERPOOL NAME BP25, BUFFERPOOL ID 25, USE COUNT 0 STC DSNB402I *DECO BUFFER POOL SIZE = 500 BUFFERS 435 ALLOCATED = TO BE DELETED = IN-USE/UPDATED = BUFFERS ACTIVE = STC DSNB406I *DECO PGFIX ATTRIBUTE CURRENT = NO PENDING = NO PAGE STEALING METHOD = LRU STC DSNB404I *DECO THRESHOLDS VP SEQUENTIAL = 10 DEFERRED WRITE = 75 VERTICAL DEFERRED WRT = 18, 0 PARALLEL SEQUENTIAL =55 ASSISTING PARALLEL SEQT= 5 STC DSNB408I *DECO NO DETAIL STATISTICS AVAILABLE FOR BUFFER POOL BP25 STC DSN9022I *DECO DSNB1CMD '-DIS BPOOL' NORMAL COMPLETION STC DSNB401I *DECO BUFFERPOOL NAME BP49, BUFFERPOOL ID 49, USE COUNT 0 STC DSNB402I *DECO BUFFER POOL SIZE = 6000 BUFFERS 443 ALLOCATED = TO BE DELETED = IN-USE/UPDATED = BUFFERS ACTIVE = STC DSNB406I *DECO PGFIX ATTRIBUTE CURRENT = NO PENDING = NO PAGE STEALING METHOD = LRU STC DSNB404I *DECO THRESHOLDS VP SEQUENTIAL = 10 DEFERRED WRITE = 10 VERTICAL DEFERRED WRT = 5, 0 PARALLEL SEQUENTIAL =59 ASSISTING PARALLEL SEQT= 9 STC DSNB408I *DECO NO DETAIL STATISTICS AVAILABLE FOR BUFFER POOL BP49 And run the same workload

Since we want to do several coordinated actions for this test we let Pool Advisor do the work. Several minutes into the test it noticed the performance problem and issued commands to reallocate existing storage :20:02 I PMDZSUPB - SYSA - DECO VSC Storage mode changed from NORMAL to BALANCE :20:02 I PMDZSUPB - SYSA - DECO PSR_STATE = 0; AVL_STATE = 0; STG_STATE = 1 :20:02 I PMDZSUPB - SYSA - DECO CUR_VS1 = 109MB; CUR_VS2 = 104MB; MAX_VS = 218MB :20:32 I PMDZCMD1 - LPG2 Cmd: DB2 DECO -ALTER BUFFERPOOL(BP49) VPSIZE(3000) :20:33 I PMDZCMD1 - LPG2 Cmd: DB2 DECO -ALTER BUFFERPOOL(BP25) VPSIZE(2500)

On completion of the run STC DSNB401I *DECO BUFFERPOOL NAME BP25, BUFFERPOOL ID 25, USE COUNT 4 STC DSNB402I *DECO BUFFER POOL SIZE = 2500 BUFFERS 656 ALLOCATED = TO BE DELETED = IN-USE/UPDATED = BUFFERS ACTIVE = STC DSNB406I *DECO PGFIX ATTRIBUTE CURRENT = NO PENDING = NO PAGE STEALING METHOD = LRU STC DSNB404I *DECO THRESHOLDS VP SEQUENTIAL = 10 DEFERRED WRITE = 75 VERTICAL DEFERRED WRT = 18, 0 PARALLEL SEQUENTIAL =55 ASSISTING PARALLEL SEQT= 5 STC DSNB410I *DECO CUMULATIVE STATISTICS SINCE 00:17:28 MAY 2, 2007 STC DSNB411I *DECO RANDOM GETPAGE = SYNC READ I/O (R) = SEQ. GETPAGE = SYNC READ I/O (S) = DMTH HIT = PAGE-INS REQUIRED = ... STC DSNB401I *DECO BUFFERPOOL NAME BP49, BUFFERPOOL ID 49, USE COUNT 3 STC DSNB402I *DECO BUFFER POOL SIZE = 3000 BUFFERS 673 ALLOCATED = TO BE DELETED = IN-USE/UPDATED = BUFFERS ACTIVE = STC DSNB406I *DECO PGFIX ATTRIBUTE CURRENT = NO PENDING = NO PAGE STEALING METHOD = LRU STC DSNB404I *DECO THRESHOLDS VP SEQUENTIAL = 10 DEFERRED WRITE = 10 VERTICAL DEFERRED WRT = 5, 0 PARALLEL SEQUENTIAL =59 ASSISTING PARALLEL SEQT= 9 STC DSNB410I *DECO CUMULATIVE STATISTICS SINCE 00:16:03 MAY 2, 2007 STC DSNB411I *DECO RANDOM GETPAGE = SYNC READ I/O (R) = 2099 SEQ. GETPAGE = SYNC READ I/O (S) = DMTH HIT = PAGE-INS REQUIRED =

The results Without adjustments BP25 RANDOM GETPAGE = SYNC READ I/O (R) = 65200 SEQ. GETPAGE = SYNC READ I/O (S) = 0 BP49 RANDOM GETPAGE = SYNC READ I/O (R) = 1065 With adjustments BP25 RANDOM GETPAGE = SYNC READ I/O (R) = SEQ. GETPAGE = SYNC READ I/O (S) = BP49 RANDOM GETPAGE = SYNC READ I/O (R) = This is also pretty much what we would expect from increasing the buffer pool size and decreasing an under-used pool It also works, without surprises

Beyond Buffer Pools Of course there is more to storage tuning in DB2 than just buffer pools The Dynamic Statement PREPARE cache The DBD pool The skeleton CT and PT pool The CT and PT pool The RID pool The Sort pool Local thread storage and the local statement cache Especially for long running threads Open datasets Compression dictionaries And more…

Beyond Buffer Pools Each of these can use a substantial amount of storage Their performance needs have to be balanced against the total storage available and the needs of the other pools. Some of these fluctuate on their own, but many can be limited by user specifiable controls. Some of these represent potential tradeoffs for storage demands that can be made when a workload fluctuation occurs. But the buffer pools still are usually the biggest storage consumer and the biggest opportunity for making trade-offs.

EDM, RID and Sort Pool Management
Manage the performance of the objects in the EDM pool Improve PREPARE caching performance Monitor RID and Sort pool efficiency Will make recommendations for EDM, RID, and Sort Pool changes EDM Pool Management Pool Advisor for DB2 manages the non-PREPARE-caching EDM performance by: Monitoring pool efficiency. Monitoring pool load failures. Monitoring pool fragmentation and posting warnings and appropriate recommendations. It improves the PREPARE caching performance by: Accumulating statistics by SQL statement and only allowing cache PREPARES which are good candidates. Only cache new statement PREPARES when statistics or priorities indicate it should displace another. RID and Sort Pool Management Pool Advisor for DB2 will post warnings and provide appropriate recommendations when RID access path failures occur due to insufficient storage. Sort failures occur due to insufficient storage. You can make dynamic changes to EDM and RID pools

Static Tuning Static Tuning Still has an important place in your BP tuning strategy Provides a best-fit recommendation without running extensive, timely traces Ability to easily analyze and modify the configuration of the database objects within the buffer pools Enables user to define various configuration scenarios Recommendations to improve BP performance Object (pageset) placement Buffer pool size and threshold modifications Based on cumulative pageset/object access attributes Access type, activity level, update level Object type, priority, size User Options Complexity - number of buffer pools BP Attributes Assignment of objects Look for this feature in the next release, V2.1.

Summary So what’s the bottom line?
Proper tuning can make a big difference in application performance Tuning is based upon workload analysis and configuring to best support it The best tuning in the world can be negated by unexpected workload fluctuations Dynamic tuning (real-time configuration changes in response to workload demands) can reduce or eliminate the performance impacts that would otherwise occur This tuning effort is needed on all the DB2 subsystems you manage

Good performance saves you money
Summary And then there is the human factor How available are you for watching DB2 performance 24x7 ? How many DB2 systems do you need to manage ? A tool makes good sub-system performance Straightforward Manageable Predictable Good performance saves you money

Dynamic Buffer Pool Management for DB2
QUESTIONS?

This slide is designed to be an opening or closing slide
This slide is designed to be an opening or closing slide. This will allow the presenter to have a presentation cued up in slideshow mode without being on the title slide. The audience can take their seats, leave, or have open discussion with this slide up.

Dynamic Buffer Pool Management for DB2
APPENDIX

Page Size Implications
Table 1. Implications of page size Page size Row size limit Column count limit Maximum capacity (DMS tablespace) 4 KB 4,005 500 64 GB 8 KB 8,101 1012 128 GB 16 KB 16,293 256 GB 32 KB 32,677 512 GB Max pages per Tablespace = 16,777,216

DB2 V8 - Buffer Pool Thresholds
Match Thresholds to Object/Buffer Pool processing Note: May change during processing day Variable / Fixed Thresholds Parallel Sequential (VPPSEQT) 50% Prefetch Disabled (90%) Data Manager Critical (95%) The five thresholds in black are adjustable via the “ALTER BUFFERPOOL” command. The default values are in parenthesis. Vertical Deferred Write Threshold is reached when 10% of the buffer pool is allocated to one data set. When reached, DB2 will start scheduling write I/Os to externalize the data pages to DASD. Parallel Sequential Threshold is reached when 50% of the sequential steal threshold has been reached. As an example, if the buffer pool is defined as 1000 pages and a query using I/O parallelism is using 400 page ( 1000*80 = 800 for the parallel sequential threshold default and 800 * .5 = 400 the parallel sequential threshold) the threshold is reached. When reached, DB2 will cease to steal pages for parallel processing for the query. Deferred Write Threshold is reached when 50% of the buffer pool is allocated to unavailable pages whether updated or in use. When reached, DB2 will start scheduling write I/Os to externalize the data pages to DASD. Sequential Steal Threshold is reached when 80% of the buffer pool represents pages for sequential processing. When reached, DB2 will steal a sequential page first before stealing a page from a randomly accessed page. Vertical Deferred Write (VDWQT) 10% Deferred Write (DWQT) 50% Sequential Steal (VPSEQT) 80% Immediate Write (97.5%)

DB2 V8 - Buffer Pool Thresholds - Variable
The following five thresholds can be changed using the ALTER BUFFERPOOL command. DWQT – DEFERRED WRITE THRESHOLD The deferred write threshold is expressed as a percentage of the virtual buffer pool that might be occupied by unavailable pages. When this threshold is reached, DB2 will start to schedule write I/Os to externalize data to disk. The default value is 50 and this threshold can be any integer from 0 to 90. VDWQT – VERTICAL DEFERRED WRITE THRESHOLD The vertical deferred write threshold is reached when this percentage of the buffer pool is allocated to updated pages for one data set. In other words, this threshold is basically similar to DWQT, but for individual data sets. When the threshold is reached, DB2 will start scheduling write I/Os to externalize that data set's page to DASD. The default value is 10 and the threshold can be any integer from 0 to 90. If the value is 0, then DB2 allows the optional specification of a second integer that is expressed as an absolute number of buffer pages. When this number of buffer pages represents updated pages in the pool, then DB2 begins writing these pages to DASD asynchronously. This value is only used when the first integer is set to 0. VPSEQT – SEQUENTIAL STEAL THRESHOLD The sequential steal threshold is reached when this percentage of the buffer pool consists of pages for sequential processing. When reached, DB2 will steal a sequential page before stealing a page from a random GETPAGE request. If this threshold is set to 0, then prefetch is disabled and sequentially accessed pages are not kept after being released by the accessing agent. If this threshold is set to 100, then DB2 does not prefer reusing sequential buffers to random buffers. The default value for this threshold is 80. VPPSEQT– PARALLEL SEQUENTIAL THRESHOLD The parallel sequential threshold is reached when this percentage of the sequential steal threshold has been reached. It is important to remember that VPPSEQT is set as a percentage of VPSEQT, not as a percentage of the entire buffer pool. For example, if the buffer pool is defined as 1000 pages, the parallel sequential threshold will be reached if a query using I/O parallelism uses 400 pages (1000*.8 = 800 for the parallel sequential threshold default and 800*.5 = 400, the parallel sequential threshold). When it is reached, DB2 stops stealing pages for parallel processing for the query. When set to 0, parallel sequential operations are disabled. The default value for this threshold is 50. VPXPSEQT – ASSISTING PARALLEL SEQUENTIAL THRESHOLD The assisting parallel sequential threshold is basically the VPPSEQT for operations from another DB2 subsystem in the data sharing group. It determines the number of buffers that can be used by another DB2 in a data-sharing group for parallel sequential operations. This threshold is only valid in a data-sharing group; otherwise, this threshold is ignored. When this threshold is set to 0, this DB2 buffer pool will not be used to assist other subsystems in the data- sharing group with parallel read operations. Otherwise, this threshold is specified as an integer from 0 to 100 and represents the percentage of the parallel sequential threshold that will be used to halt any parallel sequential read operations from other DB2 subsystems in a data-sharing group. The default value is 0. Pool Advisor for DB2 provides a summary display of: Virtual storage used Data spaces Hyper spaces System paging impacts Realistic buffer pool tuning cannot be done in a vacuum. To get maximum use out of available resources you have to know how much storage is available. This includes virtual storage limits, real storage demands (MVS paging), and where and how much virtual storage is being used elsewhere in DB2. Pool Advisor includes all these other functions in order to make realistic and comprehensive recommendations, and because the user needs all that data integrated together in one place in order to make reasonable decisions. Pool Advisor enables the customer to manage the total virtual storage environment, make intelligent trade-offs between, for example, EDM caching and buffer pool demands, and avoid wasting resources while also protecting the DB2 subsystem against inadvertent failures due to storage shortages.

DB2 V8 - Buffer Pool Thresholds - Fixed
The following 3 thresholds are fixed. If any of these thresholds are reached, there are only two methods to alleviate the problem: Increase the size of the buffer pool Reallocate the objects in the buffer pool to different buffer pools. Prefetch Disabled threshold reached when 90% of the buffer pool pages are unavailable. When this threshold is reached, DB2 no longer initiates prefetch operations and will cancel prefetch operations in progress. Data Manager Critical threshold reached when 95% of the buffer pool pages are unavailable. When this threshold is reached, DB2 accesses the pages in the virtual buffer pool once for each row that is retrieved or updated in that page. In other words, retrieving or updating several rows in one page causes several page-access operations. Immediate Write threshold reached when 97.5% of the buffer pool pages are unavailable. When this threshold is reached, DB2 writes updated pages as soon as the update is complete. The write is performed synchronously as opposed to asynchronously. This method potentially causes a large increase in the number of write I/Os performed by DB2. This situation should be avoided completely. Pool Advisor for DB2 provides a summary display of: Virtual storage used Data spaces Hyper spaces System paging impacts Realistic buffer pool tuning cannot be done in a vacuum. To get maximum use out of available resources you have to know how much storage is available. This includes virtual storage limits, real storage demands (MVS paging), and where and how much virtual storage is being used elsewhere in DB2. Pool Advisor includes all these other functions in order to make realistic and comprehensive recommendations, and because the user needs all that data integrated together in one place in order to make reasonable decisions. Pool Advisor enables the customer to manage the total virtual storage environment, make intelligent trade-offs between, for example, EDM caching and buffer pool demands, and avoid wasting resources while also protecting the DB2 subsystem against inadvertent failures due to storage shortages.

DB2 Interesting Facts Most tables in an SMS table space 65 534
Most tables in a DMS table space 51 000 Most table spaces in a database 4096 Most columns in a table (varies by page size) Most columns in a view 5 000 Maximum length of a row including all overhead bytes (varies by page size) Longest varchar bytes Longest long field (CLOB, BLOB) 2 GB Maximum size of a table per partition GB (varies by page size) Maximum size of an index per partition Most rows in a table per partition 4,000,000,000 Longest index key including all overhead 1024 bytes Most columns in an index key 16 Most indexes on a table or storage Most tables referenced in an SQL statement/view storage Most host variable references in an SQL statement 32 767 Longest SQL statement (in bytes) 65 535 Most elements in a select list 1012 Maximum number of constraints on a table Most values in an INSERT statement Most columns in a UNIQUE constraint (supported with a UNIQUE index) Maximum combined length of columns in a UNIQUE constraint (supported with a UNIQUE index) Maximum combined length of referencing 1024 Maximum number of columns in a 500 partitioning key Maximum concurrent users of server 64 000 Maximum run-time depth of cascading triggers Maximum size of a regular DMS table space 512 GB Maximum size of a long DMS table space 2 TB Maximum size of a temporary DMS table space Maximum number of concurrent users per instance Maximum partition number 999 Most table objects in DMS table space Largest database (excluding long fields) 4096*65,535*0.5 TB Largest EEE database (excluding long fields) 4096*65,535*0.5 TB * 999 nodes

Buffer Pool Tuning for DB2

Similar presentations

Presentation on theme: "Buffer Pool Tuning for DB2"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Buffer Pool Tuning for DB2

Similar presentations

Presentation on theme: "Buffer Pool Tuning for DB2"— Presentation transcript:

Similar presentations

About project

Feedback