05.11.2015 Views

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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

228<br />

CHAPTER 6 ■ LOCKING AND LATCHING<br />

■Note Due to rounding, the 4 CPU seconds is really anywhere from 3.5 to 4.49, <strong>and</strong> the 11 is really<br />

anywhere from 10.5 to 11.49 seconds.<br />

Further, the amount of CPU used by two users with bind variables is less than half the<br />

amount of CPU a single user not using bind variables required! When I went to look at the<br />

latch report in this Statspack report, I found it was missing in this report—there was so little<br />

contention for the Shared pool <strong>and</strong> library cache that it was not even reported. In fact, digging<br />

deeper turned up the fact that the Shared pool latch was requested 50,367 times versus well<br />

over 1,000,000 times in the two-user test just shown.<br />

Performance/Scalability Comparison<br />

Table 6-1 summarizes the CPU used by each implementation, as well as the latching results as<br />

we increase the number of users beyond two. As you can see, the solution using fewer latches<br />

will scale much better as the user load goes up.<br />

Table 6-1. CPU Usage Comparison With <strong>and</strong> Without Bind Variables<br />

Waits for Latches<br />

CPU Seconds/Elapsed Shared Pool Latch (Number of Waits/Time<br />

Users Time in Minutes Requests in Wait in Seconds)<br />

No Binds Binds No Binds Binds No Binds Binds<br />

1 26/0.52 4/0.10 563,883 25,232 0/0<br />

2 74/0.78 11/0.20 1,126,006 50,367 406/1<br />

3 155/1.13 29/0.37 1,712,280 75,541 2,830/4<br />

4 272/1.50 44/0.45 2,298,179 100,682 9,400/5<br />

5 370/2.03 64/0.62 2,920,219 125,933 13,800/20<br />

6 466/2.58 74/0.72 3,526,704 150,957 30,800/80 17/0<br />

7 564/3.15 95/0.92 4,172,492 176,085 40,800/154<br />

8 664/3.57 106/1.00 4,734,793 201,351 56,300/240 120/1<br />

9 747/4.05 117/1.15 5,360,188 230,516 74,600/374 230/1<br />

10 822/4.42 137/1.30 5,901,981 251,434 60,000/450 354/1<br />

The interesting observation for me is that 10 users using bind variables (<strong>and</strong> very few<br />

latch requests as a result) use the same amount of hardware resources as 2 to 2.5 users that do<br />

not use bind variables (i.e., that overuse a latch, or process more than they need to). When<br />

you examine the results for 10 users, you see that nonuse of bind variables results in the use<br />

of 6 times the CPU <strong>and</strong> takes 3.4 times the execution time when compared to the bind variable<br />

solution. The more users are added over time, the longer each user spends waiting for<br />

these latches. We went from an average of 4 seconds/session of wait time for latches with<br />

5 users to an average of 45 seconds/session of wait time with 10 users. However, the implementation<br />

that avoided overuse of the latch suffered no ill effects as it scaled up.

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

Saved successfully!

Ooh no, something went wrong!