Performance By Design

1,064 views

Published on

Oracle Performance by Design - presnetaiotn given at Oracle Open World 2009

Published in: Technology
  • Be the first to comment

Performance By Design

  1. 1. Performance by Design<br />Guy Harrison<br />Director, R&D Melbourne<br />www.guyharrison.net<br />
  2. 2. Introductions <br />
  3. 3.
  4. 4. Save the red-shirt Toad!<br />The Red-shirt Toad is NOT expendable!<br />
  5. 5. Core message<br />Design limits performance<br />Architecture maps requirements to design<br />Make sure performance requirements are specified<br />Make sure architecture allows for performance<br />Make sure performance requirements are realized<br />
  6. 6. Elements of Performance by Design<br />
  7. 7. Methodology<br />
  8. 8. High performance can mean different things<br />Speed: response time <br />
  9. 9. Efficiency: power consumption<br />
  10. 10. Power: throughput<br />
  11. 11. Not usually easy to change architectures<br />
  12. 12. Poorly defined requirements lead to this:<br />
  13. 13. The twitter lesson <br />
  14. 14. Twitter growth<br />
  15. 15. “Twitter is, fundamentally, a messaging system. Twitter was not architected as a messaging system, however. For expediency&apos;s sake, Twitter was built with technologies and practices that are more appropriate to a content management system.”<br />
  16. 16. Patterns of database performance<br />Hard to distinguish patterns at low levels<br />
  17. 17. Validating performance can’t wait...<br />User adoption and growth<br />UI Layer (HTML, JavaScript, Ajax) <br />Middleware layer (J2EE)<br />SQLs<br />Database (Tables, views, partitions, etc)<br />
  18. 18.
  19. 19. Database Design <br />
  20. 20. Normalize, but not too far!<br />
  21. 21. Other logical design thoughts<br />Artificial keys<br />Generally more efficient than long composite keys<br />Null values<br />Not a good idea if you intend to search for “unknown” or “incomplete” values<br />Null should not mean something<br />But beneficial as long as you don’t need to look for them. <br />Data types<br />Constraints on precision can sometimes reduce row lengths<br />Variable length strings usually better<br />Carefully consider CLOBs vs long VARCHARs<br />
  22. 22. Logical to Physical: Subtypes<br />“Customers are people too”<br />
  23. 23. Indexing, clustering and weird table types<br />Lots’ of options:<br />B*-Tree index<br />Bitmap index<br />Hash cluster<br />Index Cluster<br />Nested table<br />Index Organized Table<br />Most often useful:<br />B*-Tree (concatenated) indexes<br />Bitmap indexes<br />Hash Clusters<br />
  24. 24.
  25. 25. Concatenated index effectiveness<br />SELECT cust_id<br />FROM sh.customers c<br />WHERE cust_first_name = &apos;Connor&apos;<br />AND cust_last_name = &apos;Bishop&apos;<br />AND cust_year_of_birth = 1976;<br />
  26. 26. Concatenated indexing guidleines<br />Create a concatenated index for columns from a table that appear together in the WHERE clause.<br />If columns sometimes appear on their own in a WHERE clause, place them at the start of the index.<br />The more selective a column is, the more useful it will be at the leading end of the index (better single key lookups)<br />But indexes compress better when the leading columns are less selective. (better scans) <br />Index skip scans can make use of an index even if the leading columns are not specified, but it’s a poor second choice to a “normal” index range scan.<br />
  27. 27. Bitmap indexes<br />
  28. 28. Bitmap indexes <br />
  29. 29.
  30. 30. Bitmap join performance <br />SELECT SUM (amount_sold)<br />FROM customers JOIN sales s USING (cust_id) WHERE cust_email=&apos;flint.jeffreys@company2.com&apos;;<br />
  31. 31. Index overhead<br />
  32. 32. Hash Cluster<br />Cluster key determines physical location on disk<br />Single IO lookup by cluster key<br />Misconfiguration leads to overflow or sparse tables <br />
  33. 33. Hash Cluster vs B-tree index <br />
  34. 34. Hash cluster table scan <br />
  35. 35. Denormalization and partitioning<br />Repeating groups – VARRAYS, nested tables<br />Summary tables – Materialized Views, Result cache<br />Horizontal partitioning – Oracle Partition Option <br />In-line aggregations – Dimensions <br />Derived columns – Virtual columns<br />Vertical partitioning <br />Replicated columns - triggers<br />
  36. 36. Summary tables<br />Aggregate queries on big tables often the most expensive<br />Pre-computing them makes a lot of sense<br />Balance accuracy with overhead <br />Aggregate Query<br />MV on COMMIT<br />Manual Summary<br />Result set cache<br />MV stale tolerated <br />Accuracy<br />Efficiency<br />
  37. 37. Vertical partitioning<br />
  38. 38. Physical storage options<br />LOB Storage<br />PCTFREE<br />Compression <br />Block size <br />Partitioning <br />
  39. 39.
  40. 40. Application Architecture and implementation<br />
  41. 41. The best SQL is no SQL <br />Avoid asking for the same data twice. <br />
  42. 42. 11g client side cache <br />CLIENT_RESULT_CACHE_SIZE: this is the amount of memory each client program will dedicate to the cache.<br />Use RESULT_CACHE hint or (11GR2) table property<br />Optionally set the CLIENT_RESULT_CACHE_LAG<br />
  43. 43. Parse overhead<br />It’s easy enough in most programming languages to create a unique SQL for every query:<br />
  44. 44. Bind variables are preferred<br />
  45. 45. Parse overhead reduction <br />
  46. 46. Identifying similar SQLs<br />See force_matching.sql at www.guyharrison.net<br />
  47. 47. Transaction design <br />Optimistic vs. Pessimistic <br />
  48. 48. Using ORA_ROWSCN<br />Setting ROWDEPENDENCIES will reduce false fails<br />
  49. 49. Network – stored procedures <br />
  50. 50. Network traffic example <br />
  51. 51. Array processing - Fetch<br />
  52. 52. Network overhead – Array processing<br />
  53. 53. Array Insert (Java)<br />
  54. 54. Array Insert: (.NET)<br />
  55. 55. Array Insert – PL/SQL<br />
  56. 56. Thank you<br />
  57. 57. Geek quiz stuff:<br />High probability answers (keep standing if):<br />Know what Alice and Wally have in common<br />You know the next number in this series 3 . 1 4 <br />Know what “M” is in E=MC2<br />
  58. 58. Know (or can work out) your age in hex<br />Have an opinion about of ST vs SW <br />If you know who Leonard McCoy is <br />Think there is an important distinction between Nerd and Geek <br />Can quote Monty Python <br />…. Other than dead parrot?<br />You’ve ever watched Jerry Springer<br />
  59. 59. There are more networked devices in your house than people, pets and cars<br />Know the names of two of Thomas the tank engines friends<br />Know the names of any of Angelina and Brad’s babies<br />Low probability answers: (sit down if you):<br />Have a twitter account <br /># Azure is your new favourite color<br />
  60. 60. You’ve ever played Zork<br />You have a favourite Dr Who companion <br />Your favourite is Sarah Jane <br />Know your age in binary (or can work it out in your head) <br />You are proficient in some form of assembler<br />
  61. 61. # You are proficient in some for or English <br />There is a rubicks cube in your house <br />Have your own domain<br />Have ever been to Azeroth<br />Who is <br />Know who said “Dude I am not your nemesis”<br />
  62. 62. Worn a star trek or star wars costume<br />Played a game that uses a non-six sided dice<br />Get email on my phone – before getting out of bed<br />Calculator watch<br />Binary time piece <br />Was on the internet prior to the WWW<br />
  63. 63. # Met my current partner on line<br />Know the next thing in this sequence: Hydrogen, Helium, Lithuim, Berilium, ….<br />Know what a Gigaquads in a megaquad is<br />
  64. 64. Saw a sci-fi movie more than twice at the movies<br />=========================================================<br />You cleaned up at home before going to work<br />

×