Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Top 10 Oracle database tuning tips and techniques Guy Harrison The top 10 Be methodical and empirical Optimize your database design Index Wisely Write efficient code the Optimize optimizer Tune SQL and MonitorPL/SQL and Manage contention Optimize memory to IO TUNE it Tune IOreduce last, but well 2 Dell Software Group Be methodical and empirical Dell - Restricted - Confidential Hint 1: Methodical and Empirical tuning Methodical: • Have a plan • Focus on root causes, not symptoms • Hypothesis and experiment, not trial error Empirical • Measure performance • Compare before and after • What is your control group? • Beware of “old DBA tales” and “silver bullets” 4 Dell Software Group Hint 1: Methodical and Empirical tuning Performance Troubleshootin Tuning by 5 Dell Software Group • Identify the element of your workload contributing most to service time • Workload could be SQL or logical • Element is typically CPU time + Oracle time • Find a way to reduce that element • As above, but prioritize higher layers of the (which have flow on effects into lower • Distinguish between symptoms and causes Basics of a database request 6 Dell Software Group The 4 layers in database performance 7 Dell Software Group What’s wrong with the donkey? 8 Dell Software Group Measurement • Standard SQL views • AWR reports • DB control/Cloud control • Toad/Spotlight other 3rd party tools • A single query can tell you a lot http://guyharrison.net/OPS GSamples/Ch03/timeModel Simple.sql 9 Dell Software Group Database design Dell - Restricted - Confidential Database design Third Normal form (3NF) 3NF discretion Denormalizati on 11 Dell Software Group • The key, the whole key and nothing but the key • OR – Don’t repeat yourself (DRY) • Datatypes (VARCHARs vs LOBS, etc) • Subtypes • NULLS • Replicate column values to avoid joins • Summary tables and materialized views • Vertical partitioning 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 12 Dell Software Group 3NF version • Students take tests • Tests have questions • Students taking tests provide answers 13 Dell Software Group Don’t go to far! • In this example the designer pulled address into a separate table and city, 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 14 Dell Software Group Logical to Physical: Subtypes “Customers are people too” 15 Dell Software Group 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 16 Dell Software Group Denormalization 17 Dell Software Group Index Wisely Dell - Restricted - Confidential Indexes Indexes exist mainly to improve performance • Choosing the best set of indexes is crucial • Create the best set of Concatenated (multi-column) support your queries. • Indexes slow down transactions, so don’t create too many Think of indexes on a table like indexes in a • You use the index when you want to look up one thing or a things • You don’t use the index to read the whole book or read a chapter • You do use an index when you want to go to a specific 19 Dell Software Group Concatenated index effectiveness last,first,birthyear,id • The more columns in the index the less IO it takes to resolve a query using all the columns 3 last,first,BirthYear 4 last+first name • The order of the columns affects how the index can be used 6 last name 63 None 1459 0 500 Logical IO 20 Dell Software Group 1000 • If the index has all the columns, don’t need to touch the table at all 1500 SELECT cust_id FROM sh.customers c WHERE cust_first_name = 'Connor' AND cust_last_name = 'Bishop' AND cust_year_of_birth = 1976; Index overhead 7 16,316 Number of indexes 6 14,285 5 • This chart shows how inserts slow down as more and more indexes are added 12,727 4 10,719 3 • Deleting a row with lot’s of indexes is particularly expensive 8,691 2 6,671 1,191 1 (PK only) 0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000 18,000 Logical reads required 21 Dell Software Group • Indexes speed up queries, but make DML (insert, update, Delete) slower Index or FTS? 1000 Elasped Time (s) 100 10 Break even points Full Scan no caching Index sorted data, no caching Index unsorted, cached data Full Table scan, cached data 1 0 10 20 30 40 50 Pct of table accessed 22 Dell Software Group 60 70 80 90 100 Application code Dell - Restricted - Confidential Database coding guidelines SQL Execution Transaction design Network overhead 24 Dell Software Group • Don’t call the database unless you have to – cache data instead. • Reduce “hard” parsing by using bind variables • Minimize lock duration using optimistic and Pessimistic locking strategies • Array fetch and Insert • Stored procedures Parse overhead • It’s easy enough in most programming languages to create a new SQL every time you execute the query: 25 Dell Software Group Better to use the same SQL with different arguments: • Prepare the statement once, then execute many times with different arguments • Using bind variables 26 Dell Software Group Reduction in parse (SQL Compile) time Bind Variables No Bind variables 0 200 400 600 Parse Time 800 Other 1,000 executions of the code on preceding two slides in Oracle 27 Dell Software Group 1000 1200 1400 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 Dell Software Group Duration of lock Duration of lock 28 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 29 Dell Software Group 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 Array fetch size Logical Reads 30 Dell Software Group 100 Network round trips 120 140 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 31 Dell Software Group Optimize the optimizer Dell - Restricted - Confidential Table and index Structure Cardinality Estimates Object Statistics DB parameters And config Optimizer inputs IO and CPU Estimates • Remember: Garbage In : Garbage Out • The optimizer can only do a good job if statistics are up to date 33 Dell Software Group System Statistics Cost estimate Histograms • Indexes are only good for getting small amounts of the table 20,000 18,000 Number of rows 16,000 • So it might be a good idea to use an index to get “New Zealand” customers, but not “United States” 14,000 12,000 10,000 8,000 6,000 4,000 2,000 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 0 34 Dell Software Group • 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 Without a histogram Number of rows the estimated Real number of rows 35 Dell Software Group Optimizer chooses not to use an index With a histogram Optimizer estimate is correct Optimizer chooses to use an index 36 Dell Software Group DBMS_STATS GATHER_INDEX_STATS , GATHER_SCHEMA_STATS, GATHER_TABLE_STATS Basic statistics method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO' Histograms method_opt => Multi-column extended statistics 'FOR ALL COLUMNS FOR COLUMNS (col1, col2)' 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 37 Dell Software Group Tune SQL and PL/SQL Dell - Restricted - Confidential Find them and tune them 39 Find SQL • • • • 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 Dell Software Group V$SQL is your friend • Also, V$SQL_PLAN, V$SQL_PLAN_STATISTICS • Tkprof, session trace 40 Dell Software Group 41 Dell Software Group Now let’s look at the donkey 42 Dell Software Group Monitor and manage contention Dell - Restricted - Confidential Contention – the proverbial bottleneck Application Demand for DB services 44 Dell Software Group Contention for limited or serialized resources causes waits and or queuing Apparent demand at lower layers is reduced Types of contention Locks Latches and Mutex Buffer contention Latches are very light weight locks that protect memory instead of tables When sessions have to wait for a memory “buffer” to become available Usually locking problems are due to application locks (remember optimistic locking)? Sometimes internal locks can cause problems. 45 Dell Software Group Latches and mutex contention • Latches are like locks, but instead of protecting table rows, they protect memory (buffers) user user user • If two sessions try to access the same area of memory, then one will wait Buffers • 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) 46 Dell Software Group Database files Free buffer waits Write to buffers User Buffers Buffer Waits Read from • When buffers are modified they are called “dirty” – DBWR writes to disk buffers Read from disk Database Writer Write dirty blocks to disk Database files 47 Dell Software Group • Database buffers improve performance by caching data in memory • 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 Specific contention scenarios Lock/Latch Possible cause Library cache mutex Hard parsing no bind variables. Try 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 48 Dell Software Group Optimize memory to reduce IO Dell - Restricted - Confidential Memory is primarily used to avoid IO • Buffer cache avoids IO to table/index tablespaces Oracle Session 50 Buffer pools Program Global Area (PGA) Sort area Hash Area Data (USER) tablespace Temporary tablespace Dell Software Group • PGA avoids IO to temporary tablespace Temp tablespace IO can easily overwhelm table/index IO Time Multi-pass Disk Sort Single Pass Disk Sort Memory Sort Available Memory More Memory Table/Index IO 51 Dell Software Group CPU Time Less Memory Temp Segment IO Automatic Memory Management • Introduced in 11g, AMM manages allocations between and within PGA and SGA 52 Dell Software Group AMM can (rarely?) lead to thrashing or starvation • ALWAYS set minimum values for key components of the SGA 53 Dell Software Group Tune IO last, but tune it well Dell - Restricted - Confidential 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 55 Dell Software Group 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! SAS 15,000 rpm SAS 10,000 rpm SATA 10,000 rpm SATA 7,200 rpm 0 20 40 60 80 100 IO/ps 56 Dell Software Group 120 140 160 180 200 Disk Drive latency 100 90 80 Response Time (ms) • Latency is the time taken to perform a single 70 IO • Most disk drives can return an IO in 5-10 ms60 – 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 50 40 30 20 10 0 0 100 200 300 IO/second 57 Dell Software Group 400 500 The more that things change.... 58 Dell Software Group Disks are not getting faster 59 Dell Software Group SSD - Cheaper by the IO SSD DDR-RAM 15 SSD PCI flash 25 SSD SATA Flash 80 Magnetic Disk 4,000 0 60 Dell Software Group 1,000 2,000 3,000 Seek time (us) 4,000 5,000 But not by the GB 12 10 10 10 2.9 2.3 2.2 7.4 8 1.7 $$/GB $$/GB 1.3 6 1 2011 1 5.3 2013 2012 2014 4 3.2 0.35 2.9 0.28 2.2 2.3 1.7 0.21 2 Dell Software Group 1.3 0.17 1 0.35 0.28 0.21 0.17 0.13 0.13 0 0.12011 2012 2013 2014 2015 HDD 61 2015 MLC SDD SLC SSD Tiered storage management Main Memory DDR SSD $/GB Fast Disk (SAS, RAID 0+1) Slow Disk (SATA, RAID 5) Tape, Flat Files, Hadoop 62 Dell Software Group $/IOP Flash SSD Random reads – FusionIO CPU Table on SSD Other 121 DB File IO Flash cache IO SAS disk, flash cache 583 SAS disk, no flash cache 2,211 0 63 Dell Software Group 500 1000 1500 Elapsed time (s) 2000 2500 Full table scans Table on SSD 72 Flash cache doesn’t accelerate Full table scans b/c scans use direct path reads and flash cache only accelerates buffered reads SAS disk, flash cache CPU 398 Other DB File IO Flash Cache IO SAS disk, no flash cache 418 0 64 Dell Software Group 100 200 300 Elasped time (s) 400 500 Disk Sorts – temp tablespace SSD vs HDD 4000 3500 Multi-pass Disk Sort 2500 2000 1500 Single Pass Disk Sort 1000 500 0 300 65 Dell Software Group 250 200 150 Sort Area Size SAS based TTS 100 SSD based TTS 50 0 Elapsed time (s) 3000 Concurrent redo workload (x10) Flash based redo log 1,637 331 1,681 CPU Other Log File IO SAS based redo log 1,605 0 66 Dell Software Group 500 1,000 397 1,500 1,944 2,000 2,500 3,000 Elapsed time (s) 3,500 4,000 4,500 Tune RAC Dell - Restricted - Confidential RAC will scale well, providing that…. a) The time taken to transfer a block across Load is reasonably well balanced the interconnect across the instances in theiscluster much less than the time taken to read The overhead of maintaining cluster from disk consistency does not dominate overall response time 68 Dell Software Group Toad: your companion in the Big Data revolution 69 Dell Software Group Thank you Dell - Restricted - Confidential