DB2 Buffer Pool Tuning - Top Down or Bottom Up? Joel Goldstein Responsive Systems 281 Highway 79 Morganville, NJ 07751

Transcription

1 DB2 Buffer Pool Tuning - Top Down or Bottom Up? Joel Goldstein Responsive Systems 281 Highway 79 Morganville, NJ Abstract: This paper addresses the goals and objectives of buffer pool tuning, and the performance data that should wave a "red flag" indicating performance problems. Available data from standard reporting facilities provides much information about performance, but does not provide the entire picture. The top down tuning approach uses DB2 data sources. The bottom up approach uses other data sources outside DB2 to provide information useful for buffer pool tuning. While most installations still seem to be under configured regarding the amount of memory allocated to buffer pools, others go the other way and throw memory at the pools. The goal/objective of buffer pool tuning is to eliminate I/Os, to reduce both transaction and batch elapsed times, and to optimize the DB2/Memory requirements necessary to obtain good performance. Pool Thresholds Let s not spend time on the critical thresholds that hopefully are known to everyone and address the others that are also very important, and those that sometimes have dual meanings. IWTH has two meanings: the first is very critical; however, many systems show hits of this threshold and it may not be critical at all. If SPTH and DMTH have not been hit, then this is nothing to be concerned about since it is probably due to the immediate write taking place either because of a second checkpoint or because a page was taken off a write queue to be used by another application and then written immediately. DWQT hits should be quite low, while VWQT hits are what you want to see - so in most cases, lowering the VWQT (often to Zero) is the best approach especially when the number of pages/write is in the single digit range. VWQT = 0 sets the write threshold to 32 pages at the object/dataset level. The total system read I/O rate/second should be calculated and tracked, since reducing this rate by as little as 10/second over a 20 hour day will save more than $100K of PU costs per year, as well as improving application performance. Page-ins per second should be summed for all the pools and if this approaches 100/sec indicates a lack of processor storage and excessive MVS paging. alculating a correct system hit ratio for each buffer pool is important for performance analysis, and tracking performance over time; however, the I/O rate per second is usually even more indicative of overall performance. The system hit ratio is calculated as: (Getpages - Pages Read) / Getpages where the pages read is the sum of all pages read by both prefetch functions and synchronous I/O. The Getpage/RIO ratio, often shown as an efficiency ratio by online monitors is not generally meaningful for tracking overall system performance and is only useful for application performance when almost all the access is random. What is a good number for a GP/RIO ratio? 5:1, 10:1, 50:1?? Obviously, the higher the better, but the numbers are not meaningful. When using HiperPools the HP retrieval ratio should be calculated and evaluated. How much benefit are you really getting from the HPs, how many I/Os per/second is the HP saving? Low percentages should be carefully evaluated. While a percentage below 10% certainly does not sound good, it may still provide significant benefit. When the percentage is low, consider the number of pages read from the HP in a synchronous manner. How many is this per second? The average number of pages read per second can still be enough to justify having the HP. Naturally, it is all a mater of perspective for your installation. If the rate is two or three per second, the HP is most likely a waste; however, even value as low as ten per second provide reasonable benefit and avoid the synchronous I/O to DASD, and avoid the application delays associated with physical I/Os. Backing the sort/work pool with a HP often provides no benefit; however, there have been several installations that did obtain significant performance benefits from this approach. So, as usual, it depends... We also want to track several different types of hit ratios when HiperPools are in use. This gives us the ability to measure the efficiency of each pool resource. Even considering that the movement of a page from a HP to a VP is only 35 Mcs, it is still more efficient (faster & less cost) to find the page in the VP. A field that is often mis-understood is urrent Active Buffers. It is important to understand that current active buffers does not mean the number of pages used or containing data. This is the number of buffers that are not available or locked. All buffers in a pool always contain data.

