Database Reference
In-Depth Information
It can be said that developers do not need to understand the details of redo and undo as much as DBAs, but
developers do need to know the role they play in the database. It's vital to understand how redo and undo are related
to a COMMIT or ROLLBACK statement. It's also important to understand that generating redo and undo consumes
database resources and it's essential to be able to measure and manage that resource consumption.
Summary
In the following chapters, we'll discover that different databases have different ways of doing things (what works well
in SQL Server may not work as well in Oracle). We'll also see that understanding how Oracle implements locking,
concurrency control, and transactions is absolutely vital to the success of your application. This topic first discusses
Oracle's basic approach to these issues, the types of locks that can be applied (DML, DDL, and latches), and the
problems that can arise if locking is not implemented carefully (deadlocking, blocking, and escalation).
We'll also explore my favorite Oracle feature, multiversioning, and how it affects concurrency controls and
the very design of an application. Here we will see that all databases are not created equal and that their very
implementation can have an impact on the design of our applications. We'll start by reviewing the various transaction
isolation levels as defined by the ANSI SQL standard and see how they map to the Oracle implementation (as well
as how the other databases map to this standard). Then we'll take a look at what implications multiversioning, the
feature that allows Oracle to provide nonblocking reads in the database, might have for us.
This topic also examines how transactions should be used in Oracle and exposes some bad habits that may have
been picked up when developing with other databases. In particular, we look at the implications of atomicity and how
it affects statements in Oracle. We also discuss transaction control statements ( COMMIT , SAVEPOINT , and ROLLBACK ),
integrity constraints, distributed transactions (the two-phase commit, or 2PC), and finally, autonomous transactions.
The last few chapters of this topic delve into redo and undo. After first defining redo, we examine what exactly
a COMMIT does. We discuss how to find out how much redo is being generated and how to significantly reduce the
amount of redo generated for certain operations using the NOLOGGING clause. We also investigate redo generation in
relation to issues such as block cleanout and log contention. In the undo section of the chapter, we examine the role
of undo data and the operations that generate the most/least undo. Finally, we investigate the infamous ORA-01555:
snapshot too old error, its possible causes, and how to avoid it.
 
Search WWH ::




Custom Search