Oracle stores the parsed, compiled SQL along with other content in the shared pool, which is a very important shared memory structure in the System Global Area (SGA).
A bind variable is a placeholder in a query.
For example, to get the corresponding record for employee number 7369, you can use:
scott@ORCL>select * from emp where empno=7369;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
---------- ---------- --------- ---------- -------------- ---------- ---------- ----------
7369 SMITH CLERK 7902 17-12月-80 800 20
Or you can set the bind variable: empno to 7369, and then execute the query:
scott@ORCL>variable empno number;
scott@ORCL>exec :empno := 7369;
PL/SQL procedure completed successfully.
scott@ORCL>select * from emp where empno=:empno;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
---------- ---------- --------- ---------- -------------- ---------- ---------- ----------
7369 SMITH CLERK 7902 17-12月-80 800 20
In a typical system, you might query employee 7369 only once, and then never query this employee again. After that, you might query employee 666, then employee 888, and so on. If you use literals (constants) in your queries, then every query will be a brand new query, never seen before in the database view, and the query must be parsed, qualified (name resolution), security checked, optimized Wait. Every different statement you execute is compiled at execution time.
The second query uses a bind variable: empno, whose value is provided at query execution time. This query is compiled only once, and the query plan is then stored in a shared pool (library cache) for later retrieval and reuse.
--------------------------------------------------------------------------------------------------------------------------------
The first procedure uses an sql statement with bind variables, as follows:
scott@ORCL>create or replace procedure proc1 2 as 3 begin 4 for i in 1 .. 10000 5 loop 6 execute immediate 7 'insert into t values(:x)' using i; 8 end loop; 9 end; 10 / Process has been created.
The second process is to construct a unique SQL statement for each inserted row, as follows:
scott@ORCL>create or replace procedure proc2
2 as
3 begin
4 for i in 1 .. 10000
5 loop
6 execute immediate
7 'insert into t values('|| i ||')';
8 end loop;
9 end;
10 /
Process has been created.
Compare the performance difference between the two:
scott@ORCL>exec runstats_pkg.rs_start PL/SQL procedure completed successfully. scott@ORCL>exec proc1 PL/SQL procedure completed successfully. scott@ORCL>exec runstats_pkg.rs_middle PL/SQL procedure completed successfully. scott@ORCL>exec proc2 PL/SQL procedure completed successfully. scott@ORCL>exec runstats_pkg.rs_stop(1000) #Print the comparison results with a gap greater than 1000 Run1 ran in 25 cpu hsecs Run2 ran in 396 cpu hsecs run 1 ran in 6.31% of the time Name Run1 Run2 Diff LATCH.object queue header oper 2,569 280 -2,289 STAT...sql area evicted 0 7,506 7,506 STAT...session cursor cache hi 10,010 63 -9,947 STAT...calls to kcmgcs 51 10,048 9,997 STAT...enqueue requests 30 10,029 9,999 STAT...enqueue releases 28 10,029 10,001 STAT...parse count (hard) 4 10,011 10,007 STAT...parse count (total) 26 10,057 10,031 STAT...consistent gets from ca 51 10,126 10,075 STAT...consistent gets 96 10,318 10,222 STAT...consistent gets from ca 96 10,318 10,222 STAT...file io wait time 19,052 0 -19,052 LATCH.enqueue hash chains 853 20,669 19,816 LATCH.enqueues 759 20,626 19,867 STAT...db block gets 10,421 30,373 19,952 STAT...db block gets from cach 10,421 30,373 19,952 STAT...db block gets from cach 61 20,042 19,981 STAT...session logical reads 10,517 40,691 30,174 STAT...recursive calls 10,328 41,019 30,691 STAT...session uga memory max 123,512 72,952 -50,560 LATCH.kks stats 9 50,688 50,679 LATCH.cache buffers chains 57,017 113,844 56,827 STAT...session uga memory 65,488 130,976 65,488 STAT...session pga memory max 131,072 65,536 -65,536 STAT...session pga memory 65,536 131,072 65,536 LATCH.shared pool simulator 27 77,205 77,178 STAT...physical read total byt 81,920 0 -81,920 STAT...cell physical IO interc 81,920 0 -81,920 STAT...physical read bytes 81,920 0 -81,920 LATCH.row cache objects 809 182,273 181,464 LATCH.shared pool 20,393 455,102 434,709 Run1 latches total versus runs -- difference and pct Run1 Run2 Diff Pct 86,743 925,525 838,782 9.37% PL/SQL procedure completed successfully.The results clearly show that, from the wall clock, proc2 (without using bind variables) takes significantly more time to insert 10,000 rows of records than proc1 (using bind variables). In fact, proc2 takes more than 15 times as long as proc1, which means that, in this case, for each "no bind variable" insert, 14/15 of the time it takes to execute the statement is just parsing!
It can be seen that if binding variables are used, there are only 4 resolutions; without binding variables, there are no less than 10,000 hard resolutions (each insertion will bring a hard resolution).