Tchater maintenant avec le support
Tchattez avec un ingénieur du support

SQL Optimizer for Oracle 10.0 - User Guide

Welcome to SQL Optimizer
About SQL Optimizer SQL Optimization Workflow New in This Release Additional Resources Database Privileges Database Privileges Script Connect to the Database Windows Layout Customize Toolbars Keyboard Shortcuts Support Bundle Register SQL Optimizer Check for Updates SQL Operations
ALL PARTITION ALTER INDEX AND EQUAL ANTI JOIN BITMAP AND BITMAP COMPACTION BITMAP CONSTRUCTION BITMAP CONVERSION BITMAP INDEX BITMAP JOIN INDEX UPDATE BITMAP JOIN INDEX UPDATE STATEMENT BITMAP KEY ITERATION BITMAP MERGE BITMAP MINUS BITMAP OR BUFFER SORT CARTESIAN JOIN COLLECTION ITERATOR CONCATENATION CONNECT BY CONNECT BY PUMP COUNT COUNT STOPKEY CREATE AS SELECT CUBE SCAN DDL STATEMENT DELETE DOMAIN INDEX FAST FULL INDEX SCAN FILTER FIRST ROWS FIXED INDEX FIXED TABLE FOR UPDATE FULL INDEX SCAN FULL INDEX SCAN DESCENDING FULL INDEX SCAN (MIN/MAX) HASH GROUP BY HASH GROUP BY PIVOT HASH JOIN HASH JOIN BUFFERED HASH PARTITION HASH UNIQUE INDEX INDEX BUILD NON UNIQUE INDEX RANGE SCAN INDEX RANGE SCAN DESCENDING INDEX RANGE SCAN (MIN/MAX) INDEX SAMPLE FAST FULL SCAN INDEX SKIP SCAN INDEX SKIP SCAN DESCENDING INDEX UNIQUE SCAN INLIST ITERATOR INLIST PARTITION INSERT INTERSECTION INTO INVALID PARTITION ITERATOR PARTITION LOAD AS SELECT MAT_VIEW ACCESS MAT_VIEW REWRITE ACCESS MERGE JOIN MINUS MULTI-TABLE INSERT NESTED LOOPS OUTER JOIN PARTITION PARTITION HASH EMPTY PARTITION LIST PARTITION RANGE PROJECTION PX BLOCK ITERATOR PX COORDINATOR PX ITERATOR PX PARTITION PX PARTITION HASH ALL PX PARTITION LIST ALL PX PARTITION RANGE ALL PX RECEIVE PX SEND RANGE PARTITION RECURSIVE EXECUTION RECURSIVE WITH PUMP REFERENCE MODEL REMOTE SELECT SEMI JOIN SEQUENCE SINGLE PARTITION SINGLE RANGE PARTITION SORT SORT AGGREGATE SORT GROUP BY SORT GROUP BY CUBE SORT GROUP BY NOSORT SORT GROUP BY ROLLUP SORT JOIN SORT ORDER BY SORT UNIQUE SQL MODEL TABLE ACCESS TABLE ACCESS BY GLOBAL INDEX ROWID TABLE ACCESS BY INDEX ROWID TABLE ACCESS BY LOCAL INDEX ROWID TABLE ACCESS BY ROWID TABLE ACCESS BY USER ROWID TABLE ACCESS CLUSTER TABLE ACCESS FULL TABLE ACCESS HASH TABLE ACCESS SAMPLE TABLE QUEUE TEMP TABLE GENERATION TEMP TABLE TRANSFORMATION UNION UNION ALL UNION ALL (RECURSIVE WITH) UNPIVOT UPDATE VIEW VIEW PUSHED PREDICATE WINDOW
Optimize SQL
Create Optimize SQL Sessions Open Optimizer SQL Sessions Rewrite SQL Generate Execution Plan Alternatives
Optimize Indexes Batch Optimize SQL Scan SQL Inspect SGA Analyze Impact Manage Plans Configure Options SQL Optimizer Tutorials About Us Legal Notices

HASH PARTITION

Execution plan image: image\Plan_Partition_All.gif  

Partition operation.

In an Oracle8i hash partition, rows are distributed to the various partitions based on the value of specific columns. However, in the case of hash partitions the column is subjected to a hashing algorithm to determine which partition stores the rows. The hashing algorithm applies a mathematical function to the column value and assigns the row to its partition based on the return value of the function. This ensures that each partition has approximately the same number of rows. It also means that you cannot reasonably anticipate which rows will end up in specific partitions. Rows that have adjacent column values will not necessarily end up in the same partition. They are usually allocated to separate partitions.

The following statement creates a variant of the SALES table that is partitioned by the hash of SALE_DATE. Six partitions are created with default storage attributes, though it could have explicitly named and supplied storage parameters for each partition:

CREATE TABLE SALES_HASH_PART

(column definitions)

PARTITION BY HASH (sale_date) PARTITIONS 8

The key advantage of hash partitions is that they are usually well-balanced: each partition will hold approximately the same number of rows. This improves the performance of many parallel operations on the partition.

Note: For a hash partition to be well-balanced using the default hashing algorithm, the number of partitions must be a power of 2 (i.e. 2, 4, 8, 16, 32).

The disadvantage of hash partitions is that you often will not get partition elimination for range-based queries such as "what were the total sales for quarter 4". Furthermore, you cannot purge old data using a hash partition. For example, a range partition that would have allowed you to easily remove all sales data for a specific year will require all the overhead of locating and removing each individual when you use hash partitioning.

Note: Consider hash partitioning when the balance of rows between partitions is more important than the benefits of partition elimination or purging data by dropping a partition. Remember to make the number of partitions a power of 2.

 

Related Topics

 

HASH UNIQUE

 

The HASH UNIQUE operation indexes and retrieves distinct rows using hashing.

 

  

 

 

INDEX

Execution Plan image: image\Plan_By_Index_generic.gif  

Index operation.

The following INDEX options are available:

Option

Description

Where Clause Example

SINGLE VALUE

Access a single value in the index and return a bitmap for all the matching rows.

Where State = 'MD'

FULL SCAN

A complete scan of the index to find any matching values.

Where State not in ('HI', 'AL')

RANGE SCAN

Access a range of values in the index and return multiple bitmaps. These bitmaps are then merged into one bitmap.

Where City like 'New*'

 

Related Topics

 

INDEX BUILD NON UNIQUE

 

The INDEX BUILD NON UNIQUE operation builds an index where the ROWIDs are associated with the table.

 

  

 

 

Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation