11.07.2015 Views

Oracle Database 11 g - Online Public Access Catalog

Oracle Database 11 g - Online Public Access Catalog

Oracle Database 11 g - Online Public Access Catalog

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

CHAPTER 4 ■ PERFORMANCE MANAGEMENT 173■Note Adaptive cursor sharing is an automatic feature of <strong>Oracle</strong> <strong>Database</strong> <strong>11</strong>g, and you can’t turn it off.How Adaptive Cursor Sharing WorksThe key to adaptive cursor sharing is the bind sensitivity of a cursor and the concept of a bindawarecursor. A query is considered bind-sensitive if the optimizer performs bind peeking whenfiguring out the selectivity of the predicates and a change in bind variable values potentiallyleads to different execution plans. If a cursor in the cursor cache has been marked for bindawarecursor sharing, the cursor is called bind-aware.■Note Adaptive cursor sharing works independently from the setting of the cursor_sharing parameter.It doesn’t matter whether the user supplies the bindings or whether the literals are replaced by system-generatedbind variables, which is the case if you set the cursor_sharing parameter to force.Adaptive cursor sharing uses bind-aware cursor matching. Unlike in previous releases, thecursors can be bind-sensitive now. We’ll now show a simple example that illustrates how adaptivecursor sharing works in practice.Let’s say you have the following SQL query that the database executes multiple times:SQL> select * from hr.employees where salary = :1and department_id = :2;The previous SQL statement uses two bind variables, one for the salary column and theother for the department_id column.The first time the database executes the SQL statement, there is a hard parse. If the optimizerpeeks at the bind values and uses histograms to compute the selectivity of the predicatewith the two bind variables, the cursor is marked as a bind-sensitive cursor. The predicateselectivity information is stored in a cube, let’s say (0.15, 0.0025). Once the database executesthe query, it stores the execution statistics of the cursor in the cursor. Under adaptive cursorsharing, the database monitors the query execution of a new SQL statement for a while andgathers information to help decide whether it should switch to bind-aware cursor sharing forthe query.When the database executes a SQL statement the next time with a different pair of bindvalues, the database performs a soft parse as usual and compares the execution statistics tothose stored in the cursor. Based on all the previous execution statistics for this cursor, thedatabase makes a decision whether to mark this cursor as bind-aware.If the cursor is marked bind-aware, the database uses bind-aware cursor matching duringthe next soft parse of the query. Each time the database executes the query, it performs a cursorsharing check using the predicate’s bind variable selectivity estimates, which are stored in theselectivity cubes. Each plan has a selectivity range or cube associated with it. If the new bindvalues fall within this range, they will use the same plan. That is, if the selectivity of the predicatewith the new pair of bind values is within the existing cube or range of values, the databaseuses the same execution plan as that of the existing child cursor.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!