2 The buffer pool size information is available in the Ms indicates DASD performance problems. The statistics record, and an IFID 202 record containing the information in the buffer pool area of the accounting Dynamic Zparm information is produced at every statistics reports allow you to calculate a system hit ratio for ever interval. Incidentally, it is better to produce statistics execution of a plan or transaction. Between the wait records at 15 minute intervals than the default 30 minutes. times, and this information, it can be quite easy to home in This provides a better level of granularity than 30 minutes on problems before they become critical, or easy to without impacting performance, and also puts the data determine the base cause of performance problems. into the same measurement (elapsed) time frame as normal RMF data at most installations. BuffPool Buffer Pool ----> Get Page urr_active 51 Updates Read Hit % 7.89 Lst Pref VPOOL Alloc 9000 Seq Pref Exp/on 0 Dyn Pref HPOOL Alloc 0 PgsRdAsy # Backed Strg 0 SyncRead Exp/on 0 Read Fail 0 Write Fail 0 H/V Exp Fail 0 GetPage Total 1.061M Seq Random SyncRead Seq Random SeqPrefRead Request PagesRead Dis NoBf 0 Dis NoEn 0 WKFAbort 0 LstPrefRead 286 Request 249 PagesRead 3739 DynPrefRead 607 Request 626 PagesRead DWHorThreshold 1 DWVerThreshold 19 Take special note of the Synch Reads Seq field. First, there will almost always be some counts in here because prefetch always issues 1 synch I/O when it starts to run. However, large counts here, especially when coupled with low or negative hit ratios indicate a serious performance problem. Pages read into the pool for prefetch can be released (or thrown out) by other prefetch activity before an application can get to them for processing. When this happens, they are read back in using synchronous I/Os...and increment this counter. This has a serious performance impact on the elapsed time for the requesting, and most other, applications. This is most likely to happen in three (but not only) situations: when the processor is too busy (> 95%), when the application MVS dispatching priority is too low, or when the processor is not very busy and several large scan jobs execute concurrently. Application delays for I/O should be calculated from the Accounting Trace 101 records. What percentage of the application class 2 time is I/O wait? What is the average Synch I/O time? Below 18 Ms is good, 20 Ms is OK, > 20 Write HplWrite Fail Hpl Read Fail PgsRd Buffer Pool tuning usually produces substantial application performance improvements, even when the pools are not large. Pool size alone usually provides some improvement; however, the largest pay back comes from a combination of object placement and pool sizing. Pool & Object Analysis Now let s step beyond basic tracking of hit ratios and I/O rates, and determine what data is necessary to properly distribute the objects across multiple pools, and how we approach pool sizing. Just throwing memory at the environment may eventually provide the desired application response times. However, this usually wastes large amounts of memory, and memory is NOT an inexpensive resource... even though the cost is a mere fraction of what it was a few years ago. A meaningful period is the time period you consider important such as your Am or PM peak. A meaningful

