Home » RDBMS Server » Performance Tuning » Tune sql query (oracle 10.2.0.4)
Tune sql query [message #454016] Mon, 03 May 2010 08:21 Go to next message
ankush_chawla
Messages: 136
Registered: November 2006
Senior Member
Plan Cost : 43485

SELECT tblempview.empobjid            AS empobjid,
       tblempview.lastname            AS lastname,
       tblempview.firstname           AS firstname,
       tblempview.jobfunction         AS jobfunction,
       tblempview.bizcalhdr           AS bizcalhdrobjid,
       tblempview.empmaxtravradius    AS empmaxtravradius,
       tblempview.repsite_objid       AS repsiteobjid,
       tblempview.repsite_name        AS repsitename,
       tblempview.repsite_region      AS repsiteregion,
       tblempview.repsite_district    AS repsitedistrict,
       tblempview.repsite_city        AS repsitecity,
       tblempview.repsite_state       AS repsitestate,
       tblempview.repsite_lat         AS repsitelat,
       tblempview.repsite_long        AS repsitelong,
       tblempview.repsite_holiday_grp AS repsiteholidaygrp,
       tblempview.physsite_objid      AS physsiteobjid,
       tblempview.physsite_name       AS physsitename,
       tblempview.physsite_region     AS physsiteregion,
       tblempview.physsite_district   AS physsitedistrict,
       tblempview.physsite_lat        AS physsitelat,
       tblempview.physsite_long       AS physsitelong,
       tz.gmt_diff,
       tz.full_name,
       dst.start_time                 AS dststarttime,
       dst.end_time                   AS dstendtime,
       country.NAME                   AS countryname,
       penalty.x_map_from             AS beforeotmins,
       penalty.x_map_to               AS afterotmins
FROM   ora_emp_loc_view tblempview,
       table_user usr,
       table_site physsite,
       table_address addr,
       table_country country,
       table_time_zone tz,
       table_daylight_hr dst,
       table_x_gsa_penalty_map penalty
WHERE  tblempview.fieldeng = 1
       AND tblempview.usrobjid = usr.objid
       AND usr.status = 1
       AND tblempview.physsite_objid = physsite.objid
       AND physsite.cust_primaddr2address = addr.objid
       AND addr.address2country = country.objid
       AND addr .address2time_zone = tz.objid
       AND tblempview.otdefobjid = penalty.objid(+)
       AND tz.objid = dst.daylight_hr2time_zone(+)
       AND dst.start_time(+) <= :1
       AND dst.end_time(+) >= :2  



PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------
Plan hash value: 1423440423

-----------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 8799 | 3789K| 43485 (1)| 00:08:42 |
|* 1 | HASH JOIN RIGHT OUTER | | 8799 | 3789K| 43485 (1)| 00:08:42 |
|* 2 | TABLE ACCESS FULL | TABLE_DAYLIGHT_HR | 1 | 23 | 3 (0)| 00:00:01 |
|* 3 | HASH JOIN | | 8799 | 3591K| 43482 (1)| 00:08:42 |
| 4 | TABLE ACCESS FULL | TABLE_TIME_ZONE | 326 | 11410 | 3 (0)| 00:00:01 |
|* 5 | HASH JOIN | | 8799 | 3291K| 43478 (1)| 00:08:42 |
| 6 | TABLE ACCESS FULL | TABLE_COUNTRY | 252 | 5040 | 3 (0)| 00:00:01 |
| 7 | NESTED LOOPS | | 8799 | 3119K| 43475 (1)| 00:08:42 |
| 8 | NESTED LOOPS | | 8873 | 2963K| 36371 (1)| 00:07:17 |
| 9 | NESTED LOOPS | | 8873 | 2842K| 29267 (1)| 00:05:52 |
| 10 | NESTED LOOPS | | 8947 | 2717K| 22104 (1)| 00:04:26 |
|* 11 | HASH JOIN | | 8947 | 2166K| 14941 (1)| 00:03:00 |
| 12 | TABLE ACCESS FULL | TABLE_STATE_PROV | 2503 | 50060 | 10 (0)| 00:00:01 |
| 13 | NESTED LOOPS | | 8949 | 1992K| 14930 (1)| 00:03:00 |
| 14 | NESTED LOOPS | | 9024 | 1639K| 7705 (1)| 00:01:33 |
|* 15 | HASH JOIN | | 9024 | 1083K| 480 (2)| 00:00:06 |
|* 16 | TABLE ACCESS FULL | TABLE_USER | 9033 | 90330 | 135 (1)| 00:00:02 |
|* 17 | HASH JOIN | | 9025 | 995K| 345 (3)| 00:00:05 |
| 18 | INDEX FULL SCAN | PRIVCLASS_OBJINDEX | 62 | 434 | 1 (0)| 00:00:01 |
|* 19 | HASH JOIN | | 9025 | 934K| 343 (2)| 00:00:05 |
|* 20 | TABLE ACCESS FULL | TABLE_USER | 9033 | 149K| 136 (2)| 00:00:02 |
|* 21 | HASH JOIN RIGHT OUTER | | 9025 | 784K| 207 (2)| 00:00:03 |
| 22 | TABLE ACCESS FULL | TABLE_X_GSA_PENALTY_MAP | 50 | 750 | 2 (0)| 00:00:01 |
|* 23 | TABLE ACCESS FULL | TABLE_EMPLOYEE | 9025 | 652K| 204 (2)| 00:00:03 |
| 24 | TABLE ACCESS BY INDEX ROWID| TABLE_SITE | 1 | 63 | 1 (0)| 00:00:01 |
|* 25 | INDEX UNIQUE SCAN | SITE_OBJINDEX | 1 | | 1 (0)| 00:00:01 |
| 26 | TABLE ACCESS BY INDEX ROWID | TABLE_ADDRESS | 1 | 42 | 1 (0)| 00:00:01 |
|* 27 | INDEX UNIQUE SCAN | ADDRESS_OBJINDEX | 1 | | 1 (0)| 00:00:01 |
| 28 | TABLE ACCESS BY INDEX ROWID | TABLE_SITE | 1 | 63 | 1 (0)| 00:00:01 |
|* 29 | INDEX UNIQUE SCAN | SITE_OBJINDEX | 1 | | 1 (0)| 00:00:01 |
| 30 | TABLE ACCESS BY INDEX ROWID | TABLE_ADDRESS | 1 | 17 | 1 (0)| 00:00:01 |
|* 31 | INDEX UNIQUE SCAN | ADDRESS_OBJINDEX | 1 | | 1 (0)| 00:00:01 |
| 32 | TABLE ACCESS BY INDEX ROWID | TABLE_SITE | 1 | 14 | 1 (0)| 00:00:01 |
|* 33 | INDEX UNIQUE SCAN | SITE_OBJINDEX | 1 | | 1 (0)| 00:00:01 |
| 34 | TABLE ACCESS BY INDEX ROWID | TABLE_ADDRESS | 1 | 21 | 1 (0)| 00:00:01 |
|* 35 | INDEX UNIQUE SCAN | ADDRESS_OBJINDEX | 1 | | 1 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - access("TZ"."OBJID"="DST"."DAYLIGHT_HR2TIME_ZONE"(+))
2 - filter("DST"."START_TIME"(+)<=:1 AND "DST"."END_TIME"(+)>=:2)
3 - access("ADDR"."ADDRESS2TIME_ZONE"="TZ"."OBJID")
5 - access("ADDR"."ADDRESS2COUNTRY"="COUNTRY"."OBJID")
11 - access("REPSTATEPROV"."OBJID"="REPADDR"."ADDRESS2STATE_PROV")
15 - access("USR"."OBJID"="USR"."OBJID")
16 - filter("USR"."STATUS"=1)
17 - access("USR"."USER_ACCESS2PRIVCLASS"="PRIVCLASS"."OBJID")
19 - access("EMP"."EMPLOYEE2USER"="USR"."OBJID")
20 - filter("USR"."STATUS"=1)
21 - access("EMP"."X_OT_DEF2X_PENALTY_MAP"="PENALTY"."OBJID"(+))
23 - filter("EMP"."FIELD_ENG"=1)
25 - access("REPSITE"."OBJID"="EMP"."SUPP_PERSON_OFF2SITE")
27 - access("REPADDR"."OBJID"="REPSITE"."CUST_PRIMADDR2ADDRESS")
29 - access("PHYSSITE"."OBJID"="EMP"."EMP_PHYSICAL_SITE2SITE")
31 - access("PHYSADDR"."OBJID"="PHYSSITE"."CUST_PRIMADDR2ADDRESS")
33 - access("PHYSSITE"."OBJID"="PHYSSITE"."OBJID")
35 - access("PHYSSITE"."CUST_PRIMADDR2ADDRESS"="ADDR"."OBJID")




-- hot to identify the columns where index is required to avoid the full table scan

In future please format code - by Moderator

[Updated on: Mon, 03 May 2010 08:24] by Moderator

Report message to a moderator

Re: Tune sql query [message #454034 is a reply to message #454016] Mon, 03 May 2010 12:44 Go to previous messageGo to next message
Its_me_ved
Messages: 979
Registered: October 2009
Location: India
Senior Member
Quote:

how to identify the columns where index is required to avoid the full table scan


You really need to ANALYZE your tables and use the CBO to its fullest.Please go through the performance tuning sticky.

What is the output of the below two sqls


select count(*) from table_user;
select count(*) from table_user usr where usr.status=1;



What are the index created on table table_user;


What are the tables being used in view ora_emp_loc_view?

Remember : "Full scans are not always evil, indexes are not always good"

Regards,
Ved

[Updated on: Mon, 03 May 2010 12:45]

Report message to a moderator

Re: Tune sql query [message #454049 is a reply to message #454016] Mon, 03 May 2010 17:12 Go to previous messageGo to next message
cookiemonster
Messages: 13922
Registered: September 2008
Location: Rainy Manchester
Senior Member
Why have you got table_daylight_hr outer-joined when it's the only table that's restricted by user input?
Re: Tune sql query [message #454164 is a reply to message #454016] Tue, 04 May 2010 05:44 Go to previous messageGo to next message
lalitm_2003
Messages: 86
Registered: May 2005
Location: delhi
Member
Hi,
May be you can take the filters inside inline views.
That might help to reduce the data fetched after usr and dst.
Don't forget the stats should be ok and indexes should be good.

Regards
Lalit
Re: Tune sql query [message #454334 is a reply to message #454164] Wed, 05 May 2010 01:54 Go to previous messageGo to next message
rleishman
Messages: 3728
Registered: October 2005
Location: Melbourne, Australia
Senior Member
As @cookiemonster points out with the outer-joins, you are really joining every row of every table - unfiltered - then rejecting some of the joined rows.

If this is what you want, then you need an execution plan with HASH JOINS and FULL TABLE SCANS instead of INDEXED NESTED LOOP joins.

Accurate statistics on your tables would probably do the trick, otherwise you may need to resort to Optimizer Hints such as ORDERED and USE_HASH.

Ross Leishman
Re: Tune sql query [message #455999 is a reply to message #454334] Fri, 14 May 2010 00:45 Go to previous message
nitinkrmishra
Messages: 4
Registered: May 2010
Junior Member
Use Leading Hint in your query.
Previous Topic: Function based index
Next Topic: Sql Trace and tkprof
Goto Forum:
  


Current Time: Sun May 12 12:57:33 CDT 2024