Subquery factoring and materialize Hint
WITH t AS
(SELECT MAX (lDATE) tidate
FROM rate_Master
WHERE Code = 'G'
AND orno > 0
AND TYPE = 'L'
AND lDATE <= ':entereddate')
SELECT DECODE (:p1, 'B', RateB, 'S', RateS, Rate)
FROM rate_Master, t
WHERE Code = 'G'
AND orno > 0
AND TYPE = 'L'
AND NVL (lDATE, SYSDATE) = tidate;Then add the / * + Materialize * / reference to a query with is required or the optimizer itself will do and perform a transformation of the temporary table. In my example, I have to give the hint in the query. Please discuss and help
Thanks in advance.
ramarun wrote:
WITH t AS (SELECT MAX (lDATE) tidate FROM rate_Master WHERE Code = 'G' AND orno > 0 AND TYPE = 'L' AND lDATE <= ':entereddate') SELECT DECODE (:p1, 'B', RateB, 'S', RateS, Rate) FROM rate_Master, t WHERE Code = 'G' AND orno > 0 AND TYPE = 'L' AND NVL (lDATE, SYSDATE) = tidate;In the example given the sub query returns just one line because of the max aggregate function. This by making a With clause that will be of any benefit? Also I assume / understand that factoring of subquery would be really useful when we try to do a sub query that returns multiple rows in a clause. Is my right to intrepration?
Not quite.
The subquery factoring should be used when you want to use the subquery results more than once in your query. So if you write a regular SQL statement, but find that it is necessary to write the same subquery more than once inside, then you can factor on this subquery using the WITH clause, so that it is executed once, and the results may then be referenced several times in the main query. This is what gives a performance advantage in many cases.
Then add the / * + Materialize * / reference to a query with is required or the optimizer itself will do and perform a transformation of the temporary table. In my example, I have to give the hint in the query. Please discuss and help
As mentioned the suspicion of materialization is not documented so should not be used in production code. Personally, I found that it can add significant performance gain of a weighted subquery where this subquery causes a large amount of data. Don't know why the optimizer is not always materialize subqueries by default but... not really looked inside a lot.
Tags: Database
Similar Questions
-
Subquery factoring and DB Link
Hello
I have a query of the form...2 node RAC Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi PL/SQL Release 10.2.0.5.0 - Production CORE 10.2.0.5.0 Production TNS for Linux: Version 10.2.0.5.0 - Production NLSRTL Version 10.2.0.5.0 - Production
This query used to work, but recently there has been a change of remote_view1, after which the query takes a long time to run.WITH temp as (select col1, col2, col3 from LOCAL_TABLE) SELECT /*+ driving_site (remote1) */ remote1.col1, remote1.col1, remote1.col1, remote1.col1, remote1.col1, remote1.col1, remote2.col1, remote2.col1, remote2.col1, remote2.col1, remote2.col1, null, null from remote_view1@dblink remote1, -- Remote View over 2 dbs remote_view2@dblink remote2 -- Remote View over 2 dbs where remote1.col1 in (select col1 from temp);
The good performing query takes 2 seconds, while providing the wrong one takes about 8 minutes.
However, if I remove the subquery factoring and include the query as a subquery it works well.
I tried to check the data from v$ sql. I saw this;SELECT /*+ driving_site (remote1) */ remote1.col1, remote1.col1, remote1.col1, remote1.col1, remote1.col1, remote1.col1, remote2.col1, remote2.col1, remote2.col1, remote2.col1, remote2.col1, null, null from remote_view1@dblink remote1, -- Remote View over 2 dbs remote_view2@dblink remote2 -- Remote View over 2 dbs where remote1.col1 in (select col1, col2, col3 from LOCAL_TABLE);
v$ SQL. Remote = 'Y' - good performance
v$ SQL. Remote = "n" - poor performance
All the world is facing this situation?
Rgds,
GuenounDo I have reason to assume that the queries executed entirely remote db have plans stored in v$ sql_plan
Right.
SQL> select /*+ domtest */ 1 from dual@domtest; 1 ---------- 1 SQL> select * from table(dbms_xplan.display_cursor); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------------------------- SQL_ID 9d51rf84zvt0s, child number 0 select /*+ domtest */ 1 from dual@domtest NOTE: cannot fetch plan for SQL_ID: 9d51rf84zvt0s, CHILD_NUMBER: 0 Please verify value of SQL_ID and CHILD_NUMBER; It could also be that the plan is no longer in cursor cache (check v$sql_plan) 8 rows selected. SQL> select sql_id, remote, sql_text from v$sql where sql_id = '9d51rf84zvt0s'; SQL_ID R SQL_TEXT ------------- - -------------------------------------------------- 9d51rf84zvt0s Y select /*+ domtest */ 1 from dual@domtest SQL> select * from v$sql_plan where sql_id = '9d51rf84zvt0s'; no rows selected SQL> select /*+ domtest */ 1 from dual@domtest t, dual; 1 ---------- 1 Elapsed: 00:00:00.00 SQL> select * from table(dbms_xplan.display_cursor); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------------- SQL_ID d0m08znks4yak, child number 0 ------------------------------------- select /*+ domtest */ 1 from dual@domtest t, dual Plan hash value: 3754369022 ------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Cost (%CPU)| Time | Inst |IN-OUT| ------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | 4 (100)| | | | | 1 | MERGE JOIN CARTESIAN| | 1 | 4 (0)| 00:00:01 | | | | 2 | REMOTE | DUAL | 1 | 2 (0)| 00:00:01 | DOMTE~ | R->S | | 3 | BUFFER SORT | | 1 | 2 (0)| 00:00:01 | | | | 4 | FAST DUAL | | 1 | 2 (0)| 00:00:01 | | | ------------------------------------------------------------------------------------- Remote SQL Information (identified by operation id): ---------------------------------------------------- 2 - SELECT 0 FROM "DUAL" "T" (accessing 'DOMTEST' ) 22 rows selected. Elapsed: 00:00:00.04 SQL> select sql_id, remote, sql_text from v$sql where sql_id = 'd0m08znks4yak'; SQL_ID R SQL_TEXT ------------- - -------------------------------------------------- d0m08znks4yak N select /*+ domtest */ 1 from dual@domtest t, dua SQL> select /*+ driving_site(t) */ 1 from dual@domtest t, dual; 1 ---------- 1 Elapsed: 00:00:00.00 SQL> select * from table(dbms_xplan.display_cursor); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------- SQL_ID 741u736nrk6dx, child number 0 select /*+ driving_site(t) */ 1 from dual@domtest t, dual NOTE: cannot fetch plan for SQL_ID: 741u736nrk6dx, CHILD_NUMBER: 0 Please verify value of SQL_ID and CHILD_NUMBER; It could also be that the plan is no longer in cursor cache (check v$sql_plan) 8 rows selected. Elapsed: 00:00:00.01 SQL> select sql_id, remote, sql_text from v$sql where sql_id = '741u736nrk6dx'; SQL_ID R SQL_TEXT ------------- - -------------------------------------------------- 741u736nrk6dx Y select /*+ driving_site(t) */ 1 from dual@domtest t, dual Elapsed: 00:00:00.00 SQL> SQL> select * from v$sql_plan where sql_id = '741u736nrk6dx'; no rows selected Elapsed: 00:00:00.01 SQL>Published by: Dom Brooks on August 21, 2012 13:05
-
Subquery factoring clause and the temporary table
Is it possible (probably a hint) to specify the Oracle to create a temporary table in subquery factoring (with...) clause?
So if I have a query
How can I do Oracle to generate a plan that creates a temporary table for t1 (and not using t1 as inline view)?with t1 as (select ...) select ...Hello
use the indicator to materialize:
with t1 as (select /*+ materialize */ ...) select ...Herald tiomela
http://htendam.WordPress.com -
Identify cycles recursive subquery factoring (RSF/CTE)
It is possible to detect cycles AFTER executing a recursive factoring subquery with the cycle_clause.
I need to detect already in the query, similar to the virtual CONNECT_BY_ISCYCLE in a hierarchical query.
Here is a test case of the use of factoring of the recursive subquery (RSF) to the algorithm of Dijkstra shortest Implement path?.
DROP TABLE edges;
CREATE TABLE edges (char (1) src, dst char (1), distance, NUMBER (3, 0));
DROP TABLE nodes.
CREATE TABLE nodes (nodes CHAR (1));
-INSERTION in the edges
-normal direction
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('A', '' B, 2');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('A', 'C', '4');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('A' 'd', '3' ");
INSERT INTO edges (SRC, DST, DISTANCE) VALUES (' B', 'E', 7' ");
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ("C", "E", "3");
INSERT INTO edges (SRC, DST, DISTANCE) VALUES (', 'E', '4');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES (' B', 'F', 4' ");
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('C', 'F', "2");
INSERT INTO edges (SRC, DST, DISTANCE) VALUES (', 'F', '1');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES (' B', 'G', 6' ");
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('C', 'G', "4");
INSERT INTO edges (SRC, DST, DISTANCE) VALUES (', 'G', '5');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('E', 'H', '1');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('F', 'H', '6');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('G', 'H', '3');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('E', 'I', '4');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('F', 'I', '3');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('G', 'I', '3');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('H', 'J', '3');
INSERT INTO edges (SRC, DST, DISTANCE) VALUES ('I', 'J', '4');
-inversion
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('A', '' B, 2');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('A', 'C', '4');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('A' 'd', '3' ");
INSERT INTO edges (DST, SRC, DISTANCE) VALUES (' B', 'E', 7' ");
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ("C", "E", "3");
INSERT INTO edges (DST, SRC, DISTANCE) VALUES (', 'E', '4');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES (' B', 'F', 4' ");
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('C', 'F', "2");
INSERT INTO edges (DST, SRC, DISTANCE) VALUES (', 'F', '1');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES (' B', 'G', 6' ");
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('C', 'G', "4");
INSERT INTO edges (DST, SRC, DISTANCE) VALUES (', 'G', '5');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('E', 'H', '1');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('F', 'H', '6');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('G', 'H', '3');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('E', 'I', '4');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('F', 'I', '3');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('G', 'I', '3');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('H', 'J', '3');
INSERT INTO edges (DST, SRC, DISTANCE) VALUES ('I', 'J', '4');
-SELECT the recursive subquery factoring (RSF) / Common Table Expressions (CTE)
-INCLUDE the starting point of Sub
WITH the railways (root, src, dst, path, distance, cost, lev, iscyc) AS
(SELECT 'A', NULL, 'A', 'A', 0, 0, 1, 0
OF the double
UNION ALL
SELECT p.root,
e.SRC,
e.DST,
p.Path | ',' || e.DST,
e.distance,
p.cost + e.distance,
p.Lev + 1,
-good idea?
p.iscyc
RAILWAYS p
JOIN the edges e WE (e.src = p.dst)
AND lev + 1 < = 3
)
Lev RESEARCH FIRST WIDTH, cost line_no SET
CYCLE of dst SET is_cycle to 1 by DEFAULT 0
SELECT *.
TRAIL pr
WHERE 1 = 1
- AND is_cycle = 0
- AND DST = 'J '.
ORDER BY lev;
DISTANCE FROM ROOT SRC DST LEV ISCY LINE_NO IS_CYCLE COST PATH
-------------------------------------------------------------------
A A A 0 0 1 0 1 0
A A D A,D 3 3 2 0 3 0
A A B A,B 2 2 2 0 2 0
A A C A,C 4 4 2 0 4 0
A C F A,C,F 2 6 3 0 9 0
A E C E A, C, 3 7 3 0 10 0
AN E D A, D, E 4 7 3 0 11 0
B G G, B, 6 8 3 0 12 0
A C AN A, C, 4 8 3 0 13 1
A D G, D, G 5 8 3 0 14 0
G C G, C, 4 8 3 0 15 0
B E A, B, E 7 9 3 0 16 0
A B F A,B,F 4 6 3 0 7 0
A B A A,B,A 2 4 3 0 6 1
A D F A,D,F 1 4 3 0 5 0
A D A A,D,A 3 6 3 0 8 1
There is a powerful way to fill the column ISCY, while the recursion like the IS_CYCLE column?
I tried the table nested in CTE before but had a few questions. The code below works in 11g but not 12 c:
create or replace type nt_char in the table to the varchar2 (20);
/
WITH the railways (root, src, dst, path, distance, cost, lev, iscyc) AS
(SELECT 'A', NULL, 'A', CAST (nt_char ('A') AS nt_char), 0, 0, 1, 0)
OF the double
UNION ALL
SELECT p.root,
e.SRC,
e.DST,
nt_char (e.dst) MULTISET UNION ALL p.Path,
e.distance,
p.cost + e.distance,
p.Lev + 1,
CASE WHEN e.dst MEMBER OF p.path, 1 ELSE 0 END AS iscyc
RAILWAYS p
JOIN the edges e WE (e.src = p.dst)
AND lev + 1<>
)
Lev RESEARCH FIRST WIDTH, cost line_no SET
CYCLE of dst SET is_cycle to 1 by DEFAULT 0
SELECT *.
TRAIL pr
WHERE 1 = 1
- AND is_cycle = 0
- AND DST = 'J '.
ORDER BY lev;
-
Recursive subquery factoring: calculate aggregates
Table T represents a tree. Each record is a node, and each node has only one parent. This query calculates the SUM() of each branch for each node.
WITH T AS (SELECT 1 ID, NULL parent_id, NULL VALUE FROM dual UNION ALL SELECT 10 ID, 1 parent_id, 1000 VALUE FROM dual UNION ALL SELECT 20 ID, 1 parent_id, 2000 VALUE FROM dual UNION ALL SELECT 30 ID, 10 parent_id, 3000 VALUE FROM dual UNION ALL SELECT 40 ID, 10 parent_id, 4000 VALUE FROM dual UNION ALL SELECT 50 ID, 20 parent_id, 5000 VALUE FROM dual UNION ALL SELECT 60 ID, 1 parent_id, 6000 VALUE FROM dual UNION ALL SELECT 70 ID, 60 parent_id, 7000 VALUE FROM dual UNION ALL SELECT 80 ID, 70 parent_id, 8000 VALUE FROM dual ) SELECT CAST(LPAD(' ', (LEVEL-1)*4) || ID AS VARCHAR2(20)) id ,VALUE self_value , (SELECT SUM (VALUE) FROM T t2 CONNECT BY PRIOR t2.ID = t2.parent_id START WITH ID = T.ID) branch_value FROM T CONNECT BY PRIOR t.id = t.parent_id START WITH t.parent_id IS NULL ORDER SIBLINGS BY t.id; ID SELF_VALUE BRANCH_VALUE -------------------- ---------- ------------ 1 36000 10 1000 8000 30 3000 3000 40 4000 4000 20 2000 7000 50 5000 5000 60 6000 21000 70 7000 15000 80 8000 8000 9 rows selected.I tried to reach the same result of this query using the new syntax for subquery factoring. Any help would be really appreciated!
Hello
I think it's one of those things that CONNECT BY is better.
Here's a way to do it using a recursive clause (AND not CONNECT BY):
WITH recursive_results (ancestor_id, descendant_id, value, lvl, lineage) AS
(
SELECT id AS ancestor_id
id LIKE descendant_id
value
, 1 AS lvl
, TO_CHAR (id, "9999") AS line
T
UNION ALL
SELECT r.ancestor_id
t.id AS descendant_id
t.valeur
r.lvl + 1 AS lvl
r.lineage | ' /'
|| To_char (t.id, '9999') AS line
T
JOIN recursive_results r WE t.parent_id = r.descendant_id
)
SELECT LPAD (' ' ')
, 4 * (
SELECT MAX (lvl) - 1
OF recursive_results
WHERE descendant_id = m.ancestor_id
)
) || ancestor_id AS indented_id
SUM (CASE WHEN ancestor_id = descendant_id THEN value END) AS self_value
The amount (value) AS branch_value
OF recursive_results m
GROUP BY ancestor_id
ORDER BY)
SELECT MAX (lineage) DUNGEON (DENSE_RANK LAST ORDER BY lvl)
OF recursive_results
WHERE descendant_id = m.ancestor_id
)
;
Output (even you have):
INDENTED_ID SELF_VALUE BRANCH_VALUE
-------------------- ---------- ------------
1 36000
10-1000-8000
30 3000 3000
40 4000 4000
20-2000-7000
50 5000 5000
60 6000 21000
70-7000-15000
80-8000-8000
-
The recursive subquery factoring vs hierarchical query
Experts,
Here it is two queries, I'm executing using hierarchical of recursive subquery and new classical approach. Problem came out was different for the recursive subquery factoring, as this is not displayed parent-child approach, while forwards connect shows parent-child mode. Query 1, I use hierarchical as show good output parent-child, is approaching the 2 query displays all of the nodes of level 1 and then level 2 nodes. I want the query 2 output to be the same as query 1. change query 2 as required.
Note: the output of the two queries post as in sqlplus and toad. Please copy and use in your command prompt.
QUERY 1:
with the hand in the form (select 1 id, name 'John', null, mgrid Union double all the)
Select 2 id, the name of 'michael', null, mgrid Union double all the
Select 3 id, the name of "peter", null, mgrid Union double all the
Select 4 id, the name of "henry", 1 mgrid Union double all the
Select 5 id, "nickname", mgrid 2 Union double all the
Select 6 id, "pao" name, mgrid 3 of all the double union
Select 7 id, the name of 'kumar', mgrid 3 of all the double union
Select 8 id, the name 'parker', mgrid 3 of all the double union
Select 9 id, the name of "mike", 5 double mgrid),
Select lpad (' ', 2 *(level-1)). name, key start with mgrid level is null connect by prior id = mgrid.
OUTPUT:
LEVEL NAME
------------------------------ ----------
John 1
Henry 2
Michael 1
Nick 2
Mike 3
Stone 1
PAO 2
Kumar 2
Parker 2
9 selected lines.
QUERY 2:
with the hand in the form (select 1 id, name 'John', null, mgrid Union double all the)
Select 2 id, the name of 'michael', null, mgrid Union double all the
Select 3 id, the name of "peter", null, mgrid Union double all the
Select 4 id, the name of "henry", 1 mgrid Union double all the
Select 5 id, "nickname", mgrid 2 Union double all the
Select 6 id, "pao" name, mgrid 3 of all the double union
Select 7 id, the name of 'kumar', mgrid 3 of all the double union
Select 8 id, the name 'parker', mgrid 3 of all the double union
Select 9 id, the name of "mike", 5 double mgrid),
/ * Select lpad (' ', 2 *(level-1)). name, key start with mgrid level is null connect by prior id = mgrid. * /
secmain (id, name, mgrid, hierlevel) as (select id, name, mgrid, 1 hierlevel of the main where mgrid is null
Union of all the
Select m.id, $m.name, m.mgrid, sm.hierlevel + 1 in m main join secmain sm on(m.mgrid=sm.id))
cycle is_cycle set id 1 default 0
Select lpad (' ', 2 *(hierlevel-1)). name, secmain hierlevel.
OUTPUT:
NAME HIERLEVEL
------------------------------ ----------
John 1
Michael 1
Stone 1
Henry 2
Nick 2
Parker 2
Kumar 2
PAO 2
Mike 3
9 selected lines.For example
SQL> with main as(select 1 id,'john' name,null mgrid from dual union all 2 select 2 id,'michael' name,null mgrid from dual union all 3 select 3 id,'peter' name,null mgrid from dual union all 4 select 4 id,'henry' name,1 mgrid from dual union all 5 select 5 id,'nick' name,2 mgrid from dual union all 6 select 6 id,'pao' name,3 mgrid from dual union all 7 select 7 id,'kumar' name,3 mgrid from dual union all 8 select 8 id,'parker' name,3 mgrid from dual union all 9 select 9 id,'mike' name,5 mgrid from dual), 10 secmain (id,name,mgrid,hierlevel) as 11 (select id,name,mgrid,1 hierlevel from main 12 where mgrid is null 13 union all 14 select m.id,m.name,m.mgrid,sm.hierlevel+1 from main m join secmain sm on(m.mgrid=sm.id)) 15 search depth first by name set seq 16 cycle id set is_cycle to 1 default 0 17 select lpad(' ',2*(hierlevel-1))||name name,hierlevel from secmain order by seq; NAME HIERLEVEL ---------- ---------- john 1 henry 2 michael 1 nick 2 mike 3 peter 1 kumar 2 pao 2 parker 2 9 rows selected. SQL>Published by: Dom Brooks on November 23, 2011 13:52
Edited for the scope of the search and detection of cycle -
disadvantages of subquery factoring (with clause)
Hi all
What are disadvantages of subquery factoring (with clause) (if any)?Features have no disadvantages, disadvantages depends on how use you them...
-
ORA-30654: 'missing DEFAULT keyword' in the recursive subquery factoring
The subquery recursive factoring works without clause CYCLE and cycle only.
When I have a cycle (uncomment SELECT 5, 2 double UNON ALL) ORACLE detects the cycle properly, but when I include the clause CYCLE I get ORA-30654.
I'm pretty shure that this statement already worked in my DB (11.2.0.3.0 - 64 bit)
CREATE TABLE temp_rsq (a,b) AS SELECT 1, 2 FROM dual UNION ALL SELECT 2, 3 FROM dual UNION ALL SELECT 3, 4 FROM dual UNION ALL SELECT 4, 5 FROM dual UNION ALL --SELECT 5, 2 FROM dual UNION ALL SELECT 5, 6 FROM dual UNION ALL SELECT 6, 7 FROM dual; -- -- -- b-> new A WITH cte ( pb, a, b, weg) AS (SELECT NULL, a, b, a FROM temp_rsq WHERE a=1 UNION ALL SELECT cte.b, n.a a, n.b, weg+n.a FROM temp_rsq n JOIN cte ON (cte.b=n.a)) SEARCH depth FIRST BY a SET abst --CYCLE a SET is_cycle to '1' DEFAULT '0' SELECT * FROM cte;
Found last al:
It does not with cusor_sharing = FORCE, only with the cursor sharing = TRUE!
For me, a very strange behavior.
-
Subquery Factoring - cardinality estimate good but bad sql response times
This is Exadata 11.2.0.4.0 database, all tables have statistics of up to date. Cardinality estimation is good compared to the actual cardinality. It is a way to tune this sql to reduce its response time.
Sorry for the long sql and the execution plan.
WITH SUBWITH0 AS (SELECT D1.c1 AS c1 FROM ( (SELECT D1.c1 AS c1 FROM (SELECT DISTINCT T7171.CH_ID_SYM AS c1 FROM DW.TM_R_REP T7171 WHERE ( T7171.CHILD_REP_ID = 939 ) ) D1 UNION SELECT D1.c1 AS c1 FROM (SELECT DISTINCT T7167.MEMBER_KEY_SYM AS c1 FROM DW.PC_T_REP T7167 WHERE ( T7167.ANCESTOR_KEY = 939 ) ) D1 ) ) D1 ), SUBWITH1 AS (SELECT D1.c1 AS c1 FROM ( (SELECT D1.c1 AS c1 FROM (SELECT DISTINCT T7171.CH_ID_SYM AS c1 FROM DW.TM_R_REP T7171 WHERE ( T7171.CHILD_REP_ID = 939 ) ) D1 UNION SELECT D1.c1 AS c1 FROM (SELECT DISTINCT T7167.MEMBER_KEY_SYM AS c1 FROM DW.PC_T_REP T7167 WHERE ( T7167.ANCESTOR_KEY = 939 ) ) D1 ) ) D1 ), SUBWITH2 AS (SELECT DISTINCT T7171.CH_ID_SYM AS c1 FROM ( DW.PC_T_REP T7167 LEFT OUTER JOIN DW.TM_R_REP T7171 ON T7167.ANCESTOR_KEY = T7171.CHILD_REP_ID AND T7167.SALESYEARMONTH = T7171.SALES_YEAR_MONTH) LEFT OUTER JOIN DW.TM_REP T6715 ON T7171.CHILD_REP_ID_N = T6715.REP_ID WHERE ( CASE WHEN T7171.CHILD_REP_ID_N LIKE '9999%' THEN concat(concat('UNASSIGNED', lpad(' ', 2)), CAST(T7167.TERRITORY_ID AS VARCHAR ( 20 ) )) ELSE concat(concat(concat(concat(T6715.FIRST_NAME, lpad(' ', 2)), T6715.MIDDLE_NAME), lpad(' ', 2)), T6715.LAST_NAME) END = 'JOES CRAMER' AND T7171.SALES_YEAR_MONTH BETWEEN '201505' AND '201505' AND T7171.CH_ID_SYM IN (SELECT DISTINCT D1.c1 AS c1 FROM SUBWITH0 D1 ) ) ), SUBWITH3 AS (SELECT MEMBER_KEY_SYM AS c1 FROM DW.PC_T_REP T7167 WHERE ( IS_LEAF = 1 ) ), SAWITH0 AS (SELECT DISTINCT CASE WHEN T7171.CHILD_REP_ID_N LIKE '9999%' THEN concat(concat('UNASSIGNED', lpad(' ', 2)), CAST(T7167.TERRITORY_ID AS VARCHAR ( 20 ) )) ELSE concat(concat(concat(concat(T6715.FIRST_NAME, lpad(' ', 2)), T6715.MIDDLE_NAME), lpad(' ', 2)), T6715.LAST_NAME) END AS c1, T6715.REP_NUM AS c2, T7171.SALES_YEAR_MONTH AS c3, T7315.MONTH_NUMERIC AS c4, CASE WHEN T7171.CH_ID_SYM IN (SELECT D1.c1 AS c1 FROM SUBWITH3 D1 ) THEN 1 ELSE 0 END AS c5, CAST(T7171.PARENT_REP_ID AS CHARACTER ( 30 ) ) AS c6, T7171.CH_ID_SYM AS c7, T7171.PARENT_REP_ID_SYM AS c8 FROM DW.TIM_MON T7315 , ( ( DW.PC_T_REP T7167 LEFT OUTER JOIN ( (SELECT TO_NUMBER(TO_CHAR(L_OPP.CloseDate,'YYYYMM')) AS Sales_Year_Month, Tm_Rep.Rep_Id AS Rep_Id, L_OPP.Account_Name__C AS Account_Name__C, L_OPP.Closedate AS Closedate, L_OPP.Forecastcategory AS Forecastcategory, L_OPP.Forecastcategoryname AS Forecastcategoryname, L_User.NAME AS Opp_Owner_S_Sales_Org__C, L_OPP.Opportunity_Id__C AS Opportunity_Id__C, L_OPP.Renewal_Date__C AS Renewal_Date__C, L_OPP.Total_Incremental__C AS Total_Incremental__C, L_OPP.Offer_Code__C AS Offer_Code__C, L_OPP.ID AS Opportunity_ID, L_OPP.TERRITORYID AS TERRITORYID, L_OPP.ACCOUNTID AS ACCOUNTID, L_OPP.OWNERID AS OWNERID, L_OPP.TOTAL_RENEWAL__C AS TOTAL_RENEWAL__C, L_OPP.NAME AS NAME, L_OPP.STAGENAME AS STAGE_NAME, L_OPP.STAGE_DESCRIPTION__C AS STAGE_DESCRIPTION, NVL( CASE WHEN L_OPP.Forecastcategory = 'Closed' AND( OPP_C_DIM.OPPORTUNITIES_GROUP IS NULL ) THEN L_OPP.Total_Incremental__C END , 0) AS Closed_Oppurtunity, CASE WHEN L_OPP.Forecastcategory = 'Closed' AND ( OPP_C_DIM.OPPORTUNITIES_GROUP IS NULL ) THEN 'Closed_Oppurtunity_Drill' END AS Closed_Oppurtunity_Drill, NVL( CASE WHEN L_OPP.Forecastcategoryname IN ('Pipeline', 'Potential', 'Commit') AND ( OPP_C_DIM.OPPORTUNITIES_GROUP IS NULL ) THEN L_OPP.Total_Incremental__C END , 0) AS OPEN_Oppurtunity, CASE WHEN L_OPP.Forecastcategoryname IN ('Pipeline', 'Potential', 'Commit') AND ( OPP_C_DIM.OPPORTUNITIES_GROUP IS NULL ) THEN 'OPEN_Oppurtunity_Drill' END AS OPEN_Oppurtunity_Drill, NVL( CASE WHEN L_OPP.Forecastcategory = 'Closed' AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL1' THEN L_OPP.TOTAL_RENEWAL__C END , 0) AS Renewal_Year1_Closed_Opp, CASE WHEN L_OPP.Forecastcategory = 'Closed' AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL1' THEN 'Renewal_Year1_Closed_Opp_Drill' END AS Renewal_Year1_Closed_Opp_Drill, NVL( CASE WHEN L_OPP.Forecastcategory IN ('Pipeline', 'Forecast', 'BestCase') AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL1' THEN L_OPP.TOTAL_RENEWAL__C END , 0) AS Renewal_Year1_OPEN_Opp, CASE WHEN L_OPP.Forecastcategory IN ('Pipeline', 'Forecast', 'BestCase') AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL1' THEN 'Renewal_Year1_OPEN_Opp_Drill' END AS Renewal_Year1_OPEN_Opp_Drill, NVL( CASE WHEN L_OPP.Forecastcategory = 'Closed' AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL2' THEN L_OPP.TOTAL_RENEWAL__C END , 0) AS Renewal_Year2_Closed_Opp, CASE WHEN L_OPP.Forecastcategory = 'Closed' AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL2' THEN 'Renewal_Year2_Closed_Opp_Drill' END AS Renewal_Year2_Closed_Opp_Drill, NVL( CASE WHEN L_OPP.Forecastcategory IN ('Pipeline', 'Forecast', 'BestCase') AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL2' THEN L_OPP.TOTAL_RENEWAL__C END , 0) AS Renewal_Year2_OPEN_Opp, CASE WHEN L_OPP.Forecastcategory IN ('Pipeline', 'Forecast', 'BestCase') AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL2' THEN 'Renewal_Year2_OPEN_Opp_Drill' END AS Renewal_Year2_OPEN_Opp_Drill FROM DW.OPP_C_DIM RIGHT OUTER JOIN RT.L_OPP ON (TO_CHAR(OPP_C_DIM.OFFER_CODE) =TO_CHAR(L_OPP.Offer_Code__C) AND (TO_CHAR(L_OPP.CloseDate,'YYYYMM')) = TO_CHAR(OPP_C_DIM.PERIOD)) LEFT OUTER JOIN RT.L_User ON (L_OPP.Ownerid=L_User.Id) LEFT OUTER JOIN DW.Tm_Rep ON (Tm_Rep.Rep_Num='0' ||L_User.Rep_Employee_Number__C) )) T774110 ON T7167.MEMBER_KEY = T774110.Rep_Id AND T7167.SALESYEARMONTH = T774110.Sales_Year_Month) LEFT OUTER JOIN DW.TM_R_REP T7171 ON T7167.ANCESTOR_KEY = T7171.CHILD_REP_ID AND T7167.SALESYEARMONTH = T7171.SALES_YEAR_MONTH) LEFT OUTER JOIN DW.TM_REP T6715 ON T7171.CHILD_REP_ID_N = T6715.REP_ID WHERE ( T774110.Sales_Year_Month = T7315.YEAR_MONTH AND T7171.CH_ID_SYM IN (SELECT DISTINCT D1.c1 AS c1 FROM SUBWITH2 D1 ) AND T7171.SALES_YEAR_MONTH BETWEEN '201505' AND '201505' AND T7171.CH_ID_SYM IN (SELECT DISTINCT D1.c1 AS c1 FROM SUBWITH1 D1 ) ) ), SAWITH1 AS (SELECT SUM(T774110.Renewal_Year2_OPEN_Opp) AS c9, SUM(T774110.Renewal_Year2_Closed_Opp) AS c10, SUM(T774110.Renewal_Year1_OPEN_Opp) AS c11, SUM(T774110.Renewal_Year1_Closed_Opp) AS c12, SUM(T774110.OPEN_Oppurtunity) AS c13, SUM(T774110.Closed_Oppurtunity) AS c14, T7315.MONTH_NUMERIC AS c15, T7171.CH_ID_SYM AS c16 FROM DW.TIM_MON T7315 , ( RT.L_ACCOUNT T765190 LEFT OUTER JOIN ( DW.PC_T_REP T7167 LEFT OUTER JOIN ( (SELECT TO_NUMBER(TO_CHAR(L_OPP.CloseDate,'YYYYMM')) AS Sales_Year_Month, Tm_Rep.Rep_Id AS Rep_Id, L_OPP.Account_Name__C AS Account_Name__C, L_OPP.Closedate AS Closedate, L_OPP.Forecastcategory AS Forecastcategory, L_OPP.Forecastcategoryname AS Forecastcategoryname, L_User.NAME AS Opp_Owner_S_Sales_Org__C, L_OPP.Opportunity_Id__C AS Opportunity_Id__C, L_OPP.Renewal_Date__C AS Renewal_Date__C, L_OPP.Total_Incremental__C AS Total_Incremental__C, L_OPP.Offer_Code__C AS Offer_Code__C, L_OPP.ID AS Opportunity_ID, L_OPP.TERRITORYID AS TERRITORYID, L_OPP.ACCOUNTID AS ACCOUNTID, L_OPP.OWNERID AS OWNERID, L_OPP.TOTAL_RENEWAL__C AS TOTAL_RENEWAL__C, L_OPP.NAME AS NAME, L_OPP.STAGENAME AS STAGE_NAME, L_OPP.STAGE_DESCRIPTION__C AS STAGE_DESCRIPTION, NVL( CASE WHEN L_OPP.Forecastcategory = 'Closed' AND( OPP_C_DIM.OPPORTUNITIES_GROUP IS NULL ) THEN L_OPP.Total_Incremental__C END , 0) AS Closed_Oppurtunity, CASE WHEN L_OPP.Forecastcategory = 'Closed' AND ( OPP_C_DIM.OPPORTUNITIES_GROUP IS NULL ) THEN 'Closed_Oppurtunity_Drill' END AS Closed_Oppurtunity_Drill, NVL( CASE WHEN L_OPP.Forecastcategoryname IN ('Pipeline', 'Potential', 'Commit') AND ( OPP_C_DIM.OPPORTUNITIES_GROUP IS NULL ) THEN L_OPP.Total_Incremental__C END , 0) AS OPEN_Oppurtunity, CASE WHEN L_OPP.Forecastcategoryname IN ('Pipeline', 'Potential', 'Commit') AND ( OPP_C_DIM.OPPORTUNITIES_GROUP IS NULL ) THEN 'OPEN_Oppurtunity_Drill' END AS OPEN_Oppurtunity_Drill, NVL( CASE WHEN L_OPP.Forecastcategory = 'Closed' AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL1' THEN L_OPP.TOTAL_RENEWAL__C END , 0) AS Renewal_Year1_Closed_Opp, CASE WHEN L_OPP.Forecastcategory = 'Closed' AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL1' THEN 'Renewal_Year1_Closed_Opp_Drill' END AS Renewal_Year1_Closed_Opp_Drill, NVL( CASE WHEN L_OPP.Forecastcategory IN ('Pipeline', 'Forecast', 'BestCase') AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL1' THEN L_OPP.TOTAL_RENEWAL__C END , 0) AS Renewal_Year1_OPEN_Opp, CASE WHEN L_OPP.Forecastcategory IN ('Pipeline', 'Forecast', 'BestCase') AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL1' THEN 'Renewal_Year1_OPEN_Opp_Drill' END AS Renewal_Year1_OPEN_Opp_Drill, NVL( CASE WHEN L_OPP.Forecastcategory = 'Closed' AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL2' THEN L_OPP.TOTAL_RENEWAL__C END , 0) AS Renewal_Year2_Closed_Opp, CASE WHEN L_OPP.Forecastcategory = 'Closed' AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL2' THEN 'Renewal_Year2_Closed_Opp_Drill' END AS Renewal_Year2_Closed_Opp_Drill, NVL( CASE WHEN L_OPP.Forecastcategory IN ('Pipeline', 'Forecast', 'BestCase') AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL2' THEN L_OPP.TOTAL_RENEWAL__C END , 0) AS Renewal_Year2_OPEN_Opp, CASE WHEN L_OPP.Forecastcategory IN ('Pipeline', 'Forecast', 'BestCase') AND OPP_C_DIM.OPPORTUNITIES_GROUP ='RENEWAL2' THEN 'Renewal_Year2_OPEN_Opp_Drill' END AS Renewal_Year2_OPEN_Opp_Drill FROM DW.OPP_C_DIM RIGHT OUTER JOIN RT.L_OPP ON (TO_CHAR(OPP_C_DIM.OFFER_CODE) =TO_CHAR(L_OPP.Offer_Code__C) AND (TO_CHAR(L_OPP.CloseDate,'YYYYMM')) = TO_CHAR(OPP_C_DIM.PERIOD)) LEFT OUTER JOIN RT.L_User ON (L_OPP.Ownerid=L_User.Id) LEFT OUTER JOIN DW.Tm_Rep ON (Tm_Rep.Rep_Num='0' ||L_User.Rep_Employee_Number__C) )) T774110 ON T7167.MEMBER_KEY = T774110.Rep_Id AND T7167.SALESYEARMONTH = T774110.Sales_Year_Month) ON T765190.ID = T774110.ACCOUNTID) LEFT OUTER JOIN DW.TM_R_REP T7171 ON T7167.ANCESTOR_KEY = T7171.CHILD_REP_ID AND T7167.SALESYEARMONTH = T7171.SALES_YEAR_MONTH WHERE ( T774110.Sales_Year_Month = T7315.YEAR_MONTH AND T7171.CH_ID_SYM IN (SELECT DISTINCT D1.c1 AS c1 FROM SUBWITH2 D1 ) AND T7171.SALES_YEAR_MONTH BETWEEN '201505' AND '201505' AND T7171.CH_ID_SYM IN (SELECT DISTINCT D1.c1 AS c1 FROM SUBWITH1 D1 ) ) GROUP BY T7171.CH_ID_SYM, T7315.MONTH_NUMERIC ) SELECT DISTINCT D2.c9 AS c1, D2.c10 AS c2, D2.c11 AS c3, D2.c12 AS c4, D2.c13 AS c5, D2.c14 AS c6, D1.c1 AS c7, D1.c2 AS c8, D1.c3 AS c9, D1.c4 AS c10, D1.c5 AS c11, D1.c6 AS c12, D1.c7 AS c13, D1.c8 AS c14 FROM SAWITH0 D1 INNER JOIN SAWITH1 D2 ON SYS_OP_MAP_NONNULL(D2.c15) = SYS_OP_MAP_NONNULL(D1.c4) AND SYS_OP_MAP_NONNULL(D2.c16) = SYS_OP_MAP_NONNULL(D1.c7) ORDER BY c10, c13SQL in real time, followed by the details with the Predicate Section of dbms_xplan.display_cursor shot
Global stats
==============================================================================================================================
| Elapsed. CPU | E/S | Request | Cluster | Others | Pick up | Buffer | Read | Read | Write | Write | Cell |
| Time (s) | Time (s) | Waiting (s) | Waiting (s) | Waiting (s) | Waiting (s) | Calls | Gets | Reqs | Bytes | Reqs | Bytes | Unloading |
==============================================================================================================================
| 152. 146. 3.73 | 0.08 | 0.04 | 2.04 | 2. 16 M | 5223. 1 GB | 1. 200KB | 95,11% |
==============================================================================================================================
SQL details surveillance Plan (Plan hash value = 442312180)
===============================================================================================================================================================================================================================================
| ID | Operation | Name | Lines | Cost | Time | Start | Execs | Lines | Read | Read | Cell | MEM | Activity | Activity detail |
| | | | (Estimated) | | Active (s) | Active | | (Real) | Reqs | Bytes | Unloading | (Max) | (%) | (Number of samples).
===============================================================================================================================================================================================================================================
| 0 | SELECT STATEMENT | | | | 1. 152. 1. 0 | | | | | 0.65 | Cpu (1) |
| 1. RANGE OF PARTITION ALL THE | | 1. 3892 | | | 1. | | | | | | |
| 2. ACCESS STORAGE FULL FIRST RANKS TABLE. PC_T_REP | 1. 3892 | | | 37. | 74. 19 MB | 78.45% | 17 M | | |
| 3. TRANSFORMATION OF THE TEMPORARY TABLE. | | | 1. 152. 1. 1. | | | | | |
| 4. LOAD SELECT ACE | | | | 1. + 5 | 1. 1. | | | 278K | | |
| 5. VIEW | | 105. 3980 | 1. + 5 | 1. 13637 | | | | | | |
| 6. SORT UNIQUE | | 105. 3980 | 1. + 5 | 1. 13637 | | | | 757K | | |
| 7. UNION-ALL | | | | 1. + 5 | 1. 14033. | | | | | |
| 8. STORE TABLE FULL ACCESS | TM_R_REP | 22. 88. 1. + 5 | 1. 36. | | | | | |
| 9. RANGE OF PARTITION ALL THE | | 83. 3890. 1. + 5 | 1. 13997. | | | | | |
| 10. STORE TABLE FULL ACCESS | PC_T_REP | 83. 3890. 6. + 0 | 37. 13997. | | | 2 M | 0.65 | Smart cell table scan (1) |
| 11. LOAD SELECT ACE | | | | 1. + 5 | 1. 1. | | | 278K | | |
| 12. HASH UNIQUE | | 1. 4166. 1. + 5 | 1. 1. | | | 479K | | |
| 13. HASH JOIN | | 1. 4165 | 1. + 5 | 1. 444. | | | 1 M | | |
| 14. JOIN FILTER PART CREATE | : BF0000 | 3. 4075 | 1. + 5 | 1. 549. | | | | | |
| 15. OUTER HASH JOIN | | 3. 4075 | 1. + 5 | 1. 549. | | | 1 M | | |
| 16. HASH JOIN | | 3. 4068 | 1. + 5 | 1. 549. | | | 2 M | | |
| 17. VIEW | | 105. 3980 | 1. + 5 | 1. 13637 | | | | | | |
| 18. SORT UNIQUE | | 105. 3980 | 1. + 5 | 1. 13637 | | | | 757K | | |
| 19. UNION-ALL | | | | 1. + 5 | 1. 14033. | | | | | |
| 20. STORE TABLE FULL ACCESS | TM_R_REP | 22. 88. 1. + 5 | 1. 36. | | | | | |
| 21. RANGE OF PARTITION ALL THE | | 83. 3890. 1. + 5 | 1. 13997. | | | | | |
| 22. STORE TABLE FULL ACCESS | PC_T_REP | 83. 3890. 1. + 5 | 37. 13997. | | | 2 M | | |
| 23. STORE TABLE FULL ACCESS | TM_R_REP | 1884 | 88. 1. + 5 | 1. 1929 | | | | | | |
| 24. STORE TABLE FULL ACCESS | TM_REP | 7136 | 7. 1. + 5 | 1. 7137 | | | | | | |
| 25. RANGE OF SINGLE PARTITION | | 7449. 90. 1. + 5 | 1. 7449. | | | | | |
| 26. STORE TABLE FULL ACCESS | PC_T_REP | 7449. 90. 1. + 5 | 1. 7449. | | | | | |
| 27. SORT UNIQUE | | 1. 26032 | 1. 152. 1. 1. | | | 2048 | | |
| 28. OUTER HASH JOIN | | 1. 26031 | 72. + 81 | 1. 8238 | | | | 4 M | | |
| 29. FILTER | | | | 74. + 79 | 1. 8238 | | | | | 1.96 | Cpu (3) |
| 30. NESTED EXTERNAL LOOPS | | 1. 26027 | 72. + 81 | 1. 15 M | | | | | 3.27 | Cpu (5) |
| 31. HASH JOIN | | 1. 26026 | 72. + 81 | 1. 15 M | | | | 447K | 18.95 | Cpu (29) |
| 32. OUTER HASH JOIN | | 1. 13213 | 1. + 81 | 1. 332. | | | 452K | | |
| 33. HASH JOIN | | 1. 13206 | 1. + 81 | 1. 332. | | | 1 M | | |
| 34. HASH JOIN | | 1. 13199. 1. + 81 | 1. 444. | | | 434K | | |
| 35. HASH JOIN | | 1. 13197. 1. + 81 | 1. 444. | | | 290K | | |
| 36. JOIN CREATE FILTER | : BF0000 | 1. 13195. 1. + 81 | 1. 444. | | | | | |
| 37. HASH JOIN | | 1. 13195. 1. + 81 | 1. 444. | | | 2 M | | |
| 38. THE CARTESIAN MERGE JOIN. | 27. 13107 | 1. + 81 | 1. 7449. | | | | | |
| 39. HASH JOIN | | 1. 13017. 77. + 5 | 1. 1. | | | 750K | | |
| 40. STORE TABLE FULL ACCESS | TIM_MON | 1. 4. 1. + 5 | 1. 1. | | | | | |
| 41. VIEW | | 1. 13013. 1. + 81 | 1. 1. | | | | | |
| 42. HASH GROUP BY. | 1. 13013. 1. + 81 | 1. 1. | | | 482K | | |
| 43. OUTER HASH JOIN | | 1. 13012. 77. + 5 | 1. 8238 | | | | 4 M | | |
| 44. NESTED LOOPS | | 1. 13008. 77. + 5 | 1. 8238 | | | | | | |
| 45. FILTER | | | | 77. + 5 | 1. 8238 | | | | | 2.61 | Cpu (4) |
| 46. NESTED EXTERNAL LOOPS | | 1. 13007. 77. + 5 | 1. 15 M | | | | | 4.58. Cpu (7) |
| 47. HASH JOIN | | 1. 13006. 77. + 5 | 1. 15 M | | | | 424K | 11.76. Cpu (18) |
| 48. HASH JOIN | | 1. 193. 1. + 5 | 1. 332. | | | 1 M | | |
| 49. HASH JOIN | | 1. 186. 1. + 5 | 1. 444. | | | 420K | | |
| 50. HASH JOIN | | 4. 184. 1. + 5 | 1. 444. | | | 290K | | |
| 51. JOIN CREATE FILTER | : BF0002 | 1. 94. 1. + 5 | 1. 1. | | | | | |
| 52. JOIN FILTER PART CREATE | : BF0001 | 1. 94. 1. + 5 | 1. 1. | | | | | |
| 53. HASH JOIN | | 1. 94. 1. + 5 | 1. 1. | | | 290K | | |
| 54. JOIN CREATE FILTER | : BF0003 | 1. 6. 1. + 5 | 1. 1. | | | | | |
| 55. THE CARTESIAN MERGE JOIN. | 1. 6. 1. + 5 | 1. 1. | | | | | |
| 56. STORE TABLE FULL ACCESS | TIM_MON | 1. 4. 1. + 5 | 1. 1. | | | | | |
| 57. KIND OF BUFFER. | 1. 2. 1. + 5 | 1. 1. | | | 2048 | | |
| 58. VIEW | VW_NSO_1 | 1. 2. 1. + 5 | 1. 1. | | | | | |
| 59. UNIQUE HASH | | 1. | 1. + 5 | 1. 1. | | | 485K | | |
| 60. VIEW | | 1. 2. 1. + 5 | 1. 1. | | | | | |
| 61. STORE TABLE FULL ACCESS | SYS_TEMP_0FD9D71E1_B445AE36 | 1. 2. 1. + 5 | 1. 1. | | | | | |
| 62. USE OF JOIN FILTER | : BF0003 | 1884 | 88. 1. + 5 | 1. 1. | | | | | |
| 63. STORE TABLE FULL ACCESS | TM_R_REP | 1884 | 88. 1. + 5 | 1. 1. | | | | | |
| 64. USE OF JOIN FILTER | : BF0002 | 7449. 90. 1. + 5 | 1. 444. | | | | | |
| 65. RANGE OF SINGLE PARTITION | | 7449. 90. 5. + 1 | 1. 444. | | | | 0.65 | Cpu (1) |
| 66. STORE TABLE FULL ACCESS | PC_T_REP | 7449. 90. 1. + 5 | 1. 444. | | | | | |
| 67. VIEW | | 105. 2. 1. + 5 | 1. 13637 | | | | | | |
| 68. STORE TABLE FULL ACCESS | SYS_TEMP_0FD9D71E0_B445AE36 | 105. 2. 1. + 5 | 1. 13637 | | | | | | |
| 69. STORE TABLE FULL ACCESS | TM_REP | 7136 | 7. 1. + 5 | 1. 7137 | | | | | | |
| 70. STORE TABLE FULL ACCESS | L_OP | 19382 | 12813 | 77. + 5 | 1. 43879 | 565. 551 MB | 98.18% | 15 M | | |
| 71. TABLE ACCESS BY INDEX ROWID | L_US | 1. 1. 79. + 3 | 15 M | 15 M | 26. 208KO | | | 19.61 | Cpu (30) |
| 72. INDEX UNIQUE SCAN | L_US_PK | 1. | 77. + 5 | 15 M | 15 M | 2. 16384. | | 9 h 15 | Cpu (14) |
| 73. INDEX UNIQUE SCAN | L_A_PK | 1. 1. 151. + 2 | 8238 | 8238 | 3269 | 26 MB | | | 2.61 | Cpu (1) |
| | | | | | | | | | | | | | | monobloc cell physical read (3) |
| 74. STORE TABLE FULL ACCESS | OPP_C_DIM | 2304 | 4. 1. + 81 | 1. 2304 | 3. 112 KB | | | | |
| 75. KIND OF BUFFER. | 7449. 13107 | 1. + 81 | 1. 7449. | | | 370K | | |
| 76. RANGE OF SINGLE PARTITION | | 7449. 90. 1. + 81 | 1. 7449. | | | | | |
| 77. STORE TABLE FULL ACCESS | PC_T_REP | 7449. 90. 1. + 81 | 1. 7449. | | | | | |
| 78. STORE TABLE FULL ACCESS | TM_R_REP | 1884 | 88. 1. + 81 | 1. 1929 | | | | | | |
| 79. VIEW | | 1. 2. 1. + 81 | 1. 1. | | | | | |
| 80. USE OF JOIN FILTER | : BF0000 | 1. 2. 1. + 81 | 1. 1. | | | | | |
| 81. STORE TABLE FULL ACCESS | SYS_TEMP_0FD9D71E1_B445AE36 | 1. 2. 1. + 81 | 1. 1. | | | | | |
| 82. VIEW | | 105. 2. 1. + 81 | 1. 13637 | | | | | | |
| 83. STORE TABLE FULL ACCESS | SYS_TEMP_0FD9D71E0_B445AE36 | 105. 2. 1. + 81 | 1. 13637 | | | | | | |
| 84. STORE TABLE FULL ACCESS | TM_REP | 7136 | 7. 1. + 81 | 1. 7137 | | | | | | |
| 85. STORE TABLE FULL ACCESS | TM_REP | 7136 | 7. 1. + 81 | 1. 7137 | | | | | | |
| 86. STORE TABLE FULL ACCESS | L_OP | 19382 | 12813 | 72. + 81 | 1. 43879 | 593. 577 MB | 98,44% | 15 M | | |
| 87. TABLE ACCESS BY INDEX ROWID | L_US | 1. 1. 72. + 81 | 15 M | 15 M | | | | | 13.73. Cpu (21) |
| 88. INDEX UNIQUE SCAN | L_US_PK | 1. | 73. + 80 | 15 M | 15 M | | | | | 9.80 | Cpu (15) |
| 89. STORE TABLE FULL ACCESS | OPP_C_DIM | 2304 | 4. 1. 152. 1. 2304 | | | | | | |
===============================================================================================================================================================================================================================================
Information of predicates (identified by the operation identity card):
---------------------------------------------------
2. (("MEMBER_KEY_SYM" =: B1 ET "IS_LEAF" = 1) filter)
8 - storage("T7171".") CHILD_REP_ID "= 939)
filter ("T7171". ("CHILD_REP_ID" = 939)
10 - storage("T7167".") ANCESTOR_KEY "= 939)
filter ("T7167". ("ANCESTOR_KEY" = 939)
13 - access("T7167".") SALESYEARMONTH "= 'T7171'." SALES_YEAR_MONTH' AND 'T7167 '. "ANCESTOR_KEY"= "T7171". ("' CHILD_REP_ID")
filter (CASE WHEN TO_CHAR ("T7171". "CHILD_REP_ID_N") AS 9999% ' THEN 'ALL UNASSIGNED' | " CAST ("T7167". ("TERRITORY_ID" AS A VARCHAR (20)) ELSE 'T6715 '. "" NAME "| "
'||" T6715 ". "" MIDDLE_NAME "| " '||" T6715 ". ("" LAST_NAME "END ="JOES CRAMER")
15 - access("T7171".") CHILD_REP_ID_N "= 'T6715'." REP_ID")
16 - access("T7171".") CH_ID_SYM '= 'D1'.' C1")
20 - storage("T7171".") CHILD_REP_ID "= 939)
filter ("T7171". ("CHILD_REP_ID" = 939)
22 - storage("T7167".") ANCESTOR_KEY "= 939)
filter ("T7167". ("ANCESTOR_KEY" = 939)
23 - storage("T7171".") SALES_YEAR_MONTH "= 201505)
filter ("T7171". ("SALES_YEAR_MONTH" = 201505)
26 - storage("T7167".") SALESYEARMONTH "= 201505)
filter ("T7167". ("SALESYEARMONTH" = 201505)
28 - access (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM") = TO_CHAR ("OPP_C_DIM". " PERIOD") AND
TO_CHAR ("OPP_C_DIM". "OFFER_CODE") = "L_OP". ("' OFFER_CODE__C")
29 - filter("TM_REP".") REP_NUM "=" 0"|" » « « « L_US «. » REP_EMPLOYEE_NUMBER__C')
31 - access("T7315".") YEAR_MONTH «= TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP".» CLOSEDATE"),"YYYYMM")) AND
'T7167 '. «SALESYEARMONTH «= TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP".» (((("" CLOSEDATE "),"YYYYMM")))
32 - access("T7171".") CHILD_REP_ID_N "= 'T6715'." REP_ID")
33 - access("T7167".") MEMBER_KEY "=" TM_REP. " ("" REP_ID ")
34 - access("T7171".") CH_ID_SYM '= 'D1'.' C1")
35 - access("T7171".") CH_ID_SYM '= 'D1'.' C1")
37 - access (SYS_OP_MAP_NONNULL ("D2". "C16") = SYS_OP_MAP_NONNULL ("T7171". " CH_ID_SYM") AND"T7167 ". "SALESYEARMONTH"= "T7171". "" SALES_YEAR_MONTH "AND
'T7167 '. "ANCESTOR_KEY"= "T7171". ("' CHILD_REP_ID")
39 - access (SYS_OP_MAP_NONNULL ("D2". "C15") = SYS_OP_MAP_NONNULL ("T7315". " MONTH_NUMERIC'))
40 - storage("T7315".") YEAR_MONTH "= 201505)
filter ("T7315". ("YEAR_MONTH" = 201505)
43 - access (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM") = TO_CHAR ("OPP_C_DIM". " PERIOD") AND
TO_CHAR ("OPP_C_DIM". "OFFER_CODE") = "L_OP". ("' OFFER_CODE__C")
45 - filter("TM_REP".") REP_NUM "=" 0"|" » « « « L_US «. » REP_EMPLOYEE_NUMBER__C')
47 - access("T7315".") YEAR_MONTH «= TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP".» CLOSEDATE"),"YYYYMM")) AND
'T7167 '. «SALESYEARMONTH «= TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP".» (((("" CLOSEDATE "),"YYYYMM")))
48 - access("T7167".") MEMBER_KEY "=" TM_REP. " ("" REP_ID ")
49 - access("T7171".") CH_ID_SYM '= 'D1'.' C1")
50 - access("T7167".") SALESYEARMONTH "= 'T7171'." SALES_YEAR_MONTH' AND 'T7167 '. "ANCESTOR_KEY"= "T7171". ("' CHILD_REP_ID")
53 - access("T7171".") CH_ID_SYM "=" C1")
56 - storage("T7315".") YEAR_MONTH "= 201505)
filter ("T7315". ("YEAR_MONTH" = 201505)
63 - storage (("T7171". "SALES_YEAR_MONTH" = 201505 AND SYS_OP_BLOOM_FILTER (: BF0000, "T7171" ".") CH_ID_SYM')))
filter (("T7171". "SALES_YEAR_MONTH" = 201505 AND SYS_OP_BLOOM_FILTER (: BF0000, "T7171" ".") CH_ID_SYM')))
66 - storage (("T7167". "SALESYEARMONTH" = 201505 AND SYS_OP_BLOOM_FILTER (: BF0000, "T7167" ".") SALESYEARMONTH', 'T7167 '. ((("" ANCESTOR_KEY ")))
filter (("T7167". "SALESYEARMONTH" = 201505 AND SYS_OP_BLOOM_FILTER (: BF0000, "T7167" ".") SALESYEARMONTH', 'T7167 '. ((("" ANCESTOR_KEY ")))
70 - storage ((TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM")) > = 201505 AND "
TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM")) (< = 201505)) "
filter ((TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM")) > = 201505 AND "
TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM")) (< = 201505)) "
72 - access("L_OP".") OWNERID "=" L_US. " (' ' ID ')
73 - access("T765190".") WITH THE ID "=" L_OP. " ("' ACCOUNTID ')
77 - storage("T7167".") SALESYEARMONTH "= 201505)
filter ("T7167". ("SALESYEARMONTH" = 201505)
78 - storage("T7171".") SALES_YEAR_MONTH "= 201505)
filter ("T7171". ("SALES_YEAR_MONTH" = 201505)
81 - storage (SYS_OP_BLOOM_FILTER (: BF0000, "C0"))
filter (SYS_OP_BLOOM_FILTER (: BF0000, "C0"))
86 - storage ((TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM")) > = 201505 AND "
TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM")) (< = 201505)) "
filter ((TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM")) > = 201505 AND "
TO_NUMBER (TO_CHAR (INTERNAL_FUNCTION ("L_OP". "CLOSEDATE"), "YYYYMM")) (< = 201505)) "
88 - access("L_OP".") OWNERID "=" L_US. " (' ' ID ')
Note
-----
-dynamic sample used for this survey (level = 4)
-Automatic DOP: calculated degree of parallelism is 1 because of the parallel threshold
Although the table meet statistical why dynamic sampling is to be used? Why 15 million times ID 71, 72, 87 and 88 are executed, curious because that is where most of the time is spent. How can we reduce this 15 million probes?
Suggestions to reduce the response time sql would be useful.
Post edited by: Yasu masking of sensitive information (literal value)
YASU says:
For educational purposes could you please clarify why the optimizer has evaluated the join condition in the functioning of the FILTER to 15 million lines?
This is unusual, but TM_REP is attached to another PC_T_REP table using a join operation, so maybe it's the explanation of why it is moved to a FILTER operation had been delayed - could also be a side effect of the combination of ANSI join processing (Oracle internally transforms ANSI joins in Oracle join syntax) and the transformation of outer join internally.
Very curious to know how this is possible, could you please give us the hint/tour, you can use to push the inner join down execution plan is evaluated as soon as possible to reduce the data to be processed? I have a sql plus, where the situation is almost similar - ranks of filtering 2 million to the hash JOIN operation and return 0 rows. I can post the details of sql here but not to mix different sql question in the same post. Please let me know if you would like to give the details of this sql in this same thread, or a different thread? I searched for this type of information, but to no avail, so could you please suggest how this is possible, if not for this long sql then at least please provide a few examples/suggestions?
Normally you can influence this through the appropriate join order, for example with the help of the LEADING indicator, for filter indicator PUSH_SUBQ subqueries can also be useful for filtering at the beginning. But here the comment of Franck is particularly important - by leaning on the Cartesian join this problem here should be less relevant.
As I already said I would recommend here from scratch and think that all that this query is supposed to average and the question why most outer joins is actually converted into inner joins - the current query example returns the correct result?
Randolf
-
Behavior of high N lines updated with subquery sessions and parallel
Hello
I have the following scenario:
{code}
SQL > create table aaa12 (date start_time, id1 number (1) Primary key, the number of status)
((1), buffer_id number (2) default null);
Table created.
SQL > insert into aaa12 (the value of start_time, id1, status)
trunc(sysdate-level) select 2, level 6, 1 double
3. connect by level < 6;
5 rows created.
SQL > validation
2;
Validation complete.
SQL > select * from aaa12;
START_TIM STATUS BUFFER_ID ID1
--------- ---------- ---------- ----------
JUNE 10, 13 5 1
JUNE 9, 13 4 1
JUNE 8, 13 3 1
JUNE 7, 13 2 1
JUNE 6, 13 1 1
SQL > update aaa12
2 set buffer_id = 1,
3 status = 2
4 where in (select id1 id1
5 of (select id1
aaa12 6
7 where status = 1
Order 8 by start_time ASC)
9 where rownum < = 2)
10 - and status = 1
11;
2 lines to date.
{code}
Notice that I have not yet commit.
Now on a 2nd session I play the same update, only set buffer_id = 2:
{code}
SQL > update aaa12
2 set buffer_id = 2,
3 status = 2
4 where rowid in (select rowid
5 of (select rowid
aaa12 6
7 where status = 1
Order 8 by start_time ASC)
9 where rownum < = 2)
10 - and status = 1
11;
{code}
Expectations of update above (locked). Now let's commit the 1st session:
{code}
Validation complete.
SQL > select * from aaa12;
START_TIM STATUS BUFFER_ID ID1
--------- ---------- ---------- ----------
JUNE 10, 13 5 1
JUNE 9, 13 4 1
JUNE 8, 13 3 1
JUNE 7, 13 2 2 1
JUNE 6, 13 1 2 1
SQL >
{code}
and we'll see what happened during the 2nd session:
{code}
2 lines to date.
SQL >-after 1st session committed
SQL > select * from aaa12;
START_TIM STATUS BUFFER_ID ID1
--------- ---------- ---------- ----------
JUNE 10, 13 5 1
JUNE 9, 13 4 1
JUNE 8, 13 3 1
JUNE 7, 13 2 2 2
JUNE 6, 13 1 2 2
SQL >
{code}
It updated the same lines, even if their status should no longer be 1 committed after 1st session.
I guess what happens is that the subquery is performed on the time of execution of the update statement - which means that the subquery is read so coherent to reinstate the same lines.
but now if I do the same thing, but a comment the external status = 1 as part of the where the update in addition to the subquery - it seems to work:
I dropped the table, recreated, inserted the same 5 lines and now start the new updates:
{code}
SQL > update aaa12
2 set buffer_id = 1,
3 status = 2
4 where in (select id1 id1
5 of (select id1
aaa12 6
7 where status = 1
Order 8 by start_time ASC)
9 where rownum < = 2)
10 and status = 1
11;
2 lines to date.
SQL > select * from aaa12;
START_TIM STATUS BUFFER_ID ID1
--------- ---------- ---------- ----------
JUNE 10, 13 5 1
JUNE 9, 13 4 1
JUNE 8, 13 3 1
JUNE 7, 13 2 2 1
JUNE 6, 13 1 2 1
{code}
updated even with buffer_id = 2 on 2nd session:
{code}
SQL > update aaa12
2 set buffer_id = 2,
3 status = 2
4 where rowid in (select rowid
5 of (select rowid
aaa12 6
7 where status = 1
Order 8 by start_time ASC)
9 where rownum < = 2)
10 and status = 1
11;
{code}
session is locked, now after commit 1st session - session 2 updated and table looks like:
{code}
2 lines to date.
SQL > select * from aaa12;
START_TIM STATUS BUFFER_ID ID1
--------- ---------- ---------- ----------
JUNE 10, 13 5 1
JUNE 9, 13 4 2 2
JUNE 8, 13 3 2 2
JUNE 7, 13 2 2 1
JUNE 6, 13 1 2 1
{code}
I have 2 questions:
1. How is the 2nd scenario works and the subquery does not limit the update for the same 2 lines so that the update will update anything?
2 in case I have a table with many rows and I need to process the records in order, but want to do it in parallel - if I have 1000 lines of process and each session can handle 500 - I don't want to wait for the other, but work on different lines simultaneously. Is this possible without having to open a cursor with a SELECT... UPDATE SKIP LOCKED? because then I would have more than 500 lines of loop and do an update by records, which seems unwise to good performance.
Any help/advice would be appreciated.
Thank you
-Mor
Sorry, I missed a major difference between the two cases. And it's write consistency. There are some situations where UPDATE or DELETE are realizing that they cannot maintain consistency of statement-level and are forced to do a restore 'mini' (which may not be so "tiny") and start over. One of these cases is as follows. We have a UPDATE/DELETE with a WHERE clause. So we start to extract the rows that match WHERE clause. And we meet a line whose value to adapt the WHERE clause when statement has started now, but it is not. And that's exactly what is happening here. When the session 2 publishes the UPDATED session 1 did not err again. As a result, lines of June 6 & 7 correspond to the WHERE clause and must therefore be updated. However, they are locked by session 1. When the session commits 1, locks are released and session 2 could proceed with the updating of these two lines. However, to write rules of coherence mandate session 2 to check if WHERE clause is always true and realize that it's not. This causes a mini-restauration and UPDATE again. Now sinus session already committed 1, session 2 sees all of the changes and lines of June 6 & 7 do not match WHERE clause more (status = 2). So first of all (by START_TIM) two rows with STATUS = 1 are now June 8 & 9. That is why the session 2 updates the.
SY.
-
Legend of failure and legends Hint
When I record in Captivate 4 on Windows XP, the legend of failure or hint captions do not display upwards. It also does not show my mouse movements. I tried to change the settings and options, but nothing seems to work. Any help is appreciated!
Hi again
When you click on Simulation software, you have a few options. Demonstration, evaluation and Simulation of training Simulation. Demo mode will only provide the movements of the mouse. Only Simulation modes offer the legends of suspicion. FMR will enable the registration of the mouse, but you can't later to change.
In regards to the legends of the trick, SEE it only actually once that you have saved in simulation mode and reading in a preview or output has published. The indicator shows when you hover over the image map.
Does that help?
See you soon... Rick
Useful and practical links
Captivate wish form/Bug report form
-
I forgot my Windows Vista password and the hint.
I forgot my windows vista password and the answer to the clue. I tried many options, but it does not work... I don't have any what administrator, I'm onlu user.
I don't have a bootable CD or anything at HP. Can someone help me as soon as possible.
Hello
Microsoft technical support engineers cannot help you recover the passwords of the files and Microsoft who are lost or forgotten product features. For more information about this policy, please refer to the sticky below.http://social.answers.Microsoft.com/forums/en-us/vistasecurity/thread/3eba3150-8742-4264-be9f-0daaad2282cd Aaron
Microsoft Answers Support Engineer
Visit our Microsoft answers feedback Forum and let us know what you think -
diff bw parallel and noparallel hint
Hello
What is the difference between PARALLEL and NOPARALLEL during the creation of the index?
Thank you very muchHello
PARALLEL (DEGREE DEFAULT DEFAULT INSTANCES);
Default value used when you do not specify that the value is taken from the @instance level.
-Pavan Kumar N
Oracle 9i / 10g - OCP
http://oracleinternals.blogspot.com/ -
Subquery 'WITH SAWITH0 AS' OBIEE 11 g factoring clause contained in the generated sql code
I have observed that OBIEE 11 g generates in physics request log query using the (subquery factoring) WITH clause to the generated sql code elegantly readable. It's great! Thanks for the developers. However I have a few questions about it.
__Background__
Oracle database ' default behavior is that if you have only a subquery in the section, it runs as a perspective in line and he not materialized before the main sql is running. If you have more than one default database engine materializes all the in the order of definition. In some cases, it can completely blow up the SGA and make a query without end. To divert this behavior, you can apply two tips that work both in inline views in subqueries as well: / * + MATERIALIZE * / and / * + INLINE * /, however Analytics 11 g does not seem to have capabilities of Board at the table level logical, only at the level of the physical table.
If we go with the current default settings, the developers do not know this feature can fall on serious performance problems for the sake of a few sweets of syntax to the generated sql level, I'm afraid.
__Questions__
* It is possible to turn the Analytics Server to not use WITH but views inline instead?
* Is it possible to sneak in a few boards that would the / * + INLINE * / allusion to the proper place in the subqueries generated if necessary
* Is the Oracle database has any initialization parameter that can influence the behavior of this subquery factoring and divert by default?The WITH statement is not added to make the query more elegant, it is added for performance reasons. If your queries slow to run, then you can have a design problem. In a typical DWH DB SGA should be increased seriously given that ran queries are much larger and complex than on an OLTP DB. In all cases, you can disable the WITH statement in the administration tool by double clicking on your database on the physical layer from object in the features tab. The function is called WITH_CLAUSE_SUPPORTED.
-
Factoring in memory a subquery?
Welcome.
I have question about subquery factoring (and global temporary tables in general).
I ran track query:
with s as (SELECT / * + cardinality (gen 100000) * / ROWNUM OF TABLE n (rowgen (100000)) gen)
Select count (1) in s
Union of all the
Select count (1) in s.
Display statistics for this query about 1245184 bytes for the "bytes total physical reading" and "physical write total bytes"-nearly 12 bytes for each record, which suggests this subquery to oracle (s) disk write and then read it. Explain the plan show that Oracle uses CONVERSION TABLE TEMP. My understanding is that oracle creates a global temporary table that is stored in temporary tablespace, where the use of the disc.
I wonder why Oracle keep the subquery results in memory? Is there a suspicion to convince Oracle to use memory.
More general question is if I can force oracle to keep global temporary tables in memory?
If not, I guess that PL/SQL collections are the closest to the concept of in-memory table?
My question is a bit for education, so please do not ask me why I need GTT
Best regards
PawelMore general question is if I can force oracle to keep global temporary tables in memory?
This feature is not supported with TWG
SQL> create global temporary table 2 results_temp (name varchar2(10)) 3 on commit preserve rows 4 storage (buffer_pool keep); create global temporary table * ERROR at line 1: ORA-14451: unsupported feature with temporary table SQL>If not, I guess that PL/SQL collections are the closest to the concept of in-memory table?
Yes (from session specific data storage and manipulation of perspective).
Maybe you are looking for
-
HP Pavilion ZX5000 recovery download
I own a HP Pavilion ZX5000 and I want it back, but I lost the CD to do so. Y at - it a downloadable version, I could get? If so please respond with a DL link.
-
Deploy shared in the installer Variablie
I'm having a problem with a variable shared in my application. This application is integrated with a Setup program must be installed on a machine without labview. After looking around, I came across this link and think it is close to what I need.
-
On My Space, I can't watch/listen to the music streaming video and is similarly on YouTube. The problem is persistent in all media streaming. Videos open, play for a few seconds, then start buffering again. Why (?) How can this be fixed (?)
-
Problem by opening a window and with Solitaire game.
Original title: problem with the function To open a window, I need to click several times before opening. With Solitaire game, for tool to move a card is almost impossible, because it flies right back to its place of origin. Except that my Windows 7
-
ze5185 & usb 2.0 PCMCIA card
I have a Pavilion ze5185 notebook. I'm sure that all usb ports are 1.1 because of their performance and the age of the computer. I want to buy a Dynex PCMCIA usb 2.0 card that my computer will have a high speed usb port/s. Is it possible to know i