3 elapsed time is a period long enough to be representative of your transaction or business functional mix. A few minutes is not usually long enough to provide a good representation of what truly happens in your system and buffer pools. This must also be for the entire system. Access data for a specific plan or user is interesting, but does not provide any insights about how it relates to the rest of the system and pool activity. ollecting performance trace data, we get the IFID 198, and 6-7. Since we are primarily concerned with READ performance, as it effects application response time, we need these three IFIDs. If we are also concerned with write activity, we also want the 8, 9, and 10 records. These are useful because they can show other I/O contentions, and the number of pages/write - that is necessary information for the proper setting of the VWQT. [Ref Statistics example 1] Based on the 198 records we obtain these statistics, that show an 82.0 % overall pool ratio hit ratio. However, this is the application hit ratio because it doesn t consider the number of pages read by prefetch functions. While the application hit ratio is a measure of application I/O delay, the system hit ratio is usually more important, because we are tuning a Global Resource - a system buffer pool. However, overall, the primary indicator is the I/O rate per second. Note the difference between the application hit ratio and the system hit ration on the report example report. When we utilize the 6 & 7 read records, we obtain the true system hit ratio. While the application hit ratio is important because it indicates application performance, this is across all application plans and can hide application performance problems caused by synchronous (or asynchronous) I/O wait times. These statistics can easily be produced by writing some code...using SAS, PL/1, Assembler, or even in REXX. When the average number of pages/write falls into the single digit range, the VWQT should normally be lowered to keep a trickle write going and avoid huge burst of write activity at checkpoint time, or when the DWQT is triggered for pools with hundreds of objects. [Ref Statistics Example 2] After the overall pool statistics, we want the same type of information for each object within a pool. The objects should be sorted in order of decreasing Getpage activity, because we want to see the most heavily accessed objects first. The Buffer Pool displays can produce similar information, but can t order it. Therefore, the most heavily accessed objects might be at the bottom of thousands of lines, or might be truncated off the report. Likewise, it will not work to try groups of display commands. At the detail level, they are incremental since the last display...and you need all information from the same time span and duration for the results to be meaningful. Online monitors can collect the data, but cannot save and process enough of it for the type of meaningful statistical analysis and other processing we have in mind. Snapshot collections of a few minutes are not generally useful unless the transaction workload and mix is very consistent...over a short period. Longer periods provide much better consistency and accuracy. Typically, we need several million getpage records (198s) for a system. What do we look for in the statistical analysis: Indexes with a high % of sequential access, or Sequentially Accessed Mostly (SAMO). The indexes and tablespaces that are Randomly Accessed Mostly (RAMO). Additionally, we break these into small and large working sets. This then gives classifications of RAMOS, RAMOL, SAMOS, SAMOL. The end result of the analysis is to group similarly accessed objects together. The RAMOL/RAMOS and SAMOL/SAMOS objects. Additionally, we must know specifically how they are accessed, and the average and maximum number of pages (working set) they had resident in a pool at any point during the collection period. Pool tuning, sizing, and object placement is not a guessing game. It takes a substantial effort to get everything done properly, and once done, it must be monitored frequently and adjustments made. New applications come into the system, SQL is re-coded and access paths change, databases grow, etc. Monitoring should be done at least on a monthly basis, and bi-weekly is better on highly active systems. Pool tuning, sizing, and effective object placement provides significant performance improvements...for the applications, for the DB2 system, for the DASD subsystem, and for the entire MVS complex. If DB2 was really easy, and static, you would not be sitting here today because the corporations wouldn t need any of us. Performance Prediction Now we get to the difficult part...attempting to simulate, or predict pool and object performance as sizes are changed and objects are moved around. [Ref. Simulation Example 1] Simulations are extremely difficult to write, and require a lot of formula tweaking to get correct results. However, it s the only way to ever get things done correctly (optimally) since you can t play dangerous and time consuming games with your production environment. Here we see simulation results indicating increasing pool hit ratios as the size is increased. Even more importantly, we can see the reduction/saving in the I/O rate. This has

