Indexes … WHERE key = 22 22 Table Index 22 Row pointer Key Indexes Indexes are optional structures associated with tables. They can be created to improve the performance of data update and retrieval. An Oracle index provides a direct access path to a row of data. Indexes can be created on one or more columns of a table. After an index is created, it is automatically maintained and used by the Oracle server. Updates to a table’s data, such as adding new rows, updating rows, or deleting rows, are automatically propagated to all relevant indexes with complete transparency to users. Table Index

Types of Indexes These are several types of index structures available to you, depending on the need: A B-tree index is in the form of a binary tree and is the default index type. A bitmap index has a bitmap for each distinct value indexed, and each bit position represents a row that may or may not contain the indexed value. This is best for low-cardinality columns. Types of Indexes The following are the most common forms of indexes: B-tree Bitmap A B-tree index has its key values stored in a balanced tree (B-tree), allowing for fast binary searches. A bitmap index has a bitmap for each distinct key value being indexed. Within each bitmap, there is a bit set aside for each row in the table being indexed. This allows for fast lookups when there are few distinct values; that is, the indexed column has low cardinality. An example of this is a gender indicator. It can have values of “M” and “F” only. So, there are only two bitmaps to search. For example, if a bitmap index were used for a phone_number column, there would be so many bitmaps to manage and search that it would be very inefficient. Use bitmap indexes for low-cardinality columns.

B-Tree Index Index entry Root Branch Index entry header Leaf Key column length Key column value ROWID

B-Tree Index Structure of a B-tree index At the top of the index is the root, which contains entries that point to the next level in the index. At the next level are branch blocks, which in turn point to blocks at the next level in the index. At the lowest level are the leaf nodes, which contain the index entries that point to rows in the table. The leaf blocks are doubly linked to facilitate the scanning of the index in an ascending as well as descending order of key values. Format of index leaf entries An index entry is made up of the following components: An entry header, which stores the number of columns and locking information Key column length-value pairs, which define the size of a column in the key followed by the value for the column (The number of such pairs is a maximum of the number of columns in the index.) ROWID of a row that contains the key values

Bitmap Indexes File 3 Table Block 10 Block 11 Block 12 Index Key Start <Blue, 10.0.3, 12.8.3, 1000100100010010100> <Green, 10.0.3, 12.8.3, 0001010000100100000> <Red, 10.0.3, 12.8.3, 0100000011000001001> <Yellow, 10.0.3, 12.8.3, 0010001000001000010> Key Start ROWID End Bitmap

Bitmap Indexes Structure of a bitmap index A bitmap index is also organized as a B-tree, but the leaf node stores a bitmap for each key value instead of a list of ROWIDs. Each bit in the bitmap corresponds to a possible ROWID, and if the bit is set, it means that the row with the corresponding ROWID contains the key value. As shown in the diagram, the leaf node of a bitmap index contains the following: An entry header that contains the number of columns and lock info Key values consisting of length and value pairs for each key column Start ROWID End ROWID A bitmap segment consisting of a string of bits. (The bit is set when the corresponding row contains the key value and is unset when the row does not contain the key value. The Oracle server uses a patented compression technique to store bitmap segments.)

Index Options A unique index ensures that every indexed value is unique. CREATE UNIQUE INDEX emp1 ON EMP (ename); DBA_INDEXES. UNIQUENESS  ‘UNIQUE’ Bitmap index CREATE BITMAP INDEX emp2 ON EMP (deptno); DBA_INDEXES.INDEX_TYPE  ‘BITMAP’ An index can have its key values stored in ascending or descending order. CREATE INDEX emp3 ON emp (sal DESC); DBA_IND_COLUMNS.DESCEND  ‘DESC’ Index Options For efficiency of retrieval, it may be advantageous to have an index store the keys in descending order. This decision is made on the basis of how the data is accessed most frequently. A reverse key index has the bytes of the indexed value stored in reverse order. This can reduce activity in a particular hot spot in the index. If many users are processing data in the same order, then the prefix portions of the key values (that are currently being processed) are close in value at any given instant. Consequently, there is a lot of activity in that area of the index structure. A reverse key index spreads that activity out across the index structure by indexing a reversed-byte version of the key values. An index created by the combination of more than one column is called a composite index. For example, you can create an index based on a person’s last name and first name: CREATE INDEX name_ix ON employees (last_name, first_name); 7

