Top 10 tips for Oracle performance (Updated Nov 2014)

  • 21,466 views
Uploaded on

Presentation given at NZOUG in November 2014 (and in other versions in the past)

Presentation given at NZOUG in November 2014 (and in other versions in the past)

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • great share! where can I get more details?
    Are you sure you want to
    Your message goes here
  • thnx, it is very useful
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
21,466
On Slideshare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
790
Comments
2
Likes
15

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
  • All of it required diagnostic/tuning pack license

Transcript

  • 1. Top 10 Oracle database tuning tips and techniques Guy Harrison, Executive Director, Information Management R&D
  • 2. 2 Dell Software Group Introductions Web: guyharrison.net Email: guy.harrison@software.dell.com Twitter: @guyharrison
  • 3. 3 Dell Software Group
  • 4. 4 Dell Software Group
  • 5. 5 Dell Software Group
  • 6. 6 Dell Software Group
  • 7. 7 Dell Software Group
  • 8. 8 Dell Software Group
  • 9. 9 Dell Software Group
  • 10. 10 Dell Software Group
  • 11. Star trek shirt fatality analysis 0 10 20 30 40 50 60 70 80 Red Yellow Blue 11 Dell Software Group Pct
  • 12. 12 Dell Software Group
  • 13. The top 10 13 Dell Software Group Be methodical and empirical Optimize your database design Index Wisely Write efficient code Optimize the optimizer Tune SQL and PL/SQL Monitor and Manage contention Optimize memory to reduce IO Tune IO last, but TUNE it well
  • 14. Be methodical and empirical
  • 15. Hint 1: Methodical and Empirical tuning Methodical: 15 Dell Software Group • Have a plan • Focus on root causes, not symptoms • Hypothesis and experiment, not trial and error Empirical • Measure performance • Compare before and after • What is your control group? • Beware of “old DBA tales” and “silver bullets”
  • 16. Hint 1: Methodical and Empirical tuning YAPP 16 Dell Software Group • Yet Another Performance Profiling Methodology • Focus on area of greatest time consumption • Use the Oracle Wait Interface System-R • Similar, but focus on business transaction context • Use Oracle SQL trace Tuning by layers • As above, but prioritize higher layers of the stack (which have flow on effects into lower layers) • Distinguish between symptoms and causes
  • 17. Basics of a database request 17 Dell Software Group
  • 18. The 4 layers in database performance 18 Dell Software Group
  • 19. 19 Dell Software Group What’s wrong with the donkey?
  • 20. Measurement 20 Dell Software Group • Standard SQL views • AWR reports • DB control/Cloud control • Toad/Spotlight other 3rd party tools • A single query can tell you a lot http://165.225.144.123/OPSG Samples/Ch03/timeModelSi mple.sql
  • 21. Database design
  • 22. Database design Third Normal form (3NF) 22 Dell Software Group • The key, the whole key and nothing but the key • OR – Don’t repeat yourself (DRY) 3NF discretion • Datatypes (VARCHARs vs LOBS, etc) • Subtypes • NULLS Denormalization • Replicate column values to avoid joins • Summary tables and materialized views • Vertical partitioning
  • 23. 3NF is mostly Don’t Repeat Yourself (DRY) • We don’t want to repeat the student name every time they take a new test • We don’t want to repeat the test_name for every student that takes it • We don’t want the “repeating group” of answers – Also, we might not know how many questions there will be in future tests 23 Dell Software Group
  • 24. 3NF version • Students take tests • Tests have questions • Students taking tests provide answers 24 Dell Software Group
  • 25. Don’t go to far! • In this example the designer pulled address into a separate table and country into another table. • It’s correct in theory, but it means that every time we want an employees address we have to join three tables. • It would have been better to have just one table 25 Dell Software Group
  • 26. Logical to Physical: Subtypes “Customers are people too” 26 Dell Software Group
  • 27. Subtypes • It’s usually better to put all the data in one table, or have two tables for each subtype • Having a “supertype” table and two “subtype” tables means you always have to join tables Probably don’t want to do this 27 Dell Software Group
  • 28. Denormalization 28 Dell Software Group
  • 29. Index Wisely
  • 30. Indexes Indexes exist mainly to improve performance • Choosing the best set of indexes is crucial • Create the best set of Concatenated (multi-column) indexes that will support your queries. • Indexes slow down transactions, so don’t create too many Think of indexes on a table like indexes in a book • You use the index when you want to look up one thing or a few things • You don’t use the index to read the whole book or read a whole chapter • You do use an index when you want to go to a specific page 30 Dell Software Group
  • 31. Concatenated index effectiveness last,first,birthyear,id last,first,BirthYear last+first name last name 3 4 31 Dell Software Group • The more columns in the index the less IO it takes to resolve a query using all the columns • The order of the columns affects how the index can be used • If the index has all the columns, don’t need to touch the table at all SELECT cust_id FROM sh.customers c WHERE cust_first_name = 'Connor' AND cust_last_name = 'Bishop' AND cust_year_of_birth = 1976; 0 500 1000 1500 None 1459 63 6 Logical IO
  • 32. Index overhead 7 6 5 4 3 2 32 Dell Software Group • Indexes speed up queries, but make DML (insert, update, Delete) slower • This chart shows how inserts slow down as more and more indexes are added • Deleting a row with lot’s of indexes is particularly expensive 8,691 6,671 12,727 16,316 0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000 18,000 1 (PK only) 1,191 10,719 14,285 Logical reads required Number of indexes
  • 33. 1000 100 10 1 0 10 20 30 40 50 60 70 80 90 100 33 Dell Software Group Elasped Time (s) Pct of table accessed Full Scan no caching Index sorted data, no caching Index unsorted, cached data Full Table scan, cached data Index or FTS? Break even points
  • 34. Application code
  • 35. Database coding guidelines SQL Execution 35 Dell Software Group • Don’t call the database unless you have to – cache data instead. • Reduce “hard” parsing by using bind variables Transaction design • Minimize lock duration using optimistic and Pessimistic locking strategies Network overhead • Array fetch and Insert • Stored procedures
  • 36. Parse overhead • It’s easy enough in most programming languages to create a new SQL every time you execute the query: 36 Dell Software Group
  • 37. Better to use the same SQL with different arguments: • Prepare the statement once, then execute many times with different arguments • Using bind variables 37 Dell Software Group
  • 38. Reduction in parse (SQL Compile) time 0 200 400 600 800 1000 1200 1400 Bind Variables No Bind variables 1,000 executions of the code on preceding two slides in Oracle 38 Dell Software Group Parse Time Other
  • 39. Designing transactions • There are two ways to design transaction locking • Pessimistic works best if you think someone else is going to “grab” your row before you’re finished • Optimistic works best if you thing no one else will “grab” the row 39 Dell Software Group Duration of lock Duration of lock
  • 40. Reduce Network traffic • “Round trips” to the database can add a lot of overhead • Two ways to reduce round trips: – Use the “Array” interface in your program code – Use stored procedures for complex interactions with the database 40 Dell Software Group
  • 41. Array fetch performance 40,000 35,000 30,000 25,000 20,000 15,000 10,000 5,000 0 0 20 40 60 80 100 120 140 41 Dell Software Group Array fetch size Logical Reads Network round trips
  • 42. Network – stored procedures • A stored procedure is code stored in the database • If you have a transaction that goes “back and forth” to the database, consider a stored procedure • ESPECIALLY if you are working across a slow network 42 Dell Software Group
  • 43. Optimize the optimizer
  • 44. Object Statistics 44 Dell Software Group Cardinality Estimates IO and CPU Estimates DB parameters And config System Statistics Cost estimate Table and index Structure Optimizer inputs • Remember: Garbage In : Garbage Out • The optimizer can only do a good job if statistics are up to date
  • 45. Histograms 20,000 18,000 16,000 14,000 12,000 10,000 8,000 6,000 4,000 2,000 45 Dell Software Group • Indexes are only good for getting small amounts of the table • So it might be a good idea to use an index to get “New Zealand” customers, but not “United States” • A histogram allows the optimizer to understand how the data is distributed and make the best decision • Create histograms to correct bad plans on skewed tables 0 Saudi Arabia South Africa Turkey New Zealand Denmark Argentina Singapore Japan Poland China Australia Brazil Canada Spain France United Kingdom Italy Germany United States of America Number of rows
  • 46. Without a histogram 46 Dell Software Group Number of rows the estimated Real number of rows Optimizer chooses not to use an index
  • 47. With a histogram 47 Dell Software Group Optimizer estimate is correct Optimizer chooses to use an index
  • 48. DBMS_STATS GATHER_INDEX_STATS , GATHER_SCHEMA_STATS, GATHER_TABLE_STATS Basic statistics method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO' Histograms method_opt => 'FOR ALL COLUMNS FOR COLUMNS (col1, col2)' 48 Dell Software Group Multi-column extended statistics method_opt => 'FOR ALL COLUMNS FOR COLUMNS (function(column)))' Expression extended statistics DBMS_STATS.gather_system_stats ( gathering_mode => 'NOWORKLOAD'); Non-workload system statistics DBMS_STATS.gather_system_stats (gathering_mode => 'INTERVAL', interval => 60); Workload system statistics
  • 49. Tune SQL and PL/SQL
  • 50. Find them and tune them Find SQL 50 Dell Software Group • Mine V$SQL • ASH, AWR tables • Database control, grid/cloud control • Toad, Spotlight Tune SQL • SQL Profiles • SQL Baselines • Rewrites • Hints (be careful) • SQL Optimizer
  • 51. V$SQL is your friend 51 Dell Software Group • Also, V$SQL_PLAN, V$SQL_PLAN_STATISTICS • Tkprof, session trace
  • 52. 52 Dell Software Group
  • 53. 53 Dell Software Group Now let’s look at the donkey
  • 54. Monitor and manage contention
  • 55. Contention – the proverbial bottleneck Application Demand for DB services 55 Dell Software Group Contention for limited or serialized resources causes waits and or queuing Apparent demand at lower layers is reduced
  • 56. Types of contention Locks Usually locking problems are due to application locks (remember optimistic locking)? Sometimes internal locks can cause problems. 56 Dell Software Group Latches and Mutex Latches are very light weight locks that protect memory instead of tables Buffer contention When sessions have to wait for a memory “buffer” to become available
  • 57. Database 57 Dell Software Group files Buffers Database Writer User Buffer Waits Write dirty blocks to disk Write to buffers Read from disk Read from buffers Free buffer waits • Database buffers improve performance by caching data in memory • When buffers are modified they are called “dirty” – DBWR writes to disk • When all the blocks are “dirty” then sessions have to wait for the buffers to be written before new data can be read • This might mean that your DBWR can’t write to disk fast enough
  • 58. Latches and mutex contention • Latches are like locks, but instead of protecting table rows, they protect memory (buffers) • If two sessions try to access the same area of memory, then one will wait • Instead of “sleeping” (like a lock) they waiting session will “spin” on the CPU for a very short time • Latch problems may indicate “hot” blocks • They might cause CPU drain (because of spinning) user user user Buffers Database files 58 Confidential Software Group
  • 59. Specific contention scenarios Lock/Latch Possible cause Library cache mutex Hard parsing no bind variables. Try 59 Dell Software Group CURSOR_SHARING=SIMILAR Library cache pin PL/SQL package parsing and invalidations Shared pool latch Hard parsing and possibly excessive SGA resizing Cache buffers chains Hot blocks, very high logical read rates Free Buffer waits DBWR failing to “keep up” with block changes Flashback buf free Insufficient IO bandwidth for flashback area Buffer busy Hot blocks – partitioning might help
  • 60. Optimize memory to reduce IO
  • 61. Memory is primarily used to avoid IO 61 Dell Software Group • Buffer cache avoids IO to table/index tablespaces • PGA avoids IO to temporary tablespace Buffer pools Program Global Area (PGA) Sort area Hash Area Data (USER) tablespace Temporary tablespace Oracle Session
  • 62. Temp tablespace IO can easily overwhelm table/index IO More Memory Less Memory 62 Dell Software Group Time Available Memory Table/Index IO CPU Time Temp Segment IO Memory Sort Single Pass Disk Sort Multi-pass Disk Sort
  • 63. Automatic Memory Management • Introduced in 11g, AMM manages allocations between and within PGA and SGA 63 Dell Software Group
  • 64. AMM can (rarely?) lead to thrashing or starvation • ALWAYS set minimum values for key components of the SGA 64 Dell Software Group
  • 65. Tune IO last, but tune it well
  • 66. IO Tuning • Disk IO is the slowest part of the database system, so it’s critical to performance • FIRST: – Tune SQL and application – Remove contention – Allocate memory • Only when you’ve done that will your IO demand be realistic. Then you can tune your IO 66 Dell Software Group
  • 67. Basics of IO tuning (magnetic disks) • The amount of IO you can support depends on the number of disks you have • Provide enough disks to support the amount of IO you need • even if that means the disks are not filled with data • Magnetics disks can do between 75-150 IO per second (IOPS) – do the math! 0 20 40 60 80 100 120 140 160 180 200 SAS 15,000 rpm SAS 10,000 rpm SATA 10,000 rpm SATA 7,200 rpm 67 Dell Software Group IO/ps
  • 68. Disk Drive latency • Latency is the time taken to perform a single IO • Most disk drives can return an IO in 5-10 ms – Faster if the disk has a memory cache • Disk latency increases with: – Throughput (best at 50-75% of maximum) – Disk fill (best at 50% capacity) • To get best performance disks should be – Sparsely populated – Under only moderate load • RAID 0+1 is the preferred configuration 68 Dell Software Group 100 90 80 70 60 50 40 30 20 10 0 0 100 200 300 400 500 Response Time (ms) IO/second
  • 69. The more that things change.... 69 Dell Software Group
  • 70. Disks are not getting faster 70 Dell Software Group
  • 71. Cheaper by the IO SSD DDR-RAM SSD PCI flash SSD SATA Flash Oracle OpenWorld 4,000 15 25 80 0 1,000 2,000 3,000 4,000 5,000 Magnetic Disk Seek time (us)
  • 72. But not by the GB Oracle OpenWorld 10 2011 2012 2013 2014 2015 2.9 7.4 2.2 5.3 1.7 3.2 1.3 2.3 2.3 1 10 1 0.35 0.28 0.21 0.17 0.13 12 10 8 6 4 2 0 2011 2012 2013 2014 2015 $$/GB 0.35 0.28 0.21 0.17 0.13 2.9 2.2 1.7 1.3 1 0.1 $$/GB HDD MLC SDD SLC SSD
  • 73. Tiered storage management Oracle OpenWorld Main Memory DDR SSD Flash SSD Fast Disk (SAS, RAID 0+1) Slow Disk (SATA, RAID 5) Tape, Flat Files, Hadoop $/IOP $/GB
  • 74. Random reads – FusionIO Table on SSD SAS disk, flash cache 74 Dell Software Group 2,211 583 121 0 500 1000 1500 2000 2500 SAS disk, no flash cache Elapsed time (s) CPU Other DB File IO Flash cache IO
  • 75. Full table scans Table on SSD SAS disk, flash cache 75 Dell Software Group Flash cache doesn’t accelerate Full table scans b/c scans use direct path reads and flash cache only accelerates buffered reads 398 418 72 0 100 200 300 400 500 SAS disk, no flash cache Elasped time (s) CPU Other DB File IO Flash Cache IO
  • 76. Disk Sorts – temp tablespace SSD vs HDD 76 Dell Software Group 4000 3500 3000 2500 2000 1500 1000 500 0 Single Pass Disk Sort Multi-pass Disk Sort 300 250 200 150 100 50 0 Elapsed time (s) Sort Area Size SAS based TTS SSD based TTS
  • 77. Concurrent redo workload (x10) Flash based redo log 77 Dell Software Group 1,637 1,605 331 397 1,681 1,944 0 500 1,000 1,500 2,000 2,500 3,000 3,500 4,000 4,500 SAS based redo log Elapsed time (s) CPU Other Log File IO
  • 78. Thank you.