Dynamic sampling on TWG
Hi, we have a situation where dynamic sampling was not implemented for tables of TWG for subsequent executions - I have a session that connects to the database and inserts 10000 records in the TWG and executes a sql using the TWG. optimizer generates a plan based on 10000 records by sampling dynamically and this plan is good for this volume. Now in the same session I truncate the TWG and insert 10 records and then run the SQL, but I still see the same plan is used and found a further analysis that the lines of e-lines of the second race is 10000 and not 10.
Here is the output of the xplans (paste only the proper line) - first line
----------------------------------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Begins | E - lines. A - lines. A - time | Pads | OMem | 1Mem | Used Mem.
----------------------------------------------------------------------------------------------------------------------------------------------------------
| 7. TABLE ACCESS FULL | GTT_ARMA_INSTR_CURRENT_DIM | 1. 10010 | 10010 | 00:00:00.01 | 24 | | | |
| 7. TABLE ACCESS FULL | GTT_ARMA_INSTR_CURRENT_DIM | 1. 10010 | 10. 00:00:00.01 | 3 | | | | -Why not e-lines 10 when in fact it has 10 records.
Dynamic sampling is confirmed to be used at a time-
-dynamic sample used for this survey (level = 4)
It's the way it is supposed to work.
You the sample when optimize you - which usually happens on the first run, and must not be repeated unless the cursor is invalidated.
The plan on the second race WAS generated by sampling, but it is the plan was generated by sampling in the first inning.
Concerning
Jonathan Lewis
Tags: Database
Similar Questions
-
ORA-10173: time-out of dynamic sampling error: application of OBIEE 11 g
Hello
Application: OBIEE 11g
Database: Oracle Database Enterprise Edition Release 12.1.0.2.0 - 64 bit Production 12 c
The following alert was generated for the purposes of OBIEE 11 g database.
ORA-10173: time-out of dynamic sampling error:
When I google it finds that there is no resolution except that raise to Oracle.
Anyone experienced the same and any resulting resolution already?
Enjoy the you entries.
Thank you
HESH
Thanks Christian, I'll close this thread and open a new forum of the database.
-
11.2.3 Oracle dynamic sampling works is not on table with locked statistics, NULL
I work in a development environment where the statistics are locked for all schemas. Some of these table objects have had their statistics unlocked and collected manually. We have the level of dynamic sampling set to 4.
When I perform queries on this particular scheme, I can say that dynamic sampling isn't being run because I do not see any other session running in the OEM other than my request.
Any ideas?
You can check the level of dynamic sampling of the plan by querying V$ SQL_PLAN. Column OTHER_XML. For example:
11.2.0.3 ...4 3346460612... Also this info is printed according to dbms_xplan.display_cursor (). For example:
Select * from table (dbms_xplan.display_cursor('79y5x009ytcav',1));
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------
SQL_ID, 79y5x009ytcav, number of children 1
-------------------------------------
Select count (*) from...
...
Note
-----
- dynamic sample used for this survey (= level 4)
Post edited by: Mihael
-
Hi all
I am executing a SELECT statement and underlyig table is a partitioned table that does not have any available statistics.
When I ask the execution of that plan SQL, I found that SMAPLING DYNAMICS is carried out.
I'm on 10.2.0.3 on solaris 5.8
FYI...
Kind regardsSQL> explain plan for 2 SELECT /*+ INDEX ( bba BBO_PRICING_LOCAL_IDX ) */ TICKER||' '||EXCH_CODE , EXCH_CODE , TICKER , ID_ISIN , PX_LAST , PX_VOLUME , CRNCY , ID_MIC_PRIM_EXCH , CUR_MKT_CAP ,EQY_SH_OUT FROM EQHUB.BBO_PRICING_ARC BBA WHERE START_DATE <= :B1 AND END_DATE > :B1; Explained. select * from table(dbms_xplan.display()); Plan hash value: 1872597311 ---------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | ---------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 164K| 25M| 477 (5)| 00:00:06 | | | | 1 | PARTITION RANGE ITERATOR | | 164K| 25M| 477 (5)| 00:00:06 | 1 | KEY | | 2 | TABLE ACCESS BY LOCAL INDEX ROWID| BBO_PRICING_ARC | 164K| 25M| 477 (5)| 00:00:06 | 1 | KEY | |* 3 | INDEX RANGE SCAN | BBO_PRICING_LOCAL_IDX | 5314 | | 32 (69)| 00:00:01 | 1 | KEY | ---------------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - access("END_DATE">:B1 AND "START_DATE"<=:B1) filter("END_DATE">:B1) Note ----- - dynamic sampling used for this statement select owner,table_name,num_rows,blocks,LAST_ANALYZED FROM DBA_TABLES WHERE TABLE_NAME='BBO_PRICING_ARC' OWNER TABLE_NAME NUM_ROWS BLOCKS LAST_ANALYZED ------------------------------ ------------------------------ ---------- ---------- ------------------ EQHUB BBO_PRICING_ARC I have also checked index stats and they are NULL too.
Kim DesaiBhavik Desai wrote:
... and underlyig table is a partitioned table that does not have any available statistics...You pretty much answered your own question.
Check out the docs, it clearly explains what dynamic sampling will be used: [how dynamic sampling works | http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/stats.htm#sthref1108]
-
Level 3: Apply dynamic sampling to all tables that meet the criteria for level 2, as well as all the tables for which the standard selectivity estimate used a conjecture for a predicate that is a predicate of potential dynamic sampling. The number of blocks sampled is the number of dynamic blocks of default sampling. For tables not analyzed, the sampled number of blocks is twice the default number of blocks of dynamic sampling.
all tables for which one used standard selectivity estimation more conjecture for a predicate that is a predicate of potential dynamic sampling.
can you explain what dose this statement means, can you give me an example? {: 8}Jinyu wrote:
all tables for which one used standard selectivity estimation more conjecture for a predicate that is a predicate of potential dynamic sampling.
can you explain what dose this statement means, can you give me an example? {: 8}Potential for dynamic sampling predicate is a predicate to filter on a single table, not a join predicate which are now out of reach for dynamic sampling.
An assumption of the optimizer could be based on a complex expression for which the optimizer can only guess a cardinality (e.g. "COLX + 2 * COLY > 10 ' and there is no hidden column based on a function index/virtual corresponding to this expression), or for example a PL/SQL function call user defined.
Kind regards
RandolfOracle related blog stuff:
http://Oracle-Randolf.blogspot.com/SQLTools ++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676 /.
http://sourceforge.NET/projects/SQLT-pp/ -
of the instance-level (level 4) dynamic sampling works not
When I put dynamic_sampling (level 4) as an allusion to a question, I see its effect and a good plan with lines estimated very close to reality. The response of the application in this case is 4 to 7 minutes
But when I put dynamic sampling (level 4) at the instance-level or session, the query plan is the same as when he dynamic sampling is at level 2 (default). The response time for this setting is close to 20 minutes.
The two plans to end tell 'dynamic used sampling!
I want to effectively put optimizer_dynamic_sampling = 4 at the instance level. Anyone know what I can do to make this work?
Thank you
JCRead the manuals carefully.
As a system or session parameter or when it is used as an indicator without reference to a table, level 4:32 blocks for each table that has two or more predicates, or a single predicate requiring Oracle to use a default selectivity. (Or if a table has no stats - in which case the sample is of 64 blocks).As an indicator of level table (which is how you referred to the two tables), level 4 is a unconditional sample of 256 blocks of the specified table.
If your samples are completely different in both cases - and the larger sample size gets you a better plan. I think you would have to use the system or the session 7 level to get the size of the same sample at the level of the table 4.
If you run the queries with the event 10053 set, you will be able to view the comments in the trace file on targeted sampling that takes place and a report on the number of blocks and the number of blocks actually sampled.
Concerning
Jonathan Lewis
http://jonathanlewis.WordPress.com
http://www.jlcomp.demon.co.UK"The saddest aspect of life is this moment that science gathers knowledge faster that society gathers wisdom."
Isaac Asimov -
dynamic variables, sampling and bind
Hello
dynamic_sampling is used to link the variable? why he doesn't get good cardinality with lie?
When you use literals, I see that dynamic sampling occurs and get good cardinality.
When you use links (without his stats on tables), I see that dynamic sampling occurs but the cradinality is the same as without dynamic sampling.
is dynamic sampling not work well with lie?
ZvikaHi Zvika,
Why in the last selected is not using dynamic sampling?
Because you put text in your meter, I suppose.
Try something like:
select /*+ dynamic_sampling(z1_t 4) */ * , 'this is hard parse' from z1_t where flag1 = :x and flag2 = :x;In addition to the autotrace setting, you might want to trace your tests using the:
SQL> alter session set events '10053 trace name context forever, level 1'; -- your queries etc... SQL> alter session set events '10053 trace name context off';See what you find in the .trc file, as and post results/questions here.
Or use this approach, another way to see more:
http://asktom.Oracle.com/pls/asktom/f?p=100:11:0:P11_QUESTION_ID:963818400346843003
(scroll down to the "explain plan does not link peek, explain plan optimizes for '? '-part")Also: what is your version of DB?
(When I have time later today, I'll try to implement a similar testcase). -
Hello
I was doing a test of calculation amount of redo generated for sorting (disc) in the global temporary table.
Version: Oracle 10203 on Solaris 9
The trace, it was found that redosize is 0. However, v $ mystat, I get a different figure.SQL> select a.name,b.value from v$statname a,v$mystat b where a.statistic# = b.statistic# and a.name = 'redo size'; NAME VALUE ---------------------------------------------------------------- ---------- redo size 0 SQL> create global temporary table gtt on commit preserve rows as select * from dba_objects; Table created. SQL> insert into gtt select * from gtt; 11500 rows created. SQL> / 23000 rows created. SQL> / 46000 rows created. SQL> / 92000 rows created. SQL> / 184000 rows created. SQL> / 368000 rows created. SQL> / 736000 rows created. SQL> / 1472000 rows created. SQL> commit; Commit complete. SQL> select a.name,b.value from v$statname a,v$mystat b where a.statistic# = b.statistic# and a.name = 'redo size'; NAME VALUE ---------------------------------------------------------------- ---------- redo size 10640528 SQL> set autotrace traceonly; SQL> select * from gtt order by 1,2,3,4,5,6,7,8,9; 2944000 rows selected. Execution Plan ---------------------------------------------------------- Plan hash value: 2609089896 -------------------------------------------------------------------------------- --- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | -------------------------------------------------------------------------------- --- | 0 | SELECT STATEMENT | | 3432K| 579M| | 92372 (2)| 00:21:3 4 | | 1 | SORT ORDER BY | | 3432K| 579M| 1375M| 92372 (2)| 00:21:3 4 | | 2 | TABLE ACCESS FULL| GTT | 3432K| 579M| | 8682 (3)| 00:02:0 2 | -------------------------------------------------------------------------------- --- Note ----- - 'PLAN_TABLE' is old version - dynamic sampling used for this statement Statistics ---------------------------------------------------------- 300 recursive calls 27 db block gets 36579 consistent gets 26681 physical reads 0 redo size 54149123 bytes sent via SQL*Net to client 2159414 bytes received via SQL*Net from client 196268 SQL*Net roundtrips to/from client 0 sorts (memory) 1 sorts (disk) 2944000 rows processed SQL> set autotrace off; SQL> select a.name,b.value from v$statname a,v$mystat b where a.statistic# = b.statistic# and a.name = 'redo size'; NAME VALUE ---------------------------------------------------------------- ---------- redo size 10643572 SQL>
I wonder why it reports a difference of 3044 (10643572-10640528) between repeat sizes before and after so that trace shows size 0 redo.
Not sure which one is true. Could you please help?
-AravindHi Jonathan,.
"Not quite true - changes to the TWG generate none again, but they don't generate cancel, and changes to the undo blocks are protected by redo." But it is quite irrelevant in this case. »
(1) what exactly I wanted to understand in detail. Infact, it was one of the reasons why I took the test. Could you please share how can we understand how much of this recovery could be attributed to cancel?
(2) Yes, track must also be creating some redo to plan tables.
(3) thanks for the tip PLAN_TABLE. I dropped the old version and installed a new one with catplan.sql
Aravind
-
dynamics of sampling all executions or each hard analysis?
Hello
Let's say that we are on the last 11.2.0.3.5, and for some, no parallel queries oracle is using sampling dynamic level (default) 2.
How do you think, dynamic sampling used for all executions (even with the same query / same plane) or only if we parse hard duing, and
no dynamic sampling with soft parsed (no hard analysis generally).
Concerning
GregGDynamic sampling circumvents the shareable model sql has simply sampling during the difficult analysis.
-
variation on the question of "dynamic list".
A developer has created a function (for another application) which takes an input string and separates these values according to a delimiter specified, back spitting results in their own ranks. For example:
becomesSELECT string_split FROM table(shared.shared_pg.string_split_tab ( 'TD8001,TD8002,TD8003',','));
So I started to think maybe I could use it in a SQL (run from PL/SQL), then I could pass in a string of values delimited by commas to a procedure/function and easily integrate it in a SQL statement, so that I could use bind variables. It works:STRING_SPLIT ----------------------------- TD8001 TD8002 TD8003 3 rows selected.
But I am unable to get the optimizer to use the underlying index on prg.prg_nm. I tried several rewrites SQL without resultSELECT * FROM prg WHERE prg_nm IN (SELECT string_split FROM table(shared.shared_pg.string_split_tab ( 'TD8001,TD8002,TD8003',',')))
It is a potential rewrite that I'm missing?select prg.* from prg, (select string_split from table(shared.shared_pg.string_split_tab('TD8001,TD8002,TD8003',','))) inline_view where prg.prg_nm = inline_view.string_split; ---------------------------------------------------------- select * from prg where prg_nm in ( SELECT string_split FROM ( SELECT string_split FROM table(shared.shared_pg.string_split_tab ( 'TD8001,TD8002,TD8003', ',' )) ORDER BY 1)); ---------------------------------------------------------- WITH inline_view AS (SELECT string_split FROM table(shared.shared_pg.string_split_tab ( 'TD8001,TD8002,TD8003',','))) SELECT prg.* FROM prg, inline_view WHERE prg.prg_nm = inline_view.string_split;
version of DB 10.1.0.4
-= ChuckYou can use the indicator of cardinality on the virtual table to specify the number of rows, the function returns, as by default, the optimizer evaluates approximately eight thousand rows to return. It doesn't have to be exact just more close to the actual number of eight thousand, say ten or twenty.
Re: VARRAY bind parameter in clause results in Full Table Scan
I think dynamic sampling is the new way of doing, but I was not able to operate also reliable.
Published by: useless on June 1st, 2009 17:00
Also it seems sometimes to add a condition extra rownum to the select function as rownum > 0 as described here.
http://asktom.Oracle.com/pls/asktom/f?p=100:11:0:P11_QUESTION_ID:3779680732446 #15740265481549,
-
bunch of table temporary organized vs table for organizing data
We use the Oracle 10 g on Linux platform.
We have an intermediate table where the data read from the file (containing 1 million rows per day) is loaded, enriched(insert/update/delete) and then finally load in the table of another. I want to know if this table is a global temporary table or normal heap organized to reduce the generation of undo/redo.
I'm not in favor of the temporary table because:
1. any additional pressure on the temporary tablespace can cause ORA-01652: unable to extend temp segment temporary problems
2. they are mainly intended to manipulate specific session data.
3 - statistics do not exist for these work Oracle tables. To do this, we will have to do a dynamic sampling in the query.
The problem with the table organized in piles is that they generate more undo/redo as temporary tables.
Please guide me.>
We have an intermediate table where the data read from the file (containing 1 million rows per day) is loaded, enriched(insert/update/delete) and then finally load in the table of another. I want to know if this table is a global temporary table or normal heap organized to reduce the generation of undo/redo.I'm not in favor of the temporary table because:
1. any additional pressure on the temporary tablespace can cause ORA-01652: unable to extend temp segment temporary problems
2. they are mainly intended to manipulate specific session data.
3 - statistics do not exist for these work Oracle tables. To do this, we will have to do a dynamic sampling in the query.The problem with the table organized in piles is that they generate more undo/redo as temporary tables.
>
Some of you concerns can easily be mitigated.1 - temp tablespace
A common practice for ETL processing to create and use a temporary tablespace customized to use TWG. This prevents the TWG of impacting on the standard temp space and possibly interfere with the rest of the DB.
See "Creating a temporary Table" in the DBA Guide. This article has sample code that illustrates this.
http://docs.Oracle.com/CD/B28359_01/server.111/b28310/tables003.htm#i1006400
>
By default, rows in a temporary table is stored in the temporary tablespace default of the user who creates it. However, you can assign a temporary table to a different tablespace when creating the temporary table by using the TABLESPACE in CREATE TABLE of TEMPORARY GLOBAL clause. You can use this feature to save the space used by temporary tables. For example, if you need to perform many operations of small temporary table and the default temporary tablespace is configured for sort operations and uses so a large measure, these small operations consume a lot of unnecessary disk space. In this case, it is best to assign a tablespace temporary second with a smaller measure.
>
#2 (planned for the session-specific data processing) is correct, that they have the specific session data. But GTT can also be used simply to reduce the amount of REDO normal DML operations during the processing of data which are already isolated from other users and does not need to be shared.
>
3 - statistics do not exist for these work Oracle tables. To do this, we will have to do a dynamic sampling in the query.
>
Sure - but a working Oracle generally does not collect statistics whenever you do DML on your staging table. And if you do stats new TRUNCATE/LOAD operations should gather anyway once you load the new data.You may not have considered one of the factors are that you should design your architecture to be scalable. It is quite possible that you have only a SINGLE step and your current treatment is very simple.
If so AND you do not need an evolutionary process, so the solution suggested by knani, maybe the best solution for you. But this solution is not very scalable.
Complext ETL implementations have several steps. And the data still does not move between these steps in one nice, easy step. It is a common requirement that after each stage of data processing can must be discussed or reported on make sure you that he satisfied all the requirements of the company. Then data problems (e.g. lack of data, incorrect, etc.) must be resolved before the data can be processed to the next step. Depending on the severity of the problems that step may need to be rerun.
If only the TWG is used there is no way to "review" the data. And if ONLY the external tables are used, then you can not tables of several process efficient in parallel and asynchronously.
Complex implementations that I worked on usually consisted of a range of external and normal tables and TWG.
External tables and one step simple "data cleansing" are used to load data into tables normal as soon as possible. That allows multiple processes to run asynchronously and in parallel for the detection of problems of data 'stored' as much as possible. Any table can be reloaded/processed without affecting other processes.
This suggests that your first step should knapen processes in place do the same "serial" cleaning possible.
The second stage of ETL, when necessary, can perform cleanup of more complex data for data in a table or several tables. TWG can be effectively used here to store the intermediate results that may have large amounts of 'temporary' DML performed on the data. At the end of this stage the TWG data would be transferred to another table of result or permanent staging.
Start with a simple one-step process (maybe Karthicks). The key is to avoid complicating the process in a way that makes it impassable.
-
boards of opt_estimate in the merge of refresh operations quick mview
Hello
in a system (Oracle 11 g Enterprise Edition Release 11.2.0.2.0 - 64 bit Production database) I'm trying to optimize, there are materialized views with "fast refresh on commit" and there are many queries to the following distribution:
/ * MV_REFRESH (MRG) * / MERGE INTO "XXX". "" WITH THE HELP OF YYY "" SNA$ ' (SELECT / * + OPT_ESTIMATE (QUERY_BLOCK MAX = 485387) * /...)
"As far as I can see the queries show the structure explained in Alberto Dell's Oracle blog'Era ' quick refreshment of only materialized aggregate views with SUM - algorithm (in the section" Refresh for mixed-DML TMPDLT") - the best resource on refresh mview algorithms I know. But I could not find information on the setting of the OPT_ESTIMATE indicator. In the database, I see that the values in the indicator are changing:
Select st.sql_id
, substr (st.sql_text, instr (st.sql_text, 'OPT_ESTIMATE'), 40) sql_text
St dba_hist_sqltext
where st.sql_text like ' / * MV_REFRESH (MRG) * / MERGE INTO "XXX". » YYY » %'
and...
SQL_ID SQL_TEXT
------------- ----------------------------------------
6by5cwg0v6zaf OPT_ESTIMATE (QUERY_BLOCK MAX = 485387) *.
2b5rth5uxmaa2 OPT_ESTIMATE (QUERY_BLOCK MAX = 485387) *.
4kqc15tb2hvut OPT_ESTIMATE (QUERY_BLOCK MAX = 490174) *.
fyp1rn4qvxcdb OPT_ESTIMATE (QUERY_BLOCK MAX = 490174) *.
a5drp0m9wt53k OPT_ESTIMATE (QUERY_BLOCK MAX = 407399) *.
2dcmwg992pjaz OPT_ESTIMATE (QUERY_BLOCK MAX = 485272) *.
971zzvq5bdkx6 OPT_ESTIMATE (QUERY_BLOCK MAX = 493572) *.
46434kbmudkq7 OPT_ESTIMATE (QUERY_BLOCK MAX = 493572) *.
4ukc8yj73a3h3 OPT_ESTIMATE (QUERY_BLOCK MAX = 491807) *.
8k46kpy4zvy96 OPT_ESTIMATE (QUERY_BLOCK MAX = 491807) *.
3h1n5db3vdugt OPT_ESTIMATE (QUERY_BLOCK MAX = 493547) *.
5340ukdznyqr6 OPT_ESTIMATE (QUERY_BLOCK MAX = 493547) *.
7fxhdph8ymyz8 OPT_ESTIMATE (QUERY_BLOCK MAX = 407399) *.
15f3st5gdvwp3 OPT_ESTIMATE (QUERY_BLOCK MAX = 491007) *.
083ntxzh8wnhg OPT_ESTIMATE (QUERY_BLOCK MAX = 491007) *.
cg17yjx3qay5z OPT_ESTIMATE (QUERY_BLOCK MAX = 491452) *.
5qt37uzwrwkgw OPT_ESTIMATE (QUERY_BLOCK MAX = 491452) *.
byzfcg7vvj859 OPT_ESTIMATE (QUERY_BLOCK MAX = 485272) *.
aqtdpak3636y5 OPT_ESTIMATE (QUERY_BLOCK MAX = 493572) *.
dcrkruvsgpz3u OPT_ESTIMATE (QUERY_BLOCK MAX = 492226) *.
7mmt5px6sd7xg OPT_ESTIMATE (QUERY_BLOCK MAX = 492226) *.
9c6v714pbjvc0 OPT_ESTIMATE (QUERY_BLOCK MAX = 485336) *.
fbpsz02yq2qxv OPT_ESTIMATE (QUERY_BLOCK MAX = 485336) *.
0q04g2rh9j84y OPT_ESTIMATE (QUERY_BLOCK MAX = 491217) *.
gp3u5d5702dpb OPT_ESTIMATE (QUERY_BLOCK MAX = 491638) *.
9f35swtju24aa OPT_ESTIMATE (QUERY_BLOCK MAX = 491638) *.
a70jwxnrxtfjn OPT_ESTIMATE (QUERY_BLOCK MAX = 491217) *.
93mbf02cjq2ny OPT_ESTIMATE (QUERY_BLOCK MAX = 491217) *.
Then of course the cardinalities in the OPT_ESTIMATE indication are not static here and the sql_id of foreign exchange as a result. And this change prevents me from using the basic lines of sql plan to gurantee a stable path (essentially to avoid the parallel operations for refresh, well operations that Parallels access for queries do not prevent). I did a quick check with 11.2.0.1 and see the same model here:
drop materialized view t_mv;
drop table t;
create table t
as
Select rownum id
, mod (rownum, 50) col1
, mod (rownum, 10) col2
, lpad ('* ', 50,' *') col3
of the double
connect by level < = 100000;
exec dbms_stats.gather_table_stats (user, 't')
Create materialized view log on t with rowid (id, col1, col2, col3) including the new values;
Create materialized view t_mv
quickly refresh on validation
as
Select col1
sum (col2) sum_col2
count (*) NTC
count (col2) cnt_col2
t
Col1 group;
Update t set col2 = 0 where col1 = 1;
commit;
SQL_ID, 4gnafjwyvs79v, number of children 0
-------------------------------------
/ * MV_REFRESH (MRG) * / MERGE IN 'TEST '. "" T_MV ""$SNA"WITH THE HELP OF SELECT (SELECT
/ * + OPT_ESTIMATE (QUERY_BLOCK MAX = 1000) * / "DLT$ 0. "" COL1 ""GB0. "
SUM (DECODE ("DLT$ 0". "DML$ $"(, 'I', 1,-1) * DECODE ("DLT ($0". " ("" COL2 ").
(NULL, 0, 1)) 'D0', SUM (DECODE ("DLT$ 0". "DML$ $"(, 'I', 1,-1)) 'D1', "
NVL (SUM (DECODE ("DLT$ 0". "DML$ $"(, 'I', 1,-1) * ("DLT$ 0". " ((("" COL2 ")), 0)
'D2' FROM (SELECT CHARTOROWID (' MAS$ ".)) ("' M_ROW$ $') RID$,.
"MAS$". " "COL1", "MAS$". "' COL2 ', DECODE (" MAS$ ".) OLD_NEW$ $, 'N', ' (I ' 'd').
DML$ $, "MAS$". "" DMLTYPE$ $"" DMLTYPE$ $', 'TEST '. "" MLOG$ _T "" MAS$ ".
WHERE "MAS$". XID$ $ =: 1) 'DLT$ 0' GROUP BY 'DLT$ 0. ("' COL1 ')" AV$ "ON
(SYS_OP_MAP_NONNULL ("SNA$".)) ("' COL1 ') = SYS_OP_MAP_NONNULL (" AV$ ".) (("" GB0 '))
WHEN MATCHED THEN UPDATE SET "SNA$". "CNT_COL2"= "$SNA". «CNT_COL2 "+" AV$ ".»
'D0', '$SNA '. "CNT"= "$SNA". «CNT "+" AV$ ".» "' D1 ',.
"SNA$". " SUM_COL2 "= DECODE (" SNA$ "". ")" CNT_COL2 "+" AV$ ".» D0', 0, NULL, NVL ("SNA$".)
("SUM_COL2", 0) + AV$ «» ("' D2 ') DELETE WHERE (" SNA$ ".) ("' CNT ' = 0) IS NOT
MATCHED THEN INSERT ("SNA$".) "" COL1 ","$SNA ". "" CNT_COL2 ","$SNA ". "" CNT ",.
Hash value of plan: 2085662248
-----------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
-----------------------------------------------------------------------------------
| 0 | MERGE STATEMENT | | | | 24 (100) | |
| 1. MERGE | T_MV | | | | |
| 2. VIEW | | | | | |
|* 3 | OUTER HASH JOIN | | 40. 4640 | 24 (9) | 00:00:01 |
| 4. VIEW | | 40. 2080. 20 (5) | 00:00:01 |
| 5. GROUP SORT BY | | 40. 1640 | 20 (5) | 00:00:01 |
|* 6 | TABLE ACCESS FULL | MLOG$ _T | 40. 1640 | 19 (0) | 00:00:01 |
| 7. MAT_VIEW FULL ACCESS | T_MV | 50. 3200 | 3 (0) | 00:00:01 |
-----------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
3 - access (SYS_OP_MAP_NONNULL ("SNA$".)) ("' COL1 ') = SYS_OP_MAP_NONNULL (" AV$ ".) "G
B0'))
6 - filter("MAS$".") XID$ $"(=:1)"
Note
-----
-dynamic sample used for this survey (level = 2)
So I see an OPT_ESTIMATE (QUERY_BLOCK MAX = 1000) and this estimate seems to be fairly stable when I change the number of lines, number of blocks, use partitioning etc. I checked a trace with Event 10046 but didn't source the value 1000. I also disabled the comments of cardinality ("_optimizer_use_feedback" = false) and there is no profile sql in my system (according to dba_sql_profiles) - but the OPT_ESTIMATE is still there.
So the question is: is there something known about values used in the OPT_ESTIMATE indication for the materialized view fast refresh operations? Thanks in advance for your contributions.
Concerning
Martin Preiss
Martin Preiss wrote:
In regard to point 1: initially as a partitioned table starting with K 1000 lines, then 100K, then 10K, I created my test T table (using my old example of Blog Oracle MP: Materialized View Fast refresh): in all cases, I got OPT_ESTIMATE (QUERY_BLOCK MAX = 1000). My first problem in this context is that I did not come with a model showing different OPT_ESTIMATE values - as I see them in the prod system.
Using the sql Profiler and the force_match option looks promising - I'll check if I can use them here.
Concerning
Martin
Hi Martin,
but perhaps the OPT_ESTIMATE indicator is based on stats of the MLOG or MV table, where my question. Since this is the option to 'MAX' of OPT_ESTIMATE (limit the maximum number of rows for this query block) the 1000 resembles 'low' default value is used if the stats are missing or the MLOG / MV table less than 1000 lines?
Randolf
-
index_join by the rowid of the table?
Let's say you have a table like
(t)
int ID1,
ID2 int,
varchar (4000) textColumn1,.
varchar (4000) textColumn2,.
varchar (4000) textColumn3
)
And you have the index of individual columns on ID1 and ID2; composite index. In my situation, I can't create an index composite (ID1, ID2). But if I understand correctly, internally that both indices ID1 and ID2 are arranged as:
Id1.1 rowid.3
Id1.2 rowid.2
Id1.3 rowid.4
Id1.4 rowid.1
Id2.1 rowid.1
Id2.2 rowid.2
Id2.3 rowid.3
Id2.4 rowid.4
So, if you did
Select ID1 in t
where ID2 > 2;
A theoretically possible implementation plan would be to open the index the ID2 and ID1, find the ROWID for ID2, coincide with those against the ROWID in ID1, then pull the ID1 values directly from the index. But any advice I launch in, (as index_join(), index(), opt_param ('_index_join_enabled', true) opt_param('optimizer_index_cost_adj',1), etc., he don't y no plan that never presented that does not open the table.) And that's a problem because the table is actually quite massive and full of large columns. So do a scatter read through the massive tablespace for this table is so much more expensive that just read the two indexes, even in their entirety.
So is there a restriction that prevents pull the index values ID1, that has something to do with the insulation or missing/transaction null values or something? Did I miss an optimization to make it work, or Oracle (11.2.0.4, I think) ever implementation of an index_join across two indexes to single column?
It works for me in 12.1.0.2 if I do the column you want to select NOT NULL. This makes sense because otherwise the rowid would not appear in the index (although I don't see why that just cannot be interpreted as NULL). This also works if you filter nulls.
SQL > create table t_1 (id1 number, id2 number, colonne_1 varchar2 (4000));
Table created.
SQL > create index t_1_idx_01 on t_1 (id1);
The index is created.
SQL > create index t_1_idx_02 on t_1 (id2);
The index is created.
SQL > explain the plan for
2 Select / * + INDEX_JOIN (t t_1_idx_01) INDEX_JOIN (t_1_idx_02 t) * / id2 t_1 t where id1 =: X;He explained.
SQL > @x
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------
Hash value of plan: 4181077581--------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
--------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 26. 1 (0) | 00:00:01 |
| 1. TABLE ACCESS BY ROWID INDEX BATCH | T_1 | 1. 26. 1 (0) | 00:00:01 |
|* 2 | INDEX RANGE SCAN | T_1_IDX_01 | 1. | 1 (0) | 00:00:01 |
--------------------------------------------------------------------------------------------------Information of predicates (identified by the operation identity card):
---------------------------------------------------2 - access ('ID1' = TO_NUMBER (:X))
Note
-----
-the dynamic statistics used: dynamic sampling (level = 2)18 selected lines.
SQL > alter table t_1 change id2 not null;
Modified table.
SQL > explain the plan for
2 Select / * + INDEX_JOIN (t t_1_idx_01) INDEX_JOIN (t_1_idx_02 t) * / id2 t_1 t where id1 =: X;He explained.
SQL > @x
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------
Hash value of plan: 1085250311-------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
-------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 26. 2 (0) | 00:00:01 |
|* 1 | VIEW | the index $ _join$ _001. 1. 26. 2 (0) | 00:00:01 |
|* 2 | HASH JOIN | | | | | |
|* 3 | INDEX RANGE SCAN | T_1_IDX_01 | 1. 26. 1 (0) | 00:00:01 |
| 4. FULL RESTRICTED INDEX SCAN FAST | T_1_IDX_02 | 1. 26. 1 (0) | 00:00:01 |
-------------------------------------------------------------------------------------------Information of predicates (identified by the operation identity card):
---------------------------------------------------1 Filter ('ID1' = TO_NUMBER (:X))
2 - access (ROWID = ROWID)
3 - access ('ID1' = TO_NUMBER (:X))Note
-----
-the dynamic statistics used: dynamic sampling (level = 2)22 selected lines.
SQL > alter table t_1 change id2 null;
Modified table.
SQL > explain the plan for
2 Select / * + INDEX_JOIN (t t_1_idx_01) INDEX_JOIN (t_1_idx_02 t) * / id2 t_1 t where id1 =: X and id2 is not null;He explained.
SQL > @x
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 1085250311-------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
-------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 26. 2 (0) | 00:00:01 |
|* 1 | VIEW | the index $ _join$ _001. 1. 26. 2 (0) | 00:00:01 |
|* 2 | HASH JOIN | | | | | |
|* 3 | INDEX RANGE SCAN | T_1_IDX_01 | 1. 26. 1 (0) | 00:00:01 |
|* 4 | FULL RESTRICTED INDEX SCAN FAST | T_1_IDX_02 | 1. 26. 1 (0) | 00:00:01 |
-------------------------------------------------------------------------------------------Information of predicates (identified by the operation identity card):
---------------------------------------------------1 Filter ('ID1' = TO_NUMBER (:X))
2 - access (ROWID = ROWID)
3 - access ('ID1' = TO_NUMBER (:X))
4 - filter ("ID2" IS NOT NULL)Note
-----
-the dynamic statistics used: dynamic sampling (level = 2)23 selected lines.
Your columns of text are very large, what is your block size? Under the value by default 8 k blocks, if your lines are completely filled while they are chained, and readings by rowid will be additional i/o. Consider measures to avoid migration of line and row chaining. In my view, this could be the reason for your index access is so slow.
Have a read of https://docs.oracle.com/database/121/TGDBA/pfgrf_instance_tune.htm#TGDBA024 10.2.4.3 Table Fetch by row continues to see the impact and ways to circumvent migrated/chained rows.
If you select a large number of rows in the table the issue would become so what do you intend to do with so many? Is it possible that you could reduce the number of lines you choose?
-
physical_read_requests > disk_reads
Hello
I was wondering about sqls in v$ sql where physical_read_requests vs disk_reads.
I know when instead it is likely reading diluvium, but I'm trying to understand some SQLs I see with, for example, 900 k physical_read_requests and disk 4 bed.Query your database for:
select sql_id, disk_reads, physical_read_requests from v$sql where physical_read_requests > disk_reads / SQL_ID DISK_READS PHYSICAL_READ_REQUESTS ------------- ---------- ---------------------- fd9qbhuy1hgrx 0 14 2xucgknahj256 167 181 934ur8r7tqbjx 1 15 934ur8r7tqbjx 0 7 fpvps147hqh7g 1 8 89p81j073yhv8 26 40 akj15bfw7ypt4 41 48 bn4b3vjw2mj3u 0 35
Any clue?Salman Qureshi says:
I here speculates that if even block (for which a physical read request is issued to a SQL), some other SQL/session could also have requested a physical read (and a reading of disc) - occupied buffer waiting happen also. This disc has played for this sql would not increase (because the data has already been read form the disc at the request of the other sql/session). So in this case, physical_read_request for this SQL has increased, but not disk_read.
Good idea, but I don't think it should work like that.
The second session who wanted to read the block would be the cache buffers chains get found block one buffer that takes this block pinned exclusively in the State "be read from disk", so do not try to read it, so should not change either of the two stats. (He makes a good point that the session not next - but it's out of scope for this thread.)
I've been speculating in the sense of an instrumentation error - a task update a single statistic, but not the other. The possibilities include:
readings for dynamic sampling
readings of global temporary tables
readings of materialized "with" subqueries
readings of tablespace temp for mergers of sorts/axe/bitmap
journey live readings
readings of the flash cache
Exadata ' no data not necessary "read the applications
However, a much simpler explanation is that not all the readings are bed data block, so eventually the counties (for example) physical_read_requests controlfile read requests while disk_reads number just blocks to read data files. Try this:
SQL > select disk_reads, physical_read_requests, sql_text from v$ sql where sql_id = "adnu4f081dhar";
DISK_READS PHYSICAL_READ_REQUESTS SQL_TEXT
---------- ---------------------- --------------------------------------------------------------------------------
0 28 select current_scn in the database of v$
SQL > select current_scn from v$ database;
CURRENT_SCN
-----------
1.2670E + 13
SQL > select disk_reads, physical_read_requests, sql_text from v$ sql where sql_id = "adnu4f081dhar";
DISK_READS PHYSICAL_READ_REQUESTS SQL_TEXT
---------- ---------------------- --------------------------------------------------------------------------------
0 35 select current_scn in the database of v$
SQL > select current_scn from v$ database;
CURRENT_SCN
-----------
1.2670E + 13
SQL > select disk_reads, physical_read_requests, sql_text from v$ sql where sql_id = "adnu4f081dhar";
DISK_READS PHYSICAL_READ_REQUESTS SQL_TEXT
---------- ---------------------- --------------------------------------------------------------------------------
0 42 select current_scn in the database of v$
The declaration card 7 physical_read_requests and not disk_reads on each execution and at the same time I see 7 waits 'control file sequential read '.
Concerning
Jonathan Lewis
-
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
Maybe you are looking for
-
Peux I installed iOS 10 from my iPad to my iPhone6 or my PowerbookPro? Or 10 doesn't automatically do that? Doubt it!
-
Help with the older file types
Technical question for all my fellow Mac geeks. I am trying to open Zip OLD files. Here is a picture of the gadget that back, we then used to store their and a screen shot of what the files as now when I open the drive of the back then. When I try to
-
Sleep on the keyboard button no longer works after a remote session with a technician
original title: sleep function button on the keyboard function sleep and sleep in Start menu stopped working after that technical support trying to solve a problem without report with via remote access. How to make the sleep button/function to work?
-
Anyone who uses the MusexPress Pages for CMS?
I was wondering what the experience has been with someone try the MusexPress CMS. Pros and cons before you buy the number of members.Thank you!
-
in the query and parent/child relationship
WITH the data AS(SELECT '213NY1' lfrom, NULL, '215ZVD' mi lto, "215ZV9 ' id, 1 January 2014' sdate, January 2, 2014' edate, 3 January, 2014 'mdate' January 5, 2014 medate double UNION ALL.Lfrom SELECT NULL, '215ZVD' mi, id "213NY1", "215ZV9" lto 4 Ja