Ask DB Specialists: Bind Variable Peeking,Misses in library cache during parse
The Specialist
Database News You Can Use
A monthly newsletter for Oracle users
November 2003
From Database Specialists
Expert onsite and remote DBA services
for your Oracle databases
Tel: 415-344-0500 • Toll-Free: 1-888-648-0500
Ask DB Specialists: Bind Variable Peeking
You're invited to submit your Oracle-related questions to us at [email protected]. Include your name, telephone number and problem description. If your question gets published, you'll receive a free copy of our reference poster on Oracle Wait Events. Peter Koletzke's Oracle Stuff
This month's question comes from Tracy F. in Boston, MA: What is "bind variable peeking" and can we now abandon literals when querying data with a skewed distribution?
Ian Jones of the Database Specialists team responds: To answer this question we need a little background. Generally in OLTP systems, i.e. systems characterized by lots of short duration SQL statements, we want to use bind variables so as to minimize hard parses and maximize SQL reuse in the shared pool. Unfortunately, prior to Oracle 9i there was an important exception to this general rule. The exception occurred when we needed to search a column that contained relatively few heavily skewed data values. After indexing such a column and collecting optimizer statistics, Oracle was able to choose different execution plans when searching for different column values, based on their relative occurrence. Let us illustrate this:
CREATE TABLE Check_Status
(
Check_No INTEGER NOT NULL,
Status VARCHAR2(10) NOT NULL
);
CREATE INDEX Skewed_Status ON Check_Status (Status);
BEGIN
FOR l_check_no IN 1..10000 LOOP
-- Lets cancel 1 in 100 checks
IF MOD (l_check_no, 100) = 0 THEN
INSERT INTO Check_Status (Check_No, Status)
VALUES (l_check_no, 'Cancelled');
ELSE
INSERT INTO Check_Status (Check_No, Status)
VALUES (l_check_no, 'Processed');
END IF;
END LOOP;
END;
ANALYZE TABLE Check_Status COMPUTE STATISTICS;
ANALYZE TABLE Check_Status COMPUTE STATISTICS FOR COLUMNS Status;
SELECT Status, COUNT(*) FROM Check_Status GROUP BY Status;
STATUS COUNT(*)
----------- --------
Cancelled 100
Processed 9900
The optimizer now has enough data available to choose the optimal execution plan:
SELECT * FROM Check_Status WHERE Status = 'Cancelled';
Operation Rows Bytes Cost
SELECT STATEMENT Optimizer Mode=CHOOSE 100 1200 2
TABLE ACCESS BY INDEX ROWID CHECK_STATUS 100 1200 2
INDEX RANGE SCAN SKEWED_STATUS 100 1
SELECT * FROM Check_Status WHERE Status = 'Processed';
Operation Rows Bytes Cost
SELECT STATEMENT Optimizer Mode=CHOOSE 9900 118800 6
TABLE ACCESS FULL CHECK_STATUS 9900 118800 6
As the above plans show, the optimizer is clever enough to use the index range scan when we are looking for 'Cancelled' checks and the full table scan when looking for 'Processed' checks. This existing functionality handles skewed data well when literals are used but does not fare so well when bind variables are used instead of literals.
Oracle 9i introduced a new feature known as "bind variable peeking." This allows the optimizer to look inside a bind variable when a statement is hard parsed (i.e. initially when it is loaded into the shared pool). Unfortunately, this feature does not allow us to eliminate the literals from the above code. In fact, doing so would be a bad idea because we would lose one of our executions plans. To illustrate this we use the following commands in an Oracle 9i environment to query the table using a bind variable set to 'Cancelled' and then look at the tkprof output.
VARIABLE l_status VARCHAR2(20);
EXECUTE :l_status := 'Cancelled';
SELECT * FROM Check_Status WHERE Status = :l_status;
call count cpu elapsed disk query current rows
------- ------ -------- ---------- -------- -------- -------- --------
Parse 1 0.36 0.36 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 8 0.00 0.04 29 40 0 100
------- ------ -------- ---------- -------- -------- -------- --------
total 10 0.36 0.40 29 40 0 100
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 57
Rows Row Source Operation
------- ---------------------------------------------------
100 TABLE ACCESS BY INDEX ROWID OBJ#(32937)
100 INDEX RANGE SCAN OBJ#(32939)
Looking at the above output, we see that this statement was hard parsed (misses in library cache during parse is 1) and Oracle correctly performed the index range scan based on the value of the bind variable 'Cancelled'. However if we now query for the 'Processed' checks, tkprof shows us the following:
EXECUTE :l_status := 'Processed'; SELECT * FROM Check_Status WHERE Status = :l_status; call count cpu elapsed disk query current rows ------- ------ -------- ---------- -------- -------- -------- -------- Parse 1 0.00 0.00 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 661 0.06 0.26 27 1375 0 9900 ------- ------ -------- ---------- -------- -------- -------- -------- total 663 0.06 0.26 27 1375 0 9900 Misses in library cache during parse: 0 Optimizer goal: CHOOSE Parsing user id: 57 Rows Row Source Operation ------- --------------------------------------------------- 9900 TABLE ACCESS BY INDEX ROWID OBJ#(32937) 9900 INDEX RANGE SCAN OBJ#(32939)
Looking at the above output, we see that this statement was soft parsed (misses in library cache during parse is 0) and Oracle reused the previous execution plan which is definitely sub-optimal in this case. A full table scan would have been better here, as we saw when literals were used.
In summary, bind variable peeking in Oracle 9i does not help us when we need different execution plans for different values of a bind variable. Bind variable peeking allows the optimizer to take the value of a bind variable into account when first generating an execution plan for a SQL statement. If we know that the data distribution is heavily skewed and that future executions of the SQL statement may involve different data distributions for the bind variable value, we must still resort to using literals to get the best performance.
Well-known author Peter Koletzke's website contains information, utilities, and links related to Oracle database design and development. Koletzke is the author of Oracle9i JDeveloper Handbook, Oracle Developer Advanced Forms & Reports, and The Oracle Designer Handbook. On the site, you'll find lots of resources including conference papers, tips and techniques, and plenty of useful links. Check it out at http://ourworld.compuserve.com/homepages/Peter_Koletzke. Stewart's Oracle Links, Tips, and Tricks
Oracle DBA Stewart McGlaughlin has spent a lot of time developing a handy website with lots of resource links. You'll find sections on data warehousing, products, utilities, scripts, listservers/forums, and free magazines. It's all at http://www.stewartmc.com/oracle. OraSnap, a Free Performance Utility
You might also want to check out the scripts he has posted in his Tips section at http://www.stewartmc.com/oracle/tips.html. Here's a quick sampling:
- Create primary keys in parallel
- Using the Export and Import utilities with a named pipe and compress
- Decreasing the size of a column which contains data
- Long deletes (committing every x number of records)
- Identifying and removing duplicate records
Also created by Stewart McGlaughlin is OraSnap, a free performance utility. OraSnap is a collection of scripts that run against an Oracle database to display performance information. The scripts are compatible with Oracle from 7.3 on up to 9i, and the information they provide can help you tune and optimize your databases. The scripts are not too different from the typical scripts that experienced Oracle DBAs are already familiar with, but what makes OraSnap different is that the script output is presented in HTML that you view with a web browser.
Each report includes a "Notes" section that presents extra information about the statistics gathered by the script, and also the source code that created the report output.
You'll find out more information on OraSnap at http://www.stewartmc.com/oracle/orasnap/index.html.