Literal Values
Another factor to consider when planning for cursor reuse is the use of literal values. Consider the following simple code snippet that performs two straightforward queries. Pay close attention to the fact that the text of each query differs only in the specified literal order number.
CREATE OR REPLACE PROCEDURE two_queries
AS
v_order_date DATE;
BEGIN
-- get order 100
SELECT order_date
INTO v_order_date
FROM orders
WHERE order_number = 100;
-- get order 200
SELECT order_date
INTO v_order_date
FROM orders
WHERE order_number = 200;
END;After an initial execution, the shared pool contains two cursors.
SQL_TEXT PARSE_CALLS EXECUTIONS
------------------------------ ----------- ----------
SELECT ORDER_DATE FROM ORDERS 1 1
WHERE ORDER_NUMBER = 100
SELECT ORDER_DATE FROM ORDERS 1 1
WHERE ORDER_NUMBER = 200Each cursor was parsed and executed once because the ASCII totals did not match up. In addition, their only chance of further reuse will be when order 100 or 200 is explicitly queried. That’s hardly optimal because, if there are tens of thousands of orders, there will be tens of thousands of hard parses to retrieve them.
Within PL/SQL, the easiest way to make these cursors available for reuse is to parameterize them as shown in this code:
CREATE OR REPLACE PROCEDURE two_queries AS -- define a parameterized cursor CURSOR get_date ( cp_order NUMBER ) IS SELECT order_date FROM orders WHERE order_number = cp_order; v_order_date DATE; BEGIN -- get order 100 OPEN get_date(100); ...