IBM GLOBAL SERVICES IBM   DB2 Information Management Technical Conference Sept. 20-24, 2004 Las Vegas, NV ©  IBM Corporati...
Introduction <ul><li>Discuss best practices for  </li></ul><ul><ul><li>Building your databases </li></ul></ul><ul><ul><li>...
Building Databases <ul><li>Ensure enough physical disks  </li></ul><ul><ul><li>Too few disks in the #1 cause of poor perfo...
Building Databases <ul><li>If using SMS on AIX, use 3 or more containers per table space to prevent i-node contention </li...
Building Databases <ul><li>For SAN/NAS </li></ul><ul><ul><li>Do not count on a large disk cache for performance </li></ul>...
Partitioned Databases <ul><li>Rules of thumb for RAW data volumes </li></ul><ul><ul><li>For Regatta class CPUs 50 - 200 GB...
Configuring DB2 <ul><li>Use 64 bit if you can </li></ul><ul><ul><li>Allows more addressability </li></ul></ul><ul><ul><ul>...
Configuring DB2 <ul><li>Disable intra-partition parallelism using INTRA_PARALLEL </li></ul><ul><ul><li>Leaving this enable...
Configuring DB2 <ul><li>Set DIAGLEVEL and NOTIFYLEVEL to 3 </li></ul><ul><li>For large result sets set RQRIOBLK as big as ...
Configuring your databases <ul><li>Other than size, a single large buffer pool requires no tuning and gives very good perf...
Configuring your databases <ul><li>Set NUM_IOCLEANERS based on # of CPUs </li></ul><ul><li>Set NUM_IOSERVERS based on # of...
Configuring your databases <ul><li>Type II indexes can improve concurrency </li></ul><ul><ul><li>For databases migrated fr...
Configuring your OLTP databases <ul><li>For dynamic workloads define a large package cache </li></ul><ul><li>For dynamic w...
Configuring your OLTP databases <ul><li>Set MINCOMMIT to 1? </li></ul><ul><ul><li>Maybe set to # trans per second / 10 (or...
Configuring your DSS databases <ul><li>Use query optimization of 5 or higher  </li></ul><ul><ul><li>Required for some opti...
Configuring your ODS <ul><li>Use QP to ensure query response times </li></ul><ul><li>Run report is UR isolation level </li...
Monitoring <ul><li>Make sure you take DB2 and OS snapshots at the same time </li></ul><ul><li>Only take the snapshot(s) yo...
Things to Look for in Snapshots <ul><li>High number of sort overflows indicate larger SORTHEAP may help performance </li><...
Tuning <ul><li>Use AUTOCONFIGURE to get an initial configuration </li></ul><ul><li>When tuning, change one parameter at a ...
Troubleshooting <ul><li>When there is a performance problem, use vmstat to see if the bottleneck is CPU, I/O or memory </l...
Troubleshooting <ul><li>Statement snapshot (or QP) can help identify poorly performing queries </li></ul><ul><ul><li>Look ...
Summary <ul><li>Hopefully these tips can save you time and/headaches </li></ul><ul><li>Make sure you examine the tips and ...
Upcoming SlideShare
Loading in...5
×

IBM GLOBAL SERVICES IBM DB2 Information Management

584

Published on

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

  • Be the first to like this

