Your SlideShare is downloading. ×
0
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
To REORG or not to REORG That is the Question
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

To REORG or not to REORG That is the Question

1,480

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,480
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
77
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. To REORG or not to REORG That is the Question Kevin Baker BMC Software
  • 2. Objectives › Identify I/O performance trends for DB2 pagesets › Correlate reorganization benefits to I/O performance trends › Understand the methods for collecting I/O performance data › Identify object and application metrics that help identify objects in need of reorganization › Establish a process for identifying application pagesets for analysis 2
  • 3. Why Pageset Organization matters - the basics › Its all about your data and the I/O required to access it. › DB2 computes the best access path for an SQL statement to minimize I/O wait time. › The access path chosen is primarily influenced by catalog statistics about the referenced tables and indexes. › DB2’s primary mechanism for avoiding I/O wait time is asynchronous I/O via PREFETCH. › PREFETCH is most effective in situations involving sequential processing, even if in small bursts, and is significantly affected by the physical ordering of the pages on disk. 3
  • 4. About Access Paths - Prefetch › Given viable indexes, the DB2 Optimizer will try to use PREFETCH to read in the data pages asynchronously. › If it can determine that sequential processing is reasonable when the access path is determined, it will call for SEQUENTIAL PREFETCH. › If it identifies the need for a lot of specific records that are not sequentially located it may call for RID-based LIST PREFETCH. › Even if the access path calls for random access (which involves synchronous I/O), runtime monitoring may invoke DYNAMIC PREFETCH if the pages requested appear to be even loosely sequential. 4
  • 5. About Access Paths - BIND › For STATIC SQL, the access path is determined at the time the program containing the SQL goes through the BIND process. › This means that the table and index statistics in the catalog at the time of the BIND determine the access path, and it remains fixed until the next time a BIND is done. › For DYNAMIC SQL, the access path is set by the PREPARE process every time the statement is executed (more or less). › This means that the access path can change from run to run if the relevant catalog statistics are updated. 5
  • 6. About Access Paths - Statistics › There are several dozen statistics, kept in various catalog tables, that are used by the DB2 optimizer to select access paths. › Many of these influence the choice of indexes, order of joins, etc. › For the purpose of this discussion, we are interested in just a few that indicate organization level of the table or index. › We will cover some of the statistics traditionally used to recommend REORGS later in the presentation. 6
  • 7. About Access Paths - Statistics › Tables (TABLESPACES/PARTITIONS) – CARD (Cardinality) – the number of rows in the tablespace or partition – FARINDREF – the number of rows relocated far from their original page › Indexes (INDEXSPACES) – CLUSTERRATIO – the percentage of rows in clustering order – LEAFFAR – the percentage of leaf pages physically located far from the previous leaf page accessed in an index scan. 7
  • 8. Impact on SQL Performance › To explore the impact on SQL performance we set up some special tables, indexes, and SQL workloads. › To minimize variables: – We used test DB2 subsystems with stable configurations throughout the testing. – We isolated measured pagesets to their own buffer pools that were large, and cleared prior to each run. – We avoided workloads that would cause dis-organization to an extent that would drastically affect access path. › Factors explored were inserts, updates that relocate rows, and free space. 8
  • 9. Case 1: Dynamic Sequential after Updates › DB2 version 8 › 100k row table, no freespace, clustering index › DYNAMIC SELECT workload; returns 10k rows – access path using index and sequential prefetch › UPDATE workload that updates 5k random rows in such a way that the rows have to be relocated. › RUNSTATS for the table and index done after each update workload and key statistics captured. › Access performance statistics for the SELECT workloads were gathered for both the table and index. 9
  • 10. Case 1: Dynamic Sequential after Updates Thread Statistics Thread Statistics (tablespace) Runstats Statistics (indexspace) GP/ GP SIO Pref Pref CARD FARIN- CLUST LEAF GP/ GP SIO Pref Pref SIO req pgs DREF ratio FAR SIO req pgs Initial Run 350 699 2 23 733 100000 0 100 0 25 125 5 5 155 Run1 10 879 84 28 812 100000 1696 100 2286 2 242 112 12 338 Run2 7 1037 144 32 867 100000 3231 100 2372 2 242 112 12 370 Run3 5 1176 222 38 924 100000 4688 100 2380 2 244 114 12 368 Run4 5 1320 283 41 955 100000 6142 100 2380 2 244 114 12 368 Run5 4 1456 332 44 1030 100000 7524 100 2380 2 244 114 12 368 Run6 4 1604 407 46 1063 100000 8887 100 2380 2 244 114 12 368 Run7 4 1757 469 49 1106 100000 10265 100 2380 2 244 114 12 368 Run8 4 1920 533 54 1196 100000 11629 100 2380 2 244 114 12 368 Run9 3 2058 602 60 1203 100000 12989 100 2380 2 244 114 12 368 Run10 3 2202 661 65 1266 100000 14335 100 2380 2 244 114 12 368 REORG FINAL RUN 414 828 2 27 861 100000 0 100 0 28 142 5 6 187 10
  • 11. Case 2: Dynamic Random after Updates › DB2 version 8 › 100k row table, no freespace › DYNAMIC SELECT workload; returns 10k rows – access path completely random › UPDATE workload that updates 5k random rows in such a way that the rows have to be relocated. › RUNSTATS for the table and index done after each update workload. 11
  • 12. Case 2: Dynamic Random after Updates Thread Statistics (tablespace) Runstats Statistics Thread Statistics (indexspace) GP/ GP SIO Pref Pref CARD FARIN- CLUST LEAF GP/ GP SIO Pref Pref SIO req pgs DREF ratio FAR SIO req pgs Initial Run 1 1003 966 0 0 100000 0 100 0 4 3027 714 0 0 Run1 1 1030 990 0 0 100000 1696 100 2286 3 3048 886 0 0 Run2 1 1081 1037 0 0 100000 3231 100 2372 3 3045 878 0 0 Run3 1 1109 1068 0 0 100000 4688 100 2380 3 3055 912 0 0 Run4 1 1130 1078 0 0 100000 6142 100 2380 3 3052 894 0 0 Run5 1 1157 1105 0 0 100000 7524 100 2380 3 3060 908 0 0 Run6 1 1178 1128 0 0 100000 8887 100 2380 3 3054 911 0 0 Run7 1 1231 1182 0 0 100000 10265 100 2380 3 3052 887 0 0 Run8 1 1250 1193 0 0 100000 11629 100 2380 3 3052 888 0 0 Run9 1 1279 1227 0 0 100000 12989 100 2380 3 3051 900 0 0 Run10 1 1296 1229 0 0 100000 14335 100 2380 3 3046 886 0 0 REORG FINAL RUN 1 1003 981 0 0 100000 0 100 0 4 3023 747 0 0 12
  • 13. Case 3: Dynamic Sequential after Inserts › DB2 version 8 › 100k row table, no freespace, clustering index › DYNAMIC SELECT workload; returns 10k rows – access path using index and sequential prefetch › Insert workload that inserts 100 random rows each run. › RUNSTATS for the table and index done after each insert workload. 13
  • 14. Case 3: Dynamic Sequential after Inserts Thread Statistics Thread Statistics (tablespace) Runstats Statistics (indexspace) GP/ GP SIO Pref Pref CARD FARIN- CLUST LEAF GP/ GP SIO Pref Pref SIO req pgs DREF ratio FAR SIO req pgs Initial Run 349 698 2 23 733 100000 0 100 0 25 125 5 5 155 Run1 283 848 3 30 733 100100 0 99 142 3 195 75 7 196 Run2 114 1024 9 35 731 100200 0 99 196 2 219 100 8 202 Run3 86 1201 14 34 731 100300 0 99 234 2 235 112 8 189 Run4 68 1363 20 53 731 100400 0 99 238 2 235 113 7 187 Run5 62 1544 25 54 731 100500 0 99 238 2 232 113 7 187 Run6 55 1706 31 58 731 100600 0 99 238 2 230 112 7 187 Run7 51 1875 37 61 731 100700 0 99 238 2 228 111 6 186 Run8 47 2028 43 62 699 100800 0 99 238 2 225 109 6 186 Run9 46 2177 47 81 730 100900 0 99 238 2 223 108 6 186 Run10 46 2324 51 85 726 101000 0 99 238 2 221 107 6 186 REORG FINAL RUN 341 681 2 23 733 101000 0 100 0 24 121 5 5 155 14
  • 15. Case 4: Dynamic Random after Inserts › DB2 version 8 › 100k row table, no freespace › DYNAMIC SELECT workload; returns 10k rows – access path completely random › Insert workload that inserts 100 random rows each run. › RUNSTATS for the table and index done after each Insert workload. 15
  • 16. Case 4: Dynamic Random after Inserts Thread Statistics Thread Statistics (tablespace) Runstats Statistics (indexspace) GP/ GP SIO Pref Pref CARD FARIN- CLUST LEAF GP/ GP SIO Pref Pref SIO req pgs DREF ratio FAR SIO req pgs Initial Run 2 1003 546 0 0 100000 0 100 0 25 3022 123 0 0 Run1 2 1011 549 0 0 100100 0 99 142 16 3042 194 0 0 Run2 2 1024 548 0 0 100200 0 99 196 14 3045 221 0 0 Run3 2 1018 541 0 0 100300 0 99 234 13 3047 234 0 0 Run4 2 1049 561 0 0 100400 0 99 238 13 3046 242 0 0 Run5 2 1042 561 0 0 100500 0 99 238 13 3049 241 0 0 Run6 2 1064 559 0 0 100600 0 99 238 13 3055 236 0 0 Run7 2 1073 570 0 0 100700 0 99 238 13 3057 239 0 0 Run8 2 1080 569 0 0 100800 0 99 238 13 3066 241 0 0 Run9 2 1078 573 0 0 100900 0 99 238 13 3060 240 0 0 Run10 2 1113 591 0 0 101000 0 99 238 13 3033 240 0 0 REORG FINAL RUN 2 1013 587 0 0 101000 0 100 0 23 3020 132 0 0 16
  • 17. Case 5: Dynamic Sequential after Updates without RUNSTATS › DB2 version 8 › 100k row table, no freespace, clustering index › DYNAMIC SELECT workload; returns 10k rows – access path using index and sequential prefetch › UPDATE workload that updates 5k random rows in such a way that the rows have to be relocated. › No RUNSTATS between runs so the catalog statistics are not being updated. 17
  • 18. Case 5: Dynamic Sequential after Updates without RUNSTATS Thread Statistics (tablespace) Runstats Statistics Thread Statistics (indexspace) GP/ GP SIO Pref Pref CARD FARIN- CLUST LEAF GP/ GP SIO Pref Pref SIO req pgs DREF ratio FAR SIO req pgs Initial Run 349 698 2 23 733 100000 0 100 0 25 125 5 5 155 Run1 10 879 84 28 812 100000 0 100 0 2 242 112 12 338 Run2 7 1037 144 32 867 100000 0 100 0 2 242 112 12 370 Run3 5 1176 222 38 924 100000 0 100 0 2 244 114 12 368 Run4 5 1320 283 41 955 100000 0 100 0 2 244 114 12 368 Run5 4 1456 332 44 1030 100000 0 100 0 2 244 144 12 368 Run6 4 1604 407 46 1063 100000 0 100 0 2 244 114 12 368 Run7 4 1757 469 49 1106 100000 0 100 0 2 244 114 12 368 Run8 4 1920 533 54 1196 100000 0 100 0 2 244 114 12 368 Run9 3 2058 602 60 1203 100000 0 100 0 2 244 114 12 368 Run10 3 2202 661 65 1266 100000 0 100 0 2 244 114 12 368 REORG FINAL RUN 414 828 2 27 861 100000 0 100 0 28 142 5 6 187 18
  • 19. Case 6: Static Sequential after Updates without Rebind or RUNSTATS › DB2 version 8 › 100k row table, no freespace, clustering index › STATIC SELECT workload; returns 10k rows – access path using index and sequential prefetch › UPDATE workload that updates 5k random rows in such a way that the rows have to be relocated. › No RUNSTATS and no REBIND between runs › Final runs after REORG, and then after RUNSTATS and REBIND 19
  • 20. Case 6: Static Sequential after Updates without Rebind or RUNSTATS Thread Statistics Thread Statistics (tablespace) Runstats Statistics (indexspace) GP/ GP SIO Pref Pref CARD FARIN- CLUST LEAF GP/ GP SIO Pref Pref SIO req pgs DREF ratio FAR SIO req pgs Initial Run 140 698 5 23 704 100000 0 100 0 16 125 8 5 160 Run1 8 879 107 23 736 100000 0 100 0 1 242 240 0 0 Run2 5 1037 204 23 736 100000 0 100 0 1 242 240 0 0 Run3 4 1176 286 23 736 100000 0 100 0 1 244 242 0 0 Run4 4 1320 370 23 736 100000 0 100 0 1 244 242 0 0 Run5 3 1456 450 23 736 100000 0 100 0 1 244 242 0 0 Run6 3 1604 537 23 736 100000 0 100 0 1 244 242 0 0 Run7 3 1757 625 23 736 100000 0 100 0 1 244 242 0 0 Run8 3 1920 724 23 736 100000 0 100 0 1 244 242 0 0 Run9 3 2058 812 23 736 100000 0 100 0 1 244 242 0 0 Run10 2 2202 904 23 736 100000 0 100 0 1 244 242 0 0 Final run after REORG 166 828 5 27 832 100000 0 100 0 18 142 8 6 160 After REORG, STATS, REBIND 414 828 2 27 861 100000 0 100 0 28 142 5 6 187 20
  • 21. Case 7: Dynamic Sequential after Updates, no RUNSTATS, with FREESPACE › DB2 version 8 › 100k row table, – table PCTFREE = 10; index PCTFREE = 5 › Clustering index › Dynamic SELECT workload; returns 10k rows – access path using index and sequential prefetch › UPDATE workload that updates 5k random rows in such a way that the rows have to be relocated. › No RUNSTATS between runs 21
  • 22. Case 7: Dynamic Sequential after Updates, with FREESPACE Thread Statistics Thread Statistics (tablespace) Runstats Statistics (indexspace) GP/ GP SIO Pref Pref CARD FARIN- CLUST LEAF GP/ GP SIO Pref Pref SIO req pgs DREF ratio FAR SIO req pgs Initial Run 389 778 2 26 829 100000 0 100 0 27 133 5 6 187 Run1 390 780 2 26 829 100000 1696 100 2286 17 136 8 6 187 Run2 395 790 2 27 829 100000 3231 100 2372 6 156 28 6 187 Run3 407 814 2 27 829 100000 4688 100 2380 3 182 54 6 187 Run4 431 862 2 28 829 100000 6142 100 2380 3 306 78 7 214 Run5 309 928 3 35 829 100000 7524 100 2380 2 233 100 9 276 Run6 49 1028 21 38 829 100000 8887 100 2380 2 253 120 9 276 Run7 13 1190 89 46 902 100000 10265 100 2380 2 259 126 10 276 Run8 9 1338 149 50 952 100000 11629 100 2380 2 259 126 10 276 Run9 7 1471 209 52 967 100000 12989 100 2380 2 259 126 10 284 Run10 6 1616 275 57 1027 100000 14335 100 2380 2 259 126 10 284 REORG FINAL RUN 463 926 2 30 957 100000 0 100 0 30 149 5 6 187 22
  • 23. Chart of Case1: Sequential after Updates without Freespace 23
  • 24. Chart of Case7: Sequential after Updates with Freespace 24
  • 25. Conclusions about SQL Performance and Pageset Organization › Relocating update activity reduces organization, significantly affects sequential performance , – can cause some increases in workload due to increased row sizes, › Insert activity reduces organization, significantly affects sequential performance, – can also increase workload (rows fetched) › Random table access will not be significantly affected by reduced organization or improved by REORGs – Index access can be degraded although this is usually a lesser impact › Freespace delays worst performance impacts, – at cost of unused disk space 25
  • 26. Conclusions about SQL Performance and Pageset Organization › Typical performance impacts include – Increased getpage activity • Can also be caused by increased workloads – Increased sync I/Os, increased sync I/Os per getpage • Can be masked by buffer pool tuning › Updated statistics can help optimizer compensate – Dynamic SQL, Static SQL if rebound – Can also cause unexpected access path changes; could make things much worse – RUNSTATS causes statement invalidation in the Dynamic statement cache. 26
  • 27. Case 8: DB2 9 - Dynamic Sequential after Updates, no FREESPACE › DB2 version 9 › 100k row table, no freespace, clustering index › DYNAMIC SELECT workload; returns 10k rows – access path using index and sequential prefetch › UPDATE workload that updates 5k random rows in such a way that the rows have to be relocated. › RUNSTATS for the table and index done after each update workload. 27
  • 28. Case 8: DB2 9 - Dynamic Sequential after Updates, no FREESPACE Thread Statistics Thread Statistics (tablespace) Runstats Statistics (indexspace) GP/ GP SIO Pref Pref CARD FARIN- CLUST LEAF GP/ GP SIO Pref Pref SIO req pgs DREF ratio FAR SIO req pgs Initial Run 140 698 5 23 736 100000 0 100 0 24 195 8 7 224 Run1 8 876 113 23 736 100000 1707 100 1562 3 267 81 7 224 Run2 5 1029 210 23 736 100000 3223 100 2508 1 316 282 1 32 Run3 4 1165 297 23 736 100000 4637 100 3062 1 348 346 0 0 Run4 3 1302 389 23 736 100000 6057 100 3382 1 368 366 0 0 Run5 3 1436 479 23 736 100000 7417 100 3552 1 377 375 0 0 Run6 3 1579 569 23 736 100000 8749 100 3658 1 382 380 0 0 Run7 3 1726 658 23 736 100000 10103 100 3720 1 383 381 0 0 Run8 3 1887 754 23 736 100000 11452 100 3742 1 384 382 0 0 Run9 2 2018 841 23 736 100000 12782 100 3754 1 384 382 0 0 Run10 2 2158 932 23 736 100000 14111 100 3768 1 384 382 0 0 REORG FINAL RUN 166 828 5 27 864 100000 0 100 0 24 195 8 7 224 28
  • 29. Case 9: DB2 9 - Dynamic Random after Updates, no FREESPACE › DB2 version 9 › 100k row table, no freespace › DYNAMIC SELECT workload; returns 10k rows – access path completely random › UPDATE workload that updates 5k random rows in such a way that the rows have to be relocated. › RUNSTATS for the table and index done after each update workload. 29
  • 30. Case 9: DB2 9 - Dynamic Random after Updates, no FREESPACE Thread Statistics (tablespace) Runstats Statistics Thread Statistics (indexspace) GP/ GP SIO Pref Pref CARD FARIN- CLUST LEAF GP/ GP SIO Pref Pref SIO req pgs DREF ratio FAR SIO req pgs Initial Run 1 1003 973 0 0 100000 0 100 0 4 3020 820 0 0 Run1 1 1040 1004 0 0 100000 1707 100 1562 3 3030 881 0 0 Run2 1 1067 1028 0 0 100000 3223 100 2508 3 3028 932 0 0 Run3 1 1080 1047 0 0 100000 4637 100 3062 3 3042 945 0 0 Run4 1 1121 1082 0 0 100000 6057 100 3382 3 3040 939 0 0 Run5 1 1131 1093 0 0 100000 7417 100 3552 3 3042 949 0 0 Run6 1 1186 1139 0 0 100000 8749 100 3658 3 3037 938 0 0 Run7 1 1214 1157 0 0 100000 10103 100 3720 3 3038 955 0 0 Run8 1 1261 1198 0 0 100000 11452 100 3742 3 3032 955 0 0 Run9 1 1272 1210 0 0 100000 12782 100 3754 3 3039 951 0 0 Run10 1 1281 1228 0 0 100000 14111 100 3768 3 3054 968 0 0 REORG FINAL RUN 1 1003 978 0 0 100000 0 100 0 4 3026 824 0 0 30
  • 31. DB2 9 and Real-Time Statistics (RTS) › DB2 version 9 has added the ability to dynamically maintain pageset statistics in separate catalog tables. – SYSIBM.SYSTABLESPACESTATS – SYSIBM.SYSINDEXSPACESTATS › These values are maintained without RUNSTATS › The Optimizer does not use them for access path analysis › Many of the statistics are relative to the last REORG › With an understanding of when they get updated, they are basically always available. › These are available in v8 too. (even v7!) You just have to do some work to set them up. 31
  • 32. Some RTS Statistics › The RTS tables have the basic statistics we have been looking at: – SYSIBM.SYSTABLESPACESTATS – REORGLASTTIME – timestamp of last REORG – REORGNEARINDREF – number rows relocated since REORG but near the original page – REORGFARINDREF - number rows relocated since REORG far from the original page – SYSIBM.SYSINDEXSPACESTATS – NLEVELS - number of index levels – REORGLEAFNEAR – number of leaf pages relocated but near its previous logical leaf page – REORGLEAFFAR – number of leaf pages relocated far from its previous logical leaf page 32
  • 33. Methods for deciding when to REORG › Typical methods include – Automatically on fixed schedule – When certain catalog statistics breach a threshold • Change in cardinality and degraded cluster ratio • Degraded page ordering (FARINDREF) • Degraded leaf page distribution, ordering, levels › We can save resources used for REORGs if we – Correlate those statistics with performance data – Only REORG if and when needed 33
  • 34. Collecting Performance Data › DB2 IFCID 199 contains key statistics for each pageset with at least 1 I/O per second average in a stat cycle: – DBID, PSID, partition – Getpage counts – Sync I/Os – Async I/Os – Async pages read › If activated, these records are produced on the regular DB2 statistics cycle. 34
  • 35. Collecting Performance Data › A custom program, SAS procedure, or vendor tool can be used to – collect these records periodically (e.g. daily), – summarize the numbers by pageset, – add them to a performance statistics table, › This performance statistics table can have columns for date-time, DBID, PSID, Partition, getpages, sync I/Os, async I/Os, async pages read. › It’s also necessary to know when REORGS are done – add a column to indicate a REORG event 35
  • 36. Real-Time Statistics › With the availability of the RTS tables, – it is now possible to capture key organization statistics, – on a daily basis, – easily correlate with performance statistics. – Could capture them at the same time the performance statistics are summarized for the day. – Could keep them in the same table. – Solves the problem of capturing last REORG time. › Now possible to do percentage change calculations on catalog statistics as well as performance statistics. 36
  • 37. Collecting Performance Data - sample table layout › CREATE TABLE PAGESET_PERFORMANCE_TABLE › (COLLECT_TIME TIMESTAMP, › DBID SMALLINT, › PSID SMALLINT, › PART SMALLINT, › BPID SMALLINT, › DBNAME CHAR(8), › PSNAME CHAR(8), › TYPE CHAR(1), › REORGLASTTIME TIMESTAMP, › TABLE_FARINDREF INTEGER, › TABLE_NEARRINDREF INTEGER, › TABLE_REORGUNCLUSTINS INTEGER, › TABLE_TOTALROWS INTEGER, › INDEX_REORGLEAFFAR INTEGER, › INDEX_REORGLEAFNEAR INTEGER, › INDEX_NLEAF INTEGER, › INDEX_TOTALENTRIES INTEGER, › GETPAGES INTEGER, › SYNC_IO INTEGER, › GPPERSIO INTEGER, › ASYNC_IO INTEGER, › ASYNC_PAGES INTEGER); 37
  • 38. Developing REORG Triggers › Performance data analysis can be used either – to recommend REORGS as needed, or – to study the results of REORGS and use the information to adjust fixed schedules. › Either way, the analysis usually depends on a “trigger”, which is a metric or formula threshold that is used to decide whether a REORG is needed or not. › The threshold part of these triggers often have to be tailored to the needs of each application. › Note that physical state and storage use triggers, such as extents, percentage of dropped table rows, etc. are indicators that represent issues unrelated to performance. 38
  • 39. Developing REORG Triggers › Recommendations from the Administration Guide – Table spaces, REORG if • More than 10% of rows relocated far • If clustering index, then CLUSTERRATIO< 90% – Else number referenced rows far from optimal > 10% – Index spaces, REORG if • More than 10% of active leaf pages are far from optimal position • The average distance between consecutive leaf pages exceeds 2 • More than a designated percentage of rows have been inserted or deleted 39
  • 40. Developing REORG Triggers › Factoring in degraded performance… › Tables paces or index spaces, REORG if – Baseline prefetch pages is > 2 x sync I/Os – And sync I/Os have increased 20% since baseline – And getpages per sync I/O have fallen 20% › Any pageset nominated for REORG by the performance triggers and the catalog statistics triggers is a good candidate for REORG. 40
  • 41. Developing REORG Triggers › Post REORG analysis – If using regularly scheduled REORGS, analysis of the performance data a day after the reorganization can indicate the degree of improvement. › Interesting data points: (getpages, sync I/O, async pages, and getpages per sync I/O) – Before the REORG, % increase in metrics since the last REORG (baseline). – After the latest REORG, % decrease in metrics. – Small values indicate REORG was too soon or not needed at all. – Large values mean the REORG was too late. 41
  • 42. Putting it all Together › Activate Real-Time Statistics in DB2 – (pre v9, do setup work) › Activate DB2 statistics class 8 and begin recording IFCID 199 data › Create the pageset performance table. › Setup daily job to summarize 199 data, collect RTS data, and populate the pageset performance table. › Either use the data to – adjust REORG schedules, – directly trigger REORGS, or – perform post REORG analysis on benefits. 42
  • 43. Conclusion › With a little work it is possible to setup a process to capture pageset performance statistics and real-time object statistics. › With this data better triggers can be developed that only recommend REORGS when performance has been degraded. › Post REORG analysis of this data can help to refine trigger thresholds or adjust schedules to balance performance versus costs. 43
  • 44. BMC Software, Inc. Kevin Baker kevin_baker@bmc.com 44

×