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

CHAPTER 8 ■ TRANSACTIONS 281
scott@ORA10G> connect /
Connected.
ops$tkyte@ORA10G> set echo on
ops$tkyte@ORA10G> select * from audit_tab;
USERNAME TIMESTAMP MSG
--------- --------- ----------------------------------------
OPS$TKYTE 27-APR-05 Attempt to update 7369
SCOTT 27-APR-05 Attempt to update 7788
The attempt by SCOTT to perform that UPDATE has been recorded.
Summary
In this chapter, we looked at many aspects of transaction management in Oracle. Transactions
are one of the major features that set a database apart from a file system. Understanding how
they work and how to use them is necessary to implement applications correctly in any database.
Understanding that, in Oracle, all statements are atomic (including their side effects)
and that this atomicity is extended to stored procedures is crucial. We saw how the placement
of a WHEN OTHERS exception handler in a PL/SQL block could radically affect what changes took
place in the database. As database developers, having a good understanding of how transactions
work is crucial.
We took a look at the somewhat complex interaction between integrity constraints
(unique keys, check constraints, and the like) and transactions in Oracle. We discussed how
Oracle typically processes integrity constraints immediately after a statement executes, but
that we can defer this constraint validation until the end of the transaction if we wish. This
feature is key in implementing complex multitable updates when the tables being modified
are all dependent on each other—the cascading update was an example of that.
We moved on to consider some of the bad transaction habits that people tend to pick up
from working with databases that “support” rather than “promote” the use of transactions. We
looked at the cardinal rule of transactions: they should be as short as they can be but as long
as they need to be. Data integrity drives the transaction size—that is a key concept to take
away from this chapter. The only things that should drive the size of your transactions are the
business rules that govern your system. Not undo space, not locks—business rules.
We covered distributed transactions and how they differ from single database transactions.
We explored the limitations imposed upon us in a distributed transaction and discussed
why they are there. Before you build a distributed system, you need to understand these limitations.
What works in a single instance might not work in a distributed database.
The chapter closed with a look at autonomous transactions and covered what they are
and, more important, when they should and should not be used. I would like to emphasize
once again that the legitimate real-world use of autonomous transactions is exceedingly rare.
If you find them to be a feature you are using constantly, you’ll want to take a long, hard look
at why.