4 the greatest impact on both application response times, Hit ratios for BP % BP % and can provide substantial PU/dollar cost savings. BP2 90%+ From these figures, 58,000 buffers is probably optimal System Read I/O per/second 165+ unless you have memory to spare and wish to pick up that IS Transactions Avg.53 Secs of 2 Elapsed extra 2 I/O per second. The average I/O Wait per Transaction.39 The simulation combines both simulation techniques and statistical analysis to provide useful information at the object level. The results from a simulation run must be analyzed in conjunction with a Statistical analysis that shows rates and type access for each object. A sequentially scanned object monopolizes a pool, and does not provide any significant improvement as the pool Effective pool placement using only 7000 more buffers reduced the I/O rate by more than 70/Sec., and reduced the lass 2 elapsed time by more than 1/4 second (actually.28 secs.). size is increased. Unless all the pages can fit into the ASE STUDY 2 pool, the scanning and I/O just keeps wrapping around. The analyst at this installation was using an online monitor Note the reduction of the I/O rate, and increase in hit ratio to look at the buffer pools - and they only show severe or as the pool size is increased. ompare the increases in situation critical events. The pool could actually be the Wkset for a small/medium TS that is mostly random thrashing, and the online monitors won t show any to the preceding TS that was continually scanned. The problems unless the analyst really knows what to look difference between the Avg and Max WkSet for the for...like the System Hit Ratio... or knowing when the I/O previous tablespace, and the Max ranges of more than rate/second is high. 80% of the total pool size. These two objects must be lient statements: separated into different pools. We Don t Have any Performance Problems We are Using Multiple Pools Already (11 Pools) Now let s look at a large object when the access is very Our Pool Performance is Good random. Here again, there is little benefit from increasing Total Memory Used for Pools: pool size because it is just too big and too random. This 126 Megabytes for Virtual Pools is death by synchronous I/O. 250 Megabytes for HiperPools [Ref. Simulation Example 3] Avg. Transaction Elapsed Time.192 Secs. (475K Trans) ASE STUDY 1 People sometimes say that their DB2 system doesn t have After Tuning the Pools any performance problems. Well, I have never seen one that didn t, and I firmly believe that every system has performance problems. Of course the critical factor is the magnitude of the problems, and the effort required to correct them. Sometimes (but rarely) the problems are not significant, while the effort will be very large...therefore they might not be worth fixing. When somebody says they don t have any DB2 performance problems, they often don t know whereto look, how to look for them, or simply haven t taken the time to look. Any installation using only one pool, and thinking they have good and efficient performance, really hasn t gotten the message. Why do you think IBM gave us 60 Pools, and there will be 80 in DB2 V6?? It s also very rare to find a system using only three or four pools with good performance. These are initial performance results from one installation...before tuning...that said they had good performance. Just because nobody complains, does not mean things are running well... Using 7 Buffer Pools 80 Megabytes for Virtual Pools 160 Megabytes for HiperPools Average Transaction Elapsed Time.157 Secs 18% Improvement Saved 46 Megabytes of VP & 90 Megabytes of HP A 136 Megabyte Saving Reduced the I/O Rate to 193/Sec. from 222/Sec. Saved 29 I/O Sec. Three Pools...65,000 Buffers Online Monitor indicates performance is good No critical thresholds are being hit Hit ratios usually in the mid 90% range Reality... Seconds Perhaps there is room for improvement...???

