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
