Original design approach to Oracle REDO Logs

  • From: Michael D O'Shea/Woodward Informatics Ltd <woodwardinformatics@xxxxxxxxxxxxxxxx>
  • To: "ORACLE-L (oracle-l@xxxxxxxxxxxxx)" <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 17 Jun 2021 13:55:20 +0100

Chaps, request for opinions/discussion/feedback ..... 


Question: If Oracle were written today, would the same strategy behind the 
"redo log" be adopted.


An example .... for a table of 10,000,000 rows, and a contrived piece of DML 

update someTable
  set someColumn1 = 1.234

that "updated" all the rows
 but where someColumn1 was only updated to 1.234 for 6 rows as the remaining 
10,000,000 - 6 rows were already 1.234

Should (assuming just DML and also just the basic data types, number, varchar2, 
date, ... ) the redo log
  * record the data "change" for all 10,000,000 "updates"
  * record the real data change for just the 6 real updates
  * record solely the SQL used to perform the update for some playback purpose
  * send a message to some message broker such as Solace, Tibco, .... allowing 
subscribers to process the data change that way (might be replication/backup, 
some sort of refresh or push notification to other applications, email dispatch 
and so on)
  * some other approach else  

There is a considerable movement to event streaming technology such as Kafka to 
(indirectly) drive data change events to downstream and dependent systems (in 
Oracle assumably by polling the redo log file, or maybe some LogMiner interface 
.. I don't know the detail) in databases that include Oracle, MongoDB (referred 
to as Change Streams), and many more.

My "ask" focuses more on "just the database" interoperability with the 
remainder of what is often a large tech stack, and not the original design 
decision around redo logs for data recovery.

Mike

http://www.strychnine.co.uk


Other related posts: