http://www.skill-guru.com/blog/2010/01/03/understanding-materialized-view-in-ora cle/ http://www.oracle-base.com/articles/8i/partitioned-tables-and-indexes.php http://www.rampant-books.com/art_nanda_partitioning1.htm http://docs.oracle.com/cd/B28359_01/server.111/b32024/partition.

htm#

+ ALL_ROWS */ Explicitly chooses the cost-based approach to optimize a statement block with a goal of best throughput (that is, minimum total resource consumption) /*+ CHOOSE */ Causes the optimizer to choose between the rule-based approach and the cost-base d approach for a SQL statement based on the presence of statistics for the table s accessed by the statement /*+ FIRST_ROWS */ Explicitly chooses the cost-based approach to optimize a statement block with a goal of best response time (minimum resource usage to return first row). It will also force the optimizer to make use of index, if available. There are other ve rsions of FIRST_ROWS hints. This hint is useful in an OLTP environment when the user cannot wait till the last row is fetched. This is mainly used in Java looku p screens. If there are some calculations then this hint should not be used. Test your PL/SQL knowledge, Which code runs faster? /*+ RULE */ Explicitly chooses rule-based optimization for a statement block /*+ AND_EQUAL(table index) */ Explicitly chooses an execution plan that uses an access path that merges the sc ans on several single-column indexes /*+ CLUSTER(table) */ Explicitly chooses a cluster scan to access the specified table /*+ FULL(table) */ Explicitly chooses a full table scan for the specified table /*+ HASH(table) */ Explicitly chooses a hash scan to access the specified table

/*+ HASH_AJ(table) */ Transforms a NOT IN sub query into a hash anti join to access the specified tabl e /*+ HASH_SJ (table) */ Transforms a NOT IN sub query into a hash anti-join to access the specified tabl e /*+ INDEX(table index) */ Explicitly chooses an index scan for the specified table /*+ INDEX_ASC(table index) */ Explicitly chooses an ascending-range index scan for the specified table /*+ INDEX_COMBINE(table index) */ If no indexes are given as arguments for the INDEX_COMBINE hint, the optimizer u ses whatever Boolean combination of bitmap indexes has the best cost estimate. I f particular indexes are given as arguments, the optimizer tries to use some Boo lean combination of those particular bitmap indexes. /*+ INDEX_DESC(table index) */ Explicitly chooses a descending-range index scan for the specified table /*+ INDEX_FFS(table index) */ Causes a fast full index scan to be performed rather than a full table scan /*+ MERGE_AJ (table) */ Transforms a NOT IN sub query into a merge anti-join to access the specified tab le /*+ MERGE_SJ (table) */ Transforms a correlated EXISTS sub query into a merge semi-join to access the sp ecified table /*+ ROWID(table) */ Explicitly chooses a table scan by ROWID for the specified table /*+ USE_CONCAT */ Forces combined OR conditions in the WHERE clause of a query to be transformed i

nto a compound query using the UNION ALL set operator /*+ ORDERED */ Causes Oracle to join tables in the order in which they appear in the FROM claus e /*+ STAR */ Forces the large table to be joined using a nested-loop join on the index /*+ DRIVING_SITE (table) */ Forces query execution to be done at a different site from that selected by Orac le /*+ USE_HASH (table) */ Causes Oracle to join each specified table with another row source with a hash j oin /*+ USE_MERGE (table) */ Causes Oracle to join each specified table with another row source with a sort-m erge join /*+ USE_NL (table) */ Causes Oracle to join each specified table to another row source with a nested-l oops join using the specified table as the inner table /*+ APPEND */ , /*+ NOAPPEND */ Specifies that data is simply appended (or not) to a table; existing free space is not used. Use these hints only following the INSERT keyword. /*+ NOPARALLEL(table) */ Disables parallel scanning of a table, even if the table was created with a PARA LLEL clause /*+ PARALLEL(table, instances) */ This can ered (Use allows you to specify the desired number of concurrent slave processes that be used for the operation. DELETE, INSERT, and UPDATE operations are consid for parallelization only if the session is in a PARALLEL DML enabled mode. ALTER SESSION PARALLEL DML to enter this mode.)

