"High Availability" is a complex goal to achieve, because it can be
nullified by any link in the whole server chain.
So even if Oracle is theoretically more bulletproof than
Postgres, if you don't have someone who is an actual expert
in configuration and recovery Oracle installations
and operating systems, then you don't actually get the
benefit of the Oracle brand name.
For example, for a long time, ArsDigita was installing Oracle
configured with archive logging turned off by default, so a "hot
backup" could not be made in case of an error that corrupted
the database files(such as filesystem
running out of space);
the only way to get a restore was using the last export dmp file,
and the dump scripts were not configured to check if this
file was being written correctly. I learned this
the hard way when a customer installation that had
been running for two years with little attention did
in fact run out of disk space, corrupted the database,
and the cron job for nightly exports had been turned off
at some point in the past. They eventually
got some procedures in place for more bulletproof recovery
procedures, when a real Oracle admin joined, but even now I don't
know if some older customers sites have been updated to new
standards.
Anyway, the point is that no one initally knew enough about Oracle
to understand how to make reliable backup architecture, even though
this was the raison d'etre for using the whole expensive
system in the first place. So it might be necessary but it is not
sufficient to say that because you have Oracle you are winning in
availability.
