Generally when does optimizer use nested loop and Hash joins ?

Question

Version: 11.2.0.3, 10.2
Lets say I have a table called ORDER and ORDER_DETAIL.
ORDER_DETAIL is the child table of ORDERS .
This is what I understand about Nested Loop:
When we join ORDER AND ORDER_DETAIL tables oracle will form a 'nested loop' in which for each order_ID in ORDER table (outer loop), oracle will look for corresponding multiple ORDER_IDs in the ORDER_DETAIL table.
Is nested loop used when the driving table (ORDER in this case) is smaller than the child table (ORDER_DETAIL) ?
Is nested loop more likely to use Indexes in general ?
How will these two tables be joined using Hash joins ?
When is it ideal to use hash joins  ?

Answer 1

Your description of a nested loop is correct.
The overall rule is that Oracle will use the plan that it calculates to be, in general, fastest. That mostly means fewest I/O's, but there are various factors that adjust its calculation - e.g. it expects index blocks to be cached, multiple reads entries in an index may reference the same block, full scans get multiple blocks per I/O. It also has CPU cost calculations, but they generally only become significant with function / package calls or domain indexes (spatial, text, ...).
Nested loop with an index will require one indexed read of the child table per outer table row, so its I/O cost is roughly twice the number of rows expected to match the where clause conditions on the outer table.
A hash join reads the of the smaller table into a hash table then matches the rows from the larger table against the hash table, so its I/O cost is the cost of a full scan of each table (unless the smaller table is too big to fit in a single in-memory hash table). Hash joins generally don't use indexes - it doesn't use the index to look up each result. It can use an index as a data source, as a narrow version of the table or a way to identify the rows satisfying the other where clause conditions.
If you are processing the whole of both tables, Oracle is likely to use a hash join, and be very fast and efficient about it.
If your where clause restricts it to a just few rows from the parent table and a few corresponding rows from the child table, and you have an index Oracle is likely to use a nested loops solution.
If the tables are very small, either plan is efficient - you may be surprised by its choice.
Don't be worry about plans with full scans and hash joins - they are usually very fast and efficient. Often bad performance comes from having to do nested loop lookups for lots of rows.