This action might not be possible to undo. Are you sure you want to continue?
Super fast Database Copying/Cloning
Oracle Tips by Burleson Consulting
A database cloning procedure is especially useful for the DBA who wants to give his developers a full-sized TEST and DEV instance by cloning the PROD instance into the development server areas. This Oracle clone procedure can be use to quickly migrate a system from one UNIX server to another. It clones the Oracle database and this Oracle cloning procedures is often the fastest way to copy a Oracle database. STEP 1: On the old system, go into SQL*Plus, sign on as SYSDBA and issue: “alter database backup controlfile to trace”. This will put the create database syntax in the trace file directory. The trace keyword tells oracle to generate a script containing a create controlfile command and store it in the trace directory identified in the user_dump_dest parameter of the init.ora file. It will look something like this:
STARTUP NOMOUNT CREATE CONTROLFILE REUSE DATABASE "OLDLSQ" NORESETLOGS NOARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 2 MAXDATAFILES 240 MAXINSTANCES 1 MAXLOGHISTORY 113 LOGFILE GROUP 1 ('/u03/oradata/oldlsq/log1a.dbf', '/u03/oradata/olslsq/log1b.dbf') SIZE 30M, GROUP 2 ('/u04/oradata/oldlsq/log2a.dbf', '/u04/oradata/oldlsq/log2b.dbf') SIZE 30M DATAFILE '/u01/oradata/oldlsq/system01.dbf', '/u01/oradata/oldlsq/mydatabase.dbf' ; # Recovery is required if any of the datafiles are restored # backups, or if the last shutdown was not normal or immediate. RECOVER DATABASE # Database can now be opened normally. ALTER DATABASE OPEN;
STEP 2: Shutdown the old database STEP 3: Copy all data files into the new directories on the new server. You may change the file names if you want, but you must edit the controlfile to reflect the new data files names on the new server.
rcp /u01/oradata/oldlsq/* newhost:/u01/oradata/newlsq rcp /u01/oradata/oldlsq/* newhost:/u01/oradata/newlsq rcp /u03/oradata/oldlsq/* newhost:/u03/oradata/newlsq
rcp /u04/oradata/oldlsq/* newhost:/u04/oradata/newlsq
STEP 4: Copy and Edit the Control file – Using the output syntax from STEP 1, modify the controlfile creation script by changing the following: Old:
CREATE CONTROLFILE REUSE DATABASE "OLDLSQ" NORESETLOGS
CREATE CONTROLFILE SET DATABASE "NEWLSQ" RESETLOGS
STEP 5: Remove the “recover database” and “alter database open” syntax
# Recovery is required if any of the datafiles are restored # backups, or if the last shutdown was not normal or immediate. RECOVER DATABASE # Database can now be opened normally. ALTER DATABASE OPEN;
STEP 6: Re-names of the data files names that have changed. Save as db_create_controlfile.sql. Old:
DATAFILE '/u01/oradata/oldlsq/system01.dbf', '/u01/oradata/oldlsq/mydatabase.dbf'
DATAFILE '/u01/oradata/newlsq/system01.dbf', '/u01/oradata/newlsq/mydatabase.dbf'
STEP 7: Create the bdump, udump and cdump directories
cd $DBA/admin mkdir newlsq cd newlsq mkdir bdump mkdir udump mkdir cdump mkdir pfile
STEP 8: Copy-over the old init.ora file
Once the access path has been decided upon it is stored in the library cache together with the statement itself.sql STEP 10: Place the new database in archivelog mode Interpreting Explain Plan What's an explain plan? An explain plan is a representation of the access path that is taken when a query is executed within Oracle. subquery merging.ora newhost:/u01/oracle/admin/newlsq/pfile STEP 9: Start the new database @db_create_controlfile. Terminology Row Source Predicate A set of rows used in a query may be a select from a base object or the result set returned by joining 2 earlier row sources where clause of a query . We store queries in the library cache based upon a hashed representation of that query. Step  is the execution of the statement. With the Rule Based Optimizer (RBO) it uses a set of heuristics to determine access path. This access path will be used until the query is reparsed. in/or transformation)  Optimization Determines the optimal access path for the query to take. we first apply a hashing algorithm to the statement and then we look for this hash value in the library cache. When looking for a statement in the library cache. Query processing can be divided into 7 phases:  Syntactic  Semantic  View Merging Checks the syntax of the query Checks that all objects exist and are accessible Rewrites query as join on base tables as opposed to using views  Statement Rewrites query transforming some complex constructs into Transformation simpler ones where appropriate (e.g.rcp $DBA/admin/olslsq/pfile/*. The explain plan is produced by the parser. With the Cost Based Optimizer (CBO) we use statistics to analyze the relative costs of accessing objects.  QEP Generation QEP = Query Evaluation Plan  QEP Execution QEP = Query Evaluation Plan Steps - are handled by the parser.
How does Oracle access data? At the physical level Oracle reads blocks of data. The smallest amount of data read is a single Oracle block. . If this returns a lot of rows then this can have a negative affect on all subsequent operations This is the object we lookup data in after we have retrieved relevant key data from the driving table. The costs of different statements are not really directly comparable. For example the following query indicates that the CBO has been used because there is a cost in the cost field: SELECT STATEMENT [CHOOSE] Cost=1234 However the explain plan below indicates the use of the RBO because the cost field is blank: SELECT STATEMENT [CHOOSE] Cost= The cost field is a comparative cost that is used internally to determine the best cost for particular plans. [CHOOSE] is an indication of the optimizer_goal for the query. In this case it is the SELECT STATEMENT which is the top of the query. This DOES NOT necessarily indicate that plan has actually used this goal. When this operation completes then the resultant row source is passed up to the next level of the query for processing. Logically Oracle finds the data to read by using the following methods: Full Table Scan (FTS) Index Lookup (unique & non-unique) Rowid Explain plan Hierarchy Simple explain plan: Query Plan ----------------------------------------SELECT STATEMENT [CHOOSE] Cost=1234 TABLE ACCESS FULL LARGE [:Q65001] [ANALYZED] The rightmost uppermost operation of an explain plan is the first thing that the explain plan will execute. In this case TABLE ACCESS FULL LARGE is the first operation. This statement means we are doing a full table scan of table LARGE. the largest is constrained by operating system limits (and multiblock i/o).Tuples Driving Table Probed Table rows This is the row source that we use to seed the query. The only way to confirm this is to check the cost= part of the explain plan as well.
Truncate resets the HWM back to the start of the table. A rowid uniquely identifies an individual row in a particular data block. Access Methods in detail Full Table Scan (FTS) In a FTS operation. FTS uses multiblock i/o to read the blocks from disk. In this example an index is used to find the relevant row(s) and then the table is accessed to lookup the ename column (which is not included in the index): SQL> explain plan for select empno. Example FTS explain plan: SQL> explain plan for select * from dual. Multiblock i/o is controlled by the parameter <PARAM:db_block_multi_block_read_count>. FTS is not recommended for large tables unless you are reading >5-10% of it (or so) or you intend to run in parallel. This defaults to: db_block_buffers / ( (PROCESSES+3) / 4 ) Maximum values are OS dependant Buffers from FTS operations are placed on the Least Recently Used (LRU) end of the buffer cache so will be quickly aged out. The HWM marks the last block in the table that has ever had data written to it. the whole table is read up to the high water mark (HWM). This number indicates that the operation will be processed by a parallel query slave as opposed to being executed serially. There is no indication of the 'level' of analysis done. Query Plan ----------------------------------------SELECT STATEMENT [CHOOSE] Cost= TABLE ACCESS FULL DUAL Index lookup Data is accessed by looking up key values in an index and returning rowids.ename from emp where empno=10. If you have deleted all the rows then you will still read up to the HWM.[:Q65001] indicates that this particular part of the query is being executed in parallel. This block is read via single block i/o. [ANALYZED] indicates that the object in question has been analyzed and there are currently statistics available for the CBO to use. Query Plan .
Query Plan ------------------------------------------------------------SELECT STATEMENT [CHOOSE] Cost=1 TABLE ACCESS BY ROWID EMP [ANALYZED] INDEX RANGE SCAN EMP_I1 [ANALYZED] In this case the index is sorted so ther rows will be returned in the order of the index hence a sort is unecessary. SQL> explain plan for select empno. In the following example all the columns (empno) are in the index. If all the required data resides in the index then a table lookup may be unnecessary and all you will see is an index access with no table access. Query Plan -----------------------------------SELECT STATEMENT [CHOOSE] Cost=1 INDEX UNIQUE SCAN EMP_I1 Indexes are presorted so sorting may be unecessary if the sort order required is the same as the index. SQL> explain plan for select /*+ Full(emp) */ empno.-----------------------------------SELECT STATEMENT [CHOOSE] Cost=1 TABLE ACCESS BY ROWID EMP [ANALYZED] INDEX UNIQUE SCAN EMP_I1 Notice the 'TABLE ACCESS BY ROWID' section. This is explained below. In this case the rowid has been produced by looking up values in the index first. Query Plan ------------------------------------------------------------SELECT STATEMENT [CHOOSE] Cost=9 SORT ORDER BY TABLE ACCESS FULL EMP [ANALYZED] Cost=1 Card=2 Bytes=66 Because we have forced a FTS the data is unsorted and so we must sort the data after it has been retrieved.ename from emp where empno > 7876 order by empno.ename from emp where empno> 7876 order by empno. The index name in this case is EMP_I1. This indicates that the table data is not being accessed via a FTS operation but rather by a rowid lookup. There are 4 methods of index lookup: . The index is being accessed by an 'INDEX UNIQUE SCAN' operation. Notice that no table access takes place: SQL> explain plan for select empno from emp where empno=10.
We choose an index .ename from emp where empno > 7876 order by empno.g. However this may return > 1 row as the uniqueness will not be guaranteed. Full index scans are only available in the CBO as otherwise we are unable to determine whether a full scan would be a good idea or not. > < <> >= <= between) SQL> explain plan for select empno. SQL> explain plan for select empno.index index index index unique scan range scan full scan fast full scan Index unique scan Method for looking up a single key value via a unique index. Query Plan ------------------------------------------------------SELECT STATEMENT [CHOOSE] Cost=1 TABLE ACCESS BY ROWID EMP [ANALYZED] INDEX RANGE SCAN EMP_I1 [ANALYZED] A non-unique index may return multiple values for the predicate col1 = 5 and will use an index range scan SQL> explain plan for select mgr from emp where mgr = 5 Query plan -------------------SELECT STATEMENT [CHOOSE] Cost=1 INDEX RANGE SCAN EMP_I2 [ANALYZED] Index Full Scan In certain circumstances it is possible for the whole index to be scanned as opposed to a range scan (i. where no constraining predicates are provided for a table). Query Plan -----------------------------------SELECT STATEMENT [CHOOSE] Cost=1 TABLE ACCESS BY ROWID EMP [ANALYZED] INDEX UNIQUE SCAN EMP_I1 Index range scan Method for accessing multiple column values You must supply AT LEAST the leading column of the index to access data via the index Can be used for range operations (e. Always returns a single value You must supply AT LEAST the leading column of the index to access data via the index.e.ename from emp where empno=10.
For example we may do a Full index scan when we do an unbounded scan of an index and want the data to be ordered in the index order.Full Scan when we have statistics that indicate that it is going to be more efficient than a Full table scan and a sort.3 and requires V733_PLANS_ENABLED=TRUE and CBO may be hinted using INDEX_FFS hint uses multiblock i/o can be executed in parallel can be used to access second column of concatenated indexes.ename) SQL> explain plan for select empno. An Index full scan will perform single block i/o's and so it may prove to be inefficient. Most frequently seen in explain plans as Table access by Rowid .ename) SQL> explain plan for select empno. Index BE_IX is a concatenated index on big_emp (empno.ename from big_emp order by empno. Query Plan -----------------------------------------SELECT STATEMENT [CHOOSE] Cost=1 INDEX FAST FULL SCAN BE_IX [ANALYZED] Selecting the 2nd column of concatenated index: SQL> explain plan for select ename from big_emp. The optimizer may decide that selecting all the information from the index and not sorting is more efficient than doing a FTS or a Fast Full Index Scan and then sorting. Index BE_IX is a concatenated index on big_emp (empno.ename from big_emp. This is because we are selecting all of the index. Query Plan -----------------------------------------SELECT STATEMENT [CHOOSE] Cost=1 INDEX FAST FULL SCAN BE_IX [ANALYZED] Rowid This is the quickest access method available Oracle simply retrieves the block specified and extracts the rows it is interested in. Query Plan -----------------------------------------------------------SELECT STATEMENT [CHOOSE] Cost=26 INDEX FULL SCAN BE_IX [ANALYZED] Index Fast Full Scan Scans all the block in the index Rows are not returned in sorted order Introduced in 7.ename. Note that INDEX FAST FULL SCAN is the mechinism behind fast index create and recreate.
col1.C B.SQL> explain plan for select * from dept where rowid = ':x'.col1 is the leading column. Join order .col3 = = = = 10 B.B.col3.col1 C.col1 and join to A.col2 5 We could represent the joins present in the query using the following schematic: B <---> A <---> col3=10 C col3=5 There are really only 2 ways we can drive the query: via B. Consider the following query: select from where and and and A. Suppose there is a concatenated index on A(a. Note that a. This is unlikely to be efficient with large tables. We would have to do a Full scan of A to be able to drive off it. This may prevent certain access paths from being taken. Because we have now filled the leading column of the concatenated index on table A we can use this index to . Query Plan -----------------------------------SELECT STATEMENT [CHOOSE] Cost=1 TABLE ACCESS BY ROWID EMP [ANALYZED] INDEX UNIQUE SCAN EMP_I1 Joins A Join is a predicate that attempts to combine 2 row sources We only ever join 2 row sources together Join steps are always performed serially even though underlying row sources may have been accessed in parallel.col2 C.col4 A.col1. Query Plan -----------------------------------SELECT STATEMENT [CHOOSE] Cost=1 TABLE ACCESS BY ROWID DEPT [ANALYZED] Table is accessed by rowid following index lookup: SQL> explain plan for select empno.col3 or C. certain predicates may be satisfied that are not satisfied by with other join orders.a.ename from emp where empno=10.order in which joins are performed The join order makes a significant difference to the way in which the query is executed.col3=10 (as a filter or lookup key) then we will retrieve the value for B. using predicate B.col1 A. By accessing particular row sources first.col2). If we drive off table B.col3 A.
The resultant query would be: select from where and and and /*+ ordered */ A. However if we drive of table c. So it is likely that the best join order will be B A C.col2 and since this is a trailing column of a concatenated index and the leading column has not been supplied at this point.col1 A.dept d .col2 and join to A.deptno. Although the merge of the 2 row sources is handled serially. If the CBO does not choose this join order then we can hint it by changing the from clause to read: from B.C and using the /*+ ordered */ hint. then we only get a value for a.A. Row Source 1 and 2 are NOT accessed concurrently Sorted rows from both sides are then merged together (joined) MERGE / SORT | Row Source 1 \ SORT | Row Source 2 If the row sources are already (known to be) sorted then the sort operation is unecessary as long as both 'sides' are sorted using the same key.give us values for A.col2 = C.C B.col2 C.col3 = 5 Join Types Sort Merge Join (SMJ) Nested Loops (NL) Hash Join Sort Merge Join Rows are produced by Row Source 1 and are then sorted Rows from Row Source 2 are then produced and sorted by the same sort key as Row Source 1.A.col1 = B. the row sources could be accessed in parallel.d. we cannot use the index on a to lookup the data.col3 = 10 A. The CBO will obviously use costs to establish whether the individual access paths are a good idea or not.col4 B. SQL> explain plan for select /*+ ordered */ e.deptno from emp e. Presorted row sources include indexed columns and row sources that have already been sorted in earlier steps.
Query Plan ------------------------------------SELECT STATEMENT [CHOOSE] Cost=17 MERGE JOIN SORT JOIN TABLE ACCESS FULL EMP [ANALYZED] SORT JOIN TABLE ACCESS FULL DEPT [ANALYZED] Sorting is an expensive operation.deptno.b.deptno.emp b where a.deptno order by e. SQL> explain plan for select a.Probe -> Row source 2 Row source 2 Row source 2 Row source 1 is known as the outer table Row source 2 is known as the inner table Accessing row source 2 is known a probing the inner table For nested loops to be efficient it is important that the first row source returns as few rows as possible as this directly controls the number of probes of the second row source.deptno = b.Probe -> -. SMJ is often not a particularly efficient join method.3 More efficient in theory than NL & SMJ Only accessible via the CBO Smallest row source is chosen and used to build a hash table and a bitmap The second row source is hashed and checked against the hash .sql from dept a.where e. Query Plan ------------------------SELECT STATEMENT [CHOOSE] Cost=5 NESTED LOOPS TABLE ACCESS FULL DEPT [ANALYZED] TABLE ACCESS FULL EMP [ANALYZED] Hash Join New join type introduced in 7.d. Because of this.deptno = d. Nested Loops First we return all the rows from row source 1 Then we probe row source 2 once for each row returned from row source 1 Row source 1 ~~~~~~~~~~~~ Row 1 -------------Row 2 -------------Row 3 -------------- -.dname.Probe -> -. especially with large tables.deptno. Also it helps if the access method for row source 2 is efficient as this operation is being repeated once for every row returned by row source 1.
deptno. Operations Operations that show up in explain plans sort filter view Sorts . TRUE is the default in 7. The bitmap is used as a quick lookup to check if rows are in the hash table and are especially useful when the hash table is too large to fit in memory. It can be useful in some circumstances .table looking for joins.dept where emp.dept Query Plan -----------------------------SLECT STATEMENT [CHOOSE] Cost=5 MERGE JOIN CARTESIAN TABLE ACCESS FULL DEPT SORT JOIN TABLE ACCESS FULL EMP The CARTESIAN keyword indicate that we are doing a cartesian product. Query Plan ---------------------------SELECT STATEMENT [CHOOSE] Cost=3 HASH JOIN TABLE ACCESS FULL DEPT TABLE ACCESS FULL EMP Hash joins are enabled by the parameter HASH_JOIN_ENABLED=TRUE in the init. Notice that there is no join between the 2 tables: SQL> explain plan for select emp.deptno.deptno = dept.deptno from emp.ora or session.3 Cartesian Product A Cartesian Product is done where they are no join conditions between 2 row sources and there is no alternative method of accessing the data Not really a join as such as there is no join! Typically this is caused by a coding mistake where a join has been left out.dept.Star joins uses cartesian products. SQL> explain plan for select /*+ use_hash(emp) */ empno from emp.
By default sort blocks are placed into the buffer cache.e. Views When a view cannot be merged into the main query you will often see a projection . The second is filtering out the min value: SQL> explain plan for select * from emp where empno not in (select min(empno) from big_emp group by empno). Filter Has a number of different meanings used to indicate partition elimination may also indicate an actual filter step where one row source is filtering another functions such as min may introduce filter steps into query plans In this example there are 2 filter steps.There are a number of different operations that promote sorts order by clauses group by sort merge join Note that if the row source is already appropriately sorted then no sorting is required. This may result in aging out of other blocks that may be reread by other processes... To avoid this you can use the parameter <Parameter:SORT_DIRECT_WRITES> which does not place sort blocks into the buffer cache.. This is now indicated in 7. Query Plan -----------------SELECT STATEMENT [CHOOSE] Cost=1 FILTER **** This is like a bounded nested loops TABLE ACCESS FULL EMP [ANALYZED] FILTER **** This filter is introduced by the min SORT GROUP BY NOSORT INDEX FULL SCAN BE_IX This example is also interesting in that it has a NOSORT function. In this case the group by operation simply groups the rows it does not do the sort operation as this has already been completed.. This is there because of the not in. The group by does not need to sort because the index row source is already pre sorted.3: SORT GROUP BY NOSORT INDEX FULL SCAN . The first is effectively like a NL except that it stops when it gets something that it doesn't like (i. Sorts are expensive operations especially on large tables where the rows do not fit in memory and spill to disk. a bounded NL).
sum(empno) tot from big_emp group by empno) tmp where emp.bitm_numb = p1.empno = tmp.tot from emp.empno. This indicates that the 'view' will be selected from directly as opposed to being broken down into joins on the base tables. (select empno.year = 1997 and kbwyv1. Inline views are also non mergeable.kbwyv1) ordered */ from parent1 p1.class = 22 and kbwyv1. In the following example the select contains an inline view which cannot be merged: SQL> explain plan for select ename.view operation. Query Plan -----------------------SELECT STATEMENT [CHOOSE] HASH JOIN TABLE ACCESS FULL EMP [ANALYZED] VIEW SORT GROUP BY INDEX FULL SCAN BE_IX In this case the inline view tmp which contains an aggregate function cannot be merged into the main query. A number of constructs make a view non mergeable. kbwyv1 where p1. The explain plan shows this as a view step.week between 32 and 33 . Partition Views Allows a large table to be broken up into a number of smaller partitions which can be queried much more quickly than the table as a whole a union all view is built over the top to provide the original functionality Check constraints or where clauses provide partition elimination capabilities SQL> explain plan for select /*+ use_nl(p1.bitm_numb and kbwyv1. sum(prc_pd) Query Plan ----------------------------------------SELECT STATEMENT [FIRST_ROWS] Cost=1780 SORT AGGREGATE NESTED LOOPS [:Q65001] Ct=1780 Cd=40 Bt=3120 TABLE ACCESS FULL PARENT1 [:Q65000] [AN] Ct=20 Cd=40 Bt=1040 VIEW KBWYV1 [:Q65001] UNION-ALL PARTITION [:Q65001] FILTER [:Q64000] TABLE ACCESS FULL KBWYT1 [AN] Ct=11 Cd=2000 Bt=104000 TABLE ACCESS FULL KBWYT2 [AN] Ct=11 Cd=2000 Bt=104000 TABLE ACCESS FULL KBWYT3 [AN] Ct=11 Cd=2000 Bt=104000 FILTER [:Q61000] .
avg(b. The other column shows nothing.max(b. With RBO .dname.Uses cost estimates to determine whether to execute remotely or locally SQL> explain plan for select * from dept@loop_link.Drags everything across the link and joins locally CBO . Remote Queries Only shows remote in the OPERATION column OTHER column shows query executed on remote node OTHER_NODE shows where it is executed Different operational characteristics for RBO & CBO RBO .WORLD] [ANALYZED] In this case the whole query has been sent to the remote site.sal). Query Plan ------------------------------------------------------SELECT STATEMENT REMOTE [CHOOSE] Cost=1 TABLE ACCESS FULL DEPT [SJD. The filter operation indicates this.deptno group by a. emp b where a.sal). Partitions 1 & 4 are eliminated at execution time. SQL> explain plan for select a.avg(b. This query should only return rows from partions 2 & 3. Note that the tables can be accessed in parallel. The union-all partion information indicates that we have recognised this as a partition view. The view line indicates that the view is not merged. KBWYT1-4 contain rows for week 31-34 respectively and are maintained by check constraints.sal) desc.dname order by max(b. Query Plan ----------------------------------------------------SELECT STATEMENT [CHOOSE] Cost=20 SORT ORDER BY [:Q137003] [PARALLEL_TO_SERIAL] SORT GROUP BY [:Q137002] [PARALLEL_TO_PARALLEL] NESTED LOOPS [:Q137001] [PARALLEL_TO_PARALLEL] REMOTE [:Q137000] [PARALLEL_FROM_SERIAL] TABLE ACCESS FULL EMP [:Q137001] [ANALYZED] [PARALLEL_COMBINED_WITH_PARENT] Bind Variables Bind variables are recommended in most cases because they promote sharing of sql code At parse time the parser has NO IDEA what the bind variable contains.deptno=b.TABLE ACCESS FULL KBWYT4 [AN] Ct=11 Cd=2000 Bt=104000 KBWYV1 is a view on 4 tables KBWYT1-4.sal) from dept@loop_link a.
describes the contents of other object_node . / SQL> explain plan for select * from dept where rowid = ':x'. Query Plan -----------------------------------SELECT STATEMENT [CHOOSE] Cost=1 TABLE ACCESS BY ROWID DEPT [ANALYZED] Parallel Query Main indicators that a query is using PQO: [:Q1000004] entries in the explain plan Checkout the other column for details of what the slaves are executing v$pq_slave will show any parallel activity Columns to look in for information other . If parallel_min_percent is set then we error ora 12827 instead of using a lower number of slaves or going serial Consumer processes typically perform a sorting function. When you specify parallel degree 4 oracle tries to allocate 4 producer slaves and 4 consumer slaves. If there is only 1 slave available then we go serial If there are none available then we use serial.contains the query passed to the slaves other_tag . end.indicates order of pqo slaves Parallel Query operates on a producer/consumer basis.this makes no difference but with CBO. which relies on accurate statistics to produce plans. If there are only 2 slaves available then we use these. The producers can feed any of the consumers. assigning values: begin :x := 'hello'. If there is no requirement for the data to be sorted then the consumer slaves are not produced and we end up with the number of slaves used matching the degree of parallelism as opposed to being 2x the degree. Parallel Terms PARALLEL_FROM_SERIAL This means that source of the data is . Defining bind variables in sqlplus: variable x varchar2(18). this can be a problem.
The source of the data is parallel but it is passed to a serial consumer.PARALLEL_TO_PARALLEL PARALLEL_COMBINED_WITH_PARENT PARALELL_TO_SERIAL serial but it is passed to a parallel consumer Both the consumer and the producer are parallel This operation has been combined with the parent operator. Execution Plan #1 (Serial) OBJECT_NAME ------------------------------SELECT STATEMENT SORT ORDER BY SORT GROUP BY MERGE JOIN SORT JOIN TABLE ACCESS FULL emp SORT JOIN TABLE ACCESS FULL dept OBJECT_NODE OTHER ----------. This typically will happen at the top of the explain plan but could occur anywhere Examples of parallel queries Assumptions OPTIMIZER_MODE = CHOOSE DEPT is small compared to EMP DEPT has an index (DEPT_INDX) on deptno column Three examples are presented Query #1: Serial Query #2: Parallel Query #3: Parallel.deptno = B. avg(B.sal). avg(B.sal). with forced optimization to RULE and forced usage of DEPT_INDX Sample Query #1 (Serial) select A.dname order by max(B. max(B.dname.deptno group by A. For example in a sort merge join the sort operations would be shown as PARALLEL_COMBINED_WITH_PARENT because the sort and the merge are handled as 1 operation.------- .sal) desc. emp B where A.sal) from dept A.
sal) from dept A.4) parallel(A.dname order by max(B.------:Q55004 :Q55003 :Q55002 :Q55002 :Q55001 :Q55002 :Q55000 **** **** **** **** **** **** **** -. Execution Plan #2 (Parallel) OBJECT_NAME ------------------------------SELECT STATEMENT Cost = ?? SORT ORDER BY SORT GROUP BY MERGE JOIN SORT JOIN TABLE ACCESS FULL emp SORT JOIN TABLE ACCESS FULL dept Execution Plan #2 **** OBJECT_NODE OTHER ----------. emp B where A.C0 C2 FROM :Q55002 A1 GROUP BY A1.OTHER column (:Q55000) "PARALLEL_FROM_SERIAL" Serial execution of SELECT DEPTNO.4) */ A. AVG(A1. max(B.:Q55000 A2 WHERE A1. avg(B.C0 **** (:Q55003) "PARALLEL_TO_PARALLEL" SELECT MAX(A1.C1 C1 FROM :Q55001 A1.C1 C0.C1) C0. A1.dname.sal).deptno group by A.deptno = B.sal). DNAME FROM DEPT **** (:Q55001) "PARALLEL_TO_PARALLEL" SELECT /*+ ROWID(A1)*/ A1."DEPTNO" C0.C0=A2. A1. avg(B.sal) desc."SAL" C1 FROM "EMP" A1 WHERE ROWID BETWEEN :1 AND :2 **** **** **** (:Q55002) "PARALLEL_COMBINED_WITH_PARENT" (:Q55002) "PARALLEL_COMBINED_WITH_PARENT" (:Q55002) "PARALLEL_TO_PARALLEL" SELECT /*+ ORDERED USE_MERGE(A2)*/ A2.C0 **** (:Q55004) "PARALLEL_FROM_SERIAL" . A1.Notice that the object_node and other columns are empty Sample Query #2 (Query #1 with parallel hints) select /*+ parallel(B.C1) C1.
max(B.C1 DESC Sample Query #3 (Query #2 with fudged hints) select /*+ index(A dept_indx) parallel(B.C0 C2 FROM :Q58000 A1 GROUP BY A1.C0 **** (:Q58002) "PARALLEL_TO_SERIAL" SELECT A1."DEPTNO" = A1.4) parallel(A.sal).dname order by max(B.sal).C1 **** (:Q58001) "PARALLEL_TO_PARALLEL" SELECT MAX(A1.C2 C2 FROM :Q58001 A1 ORDER BY A1.dname.C1 C1.sal) from dept A."DNAME" C0. A3.deptno = B.C0 C0. Execution Plan #3 (Parallel) OBJECT_NAME ----------------------------------SELECT STATEMENT Cost = ?? SORT ORDER BY SORT GROUP BY NESTED LOOPS JOIN TABLE ACCESS FULL emp TABLE ACCESS BY ROWID dept INDEX RANGE SCAN dept_indx Execution Plan #3 **** **** **** **** (:Q58000) (:Q58000) (:Q58000) (:Q58000) -.C0 C1 FROM (SELECT /*+ ROWID(A3) */ A3. avg(B. A1.C1) C0. A1.4) */ A.C0. A1.OTHER column "PARALLEL_COMBINED_WITH_PARENT" "PARALLEL_COMBINED_WITH_PARENT" "PARALLEL_COMBINED_WITH_PARENT" "PARALLEL_TO_PARALLEL" OBJECT_NODE OTHER ----------.CO. A1.------:Q58002 :Q58001 :Q58000 :Q58000 :Q58000 :Q58000 **** **** **** **** **** **** SELECT /*+ ORDERED USE_NL(A2) INDEX(A2) */ A2. A1."SAL" CO.deptno group by A."DEPTNO" C1 FROM "EMP" A3 WHERE ROWID BETWEEN :1 AND :2) A1. A1. A1. "DEPT" A2 WHERE A2.C0 C0.sal) desc.C1 DESC . AVG(A1.C1) C1.C2 C2 FROM :Q55003 A1 ORDER BY A1. emp B where A. avg(B.C1 C1.SELECT A1. A1.
just parses the sql. You can then make a judgement as to any modifications you may choose to make. This means that it executes quickly. Autotrace Autotrace can be configured to run the sql & gives a plan and statistics afterwards or just give you an explain plan without executing the query. In the early stages of tuning explain plan gives you an idea of the potential performance of your query without actually running it.How to obtain explain plans Explain plan for Main advantage is that it does not actually run the query . Tkprof Analyzes trace file .
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.