Re: Oracle vs. PostgreSQL - a comment

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