Re: Does anyone find PDB/CDB DBs have value?

From: Kellyn Pot'Vin-Gorman <dbakevlar_at_gmail.com>
Date: Mon, 22 Apr 2019 19:32:34 -0400
Message-ID: <CAN6wuX21igOzrqQJjzGPUzeEMFbN89ynr6QBKQGJ_jvGMOSefQ_at_mail.gmail.com>



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_at_pachot.net> wrote:

> Hi,
>
> >> My main issue with PDB, ..., is it breaks things (scripts, workflows,
> monitoring).
> 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.
>
> >> Also suspect that changes like this are initially architected more for
> Oracle's financial and strategic (Oracle Cloud?)
> 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_at_gmail.com> 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_at_freelists.org <oracle-l-bounce_at_freelists.org> On
>> Behalf Of Tim Hall
>> Sent: Wednesday, April 17, 2019 12:16 PM
>> To: Andrew Kerber <andrew.kerber_at_gmail.com>
>> Cc: oracledbaquestions_at_gmail.com; ORACLE-L <oracle-l_at_freelists.org>
>> 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_at_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...
>>
>>
>>
>>
>> --
>> http://www.freelists.org/webpage/oracle-l
>>
>>
>>
>
> --

*Kellyn Pot'Vin-Gorman*
DBAKevlar Blog <http://dbakevlar.com>
President Denver SQL Server User Group <http://denversql.org/> about.me/dbakevlar

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Apr 23 2019 - 01:32:34 CEST

Original text of this message