Mike,
I don't think you can ask about hypothetical strategies for the redo log
before stating what you think the purpose of the database should be.
If you expect the database to be the reference of last resort for the
correctness and (immediate) consistency of the data then you might like a
different strategy from someone who thinks the database is some sort of
record of evolution of the data that allows the current version of the data
to be re-imaged by a client.
Regards
Jonathan Lewis
On Thu, 17 Jun 2021 at 13:55, Michael D O'Shea/Woodward Informatics Ltd <
woodwardinformatics@xxxxxxxxxxxxxxxx> wrote:
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
