Sydney Oracle Meetup - access paths

Presenter: Paul Guerin OCP Meetup presenter 4 times in past 10 months Development/Production DBA at Origin Energy for past 3.5 years Previous employers: Bluescope Steel (Wollongong), BHP Billiton (Wollongong) 2010 Oxfam Trailwalker: Origin Trail Breakers http://www2.oxfam.org.au/trailwalker/Sydney/team/67 Includes photos from Heysen trail and Flinders rangers…. DB performance - Access paths

Access paths overview Access paths are ways in which data is retrieved from the database. The query optimizer chooses an access path based on : The available access paths for the statement. eg WHERE and FROM clauses. All estimated costs of executing the statement, using each access path or combination of paths. The optimizer chooses the execution plan with the lowest estimated cost. Estimated cost is based on estimated blocks accessed, not rows accessed. Optimiser hints can influence the plan chosen. System statistics and system parameters. Statistics for the index, columns, and tables.

Full Table Scans This type of scan reads all rows from a table and filters out those that do not meet the WHERE clause. All blocks under the high water mark are scanned. Note: The high water mark indicates the amount of used space, or space that had been formatted to receive data. The blocks are adjacent and read sequentially. Note: The size of the read calls range from one block to the number of blocks indicated by the initialization parameter DB_FILE_MULTIBLOCK_READ_COUNT (or extent size).

Full Table Scans Simple example: /* EMP_ID is the primary key */ select * from employees; select * from employees where EMP_ID > 15; --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 53M| 3645M| 19314 (22)| |* 1 | TABLE ACCESS FULL | EMPLOYEES | 53M| 3645M| 19314 (22)| --------------------------------------------------------------------------- call cpu elapsed disk query current rows total 208.14 376.56 621870 1146626 0 53059049 <- 5 hrs Another simple example : 6 minute full table scan reduced to 40 seconds!!!

Index Scans Overview A row is retrieved by traversing the index, using the indexed column values specified by the statement. An index scan retrieves data from an index based on the value of one or more columns in the index. If all referenced columns are in the index then the table is not accessed.

Rowid Scans The index contains not only the indexed value, but also the rowids of rows in the table having that value. The rowid of a row specifies the data file and data block containing the row and the location of the row in that block. Locating a row by specifying its rowid is the fastest way to retrieve a single row, because the exact location of the row in the database is specified. When the Optimizer Uses Rowids This is generally the second step after retrieving the rowid from an index. The table access might be required for any columns in the statement not present in the index. Access by rowid does not need to follow every index scan. If the index contains all the columns needed for the statement, then table access by rowid might not occur.

Index Unique Scans This scan returns, at most, a single rowid: If a statement contains a UNIQUE or a PRIMARY KEY constraint that guarantees that only a single row is accessed. Statement requires all columns of a unique (B-tree) index or primary key constraint equality conditions. eg LIKE, IN, = /* EMP_ID is the primary key */ select * from employees where EMP_ID = 100; ------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| ------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 72 | 4 (25)| | 1 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 1 | 72 | 4 (25)| |* 2 | INDEX UNIQUE SCAN | EMP_PK | 1 | | 3 (34)| -------------------------------------------------------------------------------------

Index Range Scans An index range scan is a common operation for accessing selective data. It can be bounded (bounded on both sides) or unbounded (on one or both sides). Data is returned in the ascending order of index columns. If an index can satisfy an ORDER BY clause, then the optimizer uses this option and avoids a sort. /* EMP_ID is the primary key */ select * from employees where EMP_ID < 100; ------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| ------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 72 | 5 (20)| | 1 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 1 | 72 | 5 (20)| |* 2 | INDEX RANGE SCAN | EMP_PK | 1 | | 4 (25)| -------------------------------------------------------------------------------------

Index Range Scans Descending An index range scan descending is identical to an index range scan, except that the data is returned in descending order. The optimizer uses index range scan descending when an an index can satisfy an order by descending clause. /* EMP_ID is the primary key */ select * from employees where EMP_ID < 100 order by EMP_ID desc; -------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| -------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 72 | 5 (20)| | 1 | TABLE ACCESS BY INDEX ROWID | EMPLOYEES | 1 | 72 | 5 (20)| |* 2 | INDEX RANGE SCAN DESCENDING | EMP_PK | 1 | | 4 (25)| --------------------------------------------------------------------------------------