5 ASE STUDY 3 - PeopleSoft omplex application packages are very difficult to tune; however, there are still pay backs to be realized... Often the pool/object analysis process will identify application problems. Sometimes you are lucky and some of them can be corrected without major code changes. Especially when dealing with packaged software, actual code changes might not be possible. However; adding, deleting, or altering existing indexes may prove a valuable approach for obtaining performance improvements. Finding an object that receives heavy scan activity, and implementing an index can provide dramatic improvements. This was recently highlighted by an installation that recovered almost 20% of the entire 982 processor by adding one index to a table. While not a PeopleSoft application or other packaged software, this was another example where no problem was obvious to any user and nobody was screaming for help. Increased number of Pools from 3 to 6 Increased Memory requirements from 32 Meg up to 80 Meg Reduced I/O rate by almost 20/Sec Identified heavily Scanned Objects Added necessary Indexes Dropped un-necessary Indexes Recovered about 18% of the R53 processor PU Allowed the Application Rollout to complete All of the real PU saving from Application changes Buffer Pool Usage Suggestions Most installations should be able to optimize performance with 5 to 8 pools. While some installations might ultimately use a few more pools, too many simply means a lot more administrative work. In most cases might be an upper limit on effective pool and object tuning. Remember that the pools are a system resource. While segregating them on an application basis might be nice for the application, it is unlikely this approach will provide the most efficient usage of pool and memory resources. However, sometimes political expediency is appropriate. Using too many pools often wastes memory, and creates an administrative problem trying to track and analyze performance. Most installations do not have enough memory given to buffer pools to obtain good performance. While throwing memory at the system may be an easy thing to do, proper object placement will provide the best overall performance without wasting resources. Once the objects are properly grouped, the maintenance is easy and minimal. EXAMPLE POOL REOMMENDATIONS (1) BP0 atalog & Directory BP1 Random Indexes (S/M) BP2 Random Indexes (Lg/Huge) BP3 Scanned Tablespaces BP4 Random Tablespaces (S/M) BP5 Random Tablespaces (Lg..) BP7 DSNDB07 EXAMPLE POOL REOMMENDATIONS (2) BP0 atalog, Directory BP1 Random Indexes (S/M) BP2 Scanned Indexes (?) BP3 Random Indexes (Lg) BP4 Scanned Tablespaces (S/M) BP5 Scanned Tablespaces (Lg) BP6 Random Tablespaces (S/M) BP7 DSNDB07 BP8 Random Tablespaces (Lg) BP9 Random Tablespaces (Transient) Bottom UP Tuning While the performance of DASD systems has improved significantly over the decades, it remains a performance roadblock for large transaction based systems. The new software and hardware technologies offer great potential; however, the basics of performance have not changed within the last three decades and won t change within the next one. It is vital to monitor and tune the DASD environment. Dataset placement DOES matter (using an 80/20 approach). Always be careful of the averaging effect of long performance periods, since they will hide a large number of problems. Performance must be tracked at both the device and dataset level - looking at an average for the entire DASD environment will rarely show any problems. The elapsed time to retrieve a required page varies considerably depending on where it is coming from. As a general perspective of performance, consider the following average elapsed times: <.020 Seconds 3390 <.005 Seconds ache, Solid State Device Seconds HiperPool (100+ Times Faster than ache) The elapsed times for the 3390 are quite generous and more closely approximate an upper acceptable limit rather than the optimal expected time of 16 Ms.

6 Most installations still have poor overall DASD performance that impacts the online applications. Some of the primary causes are lack of staff time to properly place objects to reduce contention, and the ever larger capacity devices...so there are fewer physical devices to spread the objects and I/O workload across. While System Managed Storage (SMS) has many proponents from the DASD management side, it is a double edged sword. While it certainly reduces staff time for managing datasets, it has yet to show that it can provide acceptable performance when the entire environment is just given to SMS. Like many areas in our industry, somewhat of an 80/20 rule should be used. The important datasets should not be managed directly by SMS, nor can the placing of physical partitions of objects, nor can the DSNDB07 sort/work objects. Using separate storage classes to direct important objects to specific devices, or a specific group of devices can work quite well. One way to approach the data is to apply the calculated hit percentage to the number of I/Os. This should indicate the approximate number of I/Os that can be saved by tuning the object on the DB2 buffer pool side. The I/O elimination from pool tuning provides a positive cascading effect. Aside from the obvious elapsed time reductions and PU cost saving, the reduced I/O workload both decreases the stress on the DASD subsystem, and probably improves the cache usage and hit ratios for the remaining objects in the entire subsystem. One of the things that tends to mask poor DASD performance is system wide reporting, and very long reporting intervals. When the intervals are shortened to the peak load periods, and evaluated at the device and dataset levels, the problems really begin to stand out. Of course, as indicated earlier, tracking the average I/O wait times for transactions, average times for synchronous I/O, and overall I/O wait times for batch jobs always seem to show problem quite quickly also. The SMF 42-6 records provide a great source of performance information, and can be used to determine which objects will benefit from Buffer Pool Tuning. Those getting a high hit rate in the ache should be tuned at the system Buffer Pool level - I/Os are expensive, both from a PU and application delay perspective. Finding a page in DASD cache provides an I/O response of 4-5 Ms. Finding the same page in a BP is couple of Mcs without the added PU cost of the I/O. [Ref. Figure 1 & Figure 2] Some programming to process this data can make it easy to find problems quickly, such as multiple partitions on the same device, or multiple DSNDB07 sort/work files on the same device. Identifying the heavy hitters, the objects with the greatest opportunity is not too difficult. An important consideration is the evaluation and understanding of the data, and then determining which objects should be tuned in the buffer pools to avoid having to perform an I/O. The 42-6 record provides a field called cache hit %. However, this percentage applies only to data that was considered to be a cache candidate. It may be far more beneficial to calculate your own percentage based on the number of cache hits and the total I/Os. This is sometimes quite a bit lower than the supplied cache hit percentage.

