1. 1 Chapter 9 Tuning Table Access

2. 2 Overview Improve performance of access to single table Explain access methods – Full Table Scan – Index – Partition-level – Cluster-based Evaluation of optimizer choices Tuning objects to aid optimizer choices

3. 3 Single Value Lookups Looking up rows based on column matching SELECT * FROM customers_sv WHERE cust_year_of_birth = :year_of_birth; Choice between full table scan and index usage Full table scans – Appropriate when selection criteria references larger portion of table – Can take advantage of parallelism Index usage – As selectivity increases, index usage more appropriate – Requires reading index blocks as well as data blocks

4. 4 Full-table scan vs. Index lookup It’s not an easy answer Dependent on – SQL statements – Hardware – Data distribution – Row size – Hit rate in the buffer cache Use Full-table scan (FTS) – Accessing > 2%, well maybe 5%, well maybe 25% of data – Accessing more than x amount of the data blocks – If faster than index lookup Bottom-line: Mileage will vary!

5. 5 FTS vs. Index lookup (cont.) Optimizer choices depend on: – Number of blocks to read from table data – Number of blocks to read from index lookup (WHERE clause) – Cost of multiblock reads – Assumptions of what is in memory Most significant factor: – How many rows will be returned from query

6. 6 Helping the Optimizer Choose OPTIMIZER_MODE appropriately – FIRST_ROWS (if response time is more important) Index may be used rather than FTS – ALL_ROWS – more likely to choose FTS Use index-related parameters as appropriate – OPTIMIZER_INDEX_CACHING – OPTIMIZER_INDEX_COST_ADJ Analyze selectivity carefully for bitmap indexes Configure hash clusters carefully

7. 7 Avoid Unwanted Table Scans SQL Constructs can affect optimizer choice – Using a NOT EQUALS (<>, !=) condition – Searching for NULL values – Accidentally disabling an index with a function Use IN, OR, or > rather than NOT EQUALS Use Hints Use Histograms –

8. 8 Avoid Unwanted Table Scans (cont.) Searching for NULLS (indexes not used) – Index entries not created for NULL values To use an index in these situations, consider: – Changing NULL columns to NOT NULL – Assign default value to the column values – Index lookups are then possible

9. 9 Avoid Unwanted Table Scans (cont.) Disabling an index with a function in SQL – Occurs when placing function on left side of comparison operation SELECT SUM(amount_sold) FROM sales_f WHERE (SYSDATE – time_id) < 10; – Rewrite queries to avoid changing an indexed column SELECT SUM(amount_sold) FROM sales_f WHERE time_id > (sysdate-10); – If function required (e.g. “WHERE UPPER(cust_last_name)”) Consider function-based indexes Consider virtual columns

10. 10 Multicolumn Lookups Can be achieved efficiently by – Use single column index on most selective column – Use concatenated index – Use multiple indexes – Use full table scan

11. 11 Searching for Ranges Unbounded range scan – Getting all rows with a column value Greater than a particular value, or Less than a particular value – Typically will use an FTS – Will use index if ‘variable peeking’ suggests it would be beneficial – Histograms useful on columns with data not uniformly distributed

12. 12 Searching for Ranges (cont.) Bounded range scan – Where we provide aa maximum and a minimum value Greater than a particular value, or Less than a particular value – As with unbounded range scans Will also use index if ‘variable peeking’ suggests it would be beneficial Histograms useful on columns with data not uniformly distributed

13. 13 Searching for Ranges (cont.) Range Lookups – When finding particular value keyed on low/high value pair of columns: SELECT /*+ FIRSTROWS */ * FROM salesregion WHERE ‘50000000015’ BETWEEN lowphoneno and highphoneno; – Generally not efficient search method using SQL statement – Using PL/SQL or other procedural language may be necessary

14. 14 Using the LIKE operator Searching for rows that match a wildcard condition SELECT MAX (cust_credit_limit), count(*) FROM customers_1 WHERE cust_last_name LIKE ‘Vaugh%’; – May use index if wildcard is on trailing end – Will not use index if wildcard is on leading end

15. 15 Multivalue Single-column Lookups Usually seen with OR, IN clauses SELECT MAX (cust_credit_limit), count(*) FROM customers_1 WHERE cust_last_name IN (‘Baker’, ‘Bakerman’, ‘Bakker’, ‘Backer’); Processed two ways – Perform FTS to check each value on every row – Perform multiple index based lookups of the table – Optimizer must decide based on statistics which is better Histograms may help optimizer make better choice

16. 16 Optimizing Full Table Scans Reduce number of logical block reads Reduce number of physical block reads Reducing scan overhead by caching or sampling Use parallelism Performing fast full index scan Using Oracle partitioning Optimize the table – Lower High Water Mark – Modify PCTFREE or PCTUSED parameters – Reduce row length – Compress the table data

17. 17 Making Database IO More Efficient Avoid unnecessary IO by caching data in memory Ensuring that physical IO is efficient – Disk layout optimization – Striping – Look at all aspects of physical disk configuration Oracle configuration methods include – Sizing buffer cache effectively – Use KEEP and RECYCLE buffer pools – Use CACHE hint for appropriate oft-used SQL statements – Use server side or client side result cache

18. 18 Other Options to Tune Table Access Use Parallel Query – If multiple CPU’s and there is spare CPU capacity – Data is spread across multiple disk drives Use the fast full index scan – Blocks read in order they appear on disk – Allows multiple block reads in single IO operation – Can be performed in parallel – Can be requested with PARALLEL_INDEX hint Use Oracle partitioning – Enables use of “partition elimination” – Can be faster than index scans