Index Skip Scans Skip scanning lets a composite index be split logically into smaller subindexes. In skip scanning, the initial column of the composite index is not specified in the query. In other words, it is skipped. Note: Can skip more than 1 leading column of the index. The database determines the number of logical subindexes by the number of distinct values in the initial column. Skip scanning is advantageous when there are few distinct values in the leading column of the composite index and many distinct values in the nonleading key of the index.

Index Skip Scans Select * from employees where ID=155222; /* index on (CHANGED,ID) and CHANGED has 3 distinct values */ -------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| -------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 384 | 27648 | 5 (20)| | 1 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 384 | 27648 | 5 (20)| |* 2 | INDEX SKIP SCAN | EMP$CHANGED | 384 | | 4 (25)| -------------------------------------------------------------------------------------------- call cpu elapsed disk query current rows total 2.92 5.38 5353 20747 0 307106 /* index on (ID,CHANGED) */ ----------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| ----------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 384 | 27648 | 18 (6)| | 1 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 384 | 27648 | 18 (6)| |* 2 | INDEX RANGE SCAN | EMP$ID | 384 | | 7 (15)| ----------------------------------------------------------------------------------------------- call cpu elapsed disk query current rows total 0.70 1.59 2024 2025 0 1

Index Skip Scans Select * from employees where ID=155222; /* index on (CHANGED,ID) and CHANGED has 3 distinct values */ -------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| -------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 384 | 27648 | 5 (20)| | 1 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 384 | 27648 | 5 (20)| |* 2 | INDEX SKIP SCAN | EMP$CHANGED | 384 | | 4 (25)| -------------------------------------------------------------------------------------------- call cpu elapsed disk query current rows total 2.92 5.38 5353 20747 0 307106 /* index on (ID,CHANGED) */ -------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| -------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 384 | 27648 | 18 (6)| | 1 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 384 | 27648 | 18 (6)| |* 2 | INDEX RANGE SCAN | EMP$ID | 384 | | 7 (15)| -------------------------------------------------------------------------------------------- call cpu elapsed disk query current rows total 2.85 4.47 5393 11530 0 307106

Full index scans A full index scan eliminates a sort operation. The database uses a full index scan in any of the following situations: An ORDER BY clause that meets the following requirements is present in the query: All of the columns in the ORDER BY clause must be in the index. The order of the columns in the ORDER BY clause must match the order of the leading index columns. The query requires a sort merge join and the query meets the following requirements: All of the columns referenced in the query must be in the index. The order of the columns referenced in the query must match the order of the leading index columns. A GROUP BY clause is present in the query, and the columns in the GROUP BY clause are present in the index. The columns do not need to be in the same order in the index and the GROUP BY clause.

Full index scans Select id,count(CHANGED) from employees group by ID; /* index on (id,changed) */ ----------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| ----------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 137K| 4850K| 347K (1)| | 1 | SORT GROUP BY NOSORT| | 137K| 4850K| 347K (1)| | 2 | INDEX FULL SCAN | EMP$ID1 | 53M| 1820M| 347K (1)| ----------------------------------------------------------------------------------- call cpu elapsed disk query current rows total 114.50 295.62 347167 350487 0 183292 <- 6 minutes /* index on (id,revision) */ ----------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| ----------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 137K| 4849K| | 427K (4)| | 1 | SORT GROUP BY | | 137K| 4849K| 2248M| 427K (4)| | 2 | TABLE ACCESS FULL | EMPLOYEES | 53M| 1823M| | 18697 (19)| -----------------------------------------------------------------------------------

Full index scans Select id,count(CHANGED) from employees group by ID; /* index on (id,changed) */ ----------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| ----------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 137K| 4850K| 347K (1)| | 1 | SORT GROUP BY NOSORT| | 137K| 4850K| 347K (1)| | 2 | INDEX FULL SCAN | EMP$ID1 | 53M| 1820M| 347K (1)| ----------------------------------------------------------------------------------- call cpu elapsed disk query current rows total 114.50 295.62 347167 350487 0 183292 <- 6 minutes /* index on (id,revision) */ ----------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| ----------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 137K| 4849K| | 427K (4)| | 1 | SORT GROUP BY | | 137K| 4849K| 2248M| 427K (4)| | 2 | TABLE ACCESS FULL | EMPLOYEES | 53M| 1823M| | 18697 (19)| <- 5 hrs -----------------------------------------------------------------------------------