7 Figure 1 Figure 2

8 Summary After physical design and SQL tuning, buffer pools are the greatest tuning opportunity for your system and applications. Last year at the 1997 International DB2 User Group (IDUG) conference, Intria/IB from Toronto illustrated their projected PU/cost saving at $1.3 Million Dollars over three years from I/O elimination, as well as reducing average transaction elapsed times by 20% for one system and 13% for a second system (presented at IDUG by Patrick Morrison & Richard Gaunt). The most important consideration for Buffer Pool tuning is the ability to predict the effect of changes - to avoid creating new or worse performance problems, or suffer an application outage while objects are stopped/restarted to move them into different pools. Pool tuning is not mysticism or a guessing game, nor is DASD tuning. Tools exist to help you do it the right way and achieve a substantial payback.

9 Statistics Example 1 Statistics for Buffer Pool: BP0 Buffer size is...4k Number of VP Buffers is...10,000 VP sequential threshold is...80% Number of HP Buffers is...0 HP sequential threshold is...80% Hiper Space astout is...y Verticle Write Threshold...10% Horizontal Write Threshold...50% Number of GetP...2,379,499 Number of Sequential Access..1,429, % of GetP Number of Random Access...709, % of GetP Number of RID_List...240, % of GetP Number of Random Misses...277, Misses per Sec Number of Misses (others)...149, Misses per Sec Number of No_Reads % of GetP Number of Hits...1,952, % of GetP (Appl. HIT RATIO) System HIT RATIO % Avg. Page Residency Seconds Number of Pages Read...1,553, Pages per Second Number of Sync Pages Read...393, % of Pages Read Number of SPref Pages Read...999, % of Pages Read Number of LPref Pages Read...14, % of Pages Read Number of DPref Pages Read...144, % of Pages Read Number of Read I/Os...442, I/Os per Second Number of Sync Read I/Os...393, % of Read I/Os Number of SPref Read I/Os...32, % of Read I/Os Number of LPref Read I/Os...11, % of Read I/Os Number of DPref Read I/Os...4, % of Read I/Os Delay of Sync Read I/Os...23 Avg. MSeconds (Max 249) Delay of SPref Read I/Os...36 Avg. MSeconds (Max 250) Delay of Lpref Read I/Os...43 Avg. MSeconds (Max 249) Delay of DPref Read I/Os...44 Avg. MSeconds (Max 243) Number of SetW (Updates)...170,158 Number of Pages Written...73, Pages per Sec Number of Sync Pages Written % of Pages Written Number of ASync Pages Written...73, % of Pages Written Number of Write I/Os...45, I/Os per Sec Number of Sync Write I/Os % of Write I/Os Number of ASync Write I/Os...45, % of Write I/Os Delay of Sync Write I/Os...7 Avg. MSeconds (Max 66) Delay of ASync Write I/Os...4 Avg. MSeconds (Max 231) Average Number Pages/Write...1.6

