What's the point of redo logs?

Question

Why does Oracle bother writing everything to redo logs? If it's going to write data changes to the disk, why not just write them once to the data files and be done with it? What's the point of doing it twice? And if it's a redundancy thing, why not mirror the data disks?

Answer 1

Hemant K Chitale wrote:
How would you backup a database while it is in use ? You can't lock all the datafiles to prevent writes to them. Yet, transactions may be updating different blocks in different datafiles even as the backup is in progress. Say your backup starts with datafile 1 (or even datafiles 1,2,3,4 in parallel) at time t0. By time t5, it has copied 20% of the datafile to tape or alternate disk backup location. Along comes a transaction that updates the 100th block (somewhere within the 10-11% range) of datafile 1 and also the 60th block of datafile 5. Meanwhile, the backup continues running, already having taken a prior image of the 100th block and not being aware that the block has been changed. At time t25 it completes datafile 1 (or datafiles 1,2,3,4) and starts backing up datafile 5. Now, when it copies the 60th block of datafile 5, it (the backup utility) doesn't know that this block is inconsistent with the backup image of the 100th block of datafile 1.
Instead of 1 transaction imagine 100 or 1000 transactions occurring while the backup is running.
Surely, Oracle must be able to regenerate a consistent image of the whole database when it is restored ?
That is what the Redo stream provides. The Redo stream is written to Archivelogs so that it can be backed up -- no Archivelog file is "in flux" (particularly if you use RMAN to backup the Archivelogs as well !).
Had Oracle been merely writing to the datafiles alone, without a Redo stream, there is no way it could recreate a consistent database -- whether after Crash Recovery OR after Media Recovery.Interesting point about how redo logs facilitate backups. So what you're saying is that the redo logs help keep the data in the actual data files in a consistent state by only writing full transactions to them at a time. Presumably Oracle will either write out the redo log data to the data files before a backup or will at least prevent the redo logs from writing to the data files during a backup. I always wondered how databases got around that problem of keeping the system available for writing during a backup. I wonder how SQL Server does it.
Hemant K Chitale wrote:
Now, approach this from another angle. A database consists of 10 or 100 or 500 datafiles. You have 10 or 100 or 1000 sessions issuing COMMITs to complete their transactions, which could be of 1 row or 100 rows or 1million rows, each transaction of a different size. Should the 1000 sessions be forced to wait while Oracle writes all those updated blocks to disk in different datafiles -- how many blocks can it write in "an instant" ?
But what if Oracle manages to write much less information -- the bare minimum (called "change vectors") to re-play every transaction to a single file serially ? That would be much faster. Imagine writing to 500 datafiles concurrently, having to open the file, progess to the required block address and update the block, for each block changed in each file VERSUS writing much lesser information serially to a single file -- if the file is full, switch to another file, but keep writing serially.As to your second point, I don't really have a good enough understanding about the format of redo logs vs. the data files to follow you totally. Are you saying that it takes more time to write to the data files because you have to find the proper place in the B-Tree before you can write to it? And that doing that is slower than just opening the redo log and always appending new information to the very end? Maybe so, but it seems like all transactions having to write to a single redo log in serial would slow things down since there would be a ton of contention for one file. Whereas with the data files, you could potentially have several transactions writing to different files simultaneously (provided you hardware would support doing that). And it seems to me like a change vector would contain a lot more information than a field value, but, like I said, I'm not really familiar with the format.