| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: RAC on Linux
Pardon me for butting in, but....
"Pete Sharman" <peter.sharman_at_oracle.com> wrote in message
news:asr44o0od5_at_drn.newsguy.com...
> In article <6de2ae57.0212052248.601cb1d4_at_posting.google.com>,
> piet.de.visser_at_cmg.com says...
> >
> snip
> >
> >But I want to avoid SPFILES for the moment.
> >This dino wants to control his own startup parameters in an INI file.
> >Have generated ini-from-sp on Tru64 and found the simplified syntax in
> >it.
> >Looking for way to bounce around between SP and INI file, want best of
> >all worlds:
> > - online altering of parameters when I need that (but not always)
> > - keep and manage parameters in a readable file.
> > - all parameters for all nodes in a single place (e.g. on
> >cluster-disk).
> >
> >Current alternative would be : link all INST<n>ini.ora into one
> >directory (will be more simple if I have a single oracle-home). Use an
> >include-file
> >with all the common parameters in it and use INST<n>.ora for instance
> >specific parameters.
> >
> >Your thoughts are welcome!
>
> I don't really see why you don't want to use the SPFILE, which does
exactly what
> you want:
>
> 1. You can use the ALTER SYSTEM command to change parameters on the fly
> (provided they're dynamic of course) using either an SPFILE or not. THe
> disadvantage of doing this with an old style parameter file is that you
have to
> remember to change the parameter file as well if you want the change to be
> permanent.
There is nothing to stop you issuing completely illegal alter system commands, and yet still successfully editing the SPFILE:
alter system set db_cache_size=0 scope=spfile sid='*';
...is accepted without question.
You have, of course, just completely buggered up the SPFILE, so that next time you bounce an instance or instances, nothing restarts. Next stop: 'create pfile from spfile', edit pfile, 'create spfile from pfile'.
It *is* much quicker to just edit the init.ora.
>
> 2. The SPFILE is a readable file. It has a binary header which prevents
it
> being directly modified, but otherwise the values in there are simple text
> values.
>
Exactly. Binary, schminary. It makes correcting simple typos which render an instance un-restartable a right pain in the proverbials.
> 3. It's stored in one central location.
>
Big deal. The init.ora can also be stored in a central location, because it uses star notation too, provided you have a cluster file system.
> Probably more importantly, if you want to use the dynamic memory
management
> capabilities in 9i, you HAVE to use an SPFILE IIIRC.
>
EEEEEEEEEEEEEEEEEEKKKK! That's just not true. I'd love to know where yougot this one, Pete: 'cos if you think this is so, then I'm worried that on some platform, somewhere, at some time, it will indeed be so. And that would suck big time. But at the moment, 9i R2 resizes memory components dynamically just fine with an init.ora on Linux, Solaris and Windows.
> If you still don't want to use an SPFILE, though, keep a common init.ora
file
> for parameters that are the same across all instances, and separate
parameter
> files for each instance for instance specific parameters. First line of
the
> instance specific init.ora would be IFILE=common_parameters.ora.
>
No need. You can use just one init.ora on the shared disk, and for those parameters that need to be different for different instances, stick an instance identifier on the front, followed by a fullstop.
Regards
HJR
> HTH. Additions and corrections welcome.
>
> Pete
>
> SELECT standard_disclaimer, witty_remark FROM company_requirements;
>
Received on Fri Dec 06 2002 - 22:49:31 CST
 |
 |