Redo logs are transaction logs that Oracle uses for recovery purposes. They allow Oracle to restore data to its state before a failure by replaying redo records. There are two types of redo logs: online redo logs which are used circularly for current transactions, and archived redo logs which are used to restore data during recovery. A COMMIT makes changes permanent by writing redo records to the online logs, while a ROLLBACK undoes changes by reading from the rollback segments to reverse operations. Temporary tables generate minimal redo since their changes are not recoverable, while changes to permanent tables generate standard redo logging.

1. TUĞBA ŞAHİN
Chapter 5: Redo and Rollback

2. Chapter 5: Redo and Rollback

3. Headlines
 Redo
 What Does a COMMIT Do?
 What Does a ROLLBACK Do?
 How Much Redo Am I Generating?
 Can I Turn Off Redo Log Generation?
 Block Cleanout
 Temporary Tables and Redo/Rollback
 Set Transaction

4. Redo
Redo log files are extremely crucial to the Oracle database.These are the
transaction logs for the database.
They are used only for recovery purposes; their only purpose in life is tobe
used in the event of an instance or media failure.
If the power goes off on your database machine, causing an instance
failure, Oracle will use the online redo logs in order to restore the system
to exactly the point it was at, immediately prior to the power outage.

5. If your disk drive fails, Oracle will utilize archived redo logs as well as online redo logs
in order to restore a backup of that drive to the correct point in time.
Oracle maintains two types of redo log files, online and archived. Every Oracle
database has at least two online redo log files. These online redo log files are used in
a circular fashion. Oracle will write to log file 1, and when it gets to the end of that
file, it will switch to log file 2, and begin writing to this one.
Redo, or transaction logs, are one of the major features that make a database a
database.
Media failures, when for instance, the hard disk goes bad. Without them, the
database would not offer any more protection than a file system.

7. What Does a COMMIT Do?
When we COMMIT, all that is left to happen is the following:
• Generate a SCN (System Change Number) for our transaction.
• LGWR writes all of our remaining buffered redo log entries to disk, and records the
SCN in the online redo log files as well. This step is actually the COMMIT. If this
step occurs, we have committed. Our transaction entry is removed, this shows that
we have committed. Our record in the V$TRANSACTION view will ʹdisappearʹ.
• All locks held by our session are released, and everyone who was enqueued
waiting on locks we held will be released.
• Many of the blocks our transaction modified will be visited and ʹcleaned outʹ in a
fast mode if they are still in the buffer cache.

9. What Does a ROLLBACK Do?
Now, if we change the COMMIT to ROLLBACK, we can expect a totally
different result.
The time to roll back will definitely be a function of the amount of data
modified.
I changed the DO_COMMIT routine we developed in the What Does a
COMMIT Do? Section to perform a ROLLBACK instead (simply change the
COMMIT on line 23 to ROLLBACK) and the timings are very different.

10. When we ROLLBACK:
We undo all of the changes made. This is accomplished
by reading the data back from the ROLLBACK (undo)
segment, and in effect, reversing our operation. If we
inserted a row, a ROLLBACK will delete it. If we updated
a row, a rollback will reverse the update. If we deleted a
row, a rollback will re‐insert it again.
All locks held by our session are released, and everyone
who was enqueued waiting on locks we held will be
released.

11. Time Comparison for Commit and
Rollback Operations

12. Timecommit < Timerollback

13. How Much Redo Am I Generating?
As a developer, you will find that it can be relevant to be
able to measure how much redo your operations generate.
The more redo you generate, the longer your operations
will take, and the slower the entire system will be.

14. We saw concrete proof of this above, where a COMMIT for each row took three times
as long as committing when the transaction was complete

15. Can I Turn Off Redo Log Generation?
This question is often asked. The simple short answer
is ʹnoʹ, since redo logging is crucial
for the database; it is not overhead, it is not a waste.
You do need it, regardless of whether
you believe you do or not. It is a fact of life, and it is the
way the database works. However,
that said, there are some operations that can be done
without generating redo log in some
cases.

16. Block Cleanout
Stored on the block header. A side effect of this is that
the next time that block is accessed,
we may have to ʹclean it outʹ, in other words, remove
the transaction information. This
action generates redo and causes the block to
become ʹdirtyʹ if it wasnʹt already.

19. Temporary Tables ve Redo/Rollback
Temporary tables are a new feature of Oracle 8.1.5.
Temporary tables generate no redo for their blocks.
Therefore, an operation on a temporary table is
not ʹrecoverableʹ. When you modify a block in a
temporary table, no record of this change will be
made in the redo log files. However, temporary
tables do generate rollback, and the rollback is
logged.

20. I set up a small stored procedure to do some SQL on the table, and report the results:

21. As you can see:
• The INSERT into the ʹrealʹ table generated a lot of redo. Almost no redo was
generated for the temporary table. This makes sense ‐ there is very little rollback
data generated for INSERTs and only rollback data is logged for temporary tables.

22. The UPDATE of the real table generated about twice the
amount of redo as the temporary table. Again, this makes
sense. About half of that UPDATE, the ʹbefore imageʹ, had
to be saved. The ʹafter imageʹ (redo) for the temporary
table did not have to be saved.
The DELETEs took about the same amount of redo space.
This makes sense as the rollback for a DELETE is big, but
the redo for the modified blocks is very small.
Hence, a DELETE against a temporary table takes place
very much in the same fashion as a DELETE against a
permanent table.

23. SET TRANSACTION
 The SET TRANSACTION SQL statement may be used
to ʹpickʹ the rollback segment you would like your
transaction to use. This is generally used in order to
have a really big rollback segment for some large
operation.

24. THANKS
FOR
LISTENING