So, we can have different execution plans and different plan hash value for the same sql_ids. So, if the execution plan changes the plan hash value will also change. From Oracle 11g we have Adaptive Cursor Sharing (ACS) which allows the server to compare the effectiveness of execution plans between executions with different bind variable values and if notices suboptimal plans, allows certain bind variable values, to use different execution plans for the same statement hence creating a new child cursor.
A cursor is marked bind sensitive if the optimizer believes the optimal plan may depend on the value of the bind variable. When a cursor is marked bind sensitive, Oracle monitors the behavior of the cursor using different bind values, to determine if a different plan for different bind values is called for. This cursor was marked bind sensitive because the histogram on the C2 column was used to compute the selectivity of the predicate “where C2 = :N1”. Since the presence of the histogram indicates that the column is skewed, different values of the bind variable may call for different plans.
V$SQL column has :
select * from employees;
SELECT * FROM EMPLOYEES;
Hints : BIND_AWARE and NO_BIND_AWARE
Here are some interesting links related to MUTEX and Library Cache PINs :
Andrey Nikolaev has written some excellent articles on Mutex :