RE: DB12c in Production? (single PDB thread)
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <fuzzy.graybeard@xxxxxxxxx>, "'Iggy Fernandez'" <iggy_fernandez@xxxxxxxxxxx>
- Date: Mon, 19 May 2014 10:04:26 -0400
In addition to what Hans mentioned, you can apparently install a full new
stack of an upgraded and/or patched container database and test the upgrade
by unplugging from the older release and plugging into the new release.
Careful thought about your actual recovery and flashback query possibility
changes across such a plug and unplug operation should be considered quite
seriously.
But even with only being allowed one pluggable at a time without extra
license cost, this does seem to facilitate the idea of instituting a fully
patched up stack on a test machine and then serially testing databases from
various other machines one at a time (which may well fit with the upgrade
calendar if the applications hosted in the various putative separate
machines and database remain unconsolidated for a good reason.)
Of course in the mode of a single PDB at a time, you do lose one of the
major advantages of the CDB, which is the reduced process count on the
machine of all the Oracle background jobs with one container hosting many
sort of independent databases.
Fasten your seatbelts.
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Hans Forbrich
Sent: Monday, May 19, 2014 12:24 AM
To: Iggy Fernandez
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: DB12c in Production?
On 18/05/2014 6:18 PM, Iggy Fernandez wrote:
>
> What are the advantages of using a CDB with a single pluggable
> database (as appears to be allowed without extra cost when using
> Enterprise Edition) instead of a non-CDB?
>
> Iggy
Biggest advantage is getting used to the new architecture - the older
architecture is officially known as "pre-12c" and based on that terminology
we suspect it will phase out.
My experience is that we need to plan at least 6 months getting adjusted
to the CDB concept and fixing scripts, etc. Switch is not going to be
a cake-walk, so the sooner we start looking at it seriously ...
Other than that, it gives a whole new way of thinking about and handling
backups, migrations, duplications, PITR, etc. - think 'transportable
database' to get started.
I suspect we have not begun to see the tip of this iceberg.
/Hans
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
