On 4/21/21 12:23, Franck Pachot wrote:
>> Did Oracle change this? Last time I looked, I don't think Oracle supported local redo in their multitenant architecture either.
Hi Jeremy, they are moving in this direction (project seems to be called DGPDB internally). And what is interesting for this discussion is that they initially had redo (and even undo) at instance level, but moved this to PDB following what users were asking for: pdb level flashback, pitr, switchover,...But it is hard to compare those needs with PostgreSQL. Multiple db clusters in PG is lightweight and is the right place to isolate (users, cgroups,...). Oracle CDB is too heavy to have multiple on one host. And many isolation features is made at PDB level (lockdown profiles, resource manager)
It will be interesting to see if Oracle releases something publicly. Personally I feel like the complexity of all the different options is starting to get a bit overwhelming... in-memory, sharding, flex clusters (remote ASM), pluggable DB, data guard, VPD, RAC... and now the idea of PDB-level redo for flashback/pitr/switchover that would still enable a single shared buffer cache. And of course we still have all the plumbing for shared servers, clustered objects, freelist-based space management, external clustering software, OS-level "copy" backups, basicfile LOBs, rollback segments, freelists, dictionary-managed extents... the rule-based optimizer might even still be there! And as a sufficiently grumpy old DBA, with no real justification at all, I remain a little leery of all that automatic memory management and automatic query tuning stuff... ;)
These aren't just minor features; many of these are pretty fundamental and significant architectural differences. The testing matrix is just incomprehensible... it's hard to be sure anymore that there's anyone else on the planet running an Oracle stack the same way you are. Especially with the proliferation of one-off patches. Which increases the risk that you'll be the first one to discover the bug that exists when PDB-level redo is used together with the manual rollback segments your ETL job has used for ages alongside your old backup script which makes OS-level copies. [Just to make up an example combination.] I never did like being the first person to find a bug.
Sometimes it's hard to find that right balance of offering enough choices/configurability versus offering the single solution which can easily be made pretty robust (and having users work around known limitations).
-Jeremy
--
Jeremy Schneider
Database Engineer
Amazon Web Services
