Query takes longer to run with indexes.
Here is my situation. I had a query which I use to run in Production (oracle 9.2.0.5) and Reporting database (9.2.0.3). The time taken to run in both databases was almost the same until 2 months ago which was about 2 minutes. Now in production the query does not run at all where as in Reporting it continues to run in about 2 minutes. Some of the things I obsevred in P are 1) the optimizer_index_cost_adj parameter was changed to 20 from 100 in order to improve the performance of a paycalc program about 3 months ago. Even with this parameter being set to 20, the query use to run in 2 minutes until 2 months ago. in the last two months the GL table increased in size from 25 million rows to 27 million rows. With optimizer_index_cost_adj of 20 and Gl table of 25 million rows it runs fine, but with 27 million rows it does not run at all. If I change the value of optimizer_index_cost_adj to 100 then the query runs with 27 million rows in 2 minutes and I found that it uses full table scan. In Reporting database it always used full table sacn as found thru explain plan. CBO determines which scan is best and it uses that. So my question is that by making optimizer_index_cost_adj = 20, does oracle forces it to use index scan when the table size is 27 million rows? Isn't the index scan is not faster than full table scan? In what situation the full table scan is faster than index scan? If I drop all the indexes on the GL table then the query runs faster in production as it uses full table scan. What is the real benefit of changing optimizer_index_cost_adj values? Any input is most welcome.
Isn't the index scan is not faster than full table scan? In what situation the full table scan is faster than index scan? No. It is not about which one is the "+fastest+" as that concept is flawed. How can an index be "faster" than a table for example? Does it have better tires and shinier paint job? ;-)
It is about the amount of I/O that the database needs to perform in order to use that object's contents for resolving/executing that applicable SQL statement.
If the CBO determines that it needs a 100 widgets worth of I/O to scan the index, and then another 100 widgets of I/O to scan the table, it may decide to not use the index at all, as a full table scan will cost only a 180 I/O widgets - 20 less than the combined scanning of index and table.
Also, a full scan can make use of multi-block reads - and this, on most storage/file systems, is faster than single block reads.
So no - a full table scan is NOT a Bad Thing (tm) and not an indicator of a problem. The thing that is of concern is the amount of I/O. The more I/O, the slower the operation. So obviously, we want to make sure that we design SQL that requires the minimal amount of I/O, design a database that support minimal I/O to find the required data (using clusters/partitions/IOTs/indexes/etc), and then check that the CBO also follows suit (which can be the complex bit).
But before questioning the CBO, first question your code and design - and whether or not they provide the optimal (smallest) I/O footprint for the job at hand.
Similar Messages
-
Why update query takes long time ?
Hello everyone;
My update query takes long time. In emp ( self testing) just having 2 records.
when i issue update query , it takes long time;
SQL> select * from emp;
EID ENAME EQUAL ESALARY ECITY EPERK ECONTACT_NO
2 rose mca 22000 calacutta 9999999999
1 sona msc 17280 pune 9999999999
Elapsed: 00:00:00.05
SQL> update emp set esalary=12000 where eid='1';
update emp set esalary=12000 where eid='1'
* ERROR at line 1:
ORA-01013: user requested cancel of current operation
Elapsed: 00:01:11.72
SQL> update emp set esalary=15000;
update emp set esalary=15000
* ERROR at line 1:
ORA-01013: user requested cancel of current operation
Elapsed: 00:02:22.27Hi BCV;
Thanks for your reply but it doesn't provide output, please see this.
SQL> update emp set esalary=15000;
........... Lock already occured.
>> trying to trace >>
SQL> select HOLDING_SESSION from dba_blockers;
HOLDING_SESSION
144
SQL> select sid , username, event from v$session where username='HR';
SID USERNAME EVENT
144 HR SQL*Net message from client
151 HR enq: TX - row lock contention
159 HR SQL*Net message from client
>> It does n 't provide clear output about transaction lock >>
SQL> SELECT username, v$lock.SID, TRUNC (id1 / POWER (2, 16)) rbs,
2 BITAND (id1, TO_NUMBER ('ffff', 'xxxx')) + 0 slot, id2 seq, lmode,
3 request
4 FROM v$lock, v$session
5 WHERE v$lock.TYPE = 'TX'
6 AND v$lock.SID = v$session.SID
7 AND v$session.username = USER;
no rows selected
SQL> select MACHINE from v$session where sid = :sid;
SP2-0552: Bind variable "SID" not declared. -
SELECT CAL_EMPCALENDAR.START_DATE as main,
bit_empname(CAL_EMPCALENDAR.EMPLOYEE_ID) || ' /' ||
CAL_EMPCALENDAR.EMPLOYEE_ID as secondary,
TO_DATE('1-4-2006', 'DD-MM-YYYY') as FROM_DATE,
TO_DATE('30-4-2006', 'DD-MM-YYYY') as TO_DATE,
bit_empname(CAL_EMPCALENDAR.EMPLOYEE_ID) || ' / ' ||
CAL_EMPCALENDAR.EMPLOYEE_ID as name,
CAL_EMPCALENDAR.START_DATE as sdate,
CAL_EMPCALENDAR.OVERTIME_REASON as OTReason,
CAL_EMPCALENDAR.POSTED_ON as POSTED_ON,
TO_CHAR(CAL_EMPCALENDAR.START_DATE, 'Dy') as dayname,
TAM_GET_ADJUSTED_IN(CAL_EMPCALENDAR.EMPCALENDAR_ID) as adj_in,
TAM_GET_ADJUSTED_OUT(CAL_EMPCALENDAR.EMPCALENDAR_ID) as adj_out,
CAL_EMPCALENDAR.SHIFT_ID AS SHIFT_ABBREV,
CAL_EMPCALENDAR.LATE_IN,
CAL_EMPCALENDAR.EARLY_OUT,
CAL_EMPCALENDAR.UNDER_TIME,
CAL_EMPCALENDAR.OVERTIME,
TAM_GET_LEAVE_DESC(CAL_EMPCALENDAR.EMPCALENDAR_ID, 'ALL') Leave,
CAL_EMPCALENDAR.EMPLOYEE_ID as empid,
HRM_CURR_CAREER_V.DEPARTMENT_CODE as deptcode,
BIT_CODEDESC(HRM_CURR_CAREER_V.DEPARTMENT_CODE) as deptname,
(SELECT shift_id
FROM CAL_GRPWORKDAY
WHERE CAL_GRPWORKDAY.calgrp_id =
(SELECT calgrp_id
FROM CAL_CALASSIGNMENT
WHERE employee_id = CAL_EMPCALENDAR.employee_id
AND CAL_CALASSIGNMENT.START_DATE <=
CAL_EMPCALENDAR.START_DATE
AND (CAL_CALASSIGNMENT.END_DATE is null or
CAL_CALASSIGNMENT.END_DATE >=
CAL_EMPCALENDAR.START_DATE))
AND CAL_GRPWORKDAY.start_date = CAL_EMPCALENDAR.start_date) AS shift_id,
(SELECT max(entry_dt)
FROM , LV_TXN txn, CAL_EMPDAILYEVENT cale
WHERE status = 'Approved'
AND LV_APPSTATUSHIST.application_id = txn.application_id
AND cale.reference_id = txn.txn_id
AND cale.empcalendar_id = CAL_EMPCALENDAR.empcalendar_id
) AS entry_dt,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
WF_STATUS = 'Verified' OR WF_STATUS is Null OR
WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 1
and BIZUNIT_ID like 'SG')) F1,
--TAM_GET_ENT_AND_ADJUSTED(CAL_EMPCALENDAR.EMPCALENDAR_ID, 'SG', 1) F1,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
WF_STATUS = 'Verified' OR WF_STATUS is Null OR
WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 2
and bizunit_id like 'SG')) F2,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
WF_STATUS = 'Verified' OR WF_STATUS is Null OR
WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 3
and bizunit_id like 'SG')) F3,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
WF_STATUS = 'Verified' OR WF_STATUS is Null OR
WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 4
and bizunit_id like 'SG')) F4,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
WF_STATUS = 'Verified' OR WF_STATUS is Null OR
WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 5
and bizunit_id like 'SG')) F5
From CAL_EMPCALENDAR, HRM_CURR_CAREER_V, CAL_SHIFT, HRM_EMPLOYEE
Where CAL_SHIFT.SHIFT_ID(+) = CAL_EMPCALENDAR.ACTUAL_SHIFT_ID
AND (CAL_EMPCALENDAR.WF_STATUS = 'Approved' Or
CAL_EMPCALENDAR.WF_STATUS = 'No Action')
AND CAL_EMPCALENDAR.EMPLOYEE_ID = HRM_EMPLOYEE.EMPLOYEE_ID
--and CAL_EMPCALENDAR.START_DATE between TO_DATE('1-4-2006','DD-MM-YYYY') AND TO_DATE('31-4-2006','DD-MM-YYYY')
AND CAL_EMPCALENDAR.START_DATE BETWEEN
GREATEST(HRM_EMPLOYEE.COMMENCE_DATE,
TO_DATE('1-4-2006', 'DD-MM-YYYY')) AND
LEAST(TO_DATE('30-4-2006', 'DD-MM-YYYY'),
NVL(HRM_EMPLOYEE.CESSATION_DATE,
TO_DATE('30-4-2006', 'DD-MM-YYYY')))
And CAL_EMPCALENDAR.EMPLOYEE_ID like 'SG' || '%'
And CAL_EMPCALENDAR.EMPLOYEE_ID like 'SGTAM001'
And CAL_EMPCALENDAR.EMPLOYEE_ID = HRM_CURR_CAREER_V.EMPLOYEE_ID
-- AND HRM_CURR_CAREER_V.DEPARTMENT_CODE like 'DPHR'
--AND HRM_EMPLOYEE.EMPLOYMENT_TYPE_CODE like '$P!{EmploymentType}'
--$P!{ExceptionSQL}
--$P!{iHRFilterClause}
--order by $P!{OrderBy}
order by main
Hi all this query takes a very long time to run.
On the explain plan the The table in bold letter is using full tablescan rest all go for index scanning.
Table got Indexe on those CLOMUNS REFERREED
Oracle version 9.2.0.6
Message was edited by:
Maran.E
Message was edited by:
Maran.EMaran,
With tags and indentation it should be easiest to analyze at least for you :
SELECT CAL_EMPCALENDAR.START_DATE as main,
bit_empname(CAL_EMPCALENDAR.EMPLOYEE_ID) || ' /' || CAL_EMPCALENDAR.EMPLOYEE_ID as secondary,
TO_DATE('1-4-2006', 'DD-MM-YYYY') as FROM_DATE,
TO_DATE('30-4-2006', 'DD-MM-YYYY') as TO_DATE,
bit_empname(CAL_EMPCALENDAR.EMPLOYEE_ID) || ' / ' || CAL_EMPCALENDAR.EMPLOYEE_ID as name,
CAL_EMPCALENDAR.START_DATE as sdate,
CAL_EMPCALENDAR.OVERTIME_REASON as OTReason,
CAL_EMPCALENDAR.POSTED_ON as POSTED_ON,
TO_CHAR(CAL_EMPCALENDAR.START_DATE, 'Dy') as dayname,
TAM_GET_ADJUSTED_IN(CAL_EMPCALENDAR.EMPCALENDAR_ID) as adj_in,
TAM_GET_ADJUSTED_OUT(CAL_EMPCALENDAR.EMPCALENDAR_ID) as adj_out,
CAL_EMPCALENDAR.SHIFT_ID AS SHIFT_ABBREV,
CAL_EMPCALENDAR.LATE_IN,
CAL_EMPCALENDAR.EARLY_OUT,
CAL_EMPCALENDAR.UNDER_TIME,
CAL_EMPCALENDAR.OVERTIME,
TAM_GET_LEAVE_DESC(CAL_EMPCALENDAR.EMPCALENDAR_ID, 'ALL') Leave,
CAL_EMPCALENDAR.EMPLOYEE_ID as empid,
HRM_CURR_CAREER_V.DEPARTMENT_CODE as deptcode,
BIT_CODEDESC(HRM_CURR_CAREER_V.DEPARTMENT_CODE) as deptname,
(SELECT shift_id
FROM CAL_GRPWORKDAY
WHERE CAL_GRPWORKDAY.calgrp_id = (SELECT calgrp_id
FROM CAL_CALASSIGNMENT
WHERE employee_id = CAL_EMPCALENDAR.employee_id
AND CAL_CALASSIGNMENT.START_DATE <= CAL_EMPCALENDAR.START_DATE
AND ( CAL_CALASSIGNMENT.END_DATE is null
or CAL_CALASSIGNMENT.END_DATE >= CAL_EMPCALENDAR.START_DATE))
AND CAL_GRPWORKDAY.start_date = CAL_EMPCALENDAR.start_date) AS shift_id,
(SELECT max(entry_dt)
FROM LV_TXN txn, CAL_EMPDAILYEVENT cale
WHERE status = 'Approved'
AND LV_APPSTATUSHIST.application_id = txn.application_id
AND cale.reference_id = txn.txn_id
AND cale.empcalendar_id = CAL_EMPCALENDAR.empcalendar_id) AS entry_dt,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE ( WF_STATUS = 'Pending'
OR WF_STATUS = 'Approved'
OR WF_STATUS = 'Verified'
OR WF_STATUS is Null
OR WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 1
and BIZUNIT_ID like 'SG')) F1,
--TAM_GET_ENT_AND_ADJUSTED(CAL_EMPCALENDAR.EMPCALENDAR_ID, 'SG', 1) F1,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE ( WF_STATUS = 'Pending'
OR WF_STATUS = 'Approved'
OR WF_STATUS = 'Verified'
OR WF_STATUS is Null
OR WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 2
and bizunit_id like 'SG')) F2,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE ( WF_STATUS = 'Pending'
OR WF_STATUS = 'Approved'
OR WF_STATUS = 'Verified'
OR WF_STATUS is Null
OR WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 3
and bizunit_id like 'SG')) F3,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE ( WF_STATUS = 'Pending'
OR WF_STATUS = 'Approved'
OR WF_STATUS = 'Verified'
OR WF_STATUS is Null
OR WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 4
and bizunit_id like 'SG')) F4,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE ( WF_STATUS = 'Pending'
OR WF_STATUS = 'Approved'
OR WF_STATUS = 'Verified'
OR WF_STATUS is Null
OR WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 5
and bizunit_id like 'SG')) F5
From CAL_EMPCALENDAR,
HRM_CURR_CAREER_V,
CAL_SHIFT,
HRM_EMPLOYEE
Where CAL_SHIFT.SHIFT_ID(+) = CAL_EMPCALENDAR.ACTUAL_SHIFT_ID
AND ( CAL_EMPCALENDAR.WF_STATUS = 'Approved'
Or CAL_EMPCALENDAR.WF_STATUS = 'No Action')
AND CAL_EMPCALENDAR.EMPLOYEE_ID = HRM_EMPLOYEE.EMPLOYEE_ID
--and CAL_EMPCALENDAR.START_DATE between TO_DATE('1-4-2006','DD-MM-YYYY') AND TO_DATE('31-4-2006','DD-MM-YYYY')
AND CAL_EMPCALENDAR.START_DATE BETWEEN GREATEST(HRM_EMPLOYEE.COMMENCE_DATE, TO_DATE('1-4-2006', 'DD-MM-YYYY'))
AND LEAST(TO_DATE('30-4-2006', 'DD-MM-YYYY'), NVL(HRM_EMPLOYEE.CESSATION_DATE, TO_DATE('30-4-2006', 'DD-MM-YYYY')))
And CAL_EMPCALENDAR.EMPLOYEE_ID like 'SG' || '%'
And CAL_EMPCALENDAR.EMPLOYEE_ID like 'SGTAM001'
And CAL_EMPCALENDAR.EMPLOYEE_ID = HRM_CURR_CAREER_V.EMPLOYEE_ID
-- AND HRM_CURR_CAREER_V.DEPARTMENT_CODE like 'DPHR'
--AND HRM_EMPLOYEE.EMPLOYMENT_TYPE_CODE like '$P!{EmploymentType}'
--$P!{ExceptionSQL}
--$P!{iHRFilterClause}
--order by $P!{OrderBy}
order by mainNicolas. -
Why NL instead of HJ(query takes long)
Hi there!
There are a db(10.2.0.5 RAC), SLES 10 and two schemes.In the first schema query takes very fast:
SQL> explain plan for
select count(distinct c.unit)
from quantity_comp_v qc, comps c, noticequant nq, notices_table n, noticediss nd
where
c.id = qc.comp
and nq.quant = qc.quantity
and n.id = nq.note
and n.type_id = 2
and nq.link = 2
and nd.note = n.id
and n.trust >=0
and nd.dis in (select dr.dismbr from disrelflat dr where dr.disgrp = 1080801245);
Explained.
Elapsed: 00:00:00.27
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2567928671
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 91 | | 2099 (4)| 00:00:07 |
| 1 | SORT GROUP BY | | 1 | 91 | | | |
|* 2 | HASH JOIN | | 55203 | 4905K| | 2099 (4)| 00:00:07 |
|* 3 | INDEX RANGE SCAN | DISRELFLAT_UI_DISGRP_DISMBR | 10618 | 155K| | 54 (2)| 00:00:01 |
|* 4 | HASH JOIN | | 42398 | 3146K| 2984K| 2043 (4)| 00:00:06 |
|* 5 | HASH JOIN | | 42398 | 2484K| | 1262 (4)| 00:00:04 |
|* 6 | HASH JOIN | | 24173 | 1109K| | 1022 (4)| 00:00:03 |
|* 7 | HASH JOIN | | 21471 | 650K| | 951 (3)| 00:00:03 |
|* 8 | VIEW | index$_join$_004 | 21471 | 314K| | 783 (3)| 00:00:03 |
|* 9 | HASH JOIN | | | | | | |
|* 10 | INDEX RANGE SCAN | NOTICES_TABLE_I_TYPE_ID_TRUST_ | 21471 | 314K| | 141 (5)| 00:00:01 |
| 11 | INDEX FAST FULL SCAN | NOTICES_TABLE_PK | 21471 | 314K| | 832 (2)| 00:00:03 |
| 12 | INDEX FAST FULL SCAN | NOTICEDISS_UI_NOTE_DIS | 169K| 2647K| | 162 (4)| 00:00:01 |
|* 13 | TABLE ACCESS FULL | NOTICEQUANT | 38141 | 595K| | 69 (5)| 00:00:01 |
| 14 | VIEW | | 88786 | 1127K| | 236 (3)| 00:00:01 |
| 15 | SORT UNIQUE | | | | | | |
| 16 | UNION-ALL | | | | | | |
|* 17 | HASH JOIN | | 23140 | 1355K| | 130 (8)| 00:00:01 |
| 18 | INDEX FAST FULL SCAN | QUANTITIES_I_ID_OP | 50822 | 397K| | 51 (4)| 00:00:01 |
|* 19 | HASH JOIN | | 23057 | 1170K| | 76 (7)| 00:00:01 |
| 20 | INDEX FAST FULL SCAN | QOPNC_I_ALL | 37964 | 481K| | 55 (2)| 00:00:01 |
| 21 | VIEW | | 23057 | 878K| | 18 (6)| 00:00:01 |
|* 22 | CONNECT BY WITHOUT FILTERING| | | | | | |
| 23 | TABLE ACCESS FULL | QOPNQ | 23057 | 225K| | 18 (6)| 00:00:01 |
|* 24 | HASH JOIN | | 38100 | 781K| | 109 (6)| 00:00:01 |
| 25 | INDEX FAST FULL SCAN | QOPNC_I_ALL | 37964 | 481K| | 55 (2)| 00:00:01 |
| 26 | INDEX FAST FULL SCAN | QUANTITIES_I_ID_OP | 50822 | 397K| | 51 (4)| 00:00:01 |
| 27 | TABLE ACCESS FULL | COMPS | 218K| 3406K| | 282 (4)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("ND"."DIS"="DR"."DISMBR")
3 - access("DR"."DISGRP"=1080801245)
4 - access("C"."ID"="COMP")
5 - access("NQ"."QUANT"="ID")
6 - access("NQ"."NOTE"="N"."ID")
7 - access("ND"."NOTE"="N"."ID")
8 - filter("N"."TYPE_ID"=2 AND "N"."TRUST">=0)
9 - access(ROWID=ROWID)
10 - access("N"."TYPE_ID"=2 AND "N"."TRUST">=0)
13 - filter("NQ"."LINK"=2)
17 - access("ID"="RT")
19 - access("QOP"="QUANTITY")
22 - access("QUANTITY"=PRIOR "QOP")
24 - access("ID"="QUANTITY")
52 rows selected.
Elapsed: 00:00:00.06
SQL> In second schema query takes very long:
PLAN_TABLE_OUTPUT
Plan hash value: 543063124
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 92 | 333 (2)| 00:00:01 |
| 1 | SORT GROUP BY | | 1 | 92 | | |
| 2 | NESTED LOOPS | | 91 | 8372 | 333 (2)| 00:00:01 |
| 3 | NESTED LOOPS | | 91 | 6916 | 241 (2)| 00:00:01 |
| 4 | NESTED LOOPS | | 52 | 3276 | 189 (2)| 00:00:01 |
| 5 | NESTED LOOPS | | 47 | 2209 | 123 (3)| 00:00:01 |
|* 6 | HASH JOIN | | 81 | 2592 | 42 (8)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | DISRELFLAT_UI_DISGRP_DISMBR | 18 | 288 | 2 (0)| 00:00:01 |
| 8 | INDEX FAST FULL SCAN | NOTICEDISS_UI_NOTE_DIS | 38127 | 595K| 38 (3)| 00:00:01 |
|* 9 | TABLE ACCESS BY INDEX ROWID | NOTICES_TABLE | 1 | 15 | 1 (0)| 00:00:01 |
|* 10 | INDEX UNIQUE SCAN | NOTICES_TABLE_PK | 1 | | 0 (0)| 00:00:01 |
|* 11 | TABLE ACCESS BY INDEX ROWID | NOTICEQUANT | 1 | 16 | 3 (0)| 00:00:01 |
|* 12 | INDEX RANGE SCAN | NOTICEQUANT_UI_NOTE_QUANT | 1 | | 1 (0)| 00:00:01 |
| 13 | VIEW | | 2 | 26 | 1 (0)| 00:00:01 |
| 14 | SORT UNIQUE | | | | | |
| 15 | UNION-ALL PARTITION | | | | | |
| 16 | NESTED LOOPS | | 1 | 60 | 19 (6)| 00:00:01 |
| 17 | NESTED LOOPS | | 1 | 47 | 18 (6)| 00:00:01 |
|* 18 | INDEX RANGE SCAN | QUANTITIES_UI_ID_OP | 1 | 8 | 2 (0)| 00:00:01 |
|* 19 | VIEW | | 1 | 39 | 16 (7)| 00:00:01 |
|* 20 | CONNECT BY WITHOUT FILTERING| | | | | |
| 21 | TABLE ACCESS FULL | QOPNQ | 19811 | 193K| 16 (7)| 00:00:01 |
|* 22 | INDEX RANGE SCAN | QOPNC_UI_QUANTITY_NUM_COMP | 1 | 13 | 1 (0)| 00:00:01 |
| 23 | NESTED LOOPS | | 1 | 21 | 3 (0)| 00:00:01 |
|* 24 | INDEX RANGE SCAN | QUANTITIES_UI_ID_OP | 1 | 8 | 2 (0)| 00:00:01 |
|* 25 | INDEX RANGE SCAN | QOPNC_UI_QUANTITY_NUM_COMP | 1 | 13 | 1 (0)| 00:00:01 |
| 26 | TABLE ACCESS BY INDEX ROWID | COMPS | 1 | 16 | 1 (0)| 00:00:01 |
|* 27 | INDEX UNIQUE SCAN | COMPS_UI_ID | 1 | | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
6 - access("ND"."DIS"="DR"."DISMBR")
7 - access("DR"."DISGRP"=1080801245)
9 - filter("N"."TYPE_ID"=2 AND "N"."TRUST">=0)
10 - access("ND"."NOTE"="N"."ID")
11 - filter("NQ"."LINK"=2)
12 - access("NQ"."NOTE"="N"."ID")
18 - access("ID"="NQ"."QUANT")
19 - filter("ID"="RT" AND "RT"="NQ"."QUANT")
20 - access("QUANTITY"=PRIOR "QOP")
22 - access("QOP"="QUANTITY")
24 - access("ID"="NQ"."QUANT")
25 - access("QUANTITY"="NQ"."QUANT")
filter("ID"="QUANTITY")
27 - access("C"."ID"="COMP")As you can see, plans are different. Why? Statistics is up-to-date in both schemas.
In tkprof trace for the second schema i see strange thing:
select count(distinct c.unit)
from quantity_comp_v qc, comps c, noticequant nq, notices_table n,
noticediss nd
where
c.id = qc.comp
and nq.quant = qc.quantity
and n.id = nq.note
and n.type_id = 2
and nq.link = 2
and nd.note = n.id
and n.trust >=0
and nd.dis in (select dr.dismbr from disrelflat dr where dr.disgrp = 1080801245)
call count cpu elapsed disk query current rows
Parse 1 0.02 0.02 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 558.36 545.39 1 845921 0 1
total 4 558.38 545.42 1 845921 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 156
Rows Row Source Operation
1 SORT GROUP BY (cr=845921 pr=1 pw=0 time=545397464 us)
13865 NESTED LOOPS (cr=845921 pr=1 pw=0 time=546471010 us)
13865 NESTED LOOPS (cr=818189 pr=1 pw=0 time=546290764 us)
13308 HASH JOIN (cr=31053 pr=1 pw=0 time=172231 us)
13308 NESTED LOOPS (cr=30863 pr=0 pw=0 time=126100 us)
15326 HASH JOIN (cr=209 pr=0 pw=0 time=21640 us)
11522 INDEX RANGE SCAN DISRELFLAT_UI_DISGRP_DISMBR (cr=68 pr=0 pw=0 time=40 us)(object id 634347)
37432 INDEX FAST FULL SCAN NOTICEDISS_UI_NOTE_DIS (cr=141 pr=0 pw=0 time=50 us)(object id 638914)
13308 TABLE ACCESS BY INDEX ROWID NOTICES_TABLE (cr=30654 pr=0 pw=0 time=95620 us)
15326 INDEX UNIQUE SCAN NOTICES_TABLE_PK (cr=15328 pr=0 pw=0 time=41398 us)(object id 638937)
34391 TABLE ACCESS FULL NOTICEQUANT (cr=190 pr=1 pw=0 time=53 us)
13865 VIEW (cr=787136 pr=0 pw=0 time=544908246 us)
13865 SORT UNIQUE (cr=787136 pr=0 pw=0 time=544893509 us)
13950 UNION-ALL PARTITION (cr=787136 pr=0 pw=0 time=539509573 us)
1223 NESTED LOOPS (cr=733813 pr=0 pw=0 time=539271493 us)
1233 NESTED LOOPS (cr=731971 pr=0 pw=0 time=539245389 us)
13308 INDEX RANGE SCAN QUANTITIES_UI_ID_OP (cr=26647 pr=0 pw=0 time=120240 us)(object id 634738)
1233 VIEW (cr=705324 pr=0 pw=0 time=539109785 us)
275435676 CONNECT BY WITHOUT FILTERING (cr=705324 pr=0 pw=0 time=493869861 us)
263644788 TABLE ACCESS FULL QOPNQ (cr=705324 pr=0 pw=0 time=163378 us)
1223 INDEX RANGE SCAN QOPNC_UI_QUANTITY_NUM_COMP (cr=1842 pr=0 pw=0 time=10296 us)(object id 634729)
12727 NESTED LOOPS (cr=53323 pr=0 pw=0 time=216730 us)
13308 INDEX RANGE SCAN QUANTITIES_UI_ID_OP (cr=26647 pr=0 pw=0 time=111770 us)(object id 634738)
12727 INDEX RANGE SCAN QOPNC_UI_QUANTITY_NUM_COMP (cr=26676 pr=0 pw=0 time=84638 us)(object id 634729)
13865 TABLE ACCESS BY INDEX ROWID COMPS (cr=27732 pr=0 pw=0 time=235066 us)
13865 INDEX UNIQUE SCAN COMPS_UI_ID (cr=13867 pr=0 pw=0 time=128663 us)(object id 634315)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
gc current block 3-way 208 0.00 0.08
gc current block 2-way 93 0.00 0.02
gc cr multi block request 150 0.00 0.01
db file sequential read 1 0.01 0.01
SQL*Net message from client 2 0.00 0.00
********************************************************************************Cardinality of QOPNQ not real (over 263 millions rows instead of 19 thousands). If i set optimizer_index_cost_adj=400, plan uses HJ and cardinality in tkprof trace is right. Thanks in advance.
Best regards, Pavel.Hi there.
What I found:
In schema, where optimizer uses NL:
SQL> select TABLE_NAME,COLUMN_NAME,NUM_BUCKETS,LAST_ANALYZED from user_tab_col_statistics where table_name in ('DISRELFLAT','NOTICES_TABLE','QOPNQ','COMPS');
TABLE_NAME COLUMN_NAME NUM_BUCKETS LAST_ANALYZED
COMPS ID 254 31-JUL-10
COMPS UNIT 254 31-JUL-10
COMPS LOC 34 31-JUL-10
COMPS TIS 246 31-JUL-10
COMPS RTYP 2 31-JUL-10
DISRELFLAT DISGRP 254 31-JUL-10
DISRELFLAT DISMBR 254 31-JUL-10
DISRELFLAT CNT 174 31-JUL-10
DISRELFLAT SPL 10 31-JUL-10
DISRELFLAT DIST 16 31-JUL-10
DISRELFLAT PART 2 31-JUL-10
DISRELFLAT ISA 2 31-JUL-10
DISRELFLAT MIX 2 31-JUL-10
DISRELFLAT CLONAL 1 31-JUL-10
NOTICES_TABLE ID 1 08-SEP-10
NOTICES_TABLE TEXT 1 08-SEP-10
NOTICES_TABLE DESCRIPTION 1 08-SEP-10
NOTICES_TABLE TYPE_ID 4 08-SEP-10
NOTICES_TABLE CUSER_ID 1 08-SEP-10
NOTICES_TABLE CDATE 1 08-SEP-10
NOTICES_TABLE TRUST 10 08-SEP-10
NOTICES_TABLE RTYP 2 08-SEP-10
NOTICES_TABLE CHECKEDBY 1 08-SEP-10
NOTICES_TABLE FEATURE_ID 13 08-SEP-10
QOPNQ QUANTITY 1 31-JUL-10
QOPNQ NUM 12 31-JUL-10
QOPNQ QOP 1 31-JUL-10
27 rows selected.In schema where optimizer uses HJ:
TABLE_NAME COLUMN_NAME NUM_BUCKETS LAST_ANALYZED
COMPS ID 254 28-JUL-10
COMPS UNIT 254 28-JUL-10
COMPS LOC 29 28-JUL-10
COMPS TIS 223 28-JUL-10
COMPS RTYP 2 28-JUL-10
DISRELFLAT DISGRP 254 21-AUG-10
DISRELFLAT DISMBR 1 21-AUG-10
DISRELFLAT CNT 103 21-AUG-10
DISRELFLAT SPL 10 21-AUG-10
DISRELFLAT DIST 11 21-AUG-10
DISRELFLAT PART 2 21-AUG-10
DISRELFLAT ISA 2 21-AUG-10
DISRELFLAT MIX 2 21-AUG-10
DISRELFLAT CLONAL 2 21-AUG-10
NOTICES_TABLE ID 1 09-AUG-10
NOTICES_TABLE TEXT 254 09-AUG-10
NOTICES_TABLE DESCRIPTION 254 09-AUG-10
NOTICES_TABLE TYPE_ID 4 09-AUG-10
NOTICES_TABLE CUSER_ID 1 09-AUG-10
NOTICES_TABLE CDATE 254 09-AUG-10
NOTICES_TABLE TRUST 9 09-AUG-10
NOTICES_TABLE RTYP 2 09-AUG-10
NOTICES_TABLE CHECKEDBY 1 09-AUG-10
NOTICES_TABLE FEATURE_ID 21 09-AUG-10
QOPNQ QUANTITY 1 28-JUL-10
QOPNQ NUM 10 28-JUL-10
QOPNQ QOP 1 28-JUL-10
27 rows selected.Then i gathered statistics with estimate_percent=>null,method_opt=>'for all columns size 1'(without histogramms).
Plan became:
PLAN_TABLE_OUTPUT
Plan hash value: 2184582790
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 91 | 969 (4)| 00:00:03 |
| 1 | SORT GROUP BY | | 1 | 91 | | |
|* 2 | HASH JOIN | | 689 | 62699 | 969 (4)| 00:00:03 |
|* 3 | HASH JOIN | | 689 | 51675 | 719 (3)| 00:00:03 |
|* 4 | HASH JOIN | | 392 | 24304 | 549 (2)| 00:00:02 |
| 5 | NESTED LOOPS | | 377 | 17342 | 479 (1)| 00:00:02 |
|* 6 | HASH JOIN | | 435 | 13485 | 43 (7)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | DISRELFLAT_UI_DISGRP_DISMBR | 12 | 180 | 3 (0)| 00:00:01 |
| 8 | INDEX FAST FULL SCAN | NOTICEDISS_UI_NOTE_DIS | 38127 | 595K| 38 (3)| 00:00:01 |
|* 9 | TABLE ACCESS BY INDEX ROWID | NOTICES_TABLE | 1 | 15 | 1 (0)| 00:00:01 |
|* 10 | INDEX UNIQUE SCAN | NOTICES_TABLE_PK | 1 | | 0 (0)| 00:00:01 |
|* 11 | TABLE ACCESS FULL | NOTICEQUANT | 34306 | 536K| 69 (5)| 00:00:01 |
| 12 | VIEW | | 79375 | 1007K| 167 (3)| 00:00:01 |
| 13 | SORT UNIQUE | | | | | |
| 14 | UNION-ALL | | | | | |
|* 15 | HASH JOIN | | 19811 | 1160K| 86 (11)| 00:00:01 |
| 16 | INDEX FAST FULL SCAN | QUANTITIES_UI_ID_OP | 45161 | 352K| 33 (7)| 00:00:01 |
|* 17 | HASH JOIN | | 19811 | 1006K| 51 (10)| 00:00:01 |
| 18 | TABLE ACCESS FULL | QOPNC | 34214 | 434K| 33 (7)| 00:00:01 |
| 19 | VIEW | | 19811 | 754K| 16 (7)| 00:00:01 |
|* 20 | CONNECT BY WITHOUT FILTERING| | | | | |
| 21 | TABLE ACCESS FULL | QOPNQ | 19811 | 193K| 16 (7)| 00:00:01 |
|* 22 | HASH JOIN | | 34214 | 701K| 68 (9)| 00:00:01 |
| 23 | TABLE ACCESS FULL | QOPNC | 34214 | 434K| 33 (7)| 00:00:01 |
| 24 | INDEX FAST FULL SCAN | QUANTITIES_UI_ID_OP | 45161 | 352K| 33 (7)| 00:00:01 |
| 25 | TABLE ACCESS FULL | COMPS | 212K| 3320K| 244 (5)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("C"."ID"="COMP")
3 - access("NQ"."QUANT"="ID")
4 - access("NQ"."NOTE"="N"."ID")
6 - access("ND"."DIS"="DR"."DISMBR")
7 - access("DR"."DISGRP"=1080801245)
9 - filter("N"."TYPE_ID"=2 AND "N"."TRUST">=0)
10 - access("ND"."NOTE"="N"."ID")
11 - filter("NQ"."LINK"=2)
15 - access("ID"="RT")
17 - access("QOP"="QUANTITY")
20 - access("QUANTITY"=PRIOR "QOP")
22 - access("ID"="QUANTITY")Now,query executes as fast as in first schema.
Best regards,Pavel.
Edited by: Pavel E. -
Query takes long time for first time
I have a table with 100 million records and another tables with many rows.
When I ran a query - it's takes about 1 minute to complete, but when I ran it again it takes less than 1 second to complete.
Why it is happening?
Thanks,
Tz.Welcome to the forum.
When you post a question always provide your 4 digit Oracle version. Different versions have different functionality and this can affect your results and the advice you need.
For performance tuning questions see the FAQ (upper right corner of page) for the information needed for tuning requests.
>
When I ran a query
>
How did you run it? Did you use sql*plus, sqldeveloper, some other tool?
What command did you enter?
Using sql*plus you can get an execution plan for the query by
SQL> set serveroutput on
SQL> set autotrace traceonly
SQL> select * from emp;
Execution Plan
Plan hash value: 3956160932
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 14 | 546 | 3 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| EMP | 14 | 546 | 3 (0)| 00:00:01 |
SQL> -
My query take long time..
The output of tkprof of my trace file is :
SELECT ENEXT.NUM_PRSN_EMPLY ,ENEXT.COD_BUSUN ,ENEXT.DAT_CALDE ,ENEXT.COD_SHFT
FROM
AAC_EMPLOYEE_ENTRY_EXITS5_VIW ENEXT ,PDS.PDS_EMPLOYEES EMPL ,
PDS.PDS_EMPLOYMENT_TYPES EMPTYP ,PDS.PDS_PAY_CONDITIONS PAYCON WHERE
ENEXT.DAT_CALDE BETWEEN :B6 AND :B5 AND ENEXT.NUM_PRSN_EMPLY IN (SELECT
ATT21 FROM APPS.GLOBAL_TEMPS WHERE ATT1 = 'PRSN') AND ENEXT.NUM_PRSN_EMPLY =
EMPL.NUM_PRSN_EMPLY AND EMPL.EMTYP_COD_EMTYP = EMPTYP.COD_EMTYP AND
EMPTYP.LKP_COD_STA_PAY_EMTYP <> 3 AND
NVL(EMPL.LKP_MNTLY_WITHOUT_ENEXT_EMPLY,2) <> 1 AND EMPL.PCOND_COD_STA_PCOND
= PAYCON.COD_STA_PCOND AND NVL(EMPL.LKP_MNTLY_WITHOUT_ENEXT_EMPLY,2) <> 1
AND PAYCON.LKP_FLG_STA_PAY_PCOND = 1 AND ENEXT.DAT_CALDE >=
EMPL.DAT_EMPLT_EMPLY AND ENEXT.DAT_CALDE <= NVL(EMPL.DAT_DSMSL_EMPLY,
TO_DATE('15001229','YYYYMMDD')) AND 1 = (CASE WHEN
ENEXT.LKP_STA_HOLIDAY_CALNR = 2 AND ENEXT.LKP_CAT_SHFT_SHTAB = 1 AND
ENEXT.TYP_DAY BETWEEN 4 AND 6 THEN 0 WHEN ENEXT.LKP_STA_HOLIDAY_CALNR = 2
AND ENEXT.LKP_CAT_SHFT_SHTAB = 1 AND ENEXT.TYP_DAY NOT BETWEEN 4 AND 6 THEN
1 WHEN ENEXT.LKP_STA_HOLIDAY_CALNR = 2 AND ENEXT.LKP_CAT_SHFT_SHTAB = 2
THEN 0 WHEN ENEXT.LKP_STA_HOLIDAY_CALNR = 1 AND ENEXT.LKP_CAT_SHFT_SHTAB =
1 THEN 1 WHEN ENEXT.LKP_STA_HOLIDAY_CALNR = 1 AND ENEXT.LKP_CAT_SHFT_SHTAB =
2 THEN 0 END) AND ENEXT.LKP_COD_DPUT_BUSUN = NVL(:B4 ,
ENEXT.LKP_COD_DPUT_BUSUN) AND ENEXT.LKP_COD_MANAG_BUSUN = NVL(:B3 ,
ENEXT.LKP_COD_MANAG_BUSUN) AND ENEXT.COD_BUSUN = NVL(:B2 , ENEXT.COD_BUSUN)
AND ENEXT.COD_CAL = NVL(COD_CAL, ENEXT.COD_CAL) AND ENEXT.NUM_PRSN_EMPLY =
NVL(:B1 , ENEXT.NUM_PRSN_EMPLY) AND ENEXT.COD_SHFT IN (SELECT
SHFTBL.COD_SHTAB FROM AAC_SHIFT_TABLES SHFTBL WHERE
SHFTBL.LKP_CAT_SHFT_SHTAB = 1) AND ENEXT.DAT_CALDE NOT IN (SELECT ABN.DAT
FROM APPS.AAC_EMPL_EN_EX_ABNORMAL_VIW ABN WHERE ABN.PRSN =
ENEXT.NUM_PRSN_EMPLY AND ABN.DAT BETWEEN :B6 AND :B5 ) AND ENEXT.DAT_CALDE
IN (SELECT EMPENEXT.DAT_STR_SHFT_ENEXT FROM AAC.AAC_EMPLOYEE_ENTRY_EXITS
EMPENEXT WHERE EMPENEXT.EMPLY_NUM_PRSN_EMPLY = EMPL.NUM_PRSN_EMPLY AND
EMPENEXT.DAT_STR_SHFT_ENEXT BETWEEN :B6 AND :B5 AND
EMPENEXT.LKP_FLG_STA_ENEXT <> 3) ORDER BY ENEXT.NUM_PRSN_EMPLY,
ENEXT.DAT_CALDE
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 2 40.45 40.30 306 17107740 0 24
total 6 40.45 40.30 306 17107740 0 24
what is wrong in my query?
why it take long time?user13344656 wrote:
what is wrong in my query?
why it take long time?See PL/SQL forum FAQ
https://forums.oracle.com/forums/ann.jspa?annID=1535
*3. How to improve the performance of my query? / My query is running slow.*
SQL and PL/SQL FAQ
For instructions on what information to post an how to format it. -
Query takes 5 min when using Indexes and 1 Second without Indexes !!
Hi,
We have been using indexes on all tables until recently when we faced problems with queries like the one below:
SELECT a.std_id FROM students a, student_degree b, student_course c, course d
WHERE b.std_id = a.std_id
AND c.std_id = a.std_id
AND d.crn = c.crn
AND b.in_progress = 'Y'
AND b.major_code = 'ABTC'
AND a.program_code = 'DP'
AND a.level_code = 'S2'
AND a.campus_code = '05'
AND a.termcode = '200702';
This query takes more than 5 minutes to return a result, but as soon as we remove indexes on the columns termcode and campus_code,it shows result in 1 second.
What could be the problem ?, Is there an attribute that need to be set when creating these indexes ?
Thanks in advance
MadaniThank you Karthik for your reply.Here are the explain plan report (as shown on Oracle 9i Enterprise Manager)
*1-Explain plan without Indexes:*
Execution Steps:
Step # Step Name
11 SELECT STATEMENT
10 MERGE JOIN
7 SORT [JOIN]
6 NESTED LOOPS
4 NESTED LOOPS
1 ERMS.STUDENT_DEGREE TABLE ACCESS [FULL]
3 ERMS.STUDENTS TABLE ACCESS [BY INDEX ROWID]
2 ERMS.SYS_C006642 INDEX [UNIQUE SCAN]
5 ERMS.SYS_C007065 INDEX [RANGE SCAN]
9 SORT [JOIN]
8 ERMS.COURSE TABLE ACCESS [FULL]
Step # Description
1 This plan step retrieves all rows from table STUDENT_DEGREE.
2 This plan step retrieves a single ROWID from the B*-tree index SYS_C006642.
3 This plan step retrieves rows from table STUDENTS through ROWID(s) returned by an index.
4 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause.
5 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SYS_C007065.
6 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause.
7 This plan step accepts a row set (its only child) and sorts it in preparation for a merge-join operation.
8 This plan step retrieves all rows from table COURSE.
9 This plan step accepts a row set (its only child) and sorts it in preparation for a merge-join operation.
10 This plan step accepts two sets of rows sorted on the join key. By walking both sets of rows in the order of the join key, every distinct pair of rows satisfying the join condition in the WHERE clause is found through a single pass of the row sets.
11 This plan step designates this statement as a SELECT statement.
*2-Explain plan with Indexes:* (I added index on column campus_code which is a varchar2 column)
Execution Steps:
Step # Step Name
11 SELECT STATEMENT
10 MERGE JOIN
7 SORT [JOIN]
6 NESTED LOOPS
4 NESTED LOOPS
1 ERMS.COURSE TABLE ACCESS [FULL]
3 ERMS.STUDENTS TABLE ACCESS [BY INDEX ROWID]
2 ERMS.INDEX_STUDENTS_CAMPUS_CODE INDEX [RANGE SCAN]
5 ERMS.SYS_C007065 INDEX [RANGE SCAN]
9 SORT [JOIN]
8 ERMS.STUDENT_DEGREE TABLE ACCESS [FULL]
Step # Description
1 This plan step retrieves all rows from table COURSE.
2 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index INDEX_STUDENTS_CAMPUS_CODE.
3 This plan step retrieves rows from table STUDENTS through ROWID(s) returned by an index.
4 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause.
5 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SYS_C007065.
6 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause.
7 This plan step accepts a row set (its only child) and sorts it in preparation for a merge-join operation.
8 This plan step retrieves all rows from table STUDENT_DEGREE.
9 This plan step accepts a row set (its only child) and sorts it in preparation for a merge-join operation.
10 This plan step accepts two sets of rows sorted on the join key. By walking both sets of rows in the order of the join key, every distinct pair of rows satisfying the join condition in the WHERE clause is found through a single pass of the row sets.
11 This plan step designates this statement as a SELECT statement. -
SQL-Command to long to run with SQL*Plus
Hello to everyone,
I'm creating a dynamic SQL Script to run with SQL*Plus.
The Script contains only INSERT Command.
The point is that the SQL*Plus supports only SQL-Strings (Commands)
not longer than 2500 Characters.
I've considered to split the String in Insert- and Update-Command(s),
but I've would like first to know if there any simpler way to run these
Commands on SQL*Plus.
thanx in Advance
bmSQL> create table t(x varchar2(4000));
Table created.
SQL> insert into t values (
'1234567890........0........0........0........0........0........0........0........0......100' ||
'1234567890........0........0........0........0........0........0........0........0......200' ||
'1234567890........0........0........0........0........0........0........0........0......300' ||
'1234567890........0........0........0........0........0........0........0........0......400' ||
'1234567890........0........0........0........0........0........0........0........0......500' ||
'1234567890........0........0........0........0........0........0........0........0......600' ||
'1234567890........0........0........0........0........0........0........0........0......700' ||
'1234567890........0........0........0........0........0........0........0........0......800' ||
'1234567890........0........0........0........0........0........0........0........0......900' ||
'1234567890........0........0........0........0........0........0........0........0.....1000' ||
'1234567890........0........0........0........0........0........0........0........0.....1100' ||
'1234567890........0........0........0........0........0........0........0........0.....1200' ||
'1234567890........0........0........0........0........0........0........0........0.....1300' ||
'1234567890........0........0........0........0........0........0........0........0.....1400' ||
'1234567890........0........0........0........0........0........0........0........0.....1500' ||
'1234567890........0........0........0........0........0........0........0........0.....1600' ||
'1234567890........0........0........0........0........0........0........0........0.....1700' ||
'1234567890........0........0........0........0........0........0........0........0.....1800' ||
'1234567890........0........0........0........0........0........0........0........0.....1900' ||
'1234567890........0........0........0........0........0........0........0........0.....2000' ||
'1234567890........0........0........0........0........0........0........0........0.....2100' ||
'1234567890........0........0........0........0........0........0........0........0.....2200' ||
'1234567890........0........0........0........0........0........0........0........0.....2300' ||
'1234567890........0........0........0........0........0........0........0........0.....2400' ||
'1234567890........0........0........0........0........0........0........0........0.....2500' ||
'1234567890........0........0........0........0........0........0........0........0.....2600' ||
'1234567890........0........0........0........0........0........0........0........0.....2700' ||
'1234567890........0........0........0........0........0........0........0........0.....2800' ||
'1234567890........0........0........0........0........0........0........0........0.....2900' ||
'1234567890........0........0........0........0........0........0........0........0.....3000'
1 row created.try to break your query in multiple lines in order to avoid
SP2-0027: Input is too long (> 2499 characters) - line ignored -
Query takes long time to return results.
I am on Oracle database 10g Enterprise Edition Release 10.2.0.4.0 – 64 bit
This query takes about 58 seconds to return 180 rows...
SELECT order_num,
order_date,
company_num,
customer_num,
address_type,
create_date as address_create_date,
contact_name,
first_name,
middle_init,
last_name,
company_name,
street_address_1,
customer_class,
city,
state,
zip_code,
country_code,
MAX(decode(media_type,
'PHH',
phone_area_code || '''' || phone_number,
NULL)) home_phone,
MAX(decode(media_type,
'PHW',
phone_area_code || '''' || phone_number,
NULL)) work_phone,
address_seq_num,
street_address_2
FROM (SELECT oh.order_num order_num,
oh.order_datetime order_date,
oh.company_num company_num,
oh.customer_num customer_num,
ad.address_type address_type,
c.create_date create_date,
con.first_name || '''' || con.last_name contact_name,
con.first_name first_name,
con.middle_init middle_init,
con.last_name last_name,
ad.company_name company_name,
ad.street_address_1 street_address_1,
c.customer_class customer_class,
ad.city city,
ad.state state,
ad.zip_code zip_code,
ad.country_code,
cph.media_type media_type,
cph.phone_area_code phone_area_code,
cph.phone_number phone_number,
ad.address_seq_num address_seq_num,
ad.street_address_2 street_address_2
FROM reporting_base.gt_gaft_orders gt,
doms.us_ordhdr oh,
doms.us_address ad,
doms.us_customer c,
doms.us_contact con,
doms.us_contph cph
WHERE oh.customer_num = c.customer_num(+)
AND oh.customer_num = ad.customer_num(+)
AND (
ad.customer_num = c.customer_num
AND
ad.address_type = 'B'
OR (
ad.customer_num = c.customer_num
AND
ad.address_type = 'S'
AND
ad.address_seq_num = oh.ship_to_seq_num
AND ad.customer_num = con.customer_num(+)
AND ad.address_type = con.address_type(+)
AND ad.address_seq_num = con.address_seq_num(+)
AND con.customer_num = cph.customer_num(+)
AND con.contact_id = cph.contact_id(+)
AND oh.order_num = gt.order_num
AND oh.business_unit_id = gt.business_unit_id)
GROUP BY order_num,
order_date,
company_num,
customer_num,
address_type,
create_date,
contact_name,
first_name,
middle_init,
last_name,
company_name,
street_address_1,
customer_class,
city,
state,
zip_code,
country_code,
address_seq_num,
street_address_2;This is the explain plan for the query:
Plan
SELECT STATEMENT FIRST_ROWS Cost: 21 Bytes: 207 Cardinality: 1
18 HASH GROUP BY Cost: 21 Bytes: 207 Cardinality: 1
17 NESTED LOOPS OUTER Cost: 20 Bytes: 207 Cardinality: 1
14 NESTED LOOPS OUTER Cost: 16 Bytes: 183 Cardinality: 1
11 FILTER
10 NESTED LOOPS OUTER Cost: 12 Bytes: 152 Cardinality: 1
7 NESTED LOOPS OUTER Cost: 8 Bytes: 74 Cardinality: 1
4 NESTED LOOPS OUTER Cost: 5 Bytes: 56 Cardinality: 1
1 TABLE ACCESS FULL TABLE (TEMP) REPORTING_BASE.GT_GAFT_ORDERS Cost: 2 Bytes: 26 Cardinality: 1
3 TABLE ACCESS BY INDEX ROWID TABLE DOMS.US_ORDHDR Cost: 3 Bytes: 30 Cardinality: 1
2 INDEX UNIQUE SCAN INDEX (UNIQUE) DOMS.USORDHDR_IXUPK_ORDNUMBUID Cost: 2 Cardinality: 1
6 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_CUSTOMER Cost: 3 Bytes: 18 Cardinality: 1 Partition #: 11
5 INDEX UNIQUE SCAN INDEX (UNIQUE) DOMS.USCUSTOMER_IXUPK_CUSTNUM Cost: 2 Cardinality: 1
9 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_ADDRESS Cost: 4 Bytes: 156 Cardinality: 2 Partition #: 13
8 INDEX RANGE SCAN INDEX (UNIQUE) DOMS.USADDR_IXUPK_CUSTATYPASEQ Cost: 3 Cardinality: 2
13 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_CONTACT Cost: 4 Bytes: 31 Cardinality: 1 Partition #: 15
12 INDEX RANGE SCAN INDEX DOMS.USCONT_IX_CNATAS Cost: 3 Cardinality: 1
16 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_CONTPH Cost: 4 Bytes: 24 Cardinality: 1 Partition #: 17
15 INDEX RANGE SCAN INDEX (UNIQUE) DOMS.USCONTPH_IXUPK_CUSTCONTMEDSEQ Cost: 3 Cardinality: 1 Cost is good. All indexes are used. However the time to return the data is very high.
Any ideas to make the query faster?.
ThanksHi, here is the tkprof output as requested by Rob..
TKPROF: Release 10.2.0.4.0 - Production on Mon Jul 13 09:07:09 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: axispr1_ora_15293.trc
Sort options: default
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
SELECT ORDER_NUM, ORDER_DATE, COMPANY_NUM, CUSTOMER_NUM, ADDRESS_TYPE,
CREATE_DATE AS ADDRESS_CREATE_DATE, CONTACT_NAME, FIRST_NAME, MIDDLE_INIT,
LAST_NAME, COMPANY_NAME, STREET_ADDRESS_1, CUSTOMER_CLASS, CITY, STATE,
ZIP_CODE, COUNTRY_CODE, MAX(DECODE(MEDIA_TYPE, 'PHH', PHONE_AREA_CODE ||
'''' || PHONE_NUMBER, NULL)) HOME_PHONE, MAX(DECODE(MEDIA_TYPE, 'PHW',
PHONE_AREA_CODE || '''' || PHONE_NUMBER, NULL)) WORK_PHONE, ADDRESS_SEQ_NUM,
STREET_ADDRESS_2
FROM
(SELECT OH.ORDER_NUM ORDER_NUM, OH.ORDER_DATETIME ORDER_DATE, OH.COMPANY_NUM
COMPANY_NUM, OH.CUSTOMER_NUM CUSTOMER_NUM, AD.ADDRESS_TYPE ADDRESS_TYPE,
C.CREATE_DATE CREATE_DATE, CON.FIRST_NAME || '''' || CON.LAST_NAME
CONTACT_NAME, CON.FIRST_NAME FIRST_NAME, CON.MIDDLE_INIT MIDDLE_INIT,
CON.LAST_NAME LAST_NAME, AD.COMPANY_NAME COMPANY_NAME, AD.STREET_ADDRESS_1
STREET_ADDRESS_1, C.CUSTOMER_CLASS CUSTOMER_CLASS, AD.CITY CITY, AD.STATE
STATE, AD.ZIP_CODE ZIP_CODE, AD.COUNTRY_CODE, CPH.MEDIA_TYPE MEDIA_TYPE,
CPH.PHONE_AREA_CODE PHONE_AREA_CODE, CPH.PHONE_NUMBER PHONE_NUMBER,
AD.ADDRESS_SEQ_NUM ADDRESS_SEQ_NUM, AD.STREET_ADDRESS_2 STREET_ADDRESS_2
FROM REPORTING_BASE.GT_GAFT_ORDERS GT, DOMS.US_ORDHDR OH, DOMS.US_ADDRESS
AD, DOMS.US_CUSTOMER C, DOMS.US_CONTACT CON, DOMS.US_CONTPH CPH WHERE
OH.ORDER_NUM = GT.ORDER_NUM AND OH.BUSINESS_UNIT_ID = GT.BUSINESS_UNIT_ID
AND OH.CUSTOMER_NUM = C.CUSTOMER_NUM(+) AND OH.CUSTOMER_NUM =
AD.CUSTOMER_NUM(+) AND AD.CUSTOMER_NUM = C.CUSTOMER_NUM AND (
AD.ADDRESS_TYPE = 'B' OR ( AD.ADDRESS_TYPE = 'S' AND AD.ADDRESS_SEQ_NUM =
OH.SHIP_TO_SEQ_NUM ) ) AND AD.CUSTOMER_NUM = CON.CUSTOMER_NUM(+) AND
AD.ADDRESS_TYPE = CON.ADDRESS_TYPE(+) AND AD.ADDRESS_SEQ_NUM =
CON.ADDRESS_SEQ_NUM(+) AND CON.CUSTOMER_NUM = CPH.CUSTOMER_NUM(+) AND
CON.CONTACT_ID = CPH.CONTACT_ID(+) ) GROUP BY ORDER_NUM, ORDER_DATE,
COMPANY_NUM, CUSTOMER_NUM, ADDRESS_TYPE, CREATE_DATE, CONTACT_NAME,
FIRST_NAME, MIDDLE_INIT, LAST_NAME, COMPANY_NAME, STREET_ADDRESS_1,
CUSTOMER_CLASS, CITY, STATE, ZIP_CODE, COUNTRY_CODE, ADDRESS_SEQ_NUM,
STREET_ADDRESS_2
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 257 0.04 0.05 45 0 0 6421
total 257 0.04 0.05 45 0 0 6421
Misses in library cache during parse: 0
Parsing user id: 126
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 257 0.04 0.05 45 0 0 6421
total 257 0.04 0.05 45 0 0 6421
Misses in library cache during parse: 0
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 0 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
1 user SQL statements in session.
0 internal SQL statements in session.
1 SQL statements in session.
Trace file: axispr1_ora_15293.trc
Trace file compatibility: 10.01.00
Sort options: default
1 session in tracefile.
1 user SQL statements in trace file.
0 internal SQL statements in trace file.
1 SQL statements in trace file.
1 unique SQL statements in trace file.
289 lines in trace file.
83 elapsed seconds in trace file.Thanks in advance! -
Query takes long when using UNION
Hi ,
I habe a query as follows;
SELECT
'9999' site_id,
m.ghi_prov_num provnum,
SUBSTR (l.seq_num, 1, 3)provloc,
t.dea_number dea,
t.license_number statelicensenumber ,
n.npi_num npi,
m.prefix prefixname,
m.lastname lastname,
m.firstname firstname,
t.middle_name middleinitial,
m.suffix suffixname,
null clinicname,
l.street1 addressline1,
l.street2 addressline2,
l.city city,
l.state state,
l.zip5 zip,
l.phone phoneprimary,
null ext,
null fax,
null email,
null alt_phone,
null alt_phone_ext
FROM provider m, LOCATION l, npi n,TEMP_VITAL_CACTUS t,test_provider_pin pin
WHERE m.ghi_prov_num=l.ghi_prov_num
and m.ghi_prov_num=n.ghi_prov_num(+)
and m.ghi_prov_num=t.ghi_prov_num(+)
and m.tax_id=pin.tax_id
UNION
SELECT
'9999', m.ghi_prov_num ,
m.location provloc,
null ,
null ,
n.npi_num ,
null ,
m.lastname ,
m.firstname ,
null,
null ,
null ,
m.street1 ,
m.street2 ,
m.city ,
m.state ,
m.zip5 ,
m.phone ,
null ,
null ,
null ,
null ,
null
FROM dental_provider m, npi n,test_provider_pin pin
WHERE m.ghi_prov_num=n.tax_id(+)
and m.location=n.location(+)
and pin.tax_id=m.ghi_prov_num;The query takes for ever;
But Individual query takes less than a sec to execute.Is there any way can i rewrite the query?
Please help
Hena.user11253970 wrote:
But Individual query takes less than a sec to execute.Is there any way can i rewrite the query?Have a feeling you are using Toad/SQL Navigator or similar tool which returns data one screen at a time. If so, then it does not "takes less than a sec to execute" but rather to fetch first screen of rows. When you use UNION Oracle has to return distinct rows from both queries. Therefore it must fetch not just first screen but all rows. To verify, issue first query and in yiour GUI tool click on get last screen. Then you'll know how long whole select takes. Do the same for second query. Also, do you need distinct rows or akll rows? IF all rows, change UNION to UNION ALL.
SY. -
Why does it take longer to Save with Layers v. no Layers?
I've noticed that file save times go way up even with just 1 layer (plus Background) compared to saving with no layers. "Flat" PSDs save very fast, whether to my SSD boot drive, or to my spinny work drive.Is this normal? And can anyone tell me why?
My scratch disc is on my SSD boot drive. Windows 7 Ultimate fully updated. I have 30GB of RAM and my average file size (open) is around 400MB. I do have the compatibility turned on (otherwise Lightroom doesn't like it), and compression. I understand those will add more time. But why so much more than a "flat" PSD?Thanks. I need to rephrase my subject line I guess...
Obviously, additional layers will take longer to save, because, like you said, each layers is like another image (sorta). HOWEVER, the save time seems to increase EXPONENTIALLY just by adding 1 layer.
Here's a specific example...
I'm working on a 7360 x 4912 image which Photoshop says is 206.9M. It takes less than 2 seconds to save the PSD.
I clicked Ctrl+J to copy the Background layer to a new layer. Now there's the Background layer, plus Layer 1, and now Photoshop tells me it's 206.9M/413.7M. Now it takes 34 seconds to save the PSD!
So it's not just double, it takes 17x longer!!! Why so much longer? -
Query takes long time 41 seconds to run how to tune
my query is simple as follows...i dont know how to tune it..
cur_memb_count (p_as_of_date IN date)
is
select
count(ip.individual_id) membercount,
--lpad(re.region_id,2,'0')||lpad('000',3,'0')||lpad( pb.plan_cd,3,'0') group_id,
substr(pb.plan_cd,1,1)||lpad(re.region_id, 2,'0')||'0000' group_id,
ipp.legal_entity_id,
bus.gl_bus_unit_a,
bus.lob,
loc.gl_loc_nbr_a,
prod.gl_product_cd_a,
prod.gl_fin_argmt_a,pb.plan_type_id ,pb.plan_cd
from
plan pb ,region_map re , state_plan_billing spb,
insured_plan_profile ipp , insured_plan ip ,
ods.oods_gl_bus_unit bus, ods.oods_gl_loc_nbr loc,
ods.oods_gl_product_line prod,
household h,
employer_household eh
where
ipp.residence_st_plan_billing_id = spb.state_plan_billing_id
and ipp.insured_plan_id = ip.insured_plan_id
and ip.plan_cd = pb.plan_cd
and pb.plan_cd=spb.plan_cd
-- and pb.plan_type_id = loc.lob
and spb.state_cd = re.state_cd
and p_as_of_date between ip.insured_plan_effective_date and
nvl(ip.insured_plan_termination_date,'31-dec-9999')
and ip.insured_plan_effective_date <>
nvl(ip.insured_plan_termination_date,'31-dec-9999')
-- the condition below is necessary. but not enough data to test.when
uncommented will only give
-- a few records. try testing it just by uncommenting it.
--and p_as_of_date between re.region_map_start_date and re.region_map_stop_date
and loc.lob=prod.lob and loc.lob=bus.lob(+) and loc.company_cd=bus.company_cd(+)
and p_as_of_date between pb.plan_start_date and pb.plan_stop_date
and p_as_of_date between ipp.ins_plan_profile_start_date and
ipp.ins_plan_profile_stop_date
-- and lpad(re.region_id,2,'0')||lpad('000',3,'0')||lpad(pb.plan_cd,3,'0')
= loc.group_id
and substr(pb.plan_cd,1,
1)||lpad(re.region_id,2,'0')||nvl(employee_id,'0000') =loc.group_id
and p_household_id_param = h.household_id
and h.household_id = eh.employer_household_id
and p_date_param between eh.emp_hhold_start_date and eh.emp_hhold_stop_date
and insplan.individual_id=housmemb.individual_id(+)
and eh.delete_ind = 'N'
group by
--lpad(re.region_id,2,'0')||lpad('000',3,'0')||lpad(pb.plan_cd,3,'0'),
substr(pb.plan_cd ,1,1)||lpad(re.region_id,2, '0')||nvl(employee_id,'0000'),If many full table scans on big tables consider creating indexes. Or if many index reads consider forcing full table scans :)
Ah, I just love these tuning questions. "My query is slow. Please make it go fast". Sure, put on these red shoes, click your heels three times and make a wish. Alas, tuning is rather more complicated than that, more of a science than a voodoo rirtual. We would like to help. But we need more data, some concrete figures. Otherwise we're just guessing.
So, first off, please read the Performance Tuning Guide. Apply some of its techniques. If you still don't understand why your query is running slow, come back to us with table descriptions, volumetrics, indexes, explain plans, stats, timings and tkprof output.
Good luck, APC -
Select statement takes very long to run with order by clause.
Hi all,
I have a select statement which when I run without the order by clause takes arround 2 minutes to run. But with the order by clause it goes on for ever. I am trying to access the database server through a network which is not too fast.
The select statement is based on 9 views which are again based on some views. It also has inline views and outer joins. These views and inline views can not be done away with.
When selected without the order by clause it gives 3215 records.
Anything like 2 to 3 minutes will be Ok.
Thanks.
--MalayThe select statement is as follows :-
SELECT f.system_name,
a.signal_type,
f.sys_signal_name,
a.bus_desc,
b.vl_ident,
b.vl_name,
b.src_mac,
b.src_mac_addr,
b.dest_mac,
b.dest_mac_addr,
b.network,
bb.bufr_size_in_bytes,
bb.bag_in_ms,
bb.is_rma_used,
bb.is_ic_used,
bb.sub_vl_cnt,
bb.skew_max_in_ns,
cc.msg_name,
c.src_ip,
c.src_ip_addr,
c.src_port,
c.dest_ip,
c.dest_ip_addr,
c.dest_port,
cc.rate_in_ms,
cc.tx_mode,
cc.protocol,
cc.port_type,
cc.msg_length_in_bytes,
d.mnemonic,
d.start_addr32,
d.lsb,
d.end_addr32,
d.msb,
d.format,
d.init_value,
d.fs_mnemonic,
d.fs_afdx_data_id,
d.digital_data_id,
DECODE(
d.digital_datatype,
NULL, '',
'UNUSED', '',
api$util.concat_column_data(
'api_'
|| d.digital_datatype,
'digital_data_id',
d.digital_data_id,
bool.FALSE
) AS data_details,
f.connection_id
|| '_'
|| a.digital_bus_id
|| '_'
|| b.afdx_vl_id
|| '_'
|| bb.afdx_output_id
|| '_'
|| c.afdx_frame_id
|| '_'
|| cc.afdx_msg_id
|| '_'
|| d.afdx_data_id AS KEY
FROM api_afdx a,
api_afdx_vl b,
api_afdx_output bb,
api_afdx_frame c,
api_afdx_msg cc,
api_afdx_data d,
vf_signal e,
(SELECT DISTINCT aa.signal_id,
cc.system_name,
bb.connection_id,
bb.sys_signal_name
FROM vf_nodes aa,
vf_connections bb,
vf_system cc
WHERE aa.connection_id = bb.connection_id
AND bb.system_id = cc.system_id) f
WHERE e.signal_id = f.signal_id(+)
AND e.digital_bus_id = a.digital_bus_id
AND a.digital_bus_id = bb.digital_bus_id(+)
AND bb.afdx_output_id = b.afdx_output_id(+)
AND b.afdx_vl_id = c.afdx_vl_id(+)
AND bb.afdx_output_id = cc.afdx_output_id(+)
AND cc.afdx_msg_id = d.afdx_msg_id(+)
ORDER BY f.system_name,
a.signal_type,
f.sys_signal_name,
b.vl_name,
cc.msg_name,
d.start_addr32,
d.lsb;
Where api_afdx ,
api_afdx_vl ,
api_afdx_output ,
api_afdx_frame ,
api_afdx_msg ,
api_afdx_data ,
vf_signal ,
vf_nodes ,
vf_connections ,
vf_system
are all views. -
Hi All.
When i execute select query from View it takes about 00:00:45:12 sec to pull the data , but when i execute same query in some other system(different database with same table structure) it takes about 00:00:02:05 sec.
1)I have tried by dropped and recreated the index then i tried by exec dbms_stats.gather_table_stats procedure still no luck.
Please help me to understand the reason difference in response time
Thanks
sankardid you run the EXPLAIN PLAN?
-
Query take long time in fetching when used within a procedure
The Database is : Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
Query just takes a second from toad but when used inside a procedure as a cursor it takes takes 3 to 5 minutes.
Following is the Tkprof information when running from procedure.
SELECT CHCLP.CLM_PRVDR_TYPE_LKPCD, CHCLP.PRVDR_LCTN_IID, TO_CHAR
(CHCLP.MODIFIED_DATE, 'MM-dd-yyyy hh24:mi:ss') MODIFIED_DATE,
CHCLP.PRVDR_LCTN_IDENTIFIER, CHCLP.CLM_HDR_CLM_LN_X_PVDR_LCTN_SID
FROM
CLM_HDR_CLM_LN_X_PRVDR_LCTN CHCLP WHERE CHCLP.CLAIM_HEADER_SID = :B1 AND
CHCLP.CLAIM_LINE_SID IS NULL AND CHCLP.IDNTFR_TYPE_CID = 7
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 110.79 247.79 568931 576111 0 3
total 2 110.79 247.79 568931 576111 0 3
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93 (CMSAPP) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 PARTITION RANGE (SINGLE) PARTITION:KEYKEY
0 TABLE ACCESS MODE: ANALYZED (BY LOCAL INDEX ROWID) OF
'CLM_HDR_CLM_LN_X_PRVDR_LCTN' (TABLE) PARTITION:KEYKEY
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'XAK1CLM_HDR_CLM_LN_X_PRVDR_LCT' (INDEX (UNIQUE))
PARTITION:KEYKEY
Execution plan when running just the query from TOAD is: (it comes out in a second)
Plan
SELECT STATEMENT ALL_ROWSCost: 6 Bytes: 100 Cardinality: 2
3 PARTITION RANGE SINGLE Cost: 6 Bytes: 100 Cardinality: 2 Partition #: 1 Partitions accessed #13
2 TABLE ACCESS BY LOCAL INDEX ROWID TABLE CMSAPP.CLM_HDR_CLM_LN_X_PRVDR_LCTN Cost: 6 Bytes: 100 Cardinality: 2 Partition #: 2 Partitions accessed #13
Why would fetching take such a long time? Please let me know if you need any other information.
Thank You.
Edited by: spur230 on Apr 1, 2009 10:23 AM
Edited by: spur230 on Apr 1, 2009 10:26 AM
Edited by: spur230 on Apr 1, 2009 10:28 AM
Edited by: spur230 on Apr 1, 2009 10:30 AMQuery just takes a second from toad It's possible that the query starts returning rows in a second, but that's not the time required for the entire query.
Maybe you are looking for
-
Error message when trying to Copy iPhoto Library
I am trying to backup my iPhoto Library from it's location on a WD external hard drive to another WD external hard drive. The Library is 54GB in size. When I try to copy the library, it copies about 1.1GB then I get this message: "The operation canno
-
Hello, we create IDoc-files with the tcode we14. The system which catch the file do this on the next day. The report of the tcode we14 always create a new file. So when I run the report twize a day the second run kll the file of the first run. I don'
-
Where did the time display go and why is the screen stuck on master track? Thanks.
My time display disappeared and the screen is stuck on master track. Any ideas? Thanks.
-
Making Roll over images from photoshop layout
Hello Everyone, I am working on a website and I have sliced my parts of my Photoshop file. I have saved as a html with images as well! How would I amek a roll over image out of the buttons I made in photoshop and sliced?
-
Database Authentication Schema Setup
Hi, Page 13-17 in the User Guide talks about setting up DAD credentials verification. Text is copied below About DAD Credentials Verification DAD database authentication uses the Oracle database native authentication and user mechanisms to authentica