v$sql vs. v$sqlarea, v$sql_shared_cursor and Cursor Sharing

V$SQL vs. V$SQLAREA
Each SQL statement has 1 parent cursor, 1 or more child cursors.

V$SQLAREA: parent cursor, it contains one row for each parent cursor.

V$SQL: each parent cursor can have one or more child cursors.

-- Compared to parent cursor, child cursors have heap 6 (execution plan).

-- Each parent requires at lest 1 child cursor.

-- Multiple parent cursors are created because of differences in sql statement text.
The following statements all require separate parent cursors:
1 SELECT COUNT(*) FROM tab1;
2 select count(*) from TAB1;
3 SELECT /*comment*/ COUNT(*) FROM tab1;
4 SELECT COUNT(*) FROM tab1;


Cursor Sharing: EXACT, FORCE and SIMILAR
-- If the dynamic initialization parameter cursor_sharing is set to "EXACT", this cursor sharing feature is disabled.  If it's set to "FORCE" or "SIMILAR", the feature is enabled.


-- This parameter can be set at session or system level.


-- You can explicitly disable cursor sharing at the SQL statement level by specifying the hint "cursor_sharing_exact".


--Use "SELECT address, child_address, sql_text FROM v$sql WHERE sql_text LIKE '.....%' to check if two sql statements are the same: use same parent and child cursor. 
--The following two similar sql statements will have different results when running the above query to check parent and child cursors, when the cursor sharing paramenter is set to different values: EXACT and FORCE.
select col1 from tab1 where col1=0;
select col1 from tab1 where col1=1;


cursor_sharing=exact: 1 parent cursor with 2 child cursors


cursor_sharing=force:  1 parent cursor with 1 child cursor.  That means Oracle treats the above two sql statements as the same statement. 


cursor_sharing=similar:
The histogram factor on the column statistics will have different impacts on the parent and child cursors. 
Without histogram, Oracle will treat the following 4 sql statements as one statement: 1 parent cursor vs. 1 child cursor:
select col1 from tab1 where col1=0;

select col1 from tab1 where col1=1;

select col1 from tab1 where col1=2;

select col1 from tab1 where col1=3;
****************************************************************
cursor_sharing=force
Problems: a single child cursor is used for all SQL statements sharing the same text after the replacement of the literals.
"Consequently, the literals are peeked only during the generation of the execution plan related to the first submitted SQL statement. Naturally, this could lead to suboptimal execution plans because literals used in subsequent SQL statements will lead to different execution plans" - Christian Antognini's book (Troubleshooting Oracle Performance).
****************************************************************

========================================================================
According to Christian Antognini's book (Troubleshooting Oracle Performance):
"if an application uses literals and cursor sharing is set to similar, the behavior depends on the existence of relevant histograms. If they do exists, similar behaves like exact.  If they don't exist, similar behaves like force.  This means that if you are facing parsing problems, more often than not, it is pointless to use similar."
=================================================================================


With histogram, the above 4 sql statements will have 2 parent cursors and 3 child cursors.  


V$SQL_SHARED_CURSOR
--describes each loaed child cursor
--contains set of boolean values describing why cursors could not be shared.
--boolean values for 1st child of each parent will always be false.


SQL> select address, child_address, sql_text from v$sql where sql_text like '.....%';
SQL> select child_number, child_address, optimizer_mode_mismatch from v$sql_shared_cursor where address='xxxxxx';