SQL Query Performance [message #288749] |
Tue, 18 December 2007 10:00 |
rdoggart
Messages: 10 Registered: December 2007 Location: Belfast
|
Junior Member |
|
|
Hi All,
Having problem with the following query:
select * from (
SELECT
ENQUIRY.ID AS EnquiryID,
CASES.CaseId,
CASES.CaseRef,
SUBJECT.id AS SubjectID,
SUBJECT.name AS SubjectName,
REASON.id AS ReasonID,
REASON.name AS ReasonName,
TYPE.id AS TypeID,
TYPE.name AS TypeName,
ENQUIRY.CreationDate AS OpenedDateTime
FROM LGNCC_CLOSEDCASEHDR CASES, LGNCC_ENQUIRY ENQUIRY,
LGNCC_ENQUIRYSUBJECT SUBJECT, LGNCC_ENQUIRYREASON REASON, LGNCC_ENQUIRYTYPE TYPE
WHERE CASES.enquiryId = ENQUIRY.ID
AND ENQUIRY.deleteddate is null
AND ENQUIRY.enquirytype = TYPE.id
AND TYPE.reason = REASON.id
AND REASON.subject = SUBJECT.id
)
where upper(caseref) like '109969%'
and (1=1) order by openeddatetime desc;
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.26 0.41 0 27 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 2.34 4.25 13312 13337 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 2.60 4.67 13312 13364 0 1
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 118 (FLINE_611)
Rows Row Source Operation
------- ---------------------------------------------------
1 SORT ORDER BY
1 HASH JOIN
27 INDEX FULL SCAN LGNCC_ENQUIRYSUBJECT_IDX_001 (object id 131778)
1 HASH JOIN
80 INDEX FULL SCAN LGNCC_ENQUIRYREASON_IDX_002 (object id 131772)
1 HASH JOIN
280 INDEX FAST FULL SCAN LGNCC_ENQUIRYTYPE_IDX_008 (object id 131782)
1 HASH JOIN
1 TABLE ACCESS FULL LGNCC_CLOSEDCASEHDR
1426265 TABLE ACCESS FULL LGNCC_ENQUIRY
The inner code is from a view so I extracted it to make the query joins visible.
All the statistics are upto date and histograms exist on indexed columns.
Can anyone suggest how to make the code more efficient, by reducing the 1426265 row hash join which returns one row.
Regards
Ronnie
|
|
|
|
Re: SQL Query Performance [message #288780 is a reply to message #288749] |
Tue, 18 December 2007 11:39 |
S.Rajaram
Messages: 1027 Registered: October 2006 Location: United Kingdom
|
Senior Member |
|
|
and (1=1) order by openeddatetime desc
I would like to know what is the use/need of the above line. Also I am trying to understand the need of upper function this line
upper(caseref) like '109969%' and I am not able to understand why do you need upper function here. All you are saying is get me all the records which start with 109969 and it is a number. Why do you need upper(function) and why it is nested why can't you have it in the same level (i.e) why can't you include the outer where clause inside the inner select or Am I missing something very basic here ?
Regards
Raj
[Updated on: Tue, 18 December 2007 11:40] Report message to a moderator
|
|
|
Re: SQL Query Performance [message #288791 is a reply to message #288749] |
Tue, 18 December 2007 13:29 |
rdoggart
Messages: 10 Registered: December 2007 Location: Belfast
|
Junior Member |
|
|
Hi,
The inner select is the code from a view that is normally called, I extracted it so you could see both the outer call and the view source.
The code is generated from an application so I have limited options for making changes.
Ronnie
|
|
|
|
Re: SQL Query Performance [message #288928 is a reply to message #288749] |
Wed, 19 December 2007 01:30 |
rdoggart
Messages: 10 Registered: December 2007 Location: Belfast
|
Junior Member |
|
|
I just wanted to make sure I had not missed anything obvious, as we all make mistakes. Adding an index on upper(caseref) makes no difference as I already tried that.
Ronnie
|
|
|
|
Re: SQL Query Performance [message #288938 is a reply to message #288749] |
Wed, 19 December 2007 01:47 |
rdoggart
Messages: 10 Registered: December 2007 Location: Belfast
|
Junior Member |
|
|
Its 9.2.0.6 and I did regather the stats after creating the index, the actual query uses '%119686%' for most of the searches so the index is excluded. I know that '119686%' would us the index, but it all depends on what the user types in for the search criteria.
Thanks
Ronnie
|
|
|
|
Re: SQL Query Performance [message #288949 is a reply to message #288749] |
Wed, 19 December 2007 02:15 |
rdoggart
Messages: 10 Registered: December 2007 Location: Belfast
|
Junior Member |
|
|
Michel,
Thanks for your help, I relooked at the plans from the queries and noticed that when the index existed it used nested loops rather than hash joins. I put in a first_rows hint and now both are performing well.
Ronnie
|
|
|