Index Options A composite index is one that is based on more than one column. CREATE INDEX emp4 ON emp (empno, sal); DBA_IND_COLUMNS.COLUMN_POSITION  1,2 … A function-based index is an index based on a function’s return value. CREATE INDEX emp5 ON emp (SUBSTR(ename, 3, 4)); DBA_IND_EXPRESSIONS.COLUMN_EXPRESSION  ‘SUBSTR …’ A compressed index has repeated key values removed. CREATE INDEX emp6 ON emp (empno, ename, sal) COMPRESS 2; DBA_INDEXES.COMPRESSION  ‘ENABLED’ DBA_INDEXES.PREFIX_LENGTH  2

Creating Indexes Creating Indexes You can click the Indexes link under the Schema heading of the Administration page to view the Indexes page. You can view index attributes or use the Actions menu to view dependencies for an index. Indexes can be created explicitly, or implicitly through constraints that are placed on a table. An example of an implicitly created index is the definition of a primary key, in which case a unique index would be automatically created to enforce uniqueness on the column. CREATE INDEX my_index ON employees(last_name, first_name);

Table Types Related data from more than one table are stored together. Heap Clustered Related data from more than one table are stored together. Clustered table Data (including non-key values) is sorted and stored in a B-tree index structure. Index-organized table (IOT) Data is divided into smaller, more manageable pieces. Partitioned table Data is stored as an unordered collection (heap). Ordinary (heap- organized) table Description Type Table Types Ordinary “heap-organized” tables are introduced in the Oracle Database 10g: Administration Workshop I course. Partitions are pieces of a table or an index, created to facilitate management of a very large database (VLDB), which could contain several terabytes of data. Unlike a heap-organized table whose data is stored as an unordered collection (heap), data for an index-organized table (IOT) is stored in a B-tree index structure in a primary key–sorted manner. A cluster is a group of tables that share the same data blocks because they share common columns and are often used together. Partitioned IOT

What Is a Partition and Why Use It? A partition is: A piece of a “very large” table or index Stored in its own segment Used for improved performance and manageability What Is a Partition and Why Use It? A partition is a piece of a “very large” table or index, stored in its own segment, so that it can be managed individually. An example of a “very large” table is a data warehouse table of several hundred gigabytes of data. Partitions can be further broken down into subpartitions for finer levels of manageability and improved performance. Partitioning can also bring better performance because many queries can ignore partitions that, according to the WHERE clause, do not have the requested rows, thereby reducing the amount of data to be scanned to produce a result set. Operations on partitioned tables and indexes can be performed in parallel by assigning different parallel execution servers to different partitions of the table or index.

