Sydney Oracle Meetup - indexes

Sydney Oracle Meetup - Indexes 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….

Indexes - general An index is an optional structure, that can sometimes speed data access. Indexes are also used with integrity constraints. eg unique key, primary key Table rows in which all key columns are null are not indexed , except for bitmap indexes or when the cluster key column value is null. Can place partitioned (local, global) or non-partitioned indexes on a partitioned table. Can place partitioned (global) or non-partitioned indexes on a non-partitioned table.

Cluster Factor The clustering factor is useful as a rough measure of the number of I/Os required to read an entire table by an index range scan . Compare the cluster factor with a FTS (ie the HWM for a table). Lower the ratio the better (best ratio=1). select index_name, clustering_factor, clustering_factor/blocks from dba_tables a, dba_indexes b where a.owner=b.table_owner and a.table_name=b.table_name and a.owner=upper('&own') and a.table_name=upper('&tbl') order by 3; INDEX_NAME CLUSTERING_FACTOR CLUSTERING_FACTOR/BLOCKS ----------------- ----------------- ------------------------ CNT$BLT 4320 3.4887097 CNT$CNT_SCN 7682 6.1916129 CNT$CNTNM 23360 18.8387097 CNT$PK_CNTID 49939 40.2733871 CNT$DLNMBR 55664 44.8903226 In many situations the cluster factor can be disregarded.

Usable or unusable Not maintained by DML operations and is ignored by the optimizer. Instead of dropping an index and later re-creating it, you can make the index unusable and then rebuild it. Beginning with Oracle Database 11g Release 2, when you make an existing index unusable, its index segment is dropped. CREATE INDEX myemp_ename ON emp(ename) TABLESPACE users UNUSABLE; Note: Truncating a table makes an unusable index usable.

Visible or invisible An invisible index is maintained by DML operations, but is not used by the CBO. Used to test the removal of an index before dropping it. ALTER INDEX index INVISIBLE; ALTER INDEX index VISIBLE;

Monitoring Index Usage A means of monitoring indexes to determine whether they are being used. If an index is not being used, then it can be dropped. -- start monitoring an index ALTER INDEX <index> MONITORING USAGE; -- stop monitoring an index ALTER INDEX <index> NOMONITORING USAGE; The view V$OBJECT_USAGE can be queried for the index being monitored to see if the index has been used. select * from V$OBJECT_USAGE where table_name=‘<table>'; Note1: Need to login as the owner of the index. Note2: Doesn’t monitor usage for the child index on a foreign key when the parent primary/unique key is modified. Note3: Monitors other accesses eg gather stats, and explain plan.

Monitoring Space Use of Indexes Monitor index efficiency of space usage by analysing, then querying: /* Prevents DML by default so add the ONLINE clause */ analyze index <schema>.<index> validate structure online; SELECT PCT_USED FROM INDEX_STATS; SELECT PCT_USED FROM INDEX_HISTOGRAM;

Rebuild or Coalesce When rebuilding, querying is allowed but DDL is not. Unless you use the ONLINE clause DML is not allowed either. /* performance improvement with NOLOGGING clause */ /* Don’t lock the table with the ONLINE clause */ ALTER INDEX <schema.name> REBUILD NOLOGGING ONLINE; Start online index builds when DML activity is low. Parallel execution is not supported when creating or rebuilding an index online. /* Coalese also available - don’t need twice the index space */ ALTER INDEX <schema.name> COALESCE; ALTER INDEX ... SHRINK SPACE COMPACT;

B-tree indexes Short for balanced tree , and are the most common type of index. Excellent retrieval performance for a wide range of queries, including exact match and range searches. Descending index: Descending indexes are useful when a query sorts some columns ascending and others descending. Database can use this index to retrieve the data and avoid the extra step of sorting it in descending order.

B-tree indexes Reverse Key: Bytes of the index key are reversed, so inserts are spread over many index blocks. Reversing the key solves the problem of contention for leaf blocks in the right side of a B-tree index. This problem can be especially acute in an Oracle Real Application Clusters (Oracle RAC) database in which multiple instances repeatedly modify the same block. Index range scanning is limited because not sorted by key column. Note: As inserts are distributed across the index - cluster factor becomes much worse.

B-tree indexes Key compression: ANALYZE INDEX <schema.name> VALIDATE STRUCTURE; SELECT name, partition_name, blocks, opt_cmpr_count, opt_cmpr_pctsave FROM INDEX_STATS; CREATE INDEX emp_ename ON emp(ename) COMPRESS 1; SELECT compress, prefix_length FROM dba_indexes WHERE owner=‘<owner>’ and table_name = ‘<table>’; Example: non-compressed index: online,0,AAAPvCAAFAAAAFaAAa online,0,AAAPvCAAFAAAAFaAAg online,0,AAAPvCAAFAAAAFaAAl online,2,AAAPvCAAFAAAAFaAAm online,3,AAAPvCAAFAAAAFaAAq online,3,AAAPvCAAFAAAAFaAAt