/*+ PARALLEL_INDEX */ Allows you to parallelize fast full index scan for partitioned and non-partition ed indexes that have the PARALLEL attribute /*+ NOPARALLEL_INDEX */ Overrides a PARALLEL attribute setting on an index /*+ CACHE */ Specifies that the blocks retrieved for the table in the hint are placed at the most recently used end of the LRU list in the buffer cache when a full table sca n is performed /*+ NOCACHE */ Specifies that the blocks retrieved for this table are placed at the least recen tly used end of the LRU list in the buffer cache when a full table scan is perfo rmed /*+ MERGE (table) */ Causes Oracle to evaluate complex views or sub queries before the surrounding qu ery /*+ NO_MERGE (table) */ Causes Oracle not to merge mergeable views /*+ PUSH_JOIN_PRED (table) */ Causes the optimizer to evaluate, on a cost basis, whether or not to push indivi dual join predicates into the view /*+ NO_PUSH_JOIN_PRED (table) */ Prevents pushing of a join predicate into the view /*+ PUSH_SUBQ */ Causes non merged sub queries to be evaluated at the earliest possible place in the execution plan /*+ STAR_TRANSFORMATION */ Makes the optimizer use the best plan in which the transformation has been used. ================== Oracle SQL hints

/*+ hint */ /*+ hint(argument) */ /*+ hint(argument-1 argument-2) */ All hints except /*+ rule */ cause the CBO to be used. Therefore, it is good pra ctise to analyze the underlying tables if hints are used (or the query is fully hinted. There should be no schema names in hints. Hints must use aliases if alia s names are used for table names. So the following is wrong: select /*+ index(scott.emp ix_emp) */ from scott.emp emp_alias better: select /*+ index(emp_alias ix_emp) */ ... from scott.emp emp_alias Why using hints It is a perfect valid question to ask why hints should be used. Oracle comes wit h an optimizer that promises to optimize a query's execution plan. When this opt imizer is really doing a good job, no hints should be required at all. Sometimes , however, the characteristics of the data in the database are changing rapidly, so that the optimizer (or more accuratly, its statistics) are out of date. In t his case, a hint could help. It must also be noted, that Oracle allows to lock t he statistics when they look ideal which should make the hints meaningless again . Hint categories Hints can be categorized as follows: Hints for Optimization Approaches and Goals, Hints for Access Paths, Hints for Query Transformations, Hints for Join Orders, Hints for Join Operations, Hints for Parallel Execution, Additional Hints Documented Hints Hints for Optimization Approaches and Goals ALL_ROWS One of the hints that 'invokes' the Cost based optimizer ALL_ROWS is usually used for batch processing or data warehousing systems. FIRST_ROWS One of the hints that 'invokes' the Cost based optimizer FIRST_ROWS is usually used for OLTP systems. CHOOSE One of the hints that 'invokes' the Cost based optimizer This hint lets the server choose (between ALL_ROWS and FIRST_ROWS, based on stat istics gathered. RULE The RULE hint should be considered deprecated as it is dropped from Oracle9i2. See also the following initialization parameters: optimizer_mode, optimizer_max_ permutations, optimizer_index_cost_adj, optimizer_index_caching and Hints for Access Paths CLUSTER Performs a nested loop by the cluster index of one of the tables. FULL Performs full table scan. HASH Hashes one table (full scan) and creates a hash index for that table. Then hashe s other table and uses hash index to find corresponding records. Therefore not s uitable for < or > join conditions. ROWID Retrieves the row by rowid INDEX Specifying that index index_name should be used on table tab_name: /*+ index (ta b_name index_name) */ Specifying that the index should be used the the CBO thinks is most suitable. (N ot always a good choice).

Starting with Oracle 10g, the index hint can be described: /*+ index(my_tab my_t ab(col_1, col_2)) */. Using the index on my_tab that starts with the columns col _1 and col_2. INDEX_ASC INDEX_COMBINE INDEX_DESC INDEX_FFS INDEX_JOIN NO_INDEX AND_EQUAL The AND_EQUAL hint explicitly chooses an execution plan that uses an access path that merges the scans on several single-column indexes Hints for Query Transformations FACT The FACT hint is used in the context of the star transformation to indicate to t he transformation that the hinted table should be considered as a fact table. MERGE NO_EXPAND NO_EXPAND_GSET_TO_UNION NO_FACT NO_MERGE NOREWRITE REWRITE STAR_TRANSFORMATION USE_CONCAT Hints for Join Operations DRIVING_SITE HASH_AJ HASH_SJ LEADING MERGE_AJ MERGE_SJ NL_AJ NL_SJ USE_HASH USE_MERGE USE_NL Hints for Parallel Execution NOPARALLEL PARALLEL NOPARALLEL_INDEX PARALLEL_INDEX PQ_DISTRIBUTE Additional Hints ANTIJOIN APPEND If a table or an index is specified with nologging, this hint applied with an in sert statement produces a direct path insert which reduces generation of redo. BITMAP BUFFER CACHE CARDINALITY CPU_COSTING DYNAMIC_SAMPLING INLINE MATERIALIZE

NO_ACCESS NO_BUFFER NO_MONITORING NO_PUSH_PRED NO_PUSH_SUBQ NO_QKN_BUFF NO_SEMIJOIN NOAPPEND NOCACHE OR_EXPAND ORDERED ORDERED_PREDICATES PUSH_PRED PUSH_SUBQ QB_NAME RESULT_CACHE (Oracle 11g) SELECTIVITY SEMIJOIN SEMIJOIN_DRIVER STAR The STAR hint forces a star query plan to be used, if possible. A star plan has the largest table in the query last in the join order and joins it with a nested loops join on a concatenated index. The STAR hint applies when there are at lea st three tables, the large table's concatenated index has at least three columns , and there are no conflicting access or join method hints. The optimizer also c onsiders different permutations of the small tables. SWAP_JOIN_INPUTS USE_ANTI USE_SEMI Undocumented hints: BYPASS_RECURSIVE_CHECK Workaraound for bug 1816154 BYPASS_UJVC CACHE_CB CACHE_TEMP_TABLE CIV_GB COLLECTIONS_GET_REFS CUBE_GB CURSOR_SHARING_EXACT DEREF_NO_REWRITE DML_UPDATE DOMAIN_INDEX_NO_SORT DOMAIN_INDEX_SORT DYNAMIC_SAMPLING DYNAMIC_SAMPLING_EST_CDN EXPAND_GSET_TO_UNION FORCE_SAMPLE_BLOCK GBY_CONC_ROLLUP GLOBAL_TABLE_HINTS HWM_BROKERED IGNORE_ON_CLAUSE IGNORE_WHERE_CLAUSE INDEX_RRS INDEX_SS INDEX_SS_ASC INDEX_SS_DESC LIKE_EXPAND LOCAL_INDEXES MV_MERGE

NESTED_TABLE_GET_REFS NESTED_TABLE_SET_REFS NESTED_TABLE_SET_SETID NO_FILTERING NO_ORDER_ROLLUPS NO_PRUNE_GSETS NO_STATS_GSETS NO_UNNEST NOCPU_COSTING OVERFLOW_NOMOVE PIV_GB PIV_SSF PQ_MAP PQ_NOMAP REMOTE_MAPPED RESTORE_AS_INTERVALS SAVE_AS_INTERVALS SCN_ASCENDING SKIP_EXT_OPTIMIZER SQLLDR SYS_DL_CURSOR SYS_PARALLEL_TXN SYS_RID_ORDER TIV_GB TIV_SSF UNNEST USE_TTT_FOR_GSETS ================ What is the difference between Rule based Optimizer and Cost based Optimizer in oracle? Leave a comment January 31, 2011 Filed under: Performance tuning In brief the rule-based method means that when executing a query the database mu st follow certain predefined rules and matter what data is stored in affected da tabase tables. The cost-based method means the database must decide which query executi on plan to choose using best guess approach that takes into account what data is stored in db. A long time ago the only optimizer in the Oracle database was the Rule-Based Opt imizer (RBO). Basically the RBO used a set of rules to determine how to execute a query. If an index was available on a table the RBO rules said to always use the index. There are some cases where the use of an index slowed down a query. For example assume someone put an index on the GENDER column which holds one of two values M ALE and FEMALE. Then someone issues the following query: SELECT * FROM emp WHERE gender FEMALE ; If the above query returned approximately 5 0 of the rows then using an index would actually slow things down. It would be faster to read the entire table and throw away all rows that have MALE values. E

xperts in Oracle query optimization have come to a rule of thumb that says if th e number of rows returned is more than 5-10 of the total table volume using an ind ex would slow things down. The RBO would always use an index if present because its rules said to. It became obvious that the RBO armed with its set of discrete rules did not alwa ys make great decisions. The biggest problem with the RBO was that it did not ta ke the data distribution into account. So the Cost-Based Optimizer (CBO) was born. The CBO uses statistics about the table its indexes and the data distribution to mak e better informed decisions. Using our previous example assume that the company has employees that are 95 fem ale and 5 male. If you query for females then you do not want to use the index. If you query for males then you would like to use the index. The CBO has information at hand to help make these kind of determinations that were not available in the o ld RBO. What is Cost-Based Optimization? The Oracle cost-based optimizer is designed to determine the most efficient way to carry out a SQL statement, but it can t reach do this without good, up-to-date statistical information on the data being accessed. The optimizer can use a rule s-based approach to work without statistical information, but this approach is l ess intelligent than the cost-based approach. With the rules-based approach, the opt imizer chooses an execution plan based a set of rules about what types of operat ions usually execute faster than other types. With the cost-based approach, the optim izer factors in statistical information about the contents of the particular sch ema objects (tables, clusters, or indexes) being accessed. Rule Based Optimizer Obsolescence The Rule Based Optimizer (RBO) is now obsolete in Oracle 10g. The functionality is still present but no new functionality has been included in it and it is no l onger supported by Oracle. It is only present to provide backwards compatibility durin g the migration to the query optimizer (Cost Based Optimizer). The results of th is osolescence are: - The CHOOSE and RULE options for the OPTIMIZER_MODE parameter still exist but a re no longer supported.

- The default value for the OPTIMIZER_MODE parameter is ALL_ROWS. - The CHOOSE and RULE optimizer hints still exist but are no longer supported. - Code requiring the RBO must be migrated to use the query optimizer. =================== Materialised view: A materialized view is a stored summary containing precomputes results (originat ing from an SQL select statement). As the data is precomputed, materialized view s allow for (seemingly) faster dataware query answers Types of materialized views There are three types of materialized views: Read only materialized view Updateable materialized view Writeable materialized view Read only materialized views Advantages: There is no possibility for conflicts as they cannot be updated. Complex materialized views are supported Updateable materialized views Advantages: Can be updated even when disconnected from the master site or master materialize d view site. Requires fewer resources than multimaster replication. Are refreshed on demand. Hence the load on the network might be reduced compared to using multimaster replication because multimaster replication synchronises c hanges at regular intervalls. Updateable materialized views require the advnced replication option to be insta lled. Writeable materialized views They are created with the for update clause during creation without then adding the materialized view to a materialized view group. In such a case, the material ized view is updatable, but the changes are lost when the materialized view refr eshes. Writeable materialized views require the advnced replication option to be installed. Query rewrite ... yet to be finished .. The query rewrite facility is totally transparent to a n application which needs not be aware of the existance of the underlying materi alized view. Refreshing process Refreshing a materialized view Refreshing a materialized view synchronizes is with its master table. Oracle per forms the following operations when refreshing a materialized view. In the case of a complete refresh (using dbms_mview.refresh) sys.snap$ and sys.mlog$ are updated to reflect the time of the refresh. The materialized base view is truncated. All rows selected from the master table are inserted into the snapshot base tabl e. sys.slog$ is updated to reflect the time of the refresh. In the case of a fast refresh, the steps are: sys.snap$ and sys.mlog$ are updated to reflect the time of the refresh. Rows in the materialized base view are deleted. All rows selected from the master table are inserted into the snapshot base tabl e. sys.slog$ is updated to reflect the time of the refresh. Rows that are not needed anymore for a refresh by any materialized view are dele

ted from the materialized view log (<schema name>.MLOG$_table) If a materialized view is being refreshed can be checked by querying the type of v$lock: if the type is JI a refresh is being performed. The following query checks for this: select o.owner "Owner", o.object_name "Mat View", username "Username", s.sid "Sid" from v$lock l, dba_objects o, v$session s where o.object_id = l.id1 and l.type ='JI' and l.lmode = 6 and s.sid = l.sid and o.object_type = 'TABLE' Errors during the automatic refresh of materialized views If an error occurs during the automatic refresh of a materialized view, an error message is written into the alert.log. ================= A materialized view stores both definitions of view plus rows resulting from the execution of the view. It is more efficient to use materialized views if query involves summaries, large or multiple joins or both. It is a pre-computed table comprising aggregated or joined data from fact and possibly dimensions tables. A lso known as a summary or aggregate table and mainly used for improving query pe rformance or providing replicated data. Oracle provides SQL Access Advisor, which is a set of advisory procedures in the DBMS_ADVISOR package to help in designing and evaluating materialized views for query rewrite Key Features Can define independent tablespace, storage parameters to Materialized views. Use Index & Partition Use query re-write feature Process of modifying a query to use the view rather t han the base table is called query rewrite. Types of materialized views Materialized view with Aggregates The valid aggregate functions are: SUM, COUNT( x), COUNT(*), AVG, VARIANCE, STDDEV, MIN, and MAX Materialized views containing only joins Nested Materialized views materialized view whose definition is based on another materialized view Materialized View Logs Materialized view logs are required if you want to use fast refresh. Materializ ed view logs are defined using a CREATE MATERIALIZED VIEW LOG statement on the b ase table that is to be changed. For fast refresh of materialized views, the definition of the materialized view logs must normally specify the ROWID clause. In addition, for aggregate material ized views, it must also contain every column in the table referenced in the mat erialized view, the INCLUDING NEW VALUES clause and the SEQUENCE clause. CREATE MATERIALIZED VIEW LOG ON sales WITH ROWID (prod_id, cust_id, time_id, cha nnel_id, promo_id, quantity_sold, amount_sold) INCLUDING NEW VALUES; Note: Oracle recommends that the keyword SEQUENCE be included in your materializ ed view log statement unless you are sure that you will never perform a mixed DM

L operation (a combination of INSERT, UPDATE, or DELETE operations on multiple t ables). CREATE MATERIALIZED VIEW LOG ON sales WITH SEQUENCE, ROWID (prod_id, cust_id, ti me_id, channel_id, promo_id, quantity_sold, amount_sold) INCLUDING NEW VALUES; Create Syntax CREATE MATERIALIZED VIEW <name> TABLESPACE <tbs_name> (<storage parameter>). build option REFRESH <refresh option> <refresh mode> [ENABLE | DISABLE] QUERY REWRITE AS SELE CT <select clause>; Example CREATE MATERIALIZED VIEW product_sales_mv PCTFREE 0 TABLESPACE demo STORAGE (INITIAL 16k NEXT 16k PCTINCREASE 0) BUILD DEFERRED REFRESH COMPLETE ON DEMAND ENABLE QUERY REWRITE AS SELECT p.prod_name, SUM (s.amount_sold) AS dollar_sales FROM sales s, products p WHERE s.prod_id = p.prod_id GROUP BY p.prod_name; Built Option The <build option> determines when MV is built BUILD IMMEDIATE: Create the materialized view and then populate it with data. BUILD DEFFERED: Create the materialized view definition but do not populate it w ith data. ON PREBUILT TABLE: use an existing table as view source Materialized Views Refresh Types Refresh is the operation that synchronizes the content of the materialized view with the data in base tables. Following are the types of refresh: Complete: Involves truncating existing data & re-inserting all the data based on the detail tables by re-executing the query definition from the create command. Fast: Apply the changes made since the last refresh. a)Fast refresh using materialized view logs b)Fast refresh using ROWID range: Can do the fast refresh after the direct load, based on the rowed of the new rows.

