RE: 19c Physical Standby

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Fri, 26 Feb 2021 09:17:00 -0500
Message-ID: <49a101d70c4a$0ce7f3c0$26b7db40$_at_rsiz.com>



Yes, regarding #1, exactly as I outlined. Yet there is something special about the number 2 for the number of sets of processes.  

Especially for the log shipping variety of transmission, having the archived redo logs be smaller has value in competition with the extra set of processes.  

Also, for extreme throughput of updates, there is a value to owning the log writer.  

For example, if the throughput of change through a single PDB is limited by the write rate to a single chain of data sync on a machine complex, using two separate destinations with independently operating pathways from memory to persistence is not possible within a single container. That may dictate even more than 2 containers.  

So I maintain my position that this is indeed not “Ni!” but rather is a slippery slope where the most productive position of the stake on the slippery slope should be the result of measurements.  

I am glad you are familiar with Monty Python.  

mwf  

From: Mladen Gogala [mailto:gogala.mladen_at_gmail.com] Sent: Thursday, February 25, 2021 7:48 PM To: Mark W. Farnham; smishra_97_at_yahoo.com; oracle-l_at_freelists.org Subject: Re: 19c Physical Standby  

Well, that sort of defeats the purpose. The container databases were invented for two reasons:

  1. To avoid the overhead of running several separate instances on the same machine.
  2. Because every other manufacturer had that feature. Oracle was in the bind because they were technologically behind.

I don't have a need for the Holly Hand-Grenade of St. Antioch, I am the DBA who always says "Ni!".

On 2/25/21 8:22 AM, Mark W. Farnham wrote:

A sledge hammer approach requires asking yourself the question of whether having two distinct container databases on the complex of machinery in question is reasonable.

--

Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com

--

http://www.freelists.org/webpage/oracle-l Received on Fri Feb 26 2021 - 15:17:00 CET

Original text of this message