Cartesian Query
Hi,
I'm using Toplink 11g with Weblogic 10.3.0.
The application is generating query having cartesian product on one single table; here goes an example;
SELECT t0.ID_REQUEST,
t0.RD_NUM_RETRY,
t0.RD_START_TIME,
t0.EVENT_ID,
t0.RD_END_TIME,
t0.MSISDN,
t0.RD_STATUS,
t0.RET_MESSAGE,
t0.REQUEST,
t0.RD_BILL_DATE,
t0.SERVICE_CLASS,
t0.CSP,
t0.SERVICE_ID,
t0.RET_CODE,
t0.SERVICE_KEY,
t0.RD_ID,
t0.SERVICE_NAME,
t0.RD_CESS,
t0.TOTAL_AMOUNT,
t0.BILLED_PARTIAL
FROM BILLING_NOT_SUCCESS t0, BILLING_NOT_SUCCESS t1
WHERE ( ( ( ( (t0.RD_STATUS = 'PARKED') AND (t0.RD_END_TIME > SYSDATE))
AND (t0.RD_CESS = 0))
AND (t1.MSISDN = xxxxxxxxx))
Is there any particular reason for this or it's simply an error?
I'm afraid of the owerhead generated by this cartesian product: How can I (should I?) avoid Toplink to generate query of this kind?
Thank you veri much indeed.
AND (t1.RET_CODE IN ('006', '201', '058')));
L.D.
Hi,
thank you very much for answering.
I'm using toplink, included adding toplink.jar in classpath of my Weblogic project.
Weblogic version is 10.3.0. (no JPA2.0). It's used to implement data access metods beeing used by SINGLETON Clustered application.
Sessions are configured as SERVERSessions distributed by a broker.
Sessions are configured in sessions.xml.
Thi is the most external methos building the query:
public List<BillingNotSuccess> getFNDRecords(String msisdn) throws Exception {
List<BillingNotSuccess> billRes = null;
Expression exp = null, exp1 = null;
exp = getConditions().and(exprBuild.get("msisdn").equal(msisdn));
String retCodeCondition = null;
String valueR = configurator.getParameterValue(Parameters.PARAM_RETRY_CODES_RELOAD);
logger.debug("mcss.retry.codes.reload: "+valueR);
if (valueR != null && !valueR.equalsIgnoreCase("")){
retCodeCondition = valueR;
String valueP = configurator.getParameterValue(Parameters.PARAM_RETRY_CODES_PARTIAL);
logger.debug("mcss.retry.codes.partial: "+valueP);
if (valueP != null && !valueP.equalsIgnoreCase("")){
retCodeCondition = (retCodeCondition!=null)?retCodeCondition+","+valueP:valueP;
if (retCodeCondition != null){
exp1 = exprBuild.get("retCode").in(retCodeCondition.split(","));
billRes = readWithConditionOrdering(BillingNotSuccess.class, "rdStartTime", exp.and(exp1));
traceResult(billRes);
return billRes;
This is the method used to build AND conditions shared by other business methods:
private Expression getConditions() throws Exception {
Expression exp = null, exp1 = null, exp2 = null;
exprBuild = new ExpressionBuilder(BillingNotSuccess.class);
exp = exprBuild.get("rdStatus").equal("PARKED");
exp1 = exprBuild.get("rdEndTime").greaterThan(new Date());
exp2 = exprBuild.get("rdCess").equal(0);
return exp.and(exp1).and(exp2);
Thank you very much again and please let me know if I can help with any further details.
Best regards.
L.D.
Similar Messages
-
Merge Join Cartesian performing bad on 10g
Hello All,
I have a merge join cartesian query that took seconds in 8i. Once the database was upgraded to 10g, the same query is taking hours. In looking at the explain plans, it looks like the access paths are identical.
Has anyone encountered this issue?
Thanks.Sometimes the cost-based optimizer will do cartesian joins to optimize a query. Seeing the word "cartesian" in a query plan is still a major red flag to my eyes. Also, performance changes between versions are usually expected, though most people complain about 9i to 10g results these days :)
Are you sure you need to be doing a cartesian join at all? As Fly pointed out they have a bad reputation, and yours must be running badly as per your post. I personally get more efficient results from hash joins over sort merges these days so that's something you can look at.
Try variations on your query to generate execution plans to see if you can get better results. Don't forget to actually time results since plan statistics have been known to be out-of-touch with actual run performance.
Good luck! -
Query resulting in cartesian product-plz help
select count(distinct e.hiredate),count(distinct b.hiredate) from scott.emp e, scott.emp b where e.hiredate<to_date('01-DEC-80','DD-MON-YY') and b.hiredate<to_date('23-JUN-81','DD-MON-YY')
Hi,
When I query it individually its giving me as below and its correct.
SQL> select count(hiredate) from scott.emp where hiredate<'01-DEC-81';
COUNT(HIREDATE)
9
SQL> select count(hiredate) from scott.emp where hiredate<'23-JUN-81';
COUNT(HIREDATE)
6
Now I want these two merged in same query and it should give me the same result
SQL> select count(distinct e.hiredate),count(distinct b.hiredate) from scott.emp
e, scott.emp b where e.hiredate<'01-DEC-80' and b.hiredate<'23-JUN-81';
COUNT(DISTINCTE.HIREDATE) COUNT(DISTINCTB.HIREDATE)
0 0
But its giving me either cartesian product or the result above.
I have already used logical operator AND . -
Query having cartesian product
hi
i have the following query
select f.item_number, case when f.item_number='1020101002' then f.calc_cement_sk else f.calc_amount end act
from XXNP_OPN_JOBLOG_EST_002 F WHERE f.OPN_JOBLOG_001_ID ='6369'
output
ITEM_NUMBER ACT
1020101001 NULL
1020111001 NULL
1020112001 NULL
1020113004 NULL
1020101002 494
1020102007 232
1020103004 37
1020104004 557
1020106002 20896
1020111001 5
1020112005 16253
1020112008 46
1020113004 40
1020222010 1393
ie 14 rows
another query
SELECT J.ITEM_NUMBER,j.opn_value FROM XXNP_OPN_JOBLOG_RES_005 J WHERE J.OPN_JOBLOG_001_ID ='6369'
output
ITEM_NUMBER OPN_VALUE
1010101003 1
1010101004 3
1010101005 2
1010104016 1
1010103001 76
1010103002 228
1010106001 2
1010106006 147
1010107010 1
1010109009 1
1010107015 866
1010107014 799
1010107016 1631
ie 13 rows
when i do
select f.item_number, case when f.item_number='1020101002' then f.calc_cement_sk else f.calc_amount end act ,j.opn_value
from XXNP_OPN_JOBLOG_EST_002 F ,XXNP_OPN_JOBLOG_RES_005 J where f.OPN_JOBLOG_001_ID = J.OPN_JOBLOG_001_ID and f.OPN_JOBLOG_001_ID ='6369'
i get 182 rows :( i know its due to cartesian product
is there any way i can get 27 rows only ,can i get the output in the format given below
ITEM_NUMBER ACT opn_value
1020101001 NULL
1020111001 NULL
1020112001 NULL
1020113004 NULL
1020101002 494
1020102007 232
1020103004 37
1020104004 557
1020106002 20896
1020111001 5
1020112005 16253
1020112008 46
1020113004 40
1020222010 1393
1010101003 1
1010101004 3
1010101005 2
1010104016 1
1010103001 76
1010103002 228
1010106001 2
1010106006 147
1010107010 1
1010109009 1
1010107015 866
1010107014 791
1010107016 1631kindly guide
thanking in advance
Edited by: makdutakdu on Mar 31, 2011 8:03 AMhi
script for XXNP_OPN_JOBLOG_RES_005
CREATE TABLE XXNP_OPN_JOBLOG_RES_005
OPN_JOBLOG_005_ID NUMBER,
OPN_JOBLOG_001_ID NUMBER,
WIP_ENTITY_ID NUMBER,
WIP_ENTITY_NAME VARCHAR2(240 BYTE),
OPN_RESOURCE_CODE VARCHAR2(30 BYTE),
OPN_UOM_CODE VARCHAR2(30 BYTE),
OPN_VALUE NUMBER,
OPN_MOV_DATE DATE,
ORG_ID NUMBER(15),
CREATION_DATE DATE,
CREATED_BY NUMBER(15),
LAST_UPDATE_DATE DATE,
LAST_UPDATED_BY NUMBER(15),
LAST_UPDATE_LOGIN NUMBER(15),
OPN_RESOURCE_DESC VARCHAR2(500 BYTE),
ITEM_PRICE NUMBER,
ITEM_NUMBER NUMBER(10),
DIS_PER NUMBER(3),
EST_VALUE NUMBER(15,3),
VAL_ESTAB NUMBER(15,3)
script for XXNP_OPN_JOBLOG_EST_002
CREATE TABLE XXNP_OPN_JOBLOG_EST_002
OPN_JOBLOG_002_ID NUMBER,
OPN_JOBLOG_007_ID NUMBER,
INVENTORY_ITEM_ID NUMBER,
ITEM_NUMBER VARCHAR2(20 BYTE),
ITEM_NAME VARCHAR2(40 BYTE),
ITEM_UOM VARCHAR2(30 BYTE),
ITEM_VALUE NUMBER,
ITEM_PERCENT NUMBER,
OPN_AMOUNT NUMBER,
ITEM_CEMENT_SK NUMBER,
ORG_ID NUMBER(15),
CREATION_DATE DATE,
CREATED_BY NUMBER(15),
LAST_UPDATE_DATE DATE,
LAST_UPDATED_BY NUMBER(15),
LAST_UPDATE_LOGIN NUMBER(15),
OPN_JOBLOG_001_ID NUMBER,
OPN_JOBLOG_006_ID NUMBER,
ITEM_REF NUMBER,
DESCRIPTION VARCHAR2(500 BYTE),
CALC_AMOUNT NUMBER,
CALC_CEMENT_SK NUMBER,
) -
Could anyone help me to avoid Cartesian join in this query?
Hi, guys:
Could you help me on this query? I must generate a Cartesian join, but I do not know why it happens. dt.debtorkey, cl.clientkey, inv.invoicekey, ag.agingkey are primary keys of each table. The problem is: I got same tuple for 8 times.
select dt.debtorkey, cl.clientkey, inv.invoicekey, ag.agingkey, dt.DebtorNo, dt.Name as "debtor Name", dt.State, cl.ClientNo, cl.Name as "Client Name", inv.InvNo, inv.PurchOrd, inv.Amt,
to_char(inv.InvDate, 'MM-DD-YY') invoice_date, to_char(ag.DateLastBuy, 'MM-DD-YY') aging_lastbuy, to_char(ag.DateLastPmt, 'MM-DD-YY') aging_lastpmt
from aging ag, invoices inv, debtors dt, clients cl
where ag.clientkey=cl.clientkey
and ag.debtorkey=dt.debtorkey
and inv.clientkey=cl.clientkey
and inv.debtorkey=dt.debtorkey
and ((inv.InvDate>=to_date(:P16_DP_IDF_START_DATE, 'MM/DD/YYYY')
and inv.InvDate<=to_date(:P16_DP_IDF_END_DATE, 'MM/DD/YYYY')
and ag.DateLastBuy=to_date(:P16_DP_IDF_LAST_BUY,'MM/DD/YYYY')
order by dt.name;Thanks a lot!Hi,
Thanks for help. I am sorry for that I do not know how to upload a picture of explain plan. I am struggling to find how to provide sample data. I hope this data format could be at least useful.
"DEBTORKEY","CLIENTKEY","INVOICEKEY","AGINGKEY","DEBTORNO","debtor Name","STATE","CLIENTNO","Client Name","INVNO","PURCHORD","AMT","INVOICE_DATE"
8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"I do not know why the tuples with same primary key repeat 8 times.
Edited by: lxiscas on Oct 24, 2012 4:08 PM
Edited by: lxiscas on Oct 24, 2012 4:10 PM -
Puzzled By Cartesian Join In Query
If I do this query:
SELECT count(*)
FROM
mode_change_history psch
JOIN mode_link psl USING (mode_index)
WHERE
psch.date_changed >= TO_TIMESTAMP ('2008-03-03 05:00:00.000', 'YYYY-MM-DD HH24:MI:SS.FF');
The query takes less than a second and I get the desired results. If I modify the query by adding an additional join to the analysts table, like this:
SELECT count(*)
FROM
mode_change_history psch
JOIN mode_link psl USING (mode_index)
JOIN analysts a USING (analyst_id)
WHERE
psch.date_changed >= TO_TIMESTAMP ('2008-03-03 05:00:00.000', 'YYYY-MM-DD HH24:MI:SS.FF');
The query takes too long (about a minute) and generates a cartesian product(according to the explain plan) when joining the analysts table.
Notes:
I've removed the column names from the SELECT clause and replaced it with a count(*) just to simply this example.
Relevant info on the tables being joined:
mode_change_history columns
mode_index
date_changed
analyst_id
justification
change_type
Primary key on this table: mode_index,date_changed,analyst_id
Approximate rows in table: 50,000
mode_link columns
mode_index
mode_name
parameter_set_id
Primary key on this table is: mode_index
Approximate rows in table: 20,000
analysts columns
analyst_id
user_name
full_name
Primary key on this table is: analyst_id
Approximate rows in table: 500
As you can see, none of the tables have many rows.
After joining the first two tables listed in the query the result of the join would have rows containing mode_index (from mode_change_history and mode_link tables) that satisfy the WHERE clause. This intermediate result set should include the additional column analyst_id from the mode_change_history table. Then I would expect the RDBMS to join the rows from the analysts table that have analyst_id's in the intermediate result set. This does not appear to be happening since I'm seeing the cartesian join line show up in the execution plan.
Any ideas on what's going on?
I would post the explain plans but the Oracle instance is on a network that is not connected to the Internet so I can't easily post any output.
Thank youI don't use them myself. but I did have to debug somebody else's code which was giving all kinds of random results. natural three way join (sounds dirty) - ha!
also, I've seen discrepancies between the manuals for different versions on the syntax and rules. one manual states that the USING clause is only valid for outer joins. another release states that it's good for inner and outer. I've also seen differences regarding the use of the word NATURAL.
the bug it isn't that the optimizer uses a merge join carteian to resolve it (which could still give the correct answer, but possibly not with optimal performance). it's that it screws up the join criteria and returns a cartesian product result set.
my opinion - screw ansi, I'm using oracle syntax. and if some new guy with a t-sql background doesn't like it, tough. I came from a C & Pascal background and had an oracle manual thrown in my lap (it was long enough ago that manuals were still printed, and luckily, being v5, the manuals were small and didn't damage anything). -
Merge cartesian join in query plan
Hi All
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
W are using many GTT's in our code, the query plan have Merge Cartesain join showing cardinality as '1' which is incorrect, as GTT tables have many rows. Due to this query is taking ages to execute.
I am trying to sue dynamic sampling, but it doesn't seem to work.
please help on this.user8650395 wrote:
Hi All
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
W are using many GTT's in our code, the query plan have Merge Cartesain join showing cardinality as '1' which is incorrect, as GTT tables have many rows. Due to this query is taking ages to execute.
I am trying to sue dynamic sampling, but it doesn't seem to work.
please help on this.Interesting.
There was a a thread a day or two ago about when dynamic sampling does not work. You can search OTN for it if you like. Also check the docs to make sure that dynamic sampling works with GTTS
One problem with GTTS is getting accurate statistics. Have you considered using DBMS_STATISTICS to set the statistics on the table to adjust the cardinality?
Your cardinality of 1 sounds incorrect. In theory a cartesian join against one row should be painelss; unfortunately your cardinality figure seems to be off! Sometimes in cases like yours the cost-based optimizer will choose a Cartesian join even when the table joins are properly specified. -
Cartesian Join query optimization
Hello Experts!
I have a question about cartesian join query which might look a bit weird.
Assume the SQL query like that:
SELECT DISTINCT A.NAME
FROM A, B, C;
Here we have cartesian join for 3 tables A, B and C.
It looks to me, in order to get the result for such a particular SQL tables/sets B and C need to be accessed only to ensure they return at least 1 row (otherwise result set is empty), query table A, but there is no actual need to join the data.
If you run such a query Oracle is doing full table scans and actually joins the data.
Yes, DBMS is doing exactly what you are asking for, but I wonder if there is any way (SQL hint or db parameter or anything else) to enforce more optimal access path here?
Obvious solution to remove B and C tables from the SELECT statement is not acceptable. :-)
Thank you!Your statement in the other thread indicates you don't understand how the BI prompts actually work because you say you want it to do something that doesn't make sense for it to do.
Of course Product and Account levels will be constrained to the interval you specified. It wouldn't make sense for them not to be. Because that would mean returning data for based on product and account levels that has a different open data range than what you specified.
All UI prompt dialogs I have seen use AND relationships between the parameters. If there are three parameters (A, B, C) then the ultimate relationship is 'A AND B AND C'; not 'A OR (B AND C)', 'A AND (B OR C)', 'A OR (B OR C).
Unless the tool allows you to select OR relationships you need to use a separate dialog box (parameter dialog) for each condition set.:-)
I understand how BI prompts work and basically agree on your comment, but there are two problems here:
1. I need to convince the customer his original requirements are not valid. Customer want it to work different way and there are some reasons why.
2. There are pretty large dimensions and fact tables used here, so when I choose filter criteria for the Product (which is small table) to populate/recalculate prompt values, large SR dimension and fact tables are joined too, and if there are Account dimension filters added, huge Account dimension will be added as well. This looks to be a bit sub-optimal for just populating the Product prompt values.
Of course, technically this is solvable, but requires to put some extra effort and does not solve the 1st issue.
That other link doesn't explain the sample code you posted in this thread. Post the actual query that is being generated and the query that you want to actually use.This is what is generated:
>
select distinct T311691.X_CUST_SUBTYPE as c1
from
WC_LOV_SR_AREA_H T311695,
WC_LOV_PROD_H T311687,
WC_LOV_CUST_TYPE_H T311691,
W_SRVREQ_D T302384 /* Dim_W_SRVREQ_D */
where ( T311687.LEV1 = 'Product X' and T311691.X_CUST_TYPE = 'Business' and T302384.OPEN_DT between TO_DATE('2012-03-01 00:00:00' , 'YYYY-MM-DD HH24:MI:SS') and TO_DATE('2012-03-31 00:00:00' , 'YYYY-MM-DD HH24:MI:SS') )
order by c1
>
This is what is actually needed to query this data:
>
select distinct T311691.X_CUST_SUBTYPE as c1
from
WC_LOV_CUST_TYPE_H T311691
where ( T311691.X_CUST_TYPE = 'Business' )
order by c1 -
Merge Join Cartesian in XML query
Hi Sir
I am getting Merge join cartesian in the below XML query
SELECT
x.empno,
x1.empno AS INDEXempno
FROM
emp_vw x,
emp_index x1,
table (xmlsequence(extract(x1.xml_data,'/emp/org/constituent/'))) c
WHERE x.empno = extractvalue(VALUE(c),'/constituent/code/text()');
I am getting Merge join cartesian in XML query. whereeas below query i am running by I am not getting merge join cartesian
SELECT
x.empno,
x1.empno AS INDEXempno
FROM
emp_vw_v6 x,
emp_index_v6 x1,
table (xmlsequence(extract(x1.xml_data,'/emp/org/constituent/'))) c
WHERE x.empno = extractvalue(VALUE(c),'/constituent/code/text()');
Here emp_vw is a view and emp_index is a table.This is not giving merge join cartesian
However both the view and table are interdependent.
Please help me to resolve the performance of the first query as it is taking a lot of time to execute.?
Thanks & Regards
Thakur Manoj RPlease post a working test case, and follow the guidelines here : {message:id=9360002}
What are the differences between the view and table in the first query and the two others (*_v6) in the second query? -
Hi
below query is running 1 minutes on test server however it is stucking on production for more than 8 hours .
I compared explain plan for both queries ,on test server,optimizer is using hash join however on production ,optimizer is using Merge Cartesian join .
I tried query with ordered hit ,we get rid of mergecartesian join but cost got increased
now please advice ,if we should go by this ordered hit method on production or not not
or suggets any other ways .
below is query
SELECT DISTINCT acct_promo_hdr.row_id, '401000', 'EXPORTED',
acct_promo_hdr.src_num, 'PLAN_ACCOUNT_PROMOTION',
promo_hdr_org.NAME
FROM siebel.s_src acct_promo_hdr,
siebel.s_mdf_alloc deal,
siebel.s_bu promo_hdr_org
-- siebel.s_contact contact,
-- siebel.s_user usr
WHERE acct_promo_hdr.sub_type = 'PLAN_ACCOUNT_PROMOTION'
AND acct_promo_hdr.row_id = deal.promo_id
AND acct_promo_hdr.bu_id = promo_hdr_org.row_id
-- AND acct_promo_hdr.created_by = contact.row_id
-- AND contact.row_id = usr.row_id
AND EXISTS (
SELECT 1
FROM approval acb_approval
WHERE acb_approval.status NOT IN
('11', '12', '65', '77')
AND acct_promo_hdr.src_num =
acb_approval.commit_num)
AND deal.status_cd IN
('Cancel',
'Cancelled',
'Committed',
'On Hold',
'Processing Claim',
'Paid In Part',
'Paid In Full',
'Hold'
explain plan on production
PLAN_TABLE_OUTPUT
Plan hash value: 115701554
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 133 | 207 (2)| 00:00:03 |
| 1 | HASH UNIQUE | | 1 | 133 | 207 (2)| 00:00:03 |
| 2 | NESTED LOOPS | | | | | |
| 3 | NESTED LOOPS | | 1 | 133 | 206 (1)| 00:00:03 |
| 4 | NESTED LOOPS | | 1 | 112 | 205 (1)| 00:00:03 |
| 5 | MERGE JOIN CARTESIAN | | 1 | 57 | 67 (2)| 00:00:01 |
| 6 | SORT UNIQUE | | 1 | 30 | 64 (0)| 00:00:01 |
|* 7 | TABLE ACCESS FULL | APPROVAL | 1 | 30 | 64 (0)| 00:00:01 |
| 8 | BUFFER SORT | | 3 | 81 | 3 (34)| 00:00:01 |
| 9 | TABLE ACCESS FULL | S_BU | 3 | 81 | 2 (0)| 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID| S_SRC | 1 | 55 | 137 (0)| 00:00:02 |
|* 11 | INDEX RANGE SCAN | S_SRC_U2 | 1 | | 137 (0)| 00:00:02 |
|* 12 | INDEX RANGE SCAN | S_MDF_ALLOC_F8 | 12 | | 1 (0)| 00:00:01 |
|* 13 | TABLE ACCESS BY INDEX ROWID | S_MDF_ALLOC | 11 | 231 | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
7 - filter("ACB_APPROVAL"."STATUS"<>'11' AND "ACB_APPROVAL"."STATUS"<>'12' AND
"ACB_APPROVAL"."STATUS"<>'65' AND "ACB_APPROVAL"."STATUS"<>'77')
11 - access("ACCT_PROMO_HDR"."BU_ID"="PROMO_HDR_ORG"."ROW_ID" AND
"ACCT_PROMO_HDR"."SUB_TYPE"='PLAN_ACCOUNT_PROMOTION')
filter("ACCT_PROMO_HDR"."SUB_TYPE"='PLAN_ACCOUNT_PROMOTION' AND
"ACB_APPROVAL"."COMMIT_NUM"=TO_NUMBER("ACCT_PROMO_HDR"."SRC_NUM"))
12 - access("ACCT_PROMO_HDR"."ROW_ID"="DEAL"."PROMO_ID")
13 - filter("DEAL"."STATUS_CD"='Cancel' OR "DEAL"."STATUS_CD"='Cancelled' OR
"DEAL"."STATUS_CD"='Committed' OR "DEAL"."STATUS_CD"='Hold' OR "DEAL"."STATUS_CD"='On
Hold' OR "DEAL"."STATUS_CD"='Paid In Full' OR "DEAL"."STATUS_CD"='Paid In Part' OR
"DEAL"."STATUS_CD"='Processing Claim')
35 rows selected.pujakhetan wrote:
Tables are analysed on production .Well, the stats are indicating to the optimizer that the filter at #7 (<tt>ACB_APPROVAL_STATUS {noformat}<{noformat}> '11'</tt> etc) will return 1 row (usually indicating it thinks there are no rows to process), so if that is not the case then something has gone wrong. I'm guessing the 'good' plan you see in test has higher cardinality figures?
I tried query with ordered hit, we get rid of merge cartesian join but cost got increased nowIgnore the 'cost', it is just a figure calculated by the optimizer to indicate the relative resources required by different query plans - according to the available stats - and if those stats are out or something else is confusing it then the figure will be meaningless. Look at it this way - if the cost calculation was right, your query would already have the best plan.
Also the problem was not the join order but the join method, so I don't see an 'ordered' hint necessarily helping.
btw placing <tt></tt> tags around your code and execution plan will make it a lot easier to read. -
Cartesian join in the SQL query
Hi,
I have a problem when joining two tables that cannot join directly. As I read (please correct me if I'm wrong), two dims have to join by one fact in order to extract information from them. This way, I created logical source tables with SQL query that join both dims. So, if for example Dim A and Dim B cannot join directly, I created a "mapping table" which is a select that joins these 2 tables in the proper way and the fields are the row_wids from these tables. This way, I created the following model diagram for this relationship:
DimActivity -< FactMapping >- DimPNR
DimActivity -< FactActivity >- DimMapping
DimPNR -< FactPNR >- DimMapping
Now, I can extract information from both dims and their metrics, except in one case; If I extract info from ("Segment Designer") "Dim-Activity", "Dim-PNR", "Fact-Activity" and "Fact-PNR", I get a query that first calculates the metric from Activity, then calculates the metric from PNR, and when it joins both queries, I get cardinality because it doesn't join through the "mapping tables". The whole query is:
WITH
SAWITH0 AS (select sum(T690608."QTY") as c1,
T690608."ASSET_NUM" as c2
from "W_ASSET_D" T690608 /* Dim_W_ASSET_D */
group by T690608."ASSET_NUM"),
SAWITH1 AS (select sum(T682428."COST") as c1,
T682428."STATUS_WID" as c2
from "W_ACTIVITY_F" T682428 /* Dim_W_ACTIVITY_F */
group by T682428."STATUS_WID")
select distinct SAWITH0.c2 as c1,SAWITH1.c2 as c2,SAWITH1.c1 as c3,SAWITH0.c1 as c4
from
SAWITH0,SAWITH1
Why there is no condition joining SAWITH0 and SAWITH1? Is there a way to force this to be an inner join? I'm looking forward to your answer, since this problem is urgent within this project. Thank you in advanceOk.
I assume that you have for one activity several asset PNR and for one asset several activity.
The factPNR is on this way a real bridge table. It's a way to be able to design a many-to-many relationship.
Have a look here for more detail on how to build a many-to-many relationship :
http://gerardnico.com/wiki/dw/data_quality/relationships#many-to-many
Therefore I assume that you want this design :
DimActivity -< FactActivity >- < FactPNR >- DimPNR and you will have :
DimActivity -< FactActivity >- < BridgeTable >- DimPNR How to build your bridge table ?
In the physical layer, :
* create a new table BridgeActivityPNR, open it and select "statement"
* enter your sql statement
SELECT DISTINCT A.ROW_WID ACTIVIDAD_WID, B.ROW_WID ASSET_WID
FROM W_ACTIVITY_F A,
W_ASSET_D B,
W_SRVREQ_D C,
X_S_CMPT_MTRC_F D,
X_S_ASSET_FEA_D E
WHERE A.X_SRA_SR_ID=C.INTEGRATION_ID AND
C.X_VLG_FLIGHT_ID=D.X_ROW_ID AND
D.X_ROW_ID=E.X_CM_ID AND
E.X_ASSET_ID=B.X_ROW_ID* add two columns in the column tab : ACTIVIDAD_WID and ASSET_WID
* create the physical join with the table FactActivity and DimPNR
* drag and drop in the business model your table BridgeActivityPNR
* in the BMM, create the complex join like this :
DimActivity -< FactActivity >- < BridgeTable >- DimPNR * open your logical bridge table and check the bridge table option.
And you are done if I didn't forget anything.
A complete example here :
http://gerardnico.com/wiki/dat/obiee/obiee_bridge_table -
How to take Cartesian product on logical subsets of rows in SELECT query?
Hi All,
I have the following data in seg_tab table.
Seg_no
Seg_value
1
01
2
001
2
002
3
100040
3
100041
3
100042
3
100043
Expected result, which is produced by joining the logical subsets (by seg_no) in rows. The segments can vary, for simplicity it is 3 but it can grow upto any level.
Codes
01.001.100040
01.001.100041
01.001.100042
01.001.100043
01.002.100040
01.002.100041
01.002.100042
01.002.100043
The SQL statements required to create tables and populate it with the data is given below:
CREATE TABLE seg_tab (seg_no NUMBER, seg_value VARCHAR2(10));
--1st Subset
INSERT INTO seg_tab VALUES (1,'01');
--2nd Subset
INSERT INTO seg_tab VALUES (2,'001');
INSERT INTO seg_tab VALUES (2,'002');
--3rd Subset
INSERT INTO seg_tab VALUES (3,'100040');
INSERT INTO seg_tab VALUES (3,'100041');
INSERT INTO seg_tab VALUES (3,'100042');
INSERT INTO seg_tab VALUES (3,'100043');
Any help on guiding how to write the SQL statement will be highly appreciated.
Many Thanks
Kind Regards,
BilalAnother way
with
seg_tab as
(select 1 seg_no,'01' seg_value from dual union all
select 2,'001' from dual union all
select 2,'002' from dual union all
select 3,'100040' from dual union all
select 3,'100041' from dual union all
select 3,'100042' from dual union all
select 3,'100043' from dual
concatenator(seg,codes) as
(select seg_no,seg_value
from seg_tab
where seg_no = 1
union all
select s.seg_no,c.codes || '.' || s.seg_value
from concatenator c,
seg_tab s
where s.seg_no = c.seg + 1
select codes
from concatenator
where seg = (select max(seg_no) from seg_tab)
order by codes
CODES
01.001.100040
01.001.100041
01.001.100042
01.001.100043
01.002.100040
01.002.100041
01.002.100042
01.002.100043
Regards
Etbin -
Help optimizing query with function
Hello experts,
I need your help optmizing this query which has a condition that matches on results of non-deterministic function. The non-deterministic functino is fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY. Values that it returns depends on contents of a table, so I can't really create a function index.
Any input will be appreciated. Thanks in advance!
Sorry I couln't format the query plan properly. Can somebody advise how? Thanks again!
Giovanni
explain plan for
WITH tg AS
(SELECT taxgroup_code FROM taxgroup
WHERE taxgroup_code = 'TAXGROUP2' --?
AND taxgroup_delete_ind = 'N' AND taxgroup_active_ind = 'A'),
le_hb AS
(SELECT tgi.taxgroup_code, tgi.legalentity_id, tgi.hyperionbase_id, ou.orgunit_code, ou.hyperionbase_code
FROM tg, taxgroupitem tgi, orgunit_vw ou
WHERE tg.taxgroup_code = tgi.taxgroup_code
AND tgi.legalentity_id = ou.legalentity_id AND tgi.hyperionbase_id = ou.hyperionbase_id
UNION
SELECT tgi.taxgroup_code, tgi.legalentity_id, ou.hyperionbase_id, ou.orgunit_code, ou.hyperionbase_code
FROM tg, taxgroupitem tgi, orgunit_vw ou
WHERE tg.taxgroup_code = tgi.taxgroup_code
AND tgi.legalentity_id = ou.legalentity_id AND tgi.hyperionbase_id IS NULL),
au AS
(SELECT appusage_code FROM appusage WHERE appusage_code = 'CONSOLIDATION'),
prs AS
(SELECT prs_key,
(CASE WHEN instr(prs_key, ':') = 0 THEN prs_key
ELSE SUBSTR(prs_key, 1, (instr(prs_key, ':')-1) ) END) first_val
FROM
(SELECT fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(164415 --?
) prs_key
FROM dual
grs AS
(SELECT prs.*, fd.fielddata_group_sequence fd_grpseq
FROM prs, fielddata fd, le_hb
WHERE prs.first_val = fd.fielddata_value
AND le_hb.legalentity_id = fd.legalentity_id
AND le_hb.hyperionbase_id = fd.hyperionbase_id),
fdk AS
(SELECT
cd.celldef_id, fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_group_sequence) fd_key,
fd.fielddata_value fd_val, fd.fielddata_group_sequence fd_grpseq,
ROW_NUMBER() OVER (PARTITION BY cd.celldef_id, fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_group_sequence)
ORDER BY fd.fielddata_group_sequence) rn,
grs.prs_key
FROM le_hb, grs, fielddata fd, tablecell tc, celldef cd, tabledef td, appusage au
WHERE le_hb.legalentity_id = fd.legalentity_id AND le_hb.hyperionbase_id = fd.hyperionbase_id
AND fd.fielddata_id = tc.fielddata_id AND tc.celldef_id = cd.celldef_id
AND cd.tabledef_id = td.tabledef_id
AND grs.fd_grpseq = fd.fielddata_parent_row_sequence
and grs.prs_key = fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_parent_row_sequence)
AND cd.celldef_key_ind = 'Y'
AND fd.fielddata_delete_ind = 'N'
AND td.tabledef_id = 2265
fda AS
(SELECT
cd.celldef_id, fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_group_sequence) fd_key,
TO_CHAR(TO_NUMBER(SUM(fd.fielddata_value))) fd_val,
MIN(fd.fielddata_group_sequence) fd_grpseq,
grs.prs_key
FROM le_hb, grs, fielddata fd, tablecell tc, celldef cd, tabledef td
WHERE le_hb.legalentity_id = fd.legalentity_id AND le_hb.hyperionbase_id = fd.hyperionbase_id
AND fd.fielddata_id = tc.fielddata_id AND tc.celldef_id = cd.celldef_id
AND cd.tabledef_id = td.tabledef_id
AND grs.fd_grpseq = fd.fielddata_parent_row_sequence
and grs.prs_key = fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_parent_row_sequence)
AND cd.celldef_adjustable_ind = 'Y'
AND fd.fielddata_delete_ind = 'N'
AND td.tabledef_id = 2265
GROUP BY cd.celldef_id, fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_group_sequence),
grs.prs_key
SELECT NULL LEGALENTITY_ID, NULL hyperionbase_id, fdk.celldef_id, TO_CHAR(NULL) role_code, NULL userinfo_id, cd.celldef_adjustable_ind,
'N' celldef_editable_ind, cd.celldef_filter_code, cd.celldef_validate_rule, cd.celldef_list_code,
cd.celldef_longstring_ind, aua.appusageaccess_visible_ind celldef_viewable_ind,
cd.celldef_column_sequence, cd.celldef_column_label,
cd.celldef_column_sort_order, NULL tablecell_id, fdk.fd_grpseq tablecell_row_sequence, NULL tablecell_row_label,
'N' tablecell_delete_ind, NULL tablecell_create_by, TO_DATE(NULL) tablecell_create_dt, TO_CHAR(NULL) tablecell_update_by,
TO_DATE(NULL) tablecell_update_dt, NULL fielddata_id, TO_CHAR(NULL) datatype_code, NULL fielddata_adjref_id,
fdk.fd_grpseq fielddata_group_sequence, NULL fielddata_parent_row_sequence, NULL lookup_id,
fdk.fd_val fielddata_value, 'N' fielddata_delete_ind, TO_CHAR(NULL) fielddata_create_by,
TO_DATE(NULL) fielddata_create_dt, TO_CHAR(NULL) fielddata_update_by, TO_DATE(NULL) fielddata_update_dt,
fdk.fd_key
FROM fdk, celldef cd, appusageaccess aua, au
WHERE fdk.celldef_id = cd.celldef_id
AND cd.celldef_id = aua.celldef_id
AND aua.appusage_code = au.appusage_code
AND fdk.rn = 1
UNION ALL
SELECT NULL LEGALENTITY_ID, NULL hyperionbase_id, fda.celldef_id, TO_CHAR(NULL) role_code, NULL userinfo_id, cd.celldef_adjustable_ind,
'N' celldef_editable_ind, cd.celldef_filter_code, cd.celldef_validate_rule, cd.celldef_list_code,
cd.celldef_longstring_ind, aua.appusageaccess_visible_ind celldef_viewable_ind,
cd.celldef_column_sequence, cd.celldef_column_label,
cd.celldef_column_sort_order, NULL tablecell_id, fda.fd_grpseq tablecell_row_sequence, NULL tablecell_row_label,
'N' tablecell_delete_ind, NULL tablecell_create_by, TO_DATE(NULL) tablecell_create_dt, TO_CHAR(NULL) tablecell_update_by,
TO_DATE(NULL) tablecell_update_dt, NULL fielddata_id, TO_CHAR(NULL) datatype_code, NULL fielddata_adjref_id,
fda.fd_grpseq fielddata_group_sequence, NULL fielddata_parent_row_sequence, NULL lookup_id,
fda.fd_val fielddata_value, 'N' fielddata_delete_ind, TO_CHAR(NULL) fielddata_create_by,
TO_DATE(NULL) fielddata_create_dt, TO_CHAR(NULL) fielddata_update_by, TO_DATE(NULL) fielddata_update_dt,
fda.fd_key
FROM fda, celldef cd, appusageaccess aua, au
WHERE fda.celldef_id = cd.celldef_id
AND cd.celldef_id = aua.celldef_id
AND aua.appusage_code = au.appusage_code
ORDER BY fielddata_group_sequence, celldef_column_sequence
Query Plan:
Plan hash value: 522363234
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2 | 6227 | 249 (2)| 00:00:03 |
| 1 | TEMP TABLE TRANSFORMATION | | | | | |
| 2 | LOAD AS SELECT | | | | | |
|* 3 | TABLE ACCESS BY INDEX ROWID | TAXGROUP | 1 | 14 | 1 (0)| 00:00:01 |
|* 4 | INDEX UNIQUE SCAN | PK_TAXGROUP | 1 | | 0 (0)| 00:00:01 |
| 5 | LOAD AS SELECT | | | | | |
| 6 | SORT UNIQUE | | 4 | 224 | 12 (59)| 00:00:01 |
| 7 | UNION-ALL | | | | | |
| 8 | TABLE ACCESS BY INDEX ROWID | ORGUNIT | 1 | 29 | 2 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 1 | 56 | 5 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 27 | 3 (0)| 00:00:01 |
| 11 | VIEW | | 1 | 10 | 2 (0)| 00:00:01 |
| 12 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B51_2EBE182 | 1 | 10 | 2 (0)| 00:00:01 |
|* 13 | TABLE ACCESS BY INDEX ROWID | TAXGROUPITEM | 1 | 17 | 1 (0)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | XF1_TAXGROUPITEM_TAXGROUP | 1 | | 0 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | XF1_ORGUNIT_ID | 1 | | 1 (0)| 00:00:01 |
| 16 | TABLE ACCESS BY INDEX ROWID | ORGUNIT | 3 | 87 | 2 (0)| 00:00:01 |
| 17 | NESTED LOOPS | | 3 | 168 | 5 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | 1 | 27 | 3 (0)| 00:00:01 |
| 19 | VIEW | | 1 | 10 | 2 (0)| 00:00:01 |
| 20 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B51_2EBE182 | 1 | 10 | 2 (0)| 00:00:01 |
|* 21 | TABLE ACCESS BY INDEX ROWID | TAXGROUPITEM | 1 | 17 | 1 (0)| 00:00:01 |
|* 22 | INDEX RANGE SCAN | XF1_TAXGROUPITEM_TAXGROUP | 1 | | 0 (0)| 00:00:01 |
|* 23 | INDEX RANGE SCAN | XF1_ORGUNIT_ID | 3 | | 1 (0)| 00:00:01 |
| 24 | LOAD AS SELECT | | | | | |
|* 25 | INDEX UNIQUE SCAN | PK_APPUSAGE | 1 | 10 | 0 (0)| 00:00:01 |
| 26 | LOAD AS SELECT | | | | | |
|* 27 | TABLE ACCESS BY INDEX ROWID | FIELDDATA | 7 | 147 | 28 (0)| 00:00:01 |
| 28 | NESTED LOOPS | | 27 | 1269 | 117 (1)| 00:00:02 |
| 29 | NESTED LOOPS | | 4 | 104 | 4 (0)| 00:00:01 |
| 30 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
| 31 | VIEW | | 4 | 104 | 2 (0)| 00:00:01 |
| 32 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B52_2EBE182 | 4 | 388 | 2 (0)| 00:00:01 |
|* 33 | INDEX RANGE SCAN | XF11_DATA_LE_HB | 117 | | 12 (0)| 00:00:01 |
| 34 | SORT ORDER BY | | 2 | 6227 | 248 (51)| 00:00:03 |
| 35 | UNION-ALL | | | | | |
| 36 | NESTED LOOPS | | 1 | 4110 | 125 (2)| 00:00:02 |
| 37 | MERGE JOIN CARTESIAN | | 1 | 4093 | 124 (2)| 00:00:02 |
| 38 | NESTED LOOPS | | 1 | 4076 | 122 (2)| 00:00:02 |
|* 39 | VIEW | | 1 | 4043 | 121 (2)| 00:00:02 |
|* 40 | WINDOW SORT PUSHED RANK | | 1 | 2099 | 121 (2)| 00:00:02 |
| 41 | MERGE JOIN CARTESIAN | | 1 | 2099 | 120 (1)| 00:00:02 |
| 42 | NESTED LOOPS | | 1 | 2099 | 119 (1)| 00:00:02 |
| 43 | NESTED LOOPS | | 1 | 2088 | 118 (1)| 00:00:02 |
|* 44 | HASH JOIN | | 1 | 2077 | 117 (1)| 00:00:02 |
|* 45 | TABLE ACCESS BY INDEX ROWID| FIELDDATA | 117 | 3744 | 28 (0)| 00:00:01 |
| 46 | NESTED LOOPS | | 466 | 28892 | 114 (0)| 00:00:02 |
| 47 | NESTED LOOPS | | 4 | 120 | 2 (0)| 00:00:01 |
|* 48 | INDEX UNIQUE SCAN | PK_TABLEDEF | 1 | 4 | 0 (0)| 00:00:01 |
| 49 | VIEW | | 4 | 104 | 2 (0)| 00:00:01 |
| 50 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B52_2EBE182 | 4 | 388 | 2 (0)| 00:00:01 |
|* 51 | INDEX RANGE SCAN | XF11_DATA_LE_HB | 117 | | 12 (0)| 00:00:01 |
| 52 | VIEW | | 27 | 54405 | 2 (0)| 00:00:01 |
| 53 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B54_2EBE182 | 27 | 1269 | 2 (0)| 00:00:01 |
| 54 | TABLE ACCESS BY INDEX ROWID | TABLECELL | 1 | 11 | 1 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | XF1_TBLCEL_DATA | 1 | | 0 (0)| 00:00:01 |
|* 56 | TABLE ACCESS BY INDEX ROWID | CELLDEF | 1 | 11 | 1 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | PK_CELLDEF | 1 | | 0 (0)| 00:00:01 |
| 58 | BUFFER SORT | | 5 | | 120 (2)| 00:00:02 |
| 59 | INDEX FULL SCAN | PK_APPUSAGE | 5 | | 1 (0)| 00:00:01 |
| 60 | TABLE ACCESS BY INDEX ROWID | CELLDEF | 1 | 33 | 1 (0)| 00:00:01 |
|* 61 | INDEX UNIQUE SCAN | PK_CELLDEF | 1 | | 0 (0)| 00:00:01 |
| 62 | BUFFER SORT | | 1 | 17 | 123 (2)| 00:00:02 |
| 63 | VIEW | | 1 | 17 | 2 (0)| 00:00:01 |
| 64 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B53_2EBE182 | 1 | 10 | 2 (0)| 00:00:01 |
| 65 | TABLE ACCESS BY INDEX ROWID | APPUSAGEACCESS | 1 | 17 | 1 (0)| 00:00:01 |
|* 66 | INDEX UNIQUE SCAN | AK_APPUSAGEACCESS | 1 | | 0 (0)| 00:00:01 |
| 67 | NESTED LOOPS | | 1 | 2117 | 124 (2)| 00:00:02 |
| 68 | MERGE JOIN CARTESIAN | | 1 | 2100 | 123 (2)| 00:00:02 |
| 69 | NESTED LOOPS | | 1 | 2083 | 121 (2)| 00:00:02 |
| 70 | VIEW | | 1 | 2050 | 120 (2)| 00:00:02 |
| 71 | HASH GROUP BY | | 1 | 2091 | 120 (2)| 00:00:02 |
| 72 | NESTED LOOPS | | 1 | 2091 | 119 (1)| 00:00:02 |
| 73 | NESTED LOOPS | | 1 | 2080 | 118 (1)| 00:00:02 |
|* 74 | HASH JOIN | | 1 | 2069 | 117 (1)| 00:00:02 |
|* 75 | TABLE ACCESS BY INDEX ROWID | FIELDDATA | 117 | 3744 | 28 (0)| 00:00:01 |
| 76 | NESTED LOOPS | | 466 | 28892 | 114 (0)| 00:00:02 |
| 77 | NESTED LOOPS | | 4 | 120 | 2 (0)| 00:00:01 |
|* 78 | INDEX UNIQUE SCAN | PK_TABLEDEF | 1 | 4 | 0 (0)| 00:00:01 |
| 79 | VIEW | | 4 | 104 | 2 (0)| 00:00:01 |
| 80 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B52_2EBE182 | 4 | 388 | 2 (0)| 00:00:01 |
|* 81 | INDEX RANGE SCAN | XF11_DATA_LE_HB | 117 | | 12 (0)| 00:00:01 |
| 82 | VIEW | | 27 | 54189 | 2 (0)| 00:00:01 |
| 83 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B54_2EBE182 | 27 | 1269 | 2 (0)| 00:00:01 |
| 84 | TABLE ACCESS BY INDEX ROWID | TABLECELL | 1 | 11 | 1 (0)| 00:00:01 |
|* 85 | INDEX UNIQUE SCAN | XF1_TBLCEL_DATA | 1 | | 0 (0)| 00:00:01 |
|* 86 | TABLE ACCESS BY INDEX ROWID | CELLDEF | 1 | 11 | 1 (0)| 00:00:01 |
|* 87 | INDEX UNIQUE SCAN | PK_CELLDEF | 1 | | 0 (0)| 00:00:01 |
| 88 | TABLE ACCESS BY INDEX ROWID | CELLDEF | 1 | 33 | 1 (0)| 00:00:01 |
|* 89 | INDEX UNIQUE SCAN | PK_CELLDEF | 1 | | 0 (0)| 00:00:01 |
| 90 | BUFFER SORT | | 1 | 17 | 122 (2)| 00:00:02 |
| 91 | VIEW | | 1 | 17 | 2 (0)| 00:00:01 |
| 92 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B53_2EBE182 | 1 | 10 | 2 (0)| 00:00:01 |
| 93 | TABLE ACCESS BY INDEX ROWID | APPUSAGEACCESS | 1 | 17 | 1 (0)| 00:00:01 |
|* 94 | INDEX UNIQUE SCAN | AK_APPUSAGEACCESS | 1 | | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - filter("TAXGROUP_DELETE_IND"='N' AND "TAXGROUP_ACTIVE_IND"='A')
4 - access("TAXGROUP_CODE"='TAXGROUP2')
13 - filter("TGI"."HYPERIONBASE_ID" IS NOT NULL)
14 - access("TG"."TAXGROUP_CODE"="TGI"."TAXGROUP_CODE")
15 - access("TGI"."LEGALENTITY_ID"="OU"."ORGUNIT_ID" AND "TGI"."HYPERIONBASE_ID"="OU"."HYPERIONBASE_ID")
21 - filter("TGI"."HYPERIONBASE_ID" IS NULL)
22 - access("TG"."TAXGROUP_CODE"="TGI"."TAXGROUP_CODE")
23 - access("TGI"."LEGALENTITY_ID"="OU"."ORGUNIT_ID")
25 - access("APPUSAGE_CODE"='CONSOLIDATION')
27 - filter("FD"."FIELDDATA_VALUE"=CASE INSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415),':') WHEN 0
THEN "FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415) ELSE
SUBSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415),1,INSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(16441
5),':')-1) END )
33 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
"LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
39 - filter("FDK"."RN"=1)
40 - filter(ROW_NUMBER() OVER ( PARTITION BY "CD"."CELLDEF_ID","FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"
."FIELDDATA_GROUP_SEQUENCE") ORDER BY "FD"."FIELDDATA_GROUP_SEQUENCE")<=1)
44 - access("GRS"."FD_GRPSEQ"="FD"."FIELDDATA_PARENT_ROW_SEQUENCE" AND
"GRS"."PRS_KEY"="FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"."FIELDDATA_PARENT_ROW_SEQUENCE"))
45 - filter("FD"."FIELDDATA_DELETE_IND"='N')
48 - access("TD"."TABLEDEF_ID"=2265)
51 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
"LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
55 - access("FD"."FIELDDATA_ID"="TC"."FIELDDATA_ID")
56 - filter("CD"."TABLEDEF_ID"=2265 AND "CD"."CELLDEF_KEY_IND"='Y')
57 - access("TC"."CELLDEF_ID"="CD"."CELLDEF_ID")
61 - access("FDK"."CELLDEF_ID"="CD"."CELLDEF_ID")
66 - access("AUA"."APPUSAGE_CODE"="AU"."APPUSAGE_CODE" AND "CD"."CELLDEF_ID"="AUA"."CELLDEF_ID")
74 - access("GRS"."FD_GRPSEQ"="FD"."FIELDDATA_PARENT_ROW_SEQUENCE" AND
"GRS"."PRS_KEY"="FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"."FIELDDATA_PARENT_ROW_SEQUENCE"))
75 - filter("FD"."FIELDDATA_DELETE_IND"='N')
78 - access("TD"."TABLEDEF_ID"=2265)
81 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
"LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
85 - access("FD"."FIELDDATA_ID"="TC"."FIELDDATA_ID")
86 - filter("CD"."TABLEDEF_ID"=2265 AND "CD"."CELLDEF_ADJUSTABLE_IND"='Y')
87 - access("TC"."CELLDEF_ID"="CD"."CELLDEF_ID")
89 - access("FDA"."CELLDEF_ID"="CD"."CELLDEF_ID")
94 - access("AUA"."APPUSAGE_CODE"="AU"."APPUSAGE_CODE" AND "CD"."CELLDEF_ID"="AUA"."CELLDEF_ID")Thanks cd.
Here's the query plan:
Query Plan:
Plan hash value: 522363234
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2 | 6227 | 249 (2)| 00:00:03 |
| 1 | TEMP TABLE TRANSFORMATION | | | | | |
| 2 | LOAD AS SELECT | | | | | |
|* 3 | TABLE ACCESS BY INDEX ROWID | TAXGROUP | 1 | 14 | 1 (0)| 00:00:01 |
|* 4 | INDEX UNIQUE SCAN | PK_TAXGROUP | 1 | | 0 (0)| 00:00:01 |
| 5 | LOAD AS SELECT | | | | | |
| 6 | SORT UNIQUE | | 4 | 224 | 12 (59)| 00:00:01 |
| 7 | UNION-ALL | | | | | |
| 8 | TABLE ACCESS BY INDEX ROWID | ORGUNIT | 1 | 29 | 2 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 1 | 56 | 5 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 27 | 3 (0)| 00:00:01 |
| 11 | VIEW | | 1 | 10 | 2 (0)| 00:00:01 |
| 12 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B51_2EBE182 | 1 | 10 | 2 (0)| 00:00:01 |
|* 13 | TABLE ACCESS BY INDEX ROWID | TAXGROUPITEM | 1 | 17 | 1 (0)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | XF1_TAXGROUPITEM_TAXGROUP | 1 | | 0 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | XF1_ORGUNIT_ID | 1 | | 1 (0)| 00:00:01 |
| 16 | TABLE ACCESS BY INDEX ROWID | ORGUNIT | 3 | 87 | 2 (0)| 00:00:01 |
| 17 | NESTED LOOPS | | 3 | 168 | 5 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | 1 | 27 | 3 (0)| 00:00:01 |
| 19 | VIEW | | 1 | 10 | 2 (0)| 00:00:01 |
| 20 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B51_2EBE182 | 1 | 10 | 2 (0)| 00:00:01 |
|* 21 | TABLE ACCESS BY INDEX ROWID | TAXGROUPITEM | 1 | 17 | 1 (0)| 00:00:01 |
|* 22 | INDEX RANGE SCAN | XF1_TAXGROUPITEM_TAXGROUP | 1 | | 0 (0)| 00:00:01 |
|* 23 | INDEX RANGE SCAN | XF1_ORGUNIT_ID | 3 | | 1 (0)| 00:00:01 |
| 24 | LOAD AS SELECT | | | | | |
|* 25 | INDEX UNIQUE SCAN | PK_APPUSAGE | 1 | 10 | 0 (0)| 00:00:01 |
| 26 | LOAD AS SELECT | | | | | |
|* 27 | TABLE ACCESS BY INDEX ROWID | FIELDDATA | 7 | 147 | 28 (0)| 00:00:01 |
| 28 | NESTED LOOPS | | 27 | 1269 | 117 (1)| 00:00:02 |
| 29 | NESTED LOOPS | | 4 | 104 | 4 (0)| 00:00:01 |
| 30 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
| 31 | VIEW | | 4 | 104 | 2 (0)| 00:00:01 |
| 32 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B52_2EBE182 | 4 | 388 | 2 (0)| 00:00:01 |
|* 33 | INDEX RANGE SCAN | XF11_DATA_LE_HB | 117 | | 12 (0)| 00:00:01 |
| 34 | SORT ORDER BY | | 2 | 6227 | 248 (51)| 00:00:03 |
| 35 | UNION-ALL | | | | | |
| 36 | NESTED LOOPS | | 1 | 4110 | 125 (2)| 00:00:02 |
| 37 | MERGE JOIN CARTESIAN | | 1 | 4093 | 124 (2)| 00:00:02 |
| 38 | NESTED LOOPS | | 1 | 4076 | 122 (2)| 00:00:02 |
|* 39 | VIEW | | 1 | 4043 | 121 (2)| 00:00:02 |
|* 40 | WINDOW SORT PUSHED RANK | | 1 | 2099 | 121 (2)| 00:00:02 |
| 41 | MERGE JOIN CARTESIAN | | 1 | 2099 | 120 (1)| 00:00:02 |
| 42 | NESTED LOOPS | | 1 | 2099 | 119 (1)| 00:00:02 |
| 43 | NESTED LOOPS | | 1 | 2088 | 118 (1)| 00:00:02 |
|* 44 | HASH JOIN | | 1 | 2077 | 117 (1)| 00:00:02 |
|* 45 | TABLE ACCESS BY INDEX ROWID| FIELDDATA | 117 | 3744 | 28 (0)| 00:00:01 |
| 46 | NESTED LOOPS | | 466 | 28892 | 114 (0)| 00:00:02 |
| 47 | NESTED LOOPS | | 4 | 120 | 2 (0)| 00:00:01 |
|* 48 | INDEX UNIQUE SCAN | PK_TABLEDEF | 1 | 4 | 0 (0)| 00:00:01 |
| 49 | VIEW | | 4 | 104 | 2 (0)| 00:00:01 |
| 50 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B52_2EBE182 | 4 | 388 | 2 (0)| 00:00:01 |
|* 51 | INDEX RANGE SCAN | XF11_DATA_LE_HB | 117 | | 12 (0)| 00:00:01 |
| 52 | VIEW | | 27 | 54405 | 2 (0)| 00:00:01 |
| 53 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B54_2EBE182 | 27 | 1269 | 2 (0)| 00:00:01 |
| 54 | TABLE ACCESS BY INDEX ROWID | TABLECELL | 1 | 11 | 1 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | XF1_TBLCEL_DATA | 1 | | 0 (0)| 00:00:01 |
|* 56 | TABLE ACCESS BY INDEX ROWID | CELLDEF | 1 | 11 | 1 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | PK_CELLDEF | 1 | | 0 (0)| 00:00:01 |
| 58 | BUFFER SORT | | 5 | | 120 (2)| 00:00:02 |
| 59 | INDEX FULL SCAN | PK_APPUSAGE | 5 | | 1 (0)| 00:00:01 |
| 60 | TABLE ACCESS BY INDEX ROWID | CELLDEF | 1 | 33 | 1 (0)| 00:00:01 |
|* 61 | INDEX UNIQUE SCAN | PK_CELLDEF | 1 | | 0 (0)| 00:00:01 |
| 62 | BUFFER SORT | | 1 | 17 | 123 (2)| 00:00:02 |
| 63 | VIEW | | 1 | 17 | 2 (0)| 00:00:01 |
| 64 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B53_2EBE182 | 1 | 10 | 2 (0)| 00:00:01 |
| 65 | TABLE ACCESS BY INDEX ROWID | APPUSAGEACCESS | 1 | 17 | 1 (0)| 00:00:01 |
|* 66 | INDEX UNIQUE SCAN | AK_APPUSAGEACCESS | 1 | | 0 (0)| 00:00:01 |
| 67 | NESTED LOOPS | | 1 | 2117 | 124 (2)| 00:00:02 |
| 68 | MERGE JOIN CARTESIAN | | 1 | 2100 | 123 (2)| 00:00:02 |
| 69 | NESTED LOOPS | | 1 | 2083 | 121 (2)| 00:00:02 |
| 70 | VIEW | | 1 | 2050 | 120 (2)| 00:00:02 |
| 71 | HASH GROUP BY | | 1 | 2091 | 120 (2)| 00:00:02 |
| 72 | NESTED LOOPS | | 1 | 2091 | 119 (1)| 00:00:02 |
| 73 | NESTED LOOPS | | 1 | 2080 | 118 (1)| 00:00:02 |
|* 74 | HASH JOIN | | 1 | 2069 | 117 (1)| 00:00:02 |
|* 75 | TABLE ACCESS BY INDEX ROWID | FIELDDATA | 117 | 3744 | 28 (0)| 00:00:01 |
| 76 | NESTED LOOPS | | 466 | 28892 | 114 (0)| 00:00:02 |
| 77 | NESTED LOOPS | | 4 | 120 | 2 (0)| 00:00:01 |
|* 78 | INDEX UNIQUE SCAN | PK_TABLEDEF | 1 | 4 | 0 (0)| 00:00:01 |
| 79 | VIEW | | 4 | 104 | 2 (0)| 00:00:01 |
| 80 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B52_2EBE182 | 4 | 388 | 2 (0)| 00:00:01 |
|* 81 | INDEX RANGE SCAN | XF11_DATA_LE_HB | 117 | | 12 (0)| 00:00:01 |
| 82 | VIEW | | 27 | 54189 | 2 (0)| 00:00:01 |
| 83 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B54_2EBE182 | 27 | 1269 | 2 (0)| 00:00:01 |
| 84 | TABLE ACCESS BY INDEX ROWID | TABLECELL | 1 | 11 | 1 (0)| 00:00:01 |
|* 85 | INDEX UNIQUE SCAN | XF1_TBLCEL_DATA | 1 | | 0 (0)| 00:00:01 |
|* 86 | TABLE ACCESS BY INDEX ROWID | CELLDEF | 1 | 11 | 1 (0)| 00:00:01 |
|* 87 | INDEX UNIQUE SCAN | PK_CELLDEF | 1 | | 0 (0)| 00:00:01 |
| 88 | TABLE ACCESS BY INDEX ROWID | CELLDEF | 1 | 33 | 1 (0)| 00:00:01 |
|* 89 | INDEX UNIQUE SCAN | PK_CELLDEF | 1 | | 0 (0)| 00:00:01 |
| 90 | BUFFER SORT | | 1 | 17 | 122 (2)| 00:00:02 |
| 91 | VIEW | | 1 | 17 | 2 (0)| 00:00:01 |
| 92 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B53_2EBE182 | 1 | 10 | 2 (0)| 00:00:01 |
| 93 | TABLE ACCESS BY INDEX ROWID | APPUSAGEACCESS | 1 | 17 | 1 (0)| 00:00:01 |
|* 94 | INDEX UNIQUE SCAN | AK_APPUSAGEACCESS | 1 | | 0 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id):
3 - filter("TAXGROUP_DELETE_IND"='N' AND "TAXGROUP_ACTIVE_IND"='A')
4 - access("TAXGROUP_CODE"='TAXGROUP2')
13 - filter("TGI"."HYPERIONBASE_ID" IS NOT NULL)
14 - access("TG"."TAXGROUP_CODE"="TGI"."TAXGROUP_CODE")
15 - access("TGI"."LEGALENTITY_ID"="OU"."ORGUNIT_ID" AND "TGI"."HYPERIONBASE_ID"="OU"."HYPERIONBASE_ID")
21 - filter("TGI"."HYPERIONBASE_ID" IS NULL)
22 - access("TG"."TAXGROUP_CODE"="TGI"."TAXGROUP_CODE")
23 - access("TGI"."LEGALENTITY_ID"="OU"."ORGUNIT_ID")
25 - access("APPUSAGE_CODE"='CONSOLIDATION')
27 - filter("FD"."FIELDDATA_VALUE"=CASE INSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415),':') WHEN 0
THEN "FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415) ELSE
SUBSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415),1,INSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(16441
5),':')-1) END )
33 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
"LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
39 - filter("FDK"."RN"=1)
40 - filter(ROW_NUMBER() OVER ( PARTITION BY "CD"."CELLDEF_ID","FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"
."FIELDDATA_GROUP_SEQUENCE") ORDER BY "FD"."FIELDDATA_GROUP_SEQUENCE")<=1)
44 - access("GRS"."FD_GRPSEQ"="FD"."FIELDDATA_PARENT_ROW_SEQUENCE" AND
"GRS"."PRS_KEY"="FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"."FIELDDATA_PARENT_ROW_SEQUENCE"))
45 - filter("FD"."FIELDDATA_DELETE_IND"='N')
48 - access("TD"."TABLEDEF_ID"=2265)
51 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
"LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
55 - access("FD"."FIELDDATA_ID"="TC"."FIELDDATA_ID")
56 - filter("CD"."TABLEDEF_ID"=2265 AND "CD"."CELLDEF_KEY_IND"='Y')
57 - access("TC"."CELLDEF_ID"="CD"."CELLDEF_ID")
61 - access("FDK"."CELLDEF_ID"="CD"."CELLDEF_ID")
66 - access("AUA"."APPUSAGE_CODE"="AU"."APPUSAGE_CODE" AND "CD"."CELLDEF_ID"="AUA"."CELLDEF_ID")
74 - access("GRS"."FD_GRPSEQ"="FD"."FIELDDATA_PARENT_ROW_SEQUENCE" AND
"GRS"."PRS_KEY"="FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"."FIELDDATA_PARENT_ROW_SEQUENCE"))
75 - filter("FD"."FIELDDATA_DELETE_IND"='N')
78 - access("TD"."TABLEDEF_ID"=2265)
81 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
"LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
85 - access("FD"."FIELDDATA_ID"="TC"."FIELDDATA_ID")
86 - filter("CD"."TABLEDEF_ID"=2265 AND "CD"."CELLDEF_ADJUSTABLE_IND"='Y')
87 - access("TC"."CELLDEF_ID"="CD"."CELLDEF_ID")
89 - access("FDA"."CELLDEF_ID"="CD"."CELLDEF_ID")
94 - access("AUA"."APPUSAGE_CODE"="AU"."APPUSAGE_CODE" AND "CD"."CELLDEF_ID"="AUA"."CELLDEF_ID") -
Sql Query Tuning. Please help me to tune this query
Hi All ,
I have this problematic Sql . It is taking huge time to execute. It contains a view CIDV, which i think is the bottleneck.
I have pasted the query below. I will be pasting TKPROF and explain plan for the same. Please advice me to tune this query.
SELECT GCC.SEGMENT1 || '.' || GCC.SEGMENT2 || '.' || GCC.SEGMENT3 || '.' ||
GCC.SEGMENT4 || '.' || GCC.SEGMENT5 || '.' || GCC.SEGMENT6 || '.' ||
GCC.SEGMENT7 || '.' || GCC.SEGMENT8 || '.' || GCC.SEGMENT9 OFFSET_ACCOUNT,
OOD.ORGANIZATION_CODE,
CIDV.SUBINVENTORY_CODE OFFSET_SUBINV,
MIL.SEGMENT1 || '.' || MIL.SEGMENT2 || '.' || MIL.SEGMENT3 || '.' ||
MIL.SEGMENT4 || '.' || MIL.SEGMENT5 OFFSET_LOCATOR,
CIDV.LAST_UPDATE_LOGIN
FROM APPS.CST_INV_DISTRIBUTION_V CIDV,
APPS.GL_CODE_COMBINATIONS GCC,
APPS.MTL_ITEM_LOCATIONS MIL,
APPS.ORG_ORGANIZATION_DEFINITIONS OOD
WHERE CIDV.TRANSACTION_ID = :B2
AND CIDV.PRIMARY_QUANTITY = (-1) * :B1
AND CIDV.REFERENCE_ACCOUNT = GCC.CODE_COMBINATION_ID
AND OOD.ORGANIZATION_ID = CIDV.ORGANIZATION_ID
AND MIL.INVENTORY_LOCATION_ID = CIDV.LOCATOR_ID
AND GCC.ACCOUNT_TYPE = 'A'****************
TKPROF
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 68337 10.32 10.32 0 0 0 0
Fetch 68337 229.75 936.36 58819 6743323 1121 68232
total 136675 240.07 946.69 58819 6743323 1121 68232
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 203 (recursive depth: 1)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
1 1 1 MERGE JOIN CARTESIAN (cr=102 pr=15 pw=0 time=193608 us cost=56 size=219 card=1)
1 1 1 NESTED LOOPS (cr=100 pr=15 pw=0 time=193483 us cost=53 size=219 card=1)
1 1 1 NESTED LOOPS (cr=99 pr=15 pw=0 time=193407 us cost=52 size=215 card=1)
1 1 1 NESTED LOOPS (cr=96 pr=15 pw=0 time=193378 us cost=51 size=190 card=1)
1 1 1 NESTED LOOPS (cr=93 pr=15 pw=0 time=193284 us cost=49 size=162 card=1)
1 1 1 NESTED LOOPS (cr=89 pr=14 pw=0 time=185515 us cost=46 size=138 card=1)
1 1 1 NESTED LOOPS (cr=85 pr=12 pw=0 time=157975 us cost=44 size=81 card=1)
1 1 1 NESTED LOOPS (cr=83 pr=12 pw=0 time=157925 us cost=43 size=73 card=1)
1 1 1 NESTED LOOPS (cr=81 pr=12 pw=0 time=157641 us cost=43 size=132 card=2)
1 1 1 VIEW CST_INV_DISTRIBUTION_V (cr=78 pr=12 pw=0 time=156386 us cost=41 size=118 card=2)
1 1 1 UNION-ALL (cr=78 pr=12 pw=0 time=156378 us)
0 0 0 NESTED LOOPS OUTER (cr=44 pr=9 pw=0 time=124997 us cost=20 size=291 card=1)
0 0 0 NESTED LOOPS (cr=44 pr=9 pw=0 time=124993 us cost=18 size=255 card=1)
0 0 0 NESTED LOOPS (cr=44 pr=9 pw=0 time=124990 us cost=18 size=251 card=1)
33 33 33 MERGE JOIN CARTESIAN (cr=25 pr=6 pw=0 time=98544 us cost=14 size=192 card=1)
1 1 1 NESTED LOOPS OUTER (cr=22 pr=5 pw=0 time=85754 us cost=12 size=156 card=1)
1 1 1 NESTED LOOPS (cr=19 pr=4 pw=0 time=79830 us cost=10 size=120 card=1)
1 1 1 NESTED LOOPS OUTER (cr=17 pr=4 pw=0 time=79813 us cost=9 size=113 card=1)
1 1 1 NESTED LOOPS (cr=15 pr=4 pw=0 time=79752 us cost=8 size=106 card=1)
1 1 1 NESTED LOOPS (cr=11 pr=2 pw=0 time=43120 us cost=6 size=93 card=1)
1 1 1 NESTED LOOPS (cr=7 pr=2 pw=0 time=43087 us cost=4 size=83 card=1)
1 1 1 NESTED LOOPS (cr=6 pr=2 pw=0 time=43072 us cost=4 size=80 card=1)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_MATERIAL_TRANSACTIONS (cr=5 pr=2 pw=0 time=43042 us cost=4 size=76 card=1)
1 1 1 INDEX UNIQUE SCAN MTL_MATERIAL_TRANSACTIONS_U1 (cr=4 pr=2 pw=0 time=43011 us cost=3 size=0 card=1)(object id 12484094)
1 1 1 INDEX UNIQUE SCAN MTL_TRANSACTION_TYPES_U1 (cr=1 pr=0 pw=0 time=20 us cost=0 size=764 card=191)(object id 9983)
1 1 1 INDEX UNIQUE SCAN MTL_TXN_SOURCE_TYPES_U1 (cr=1 pr=0 pw=0 time=7 us cost=0 size=54 card=18)(object id 9987)
1 1 1 INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_B_U1 (cr=4 pr=0 pw=0 time=27 us cost=2 size=736324450 card=73632445)(object id 12484155)
1 1 1 INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_TL_U1 (cr=4 pr=2 pw=0 time=36626 us cost=2 size=957481070 card=73652390)(object id 12484137)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=42 us cost=1 size=3290 card=470)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=28 us cost=0 size=0 card=1)(object id 9847)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=12 us cost=1 size=3290 card=470)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=7 us cost=0 size=0 card=1)(object id 9847)
0 0 0 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=1 pw=0 time=5915 us cost=2 size=36 card=1)(object id 705891)
33 33 33 BUFFER SORT (cr=3 pr=1 pw=0 time=12713 us cost=12 size=36 card=1)
33 33 33 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=1 pw=0 time=12582 us cost=2 size=36 card=1)(object id 705891)
0 0 0 TABLE ACCESS BY INDEX ROWID MTL_TRANSACTION_ACCOUNTS (cr=19 pr=3 pw=0 time=26591 us cost=4 size=59 card=1)
66 66 66 INDEX RANGE SCAN MTL_TRANSACTION_ACCOUNTS_N1 (cr=18 pr=2 pw=0 time=13607 us cost=3 size=0 card=3)(object id 12484127)
0 0 0 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=0 pr=0 pw=0 time=0 us cost=0 size=4 card=1)(object id 9847)
0 0 0 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=36 card=1)(object id 705891)
1 1 1 NESTED LOOPS (cr=34 pr=3 pw=0 time=31269 us cost=21 size=288 card=1)
1 1 1 NESTED LOOPS (cr=30 pr=3 pw=0 time=31161 us cost=19 size=275 card=1)
1 1 1 NESTED LOOPS (cr=26 pr=3 pw=0 time=31105 us cost=17 size=265 card=1)
1 1 1 NESTED LOOPS (cr=25 pr=3 pw=0 time=31082 us cost=17 size=261 card=1)
1 1 1 NESTED LOOPS OUTER (cr=23 pr=3 pw=0 time=31027 us cost=16 size=254 card=1)
1 1 1 NESTED LOOPS (cr=21 pr=3 pw=0 time=30980 us cost=15 size=247 card=1)
1 1 1 NESTED LOOPS (cr=20 pr=3 pw=0 time=30957 us cost=15 size=243 card=1)
1 1 1 NESTED LOOPS OUTER (cr=19 pr=3 pw=0 time=30926 us cost=15 size=240 card=1)
1 1 1 NESTED LOOPS (cr=16 pr=3 pw=0 time=30389 us cost=13 size=204 card=1)
1 1 1 NESTED LOOPS (cr=11 pr=0 pw=0 time=665 us cost=9 size=131 card=1)
1 1 1 NESTED LOOPS OUTER (cr=8 pr=0 pw=0 time=306 us cost=7 size=95 card=1)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_TRANSACTION_ACCOUNTS (cr=5 pr=0 pw=0 time=37 us cost=5 size=59 card=1)
2 2 2 INDEX RANGE SCAN MTL_TRANSACTION_ACCOUNTS_N1 (cr=4 pr=0 pw=0 time=17 us cost=4 size=0 card=3)(object id 12484127)
1 1 1 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=0 pw=0 time=216 us cost=2 size=36 card=1)(object id 705891)
1 1 1 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=0 pw=0 time=352 us cost=2 size=36 card=1)(object id 705891)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_MATERIAL_TRANSACTIONS (cr=5 pr=3 pw=0 time=29716 us cost=4 size=73 card=1)
1 1 1 INDEX RANGE SCAN MTL_MATERIAL_TRANSACTIONS_N23 (cr=4 pr=3 pw=0 time=29588 us cost=3 size=0 card=1)(object id 12484133)
0 0 0 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=0 pw=0 time=520 us cost=2 size=36 card=1)(object id 705891)
1 1 1 INDEX UNIQUE SCAN MTL_TXN_SOURCE_TYPES_U1 (cr=1 pr=0 pw=0 time=22 us cost=0 size=3 card=1)(object id 9987)
1 1 1 INDEX UNIQUE SCAN MTL_TRANSACTION_TYPES_U1 (cr=1 pr=0 pw=0 time=16 us cost=0 size=4 card=1)(object id 9983)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=34 us cost=1 size=7 card=1)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=19 us cost=0 size=0 card=1)(object id 9847)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=44 us cost=1 size=7 card=1)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=14 us cost=0 size=0 card=1)(object id 9847)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=13 us cost=0 size=4 card=1)(object id 9847)
1 1 1 INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_B_U1 (cr=4 pr=0 pw=0 time=49 us cost=2 size=10 card=1)(object id 12484155)
1 1 1 INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_TL_U1 (cr=4 pr=0 pw=0 time=96 us cost=2 size=13 card=1)(object id 12484137)
1 1 1 TABLE ACCESS BY INDEX ROWID HR_ALL_ORGANIZATION_UNITS (cr=3 pr=0 pw=0 time=1246 us cost=1 size=7 card=1)
1 1 1 INDEX UNIQUE SCAN HR_ORGANIZATION_UNITS_PK (cr=2 pr=0 pw=0 time=24 us cost=0 size=0 card=1)(object id 250158)
1 1 1 INDEX UNIQUE SCAN HR_ALL_ORGANIZATION_UNTS_TL_PK (cr=2 pr=0 pw=0 time=275 us cost=0 size=7 card=1)(object id 689101)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=38 us cost=1 size=8 card=1)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=15 us cost=0 size=0 card=1)(object id 9847)
1 1 1 TABLE ACCESS BY INDEX ROWID GL_CODE_COMBINATIONS (cr=4 pr=2 pw=0 time=27531 us cost=2 size=57 card=1)
1 1 1 INDEX UNIQUE SCAN GL_CODE_COMBINATIONS_U1 (cr=3 pr=1 pw=0 time=19925 us cost=1 size=0 card=1)(object id 51426)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_ITEM_LOCATIONS (cr=4 pr=1 pw=0 time=7758 us cost=3 size=24 card=1)
1 1 1 INDEX RANGE SCAN MTL_ITEM_LOCATIONS_U1 (cr=3 pr=0 pw=0 time=51 us cost=2 size=0 card=1)(object id 9761)
1 1 1 TABLE ACCESS BY INDEX ROWID HR_ORGANIZATION_INFORMATION (cr=3 pr=0 pw=0 time=85 us cost=2 size=28 card=1)
1 1 1 INDEX RANGE SCAN HR_ORGANIZATION_INFORMATIO_FK2 (cr=2 pr=0 pw=0 time=29 us cost=1 size=0 card=2)(object id 5379798)
1 1 1 TABLE ACCESS BY INDEX ROWID HR_ORGANIZATION_INFORMATION (cr=3 pr=0 pw=0 time=25 us cost=1 size=25 card=1)
1 1 1 INDEX RANGE SCAN HR_ORGANIZATION_INFORMATIO_FK2 (cr=2 pr=0 pw=0 time=11 us cost=1 size=0 card=1)(object id 5379798)
1 1 1 INDEX FULL SCAN GL_SETS_OF_BOOKS_U2 (cr=1 pr=0 pw=0 time=69 us cost=1 size=4 card=1)(object id 1380842)
1 1 1 BUFFER SORT (cr=2 pr=0 pw=0 time=110 us cost=55 size=0 card=1)
1 1 1 TABLE ACCESS FULL FND_PRODUCT_GROUPS (cr=2 pr=0 pw=0 time=59 us cost=3 size=0 card=1)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
library cache lock 2 0.00 0.00
library cache pin 2 0.00 0.00
Disk file operations I/O 249 0.00 0.00
db file sequential read 58819 2.61 714.28
gc cr grant 2-way 5198 0.16 4.52
gc current grant busy 1 0.00 0.00
KJC: Wait for msg sends to complete 517 0.00 0.05
library cache: mutex X 433 0.01 0.04
gc cr grant congested 28 0.08 0.18
latch: ges resource hash list 5 0.00 0.00
gc current block 2-way 513 0.11 0.61
gc current block congested 2 0.00 0.00
latch: gc element 16 0.00 0.01
latch: cache buffers chains 4 0.00 0.00
latch: object queue header operation 3 0.00 0.00
********************************************************************************Explain Plan for the query
SELECT STATEMENT, GOAL = ALL_ROWS Cost=56 Cardinality=1 Bytes=219
MERGE JOIN CARTESIAN Cost=56 Cardinality=1 Bytes=219
NESTED LOOPS Cost=53 Cardinality=1 Bytes=219
NESTED LOOPS Cost=52 Cardinality=1 Bytes=215
NESTED LOOPS Cost=51 Cardinality=1 Bytes=190
NESTED LOOPS Cost=49 Cardinality=1 Bytes=162
NESTED LOOPS Cost=46 Cardinality=1 Bytes=138
NESTED LOOPS Cost=44 Cardinality=1 Bytes=81
NESTED LOOPS Cost=43 Cardinality=1 Bytes=73
NESTED LOOPS Cost=43 Cardinality=2 Bytes=132
VIEW Object owner=APPS Object name=CST_INV_DISTRIBUTION_V Cost=41 Cardinality=2 Bytes=118
UNION-ALL
NESTED LOOPS OUTER Cost=20 Cardinality=1 Bytes=291
NESTED LOOPS Cost=18 Cardinality=1 Bytes=255
NESTED LOOPS Cost=18 Cardinality=1 Bytes=251
MERGE JOIN CARTESIAN Cost=14 Cardinality=1 Bytes=192
NESTED LOOPS OUTER Cost=12 Cardinality=1 Bytes=156
NESTED LOOPS Cost=10 Cardinality=1 Bytes=120
NESTED LOOPS OUTER Cost=9 Cardinality=1 Bytes=113
NESTED LOOPS Cost=8 Cardinality=1 Bytes=106
NESTED LOOPS Cost=6 Cardinality=1 Bytes=93
NESTED LOOPS Cost=4 Cardinality=1 Bytes=83
NESTED LOOPS Cost=4 Cardinality=1 Bytes=80
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_MATERIAL_TRANSACTIONS Cost=4 Cardinality=1 Bytes=76
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_MATERIAL_TRANSACTIONS_U1 Cost=3 Cardinality=1
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_TRANSACTION_TYPES_U1 Cost=0 Cardinality=191 Bytes=764
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_TXN_SOURCE_TYPES_U1 Cost=0 Cardinality=18 Bytes=54
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_SYSTEM_ITEMS_B_U1 Cost=2 Cardinality=73632445 Bytes=736324450
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_SYSTEM_ITEMS_TL_U1 Cost=2 Cardinality=73652390 Bytes=957481070
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_PARAMETERS Cost=1 Cardinality=470 Bytes=3290
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_PARAMETERS Cost=1 Cardinality=470 Bytes=3290
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
BUFFER SORT Cost=12 Cardinality=1 Bytes=36
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_TRANSACTION_ACCOUNTS Cost=4 Cardinality=1 Bytes=59
INDEX RANGE SCAN Object owner=INV Object name=MTL_TRANSACTION_ACCOUNTS_N1 Cost=3 Cardinality=3
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1 Bytes=4
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
NESTED LOOPS Cost=21 Cardinality=1 Bytes=288
NESTED LOOPS Cost=19 Cardinality=1 Bytes=275
NESTED LOOPS Cost=17 Cardinality=1 Bytes=265
NESTED LOOPS Cost=17 Cardinality=1 Bytes=261
NESTED LOOPS OUTER Cost=16 Cardinality=1 Bytes=254
NESTED LOOPS Cost=15 Cardinality=1 Bytes=247
NESTED LOOPS Cost=15 Cardinality=1 Bytes=243
NESTED LOOPS OUTER Cost=15 Cardinality=1 Bytes=240
NESTED LOOPS Cost=13 Cardinality=1 Bytes=204
NESTED LOOPS Cost=9 Cardinality=1 Bytes=131
NESTED LOOPS OUTER Cost=7 Cardinality=1 Bytes=95
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_TRANSACTION_ACCOUNTS Cost=5 Cardinality=1 Bytes=59
INDEX RANGE SCAN Object owner=INV Object name=MTL_TRANSACTION_ACCOUNTS_N1 Cost=4 Cardinality=3
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_MATERIAL_TRANSACTIONS Cost=4 Cardinality=1 Bytes=73
INDEX RANGE SCAN Object owner=INV Object name=MTL_MATERIAL_TRANSACTIONS_N23 Cost=3 Cardinality=1
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_TXN_SOURCE_TYPES_U1 Cost=0 Cardinality=1 Bytes=3
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_TRANSACTION_TYPES_U1 Cost=0 Cardinality=1 Bytes=4
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_PARAMETERS Cost=1 Cardinality=1 Bytes=7
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_PARAMETERS Cost=1 Cardinality=1 Bytes=7
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1 Bytes=4
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_SYSTEM_ITEMS_B_U1 Cost=2 Cardinality=1 Bytes=10
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_SYSTEM_ITEMS_TL_U1 Cost=2 Cardinality=1 Bytes=13
TABLE ACCESS BY INDEX ROWID Object owner=HR Object name=HR_ALL_ORGANIZATION_UNITS Cost=1 Cardinality=1 Bytes=7
INDEX UNIQUE SCAN Object owner=HR Object name=HR_ORGANIZATION_UNITS_PK Cost=0 Cardinality=1
INDEX UNIQUE SCAN Object owner=HR Object name=HR_ALL_ORGANIZATION_UNTS_TL_PK Cost=0 Cardinality=1 Bytes=7
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_PARAMETERS Cost=1 Cardinality=1 Bytes=8
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=GL Object name=GL_CODE_COMBINATIONS Cost=2 Cardinality=1 Bytes=57
INDEX UNIQUE SCAN Object owner=GL Object name=GL_CODE_COMBINATIONS_U1 Cost=1 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_ITEM_LOCATIONS Cost=3 Cardinality=1 Bytes=24
INDEX RANGE SCAN Object owner=INV Object name=MTL_ITEM_LOCATIONS_U1 Cost=2 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=HR Object name=HR_ORGANIZATION_INFORMATION Cost=2 Cardinality=1 Bytes=28
INDEX RANGE SCAN Object owner=HR Object name=HR_ORGANIZATION_INFORMATIO_FK2 Cost=1 Cardinality=2
TABLE ACCESS BY INDEX ROWID Object owner=HR Object name=HR_ORGANIZATION_INFORMATION Cost=1 Cardinality=1 Bytes=25
INDEX RANGE SCAN Object owner=HR Object name=HR_ORGANIZATION_INFORMATIO_FK2 Cost=1 Cardinality=1
INDEX FULL SCAN Object owner=GL Object name=GL_SETS_OF_BOOKS_U2 Cost=1 Cardinality=1 Bytes=4
BUFFER SORT Cost=55 Cardinality=1
TABLE ACCESS FULL Object owner=APPLSYS Object name=FND_PRODUCT_GROUPS Cost=3 Cardinality=1 -
Hi,
I have a Oracle 9.2 DB with 2 cpu's,when i took a statspack report i found that CPU Time is very hight i,e more that 81%....
one of the query is taking near about 51% CPU Usage...
i.e
SELECT /*+ INDEX (OM_COURSE_FEE OCF_CFC_CODE) */DISTINCT CF_COURSE_CODE FROM OM_COURSE_FEE,OT_STUDENT_FEE_COL_HEAD,OT_STUDENT_FEE_COL_DETL WHERE SFCH_SYS_ID = SFCD_SFCH_SYS_ID AND
SFCD_FEE_TYPE_CODE = CF_TYPE_CODE AND CF_COURSE_CODE IN ( 'PE1','PE2','CCT','CPT' ) AND SFCH_TXN_CODE = :b1 AND SFCD_SUBSCRBE_JOURNAL_YN IN ( 'T','R','1','C' ) AND SFCH_APPR_UID IS NOT NULL
AND SFCH_APPR_DT IS NOT NULL AND SFCH_NO = :b2 AND NOT EXISTS (SELECT 'X' FROM OM_STUDENT_HEAD WHERE STUD_SRN = SFCH_STUD_SRN_TEMP_NO AND NVL(STUD_CLO_STATUS,0) != 1 AND
NVL(STUD_REG_STATUS,0) != 23 AND STUD_COURSE_CODE != 'CCT' AND CF_COURSE_CODE= STUD_COURSE_CODE ) ORDER BY 1 DESCExplain Plan for......
SQL> select * from table(dbms_xplan.display());
PLAN_TABLE_OUTPUT
| Id | Operation | Name
| Rows | Bytes | Cost | Pstart| Pstop |
| 0 | SELECT STATEMENT |
PLAN_TABLE_OUTPUT
| 1 | 69 | 45 | | |
| 1 | SORT UNIQUE |
| 1 | 69 | 27 | | |
| 2 | TABLE ACCESS BY GLOBAL INDEX ROWID | OT_STUDENT_FEE_COL_DETL
| 1 | 12 | 2 | ROWID | ROW L |
| 3 | NESTED LOOPS |
| 1 | 69 | 9 | | |
PLAN_TABLE_OUTPUT
| 4 | NESTED LOOPS |
| 1 | 57 | 7 | | |
| 5 | TABLE ACCESS BY GLOBAL INDEX ROWID | OT_STUDENT_FEE_COL_HEAD
| 1 | 48 | 5 | ROWID | ROW L |
| 6 | INDEX SKIP SCAN | OT_STUDENT_FEE_COL_HEAD_UK0
1 | 1 | | 4 | | |
| 7 | INLIST ITERATOR |
| | | | | |
PLAN_TABLE_OUTPUT
| 8 | TABLE ACCESS BY INDEX ROWID | OM_COURSE_FEE
| 1 | 9 | 2 | | |
| 9 | INDEX RANGE SCAN | OCF_CFC_CODE
| 1 | | 1 | | |
| 10 | FILTER |
| | | | | |
| 11 | TABLE ACCESS BY GLOBAL INDEX ROWID| OM_STUDENT_HEAD
PLAN_TABLE_OUTPUT
| 1 | 21 | 4 | ROWID | ROW L |
| 12 | INDEX RANGE SCAN | IDM_STUD_SRN_COURSE
| 1 | | 3 | | |
| 13 | INDEX RANGE SCAN | IDM_SFCD_FEE_TYPE_CODE
| 34600 | | 1 | | |
PLAN_TABLE_OUTPUT
Note: cpu costing is off, PLAN_TABLE' is old version
21 rows selected.
SQL>Statspack report
DB Name DB Id Instance Inst Num Release Cluster Host
ai 1372079993 ai11 1 9.2.0.6.0 YES ai1
Snap Id Snap Time Sessions Curs/Sess Comment
Begin Snap: 175 12-Dec-08 13:21:33 ####### .0
End Snap: 176 12-Dec-08 13:56:09 ####### .0
Elapsed: 34.60 (mins)
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 3,264M Std Block Size: 8K
Shared Pool Size: 608M Log Buffer: 977K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 5,727.62 21,658.54
Logical reads: 16,484.89 62,336.32
Block changes: 32.49 122.88
Physical reads: 200.46 758.03
Physical writes: 5.08 19.23
User calls: 97.43 368.44
Parses: 11.66 44.11
Hard parses: 0.39 1.48
Sorts: 3.22 12.19
Logons: 0.02 0.06
Executes: 36.70 138.77
Transactions: 0.26
% Blocks changed per Read: 0.20 Recursive Call %: 28.65
Rollback per transaction %: 20.95 Rows per Sort: 131.16
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 98.79 In-memory Sort %: 99.99
Library Hit %: 98.92 Soft Parse %: 96.65
Execute to Parse %: 68.21 Latch Hit %: 99.98
Parse CPU to Parse Elapsd %: 60.50 % Non-Parse CPU: 99.48
Shared Pool Statistics Begin End
Memory Usage %: 90.06 89.79
% SQL with executions>1: 72.46 72.46
% Memory for SQL w/exec>1: 69.42 69.51
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
CPU time 3,337 81.43
db file sequential read 60,550 300 7.32
global cache cr request 130,852 177 4.33
db file scattered read 72,915 101 2.46
db file parallel read 3,384 75 1.84
Cluster Statistics for DB: ai Instance: ai11 Snaps: 175 -176
Global Cache Service - Workload Characteristics
Ave global cache get time (ms): 1.3
Ave global cache convert time (ms): 2.1
Ave build time for CR block (ms): 0.1
Ave flush time for CR block (ms): 0.3
Ave send time for CR block (ms): 0.3
Ave time to process CR block request (ms): 0.7
Ave receive time for CR block (ms): 4.9
Ave pin time for current block (ms): 0.0
Ave flush time for current block (ms): 0.0
Ave send time for current block (ms): 0.3
Ave time to process current block request (ms): 0.3
Ave receive time for current block (ms): 2.8
Global cache hit ratio: 1.5
Ratio of current block defers: 0.0
% of messages sent for buffer gets: 1.4
% of remote buffer gets: 0.1
Ratio of I/O for coherence: 1.1
Ratio of local vs remote work: 9.7
Ratio of fusion vs physical writes: 0.1
Global Enqueue Service Statistics
Ave global lock get time (ms): 0.8
Ave global lock convert time (ms): 0.0
Ratio of global lock gets vs global lock releases: 1.1
GCS and GES Messaging statistics
Ave message sent queue time (ms): 0.4
Ave message sent queue time on ksxp (ms): 2.7
Ave message received queue time (ms): 0.2
Ave GCS message process time (ms): 0.1
Ave GES message process time (ms): 0.1
% of direct sent messages: 19.4
% of indirect sent messages: 43.5
% of flow controlled messages: 37.1
GES Statistics for DB: ai Instance: ai11 Snaps: 175 -176
Statistic Total per Second per Trans
dynamically allocated gcs resourc 0 0.0 0.0
dynamically allocated gcs shadows 0 0.0 0.0
flow control messages received 0 0.0 0.0
flow control messages sent 0 0.0 0.0
gcs ast xid 0 0.0 0.0
gcs blocked converts 1,231 0.6 2.2
gcs blocked cr converts 2,432 1.2 4.4
gcs compatible basts 0 0.0 0.0
gcs compatible cr basts (global) 658 0.3 1.2
gcs compatible cr basts (local) 57,822 27.9 105.3
gcs cr basts to PIs 0 0.0 0.0
gcs cr serve without current lock 0 0.0 0.0
gcs error msgs 0 0.0 0.0
gcs flush pi msgs 821 0.4 1.5
gcs forward cr to pinged instance 0 0.0 0.0
gcs immediate (compatible) conver 448 0.2 0.8
gcs immediate (null) converts 1,114 0.5 2.0
gcs immediate cr (compatible) con 42,094 20.3 76.7
gcs immediate cr (null) converts 396,284 190.9 721.8
gcs msgs process time(ms) 42,220 20.3 76.9
gcs msgs received 545,133 262.6 993.0
gcs out-of-order msgs 5 0.0 0.0
gcs pings refused 1 0.0 0.0
gcs queued converts 0 0.0 0.0
gcs recovery claim msgs 0 0.0 0.0
gcs refuse xid 0 0.0 0.0
gcs retry convert request 0 0.0 0.0
gcs side channel msgs actual 2,397 1.2 4.4
gcs side channel msgs logical 232,024 111.8 422.6
gcs write notification msgs 15 0.0 0.0
gcs write request msgs 278 0.1 0.5
gcs writes refused 1 0.0 0.0
ges msgs process time(ms) 4,873 2.3 8.9
ges msgs received 39,769 19.2 72.4
global posts dropped 0 0.0 0.0
global posts queue time 0 0.0 0.0
global posts queued 0 0.0 0.0
global posts requested 0 0.0 0.0
global posts sent 0 0.0 0.0
implicit batch messages received 39,098 18.8 71.2
implicit batch messages sent 33,386 16.1 60.8
lmd msg send time(ms) 635 0.3 1.2
lms(s) msg send time(ms) 2 0.0 0.0
messages flow controlled 196,546 94.7 358.0
messages received actual 182,783 88.0 332.9
messages received logical 584,848 281.7 1,065.3
messages sent directly 102,657 49.4 187.0
messages sent indirectly 230,329 110.9 419.5
msgs causing lmd to send msgs 9,169 4.4 16.7
msgs causing lms(s) to send msgs 3,347 1.6 6.1
msgs received queue time (ms) 142,759 68.8 260.0
msgs received queued 584,818 281.7 1,065.2
msgs sent queue time (ms) 99,300 47.8 180.9
msgs sent queue time on ksxp (ms) 608,239 293.0 1,107.9
msgs sent queued 230,391 111.0 419.7
msgs sent queued on ksxp 229,013 110.3 417.1
GES Statistics for DB: ai Instance: ai11 Snaps: 175 -176
Statistic Total per Second per Trans
process batch messages received 65,059 31.3 118.5
process batch messages sent 50,959 24.5 92.8
Wait Events for DB: ai Instance: ai11 Snaps: 175 -176
-> s - second
-> cs - centisecond - 100th of a second
-> ms - millisecond - 1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
db file sequential read 60,550 0 300 5 110.3
global cache cr request 130,852 106 177 1 238.3
db file scattered read 72,915 0 101 1 132.8
db file parallel read 3,384 0 75 22 6.2
latch free 7,253 1,587 52 7 13.2
enqueue 44,947 0 16 0 81.9
log file parallel write 2,140 0 6 3 3.9
db file parallel write 341 0 5 14 0.6
global cache open x 1,134 3 4 4 2.1
CGS wait for IPC msg 166,993 164,390 4 0 304.2
library cache lock 3,169 0 3 1 5.8
log file sync 494 0 3 5 0.9
row cache lock 702 0 3 4 1.3
DFS lock handle 6,900 0 2 0 12.6
control file parallel write 689 0 2 3 1.3
control file sequential read 2,785 0 2 1 5.1
wait for master scn 687 0 2 2 1.3
global cache null to x 699 0 2 2 1.3
global cache s to x 778 5 1 2 1.4
direct path write 148 0 0 3 0.3
SQL*Net more data to client 3,621 0 0 0 6.6
global cache open s 149 0 0 2 0.3
library cache pin 78 0 0 2 0.1
ksxr poll remote instances 3,536 2,422 0 0 6.4
LGWR wait for redo copy 12 6 0 9 0.0
buffer busy waits 23 0 0 5 0.0
direct path read 9 0 0 10 0.0
buffer busy global CR 5 0 0 17 0.0
SQL*Net break/reset to clien 172 0 0 0 0.3
global cache quiesce wait 4 1 0 7 0.0
KJC: Wait for msg sends to c 86 0 0 0 0.2
BFILE get length 67 0 0 0 0.1
global cache null to s 9 0 0 1 0.0
BFILE open 6 0 0 0 0.0
BFILE read 60 0 0 0 0.1
BFILE internal seek 60 0 0 0 0.1
BFILE closure 6 0 0 0 0.0
cr request retry 4 4 0 0 0.0
SQL*Net message from client 201,907 0 180,583 894 367.8
gcs remote message 171,236 43,749 3,975 23 311.9
ges remote message 79,324 40,722 2,017 25 144.5
SQL*Net more data from clien 447 0 9 21 0.8
SQL*Net message to client 201,901 0 0 0 367.8
Background Wait Events for DB: ai Instance: ai11 Snaps: 175 -176
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
enqueue 44,666 0 16 0 81.4
latch free 4,895 108 6 1 8.9
log file parallel write 2,140 0 6 3 3.9
db file parallel write 341 0 5 14 0.6
CGS wait for IPC msg 166,969 164,366 4 0 304.1
DFS lock handle 6,900 0 2 0 12.6
control file parallel write 689 0 2 3 1.3
control file sequential read 2,733 0 2 1 5.0
wait for master scn 687 0 2 2 1.3
ksxr poll remote instances 3,528 2,419 0 0 6.4
LGWR wait for redo copy 12 6 0 9 0.0
db file sequential read 7 0 0 9 0.0
global cache null to x 26 0 0 2 0.0
global cache open x 16 0 0 1 0.0
global cache cr request 1 0 0 0 0.0
rdbms ipc message 28,636 20,600 16,937 591 52.2
gcs remote message 171,254 43,746 3,974 23 311.9
pmon timer 708 686 2,022 2856 1.3
ges remote message 79,305 40,719 2,017 25 144.5
smon timer 125 0 1,972 15776 0.2
SQL ordered by Gets for DB: ai Instance: ai11 Snaps: 175 -176
-> End Buffer Gets Threshold: 10000
-> Note that resources reported for PL/SQL includes the resources used by
all SQL statements called within the PL/SQL code. As individual SQL
statements are also reported, it is possible and valid for the summed
total % to exceed 100
CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
17,503,305 84 208,372.7 51.1 676.25 1218.80 17574787
SELECT /*+ INDEX (OM_COURSE_FEE OCF_CFC_CODE) */DISTINCT CF_COU
RSE_CODE FROM OM_COURSE_FEE,OT_STUDENT_FEE_COL_HEAD,OT_STUDENT
FEECOL_DETL WHERE SFCH_SYS_ID = SFCD_SFCH_SYS_ID AND SFCD_FE
E_TYPE_CODE = CF_TYPE_CODE AND CF_COURSE_CODE IN ( 'PE1','PE2',
'CCT','CPT' ) AND SFCH_TXN_CODE = :b1 AND SFCD_SUBSCRBE_JOURNAuser00726 wrote:
somw of the changes that have been done....
cai11_lmd0_15771.trc.
Thu Oct 2 13:35:48 2008
CKPT: Begin resize of buffer pool 3 (DEFAULT for block size 8192)
CKPT: Current size = 2512 MB, Target size = 3072 MB
CKPT: Resize completed for buffer pool DEFAULT for blocksize 8192
Thu Oct 2 13:35:50 2008
ALTER SYSTEM SET db_cache_size='3072M' SCOPE=BOTH SID='icai11';
Thu Oct 2 14:04:34 2008
ALTER SYSTEM SET sga_max_size='5244772679680' SCOPE=SPFILE SID='*';
ALTER SYSTEM SET sga_max_size='5244772679680' SCOPE=SPFILE SID='*';
Thu Oct 2 15:24:14 2008
CKPT: Begin resize of buffer pool 3 (DEFAULT for block size 8192)
CKPT: Current size = 3072 MB, Target size = 2512 MB
CKPT: Resize completed for buffer pool DEFAULT for blocksize 8192
Thu Oct 2 15:24:20 2008
ALTER SYSTEM SET db_cache_size='2512M' SCOPE=BOTH SID='icai11';
Thu Oct 2 15:32:33 2008
CKPT: Begin resize of buffer pool 3 (DEFAULT for block size 8192)
CKPT: Current size = 2512 MB, Target size = 3072 MB
CKPT: Resize completed for buffer pool DEFAULT for blocksize 8192
Thu Oct 2 15:32:34 2008
ALTER SYSTEM SET db_cache_size='3072M' SCOPE=BOTH SID='icai11';
Thu Oct 2 15:36:46 2008
ALTER SYSTEM SET shared_pool_size='640M' SCOPE=BOTH SID='icai11';
Thu Oct 2 16:33:52 2008
CKPT: Begin resize of buffer pool 3 (DEFAULT for block size 8192)
CKPT: Current size = 3072 MB, Target size = 2512 MB
CKPT: Resize completed for buffer pool DEFAULT for blocksize 8192
Thu Oct 2 16:33:56 2008
ALTER SYSTEM SET db_cache_size='2512M' SCOPE=BOTH SID='icai11';
Thu Oct 2 16:39:30 2008
ALTER SYSTEM SET pga_aggregate_target='750M' SCOPE=BOTH SID='icai11';Just to make certain that I am not missing anything, if the above you set (all scaled to GB just for the sake of comparison):
sga_max_size=4885GB
db_cache_size=3GB
shared_pool_size=0.625GB
pga_aggregate_target=0.733GB
The SQL statement is forcing the use of a specific index, is this the best index?:
SELECT /*+ INDEX (OM_COURSE_FEE OCF_CFC_CODE) */DISTINCT CF_COURSE_CODE FROM OM_COURSE_FEE,OT_STUDENT_FEE_COL_HEAD,OT_STUDENT_FEE_COL_DETL WHERE SFCH_SYS_ID = SFCD_SFCH_SYS_ID AND
SFCD_FEE_TYPE_CODE = CF_TYPE_CODE AND CF_COURSE_CODE IN ( 'PE1','PE2','CCT','CPT' ) AND SFCH_TXN_CODE = :b1 AND SFCD_SUBSCRBE_JOURNAL_YN IN ( 'T','R','1','C' ) AND SFCH_APPR_UID IS NOT NULL
AND SFCH_APPR_DT IS NOT NULL AND SFCH_NO = :b2 AND NOT EXISTS (SELECT 'X' FROM OM_STUDENT_HEAD WHERE STUD_SRN = SFCH_STUD_SRN_TEMP_NO AND NVL(STUD_CLO_STATUS,0) != 1 AND
NVL(STUD_REG_STATUS,0) != 23 AND STUD_COURSE_CODE != 'CCT' AND CF_COURSE_CODE= STUD_COURSE_CODE ) ORDER BY 1 DESC
Unfortunately, explain plans, even with dbms_xplan.display, may not show the actual execution plan - this is more of a problem when the SQL statement includes bind variables (capturing a 10046 trace at level 8 or 12 will help). With the information provided, it looks like the problem is with the number of logical reads performed: 17,503,305 in 84 executions = 208,373 logical reads per execution. Something is causing the SQL statement to execute inefficiently, possibly a join problem between tables, possibly the forced use of an index.
From one of my previous posts related to this same SQL statement:
SELECT /*+ INDEX (OM_COURSE_FEE OCF_CFC_CODE) */ DISTINCT
CF_COURSE_CODE
FROM
OM_COURSE_FEE,
OT_STUDENT_FEE_COL_HEAD,
OT_STUDENT_FEE_COL_DETL
WHERE
SFCH_SYS_ID = SFCD_SFCH_SYS_ID
AND SFCD_FEE_TYPE_CODE = CF_TYPE_CODE
AND CF_COURSE_CODE IN ( 'PE1','PE2','CCT','CPT' )
AND SFCH_TXN_CODE = :b1
AND SFCD_SUBSCRBE_JOURNAL_YN IN ( 'T','R','1','C' )
AND SFCH_APPR_UID IS NOT NULL
AND SFCH_APPR_DT IS NOT NULL
AND SFCH_NO = :b2
AND NOT EXISTS (
SELECT
'X'
FROM
OM_STUDENT_HEAD
WHERE
STUD_SRN = SFCH_STUD_SRN_TEMP_NO
AND NVL(STUD_CLO_STATUS,0) != 1
AND NVL(STUD_REG_STATUS,0) != 23
AND STUD_COURSE_CODE != 'CCT'
AND CF_COURSE_CODE = STUD_COURSE_CODE)
ORDER BY
1 DESC
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop |
| 0 | SELECT STATEMENT 1 69 34
| 1 | SORT UNIQUE 1 69 22
| 2 | TABLE ACCESS BY GLOBAL INDEX ROWID | OT_STUDENT_FEE_COL_DETL | 1 | 12 | 2 | ROWID | ROW L |
| 3 | NESTED LOOPS 1 69 9
| 4 | NESTED LOOPS 1 57 7
| 5 | TABLE ACCESS BY GLOBAL INDEX ROWID | OT_STUDENT_FEE_COL_HEAD | 1 | 48 | 5 | ROWID | ROW L |
| 6 | INDEX SKIP SCAN OT_STUDENT_FEE_COL_HEAD_UK0| 1 | 1 | 4 |
| 7 | INLIST ITERATOR |
| 8 | TABLE ACCESS BY INDEX ROWID | OM_COURSE_FEE | 1 | 9 | 2 | | |
| 9 | INDEX RANGE SCAN | OCF_CFC_CODE | 1 | | 1 | | |
| 10 | FILTER
| 11 | TABLE ACCESS BY GLOBAL INDEX ROWID| OM_STUDENT_HEAD | 1 | 21 | 4 | ROWID | ROW L |
| 12 | INDEX RANGE SCAN | IDM_STUD_SRN_COURSE | 1 | | 3 | | |
| 13 | INDEX RANGE SCAN | IDM_SFCD_FEE_TYPE_CODE | 34600 | | 1 | | |It appears, based just on the SQL statement, that there is no direct relationship between OM_COURSE_FEE and OT_STUDENT_FEE_COL_HEAD, yet the plan above indicates that the two tables are being joined together, likely as a result of the index hint. There is the possibility of additional predicates being generated by Oracle which will make this possible without introducing a Cartesian join, but those predicates are not displayed with an explain plan (they will appear with a DBMS_XPLAN). I may not be remembering correctly, but if the optimizer goal is set to first rows, a Cartesian join might appear in a plan as a nested loops join - Jonathan will know for certain if that is the case.
Have you investigated the above as a possible cause? If you know that there is a problem with this one SQL statement, a 10046 trace at level 8 or 12 is much more helpful than a Statspack report.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.
Maybe you are looking for
-
Lion + Safari made Google Earth stop working properly
Upgraded to Lion now Google Earth Plugin won't work on Safari anymore. It works perfectly on Firefox, Chrome and Opera. I would like to keep using...please help. Thanks. It worked FLAWLESSLY (Safari & Google Earth) on Snow Leopard before upgrading to
-
Opinions on FCP w/ Quad or 8-core
Do you think it's worth the extra money to invest in the 8 core Mac Pro, instead of Quad, mostly for use with Final Cut Studio?
-
Hi all, I am using these two transactions for check printing. How to print check from it. I am creating smartform. How can i attach this to the transaction? Thanks in advamce
-
Hi all, I'm developing some templates for computer software manuals. I need a nice neat generic method for adding images and their titles. I need the figure titles to be positioned in the side heading, aligned with the top of the figure beside it. Fo
-
How to create a custom metadata for a file/document to be uploaded to KM and use just that metadata in search. Kiran