Force: First tries to refresh with fast mechanism if possible or else will use a complete refresh. This is default refresh type. Never: Suppresses all refreshes on materialized views. Materialized Views Refresh Modes Manual Refresh: Can be performed using DBMS_MVIEW package. (REFRESH, REFRESH_DE PENDENT, REFRESH_ALL_VIEWS) Automatic Refresh: Can be performed in two ways: a)ON COMMIT Materialized view gets updated whenever changes to one of these tabl es are committed. b)ON DEMMAND At Specified Time Refresh is scheduled to occur for specified time by using START WITH & NEXT clauses. For such refreshes, instance must initiate a process with JOB_QUEUE_PROCESSES. Materialized Views restrictions Underlying Query cannot contain non-repeatable expressions (ROWNUM, SYSDATE, non -repeatable PL/SQL functions, and so on). The query cannot contain any references to RAW or LONG RAW datatypes or object R EFs For PREBUILT, the precision of the columns must agree with the precision of the corresponding SELECT expressions MV with FAST refresh cannot contain any subquery. Adding Comments to Materialized Views COMMENT ON MATERIALIZED VIEW sales_mv IS SELECT MVIEW_NAME, COMMENTS FROM USER_MVIEW_COMMENTS WHERE MVIEW_NAME = Dropping Materialized Views DROP MATERIALIZED VIEW sales_sum_mv; Analyzing Materialized View Capabilities To analyze the potential / Details of MV can use following package. This will wr ite details into MV_CAPABILITIES_TABLE. EXECUTE DBMS_MVIEW.EXPLAIN_MVIEW ( SH.CAL_MONTH_SALES_MV ); SELECT capability_name, possible, SUBSTR(related_text,1,8) AS rel_text, SUBSTR(msgtxt,1,60) AS msgtxt FROM MV_CAPABILITIES_TABLE ORDER BY seq; Partition Change Tracking (PCT) The ability to identify which rows in a materialized view are affected by a cert ain detail table partition is known as Partition Change Tracking. When one or mo re of the detail tables are partitioned, it may be possible to identify the spec ific rows in the materialized view that correspond to a modified detail partitio SALES_MV ; sales materialized view ;

n(s); those rows become stale when a partition is modified while all other rows remain fresh. Requirements for PCT At least one of the detail tables referenced by the materialized view must be pa rtitioned Partitioned tables must use either range, list or composite partitioning The top level partition key must consist of only a single column PCT-based refresh is not supported for UNION ALL materialized views PCT is not supported for a materialized view that refers to views, remote tables , or outer joins QUERY REWRITE Query rewrite is the process of modifying a query to use the view rather than th e base table. User do not explicitly need privileges on materialized views, permission on unde rlying base tables are required. Optimizer rewrites the queries in order to utilize materialized views. GLOBAL_QUERY_REWRITE & QUERY_REWRITE system privileges allows user to enable mat erialized views. ============= partitioning: Basics of Partitioning Partitioning allows a table, index, or index-organized table to be subdivided in to smaller pieces, where each piece of such a database object is called a partit ion. Each partition has its own name, and may optionally have its own storage ch aracteristics. From the perspective of a database administrator, a partitioned object has multi ple pieces that can be managed either collectively or individually. This gives t he administrator considerable flexibility in managing partitioned objects. Howev er, from the perspective of the application, a partitioned table is identical to a non-partitioned table; no modifications are necessary when accessing a partit ioned table using SQL queries and DML statements