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

310
CHAPTER 9 ■ REDO AND UNDO
ops$tkyte@ORA10G> @mystat2
ops$tkyte@ORA10G> set echo off
NAME
V DIFF
---------- ---------- ----------------
redo size 11540676 81,168
This time, there is only 80KB of redo generated.
As you can see, this makes a tremendous difference—5.5MB of redo versus 80KB. The
5.5MB is the actual table data itself; it was written directly to disk, with no redo log generated
for it.
If you test this on a NOARCHIVELOG mode database, you will not see any differences. The
CREATE TABLE will not be logged, with the exception of the data dictionary modifications, in a
NOARCHIVELOG mode database. If you would like to see the difference on a NOARCHIVELOG mode
database, you can replace the DROP TABLE and CREATE TABLE with DROP INDEX and CREATE INDEX
on table T. These operations are logged by default, regardless of the mode in which the database
is running. This example also points out a valuable tip: test your system in the mode it
will be run in production, as the behavior may be different. Your production system will be
running in ARCHIVELOG mode; if you perform lots of operations that generate redo in this
mode, but not in NOARCHIVELOG mode, you’ll want to discover this during testing, not during
rollout to the users!
Of course, it is now obvious that you will do everything you can with NOLOGGING, right? In
fact, the answer is a resounding no. You must use this mode very carefully, and only after discussing
the issues with the person in charge of backup and recovery. Let’s say you create this
table and it is now part of your application (e.g., you used a CREATE TABLE AS SELECT NOLOGGING
as part of an upgrade script). Your users modify this table over the course of the day. That
night, the disk that the table is on fails. “No problem,” the DBA says. “We are running in
ARCHIVELOG mode, and we can perform media recovery.” The problem is, however, that the initially
created table, since it was not logged, is not recoverable from the archived redo log. This
table is unrecoverable and this brings out the most important point about NOLOGGING operations:
they must be coordinated with your DBA and the system as a whole. If you use them
and others are not aware of that fact, you may compromise the ability of your DBA to recover
your database fully after a media failure. They must be used judiciously and carefully.
The important things to note about NOLOGGING operations are as follows:
• Some amount of redo will be generated, as a matter of fact. This redo is to protect the
data dictionary. There is no avoiding this at all. It could be of a significantly lesser
amount than before, but there will be some.
• NOLOGGING does not prevent redo from being generated by all subsequent operations.
In the preceding example, I did not create a table that is never logged. Only the single,
individual operation of creating the table was not logged. All subsequent “normal”
operations such as INSERTs, UPDATEs, and DELETEs will be logged. Other special operations,
such as a direct path load using SQL*Loader, or a direct path insert using the
INSERT /*+ APPEND */ syntax, will not be logged (unless and until you ALTER the table
and enable full logging again). In general, however, the operations your application
performs against this table will be logged.