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.

CHAPTER 9 ■ REDO AND UNDO 327<br />

• Each transaction generates 8KB of undo on average.<br />

• You do five of these transactions per second on average (40KB of undo per second,<br />

2,400KB per minute).<br />

• You have a transaction that generates 1MB of undo that occurs once per minute on<br />

average. In total, you generate about 3.5MB of undo per minute.<br />

• You have 15MB of undo configured for the system.<br />

That is more than sufficient undo for this database when processing transactions. The<br />

undo segments will wrap around <strong>and</strong> reuse space about every three to four minutes or so, on<br />

average. If you were to size undo segments based on your transactions that do modifications,<br />

you did all right.<br />

In this same environment, however, you have some reporting needs. Some of these<br />

queries take a really long time to run—five minutes, perhaps. Here is where the problem<br />

comes in. If these queries take five minutes to execute <strong>and</strong> they need a view of the data as it<br />

existed when the query began, you have a very good probability of the ORA-01555 error occurring.<br />

Since your undo segments will wrap during this query execution, you know that some<br />

undo information generated since your query began is gone—it has been overwritten. If you<br />

hit a block that was modified near the time you started your query, the undo information for<br />

this block will be missing, <strong>and</strong> you will receive the ORA-01555 error.<br />

Here is a small example. Let’s say we have a table with blocks 1, 2, 3, . . . 1,000,000 in it.<br />

Table 9-4 shows a sequence of events that could occur.<br />

Table 9-4. Long-Running Query Timeline<br />

Time<br />

(Minutes:Seconds) Action<br />

0:00 Our query begins.<br />

0:01 Another session UPDATEs block 1,000,000. Undo information for this is<br />

recorded into some undo segment.<br />

0:01 This UPDATE session COMMITs. The undo data it generated is still there, but<br />

is now subject to being overwritten if we need the space.<br />

1:00 Our query is still chugging along. It is at block 200,000.<br />

1:01 Lots of activity going on. We have generated a little over 14MB of undo<br />

by now.<br />

3:00 Our query is still going strong. We are at block 600,000 or so by now.<br />

4:00 Our undo segments start to wrap around <strong>and</strong> reuse the space that was<br />

active when our query began at time 0:00. Specifically, we have just reused<br />

the undo segment space that the UPDATE to block 1,000,000 used back at<br />

time 0:01.<br />

5:00 Our query finally gets to block 1,000,000. It finds it has been modified<br />

since the query began. It goes to the undo segment <strong>and</strong> attempts to find<br />

the undo for that block to get a consistent read on it. At this point, it discovers<br />

the information it needs no longer exists. ORA-01555 is raised <strong>and</strong><br />

the query fails.

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

Saved successfully!

Ooh no, something went wrong!