Tunning overview
-
Upload
hitesh-kumar-markam -
Category
Education
-
view
128 -
download
2
description
Transcript of Tunning overview
![Page 1: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/1.jpg)
Performance Tuning
![Page 2: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/2.jpg)
Tuning: overview• Rewrite SQL (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
![Page 3: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/3.jpg)
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)
![Page 4: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/4.jpg)
Different Type of Indexes
• B-Trees (traditional) indexes
• Hash-cluster
• Bitmap indexes
• Index-Organized Tables
• Reverse-Key Indexes
![Page 5: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/5.jpg)
Create Index command
• Create index <iName> on
<tname> (<col_name>);
• Create index cidx on orders (cid);
![Page 6: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/6.jpg)
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 ?
![Page 7: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/7.jpg)
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.
![Page 8: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/8.jpg)
B-Tree (Balanced Tree)
• Most popular type of index structure for any programming language or database.
• When you don’t 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
![Page 9: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/9.jpg)
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.
![Page 10: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/10.jpg)
Good Indexing (B-Tree) Candidates
• Table must be reasonably large
• Field is queried by frequently
• Field has a high cardinality (don’t index by sex, where the cardinality is 2!!).
• Badly balanced trees may inhibit performance. Destroying and re-creating index may improve performance.
![Page 11: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/11.jpg)
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).
![Page 12: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/12.jpg)
Bitmap Index (cont.)
• Syntax: Create Bitmap index ….• Bitmap index works better with equality tests = or in
(not with < or > )• 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
![Page 13: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/13.jpg)
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;
![Page 14: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/14.jpg)
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
![Page 15: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/15.jpg)
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.
• Index works best when there are few (and small) columns in your table other than the PK.
![Page 16: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/16.jpg)
Reverse Key Indexes
• Key ‘1234’ becomes ‘4321’, etc. • Only efficient for few scenarios involving
parallel processing and a huge amount of data.• By reversing key values, index blocks might
be more evenly distributed reducing the likelihood of densely or sparsely populated indexes.
![Page 17: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/17.jpg)
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.
![Page 18: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/18.jpg)
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).
![Page 19: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/19.jpg)
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.
![Page 20: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/20.jpg)
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.
![Page 21: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/21.jpg)
Typical SQL operations (results of autotrace)
• TABLE ACCESS FULL
• TABLE ACCESS BY ROWID
• INDEX RANGE SCAN
• INDEX UNIQUE SCAN
• NESTED LOOPS
![Page 22: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/22.jpg)
• 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.
![Page 23: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/23.jpg)
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).
![Page 24: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/24.jpg)
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.).
![Page 25: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/25.jpg)
INDEX UNIQUE SCAN
Oracle will perform this operation when the table’s primary key or
a unique key is part of the where clause. This is the most efficient
way to search an index.
![Page 26: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/26.jpg)
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.
![Page 27: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/27.jpg)
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.
Select emp_sal from emp where emp_id exists (select emp_id from dept where deptname like’mca’);
![Page 28: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/28.jpg)
ROWID
• SELECT ROWID, …
INTO :EMP_ROWID, …
FROM EMP
WHERE EMP.EMP_NO = 56722
FOR UPDATE;
UPDATE EMP SET EMP.NAME = …
WHERE ROWID = :EMP_ROWID;
![Page 29: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/29.jpg)
ROWID (cont.)
• Fastest
• Less Flexible
• Are very useful for removing duplicates of rows
![Page 30: Tunning overview](https://reader034.fdocuments.in/reader034/viewer/2022052321/54c6add34a7959526c8b457d/html5/thumbnails/30.jpg)
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