Fast Full Index Scans Fast full index scans are an alternative to a full table scan when the index contains all the columns that are needed for the query, and at least one column in the index key has the NOT NULL constraint. A fast full scan accesses the data in the index itself, without accessing the table. The database cannot use this scan to eliminate a sort operation because the data is not ordered by the index key. The database reads the entire index using multiblock reads, unlike a full index scan, and can scan in parallel. A fast full scan is faster than a normal full index scan because it can use multiblock I/O and can run in parallel just like a table scan.

Fast Full Index Scans Select ID, count(CHANGED) from employees group by ID order by ID desc ; /* index on (ID, CHANGED) */ -------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| | 0 | SELECT STATEMENT | | 137K| 4843K| | 418K (4)| | 1 | SORT GROUP BY | | 137K| 4843K| 2246M| 418K (4)| | 2 | INDEX FAST FULL SCAN | EMP$ID2 | 53M| 1821M| | 10096 (15)| -------------------------------------------------------------------------------------------- call cpu elapsed disk query current rows total 173.39 190.97 351251 350838 9 183292 < ~4 minutes /* index on (ID desc, CHANGED) */ ------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| | 0 | SELECT STATEMENT | | 137K| 4847K| | 755K (2)| | 1 | SORT GROUP BY | | 137K| 4847K| 2246M| 755K (2)| | 2 | INDEX FULL SCAN | EMP$ID3 | 53M| 1821M| | 347K (1)| ------------------------------------------------------------------------------------------- call cpu elapsed disk query current rows total 157.17 335.36 349129 348667 9 183292 < ~6 minutes

Fast Full Index Scans /* index on (CHANGED, ID) */ select ID,CHANGED from employees where CHANGED='PAUL'; ------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| ------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 26M| 910M| 10071 (15)| |* 1 | INDEX FAST FULL SCAN | EMP$CHANGE | 26M| 910M| 10071 (15)| ------------------------------------------------------------------------------------- call cpu elapsed disk query current rows ------- -------- ---------- ---------- ---------- ---------- ---------- total 16.56 41.97 350792 350841 0 0 <- 42 seconds select * from employees where CHANGED='PAUL'; --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 26M| 1821M| 18958 (20)| |* 1 | TABLE ACCESS FULL | EMPLOYEES | 26M| 1821M| 18958 (20)| <- 5 hours ---------------------------------------------------------------------------

Other types Index Joins An index join is a hash join of several indexes that together contain all the table columns referenced in the query. If the database uses an index join, then table access is not needed because the database can retrieve all the relevant column values from the indexes. The database cannot use an index join cannot to eliminate a sort operation. Bitmap Indexes A bitmap join uses a bitmap for key values and a mapping function that converts each bit position to a rowid. Bitmaps can efficiently merge indexes that correspond to several conditions in a WHERE clause, using Boolean operations to resolve AND and OR conditions. Cluster Access The database uses a cluster scan to retrieve all rows that have the same cluster key value from a table stored in an indexed cluster. In an indexed cluster, the database stores all rows with the same cluster key value in the same data block. To perform a cluster scan, Oracle Database first obtains the rowid of one of the selected rows by scanning the cluster index. Oracle Database then locates the rows based on this rowid. Hash Access The database uses a hash scan to locate rows in a hash cluster based on a hash value. In a hash cluster, all rows with the same hash value are stored in the same data block. To perform a hash scan, Oracle Database first obtains the hash value by applying a hash function to a cluster key value specified by the statement. Oracle Database then scans the data blocks containing rows with that hash value.

Other types Sample Table Scans A sample table scan retrieves a random sample of data from a simple table or a complex SELECT statement, such as a statement involving joins and views. The database uses this access path when a statement's FROM clause includes the SAMPLE clause or the SAMPLE BLOCK clause. To perform a sample table scan when sampling by rows with the SAMPLE clause, the database reads a specified percentage of rows in the table. To perform a sample table scan when sampling by blocks with the SAMPLE BLOCK clause, the database reads a specified percentage of table blocks. /* access 1% of the employees table, sampling by blocks */ SELECT * FROM employees SAMPLE BLOCK (1);

Sydney Oracle Meetup - access paths

More Related Content

Similar to Sydney Oracle Meetup - access paths (20)

More from paulguerin (7)

Recently uploaded (20)

Sydney Oracle Meetup - access paths

Editor's Notes