Tuning: overview Rewrite SQL (Leccotech)Leccotech Create Index Redefine Main memory structures (SGA in Oracle) Change the Block Size Materialized Views, Denormalization Export/Import (drop indexes): defragment Check Locks Separate data by category in proper tablespaces Partition Database Redundant Arrays of Inexpensive Disks (RAID) Redefining Client-Server Architecture Buy Hardware

When to Index Large tables A field that you query by frequently Field with high cardinality (not sex where card. Is only 2) Smaller Fields and Fixed length are preferred. (Obs:Most DBMSs automatically index PK)

Different Type of Indexes B-Trees (traditional) indexes Hash-cluster Bitmap indexes Index-Organized Tables Reverse-Key Indexes

Create Index command Create index on ( ); Create index cidx on orders (cid);

Why do we create an index ? (OLTP x Data Warehouse) A) To speed up query (SELECT) ? B) To speed up data entry (insert/update/delete) ? C) All of the above ?

Indexes (Defaults) Anytime a PK is created, an index is automatically created. Anytime when the type of index is not specificied, the type of index created is a B-Trees.

B-Tree (Balanced Tree) Most popular type of index structure for any programming language or database. When you dont know what to do, the best option is usually a B-Tree. They are flexible and perform well (not very well) in several scenarios. It is really the B+ tree or B* tree

B-Trees (continued) One node corresponds to one block/page (minimum disk I-O). Non-Leaf nodes(n keys, n+1 pointers) Leaf-Nodes (contain n entries, where each entry has an index and a pointer to a data block). Also, each node has a pointer to next node. All leaves are at the same height.

Good Indexing (B-Tree) Candidates Table must be reasonably large Field is queried by frequently Field has a high cardinality (dont index by sex, where the cardinality is 2!!). Badly balanced trees may inhibit performance. Destroying and re-creating index may improve performance.

Bitmap Index Bitmap indexes contain the key value and a bitmap listing the value of 0 or 1 (yes/no) for each row indicating whether the row contains that value or not. May be a good option for indexing fields that have low cardinality (opposite of B- trees).

Bitmap Index (cont.) Syntax: Create Bitmap index …. Bitmap index works better with equality tests = or in (not with ) Bitmap index maintenance can be expensive; an individual bit may not be locked; a single update locks a large portion of index. Bitmap indexes are best in read-only datawarehouse situations

Hash Indexing B-trees and Bitmap index keys are used to find rows requiring I/O to process index Hash gets rows with a key based algorithm Rows are stored based on a hashed value Index size should be known at index creation Example: –create index cidx on orders (cid) hashed;

Hash Index work best with Very-high cardinality columns Only equal (=) tests are used Index values do not change Number of rows are known ahead of time

Index-Organized Tables Table data is incorporated into the B-Tree using the PK as the index. Table data is always in order of PK. Many sorts can be avoided. Especially useful for lookup type tables Index works best when there are few (and small) columns in your table other than the PK.

Reverse Key Indexes Key 1234 becomes 4321, etc. Only efficient for few scenarios envolving parallel processing and a hughe amount of data. By reversing key values, index blocks might be more evenly distributed reducing the likelihood of densely or sparsely populated indexes.

Conclusions on Indexes For high-cardinality key values, B-Tree indexes are usually best. B-Trees work with all types of comparisons and gracefully shrink and grow as table changes. For low cardinality read-only environments, Bitmaps may be a good option.

Query Optimizer A query optimizer parsers your SQL/Query into a sequence of relational algebra operations, determining an execution plan. The query optimizer figures out the best execution plan based on rules of thumb and information provided in the Data Dictionary (System catalog).

Oracle Query Optimizer Up to version 6, Oracle Used a Rule Based Optimizer. After version 6, Oracle offered the Cost Based and the Rule Based Optimizer. The default is now the Cost Based Optimizer.

Query Optimizer To view how the query plan you must use either set autotrace on or explain plan. Set autotrace on is much simpler. Explain plan is a little bit more efficient, but more complicated.

Typical SQL operations (results of autotrace) TABLE ACCESS FULL TABLE ACCESS BY ROWID INDEX RANGE SCAN INDEX UNIQUE SCAN NESTED LOOPS

TABLE ACCESS FULL (full table scan): Oracle will look at every row in the table to find the requested information. This is usually the slowest way to access a table.

TABLE ACCESS BY ROWID Oracle will use the ROWID method to find a row in the table. ROWID is a special column detailing an exact Oracle block where the row can be found. This is the fastest way to access a table (faster than any index. Less flexible than any index).

INDEX RANGE SCAN Oracle will search an index for a range of values. Usually, this even occurs when a range or between operation is specified by the query or when only the leading columns in a composite index are specified by the where clause. Can perform well or poorly, based on the size of the range and the fragmentation of the index.).

INDEX UNIQUE SCAN Oracle will perform this operation when the tables primary key or a unique key is part of the where clause. This is the most efficient way to search an index.

NESTED LOOPS Indicates that a join operation is occurring. Can perform well or poorly, depending on performance on the index and table operations of the individual tables being joined.

Tuning SQL and PL/SQL Queries Sometimes, Same Query written more than 1000 ways. Generating more than 100 execution plans. Some firms have products that re-write correctly written SQL queries automatically.

ROWID SELECT ROWID, … INTO :EMP_ROWID, … FROM EMP WHERE EMP.EMP_NO = FOR UPDATE; UPDATE EMP SET EMP.NAME = … WHERE ROWID = :EMP_ROWID;

ROWID (cont.) Fastest Less Flexible Are very useful for removing duplicates of rows

SELECT STATEMENT Not exists in place of NOT IN Joins in place of Exists Avoid sub-selects Exists in place of distinct UNION in place of OR on an index column WHERE instead of ORDER BY