Pruning
Hello Experts,
I built a query on a multiprovider that has 11 cubes.
I have to see if my query is using the pruning logic or not. So I went and ran my query in RSRT and there I dont know what options should I check to see ,if given a particular year and version combination if my query is going only to the cube required.
I already have the config table built where it says for sepcific version and year combination a particular cube needs to be used.
Please help me out with a solution.
Thanks
Lakshmi
Follow up.
I looked into using the Lines property and also leveraging the text selection methods of the text box. I found the following two methods to work:
txtCon.Text = txtCon.Text.Substring(txtCon.Text.IndexOf("READY.", Convert.ToInt32(txtCon.TextLength * .7)) + 8);
and
txtCon.Text = txtCon.Text.Remove(0, txtCon.Text.IndexOf("READY.", Convert.ToInt32(txtCon.TextLength * .7)) + 8);
In the above examples "READY." is the prompt. I keep everything after this text.
Here I am testing removing 70% of the text box contents, a small change from the 80% I mentioned in my original post.
I am tending towards using the remove function guessing that it might be more efficient. I welcome any corrections or alternative ideas :-) Saga
You can't take the sky from me
Similar Messages
-
[Oracle 8i] Need help pruning branches from a hierarchical query
My problem is that my hierarchical query seems only to trim out the values that don't meet my criteria, but still includes their children. When my query hits a record that does not meet my criteria, I want it to stop there. I've tried including the criteria in just the 'where' clause of the query, and have also put the criteria in the 'connect by' clause as well, but nothing has fixed it. Please keep in mind I'm using Oracle 8i, so I can't use some of the 'nicer' statements for hierarchical queries that they introduced in 9. I'm stuck with 'Start With...Connect By'.
I have sample tables/data that I can post if someone needs to see that to help me, but to start with, here's my current query:
SELECT *
FROM (
SELECT
LEVEL
, c_bill.comp_part_nbr AS c_part_nbr
, (select c_part.part_desc
FROM part c_part
WHERE c_part.part_nbr=c_bill.comp_part_nbr) AS c_part_desc
, (SELECT c_part.part_type
FROM part c_part
WHERE c_part.part_nbr=c_bill.comp_part_nbr) AS c_part_type
, c_bill.qty_per AS c_qty_per_p
, c_bill.qty_per_type AS c_qty_per_type
, (SELECT c_part.qty_on_hand
FROM part c_part
WHERE c_part.part_nbr=c_bill.comp_part_nbr) AS c_qty_on_hand
, c_bill.oper_nbr AS rqd_at_op
, c_bill.comp_off_adj AS rqd_offset
, c_bill.bom_doc_nbr AS p_part_nbr
, (SELECT p_part.qty_on_hand
FROM part p_part
WHERE p_part.part_nbr=c_bill.bom_doc_nbr) AS p_qty_on_hand
FROM
BILL c_bill
WHERE
(c_bill.status = 'RL')
AND (c_bill.view_code IN ('M','G'))
AND (c_bill.end_eff_dt > SYSDATE)
AND (c_bill.begn_eff_dt <= SYSDATE)
START WITH c_bill.bom_doc_nbr=RPAD(?,25)
CONNECT BY PRIOR c_bill.comp_part_nbr=c_bill.bom_doc_nbr
AND c_bill.view_code IN ('M','G')
AND c_bill.status = 'RL'
AND c_bill.end_eff_dt > SYSDATE
AND c_bill.begn_eff_dt <= SYSDATE
) a
WHERE c_part_type = 'M'The outside criterion of part_type='M' isn't my problem. Where I'm actually seeing my issue rear its ugly head is in the criterion:
(c_bill.view_code IN ('M','G'))What I'll have happen is that one of the children or grandchildren of the part number I'm querying for (my parameter), will be of some view code that's not 'M' or 'G'. In my sample data below, I have a level 4 part that is part of the 'H' view code, which I don't want, nor do I want it's children. However, its child is in the 'G' view code, and my query returns it anyway.
In my sample data below, I'm assuming that the parameter = 'XYZ-100'
CREATE TABLE part
part_nbr varchar(25) not null,
part_desc varchar(25) not null,
part_type char(1) not null,
qty_on_hand double(13,4) not null
CONSTRAINT part_pk
PRIMARY KEY (part_nbr),
CONSTRAINT check_part_type
CHECK (part_type IN ('M','P','X','Y')),
CONSTRAINT check_qty_on_hand
CHECK (qty_on_hand >= 0)
CREATE TABLE bill
row_added_ts char(20) not null,
bom_doc_nbr varchar(25) not null,
comp_part_nbr varchar(25) not null,
qty_per double(9,5) not null,
qty_per_type char(1) not null,
oper_nbr char(4) not null,
comp_off_adj double(3,0),
status char(2),
view_code char(1) not null,
end_eff_dt date() not null,
begn_eff_dt date() not null
CONSTRAINT bill_pk
PRIMARY KEY (row_added_ts),
CONSTRAINT check_qty_per_type
CHECK (qty_per_type IN ('0','1','2','3')),
CONSTRAINT check_status
CHECK (status IN ('IN', 'RL')),
); Values for those tables:
INSERT INTO part
VALUES ('xyz-1', 'purchased part', 'P', 5);
INSERT INTO part
VALUES ('xyz-2', 'purchased part', 'P', 1);
INSERT INTO part
VALUES ('xyz-3', 'purchased part', 'P', 1);
INSERT INTO part
VALUES ('xyz-3a', 'manufactured part', 'M', 1);
INSERT INTO part
VALUES ('xyz-4', 'purchased part', 'P', 1);
INSERT INTO part
VALUES ('xyz-9-1', 'manufactured part', 'M', 0);
INSERT INTO part
VALUES ('xyz-9a', 'manufactured part', 'M', 0);
INSERT INTO part
VALUES ('raw-1', 'purchased raw material', 'P', 212);
INSERT INTO part
VALUES ('raw-2', 'purchased raw material', 'P', 75.5);
INSERT INTO part
VALUES ('XYZ-100', 'manufactured part', 'M', 0);
INSERT INTO part
VALUES ('(OPEN)', '(not in use)', 'Y', 0);
INSERT INTO part
VALUES ('XYZ-100-1', 'manufactured part', 'M', 0);
INSERT INTO part
VALUES ('XYZ-100-2', 'manufactured part', 'M', 1);
INSERT INTO part
VALUES ('XYZ-100-3', 'manufactured part', 'M', 0);
INSERT INTO part
VALUES ('XYZ-100-4', 'manufactured part', 'M', 2);
INSERT INTO part
VALUES ('XYZ-100-A', 'manufactured part', 'M', 0);
INSERT INTO bill
VALUES ('2008072153100150000','XYZ-100','xyz-1',3,'1','****',0,'RL','M','01-Jan-2050','01-Jan-1900');
INSERT INTO bill
VALUES ('2008072153100150000','XYZ-100','XYZ-100-1',1,'1','****',0,'RL','M','01-Jan-2050','01-Jan-1900');
INSERT INTO bill
VALUES ('2008072153100150000','XYZ-100-1','xyz-1',2,'1','****',1,'RL','M','01-Jan-2050','01-Jan-1900');
INSERT INTO bill
VALUES ('2008072153100150000','XYZ-100-1','XYZ-100-2',3,'1','****',0,'RL','M','01-Jan-2050','01-Jan-1900');
INSERT INTO bill
VALUES ('2008072153100150000','XYZ-100-2','xyz-2',6,'1','****',2,'RL','M','01-Jan-2050','01-Jan-1900');
INSERT INTO bill
VALUES ('2008072153100150000','XYZ-100-2','xyz-4',6,'1','****',2,'IN','M','01-Jan-2050','01-Jan-1900');
INSERT INTO bill
VALUES ('2008072153100150000','XYZ-100-2','xyz-100-3',1,'1','****',0,'RL','M','01-Jan-2050','01-Jan-1900');
INSERT INTO bill
VALUES ('2008072153100150000','XYZ-100-3','xyz-3',8,'1','****',1,'RL','M','01-Jan-2050','01-Jan-2000');
INSERT INTO bill
VALUES ('2008072153100150000','XYZ-100-3','xyz-3a',8,'1','****',1,'RL','M','01-Jan-2000','01-Jan-1900');
INSERT INTO bill
VALUES ('2008072153100150000','XYZ-100-3','XYZ-100-4',4,'1','****',0,'RL','M','01-Jan-2050','01-Jan-1900');
INSERT INTO bill
VALUES ('2008072153100150000','XYZ-100-3','XYZ-100-A',2,'1','****',2,'RL','M','01-Jan-2050','01-Jan-1900');
INSERT INTO bill
VALUES ('2008071153100150000','XYZ-100-3','(OPEN)',2,'1','****',0,'RL','E','01-Jan-2050','01-Jan-1900');
INSERT INTO bill
VALUES ('2008071153100150000','XYZ-100-3','xyz-9-1',2,'1','****',0,'RL','H','01-Jan-2050','01-Jan-1900');
INSERT INTO bill
VALUES ('2008072153100150000','XYZ-100-4','raw-1',8.75,'1','****',0,'RL','M','01-Jan-2050','01-Jan-1900');
INSERT INTO bill
VALUES ('2008072153100150000','XYZ-100-A','raw-2',3.75,'1','****',0,'RL','M','01-Jan-2050','01-Jan-1900');
INSERT INTO bill
VALUES ('2008075911100150000','xyz-9-1','xyz-9a',1,'1','****',0,'RL','G','01-Jan-2050','01-Jan-1900');
INSERT INTO bill
VALUES ('2008087711100150000','xyz-9a','raw-2',3.75,'1','****',0,'RL','G','01-Jan-2050','01-Jan-1900');Sample data displayed in table format:
--PART table (from insert statements above)
part_nbr part_desc part_type qty_on_hand
xyz-1 purchased part P 5
xyz-2 purchased part P 1
xyz-3 purchased part P 1
xyz-3a manufactured part M 1
xyz-4 purchased part P 1
xyz-9-1 manufactured part M 0
xyz-9a manufactured part M 0
raw-1 purchased raw material P 212
raw-2 purchased raw material P 75.5
XYZ-100 manufactured part M 0
(OPEN) (not in use) Y 0
XYZ-100-1 manufactured part M 0
XYZ-100-2 manufactured part M 1
XYZ-100-3 manufactured part M 0
XYZ-100-4 manufactured part M 2
XYZ-100-A manufactured part M 0
--BILL table (from insert statements above)
row_added_ts bom_doc_nbr comp_part_nbr qty_per qty_per_type oper_nbr comp_off_adj status view_code end_eff_dt begn_eff_dt
2008072153100150000 XYZ-100 xyz-1 3 1 **** 0 RL G 01-Jan-2050 01-Jan-1900
2008072223100150000 XYZ-100 XYZ-100-1 1 1 **** 0 RL M 01-Jan-2050 01-Jan-1900
2008072411100150000 XYZ-100-1 xyz-1 2 1 **** 1 RL M 01-Jan-2050 01-Jan-1900
2008072459100150000 XYZ-100-1 XYZ-100-2 3 1 **** 0 RL M 01-Jan-2050 01-Jan-1900
2008072578100150000 XYZ-100-2 xyz-2 6 1 **** 2 RL M 01-Jan-2050 01-Jan-1900
2008072694100150000 XYZ-100-2 xyz-4 6 1 **** 2 IN G 01-Jan-2050 01-Jan-1900
2008072786100150000 XYZ-100-2 xyz-100-3 1 1 **** 0 RL M 01-Jan-2050 01-Jan-1900
2008072865100150000 XYZ-100-3 xyz-3 8 1 **** 1 RL M 01-Jan-2050 01-Jan-2000
2008073100100150000 XYZ-100-3 xyz-3a 8 1 **** 1 RL M 01-Jan-2000 01-Jan-1900
2008073159100150000 XYZ-100-3 XYZ-100-4 4 1 **** 0 RL M 01-Jan-2050 01-Jan-1900
2008073346100150000 XYZ-100-3 XYZ-100-A 2 1 **** 2 RL M 01-Jan-2050 01-Jan-1900
2008073478100150000 XYZ-100-3 (OPEN) 2 1 **** 0 RL E 01-Jan-2050 01-Jan-1900
2008073529100150000 XYZ-100-3 xyz-9-1 2 1 **** 0 RL H 01-Jan-2050 01-Jan-1900
2008073798100150000 XYZ-100-4 raw-1 8.75 1 **** 0 RL M 01-Jan-2050 01-Jan-1900
2008073811100150000 XYZ-100-A raw-2 3.75 1 **** 0 RL M 01-Jan-2050 01-Jan-1900
2008075911100150000 xyz-9-1 xyz-9a 1 1 **** 0 RL G 01-Jan-2050 01-Jan-1900
2008087711100150000 xyz-9a raw-2 3.75 1 **** 0 RL G 01-Jan-2050 01-Jan-1900--What I want to get with my query (branches pruned off my tree)
LEVEL C_PART_NBR C_PART_DESC C_PART_TYPE C_QTY_PER_P C_QTY_PER_TYPE C_QTY_ON_HAND RQD_AT_OP RQD_OFFSET P_PART_NBR P_QTY_ON_HAND
1 XYZ-100-1 manufactured part M 1 1 0 **** 0 XYZ-100 0
2 XYZ-100-2 manufactured part M 3 1 1 **** 0 XYZ-100-1 0
3 xyz-100-3 manufactured part M 1 1 0 **** 0 XYZ-100-2 1
4 XYZ-100-4 manufactured part M 4 1 2 **** 0 XYZ-100-3 0
4 XYZ-100-A manufactured part M 2 1 0 **** 2 XYZ-100-3 0--What I actually get with my query (includes children of items that don't meet query criteria)
LEVEL C_PART_NBR C_PART_DESC C_PART_TYPE C_QTY_PER_P C_QTY_PER_TYPE C_QTY_ON_HAND RQD_AT_OP RQD_OFFSET P_PART_NBR P_QTY_ON_HAND
1 XYZ-100-1 manufactured part M 1 1 0 **** 0 XYZ-100 0
2 XYZ-100-2 manufactured part M 3 1 1 **** 0 XYZ-100-1 0
3 xyz-100-3 manufactured part M 1 1 0 **** 0 XYZ-100-2 1
4 XYZ-100-4 manufactured part M 4 1 2 **** 0 XYZ-100-3 0
4 XYZ-100-A manufactured part M 2 1 0 **** 2 XYZ-100-3 0
5 xyz-9a manufactured part M 1 1 0 **** 0 xyz-9-1 0Edited by: user11033437 on Jul 30, 2009 7:27 AM (grammar) -
Partition Pruning - Dimension and FACT tables..
Hi
I have a DWH environment where we have partitioned the FACT table by a date column. This is RANGE partition. The TIME dimension table joins to the FACT table based on this date. However the end user queries will typically be fired using a different column in the time dimension that will hold more VIEWABLE date values (e.g.) in format MON-YYYY or YYYY-MM etc..
The query is autogenerated by the viewer tool. The SQL has something like
select sum(balance), MONTH from fact a, dim_time b
where a.date = b.date and <-- this the partitioned key in fact
b.month_year_col = 'Apr-2006' <-- Dimension filter.
In the above case, Oracle is not doing PARTITION PRUNING. I have 24 period data and in the explain plan i can see it goes to the entire 24 periods. However if i change the query to
select sum(balance), MONTH from fact a, dim_time b
where a.date = b.date and <-- this the partitioned key in fact
b.date = '31-Apr-2006' <-- Dimension filter.
it does partition pruning. The explain plan shows that i goes to only one partition.
Any help on this please. I would need the first query to use PARTITION PRUNING.
Thanks
balaHi All
Got it to work with these 3 parameters
alter system set "_subquery_pruning_enabled" = true
alter session set "_subquery_pruning_cost_factor"=1;
alter session set "_subquery_pruning_reduction"=100;
Thanks for all those who had a look into my question.
Regards
bala -
Logical partitioning, pass-through layer, query pruning
Hi,
I am dealing with performance guidelines for BW and encountered few interesting topics, which however I do not fully undestand.
1. Mainetance of logical partitioning.
Let's assume logical partitioning is performed on year. Does it mean that every year or so it is necessary to create additional cube/transformation and modify multiprovider? Is there any automatic procedure by SAP that supports creation of new objects, or it is fully manual?
2.Pass- though layer.
There are very few information about this basic concept. Anyway:
- is pass through DSO write optimized one? Does it store only one loading - last one? Is it deleted after lading is sucessfully finished (or before new load starts)? And - does this deletion do not destroy delta mechanism? Is the DSO replacing PSAfunctionally (i.e. PSA can be deleted every load as well)?
3. Query pruning
Does this happen automatically on DB level, or additional developments with exits variables, steering tables and FMs is required?
4. DSOs for master data loads
What is the benefit of using full MD extraction and DSO delta insetad of MD delta extraction?
Thanks,
Marcin1. Mainetance of logical partitioning.
Let's assume logical partitioning is performed on year. Does it mean that every year or so it is necessary to create additional cube/transformation and modify multiprovider? Is there any automatic procedure by SAP that supports creation of new objects, or it is fully manual?
Logical partitioning is when you have separate ODS / Cubes for separate Years etc ....
There is no automated way - however if you want to you can physically partition the cubes using time periods and extend them regularly using the repartitioning options provided.
2.Pass- though layer.
There are very few information about this basic concept. Anyway:
- is pass through DSO write optimized one? Does it store only one loading - last one? Is it deleted after lading is sucessfully finished (or before new load starts)? And - does this deletion do not destroy delta mechanism? Is the DSO replacing PSAfunctionally (i.e. PSA can be deleted every load as well)?
Usually a pass through layer is used to
1. Ensure data consistency
2. Possibly use Deltas
3. Additional transformations
In a write optimized DSo - the request ID is key and hence delta is based on request ID. If you do not have any additional transformations - then a Write optimized DSO is essentially like your PSA.
3. Query pruning
Does this happen automatically on DB level, or additional developments with exits variables, steering tables and FMs is required?
The query pruning - depends on the run based and cost based optimizers within the DB and not much control over how well you can influence the execution of a query other than havin up to date statistics , building aggregates etc etc.
4. DSOs for master data loads
What is the benefit of using full MD extraction and DSO delta insetad of MD delta extraction?
It depends more on the data volumes and also the number of transformation required...
If you have multiple levels of transformations - use a DSO or if you have very high data volumes and want to identify changed records - then use a DSO. -
Decision Tree training runtime error. Perform Pruning.
Hello I get the error below when trying to train a decisio n tree model in RSANWB. The same model trained correctly before I selected Perform Pruning + Extended Pruning in the Parameters tab.
Note 738285 seems to address a similar problem, but is not applicable (or already corrected) in the system I am running (SAPKW35012, SAPKIBIFP5).
Can anyone help me on that?
Claudio Ciardelli
Here is the error log.
Runtime Errors TABLE_FREE_IN_LOOP
Date and Time 28.07.2005 15:40:59
|ShrtText |
| When you LOOP through an internal table, you must not change it. |
|What happened? |
| Error in ABAP application program. |
| |
| The current ABAP program "SAPLRS_DME_DECISION_TREE_PRUNE" had to be terminated |
| because one of the |
| statements could not be executed. |
| |
| This is probably due to an error in the ABAP program. |
|Error analysis |
| When you LOOP through an internal table, the table as a whole may |
| not be changed, |
| SORT, MOVE, REFRESH, and CLEAR are, for example, not allowed. |
|Trigger Location of Runtime Error |
| Program SAPLRS_DME_DECISION_TREE_PRUNE |
| Include LRS_DME_DECISION_TREE_PRUNEF01 |
| Row 163 |
| Module type (FORM) |
| Module Name UPDATE_BRANCH_NEW |
|Source Code Extract |
|Line |SourceCde |
| 133| IF sy-subrc EQ space. |
| 134| l_parent_index = sy-tabix. |
| 135| LOOP AT gt_tree_sorted |
| 136| ASSIGNING <fs_tree> |
| 137| FROM l_parent_index. |
| 138| IF <fs_tree>-parent NE p_node. |
| 139| EXIT. |
| 140| ENDIF. |
| 141| CHECK <fs_tree>-node NE p_branch. |
| 142| l_node_index = sy-tabix. |
| 143| PERFORM delete_children_new USING <fs_tree>-node. |
| 144| DELETE gt_tree_sorted INDEX l_node_index. |
| 145| ENDLOOP. |
| 146| ENDIF. |
| 147|* Update Parent = P_NODE for all Childnodes of P_BRANCH |
| 148| READ TABLE gt_tree_sorted TRANSPORTING NO FIELDS |
| 149| WITH KEY parent = p_branch BINARY SEARCH. |
| 150| IF sy-subrc EQ space. |
| 151| l_parent_index = sy-tabix. |
| 152| LOOP AT gt_tree_sorted |
| 153| ASSIGNING <fs_tree> |
| 154| FROM l_parent_index. |
| 155| IF <fs_tree>-parent NE p_branch. |
| 156| EXIT. |
| 157| ENDIF. |
| 158| l_node_index = sy-tabix. |
| 159| <fs_tree>-parent = p_node. |
| 160| ENDLOOP. |
| 161| ENDIF. |
| 162|* Sort again..since parent info is changed.. |
|>>>>>| SORT gt_tree_sorted BY parent node. |
| 164|* Update Parent = P_NODE for all Childnodes of P_BRANCH |
| 165| READ TABLE gt_tree_sorted TRANSPORTING NO FIELDS |
| 166| WITH KEY parent = p_branch_parent |
| 167| node = p_branch BINARY SEARCH. |
| 168| IF sy-subrc EQ space. |
| 169| DELETE gt_tree_sorted INDEX sy-tabix. |
| 170| ENDIF. |
| 171| |
| 172| |
| 173|ENDFORM. "update_branch_new |
| 174| |
| 175|*&---------------------------------------------------------------------* |
| 176|*& Form update_tree |
| 177|*&---------------------------------------------------------------------* |
| 178|* text |
| 179|*----------------------------------------------------------------------* |
| 180|* -->P_I_T_CLASSDIST text |
| 181|* -->P_I_NODE text |
| 182|*----------------------------------------------------------------------* |
Message was edited by: Claudio Ciardelliotherwise I would contact SAP because you can't update the temp internal table (See ABAP Coding),
best regards,
Klaus -
We have tables that are interval range partitioned on a DATE column, with a partition for each day - all very standard and straight out of Oracle doc.
A 3rd party application queries the tables to find number of rows based on date range that is on the column used for the partition key.
This application uses date range specified relative to current date - i.e. for last two days would be "..startdate > SYSDATE -2 " - but partition pruning does not take place and the explain plan shows that every partition is included.
By presenting the query using the date in a variable partition pruning does table place, and query obviously performs much better.
DB is 11.2.0.3 on RHEL6, and default parameters set - i.e. nothing changed that would influence optimizer behavior to something unusual.
I can't work out why this would be so. It very easy to reproduce with simple test case below.
I'd be very interested to hear any thoughts on why it is this way and whether anything can be done to permit the partition pruning to work with a query including SYSDATE as it would be difficult to get the application code changed.
Furthermore to make a case to change the code I would need an explanation of why querying using SYSDATE is not good practice, and I don't know of any such information.
1) Create simple partitioned table
CREATETABLE part_test
(id NUMBER NOT NULL,
starttime DATE NOT NULL,
CONSTRAINT pk_part_test PRIMARY KEY (id))
PARTITION BY RANGE (starttime) INTERVAL (NUMTODSINTERVAL(1,'day')) (PARTITION p0 VALUES LESS THAN (TO_DATE('01-01-2013','DD-MM-YYYY')));
2) Populate table 1million rows spread between 10 partitions
BEGIN
FOR i IN 1..1000000
LOOP
INSERT INTO part_test (id, starttime) VALUES (i, SYSDATE - DBMS_RANDOM.value(low => 1, high => 10));
END LOOP;
END;
EXEC dbms_stats.gather_table_stats('SUPER_CONF','PART_TEST');
3) Query the Table for data from last 2 days using SYSDATE in clause
EXPLAIN PLAN FOR
SELECT count(*)
FROM part_test
WHERE starttime >= SYSDATE - 2;
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 8 | 7895 (1)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | 8 | | | | |
| 2 | PARTITION RANGE ITERATOR| | 111K| 867K| 7895 (1)| 00:00:01 | KEY |1048575|
|* 3 | TABLE ACCESS FULL | PART_TEST | 111K| 867K| 7895 (1)| 00:00:01 | KEY |1048575|
Predicate Information (identified by operation id):
3 - filter("STARTTIME">=SYSDATE@!-2)
4) Now do the same query but with SYSDATE - 2 presented as a literal value.
This query returns the same answer but very different cost.
EXPLAIN PLAN FOR
SELECT count(*)
FROM part_test
WHERE starttime >= (to_date('23122013:0950','DDMMYYYY:HH24MI'))-2;
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 8 | 131 (0)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | 8 | | | | |
| 2 | PARTITION RANGE ITERATOR| | 111K| 867K| 131 (0)| 00:00:01 | 356 |1048575|
|* 3 | TABLE ACCESS FULL | PART_TEST | 111K| 867K| 131 (0)| 00:00:01 | 356 |1048575|
Predicate Information (identified by operation id):
3 - filter("STARTTIME">=TO_DATE(' 2013-12-21 09:50:00', 'syyyy-mm-dd hh24:mi:ss'))
thanks in anticipation
JimAs Jonathan has already pointed out there are situations where the CBO knows that partition pruning will occur but is unable to identify those partitions at parse time. The CBO will then use a dynamic pruning which means determine the partitions to eliminate dynamically at run time. This is why you see the KEY information instead of a known partition number. This is to occur mainly when you compare a function to your partition key i.e. where partition_key = function. And SYSDATE is a function. For the other bizarre PSTOP number (1048575) see this blog
http://hourim.wordpress.com/2013/11/08/interval-partitioning-and-pstop-in-execution-plan/
Best regards
Mohamed Houri -
Min max with Alpha Beta pruning
Hey I would like to add Min max with Alpha - Beta pruning for my tic tac toe game. If you know some sort of tutorial or anything please let me know. After I complete I'm going to make a complete guide to make a Tic Tac Toe game with a really nice GUI, Music, AI, and Network capabilities. I have the game made so far. I'm going to rewrite it with interfaces and clean up the code a lot then create the guide, but before I do all this I want to create and AI for it.
I suppose that since, other than reading a summary on Wikipedia, I
don't know what a 'minimax algorithm' is and have never tried to
implement one I should not make fun.The idea is quite simple: your best move e.g. in a board game is my worst
result and vice versa. If I can minimize your best move I have maximized
my best move (and that's the move I'll play).
Now suppose my best move somewhere in that game tree turns out
to be worse than another best move of mine somewhere else in that
same tree, there is no need anymore for me to explore the rest of that
subtree. That's the alpha pruning part. The same counts for you and
that's the beta pruning part.
alpha-beta pruning reduces the number of nodes to be examined to
O(sqrt(n)) where n are all the nodes in the fully examined tree. It is
quite a nice algorithm although quite tricky too when you have to build it.
The best reference I can think of now is the old book "Data Structures"
by Horrowitz and Sahni.
kind regards,
Jos -
Pruning on subpartition not occurs
Hello
I have a little problem of performance on a query that seems for me simple
SELECT /*+ no_parallel (dwh_ind_ca_marge) use_nl(dwh_ind_ca_marge) */
FROM dwh_ind_ca_marge, dwh_ag ag, dwh_ag com
WHERE com.pk_id_ag = ag.id_ag_com
AND fk_id_ag = ag.pk_id_ag
AND com.cd_ag = 121
AND id_an_mois = 200910
Dwh_ind_ca_marge is a subpartition table (range / hash) :
the range is on the month (200101 200102 .....)
the hash is on fk_id_ag : the id of an agency (128 subpartitions)
dwh_ag is the table of agency with primary key pk_id_ag
In fact I dont understand why subquery pruning on fk_id_ag doesn t occur
The problem is workarounded by forcing the nested loop between dwh_ag andf dwh_ind_ca_marge
What is surprising is that on the 10053 trace the nested loop has a lower cost that the plan choosen !!!!
What s the problem ?
thanks
ps : i am on 10.2.0.5 enterprise edition
Edited by: user12210577 on 21 oct. 2010 05:22
Edited by: user12210577 on 21 oct. 2010 05:44QUERY BLOCK TEXT
select /*+ no_parallel (dwh_ind_ca_marge) */ -----use_nl(dwh_ind_ca_marge) */
* from dwh_ind_ca_marge, dwh_ag ag, dwh_ag com where
com.pk_id_ag = ag.id_ag_com and fk_id_ag= ag.pk_id_ag and
com.cd_ag=121 and id_an_mois=200910 and 1=1
QUERY BLOCK SIGNATURE
qb name was generated
signature (optimizer): qb_name=SEL$1 nbfros=3 flg=0
fro(0): flg=0 objn=14305 hint_alias="AG"@"SEL$1"
fro(1): flg=0 objn=14305 hint_alias="COM"@"SEL$1"
fro(2): flg=0 objn=121227 hint_alias="DWH_IND_CA_MARGE"@"SEL$1"
SYSTEM STATISTICS INFORMATION
Using WORKLOAD Stats
CPUSPEED: 1257 millions instructions/sec
SREADTIM: 10 milliseconds
MREADTIM: 42 millisecons
MBRC: 51.000000 blocks
MAXTHR: 33554432 bytes/sec
SLAVETHR: 2097152 bytes/sec
BASE STATISTICAL INFORMATION
Table Stats::
Table: DWH_AG Alias: COM (NOT ANALYZED)
#Rows: 1634 #Blks: 20 AvgRowLen: 100.00
Column (#1): PK_ID_AG(NUMBER) NO STATISTICS (using defaults)
AvgLen: 13.00 NDV: 51 Nulls: 0 Density: 0.019584
Index Stats::
Index: IDX_DWH_AG_1 Col#: 5 (NOT ANALYZED)
LVLS: 1 #LB: 25 #DK: 100 LB/K: 1.00 DB/K: 1.00 CLUF: 800.00
Index: PK_DWH_AG Col#: 1 (NOT ANALYZED)
LVLS: 1 #LB: 25 #DK: 100 LB/K: 1.00 DB/K: 1.00 CLUF: 800.00
Table Stats::
Table: DWH_AG Alias: AG (NOT ANALYZED)
#Rows: 1634 #Blks: 20 AvgRowLen: 100.00
Column (#22): ID_AG_COM(NUMBER) NO STATISTICS (using defaults)
AvgLen: 13.00 NDV: 51 Nulls: 0 Density: 0.019584
Column (#1): PK_ID_AG(NUMBER) NO STATISTICS (using defaults)
AvgLen: 13.00 NDV: 51 Nulls: 0 Density: 0.019584
Index Stats::
Index: IDX_DWH_AG_1 Col#: 5 (NOT ANALYZED)
LVLS: 1 #LB: 25 #DK: 100 LB/K: 1.00 DB/K: 1.00 CLUF: 800.00
Index: PK_DWH_AG Col#: 1 (NOT ANALYZED)
LVLS: 1 #LB: 25 #DK: 100 LB/K: 1.00 DB/K: 1.00 CLUF: 800.00
Table Stats::
Table: DWH_IND_CA_MARGE Alias: DWH_IND_CA_MARGE (Using composite stats)
#Rows: 100302273 #Blks: 46538 AvgRowLen: 452.00
Index Stats::
Index: IDX_DWH_IND_CA_MARGE_1 Col#: 88
LVLS: 2 #LB: 1223 #DK: 98204 LB/K: 1.00 DB/K: 2.00 CLUF: 277386.00
Index: IDX_DWH_IND_CA_MARGE_2 Col#: 10 5
LVLS: 3 #LB: 350280 #DK: 1086 LB/K: 322.00 DB/K: 33633.00 CLUF: 36526000.00
Index: IDX_DWH_IND_CA_MARGE_3 Col#: 6
LVLS: 3 #LB: 385313 #DK: 2124 LB/K: 181.00 DB/K: 19421.00 CLUF: 41252307.00
Index: IDX_DWH_IND_CA_MARGE_4 Col#: 9
LVLS: 3 #LB: 353713 #DK: 6863 LB/K: 80.00 DB/K: 14320.00 CLUF: 98677547.00
Index: IDX_DWH_IND_CA_MARGE_5 Col#: 10
LVLS: 3 #LB: 302187 #DK: 112 LB/K: 2698.00 DB/K: 95529.00 CLUF: 10699333.00
Index: IDX_DWH_IND_CA_MARGE_6 Col#: 5
LVLS: 3 #LB: 315320 #DK: 18 LB/K: 17517.00 DB/K: 1746632.00 CLUF: 31439393.00
Index: PK_DWH_IND_CA_MARGE Col#: 1
LVLS: 3 #LB: 314060 #DK: 97686787 LB/K: 1.00 DB/K: 1.00 CLUF: 92745280.00
SINGLE TABLE ACCESS PATH
BEGIN Single Table Cardinality Estimation
*** 2010-10-21 13:52:04.086
** Performing dynamic sampling initial checks. **
Column (#8): ID_AN_MOIS(NUMBER)
AvgLen: 5.00 NDV: 79 Nulls: 0 Density: 5.9155e-06 Min: 200404 Max: 201010
Histogram: Freq #Bkts: 79 UncompBkts: 15045341 EndPtVals: 79
** Dynamic sampling initial checks returning FALSE.
Table: DWH_IND_CA_MARGE Alias: DWH_IND_CA_MARGE
Card: Original: 100302273 Rounded: 1907307 Computed: 1907306.66 Non Adjusted: 1907306.66
END Single Table Cardinality Estimation
Access Path: TableScan
Cost: 4014.54 Resp: 4014.54 Degree: 0
Cost_io: 3710.00 Cost_cpu: 3963249652
Resp_io: 3710.00 Resp_cpu: 3963249652
Best:: AccessPath: TableScan
Cost: 4014.54 Degree: 1 Resp: 4014.54 Card: 1907306.66 Bytes: 0
SINGLE TABLE ACCESS PATH
BEGIN Single Table Cardinality Estimation
*** 2010-10-21 13:52:04.087
** Performing dynamic sampling initial checks. **
** Dynamic sampling initial checks returning TRUE (level = 4).
** Dynamic sampling updated table stats.: blocks=20
*** 2010-10-21 13:52:04.087
** Generated dynamic sampling query:
query text :
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false') NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0), COUNT(DISTINCT C3), NVL(SUM(CASE WHEN C3 IS NULL THEN 1 ELSE 0 END),0) FROM (SELECT /*+ NO_PARALLEL("AG") FULL("AG") NO_PARALLEL_INDEX("AG") */ 1 AS C1, 1 AS C2, "AG"."ID_AG_COM" AS C3 FROM "DWH_AG" "AG") SAMPLESUB
*** 2010-10-21 13:52:04.089
** Executed dynamic sampling query:
level : 4
sample pct. : 100.000000
actual sample size : 565
filtered sample card. : 565
orig. card. : 1634
block cnt. table stat. : 20
block cnt. for sampling: 20
max. sample block cnt. : 64
sample block cnt. : 20
ndv C3 : 557
scaled : 557.00
nulls C4 : 6
scaled : 6.00
min. sel. est. : -1.00000000
** Dynamic sampling col. stats.:
Column (#22): ID_AG_COM(NUMBER) Part#: 0
AvgLen: 22.00 NDV: 557 Nulls: 6 Density: 0.0017953
** Using dynamic sampling NULLs estimates.
** Using dynamic sampling NDV estimates.
Scaled NDVs using cardinality = 565.
** Using dynamic sampling card. : 565
** Dynamic sampling updated table card.
Table: DWH_AG Alias: AG
Card: Original: 565 Rounded: 565 Computed: 565.00 Non Adjusted: 565.00
END Single Table Cardinality Estimation
Access Path: TableScan
Cost: 3.05 Resp: 3.05 Degree: 0
Cost_io: 3.00 Cost_cpu: 713079
Resp_io: 3.00 Resp_cpu: 713079
Best:: AccessPath: TableScan
Cost: 3.05 Degree: 1 Resp: 3.05 Card: 565.00 Bytes: 0
SINGLE TABLE ACCESS PATH
BEGIN Single Table Cardinality Estimation
*** 2010-10-21 13:52:04.090
** Performing dynamic sampling initial checks. **
Column (#5): CD_AG(NUMBER) NO STATISTICS (using defaults)
AvgLen: 13.00 NDV: 51 Nulls: 0 Density: 0.019584
** Dynamic sampling initial checks returning TRUE (level = 4).
** Dynamic sampling updated index stats.: IDX_DWH_AG_1, blocks=6
** Dynamic sampling updated index stats.: PK_DWH_AG, blocks=1
** Dynamic sampling index access candidate : IDX_DWH_AG_1
** Dynamic sampling updated table stats.: blocks=20
*** 2010-10-21 13:52:04.090
** Generated dynamic sampling query:
query text :
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false') NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0), COUNT(DISTINCT C3), NVL(SUM(CASE WHEN C3 IS NULL THEN 1 ELSE 0 END),0) FROM (SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("COM") FULL("COM") NO_PARALLEL_INDEX("COM") */ 1 AS C1, CASE WHEN "COM"."CD_AG"=121 THEN 1 ELSE 0 END AS C2, "COM"."PK_ID_AG" AS C3 FROM "DWH_AG" "COM") SAMPLESUB
*** 2010-10-21 13:52:04.091
** Executed dynamic sampling query:
level : 4
sample pct. : 100.000000
actual sample size : 565
filtered sample card. : 1
orig. card. : 1634
block cnt. table stat. : 20
block cnt. for sampling: 20
max. sample block cnt. : 64
sample block cnt. : 20
ndv C3 : 565
scaled : 565.00
nulls C4 : 0
scaled : 0.00
min. sel. est. : 0.01000000
** Dynamic sampling col. stats.:
Column (#1): PK_ID_AG(NUMBER) Part#: 0
AvgLen: 22.00 NDV: 565 Nulls: 0 Density: 0.0017699
** Using dynamic sampling NULLs estimates.
** Using dynamic sampling NDV estimates.
Scaled NDVs using cardinality = 565.
** Using recursive dynamic sampling card. est. : 565.000000
*** 2010-10-21 13:52:04.091
** Generated dynamic sampling query:
query text :
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS opt_param('parallel_execution_enabled', 'false') NO_PARALLEL(SAMPLESUB) NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0), NVL(SUM(C3),0) FROM (SELECT /*+ NO_PARALLEL("COM") INDEX("COM" IDX_DWH_AG_1) NO_PARALLEL_INDEX("COM") */ 1 AS C1, 1 AS C2, 1 AS C3 FROM "DWH_AG" "COM" WHERE "COM"."CD_AG"=121 AND ROWNUM <= 2500) SAMPLESUB
*** 2010-10-21 13:52:04.091
** Executed dynamic sampling query:
level : 4
sample pct. : 100.000000
actual sample size : 565
filtered sample card. : 1
filtered sample card. (index IDX_DWH_AG_1): 1
orig. card. : 565
block cnt. table stat. : 20
block cnt. for sampling: 20
max. sample block cnt. : 4294967295
sample block cnt. : 20
min. sel. est. : 0.01000000
index IDX_DWH_AG_1 selectivity est.: 0.00176991
** Using dynamic sampling card. : 565
** Dynamic sampling updated table card.
** Using single table dynamic sel. est. : 0.00176991
Table: DWH_AG Alias: COM
Card: Original: 565 Rounded: 1 Computed: 1.00 Non Adjusted: 1.00
END Single Table Cardinality Estimation
Access Path: TableScan
Cost: 3.02 Resp: 3.02 Degree: 0
Cost_io: 3.00 Cost_cpu: 301409
Resp_io: 3.00 Resp_cpu: 301409
Access Path: index (AllEqRange)
Index: IDX_DWH_AG_1
resc_io: 3.00 resc_cpu: 28264
ix_sel: 0.0017699 ix_sel_with_filters: 0.0017699
Cost: 3.00 Resp: 3.00 Degree: 1
Best:: AccessPath: IndexRange Index: IDX_DWH_AG_1
Cost: 3.00 Degree: 1 Resp: 3.00 Card: 1.00 Bytes: 0
OPTIMIZER STATISTICS AND COMPUTATIONS
GENERAL PLANS
Considering cardinality-based initial join order.
Permutations for Starting Table :0
Join order[1]: DWH_AG[COM]#0 DWH_AG[AG]#1 DWH_IND_CA_MARGE[DWH_IND_CA_MARGE]#2
Now joining: DWH_AG[AG]#1
NL Join
Outer table: Card: 1.00 Cost: 3.00 Resp: 3.00 Degree: 1 Bytes: 706
Inner table: DWH_AG Alias: AG
Access Path: TableScan
NL Join: Cost: 6.06 Resp: 6.06 Degree: 1
Cost_io: 6.00 Cost_cpu: 741343
Resp_io: 6.00 Resp_cpu: 741343
Best NL cost: 6.06
resc: 6.06 resc_io: 6.00 resc_cpu: 741343
resp: 6.06 resp_io: 6.00 resp_cpu: 741343
Join Card: 1.00 = outer (1.00) * inner (565.00) * sel (0.0017763)
Join Card - Rounded: 1 Computed: 1.00
SM Join
Outer table:
resc: 3.00 card 1.00 bytes: 706 deg: 1 resp: 3.00
Inner table: DWH_AG Alias: AG
resc: 3.05 card: 565.00 bytes: 706 deg: 1 resp: 3.05
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 598 Area size: 1048576 Max Area size: 104857600
Degree: 1
Blocks to Sort: 1 Row size: 787 Total Rows: 1
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 13013721
Total Temp space used: 0
SORT resource Sort statistics
Sort width: 598 Area size: 1048576 Max Area size: 104857600
Degree: 1
Blocks to Sort: 55 Row size: 787 Total Rows: 565
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 13246441
Total Temp space used: 0
SM join: Resc: 8.07 Resp: 8.07 [multiMatchCost=0.00]
SM cost: 8.07
resc: 8.07 resc_io: 6.00 resc_cpu: 27001505
resp: 8.07 resp_io: 6.00 resp_cpu: 27001505
HA Join
Outer table:
resc: 3.00 card 1.00 bytes: 706 deg: 1 resp: 3.00
Inner table: DWH_AG Alias: AG
resc: 3.05 card: 565.00 bytes: 706 deg: 1 resp: 3.05
using dmeth: 2 #groups: 1
Cost per ptn: 0.50 #ptns: 1
hash_area: 256 (max=25600) buildfrag: 1 probefrag: 50 ppasses: 1
Hash join: Resc: 6.56 Resp: 6.56 [multiMatchCost=0.00]
HA cost: 6.56
resc: 6.56 resc_io: 6.00 resc_cpu: 7304854
resp: 6.56 resp_io: 6.00 resp_cpu: 7304854
Best:: JoinMethod: Hash
Cost: 6.56 Degree: 1 Resp: 6.56 Card: 1.00 Bytes: 1412
Now joining: DWH_IND_CA_MARGE[DWH_IND_CA_MARGE]#2
NL Join
Outer table: Card: 1.00 Cost: 6.56 Resp: 6.56 Degree: 1 Bytes: 1412
Inner table: DWH_IND_CA_MARGE Alias: DWH_IND_CA_MARGE
Access Path: TableScan
NL Join: Cost: 4017.38 Resp: 4017.38 Degree: 1
Cost_io: 3716.00 Cost_cpu: 3922124065
Resp_io: 3716.00 Resp_cpu: 3922124065
Access Path: index (RangeScan)
Index: IDX_DWH_IND_CA_MARGE_2
resc_io: 329255.00 resc_cpu: 4355303457
ix_sel: 0.0089286 ix_sel_with_filters: 0.0089286
NL Join: Cost: 329596.23 Resp: 329596.23 Degree: 1
Cost_io: 329261.00 Cost_cpu: 4362608310
Resp_io: 329261.00 Resp_cpu: 4362608310
Access Path: index (AllEqJoinGuess)
Index: IDX_DWH_IND_CA_MARGE_5
resc_io: 98230.00 resc_cpu: 2748127704
ix_sel: 0.0089286 ix_sel_with_filters: 0.0089286
NL Join: Cost: 98447.73 Resp: 98447.73 Degree: 1
Cost_io: 98236.00 Cost_cpu: 2755432557
Resp_io: 98236.00 Resp_cpu: 2755432557
****** trying bitmap/domain indexes ******
****** finished trying bitmap/domain indexes ******
Best NL cost: 4017.38
resc: 4017.38 resc_io: 3716.00 resc_cpu: 3922124065
resp: 4017.38 resp_io: 3716.00 resp_cpu: 3922124065
Join Card: 17090.67 = outer (1.00) * inner (1907306.66) * sel (0.0089286)
Join Card - Rounded: 17091 Computed: 17090.67
SM Join
Outer table:
resc: 6.56 card 1.00 bytes: 1412 deg: 1 resp: 6.56
Inner table: DWH_IND_CA_MARGE Alias: DWH_IND_CA_MARGE
resc: 4014.54 card: 1907306.66 bytes: 452 deg: 1 resp: 4014.54
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 598 Area size: 1048576 Max Area size: 104857600
Degree: 1
Blocks to Sort: 1 Row size: 1564 Total Rows: 1
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 13013721
Total Temp space used: 0
SORT resource Sort statistics
Sort width: 598 Area size: 1048576 Max Area size: 104857600
Degree: 1
Blocks to Sort: 118623 Row size: 508 Total Rows: 1907307
Initial runs: 10 Merge passes: 1 IO Cost / pass: 42378
Total IO sort cost: 161001 Total CPU sort cost: 4727050693
Total Temp space used: 2604131000
SM join: Resc: 165386.34 Resp: 165386.34 [multiMatchCost=0.00]
SM cost: 165386.34
resc: 165386.34 resc_io: 164717.00 resc_cpu: 8710618919
resp: 165386.34 resp_io: 164717.00 resp_cpu: 8710618919
HA Join
Outer table:
resc: 6.56 card 1.00 bytes: 1412 deg: 1 resp: 6.56
Inner table: DWH_IND_CA_MARGE Alias: DWH_IND_CA_MARGE
resc: 4014.54 card: 1907306.66 bytes: 452 deg: 1 resp: 4014.54
using dmeth: 2 #groups: 1
Cost per ptn: 15.16 #ptns: 1
hash_area: 256 (max=25600) buildfrag: 1 probefrag: 108032 ppasses: 1
Hash join: Resc: 4036.26 Resp: 4036.26 [multiMatchCost=0.00]
HA cost: 4036.26
resc: 4036.26 resc_io: 3716.00 resc_cpu: 4167792216
resp: 4036.26 resp_io: 3716.00 resp_cpu: 4167792216
Best:: JoinMethod: Hash
Cost: 4036.26 Degree: 1 Resp: 4036.26 Card: 17090.67 Bytes: 1864
Best so far: Table#: 0 cost: 3.0022 card: 1.0000 bytes: 706
Table#: 1 cost: 6.5613 card: 1.0036 bytes: 1412
Table#: 2 cost: 4036.2614 card: 17090.6711 bytes: 31857624
Join order[2]: DWH_AG[COM]#0 DWH_IND_CA_MARGE[DWH_IND_CA_MARGE]#2 DWH_AG[AG]#1
Now joining: DWH_IND_CA_MARGE[DWH_IND_CA_MARGE]#2
NL Join
Outer table: Card: 1.00 Cost: 3.00 Resp: 3.00 Degree: 1 Bytes: 706
Inner table: DWH_IND_CA_MARGE Alias: DWH_IND_CA_MARGE
Access Path: TableScan
NL Join: Cost: 4017.55 Resp: 4017.55 Degree: 1
Cost_io: 3713.00 Cost_cpu: 3963277916
Resp_io: 3713.00 Resp_cpu: 3963277916
Best NL cost:
.55
resc: 4017.55 resc_io: 3713.00 resc_cpu: 3963277916
resp: 4017.55 resp_io: 3713.00 resp_cpu: 3963277916
Join Card: 1907306.66 = outer (1.00) * inner (1907306.66) * sel (1)
Join Card - Rounded: 1907307 Computed: 1907306.66
Best:: JoinMethod: NestedLoop
Cost: 4017.55 Degree: 1 Resp: 4017.55 Card: 1907306.66 Bytes: 1158
Now joining: DWH_AG[AG]#1
NL Join
Outer table: Card: 1907306.66 Cost: 4017.55 Resp: 4017.55 Degree: 1 Bytes: 1158
Inner table: DWH_AG Alias: AG
Access Path: TableScan
NL Join: Cost: 3148354.25 Resp: 3148354.25 Degree: 1
Cost_io: 3043540.00 Cost_cpu: 1364023464708
Resp_io: 3043540.00 Resp_cpu: 1364023464708
Access Path: index (UniqueScan)
Index: PK_DWH_AG
resc_io: 1.00 resc_cpu: 10031
ix_sel: 0.0017699 ix_sel_with_filters: 0.0017699
NL Join: Cost: 874409.56 Resp: 874409.56 Degree: 1
Cost_io: 873283.21 Cost_cpu: 14658019216
Resp_io: 873283.21 Resp_cpu: 14658019216
Access Path: index (AllEqUnique)
Index: PK_DWH_AG
resc_io: 1.00 resc_cpu: 10031
ix_sel: 0.0089286 ix_sel_with_filters: 0.0089286
NL Join: Cost: 874409.56 Resp: 874409.56 Degree: 1
Cost_io: 873283.21 Cost_cpu: 14658019216
Resp_io: 873283.21 Resp_cpu: 14658019216
Best NL cost: 874409.56
resc: 874409.56 resc_io: 873283.21 resc_cpu: 14658019216
resp: 874409.56 resp_io: 873283.21 resp_cpu: 14658019216
Join Card: 17090.67 = outer (1907306.66) * inner (565.00) * sel (1.5860e-05)
Join Card - Rounded: 17091 Computed: 17090.67
SM Join
Outer table:
resc: 4017.55 card 1907306.66 bytes: 1158 deg: 1 resp: 4017.55
Inner table: DWH_AG Alias: AG
resc: 3.05 card: 565.00 bytes: 706 deg: 1 resp: 3.05
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 598 Area size: 1048576 Max Area size: 104857600
Degree: 1
Blocks to Sort: 299827 Row size: 1284 Total Rows: 1907307
Initial runs: 24 Merge passes: 1 IO Cost / pass: 107112
Total IO sort cost: 406939 Total CPU sort cost: 9189380397
Total Temp space used: 5208237000
SORT resource Sort statistics
Sort width: 598 Area size: 1048576 Max Area size: 104857600
Degree: 1
Blocks to Sort: 55 Row size: 787 Total Rows: 565
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 13246441
Total Temp space used: 0
SM join: Resc: 411666.75 Resp: 411666.75 [multiMatchCost=0.00]
SM cost: 411666.75
resc: 411666.75 resc_io: 410655.00 resc_cpu: 13166617832
resp: 411666.75 resp_io: 410655.00 resp_cpu: 13166617832
HA Join
Outer table:
resc: 4017.55 card 1907306.66 bytes: 1158 deg: 1 resp: 4017.55
Inner table: DWH_AG Alias: AG
resc: 3.05 card: 565.00 bytes: 706 deg: 1 resp: 3.05
using dmeth: 2 #groups: 1
Cost per ptn: 50003.38 #ptns: 1
hash_area: 256 (max=25600) buildfrag: 272406 probefrag: 50 ppasses: 1
Hash join: Resc: 54024.11 Resp: 54024.11 [multiMatchCost=0.13]
HA Join (swap)
Outer table:
resc: 3.05 card 565.00 bytes: 706 deg: 1 resp: 3.05
Inner table: DWH_IND_CA_MARGE Alias: DWH_IND_CA_MARGE
resc: 4017.55 card: 1907306.66 bytes: 1158 deg: 1 resp: 4017.55
using dmeth: 2 #groups: 1
Cost per ptn: 15.16 #ptns: 1
hash_area: 256 (max=25600) buildfrag: 50 probefrag: 272406 ppasses: 1
Hash join: Resc: 4035.76 Resp: 4035.76 [multiMatchCost=0.00]
HA cost: 4035.76
resc: 4035.76 resc_io: 3716.00 resc_cpu: 4161313305
resp: 4035.76 resp_io: 3716.00 resp_cpu: 4161313305
Best:: JoinMethod: Hash
Cost: 4035.76 Degree: 1 Resp: 4035.76 Card: 17090.67 Bytes: 1864
Best so far: Table#: 0 cost: 3.0022 card: 1.0000 bytes: 706
Table#: 2 cost: 4017.5461 card: 1907306.6603 bytes: 2208661506
Table#: 1 cost: 4035.7635 card: 17090.6711 bytes: 31857624
Join order[3]: DWH_AG[AG]#1 DWH_AG[COM]#0 DWH_IND_CA_MARGE[DWH_IND_CA_MARGE]#2
Now joining: DWH_AG[COM]#0
NL Join
Outer table: Card: 565.00 Cost: 3.05 Resp: 3.05 Degree: 1 Bytes: 706
Inner table: DWH_AG Alias: COM
Access Path: TableScan
NL Join: Cost: 918.14 Resp: 918.14 Degree: 1
Cost_io: 905.00 Cost_cpu: 171009051
Resp_io: 905.00 Resp_cpu: 171009051
Access Path: index (UniqueScan)
Index: PK_DWH_AG
resc_io: 1.00 resc_cpu: 10081
ix_sel: 0.0017699 ix_sel_with_filters: 0.0017699
NL Join: Cost: 568.49 Resp: 568.49 Degree: 1
Cost_io: 568.00 Cost_cpu: 6409092
Resp_io: 568.00 Resp_cpu: 6409092
Access Path: index (AllEqJoin)
Index: IDX_DWH_AG_1
resc_io: 3.00 resc_cpu: 28264
ix_sel: 0.0017699 ix_sel_with_filters: 0.0017699
NL Join: Cost: 1699.28 Resp: 1699.28 Degree: 1
Cost_io: 1698.00 Cost_cpu: 16682420
Resp_io: 1698.00 Resp_cpu: 16682420
Access Path: index (AllEqUnique)
Index: PK_DWH_AG
resc_io: 1.00 resc_cpu: 10081
ix_sel: 0.0017699 ix_sel_with_filters: 0.0017699
NL Join: Cost: 568.49 Resp: 568.49 Degree: 1
Cost_io: 568.00 Cost_cpu: 6409092
Resp_io: 568.00 Resp_cpu: 6409092
****** trying bitmap/domain indexes ******
Access Path: index (AllEqJoin)
Index: IDX_DWH_AG_1
resc_io: 1.00 resc_cpu: 8971
ix_sel: 0.0017699 ix_sel_with_filters: 0.0017699
NL Join: Cost: 568.44 Resp: 568.44 Degree: 1
Cost_io: 568.00 Cost_cpu: 5781942
Resp_io: 568.00 Resp_cpu: 5781942
Access Path: index (AllEqUnique)
Index: PK_DWH_AG
resc_io: 0.00 resc_cpu: 1900
ix_sel: 0.0017699 ix_sel_with_filters: 0.0017699
NL Join: Cost: 3.14 Resp: 3.14 Degree: 1
Cost_io: 3.00 Cost_cpu: 1786579
Resp_io: 3.00 Resp_cpu: 1786579
Access path: Bitmap index - rejected
Cost: 577.49 Cost_io: 576.81 Cost_cpu: 8873906 Sel: 1.7763e-05
Not believed to be index-only
****** finished trying bitmap/domain indexes ******
Best NL cost: 568.49
resc: 568.49 resc_io: 568.00 resc_cpu: 6409092
resp: 568.49 resp_io: 568.00 resp_cpu: 6409092
Join Card: 1.00 = outer (565.00) * inner (1.00) * sel (0.0017763)
Join Card - Rounded: 1 Computed: 1.00
SM Join
Outer table:
resc: 3.05 card 565.00 bytes: 706 deg: 1 resp: 3.05
Inner table: DWH_AG Alias: COM
resc: 3.00 card: 1.00 bytes: 706 deg: 1 resp: 3.00
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 598 Area size: 1048576 Max Area size: 104857600
Degree: 1
Blocks to Sort: 55 Row size: 787 Total Rows: 565
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 13246441
Total Temp space used: 0
SORT resource Sort statistics
Sort width: 598 Area size: 1048576 Max Area size: 104857600
Degree: 1
Blocks to Sort: 1 Row size: 787 Total Rows: 1
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 13013721
Total Temp space used: 0
SM join: Resc: 8.07 Resp: 8.07 [multiMatchCost=0.00]
SM cost: 8.07
resc: 8.07 resc_io: 6.00 resc_cpu: 27001505
resp: 8.07 resp_io: 6.00 resp_cpu: 27001505
HA Join
Outer table:
resc: 3.05 card 565.00 bytes: 706 deg: 1 resp: 3.05
Inner table: DWH_AG Alias: COM
resc: 3.00 card: 1.00 bytes: 706 deg: 1 resp: 3.00
using dmeth: 2 #groups: 1
Cost per ptn: 0.51 #ptns: 1
hash_area: 256 (max=25600) buildfrag: 50 probefrag: 1 ppasses: 1
Hash join: Resc: 6.56 Resp: 6.56 [multiMatchCost=0.00]
HA Join (swap)
Outer table:
resc: 3.00 card 1.00 bytes: 706 deg: 1 resp: 3.00
Inner table: DWH_AG Alias: AG
resc: 3.05 card: 565.00 bytes: 706 deg: 1 resp: 3.05
using dmeth: 2 #groups: 1
Cost per ptn: 0.50 #ptns: 1
hash_area: 256 (max=25600) buildfrag: 1 probefrag: 50 ppasses: 1
Hash join: Resc: 6.56 Resp: 6.56 [multiMatchCost=0.00]
HA cost: 6.56
resc: 6.56 resc_io: 6.00 resc_cpu: 7304854
resp: 6.56 resp_io: 6.00 resp_cpu: 7304854
Best:: JoinMethod: Hash
Cost: 6.56 Degree: 1 Resp: 6.56 Card: 1.00 Bytes: 1412
Now joining: DWH_IND_CA_MARGE[DWH_IND_CA_MARGE]#2
NL Join
Outer table: Card: 1.00 Cost: 6.56 Resp: 6.56 Degree: 1 Bytes: 1412
Inner table: DWH_IND_CA_MARGE Alias: DWH_IND_CA_MARGE
Access Path: TableScan
NL Join: Cost: 4017.38 Resp: 4017.38 Degree: 1
Cost_io: 3716.00 Cost_cpu: 3922124065
Resp_io: 3716.00 Resp_cpu: 3922124065
Access Path: index (RangeScan)
Index: IDX_DWH_IND_CA_MARGE_2
resc_io: 329255.00 resc_cpu: 4355303457
ix_sel: 0.0089286 ix_sel_with_filters: 0.0089286
NL Join: Cost: 329596.23 Resp: 329596.23 Degree: 1
Cost_io: 329261.00 Cost_cpu: 4362608310
Resp_io: 329261.00 Resp_cpu: 4362608310
Access Path: index (AllEqJoinGuess)
Index: IDX_DWH_IND_CA_MARGE_5
resc_io: 98230.00 resc_cpu: 2748127704
ix_sel: 0.0089286 ix_sel_with_filters: 0.0089286
NL Join: Cost: 98447.73 Resp: 98447.73 Degree: 1
Cost_io: 98236.00 Cost_cpu: 2755432557
Resp_io: 98236.00 Resp_cpu: 2755432557
****** trying bitmap/domain indexes ******
****** finished trying bitmap/domain indexes ******
Best NL cost: 4017.38
resc: 4017.38 resc_io: 3716.00 resc_cpu: 3922124065
resp: 4017.38 resp_io: 3716.00 resp_cpu: 3922124065
Join Card: 17090.67 = outer (1.00) * inner (1907306.66) * sel (0.0089286)
Join Card - Rounded: 17091 Computed: 17090.67
SM Join
Outer table:
resc: 6.56 card 1.00 bytes: 1412 deg: 1 resp: 6.56
Inner table: DWH_IND_CA_MARGE Alias: DWH_IND_CA_MARGE
resc: 4014.54 card: 1907306.66 bytes: 452 deg: 1 resp: 4014.54
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 598 Area size: 1048576 Max Area size: 104857600
Degree: 1
Blocks to Sort: 1 Row size: 1564 Total Rows: 1
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 13013721
Total Temp space used: 0
SORT resource Sort statistics
Sort width: 598 Area size: 1048576 Max Area size: 104857600
Degree: 1
Blocks to Sort: 118623 Row size: 508 Total Rows: 1907307
Initial runs: 10 Merge passes: 1 IO Cost / pass: 42378
Total IO sort cost: 161001 Total CPU sort cost: 4727050693
Total Temp space used: 2604131000
SM join: Resc: 165386.34 Resp: 165386.34 [multiMatchCost=0.00]
SM cost: 165386.34
resc: 165386.34 resc_io: 164717.00 resc_cpu: 8710618919
resp: 165386.34 resp_io: 164717.00 resp_cpu: 8710618919
HA Join
Outer table:
resc: 6.56 card 1.00 bytes: 1412 deg: 1 resp: 6.56
Inner table: DWH_IND_CA_MARGE Alias: DWH_IND_CA_MARGE
resc: 4014.54 card: 1907306.66 bytes: 452 deg: 1 resp: 4014.54
using dmeth: 2 #groups: 1
Cost per ptn: 15.16 #ptns: 1
hash_area: 256 (max=25600) buildfrag: 1 probefrag: 108032 ppasses: 1
Hash join: Resc: 4036.26 Resp: 4036.26 [multiMatchCost=0.00]
HA cost: 4036.26
resc: 4036.26 resc_io: 3716.00 resc_cpu: 4167792216
resp: 4036.26 resp_io: 3716.00 resp_cpu: 4167792216
Join order aborted: cost > best plan cost
Join order[4]: DWH_AG[AG]#1 DWH_IND_CA_MARGE[DWH_IND_CA_MARGE]#2 DWH_AG[COM]#0
Now joining: DWH_IND_CA_MARGE[DWH_IND_CA_MARGE]#2
************** -
Reference partitioning and partition pruning
Hi All,
I am on v 11.2.0.3.
I have a pair of typical parent-child tables. Child table is growing like hell, hence we want to partition it, which will be used for deleting/dropping old data later on.
There is no partitioning key in the child table which I can use for relating the data to the time when data was created. So, I thought I can use the timestamp from parent table for partitioning the parent table and reference partition the child table.
I am more concerned about the child table (or the queries running on the child table) in terms of performance. ITEM_LIST_ID from the child table is extensively used in queries to access data from child table.
How will partition pruning work when the child table is queried on the foreign key? will it every time go to the parent table, find out the partition and then resolve the partition for child table?
The setup is given in the scripts below, will it cause lot of locking (to resolve partitions)? or am I worrying for nothing?
Here are the scripts
CREATE TABLE ITEM_LISTS /* Parent table, tens of thousands of records */
ITEM_LIST_ID NUMBER(10) NOT NULL PRIMARY KEY, /* Global index on partitioned table !!! */
LIST_NAME VARCHAR2(500) NOT NULL,
FIRST_INSERTED TIMESTAMP(6) NOT NULL
PARTITION BY RANGE ( FIRST_INSERTED )
partition p0 values less than ( to_date('20130101','YYYYMMDD') ),
partition p201301 values less than ( to_date('20130201','YYYYMMDD') ),
partition p201302 values less than ( to_date('20130301','YYYYMMDD') ),
partition p201303 values less than ( to_date('20130401','YYYYMMDD') ),
partition p201304 values less than ( to_date('20130501','YYYYMMDD') ),
partition p201305 values less than ( to_date('20130601','YYYYMMDD') )
CREATE INDEX ITEM_LISTS_IDX1 ON ITEM_LISTS ( LIST_NAME ) LOCAL ;
CREATE TABLE ITEM_LIST_DETAILS /* Child table, millions of records */
ITEM_ID NUMBER(10) NOT NULL,
ITEM_LIST_ID NUMBER(10) NOT NULL, /* Always used in WHERE clause by lots of big queries */
CODE VARCHAR2(30) NOT NULL,
ALT_CODE VARCHAR2(30) NOT NULL,
CONSTRAINT ITEM_LIST_DETAILS_FK
FOREIGN KEY ( ITEM_LIST_ID ) REFERENCES ITEM_LISTS
PARTITION BY REFERENCE ( ITEM_LIST_DETAILS_FK )
CREATE INDEX ITEM_LIST_DETAILS_IDX1 ON ITEM_LIST_DETAILS (ITEM_ID) LOCAL;
CREATE INDEX ITEM_LIST_DETAILS_IDX2 ON ITEM_LIST_DETAILS (ITEM_LIST_ID, CODE) LOCAL;Any thoughts / opinions / corrections ?
Thanks in advanceTo check how partition pruning works here, I inserted some data in these tables. Inserted data in ITEM_LISTS (parent) from DBA_OBJECTS ( object_id => item_list_id, object_name => list_name, first_inserted => manually created). Also created corresponding child data in ITEM_LIST_DETAILS, so that, for every item_list_id in parent about 5000 records go in child table.
Looking at the queries and plan below, my question is, what exactly does the operations "PARTITION REFERENCE SINGLE" and "PARTITION REFERENCE ITERATOR" imply ??
I gave a search on "PARTITION REFERENCE ITERATOR" in Oracle 11.2 documentation, it says "No exact match found" !!
/* Direct query on child table */
SQL> select count(*) from item_list_details where item_list_id = 6323 ;
COUNT(*)
5000
1 row selected.
Execution Plan
Plan hash value: 2798904155
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 5 | 22 (0)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | 5 | | | | |
| 2 | PARTITION REFERENCE SINGLE| | 5000 | 25000 | 22 (0)| 00:00:01 | KEY | KEY |
|* 3 | INDEX RANGE SCAN | ITEM_LIST_DETAILS_IDX2 | 5000 | 25000 | 22 (0)| 00:00:01 | KEY | KEY |
Predicate Information (identified by operation id):
3 - access("ITEM_LIST_ID"=6323)
SQL> select * from temp1; /* Dummy table to try out some joins */
OBJECT_ID OBJECT_NAME
6598 WRH$_INTERCONNECT_PINGS
1 row selected.
/* Query on child table, joining with some other table */
SQL> select count(*)
2 from temp1 d, ITEM_LIST_DETAILS i1
3 where d.object_id = i1.item_list_id
4 and d.object_name = 'WRH$_INTERCONNECT_PINGS';
COUNT(*)
5000
1 row selected.
Execution Plan
Plan hash value: 2288153583
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 70 | 24 (0)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | 70 | | | | |
| 2 | NESTED LOOPS | | 5000 | 341K| 24 (0)| 00:00:01 | | |
|* 3 | TABLE ACCESS FULL | TEMP1 | 1 | 65 | 3 (0)| 00:00:01 | | |
| 4 | PARTITION REFERENCE ITERATOR| | 5000 | 25000 | 21 (0)| 00:00:01 | KEY | KEY |
|* 5 | INDEX RANGE SCAN | ITEM_LIST_DETAILS_IDX2 | 5000 | 25000 | 21 (0)| 00:00:01 | KEY | KEY |
Predicate Information (identified by operation id):
3 - filter("D"."OBJECT_NAME"='WRH$_INTERCONNECT_PINGS')
5 - access("D"."OBJECT_ID"="I1"."ITEM_LIST_ID") -
Star transformation and Partition pruning
All experts,
I need advice on my situation -
I have data warehouse running on oracle 11.2.0.1
We are using star trnasformation. The fact table is partitioned.
However, with the star query (fact joined to dimensions with keys and filters only on dimensions), partition pruning is not happening.
I read some documents online and it seems that partition pruning is not going to happen unless I directly filter fact (which is against the best paractices of star query).
Please adviceSELECT
PTL_EDW.D_TIME.CAL_YYYYMM,
(( ( ( sum(PTL_EDWPERF.F_JOB_OIL_COST.LABOR_COST) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.OUTSIDE_COST) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.PARTS_COST) ) )-( ( sum(PTL_EDWPERF.F_JOB_OIL_COST.RECOVERY_LABOR_AMOUNT) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.RECOVERY_OUTSIDE_AMOUNT) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.RECOVERY_PARTS_AMOUNT) ) )+( ( sum(PTL_EDWPERF.F_JOB_OIL_COST.WARRANTY_LABOR_AMOUNT) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.WARRANTY_OUTSIDE_AMOUNT) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.WARRANTY_PARTS_AMOUNT) ) ) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.OIL_COST) ))
FROM
PTL_EDWPERF.F_JOB_OIL_COST,
PTL_EDW.D_LOCATION_MASTER D_LOCATION_DOMICILE,
PTL_EDW.D_VEHICLE_CAP_STATUS,
PTL_EDW.D_UNIT_MASTER,
PTL_EDW.D_ACCOUNT_CODE,
PTL_EDW.D_TIME
WHERE
( PTL_EDWPERF.F_JOB_OIL_COST.ACCOUNT_CODE_KEY = PTL_EDW.D_ACCOUNT_CODE.ACCOUNT_CODE_KEY)
AND ( PTL_EDWPERF.F_JOB_OIL_COST.VEHICLE_CAP_STATUS_KEY=PTL_EDW.D_VEHICLE_CAP_STATUS.VEHICLE_CAP_STATUS_KEY )
AND ( PTL_EDWPERF.F_JOB_OIL_COST.CHARGING_LOCATION_KEY=D_LOCATION_DOMICILE.LOCATION_MASTER_KEY )
AND (PTL_EDWPERF.F_JOB_OIL_COST.UNIT_MASTER_KEY = PTL_EDW.D_UNIT_MASTER.UNIT_MASTER_KEY)
AND (PTL_EDWPERF.F_JOB_OIL_COST.RO_ACCOUNTING_MONTH_KEY = PTL_EDW.D_TIME.TIME_KEY)
AND ( exists (select 1 from ptl_edw.s_location where s_location.ssoid = '600028988' and PTL_EDWPERF.F_JOB_OIL_COST.CHARGING_LOCATION_KEY = decode(s_location.location_master_key, -99999, PTL_EDWPERF.F_JOB_OIL_COST.CHARGING_LOCATION_KEY, s_location.location_master_key)) )
AND
--PTL_EDWPERF.F_JOB_OIL_COST.PARTITION_KEY BETWEEN 201011 AND 201104
PTL_EDW.D_TIME.CAL_YYYYMM BETWEEN 200601 AND 201104
AND
D_LOCATION_DOMICILE.CORP_CD IN ( '2000','HPTL' )
AND
( ( PTL_EDW.D_VEHICLE_CAP_STATUS.VEHICLE_CAP_STATUS ) IN ( 'ACCRUED','ACTIVE' ) )
AND
( PTL_EDW.D_UNIT_MASTER.CONTRACT_GROUP = 'P' )
AND
PTL_EDW.D_UNIT_MASTER.UNIT_CATEGORY IN ( 'TRACTOR','TRAILER','TRUCK' )
AND
PTL_EDW.D_ACCOUNT_CODE.ACCOUNT_CODE_GROUP1 IN ( 'COMMERCIAL RENTAL','CONTRACT MAINTENANCE - GUAR','CONTRACT MAINTENANCE - OTHER','CONTRACT MAINTENANCE - PEG','LEASE','TRAILER PLUS' )
GROUP BY
PTL_EDW.D_TIME.CAL_YYYYMM
-- bg4643wj2d3xn
=====================================
Elapsed: 00:39:35.08
Execution Plan
Plan hash value: 2317670688
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 9 | 666 | | 186K (1)| 00:43:36 | | |
| 1 | HASH GROUP BY | | 9 | 666 | | 186K (1)| 00:43:36 | | |
|* 2 | FILTER | | | | | | | | |
|* 3 | HASH JOIN | | 557K| 39M| | 186K (1)| 00:43:35 | | |
|* 4 | VIEW | index$_join$_006 | 1925 | 19250 | | 16 (7)| 00:00:01 | | |
|* 5 | HASH JOIN | | | | | | | | |
|* 6 | INDEX RANGE SCAN | D_TIME_CALYYYYMM_IDX2 | 1925 | 19250 | | 5 (20)| 00:00:01 | | |
| 7 | INDEX FAST FULL SCAN | D_TIME_TIME_KEY_PK | 1925 | 19250 | | 14 (0)| 00:00:01 | | |
|* 8 | HASH JOIN | | 557K| 34M| 32M| 186K (1)| 00:43:34 | | |
| 9 | PARTITION RANGE ALL | | 557K| 26M| | 131K (1)| 00:30:46 | 1 | 133 |
| 10 | TABLE ACCESS BY LOCAL INDEX ROWID| F_JOB_OIL_COST | 557K| 26M| | 131K (1)| 00:30:46 | 1 | 133 |
| 11 | BITMAP CONVERSION TO ROWIDS | | | | | | | | |
| 12 | BITMAP AND | | | | | | | | |
| 13 | BITMAP MERGE | | | | | | | | |
| 14 | BITMAP KEY ITERATION | | | | | | | | |
| 15 | BUFFER SORT | | | | | | | | |
|* 16 | VIEW | index$_join$_179 | 2 | 20 | | 2 (50)| 00:00:01 | | |
|* 17 | HASH JOIN | | | | | | | | |
| 18 | INLIST ITERATOR | | | | | | | | |
|* 19 | INDEX UNIQUE SCAN | D_CAPSTS_ETL_IDX | 2 | 20 | | 0 (0)| 00:00:01 | | |
| 20 | INDEX FAST FULL SCAN | D_VEHICLE_CAP_STATUS_PK | 2 | 20 | | 1 (0)| 00:00:01 | | |
|* 21 | BITMAP INDEX RANGE SCAN | BIMAP_JOBOIL_COST_VEH_CAP_KY | | | | | | 1 | 133 |
| 22 | BITMAP MERGE | | | | | | | | |
| 23 | BITMAP KEY ITERATION | | | | | | | | |
| 24 | BUFFER SORT | | | | | | | | |
|* 25 | TABLE ACCESS FULL | D_TIME | 1925 | 51975 | | 19 (6)| 00:00:01 | | |
|* 26 | BITMAP INDEX RANGE SCAN | BIMAP_JOBOIL_CST_RO_ACC_MTH_KY | | | | | | 1 | 133 |
| 27 | BITMAP MERGE | | | | | | | | |
| 28 | BITMAP KEY ITERATION | | | | | | | | |
| 29 | BUFFER SORT | | | | | | | | |
|* 30 | TABLE ACCESS FULL | D_ACCOUNT_CODE | 11 | 165 | | 4 (0)| 00:00:01 | | |
|* 31 | BITMAP INDEX RANGE SCAN | BIMAP_JOBOIL_COST_ACCT_CODE_KY | | | | | | 1 | 133 |
| 32 | BITMAP MERGE | | | | | | | | |
| 33 | BITMAP KEY ITERATION | | | | | | | | |
| 34 | BUFFER SORT | | | | | | | | |
|* 35 | VIEW | index$_join$_172 | 3136 | 28224 | | 19 (6)| 00:00:01 | | |
|* 36 | HASH JOIN | | | | | | | | |
| 37 | INLIST ITERATOR | | | | | | | | |
|* 38 | INDEX RANGE SCAN | D_LOCNMST_ETL_IDX | 3136 | 28224 | | 12 (17)| 00:00:01 | | |
| 39 | INDEX FAST FULL SCAN | LOCATION_MASTER_KEY_PK | 3136 | 28224 | | 10 (0)| 00:00:01 | | |
|* 40 | BITMAP INDEX RANGE SCAN | BIMAP_JOBOIL_COST_CHRG_LOCN_KY | | | | | | 1 | 133 |
|* 41 | TABLE ACCESS FULL | D_UNIT_MASTER | 1790K| 23M| | 51484 (2)| 00:12:01 | | |
|* 42 | TABLE ACCESS BY INDEX ROWID | S_LOCATION | 1 | 23 | | 12 (0)| 00:00:01 | | |
|* 43 | INDEX RANGE SCAN | S_LOCN_SSOID_IDX | 14 | | | 1 (0)| 00:00:01 | | |
Predicate Information (identified by operation id):
2 - filter( EXISTS (SELECT 0 FROM "PTL_EDW"."S_LOCATION" "S_LOCATION" WHERE "S_LOCATION"."SSOID"='600028988' AND
DECODE("S_LOCATION"."LOCATION_MASTER_KEY",(-99999),:B1,"S_LOCATION"."LOCATION_MASTER_KEY")=:B2))
3 - access("F_JOB_OIL_COST"."RO_ACCOUNTING_MONTH_KEY"="D_TIME"."TIME_KEY")
4 - filter("D_TIME"."CAL_YYYYMM">=200601 AND "D_TIME"."CAL_YYYYMM"<=201104)
5 - access(ROWID=ROWID)
6 - access("D_TIME"."CAL_YYYYMM">=200601 AND "D_TIME"."CAL_YYYYMM"<=201104)
8 - access("F_JOB_OIL_COST"."UNIT_MASTER_KEY"="D_UNIT_MASTER"."UNIT_MASTER_KEY")
16 - filter("D_VEHICLE_CAP_STATUS"."VEHICLE_CAP_STATUS"='ACCRUED' OR "D_VEHICLE_CAP_STATUS"."VEHICLE_CAP_STATUS"='ACTIVE')
17 - access(ROWID=ROWID)
19 - access("D_VEHICLE_CAP_STATUS"."VEHICLE_CAP_STATUS"='ACCRUED' OR "D_VEHICLE_CAP_STATUS"."VEHICLE_CAP_STATUS"='ACTIVE')
21 - access("F_JOB_OIL_COST"."VEHICLE_CAP_STATUS_KEY"="D_VEHICLE_CAP_STATUS"."VEHICLE_CAP_STATUS_KEY")
25 - filter("D_TIME"."CAL_YYYYMM">=200601 AND "D_TIME"."CAL_YYYYMM"<=201104)
26 - access("F_JOB_OIL_COST"."RO_ACCOUNTING_MONTH_KEY"="D_TIME"."TIME_KEY")
30 - filter("D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='COMMERCIAL RENTAL' OR "D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='CONTRACT MAINTENANCE
- GUAR' OR "D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='CONTRACT MAINTENANCE - OTHER' OR "D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='CONTRACT
MAINTENANCE - PEG' OR "D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='LEASE' OR "D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='TRAILER PLUS')
31 - access("F_JOB_OIL_COST"."ACCOUNT_CODE_KEY"="D_ACCOUNT_CODE"."ACCOUNT_CODE_KEY")
35 - filter("D_LOCATION_DOMICILE"."CORP_CD"='2000' OR "D_LOCATION_DOMICILE"."CORP_CD"='HPTL')
36 - access(ROWID=ROWID)
38 - access("D_LOCATION_DOMICILE"."CORP_CD"='2000' OR "D_LOCATION_DOMICILE"."CORP_CD"='HPTL')
40 - access("F_JOB_OIL_COST"."CHARGING_LOCATION_KEY"="D_LOCATION_DOMICILE"."LOCATION_MASTER_KEY")
41 - filter("D_UNIT_MASTER"."CONTRACT_GROUP"='P' AND ("D_UNIT_MASTER"."UNIT_CATEGORY"='TRACTOR' OR
"D_UNIT_MASTER"."UNIT_CATEGORY"='TRAILER' OR "D_UNIT_MASTER"."UNIT_CATEGORY"='TRUCK'))
42 - filter(DECODE("S_LOCATION"."LOCATION_MASTER_KEY",(-99999),:B1,"S_LOCATION"."LOCATION_MASTER_KEY")=:B2)
43 - access("S_LOCATION"."SSOID"='600028988')
Note
- star transformation used for this statement
Statistics
3034 recursive calls
0 db block gets
28519518 consistent gets
1075291 physical reads
0 redo size
2519 bytes sent via SQL*Net to client
567 bytes received via SQL*Net from client
6 SQL*Net roundtrips to/from client
4 sorts (memory)
0 sorts (disk)
64 rows processed
Partition is range on YYYYMM(numeric format) -
Partition pruning doesn't work
Hi all,
in this query I've joined 3 tables, each of them partitioned along the field PARTITION_KEY_PRE:
SELECT *
FROM t_cp_pp_basdat basdat LEFT OUTER JOIN t_cp_pp_custom custom
ON basdat.pre_processing_id = custom.pre_processing_id
AND basdat.partition_key_pre = custom.partition_key_pre
AND basdat.customer_unique_id_f = custom.customer_unique_id_f
LEFT OUTER JOIN t_cp_pp_groups groups
ON basdat.partition_key_pre = groups.partition_key_pre
AND basdat.pre_processing_id = groups.pre_processing_id
AND custom.customer_group_id = groups.customer_group_id
WHERE basdat.partition_key_pre = '111100361A0700';
The problem is that the T_CP_PP_GROUPS table don't prune; if I remove the condition
custom.customer_group_id = groups.customer_group_id
the prune works, but obviously the query is wrong. Here it is the explain plan
Operation Object Name Cost Object Node In/Out PStart PStop
SELECT STATEMENT Optimizer Mode=ALL_ROWS 6156
PX COORDINATOR
PX SEND QC (RANDOM) SYS.:TQ10003 6156 :Q1003 P->S QC (RANDOM)
HASH JOIN OUTER 6156 :Q1003 PCWP
PX RECEIVE 50 :Q1003 PCWP
PX SEND PARTITION (KEY) SYS.:TQ10002 50 :Q1002 P->P PART (KEY)
VIEW 50 :Q1002 PCWP
HASH JOIN RIGHT OUTER BUFFERED 50 :Q1002 PCWP
PX RECEIVE 5 :Q1002 PCWP
PX SEND HASH SYS.:TQ10000 5 :Q1000 P->P HASH
PX BLOCK ITERATOR 5 :Q1000 PCWC KEY KEY
TABLE ACCESS FULL TUKB103.T_CP_PP_CUSTOM 5 :Q1000 PCWP 466 466
PX RECEIVE 44 :Q1002 PCWP
PX SEND HASH SYS.:TQ10001 44 :Q1001 P->P HASH
PX BLOCK ITERATOR 44 :Q1001 PCWC KEY KEY
TABLE ACCESS FULL TUKB103.T_CP_PP_BASDAT 44 :Q1001 PCWP 1437 1437
PX PARTITION LIST ALL 6013 :Q1003 PCWC 1 635
TABLE ACCESS FULL TUKB103.T_CP_PP_GROUPS 6013 :Q1003 PCWP 1 635
Can anyone help me to tune this query?
Thanks,
DavidePlease learn to use { code } tags. Since that makes you code to read much better in the forum. See the FAQ for further instructions on that.
About the pruning question.
You could experiment with different types of joins.
a) Join the GROUPS table with the columns from CUSTOM
SELECT *
FROM t_cp_pp_basdat basdat
LEFT OUTER JOIN t_cp_pp_custom custom
ON basdat.pre_processing_id = custom.pre_processing_id
AND basdat.partition_key_pre = custom.partition_key_pre
AND basdat.customer_unique_id_f = custom.customer_unique_id_f
LEFT OUTER JOIN t_cp_pp_groups groups
ON custom.partition_key_pre = groups.partition_key_pre
AND custom.pre_processing_id = groups.pre_processing_id
AND custom.customer_group_id = groups.customer_group_id
WHERE basdat.partition_key_pre = '111100361A0700'; b) Put the partion key into each on clause.
SELECT *
FROM t_cp_pp_basdat basdat
LEFT OUTER JOIN t_cp_pp_custom custom
ON basdat.pre_processing_id = custom.pre_processing_id
AND custom.partition_key_pre = '111100361A0700'
AND basdat.customer_unique_id_f = custom.customer_unique_id_f
LEFT OUTER JOIN t_cp_pp_groups groups
ON custom.partition_key_pre = '111100361A0700'
AND basdat.pre_processing_id = groups.pre_processing_id
AND custom.customer_group_id = groups.customer_group_id
WHERE basdat.partition_key_pre = '111100361A0700'; Did you consider to add subpartions to your tables? You could profit from some partition wise joins. Customer_Unique_ID would be a candidate for a hash subpartition. -
Partition pruning in the partition_wise join
Given tables table1 partitioned by hash on client_id column, and another table2 equipartitioned (hash on client_id column) I want to get both tables joined, but read the data partition by partition (in serial or from multiple client sessions). How to do this?
select * from table1 T1, table2 T2
where t1.client_id = t2.client_id
The query above works fine - it DOES partition_wise join, but i cant use it since huge amount of rows it returns. Id like to use
select *
from table1 partition (P1) T1 ,
table2 T2
where t1.client_id = t2.client_id
But in this case Oracle does not prune all Table2 partitions - it makes join between 1st partition of Table1 and all partitions of Table2. First question is why?
I can fix it by pointing table2 partition too, then second question is - how can I be sure that all corresponding partitions with the same order number (given uniform partitioning for several tables) contain same keys?Using composite changes nothing. I've realized the problem - partition pruning is performed basing on "where" clause content. So, using "select from partition"
does not affect a joined table. Probably, creating "partition_id" column filled with
custom hash would solve the problem. -
Partition Pruning vs Partition-Wise Join
Hi,
I am not sure if this is the right place for this question, but here it goes.
I am in a situation where in the begining I have to join two big tables without any where clauses. It is pretty much a Caretsian Product where a criteria meets (Internal Code), but I have to join all rows. (Seems like a good place for Partition-Wise Join).
Later I only need to update certain rows based on a key value (Customer ID, Region ID). (Good candidate for Partition Pruning).
What would be the best option. Is there a way to use both?
Assume that following:
Table 1 has the structure of
Customer ID
Internal Code
Other Data
There are about 1000 Customer ID. Each Customer ID has 1000 Internal Codes.
Table 2 has the structure of
Region ID
Internal Code
Other Data
There are about 5000 Region ID. Each Region ID has 1000 Internal Codes(same as Table 1).
I am currently thinking of doing a HASH PARTITION (8 partitions) on Customer ID for Table 1 and HASH PARTITION (8 partitions) on Region ID for Table 2.
The initial insert will take a long time, but when I go to update the joined data based on specific Customer ID, or Region ID atleast from one Table only one Partition will be used.
I would sincerely appreciate some advice from the gurus.
Thanks...Hi,
I still don't understand what it is that you are trying to do.
Would it be possible for you to create a silly example with just a few rows
to show us what it is that you are trying to accomplish?
Then we can help you solve whatever problem it is that you are having.
create table t1(
customer_id number not null
,internal_code varchar2(20) not null
,<other_columns>
,constraint t1_pk primary key(customer_id, internal_code)
create table t2(
region_id number not null
,internal_code varchar2(20) not null
,<other_columns>
,constraint t2_pk primary key(region_id, internal_code)
insert into t1(customer_id, internal_code, ...) values(...);
insert into t1(customer_id, internal_code, ...) values(...);
insert into t2(region_id, internal_code, ...) values(...);
insert into t2(region_id, internal_code, ...) values(...);
select <the rating calculation>
from t1 join t2 using(internal_code); -
Partition Pruning Aint Happening
I have a situation where Oracle pruning is not happening and this situation is getting worse when the search criteria is close to current date.
Table has a date based partition. SQL Statement has 2 partitioned tables. Date range is applied on a relatively smaller daily partitioned table and further joined to the next table (Its also date based partition). First table has partition column in the where clause and it joins to the next table using the partitioned column.
SQL does partition pruning even for a month range search if the date range is in August. It will do partition pruning only for 25 days for september where clause. Likewise the where clause date range ability for partition pruning goes down and It will only do partition pruning for where clause with 5 days. If the where clause has more than 6 days (Mar 01 Thru Mar 06) in March 2009, Oracle does All partitions.
Query is examined and it contains partition column in the where clause and we have also gathered 100% statistics of the table which is not partition pruning. Data growth is happening relatively each month.
Sample: -
Select 1
From TAB1, TAB2
Where TAB1.SELECT_DATE >= '01JAN2009
And TAB1.SELECT_DATE <= '31JAN2009
And TAB2.DATE_SELECT = TAB1.DATE_SELECT
TAB1 Is a daily partition with SELECT_DATE column. Oracle is able to successfully do partition pruning on this table. But TAB2 partition pruning is not happening.
How I can overcome this situation? Thanks for your help.
Here is the explain plan for the SQL statement| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1224 | 96696 | | 978K (4)| 01:21:35 | | |
| 1 | HASH GROUP BY | | 1224 | 96696 | | 978K (4)| 01:21:35 | | |
|* 2 | HASH JOIN | | 1122K| 84M| 49M| 978K (4)| 01:21:34 | | |
|* 3 | HASH JOIN | | 1122K| 36M| | 5218 (4)| 00:00:27 | | |
| 4 | COLLECTION ITERATOR PICKLER FETCH| TABLE FUNC | | | | | | | |
| 5 | PARTITION RANGE ITERATOR | | 729K| 22M| | 5145 (3)| 00:00:26 | 413 | 422 |
| 6 | PARTITION LIST ALL | | 729K| 22M| | 5145 (3)| 00:00:26 | 1 | 2 |
|* 7 | MAT_VIEW ACCESS FULL | TAB_01 | 729K| 22M| | 5145 (3)| 00:00:26 | 825 | 844 |
| 8 | PARTITION RANGE ALL | | 84M| 3623M| | 575K (5)| 00:47:59 | 1 | 970 |
| 9 | TABLE ACCESS FULL | TAB_02 | 84M| 3623M| | 575K (5)| 00:47:59 | 1 | 970 |
Predicate Information (identified by operation id):
2 - access("TAB_02"."SELECT_DATE"="TAB_01"."SELECT_DATE" AND "TAB_02"."SELECT_NUMBER"="TAB_01"."SELECT_NUMBER")
3 - access("TAB_01"."TAG_ID"=SYS_OP_ATG(VALUE(KOKBF$),16,17,2))
7 - filter("TAB_01"."SELECT_DATE"<=TO_DATE('2009-02-10 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))Following is the explain paln where partition elimination happening for a shorter date range search
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 714 | 56406 | 851K (1)| 01:10:56 | | |
| 1 | HASH GROUP BY | | 714 | 56406 | 851K (1)| 01:10:56 | | |
| 2 | NESTED LOOPS | | 621K| 46M| 850K (1)| 01:10:55 | | |
|* 3 | HASH JOIN | | 621K| 20M| 3210 (3)| 00:00:17 | | |
| 4 | COLLECTION ITERATOR PICKLER FETCH| TABLE FUNC | | | | | | |
| 5 | PARTITION RANGE ITERATOR | | 403K| 12M| 3152 (3)| 00:00:16 | 413 | 418 |
| 6 | PARTITION LIST ALL | | 403K| 12M| 3152 (3)| 00:00:16 | 1 | 2 |
|* 7 | MAT_VIEW ACCESS FULL | TAB_01 | 403K| 12M| 3152 (3)| 00:00:16 | 825 | 836 |
| 8 | PARTITION RANGE ITERATOR | | 1 | 45 | 2 (0)| 00:00:01 | KEY | KEY |
| 9 | TABLE ACCESS BY LOCAL INDEX ROWID| TAB_02 | 1 | 45 | 2 (0)| 00:00:01 | KEY | KEY |
|* 10 | INDEX RANGE SCAN | TAB_02_PK | 1 | | 1 (0)| 00:00:01 | KEY | KEY |
Predicate Information (identified by operation id):
3 - access("TAB_01"."TAG_ID"=SYS_OP_ATG(VALUE(KOKBF$),16,17,2))
7 - filter("TAB_01"."SELECT_DATE"<=TO_DATE('2009-02-06 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))
10 - access("TAB_02"."SELECT_DATE"="TAB_01"."SELECT_DATE" AND "TAB_02"."SELECT_NUMBER"="TAB_01"."SELECT_NUMBER")Query where partition elimination not happening on the second table is having date range of 7 days or more. SO the first explain plan is for Feb-01 Thru Feb 10 search
Query where partition elimination happening on the second table is having date range of 7 days or less. The second explain plan is for Feb-01 Thru Feb-06 search
This is great.
Edited by: user10929035 on Mar 24, 2009 8:18 AM -
Partition pruning not working for partitioned table joins
Hi,
We are joining 4 partitioned tables on partition column & other key columns. And we are filtering the driving table on partition key. But explain plan is showing that all tables except the driving table are not partition pruning and scanning all partitions.Is there any limitation that filter condition cannot be dynamic?
Thanks a lot in advance.
Here are the details...
SELECT a.pay_prd_id,
a.a_id,
a.a_evnt_no
FROM b,
c,
a,
d
WHERE ( a.pay_prd_id = b.pay_prd_id ---partition range all
AND a.a_evnt_no = b.b_evnt_no
AND a.a_id = b.b_id
AND ( a.pay_prd_id = c.pay_prd_id---partition range all
AND a.a_evnt_no = c.c_evnt_no
AND a.a_id = c.c_id
AND ( a.pay_prd_id = d.pay_prd_id---partition range all
AND a.a_evnt_no = d.d_evnt_no
AND a.a_id = d.d_id
AND (a.pay_prd_id = ---partition range single
CASE '201202'
WHEN 'YYYYMM'
THEN (SELECT min(pay_prd_id)
FROM pay_prd
WHERE pay_prd_stat_cd = 2)
ELSE TO_NUMBER ('201202', '999999')
END
DDLs.
create table pay_prd
pay_prd_id number(6),
pay_prd_stat_cd integer,
pay_prd_stat_desc varchar2(20),
a_last_upd_dt DATE
insert into pay_prd
select 201202,2,'OPEN',sysdate from dual
union all
select 201201,1,'CLOSE',sysdate from dual
union all
select 201112,1,'CLOSE',sysdate from dual
union all
select 201111,1,'CLOSE',sysdate from dual
union all
select 201110,1,'CLOSE',sysdate from dual
union all
select 201109,1,'CLOSE',sysdate from dual
CREATE TABLE A
(PAY_PRD_ID NUMBER(6) NOT NULL,
A_ID NUMBER(9) NOT NULL,
A_EVNT_NO NUMBER(3) NOT NULL,
A_DAYS NUMBER(3),
A_LAST_UPD_DT DATE
PARTITION BY RANGE (PAY_PRD_ID)
INTERVAL( 1)
PARTITION A_0001 VALUES LESS THAN (201504)
ENABLE ROW MOVEMENT;
ALTER TABLE A ADD CONSTRAINT A_PK PRIMARY KEY (PAY_PRD_ID,A_ID,A_EVNT_NO) USING INDEX LOCAL;
insert into a
select 201202,1111,1,65,sysdate from dual
union all
select 201202,1111,2,75,sysdate from dual
union all
select 201202,1111,3,85,sysdate from dual
union all
select 201202,1111,4,95,sysdate from dual
CREATE TABLE B
(PAY_PRD_ID NUMBER(6) NOT NULL,
B_ID NUMBER(9) NOT NULL,
B_EVNT_NO NUMBER(3) NOT NULL,
B_DAYS NUMBER(3),
B_LAST_UPD_DT DATE
PARTITION BY RANGE (PAY_PRD_ID)
INTERVAL( 1)
PARTITION B_0001 VALUES LESS THAN (201504)
ENABLE ROW MOVEMENT;
ALTER TABLE B ADD CONSTRAINT B_PK PRIMARY KEY (PAY_PRD_ID,B_ID,B_EVNT_NO) USING INDEX LOCAL;
insert into b
select 201202,1111,1,15,sysdate from dual
union all
select 201202,1111,2,25,sysdate from dual
union all
select 201202,1111,3,35,sysdate from dual
union all
select 201202,1111,4,45,sysdate from dual
CREATE TABLE C
(PAY_PRD_ID NUMBER(6) NOT NULL,
C_ID NUMBER(9) NOT NULL,
C_EVNT_NO NUMBER(3) NOT NULL,
C_DAYS NUMBER(3),
C_LAST_UPD_DT DATE
PARTITION BY RANGE (PAY_PRD_ID)
INTERVAL( 1)
PARTITION C_0001 VALUES LESS THAN (201504)
ENABLE ROW MOVEMENT;
ALTER TABLE C ADD CONSTRAINT C_PK PRIMARY KEY (PAY_PRD_ID,C_ID,C_EVNT_NO) USING INDEX LOCAL;
insert into c
select 201202,1111,1,33,sysdate from dual
union all
select 201202,1111,2,44,sysdate from dual
union all
select 201202,1111,3,55,sysdate from dual
union all
select 201202,1111,4,66,sysdate from dual
CREATE TABLE D
(PAY_PRD_ID NUMBER(6) NOT NULL,
D_ID NUMBER(9) NOT NULL,
D_EVNT_NO NUMBER(3) NOT NULL,
D_DAYS NUMBER(3),
D_LAST_UPD_DT DATE
PARTITION BY RANGE (PAY_PRD_ID)
INTERVAL( 1)
PARTITION D_0001 VALUES LESS THAN (201504)
ENABLE ROW MOVEMENT;
ALTER TABLE D ADD CONSTRAINT D_PK PRIMARY KEY (PAY_PRD_ID,D_ID,D_EVNT_NO) USING INDEX LOCAL;
insert into c
select 201202,1111,1,33,sysdate from dual
union all
select 201202,1111,2,44,sysdate from dual
union all
select 201202,1111,3,55,sysdate from dual
union all
select 201202,1111,4,66,sysdate from dualBelow query generated from Business Objects and submitted to Database (the case statement is generated by BO). Cant we use Case/Subquery/Decode etc for the partitioned column? We are assuming that the case causing the issue to not to dynamic partition elimination on the other joined partitioned tables (TAB_B_RPT, TAB_C_RPT).
SELECT TAB_D_RPT.acvy_amt,
TAB_A_RPT.itnt_typ_desc,
TAB_A_RPT.ls_typ_desc,
TAB_A_RPT.evnt_no,
TAB_C_RPT.pay_prd_id,
TAB_B_RPT.id,
TAB_A_RPT.to_mdfy,
TAB_A_RPT.stat_desc
FROM TAB_D_RPT,
TAB_C_RPT fee_rpt,
TAB_C_RPT,
TAB_A_RPT,
TAB_B_RPT
WHERE (TAB_B_RPT.id = TAB_A_RPT.id)
AND ( TAB_A_RPT.pay_prd_id = TAB_D_RPT.pay_prd_id -- expecting Partition Range Single, but doing Partition Range ALL
AND TAB_A_RPT.evnt_no = TAB_D_RPT.evnt_no
AND TAB_A_RPT.id = TAB_D_RPT.id
AND ( TAB_A_RPT.pay_prd_id = TAB_C_RPT.pay_prd_id -- expecting Partition Range Single, but doing Partition Range ALL
AND TAB_A_RPT.evnt_no = TAB_C_RPT.evnt_no
AND TAB_A_RPT.id = TAB_C_RPT.id
AND ( TAB_A_RPT.pay_prd_id = fee_rpt.pay_prd_id -- expecting Partition Range Single
AND TAB_A_RPT.evnt_no = fee_rpt.evnt_no
AND TAB_A_RPT.id = fee_rpt.id
AND (TAB_A_RPT.rwnd_ind = 'N')
AND (TAB_A_RPT.pay_prd_id =
CASE '201202'
WHEN 'YYYYMM'
THEN (SELECT DISTINCT pay_prd.pay_prd_id
FROM pay_prd
WHERE pay_prd.stat_cd = 2)
ELSE TO_NUMBER ('201202', '999999')
END
And its explain plan is...
Plan
SELECT STATEMENT ALL_ROWS Cost: 79 K Bytes: 641 M Cardinality: 3 M
18 HASH JOIN Cost: 79 K Bytes: 641 M Cardinality: 3 M
3 PART JOIN FILTER CREATE SYS.:BF0000 Cost: 7 K Bytes: 72 M Cardinality: 3 M
2 PARTITION RANGE ALL Cost: 7 K Bytes: 72 M Cardinality: 3 M Partition #: 3 Partitions accessed #1 - #1048575
1 TABLE ACCESS FULL TABLE TAB_D_RPT Cost: 7 K Bytes: 72 M Cardinality: 3 M Partition #: 3 Partitions accessed #1 - #1048575
17 HASH JOIN Cost: 57 K Bytes: 182 M Cardinality: 874 K
14 PART JOIN FILTER CREATE SYS.:BF0001 Cost: 38 K Bytes: 87 M Cardinality: 914 K
13 HASH JOIN Cost: 38 K Bytes: 87 M Cardinality: 914 K
6 PART JOIN FILTER CREATE SYS.:BF0002 Cost: 8 K Bytes: 17 M Cardinality: 939 K
5 PARTITION RANGE ALL Cost: 8 K Bytes: 17 M Cardinality: 939 K Partition #: 9 Partitions accessed #1 - #1048575
4 TABLE ACCESS FULL TABLE TAB_C_RPT Cost: 8 K Bytes: 17 M Cardinality: 939 K Partition #: 9 Partitions accessed #1 - #1048575
12 HASH JOIN Cost: 24 K Bytes: 74 M Cardinality: 957 K
7 INDEX FAST FULL SCAN INDEX (UNIQUE) TAB_B_RPT_PK Cost: 675 Bytes: 10 M Cardinality: 941 K
11 PARTITION RANGE SINGLE Cost: 18 K Bytes: 65 M Cardinality: 970 K Partition #: 13 Partitions accessed #KEY(AP)
10 TABLE ACCESS FULL TABLE TAB_A_RPT Cost: 18 K Bytes: 65 M Cardinality: 970 K Partition #: 13 Partitions accessed #KEY(AP)
9 HASH UNIQUE Cost: 4 Bytes: 14 Cardinality: 2
8 TABLE ACCESS FULL TABLE PAY_PRD Cost: 3 Bytes: 14 Cardinality: 2
16 PARTITION RANGE JOIN-FILTER Cost: 8 K Bytes: 106 M Cardinality: 939 K Partition #: 17 Partitions accessed #:BF0001
15 TABLE ACCESS FULL TABLE TAB_C_RPT Cost: 8 K Bytes: 106 M Cardinality: 939 K Partition #: 17 Partitions accessed #:BF0001
Thanks Again. -
Partition pruning, Nested loops
Hi,
I am having a problem with getting partition pruning in a query. I've managed to dumb down the problem to two tables and a minimal query (see below).
Basically, I have a partitioned table "Yearly Facts", and a helper table "Current Year" that always contain 1 row. The sole purpose of this one row is to tell what the curent year is, what the previous year was and what the next year will be. (In the real problem, there are non-standard timeperiods, so one cannot just calculate previous and next by adding/subtracting 1 as would be possible in this example).
The following query is executed the way I want.
It performs a scan on current_year, and then nested loop into the facts. And partition pruning was happening.
select sum(decode(a.year_key, b.curr_year, some_measure)) as curr_year_measure
from yearly_fact_t a
,current_year b
where a.year_key = b.curr_year;
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 39 | 4 (0)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | 39 | | | | |
| 2 | NESTED LOOPS | | 1 | 39 | 4 (0)| 00:00:01 | | |
| 3 | INDEX FAST FULL SCAN | SYS_C00247890 | 1 | 13 | 2 (0)| 00:00:01 | | |
| 4 | PARTITION RANGE ITERATOR| | 1 | 26 | 2 (0)| 00:00:01 | KEY | KEY |
|* 5 | TABLE ACCESS FULL | YEARLY_FACT_T | 1 | 26 | 2 (0)| 00:00:01 | KEY | KEY |
Predicate Information (identified by operation id):
5 - filter("A"."YEAR_KEY"="B"."CURR_YEAR")The following query is where I have my problem.
The basic xplan is the same, but for some reason the cbo gave up and decide to scan all partitions, which was not very scalable on production data :)
I would have thought that the plan would be the same.
select sum(decode(a.year_key, b.curr_year, some_measure)) as curr_year_measure
,sum(decode(a.year_key, b.prev_year, some_measure)) as prev_year_measure
from yearly_fact_t a
,current_year b
where a.year_key = b.curr_year
or a.year_key = b.prev_year;
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 52 | 13 (0)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | 52 | | | | |
| 2 | NESTED LOOPS | | 4 | 208 | 13 (0)| 00:00:01 | | |
| 3 | TABLE ACCESS FULL | CURRENT_YEAR | 1 | 26 | 4 (0)| 00:00:01 | | |
| 4 | PARTITION RANGE ALL| | 4 | 104 | 9 (0)| 00:00:01 | 1 | 6 |
|* 5 | TABLE ACCESS FULL | YEARLY_FACT_T | 4 | 104 | 9 (0)| 00:00:01 | 1 | 6 |
Predicate Information (identified by operation id):
5 - filter("A"."YEAR_KEY"="B"."CURR_YEAR" OR "A"."YEAR_KEY"="B"."PREV_YEAR")
-- drop table yearly_fact_t purge;
-- drop table current_year purge;
create table current_year(
curr_year number(4) not null
,prev_year number(4) not null
,next_year number(4) not null
,primary key(curr_year)
,unique(prev_year)
,unique(next_year)
insert into current_year(curr_year, prev_year, next_year) values(2010, 2009, 2011);
commit;
create table yearly_fact_t(
year_key number(4) not null
,some_dim_key number not null
,some_measure number not null
partition by range(year_key)(
partition p2007 values less than(2008)
,partition p2008 values less than(2009)
,partition p2009 values less than(2010)
,partition p2010 values less than(2011)
,partition p2011 values less than(2012)
,partition pmax values less than(maxvalue)
insert into yearly_fact_t(year_key, some_dim_key, some_measure) values(2007,1, 10);
insert into yearly_fact_t(year_key, some_dim_key, some_measure) values(2008,1, 20);
insert into yearly_fact_t(year_key, some_dim_key, some_measure) values(2009,1, 30);
insert into yearly_fact_t(year_key, some_dim_key, some_measure) values(2010,1, 40);
commit; What can I do to get partition pruning to happen in the second query?
Or even better, what is it in my query that prevents it from happening?
We're running Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit.
Best regards
RonnieHi Ronnie,
Check whether your statistics are up to date.
SQL> set autotrace traceonly exp
SQL> select sum(decode(a.year_key, b.curr_year, some_measure)) as curr_year_measure
2 ,sum(decode(a.year_key, b.prev_year, some_measure)) as prev_year_measure
3 from yearly_fact_t a
4 ,current_year b
5 where a.year_key = b.curr_year
6 or a.year_key = b.prev_year;
Execution Plan
Plan hash value: 229094315
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 52 | 10 (0)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | 52 | | | | |
| 2 | NESTED LOOPS | | 4 | 208 | 10 (0)| 00:00:01 | | |
| 3 | TABLE ACCESS FULL | CURRENT_YEAR | 1 | 26 | 3 (0)| 00:00:01 | | |
| 4 | PARTITION RANGE ALL| | 4 | 104 | 7 (0)| 00:00:01 | 1 | 6 |
|* 5 | TABLE ACCESS FULL | YEARLY_FACT_T | 4 | 104 | 7 (0)| 00:00:01 | 1 | 6 |
Predicate Information (identified by operation id):
5 - filter("A"."YEAR_KEY"="B"."CURR_YEAR" OR "A"."YEAR_KEY"="B"."PREV_YEAR")
Note
- dynamic sampling used for this statement
SQL> set autotrace off
SQL> exec dbms_stats.gather_table_stats(user, 'current_year', estimate_percent=>100, cascade=>true, method_opt
=>'for all columns size 1');
PL/SQL procedure successfully completed.
SQL>
SQL> exec dbms_stats.gather_table_stats(user, 'yearly_fact_t', estimate_percent=>100, cascade=>true, method_op
t=>'for all columns size 1');
PL/SQL procedure successfully completed.
SQL> set autotrace traceonly exp
SQL> select sum(decode(a.year_key, b.curr_year, some_measure)) as curr_year_measure
2 ,sum(decode(a.year_key, b.prev_year, some_measure)) as prev_year_measure
3 from yearly_fact_t a
4 ,current_year b
5 where a.year_key = b.curr_year
6 or a.year_key = b.prev_year;
Execution Plan
Plan hash value: 2253546831
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 15 | 8 (0)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | 15 | | | | |
| 2 | CONCATENATION | | | | | | | |
| 3 | NESTED LOOPS | | 1 | 15 | 4 (0)| 00:00:01 | | |
| 4 | TABLE ACCESS FULL | CURRENT_YEAR | 1 | 8 | 3 (0)| 00:00:01 | | |
| 5 | PARTITION RANGE ITERATOR| | 1 | 7 | 1 (0)| 00:00:01 | KEY | KEY |
|* 6 | TABLE ACCESS FULL | YEARLY_FACT_T | 1 | 7 | 1 (0)| 00:00:01 | KEY | KEY |
| 7 | NESTED LOOPS | | 1 | 15 | 4 (0)| 00:00:01 | | |
| 8 | TABLE ACCESS FULL | CURRENT_YEAR | 1 | 8 | 3 (0)| 00:00:01 | | |
| 9 | PARTITION RANGE ITERATOR| | 1 | 7 | 1 (0)| 00:00:01 | KEY | KEY |
|* 10 | TABLE ACCESS FULL | YEARLY_FACT_T | 1 | 7 | 1 (0)| 00:00:01 | KEY | KEY |
Predicate Information (identified by operation id):
6 - filter("A"."YEAR_KEY"="B"."PREV_YEAR")
10 - filter("A"."YEAR_KEY"="B"."CURR_YEAR" AND LNNVL("A"."YEAR_KEY"="B"."PREV_YEAR"))
SQL> set autotrace off
SQL>Asif Momen
http://momendba.blogspot.com
Maybe you are looking for
-
I imported my DV footage and edited my project. Now how do I burn it to a DVD? My previous version of iMovie allowed you to export the project to iDVD. How do you make a dvd from you imovie project in imovie09?
-
bank page not opening n it's giving error that ur browser don't have java. am using ur browser in Samsung tab 2. with android 4.3
-
I have a date in text form in Excel like 41579,41609 but now I need to convert that to date form(YYYYMM) like 201311 ,201312 etc. Can somebody help me to figure this out? I used : Convert ([varchar](10), dateadd(day,-2,convert(decimal,substring([Fiel
-
Exception in useOneAsMany function
Hi Experts, I have a scenario IDoc (ORDERS05) to cXML. to map the E1CUCFG (SO configuration data) to CXML.I have used the below mapping Please click the link: [http://www.flickr.com/photos/25429360@N07/2466275133/] Everything works fine, but if a IDo
-
New Windows XP 64bit, but no drivers for K8N Neo Platinum
Hello, I have a MSI K8N Neo Platinum with an AMD 2800+. Just received the new Windows XP 64bit edition after attending a trade show in Houston. Used Partition Magic to make a separate partition on my SATA 400GB HD, knowing there was possibly going