Docstoc

Leccotech - PowerPoint

Document Sample
Leccotech - PowerPoint Powered By Docstoc
					             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
            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 <iName> on
           <tname> (<col_name>);

• 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 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
         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 (don‟t 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 < 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
              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 table‟s 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 = 56722
    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

				
DOCUMENT INFO
Description: Leccotech document sample