10 Statistics Example 2 Statistics for Table Space...DB2PO.SOLNSORD Number of GetP...690, % of pool GetP Number of Sequential Access.634, % of GetP Number of Random Access...56, % of GetP Number of RID_List % of GetP <<< Note Number of Random Misses...27, Misses per Sec Number of Misses (others)...19, Misses per Sec Number of No_Reads % of GetP Number of Hits...643, % of GetP (Appl. HIT RATIO) System HIT RATIO % Avg. Page Residency...0 Seconds Number of Pages Read...704, Pages per Second Number of Sync Pages Read...27, % of Pages Read Number of SPref Pages Read...654, % of Pages Read Number of LPref Pages Read % of Pages Read Number of DPref Pages Read...22, % of Pages Read Number of Read I/Os...49, Read I/Os per Sec Number of Sync Read I/Os...27, % of Read I/Os Number of SPref Read I/Os...20, % of Read I/Os Number of LPref Read I/Os % of Read I/Os Number of DPref Read I/Os % of Read I/Os Delay of Sync Read I/Os...21 Avg. MSeconds (Max 239) Delay of SPref Read I/Os...38 Avg. MSeconds (Max 250) Delay of LPref Read I/Os...0 Avg. MSeconds (Max 0) Delay of DPref Read I/Os...43 Avg. MSeconds (Max 183) Number of SetW (Updates)...14, % of pool SetW Number of Pages Written...8, Pages per Sec Number of Sync Pages Written % of Pages Written Number of ASync Pages Written...8, % of Pages Written Number of Write I/Os...4, I/Os per Sec Number of Sync Write I/Os % of Write I/Os Number of ASync Write I/Os...4, % of Write I/Os Delay of Sync Write I/Os...6 Avg. MSeconds (Max 6) Delay of ASync Write I/Os...4 Avg. MSeconds (Max 219) Average Pages/Write (Asynch): 1.67

11 Simulation Example 1 Results of Simulation for Buffer Pool...BP0 Bpool GetP total...2,379,499 Bpool Size GetP used Num. of Hits ApHit Ratio 10,000 2,362,768 1,971, % 18,000 2,349,204 2,049, % 26,000 2,322,343 2,067, % 34,000 2,294,862 2,070, % 42,000 2,267,584 2,064, % 50,000 2,233,613 2,044, % 58,000 2,171,257 1,995, % 66,000 2,160,792 1,991, % Bpool Size Pages Read Read I/O SyHit Ratio 10, /S /S 34.0 % << Baseline Verification 18, /S 95.0 /S 42.6 % 26, /S 83.1 /S 46.7 % 34, /S 75.1 /S 49.9 % 42, /S 69.2 /S 51.6 % 50, /S 66.3 /S 52.5 % 58, /S 64.2 /S 52.6 % 66, /S 62.1 /S 53.6 % Simulation Example 2 Results for Tablespace...DB2PO.HOLDSORD Object GetP total...406,973 ( 17.1% of BP GetP) Bpool Size GetP used Num. of Hits ApHit Ratio Avg. WSet Max. WSet 10, , , % 2,352 6,653 18, , , % 3,512 7,072 26, , , % 4,312 8,501 34, , , % 4,914 8,476 42, , , % 5,341 8,643 50, , , % 5,592 8,712 Bpool Size Pages Read Read I/O SyHit Ratio 10, /S 31.0 /S 25.4 % 18, /S 17.2 /S 55.4 % 26, /S 12.5 /S 66.0 % 34, /S 9.3 /S 74.2 % 42, /S 7.1 /S 78.9 % 50, /S 6.5 /S 81.3 %

12 Simulation Example 3 Results for Index Space...DB2PO.SOLNSOI1 Object GetP total...559,377 ( 17.2% of BP GetP) Bpool Size GetP used Num. of Hits ApHit Ratio Avg. WSet Max. WSet 10, , , % 3,364 6,264 18, , , % 7,249 10,112 26, , , % 9,656 12,314 34, , , % 13,513 15,965 42, , , % 15,223 17,101 50, , , % 16,174 18,096 Bpool Size Pages Read Read I/O SyHit Ratio 10, /S 20.8 /S 58.1 % 18, /S 19.9 /S 58.5 % 26, /S 19.5 /S 59.1 % 34, /S 18.9 /S 59.7 % 42, /S 18.7 /S 60.1 % 50, /S 18.4 /S 60.5 %