Re: Shooting yourself in the spfile
- From: Adam Donahue <adonahue@xxxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Wed, 18 Feb 2004 18:07:52 -0800
Yikes!
<<that can be done by creating a pfile from your init.ora or just
simply by creating a copy of your 'current' init.ora>>
That is one jumble of a sentence!
An init.ora *is* a pfile. And you do not need to change the pfile and
recreate the spfile to change an spfile. You can alter system ... scope
= spfile (or scope = both). You /do/ need to recreate the pfile from an
spfile (or manually modify it by hand) in order to keep in sync with
your live parameters. Perhaps you have pfile and spfile reversed...
OK -- I think we've exhausted *this* topic! :-)
Adam
QuijadaReina, Julio C wrote:
>Let's talk the same language ;-)
> working init.ora = current init.ora
>and yes, my example will require to bounce the instance...
>
>I totally agree with you in doing pre and post backups...and that can be done
>by creating a pfile from your init.ora or just simply by creating a copy of
>your 'current' init.ora. Now, that you have a spfile in place, the only way to
>change it is by making the changes you need to init.ora and creating the
>spfile again. This will overwrite your old spfile with one containing the new
>parameters read from your init.ora....Again...this approach will require you
>to bounce your instance, which might now work for some.....Ultimately...there
>is the option to talk to Oracle about it...;-)
>
>Julio
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx on behalf of Adam Donahue
> Sent: Wed 2/18/2004 8:05 PM
> To: oracle-l@xxxxxxxxxxxxx
> Cc:
> Subject: Re: Shooting yourself in the spfile
>
>
>
> Hmmm... what do you mean, 'working init.ora'? I believe the procedure
> below would also require a restart of the instance, to utilize the
> updated pfile. This is great for first-time use, but going forward
> (now that an spfile's in place), how would you update it then?
> Essentially, you can back up the 'current' init.ora by running create
> pfile from spfile prior to the change, but I just assumed for my example
> that a backup had been made on the prior change. (In reality, of
> course, it's a good idea to run both pre and post backups.)
>
> Adam
>
> QuijadaReina, Julio C wrote:
>
> >Adam,
> >
> >I find it useful to always back up my original init.ora file, being
> that with Oracle 9i and never versions, one cannot make changes to the binary
> spfile. So, whenever I need to make a permanent change on startup parameters:
> >
> >1. Create a copy of the working init.ora
> >2. Make the changes needed
> >3. Create the new spfile using:
> > CREATE SPFILE FROM PFILE = '$ORACLE_HOME/location/of/init.ora'
> >
> >Julio
> >
> > -----Original Message-----
> > From: oracle-l-bounce@xxxxxxxxxxxxx on behalf of Adam Donahue
> > Sent: Wed 2/18/2004 7:42 PM
> > To: oracle-l@xxxxxxxxxxxxx
> > Cc:
> > Subject: Re: Shooting yourself in the spfile
> >
> >
> >
> > I know there's a bug with fixed_date, in that you have to set
> it to
> > 'none' in memory but the empty string '' in the spfile. I
> don't think
> > that that hoses your spfile, though.
> >
> > An advantage of using an spfile is that when starting a
> database from
> > remote, the pfile might not be available (you have to have a
> copy
> > locally) whereas the spfile used is always the one on the
> server side.
> > I typically save a pfile version as well, for versioning
> purposes. So
> > the change becomes:
> >
> > sql> alter system set var = value scope = both;
> > sql> create pfile = '/tmp/backup/initINST_date.ora' from spfile;
> >
> > Adam
> >
> > Brian McGraw wrote:
> >
> > >My approach so far has actually been to avoid the spfile
> altogether, out of
> > >the fear of encountering your scenario.
> > >
> > >But curious minds want to know, Jonathan... what did you
> change?? :)
> > >
> > >---------------------------------
> > >| Brian McGraw -+- Senior DBA |
> > >| mailto:Brian.McGraw@xxxxxxxxx |
> > >---------------------------------
> > >
> > >-----Original Message-----
> > >From: oracle-l-bounce@xxxxxxxxxxxxx
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
> > >On Behalf Of Jonathan Gennick
> > >Sent: Wednesday, February 18, 2004 4:57 PM
> > >To: oracle-l@xxxxxxxxxxxxx
> > >Subject: Shooting yourself in the spfile
> > >
> > >I just went through an episode in which I changed a
> > >parameter setting using scope=spfile, attempted to bounce my
> > >instance, and found that I was hosed. Fortunately, I had an
> > >up-to-date text version of my parameter file (i.e. init.ora)
> > >that I was able to fall back on, and I easily used that to
> > >restart my instance. Now I have to recreate my server
> > >parameter file, because, having started my instance using
> > >init.ora, it won't let me change a parameter using
> > >scope=spfile. Arg!
> > >
> > >All this has underscored the importance of backing myself up
> > >when it comes to parameter changes, and I'm wondering about
> > >best-practices. What do you all do to protect yourself here?
> > >I can think of two alternatives:
> > >
> > >* Follow each successful spfile change by creation of a new,
> > >text-based (init.ora) parameter file, to use in case you
> > >muck up your spfile in the future.
> > >
> > >* Make a copy of your binary spfile after each successful
> > >change, or before making a change, so that you can fall back
> > >by copying the last known-good spfile over the one you
> > >screwed up.
> > >
> > >Are there any alternatives that I've missed here? What
> > >approach is best, and why? Right now, I lean towards keeping
> > >a current, text-based parameter file, because that gives you
> > >the flexibility to go in with vi and tweak a parameter. In
> > >fact, I wonder why the server parameter file can't be
> > >text-based. If I have to constantly make text-based backups
> > >to protect myself, why not just make the spfile text-based
> > >to begin with?
> > >
> > >Best regards,
> > >
> > >Jonathan Gennick --- Brighten the corner where you are
> > >http://Gennick.com * 906.387.1698 * mailto:jonathan@xxxxxxxxxxx
> > >
> > >Join the Oracle-article list and receive one
> > >article on Oracle technologies per month by
> > >email. To join, visit
> > >http://four.pairlist.net/mailman/listinfo/oracle-article,
> > >or send email to Oracle-article-request@xxxxxxxxxxx and
> > >include the word "subscribe" in either the subject or body.
> > >
> >
> >----------------------------------------------------------------
> > >Please see the official ORACLE-L FAQ: http://www.orafaq.com
> >
> >----------------------------------------------------------------
> > >To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> > >put 'unsubscribe' in the subject line.
> > >--
> > >Archives are at //www.freelists.org/archives/oracle-l/
> > >FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> >
> >-----------------------------------------------------------------
> > >
> > >
> >
> >----------------------------------------------------------------
> > >Please see the official ORACLE-L FAQ: http://www.orafaq.com
> >
> >----------------------------------------------------------------
> > >To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> > >put 'unsubscribe' in the subject line.
> > >--
> > >Archives are at //www.freelists.org/archives/oracle-l/
> > >FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> >
> >-----------------------------------------------------------------
> > >
> > >
> >
> > ----------------------------------------------------------------
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > ----------------------------------------------------------------
> > To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> > put 'unsubscribe' in the subject line.
> > --
> > Archives are at //www.freelists.org/archives/oracle-l/
> > FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> >
> -----------------------------------------------------------------
> >
> >
> >-- Binary/unsupported file stripped by Ecartis --
> >-- Type: application/ms-tnef
> >-- File: winmail.dat
> >
> >
> >----------------------------------------------------------------
> >Please see the official ORACLE-L FAQ: http://www.orafaq.com
> >----------------------------------------------------------------
> >To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> >put 'unsubscribe' in the subject line.
> >--
> >Archives are at //www.freelists.org/archives/oracle-l/
> >FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> >-----------------------------------------------------------------
> >
> >
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
>
>-- Binary/unsupported file stripped by Ecartis --
>-- Type: application/ms-tnef
>-- File: winmail.dat
>
>
>----------------------------------------------------------------
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>----------------------------------------------------------------
>To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
>put 'unsubscribe' in the subject line.
>--
>Archives are at //www.freelists.org/archives/oracle-l/
>FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
>-----------------------------------------------------------------
>
>
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