CREATE TABLE eladasok ( szla_szam NUMBER(5), szla_nev CHAR(30), RANGE PARTITION CREATE TABLE eladasok ( szla_szam NUMBER(5), szla_nev CHAR(30), mennyiseg NUMBER(6), het INTEGER ) PARTITION BY RANGE ( het ) (PARTITION negyedev1 VALUES LESS THAN ( 13 ) TABLESPACE users, PARTITION negyedev2 VALUES LESS THAN ( 26 ) TABLESPACE example, PARTITION negyedev3 VALUES LESS THAN ( 39 ) TABLESPACE users ) DBA_PART_TABLES DBA_TAB_PARTITIONS DBA_TAB_SUBPARTITIONS 12

HASH PARTITION, LIST PARTITION CREATE TABLE eladasok2 (szla_szam NUMBER(5), szla_nev CHAR(30), mennyiseg NUMBER(6), het INTEGER ) PARTITION BY HASH ( het ) (PARTITION part1 TABLESPACE users, PARTITION part2 TABLESPACE example, PARTITION part3 TABLESPACE users ); CREATE TABLE eladasok3 (szla_szam NUMBER(5), PARTITION BY LIST ( het ) (PARTITION part1 VALUES(1,2,3,4,5) TABLESPACE users, PARTITION part2 VALUES(6,7,8,9) TABLESPACE example, PARTITION part3 VALUES(10,11,12,13) TABLESPACE users ) ; 13

SUBPARTITIONS (RANGE-HASH) CREATE TABLE eladasok4 (szla_szam NUMBER(5), szla_nev CHAR(30), mennyiseg NUMBER(6), het INTEGER ) PARTITION BY RANGE ( het ) SUBPARTITION BY HASH (mennyiseg) SUBPARTITIONS 3 (PARTITION negyedev1 VALUES LESS THAN ( 13 ) TABLESPACE users, PARTITION negyedev2 VALUES LESS THAN ( 26 ) TABLESPACE example, PARTITION negyedev3 VALUES LESS THAN ( 39 ) TABLESPACE users ); 14

Index-Organized Tables Regular table access IOT access Table access by ROWID Non-key columns Index-Organized Tables Unlike an ordinary (heap-organized) table whose data is stored as an unordered collection (heap), data for an index-organized table (IOT) is stored in a B-tree index structure in a primary key–sorted manner. Besides storing the primary key column values, each index entry in the IOT B-tree stores the non-key column values as well. Index-organized tables have full table functionality. They support features such as constraints, triggers, LOB and object columns, partitioning, parallel operations, online reorganization, and replication. You can even create indexes on an index-organized table. Index-organized tables are ideal for OLTP applications, which require fast primary key access and high availability. Queries and DML on an orders table used in online order processing are predominantly primary-key based, and a heavy volume of DML causes fragmentation that results in a frequent need to reorganize. Because an index-organized table can be reorganized online and without invalidating its secondary indexes, the window of unavailability is greatly reduced or eliminated. An index-organized table is an alternative to: A table indexed on the primary key by using the CREATE INDEX statement A cluster table stored in an indexed cluster, which has been created using the CREATE CLUSTER statement that maps the primary key for the table to the cluster key Key column Row header

Index-Organized Tables and Heap Tables Compared to heap tables, IOTs: Have faster key-based access to table data Do not duplicate the storage of primary key values Require less storage Use secondary indexes and logical row IDs Have higher availability because table reorganization does not invalidate secondary indexes Index-Organized Tables and Heap Tables Index-organized tables do not have regular (physical) row IDs, but use logical row IDs instead. Logical row IDs give the fastest possible access to rows in IOTs by using two methods: A physical guess whose access time is equal to that of physical row IDs Access without the guess (or after an incorrect guess); this performs a primary key access of the IOT The guess is based on knowledge of the file and block that a row resides in. The latter information is accurate when the index is created, but changes if the leaf block splits. If the guess is wrong and the row no longer resides in the specified block, then the remaining portion of the logical row ID entry, the primary key, is used to get the row. The Oracle database constructs secondary indexes on index-organized tables by using logical row IDs that are based on the table’s primary key. Because rows in index-organized tables do not have permanent physical addresses, the physical guesses can become stale when rows are moved to new blocks. To obtain fresh guesses, you can rebuild the secondary index. Note that rebuilding a secondary index on an index-organized table involves reading the base table, unlike rebuilding an index on an ordinary table.

Index-Organized Tables CREATE TABLE cikk_iot ( ckod integer, cnev varchar2(20), szin varchar2(15), suly float, CONSTRAINT cikk_iot_pk PRIMARY KEY (ckod) ) ORGANIZATION INDEX PCTTHRESHOLD 20 INCLUDING cnev OVERFLOW TABLESPACE users; DBA_INDEXES index_type  ‘IOT-TOP’ table_name  ‘CIKK_IOT’ DBA_TABLES.IOT_TYPE  ‘IOT’ or ‘IOT_OVERFLOW’ DBA_TABLES.IOT_NAME  ‘CIKK_IOT’ for overflow segment Index-Organized Tables and Heap Tables Index-organized tables do not have regular (physical) row IDs, but use logical row IDs instead. Logical row IDs give the fastest possible access to rows in IOTs by using two methods: A physical guess whose access time is equal to that of physical row IDs Access without the guess (or after an incorrect guess); this performs a primary key access of the IOT The guess is based on knowledge of the file and block that a row resides in. The latter information is accurate when the index is created, but changes if the leaf block splits. If the guess is wrong and the row no longer resides in the specified block, then the remaining portion of the logical row ID entry, the primary key, is used to get the row. The Oracle database constructs secondary indexes on index-organized tables by using logical row IDs that are based on the table’s primary key. Because rows in index-organized tables do not have permanent physical addresses, the physical guesses can become stale when rows are moved to new blocks. To obtain fresh guesses, you can rebuild the secondary index. Note that rebuilding a secondary index on an index-organized table involves reading the base table, unlike rebuilding an index on an ordinary table. 17

Clusters Unclustered orders and order_item tables ORD_NO PROD QTY ... ----- ------ ------ 101 A4102 20 102 A2091 11 102 G7830 20 102 N9587 26 101 A5675 19 101 W0824 10 Cluster Key (ORD_NO) 101 ORD_DT CUST_CD 05-JAN-97 R01 PROD QTY A4102 20 A5675 19 W0824 10 102 ORD_DT CUST_CD 07-JAN-97 N45 A2091 11 G7830 20 N9587 26 ORD_NO ORD_DT CUST_CD ------ ------ ------ 101 05-JAN-97 R01 102 07-JAN-97 N45 Definition of Clusters A cluster is a group of one or more tables that share the same data blocks because they share common columns and are often used together in join queries. Storing tables in clusters offers the DBA a method to denormalize data. If you implement clustered tables in your database, you do not need to change any application code that accesses the tables. Clusters are transparent to the end user and programmer. Performance Benefits of Clusters Disk I/O is reduced and access time improved for joins of clustered tables. Each cluster key value is stored only once for all the rows of the same key value; therefore, it uses less storage space. Performance Consideration Full table scans are generally slower on clustered tables than on nonclustered tables. Unclustered orders and order_item tables Clustered orders and order_item tables

Cluster Types Index cluster Hash cluster Hash function

Situations Where Clusters Are Useful Criterion Uniform key distribution Evenly spread key values Rarely updated key Often joined master-detail tables Predictable number of key values Queries using equality predicate on key Index X Hash X

INDEX CLUSTER CREATE CLUSTER personnel ( department_number NUMBER(2) ) SIZE 512; CREATE TABLE emp_cl ( empno NUMBER PRIMARY KEY,ename VARCHAR2(30), job VARCHAR2(27), mgr NUMBER(4), hiredate DATE, sal NUMBER(7,2), comm NUMBER(7,2), deptno NUMBER(2) NOT NULL) CLUSTER personnel (deptno); CREATE TABLE dept_cl ( deptno NUMBER(2), dname VARCHAR2(9), loc VARCHAR2(9)) CREATE INDEX idx_personnel ON CLUSTER personnel; DBA_CLUSTERS DBA_CLU_COLUMNS DBA_TABLES.CLUSTER_NAME  ‘PERSONNEL’ 21

HASH CLUSTER CREATE CLUSTER personnel1 ( department_number NUMBER ) SIZE 512 HASHKEYS 500 STORAGE (INITIAL 100K NEXT 50K); CREATE CLUSTER personnel2 ( home_area_code NUMBER, home_prefix NUMBER ) HASHKEYS 20 HASH IS MOD(home_area_code + home_prefix, 101); CREATE CLUSTER personnel3 (deptno NUMBER) SIZE 512 SINGLE TABLE HASHKEYS 500; DBA_CLUSTERS DBA_CLU_COLUMNS DBA_CLUSTER_HASH_EXPRESSIONS 22