10g doing VIEW type join even when no view in SQL - and performing poorly

Question

Using 10.2.0.2.0
Every once in a while I see CBO deciding to use VIEW type join even when there is no view in the SQL and whenever it does that the performance just sucks.
Example –
SQL-
SELECT a.emplid, a.empl_rcd, TO_CHAR (((a.dur) + (:"SYS_B_00")), :"SYS_B_01"),
a.seqnum
FROM ps_wrk_adhoc_tao5 a, ps_tl_prof_wrk5 b, ps_tl_empl_data c
WHERE a.dur =
(SELECT MAX (a1.dur)
FROM ps_wrk_adhoc_tao5 a1
WHERE a1.process_instance = :"SYS_B_02"
AND a1.emplid = a.emplid
AND a1.empl_rcd = a.empl_rcd)
AND a.dur < TO_DATE (:"SYS_B_03", :"SYS_B_04")
AND NOT EXISTS (
SELECT :"SYS_B_05"
FROM ps_tl_ta_exceptn5 q
WHERE q.process_instance = :"SYS_B_06"
AND q.exception_id = :"SYS_B_07"
AND q.emplid = a.emplid
AND q.empl_rcd = a.empl_rcd
AND q.dur = a.dur)
AND :"SYS_B_08" = :"SYS_B_09"
AND c.emplid = a.emplid
AND b.emplid = a.emplid
AND c.empl_rcd = a.empl_rcd
AND b.empl_rcd = a.empl_rcd
AND c.effdt =
(SELECT MAX (c1.effdt)
FROM ps_tl_empl_data c1
WHERE c1.emplid = c.emplid
AND c1.empl_rcd = c.empl_rcd
AND c1.effdt <= ((a.dur) + (:"SYS_B_10")))
AND b.effdt =
(SELECT MAX (b1.effdt)
FROM ps_tl_prof_wrk5 b1
WHERE b1.process_instance = :"SYS_B_11"
AND b1.emplid = b.emplid
AND b1.empl_rcd = b.empl_rcd
AND b1.effdt <= ((a.dur) + (:"SYS_B_12")))
AND c.time_rptg_status = :"SYS_B_13"
AND b.empl_status IN (:"SYS_B_14", :"SYS_B_15", :"SYS_B_16", :"SYS_B_17")
AND a.process_instance = :"SYS_B_18"
AND b.process_instance = :"SYS_B_19"
Plan –
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
SELECT STATEMENT Optimizer Mode=CHOOSE 1 18
NESTED LOOPS ANTI 1 153 13
NESTED LOOPS 1 125 12
NESTED LOOPS 1 103 10
HASH JOIN 1 76 9
INDEX RANGE SCAN SYSADM.PS0WRK_ADHOC_TAO5 7 245 2
SORT AGGREGATE 1 21
TABLE ACCESS BY INDEX ROWID SYSADM.PS_WRK_ADHOC_TAO5 6 126 3
INDEX RANGE SCAN SYSADM.PS_WRK_ADHOC_TAO5 6 2
VIEW SYS.VW_SQ_1 524 20 K 6
HASH GROUP BY 524 40 K 6
FILTER
MERGE JOIN 1 K 124 K 5
SORT JOIN 151 5 K 2
INDEX RANGE SCAN SYSADM.PS_TL_PROF_WRK5 151 5 K 1
SORT JOIN 214 8 K 3
INDEX RANGE SCAN SYSADM.PS0WRK_ADHOC_TAO5 214 8 K 2
TABLE ACCESS BY INDEX ROWID SYSADM.PS_TL_PROF_WRK5 1 27 1
INDEX UNIQUE SCAN SYSADM.PS_TL_PROF_WRK5 1 0
TABLE ACCESS BY INDEX ROWID SYSADM.PS_TL_EMPL_DATA 1 22 2
INDEX RANGE SCAN SYSADM.PS_TL_EMPL_DATA 1 1
SORT AGGREGATE 1 20
FIRST ROW 1 20 2
INDEX RANGE SCAN (MIN/MAX) SYSADM.PS_TL_EMPL_DATA 1 20 2
INDEX RANGE SCAN SYSADM.PS_TL_TA_EXCEPTN5 1 28 1
If I use a rule hint here I get this plan. I get the plan given below on another database even without the rule hint –
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
SELECT STATEMENT Optimizer Mode=HINT: RULE
FILTER
FILTER
TABLE ACCESS BY INDEX ROWID SYSADM.PS_TL_EMPL_DATA
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID SYSADM.PS_TL_PROF_WRK5
INDEX RANGE SCAN SYSADM.PS_TL_PROF_WRK5
TABLE ACCESS BY INDEX ROWID SYSADM.PS_WRK_ADHOC_TAO5
INDEX RANGE SCAN SYSADM.PS_WRK_ADHOC_TAO5
INDEX RANGE SCAN SYSADM.PS_TL_EMPL_DATA
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID SYSADM.PS_WRK_ADHOC_TAO5
INDEX RANGE SCAN SYSADM.PS_WRK_ADHOC_TAO5
INDEX RANGE SCAN SYSADM.PS_TL_TA_EXCEPTN5
SORT AGGREGATE
INDEX RANGE SCAN SYSADM.PS_TL_EMPL_DATA
SORT AGGREGATE
INDEX RANGE SCAN SYSADM.PS_TL_PROF_WRK5
The whole schema was analyzed using dbms.stats only yesterday. My question is why is Oracle doing VIEW, and how can I stop it from doing that. Hint is not an option.

Answer 1

I understand that SQL Developer takes it's NLS settings from Preferences - Database - NLS Parameters. What I was not aware of is that when SQL Developer is run for the first time the NLS Parameters seem to be populated from the settings on the OS of the PC it is running on. To test that this was the case I did the following
I work on a Windows XP system with Regional Options - Standards and Formats and Regional Options - Location set with English (United Kingdom) and United Kingdom respectively.
I unzipped two clean SQL Developer instances (both Version 1.2.1). The first instance I first ran under my current PC set up without importing settings from a previous installation. The Preferences - Database - NLS Parameters - Language and Preferences - Database - NLS Parameters - Territory had been populated with English and United Kingdom.
I then changed the Regional Options on the OS to English (United States) and United States and ran the second instance of SQL Developer for the first time, again without importing settings. In this instance of SQL Developer the NLS Parameters were populated with American and America.
When the first instance of SQL Developer was the checked under these OS settings the NLS Parameters were still English and United Kingdom.
I was not aware this was the case and, if my test is correct, it seems to contradict the SQL Developer user guide http://download.oracle.com/docs/cd/E10405_01/doc/appdev.120/e10406/intro.htm#CHDBHCAG
James
Message was edited by: Jampat to include SQL Developer version number.