05.11.2015 Views

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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

CHAPTER 3 ■ FILES 99<br />

“accidentally” drop a table or remove some critical information <strong>and</strong> commit that operation,<br />

you can restore a backup <strong>and</strong> have <strong>Oracle</strong> restore it to the point immediately prior to the accident<br />

using these online <strong>and</strong> archive redo log files.<br />

Virtually every operation you perform in <strong>Oracle</strong> generates some amount of redo to be<br />

written to the online redo log files. When you insert a row into a table, the end result of that<br />

insert is written to the redo logs. When you delete a row, the fact that you deleted that row is<br />

written. When you drop a table, the effects of that drop are written to the redo log. The data<br />

from the table you dropped is not written; however, the recursive SQL that <strong>Oracle</strong> performs<br />

to drop the table does generate redo. For example, <strong>Oracle</strong> will delete a row from the SYS.OBJ$<br />

table (<strong>and</strong> other internal dictionary objects), <strong>and</strong> this will generate redo, <strong>and</strong> if various modes<br />

of supplemental logging are enabled, the actual DROP TABLE statement will be written into the<br />

redo log stream.<br />

Some operations may be performed in a mode that generates as little redo as possible.<br />

For example, I can create an index with the NOLOGGING attribute. This means that the initial<br />

creation of the index data will not be logged, but any recursive SQL <strong>Oracle</strong> performed on my<br />

behalf will be. For example, the insert of a row into SYS.OBJ$ representing the existence of the<br />

index will be logged, as will all subsequent modifications of the index using SQL inserts,<br />

updates, <strong>and</strong> deletes. But the initial writing of the index structure to disk will not be logged.<br />

I’ve referred to two types of redo log file: online <strong>and</strong> archived. We’ll take a look at each in<br />

the sections that follow. In Chapter 9, we’ll take another look at redo in conjunction with rollback<br />

segments, to see what impact they have on you as the developer. For now, we’ll just<br />

concentrate on what they are <strong>and</strong> what their purpose is.<br />

Online Redo Log<br />

Every <strong>Oracle</strong> database has at least two online redo log file groups. Each redo log group consists<br />

of one or more redo log members (redo is managed in groups of members). The individual<br />

redo log file members of these groups are true mirror images of each other. These online redo<br />

log files are fixed in size <strong>and</strong> are used in a circular fashion. <strong>Oracle</strong> will write to log file group 1,<br />

<strong>and</strong> when it gets to the end of this set of files, it will switch to log file group 2 <strong>and</strong> rewrite the<br />

contents of those files from start to end. When it has filled log file group 2, it will switch back to<br />

log file group 1 (assuming we have only two redo log file groups; if we have three, it would, of<br />

course, proceed to the third group). This is shown in Figure 3-4.<br />

Figure 3-4. Log file groups

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

Saved successfully!

Ooh no, something went wrong!