Why optimizer prefers nested loop over hash join?

Question

What do I look for if I want to find out why the server prefers a nested loop over hash join?
The server is 10.2.0.4.0.
The query is:
SELECT p.*
    FROM t1 p, t2 d
    WHERE d.emplid = p.id_psoft
      AND p.flag_processed = 'N'
      AND p.desc_pool = :b1
      AND NOT d.name LIKE '%DUPLICATE%'
      AND ROWNUM < 2tkprof output is:
Production
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.00          0          0          4           0
Execute      1      0.00       0.01          0          4          0           0
Fetch        1    228.83     223.48          0    4264533          0           1
total        3    228.84     223.50          0    4264537          4           1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 108  (SANJEEV)
Rows     Row Source Operation
      1  COUNT STOPKEY (cr=4264533 pr=0 pw=0 time=223484076 us)
      1   NESTED LOOPS  (cr=4264533 pr=0 pw=0 time=223484031 us)
  10401    TABLE ACCESS FULL T1 (cr=192 pr=0 pw=0 time=228969 us)
      1    TABLE ACCESS FULL T2 (cr=4264341 pr=0 pw=0 time=223182508 us)Development
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.00          0          0          0           0
Execute      1      0.00       0.01          0          4          0           0
Fetch        1      0.05       0.03          0        512          0           1
total        3      0.06       0.06          0        516          0           1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 113  (SANJEEV)
Rows     Row Source Operation
      1  COUNT STOPKEY (cr=512 pr=0 pw=0 time=38876 us)
      1   HASH JOIN  (cr=512 pr=0 pw=0 time=38846 us)
     51    TABLE ACCESS FULL T2 (cr=492 pr=0 pw=0 time=30230 us)
    861    TABLE ACCESS FULL T1 (cr=20 pr=0 pw=0 time=2746 us)

Answer 1

sanjeevchauhan wrote:
What do I look for if I want to find out why the server prefers a nested loop over hash join?
The server is 10.2.0.4.0.
The query is:
SELECT p.*
FROM t1 p, t2 d
WHERE d.emplid = p.id_psoft
AND p.flag_processed = 'N'
AND p.desc_pool = :b1
AND NOT d.name LIKE '%DUPLICATE%'
AND ROWNUM < 2
You've got already some suggestions, but the most straightforward way is to run the unhinted statement in both environments and then force the join and access methods you would like to see using hints, in your case probably "USE_HASH(P D)" in your production environment and "FULL(P) FULL(D) USE_NL(P D)" in your development environment should be sufficient to see the costs and estimates returned by the optimizer when using the alternate access and join patterns.
This give you a first indication why the optimizer thinks that the chosen access path seems to be cheaper than the obviously less efficient plan selected in production.
As already mentioned by Hemant using bind variables complicates things a bit since EXPLAIN PLAN is not reliable due to bind variable peeking performed when executing the statement, but not when explaining.
Since you're already on 10g you can get the actual execution plan used for all four variants using DBMS_XPLAN.DISPLAY_CURSOR which tells you more than the TKPROF output in the "Row Source Operation" section regarding the estimates and costs assigned.
Of course the result of your whole exercise might be highly dependent on the actual bind variable value used.
By the way, your statement is questionable in principle since you're querying for the first row of an indeterministic result set. It's not deterministic since you've defined no particular order so depending on the way Oracle executes the statement and the physical storage of your data this query might return different results on different runs.
This is either an indication of a bad design (If the query is supposed to return exactly one row then you don't need the ROWNUM restriction) or an incorrect attempt of a Top 1 query which requires you to specify somehow an order, either by adding a ORDER BY to the statement and wrapping it into an inline view, or e.g. using some analytic functions that allow you specify a RANK by a defined ORDER.
This is an example of how a deterministic Top N query could look like:
SELECT
FROM
SELECT p.*
    FROM t1 p, t2 d
    WHERE d.emplid = p.id_psoft
      AND p.flag_processed = 'N'
      AND p.desc_pool = :b1
      AND NOT d.name LIKE '%DUPLICATE%'
ORDER BY <order_criteria>
WHERE ROWNUM <= 1;Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/