For me, PDBs was just Oracle’s final step into the architecture that most
other RDBMS platforms already possessed- multi-tenancy. I’m also aware,
that in reverse, a schema and other “better known features in Oracle” have
become the norm in other RDBMS. Customers experience a feature and the
benefits in one and want it in the other- it’s just human nature.
I’ve been executing detach/attach commands, and other tenant benefits on
user databases since SQL Server 7, where PDBs weren’t around till Oracle
12c. The same demands for other platform features I am experiencing in the
Azure realm. I have a customer right now that wants RAC One Node in an
Azure AG environment- multi-node, a single, clustered database to scale
vs. replicas with no write-back to the primary.
There are considerable benefits to isolating the tenant when it comes to
consolidation of resources and data security, but as with any
implementation of a new feature into a release, it can take a couple
versions to bake it without burning anyone.
Kellyn
On Mon, Apr 22, 2019 at 6:30 PM Franck Pachot <franck@xxxxxxxxxx> wrote:
Hi,
monitoring).My main issue with PDB, ..., is it breaks things (scripts, workflows,
If going multitenant breaks things, then those things may have been
already bad. If your scripts always connect '/ as sysdba' and your
applications connect with (SID=) then they are easily broken. If they are
not, you can be surprised to see how things continue to work with minimal
change. If they are, that's a good occasion to fix that.
Oracle's financial and strategic (Oracle Cloud?)Also suspect that changes like this are initially architected more for
Sure, the budget to do this came from the Cloud. But that's positive that
it finally helped to change this architecture which was maybe the only bad
decision remaining from the initial development of Oracle dictionary:
mixing system data and metadata with user stuff is bad.
If you think that there is no benefit coming with multitenant (including
single-tenant), please try a PDB 'relocate availability max' in Standard
Edition ;)
Regards,
Franck.
On Wed, Apr 17, 2019 at 8:34 PM <post.ethan@xxxxxxxxx> wrote:
I am thinking of Linus Torvalds development rule of "Do no harm, don't
break users."
My main issue with PDB, or at least the issue I think exists until I have
had a chance to work with it more, is it breaks things (scripts, workflows,
monitoring).
Perhaps there may have been a way to achieve PDB as an abstraction that
looked the same as always but was in fact single PDB. Not sure and the
engineering challenges I am sure are ginormous.
Also suspect that changes like this are initially architected more for
Oracle's financial and strategic (Oracle Cloud?) interests more so than
that of the customer base.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> On
Behalf Of Tim Hall
Sent: Wednesday, April 17, 2019 12:16 PM
To: Andrew Kerber <andrew.kerber@xxxxxxxxx>
Cc: oracledbaquestions@xxxxxxxxx; ORACLE-L <oracle-l@xxxxxxxxxxxxx>
Subject: Re: Does anyone find PDB/CDB DBs have value?
Hi.
Check out the CONTAINERS clause. You can query across containers with
that. If you don't like that, you can use catcon.pl to perform and
action in each PDB, including queries.
Full disclosure. I'm a fan. I even like them with Lone-PDB, which is what
we use in our company. We don't have the multitenant option, so this is all
we can sensibly use. Even then there are some neat things.
We do a lot of cloning to refresh Dev/Test environments. Prior to PDBs,
that meant doing RMAN clones (typically active). They are all scripted and
work, but it's so much easier to throw in:
CREATE PLUGGABLE DATABASE devpdb FROM prodpdb@prod_link; ALTER PLUGGABLE
DATABASE devpdb OPEN;
Since the CDB is already there, with backup schedules in place and
registered with Cloud Control, there is no messing about. It cuts down on
the scripting and the post-clone cleanup.
Upgrades and patches are a little quicker if you want to just patch the
PDB, rather than the CDB and the PDB at once. You can build your new
patched CDB, then when everything is sorted and you are happy it's all
good, just upgrade/patch the PDB using the unplug/plugin method.
I've written a bunch about it all here, but I'm still learning.
https://oracle-base.com/articles/12c/multitenant-overview-container-database-cdb-12cr1#multitenant-articles
I suppose one of the big factors in my mind is, this is that way it is
now. You might not like the multitenant architecture, but Non-CDB is
deprecated and will be removed in a future release, so you might as well
get used to it. We only use non-CDB if forced to my external factors, like
vendors not understanding it. :)
Cheers
Tim...
--
//www.freelists.org/webpage/oracle-l
--
