Re: Why does Orcl generate REDO logs in NOARCHIVE mode?

From: Thomas Kyte <tkyte_at_us.oracle.com>
Date: Wed, 24 Mar 1999 13:25:20 GMT
Message-ID: <36fbe3c6.3408941@192.86.155.100>

A copy of this was sent to Mike Burden <michael.burden_at_capgemini.co.uk> (if that email address didn't require changing) On Wed, 24 Mar 1999 11:33:27 +0000, you wrote:

>Agreed that redo logs aid recovery, but surely they are not essential. If you
>accept that in the event of a failure, you will restore to a cold backup, why do

The redo logs are used to recover from things like a POWER failure, software failure, database crash, etc. They are only "essential" if you don't want to always have to go back to your last full cold backup after a power failure, system failure, software failure of some sort (eg: they are pretty essential).

We log changed bytes to a large sequential file called the online redo logs. We buffer hundreds or thousands of changed blocks that will need to be randomly written all over the place. It makes the database go faster. Thats the concept of having redo logs -- speed and safety.

Lets say you change 100 blocks. Block1 is in file1, block2 is in file2, and so on (extreme case -- you've inserted 100 rows into 100 tables and changed 100 blocks on different files all over the place). Instead of doing 100 seeks and random writes to 'commit' your work and make it permanent -- we take the changed bytes from your 100 updates and in one large write we write them out. Much much faster then 100 seeks and 100 separate writes. If the database fails (power goes out) right now, we have safely in the redo logs the changes you made even though the datafiles *do not*. When the database restarts, it will read the online redo logs -- REDOING any work that was done before the crash. The database will then rollback any work that was redone but not committing and will 'commit' anything that was committed. You lose no work.

>you need the redo logs. If you don't back them up and you loose everything you
>can still go back to a cold back even without the redo logs. I have thought
>about putting redo and rollback segments into a RAM disk to prevent the disk IO
>in certain situations (e.g. Development environment). I've already tried it with
>Rollbacks in RAM which seem to work OK. If it all goes nasty you just restore
>and re-run. No roll forward necessary.
>

don't, don't, don't -- unless you want to rebuild the whole database as you describe. Wouldn't recommend it. all it takes is one shutdown abort or pulled plug to kill your database and unless its a trivially sized database, it could take a while to find the tapes and restore.

>It would be nice if you could turn either or both off and save on the overhead.
>Hence three modes. This would be particularly useful for large overnight batch
>jobs where you do a cold backup at the end anyway. Because the job works 99.999%
>of the time you wish to take advantage of the fact by switching off redo and
>rollback and save on loads of IO.
>

but you wouldn't be saving on loads of IO really -- if the database crashed in the middle of a large load you would have a *real* mess on your hands. Some of the data would be loaded and on disk, some would be loaded but lost (since it was in the buffer cache) and some would be not loaded at all -- you would have *no* way of finding out.

the only time this would be useful is if you are loading an empty table or appending lots of data. In that case -- put the database in noarchivelog mode and direct path load the data -- no log, no rollback just write to disk. So, that mode does exist (but after putting the database into noarchivelog mode and then back into archive log mode, you'll have to backup again so it may actually not be worth it in many cases)...

>Just my thoughts. Anyone else care to comment. Are these features available in
>any other DBMS?
>
>I still think Oracle writes twice as much data to the redo logs than it needs to
>because rollback info gets logged too. But that's another story.
>

its gotta. We roll forward from the log, back from rollback. rollback is logged. Its a performance enhancement believe it or not (separate redo and rollback). Some databases put both ROLLBACK and REDO into their logs. This has a couple of implications:

logs are both read from and written to. They will rollback from the logs (read) and write to the logs. Oracle only WRITES to the online redo logs when the database is up (well, arch will read them but only when lgwr isn't writing them). There is no read/write contention on logs -- no thrashing.
logs in databases that store redo and rollback are typically managed like a HEAP (whereas in Oracle they are managed like a stack). Heap space management has a high overhead when compared to a stack. They have to use heap management for support of long transactions (anything over a second or two) else they would almost immediately run out of log space. They need to micro manage the space in the transaction logs. Oracle managemes it like a stack. We 'roll' logs as we go along. Space management is much more efficient this way. Additionally we have the concept of many rollback segments -- this further reduces the contention problem for a shared resource and allows the logs to 'roll' without getting full. You can distribute the rollback io over many many disks and many many users -- logs are a serial beast and reducing contention on them is a good thing.

>
>Jan-Marten Spit wrote:
>
>> Chakravarthy KM Nalamotu wrote in message <7d97kq$fh8_at_news.Hawaii.Edu>...
>> >Hello Oracle Users,
>> >I was wondering if someone could explain why Oracle
>> >writes transactions to redo logs even though
>> >the database is running in NOARCHIVELOG mode.
>> >If I am running in NOARCHIVELOG mode, doesn't it mean
>> >that I don't need the logs which also should include redo logs?
>> >What good are these logs doing to me except for wasting
>> >my system resources?
>> >There must be a good reason for this.
>> >Can someone explain the logic behind this architecture.
>> >Thanx,
>> > Kittu.
>>
>> Separate these concepts:
>>
>> -Redo log
>> The redo log consist of two or more log files, and contains all changes to
>> data blocks in the buffer cache not synced with their datafiles. In case of
>> a database crash, the redo log is used to sync the datafiles with the
>> database state at the time of the crash. The redo log aids in recovering in
>> case of a disk failure. When a redo log file is full, a log switch occurs,
>> and the redo log is written to the next redo logfile. There are always two
>> or more redo logfiles.
>>
>> -Archive log
>> Since the redo log is circular, the redo log files are overwritten
>> eventually. In archive log mode, a trail of redo log files is kept. An
>> archive is created of a redo log file before the redo log overwrites it. The
>> archive log aids in instance failures, being able to roll forward the
>> database state from the last backup to a specific (check) point in time.
>> Only backups (while the database is fully operational) are also possible.
>>
>> In short, you need your redo logs files in all cases, because oracle needs
>> it to guarantee database consistency. The use of archive log mode is
>> optional. Benefits are recovering to point in time, and possibility for
>> online backups. When you only require offline backups (shut-backup-start),
>> and the tape from your last offline backup is good enough in case of a
>> failure, you do not need archive log mode. Note that the archive log grows
>> unless you do something about it, like cleaning after backup.
>>
>> Hope this helps,
>>
>> JM

Thomas Kyte
tkyte_at_us.oracle.com
Oracle Service Industries
Reston, VA USA

--
http://govt.us.oracle.com/ -- downloadable utilities

Opinions are mine and do not necessarily reflect those of Oracle Corporation Received on Wed Mar 24 1999 - 07:25:20 CST