No Downloads
Views
Total Views
584
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 2
  • IBM GLOBAL SERVICES IBM DB2 Information Management

    1. 1. IBM GLOBAL SERVICES IBM DB2 Information Management Technical Conference Sept. 20-24, 2004 Las Vegas, NV © IBM Corporation 2004 D17 Dwaine R Snow DB2 UDB Best Practices
    2. 2. Introduction <ul><li>Discuss best practices for </li></ul><ul><ul><li>Building your databases </li></ul></ul><ul><ul><li>Configuring DB2 and your databases </li></ul></ul><ul><ul><li>Monitoring </li></ul></ul><ul><ul><li>Tuning </li></ul></ul><ul><li>Based on experience with customers </li></ul>
    3. 3. Building Databases <ul><li>Ensure enough physical disks </li></ul><ul><ul><li>Too few disks in the #1 cause of poor performance </li></ul></ul><ul><ul><li>General ROT, minimum 6-10 disks per CPU </li></ul></ul><ul><ul><ul><li>More is good </li></ul></ul></ul><ul><ul><li>Do not isolate table spaces to disks unless you have plenty of disks </li></ul></ul><ul><ul><ul><li>Normally better to spread table spaces across all available disks </li></ul></ul></ul><ul><li>Do not create more than one TEMP table space per page size </li></ul><ul><li>SMS is normally the best choice for TEMP </li></ul>
    4. 4. Building Databases <ul><li>If using SMS on AIX, use 3 or more containers per table space to prevent i-node contention </li></ul><ul><li>Logging </li></ul><ul><ul><li>Ensure logs are placed on separate disks </li></ul></ul><ul><ul><li>Use mirror logging </li></ul></ul><ul><ul><ul><li>Removes logging as a single point of failure </li></ul></ul></ul><ul><ul><li>When using mirror logging, ensure the logs are on different disks, arrays, disk adapters </li></ul></ul>
    5. 5. Building Databases <ul><li>For SAN/NAS </li></ul><ul><ul><li>Do not count on a large disk cache for performance </li></ul></ul><ul><ul><li>Buffer pool normally absorbs the hits </li></ul></ul><ul><ul><li>Size for performance, NOT capacity </li></ul></ul>
    6. 6. Partitioned Databases <ul><li>Rules of thumb for RAW data volumes </li></ul><ul><ul><li>For Regatta class CPUs 50 - 200 GB per CPU </li></ul></ul><ul><ul><li>For Intel/AMD, HP, SUN 25 - 150 GB per CPU </li></ul></ul><ul><li>Rules of thumb for CPU to Partition Ratio </li></ul><ul><ul><li>For Regatta 1 or 2 CPUs per partition both work well </li></ul></ul><ul><ul><li>For Intel/AMD, HP, SUN 2 CPUs per partition typically work best </li></ul></ul>
    7. 7. Configuring DB2 <ul><li>Use 64 bit if you can </li></ul><ul><ul><li>Allows more addressability </li></ul></ul><ul><ul><ul><li>Bigger buffer pools </li></ul></ul></ul><ul><ul><ul><li>Bigger sorts </li></ul></ul></ul><ul><ul><li>Less limitations for dynamic tuning </li></ul></ul>
    8. 8. Configuring DB2 <ul><li>Disable intra-partition parallelism using INTRA_PARALLEL </li></ul><ul><ul><li>Leaving this enabled and setting MAX_DEGREE to 1 is worst possible configuration </li></ul></ul><ul><li>Connection Concentrator should be used for workloads with: </li></ul><ul><ul><li>Many connections </li></ul></ul><ul><ul><li>Issuing very quick SQL statements </li></ul></ul><ul><ul><li>Do not use connection concentrator for large / long running queries </li></ul></ul><ul><li>Set the CPUSPEED to –1 so DB2 can calculate the appropriate value </li></ul>
    9. 9. Configuring DB2 <ul><li>Set DIAGLEVEL and NOTIFYLEVEL to 3 </li></ul><ul><li>For large result sets set RQRIOBLK as big as possible (64K) </li></ul><ul><ul><li>Default OK for single row results </li></ul></ul><ul><li>Set SHEAPTHRES based on the average # of concurrently executing apps times the SORTHEAP </li></ul><ul><ul><li>But not less than 10X SORTHEAP </li></ul></ul><ul><li>Make sure there are few people in the SYSADM group </li></ul><ul><ul><li>Too many can lead to problems </li></ul></ul>
    10. 10. Configuring your databases <ul><li>Other than size, a single large buffer pool requires no tuning and gives very good performance </li></ul><ul><li>Multiple buffer pools </li></ul><ul><ul><li>Can give better performance if sized correctly </li></ul></ul><ul><ul><li>Require constant monitoring </li></ul></ul><ul><li>Configure enough primary logs to handle workload </li></ul><ul><ul><li>Creating secondary logs is expensive </li></ul></ul><ul><li>Setting LOGPRIMARY to -1 enables infinite logging </li></ul><ul><ul><li>Do you really need/want this? </li></ul></ul><ul><ul><li>If using this, set MAX_LOG to limit recovery timeframe </li></ul></ul>
    11. 11. Configuring your databases <ul><li>Set NUM_IOCLEANERS based on # of CPUs </li></ul><ul><li>Set NUM_IOSERVERS based on # of physical disk the database is using </li></ul><ul><li>Set DFT_EXTENT_SZ based on underlying disks </li></ul><ul><ul><li>Be aware of striping, SAN disk configuration </li></ul></ul><ul><li>Set DFT_PREFETCH_SZ based on underlying disks </li></ul><ul><li>Set BLK_LOG_DSK_FUL so that DB2 waits if the log disk becomes full </li></ul>
    12. 12. Configuring your databases <ul><li>Type II indexes can improve concurrency </li></ul><ul><ul><li>For databases migrated from V7, use reorg to convert the indexes </li></ul></ul><ul><li>If you encounter an “Out of DBHEAP’ error </li></ul><ul><ul><li>Double DBHEAP and continue </li></ul></ul><ul><ul><li>Since DB2 only allocates what is needed, no need to spend a lot of time calculating exact value </li></ul></ul>
    13. 13. Configuring your OLTP databases <ul><li>For dynamic workloads define a large package cache </li></ul><ul><li>For dynamic workloads use query optimization 2 or 3 </li></ul><ul><li>Set the log buffer to at least 256 pages </li></ul><ul><li>Larger log file size improves performance </li></ul><ul><ul><li>But can impact recovery </li></ul></ul><ul><li>Set MAXLOCKS to 20-30% </li></ul><ul><ul><li>UNIX default is too low </li></ul></ul><ul><ul><li>Also increase LOCKLIST from default </li></ul></ul>
    14. 14. Configuring your OLTP databases <ul><li>Set MINCOMMIT to 1? </li></ul><ul><ul><li>Maybe set to # trans per second / 10 (or # trans / 100) </li></ul></ul><ul><li>Set AVG_APPLS low, typically 1 is good </li></ul><ul><ul><li>Not based on the # of connections </li></ul></ul><ul><li>Reduce CHNGPGS_THRES to 20-30 % </li></ul><ul><ul><li>Default can cause system slowdowns </li></ul></ul><ul><li>Set SOFTMAX to an integer multiple of 100% </li></ul><ul><li>Do not set SORTHEAP too large as it makes sorts more “attractive” to the optimizer </li></ul><ul><li>Use smaller page sizes </li></ul>
    15. 15. Configuring your DSS databases <ul><li>Use query optimization of 5 or higher </li></ul><ul><ul><li>Required for some optimizations, i.e. hash joins </li></ul></ul><ul><li>Ensure AVG_APPLS is set based on real workload </li></ul><ul><ul><li>Monitor the system and determine the average # of concurrently executing applications </li></ul></ul><ul><ul><li>Not based on # of connections </li></ul></ul><ul><li>Large SORTHEAP can help to reduce overflowed sorts </li></ul><ul><li>Since normally read only, increase DLCHKTIME </li></ul><ul><li>Use larger page sizes </li></ul>
    16. 16. Configuring your ODS <ul><li>Use QP to ensure query response times </li></ul><ul><li>Run report is UR isolation level </li></ul><ul><li>Use MQTs to improve report performance, separate access from updates </li></ul>
    17. 17. Monitoring <ul><li>Make sure you take DB2 and OS snapshots at the same time </li></ul><ul><li>Only take the snapshot(s) you are interested in </li></ul><ul><ul><li>Snapshot for all can add overhead </li></ul></ul><ul><li>SQL functions for snapshots allow you to easily insert the data into table(s) for analysis using SQL </li></ul><ul><ul><li>Can analyze data for trends </li></ul></ul><ul><ul><li>Predict and plan for growth </li></ul></ul>
    18. 18. Things to Look for in Snapshots <ul><li>High number of sort overflows indicate larger SORTHEAP may help performance </li></ul><ul><li>Examine ratio of rows read to rows selected </li></ul><ul><ul><li>High ratio indicates likely table scans </li></ul></ul><ul><li>Rows written/inserted for a query only workload indicates sorts </li></ul><ul><li>Application snapshots are for the length of the connection, not individual statements </li></ul><ul><ul><li>To examine statements look at statement snapshot </li></ul></ul>
    19. 19. Tuning <ul><li>Use AUTOCONFIGURE to get an initial configuration </li></ul><ul><li>When tuning, change one parameter at a time, and re-test </li></ul><ul><li>Make sure your statistics are current </li></ul><ul><li>If you add an index, make sure you run RUNSTATS </li></ul><ul><li>Before retesting a poorly performing stmt </li></ul><ul><ul><li>Flush the package cache </li></ul></ul><ul><ul><ul><li>Otherwise the old plan will be reused </li></ul></ul></ul><ul><li>When you create an index, the key order does matter </li></ul><ul><ul><li>Put column with highest cardinality as the first key </li></ul></ul>
    20. 20. Troubleshooting <ul><li>When there is a performance problem, use vmstat to see if the bottleneck is CPU, I/O or memory </li></ul><ul><li>High I/O wait typically indicates overflowed sorts or table scans </li></ul><ul><ul><li>Use iostat to isolate the disk, then correlate to the database object </li></ul></ul><ul><li>High CPU usage may indicate sorting or lock waits are occurring </li></ul><ul><ul><li>Examine database snapshots to determine which one is occurring </li></ul></ul><ul><li>Memory issues usually indicated by paging </li></ul>
    21. 21. Troubleshooting <ul><li>Statement snapshot (or QP) can help identify poorly performing queries </li></ul><ul><ul><li>Look for queries with high execution times </li></ul></ul><ul><ul><ul><li>Especially if their cost is low </li></ul></ul></ul><ul><ul><li>Look for queries with a number of sorts </li></ul></ul><ul><ul><ul><li>More important for queries that are run many times </li></ul></ul></ul>
    22. 22. Summary <ul><li>Hopefully these tips can save you time and/headaches </li></ul><ul><li>Make sure you examine the tips and think about how they relate to your environment </li></ul><ul><li>When making config changes, make one change at a time and re-test </li></ul>
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×