B-tree indexes compressed index (specified prefix length 1): online 0,AAAPvCAAFAAAAFaAAa 0,AAAPvCAAFAAAAFaAAg 0,AAAPvCAAFAAAAFaAAl 2,AAAPvCAAFAAAAFaAAm 3,AAAPvCAAFAAAAFaAAq 3,AAAPvCAAFAAAAFaAAt compressed index (default prefix – not always optimal): online,0 AAAPvCAAFAAAAFaAAa AAAPvCAAFAAAAFaAAg AAAPvCAAFAAAAFaAAl online,2 AAAPvCAAFAAAAFaAAm online,3 AAAPvCAAFAAAAFaAAq AAAPvCAAFAAAAFaAAt

Index Organised Tables (IOTs) The data is stored inside the index. There is no table. Rows are stored in an index defined on the primary key for the table. (in a normal table, inserts are where ever they can fit). Index-organized tables provide faster key-based access to table data for queries that involve exact match or range search or both. The presence of non-key columns of a row in the leaf block avoids an additional data block I/O.

Index Organised Tables (IOTs) A secondary index is an index on an index-organized table. In a sense, it is an index on an index. The secondary index is an independent schema object and is stored separately from the index-organized table. Secondary indexes provide fast and efficient access to index-organized tables using columns that are neither the primary key nor a prefix of the primary key. A secondary index on an index-organized table can be a bitmap index.

Bitmap indexes In a bitmap index, the database stores a bitmap for each index key. (In a B-tree index, one index entry points to a single row.) In a bitmap index, each index key stores pointers to multiple rows. Useful when: The indexed columns have low cardinality, that is, the number of distinct values is small compared to the number of table rows. The indexed table is either read-only or not subject to significant modification by DML statements. The WHERE clause contains multiple predicates on low- or medium-cardinality columns. The individual predicates on these low- or medium-cardinality columns select a large number of rows. The bitmap indexes used in the queries have been created on some or all of these low- or medium-cardinality columns. The tables in the queries contain many rows.

Bitmap indexes Bitmap indexes can include keys that consist entirely of null values, unlike B-tree indexes. Conceptually, an index leaf contains entries as follows: index key, low rowid and high rowid, a bitmap for those rowids. Shipping Clerk,AAAPzRAAFAAAABSABQ,AAAPzRAAFAAAABSABZ,0010000100 Shipping Clerk,AAAPzRAAFAAAABSABa,AAAPzRAAFAAAABSABh,010010 Stock Clerk,AAAPzRAAFAAAABSAAa,AAAPzRAAFAAAABSAAc,1001001100 Stock Clerk,AAAPzRAAFAAAABSAAd,AAAPzRAAFAAAABSAAt,0101001001 Stock Clerk,AAAPzRAAFAAAABSAAu,AAAPzRAAFAAAABSABz,100001 If the indexed column in a single row is updated, then the database locks the index key entry and not the individual bit mapped to the updated row. Because a key points to many rows, DML on indexed data typically locks all of these rows. For this reason, bitmap indexes are not appropriate for many OLTP applications.

Bitmap join indexes A bitmap join index is a bitmap index for the join of two or more tables. In a bitmap index, an index entry uses a bitmap to point to multiple rows. In contrast, a B-tree index entry points to a single row. For each value in a table column, the index stores the rowid of the corresponding row in the indexed table.

Bitmap join indexes CREATE BITMAP INDEX employees_bm_idx ON employees (jobs.job_title) FROM employees, jobs WHERE employees.job_id = jobs.job_id; SELECT COUNT(*) FROM employees, jobs WHERE employees.job_id = jobs.job_id AND jobs.job_title = 'Accountant'; Bitmap join indexes are sometimes much more efficient in storage than materialized join views.

Function-based indexes Include columns that are either transformed by a function, or within an expression. Can be B-tree or bitmap. The database only uses the function-based index when the function is included in a query. CREATE INDEX emp_total_sal_idx ON employees ( 12 * salary * commission_pct , salary, commission_pct); SELECT employee_id, last_name, first_name, 12*salary*commission_pct AS "ANNUAL SAL" FROM employees WHERE (12 * salary * commission_pct) < 30000 ORDER BY "ANNUAL SAL" DESC; A function-based index is also useful for indexing only specific rows in a table. eg Index only the A rows: CREATE INDEX cust_valid_idx ON customers ( CASE cust_valid WHEN 'A' THEN 'A' END );

B-tree cluster indexes This type of index is used to index a table cluster key. Instead of pointing to a row, the key points to the block that contains rows related to the cluster key.

Application domain indexes This type of index is created by a user for data in an application-specific domain. The physical index need not use a traditional index structure and can be stored either in the Oracle database as tables or externally as a file. Accommodate indexes on customized, complex data types such as documents, spatial data, images, and video clips (see "Unstructured Data") . The application software, called the cartridge, controls the structure and content of a domain index. The database interacts with the application to build, maintain, and search the domain index. The index structure itself can be stored in the database as an index-organized table or externally as a file.

Domain indexes Domain indexes are built using the indexing logic supplied by a user-defined indextype. An indextype provides an efficient mechanism to access data that satisfy certain operator predicates. Typically, the user-defined indextype is part of an Oracle Database option, like the Spatial option.

Sydney Oracle Meetup - indexes

More Related Content

What's hot (20)

Viewers also liked (12)

Similar to Sydney Oracle Meetup - indexes (20)

Recently uploaded (20)

Sydney Oracle Meetup - indexes

Editor's Notes