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.

240<br />

CHAPTER 7 ■ CONCURRENCY AND MULTI-VERSIONING<br />

Instead of results being consistent with respect to the start of a statement, they are preordained<br />

at the time you begin the transaction. In other words, <strong>Oracle</strong> uses the rollback segments<br />

to reconstruct the data as it existed when our transaction began, instead of just when our<br />

statement began.<br />

That’s a pretty deep thought there—the database already knows the answer to any question<br />

you might ask it, before you ask it.<br />

This degree of isolation comes with a price, <strong>and</strong> that price is the following possible error:<br />

ERROR at line 1:<br />

ORA-08177: can't serialize access for this transaction<br />

You will get this message whenever you attempt to update a row that has changed since<br />

your transaction began.<br />

■Note <strong>Oracle</strong> attempts to do this purely at the row level, but you may receive an ORA-01877 error even<br />

when the row you are interested in modifying has not been modified. The ORA-01877 error may happen due<br />

to some other row(s) being modified on the block that contains your row.<br />

<strong>Oracle</strong> takes an optimistic approach to serialization—it gambles on the fact that the data<br />

your transaction wants to update won’t be updated by any other transaction. This is typically<br />

the way it happens, <strong>and</strong> usually the gamble pays off, especially in quick-transaction, OLTPtype<br />

systems. If no one else updates your data during your transaction, this isolation level,<br />

which will generally decrease concurrency in other systems, will provide the same degree of<br />

concurrency as it would without SERIALIZABLE transactions. The downside to this is that you<br />

may get the ORA-08177 error if the gamble doesn’t pay off. If you think about it, however, it’s<br />

worth the risk. If you’re using a SERIALIZABLE transaction, you shouldn’t expect to update the<br />

same information as other transactions. If you do, you should use the SELECT ... FOR UPDATE<br />

as described previously in Chapter 1, <strong>and</strong> this will serialize the access. So, using an isolation<br />

level of SERIALIZABLE will be achievable <strong>and</strong> effective if you<br />

• Have a high probability of no one else modifying the same data<br />

• Need transaction-level read consistency<br />

• Will be doing short transactions (to help make the first bullet point a reality)<br />

<strong>Oracle</strong> finds this method scalable enough to run all of their TPC-Cs (an industry st<strong>and</strong>ard<br />

OLTP benchmark; see www.tpc.org for details). In many other implementations, you will find<br />

this being achieved with shared read locks <strong>and</strong> their corresponding deadlocks, <strong>and</strong> blocking.<br />

Here in <strong>Oracle</strong>, we do not get any blocking, but we will get the ORA-08177 error if other sessions<br />

change the data we want to change as well. However, we will not get the error as frequently as<br />

we will get deadlocks <strong>and</strong> blocks in the other systems.<br />

But—there is always a “but”—you must take care to underst<strong>and</strong> these different isolation<br />

levels <strong>and</strong> their implications. Remember, with isolation set to SERIALIZABLE, you will not see<br />

any changes made in the database after the start of your transaction, until you commit. Applications<br />

that attempt to enforce their own data integrity constraints, such as the resource<br />

scheduler described in Chapter 1, must take extra care in this regard. If you recall, the problem

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

Saved successfully!

Ooh no, something went wrong!