Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

CHAPTER 6 ■ LOCKING AND LATCHING 223
SQL, or unique SQL for each statement). To do this, we’ll use a very small Java program that
simply logs into Oracle, turns off auto-commit (as all Java programs should do immediately
after connecting to a database), and executes 25,000 unique INSERT statements in a loop. We’ll
perform two sets of tests: our program will not use bind variables in the first set, and in the
second set it will.
To evaluate these programs and their behavior in a multiuser environment, I opted to use
Statspack to gather the metrics, as follows:
1. Execute a Statspack snapshot to gather the current state of the system.
2. Run N copies of the program, having each program INSERT into its own database table
so as to avoid the contention associated with having all programs trying to insert into a
single table.
3. Take another snapshot immediately after the last copy of the program finishes.
Then it is a simple matter of printing out the Statspack report and finding out how long
it took N copies of the program to complete, how much CPU was used, what the major wait
events occurred, and so on.
These tests were performed on a dual-CPU machine with hyperthreading enabled (making
it appear as if there were four CPUs). Given that there were two physical CPUs, you might
expect very linear scaling here—that is, if one user uses 1 unit of CPU to process her inserts,
then you might expect that two users would require 2 units of CPU. You’ll discover that this
premise, while sounding plausible, may well be inaccurate (just how inaccurate depends on
your programming technique, as you’ll see). It would be correct if the processing we were performing
needed no shared resource, but our process will use a shared resource, namely the
Shared pool. We need to latch the Shared pool to parse SQL statements, and we need to latch
the Shared pool because it is a shared data structure, and we cannot modify it while others are
reading it and we cannot read it while it is being modified.
■Note I’ve performed these tests using Java, PL/SQL, Pro*C, and other languages. The end results are very
much the same every time. This demonstration and discussion applies to all languages and all interfaces to
the database. I chose Java for this example as I find Java and Visual Basic applications are most likely to not
use bind variables when working with the Oracle database.
Without Bind Variables
In the first instance, our program will not use bind variables, but rather will use string concatenation
to insert data:
import java.sql.*;
public class instest
{
static public void main(String args[]) throws Exception
{
DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
Connection