Re: Automatic startup of pluggable databases - why not the default?

  • From: Andrew Kerber <andrew.kerber@xxxxxxxxx>
  • To: "post.ethan@xxxxxxxxx" <post.ethan@xxxxxxxxx>
  • Date: Fri, 28 Aug 2015 07:25:04 -0500

See section 1.18.
http://docs.oracle.com/database/121/NEWFT/chapter12102.htm#NEWFT514
Sent from my iPad

On Aug 27, 2015, at 10:42 PM, Ethan Post <post.ethan@xxxxxxxxx> wrote:

Why wouldn't it simply restart anything that was running prior to crash or
shutdown and leave anything that was not running alone?

On Mon, Jul 27, 2015 at 5:41 AM, Mark W. Farnham <mwf@xxxxxxxx> wrote:
+42 to Jared’s notion that there should be a proper startup control
mechanism with fine grained control.



Further notions (risking the creation of a design by committee camel when
we’re looking for a horse):



1) A full table describing things like workshift definitions. (Hey, the
container got restarted, what is supposed to be open NOW.)

2) Order of start

3) Alert instruction mechanism if unable to start, possibly unable to
start within delta time

4) IF it requires recovery beyond instance recovery from the online redo,
do you want to proceed automatically?

5) …



Probably want to make it easy to instantiate and edit and external table
version of the control table, which, in addition to Jared’s suggestion of a
command option to start nothing, could be used to observe and alter the
start based on an external table instead of the routine one. (I think of
this as analogous to pfile versus system parameters). After all, it would be
when you’re having trouble or wanting to start up selectively that this
would be most in need, so you’d want to be able to toggle things without
first doing a startup, right?



Probably there is a child table with services per database and workshifts,
order of start, and alerting rules as well.



I’m uncertain how this should dovetail with the Pete Sharman’s product.
Clearly it needs to work for an individual container as well as being
referenced in a natural way from EM.



Figuring out the best balance between having all the useful features and
having this be simple, like a NEST thermostat, will be the tricky part.



mwf



From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Jared Still
Sent: Friday, July 24, 2015 12:24 PM
To: John Hallas
Cc: Brent Day; oracle-l@xxxxxxxxxxxxx
Subject: Re: Automatic startup of pluggable databases - why not the default?





On Fri, Jul 24, 2015 at 7:17 AM, John Hallas
<John.Hallas@xxxxxxxxxxxxxxxxxx> wrote:

Yes I agree Brent that is the workaround that the changes in 12.1.0.2 were
meant to address. I am interested in understanding why it was not seen as
reasonable to start the pdb databases up after a container restart


I can see why it would not be reasonable to start all PDB's at startup.



- there may be hundreds of them; you don't want to start these all at once.

- of those hundreds, possibly a fraction of them are used regularly and
should be started.



What I don't understand is the lack of a proper method for dealing this this.



Neither the trigger nor the save state seem good options to me.



Why not a pdb control table with a START_MODE column?



Possible values

- NEVER: Never open the pdb at startup

- ALWAYS: Always start this pdb.

- ON_DEMAND: Start this pdb when someone tries to connect to it.



And then some mechanism to override this.



'startup open cdb nomount nopdb' for instance.





Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist

Principal Consultant at Pythian

Pythian Blog http://www.pythian.com/blog/author/still/
Oracle Blog: http://jkstill.blogspot.com
Home Page: http://jaredstill.com


Other related posts: