Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: RAC on Linux

Re: RAC on Linux

From: Pete Sharman <peter.sharman_at_oracle.com>
Date: 10 Dec 2002 09:44:28 -0800
Message-ID: <at595s02s9p@drn.newsguy.com>


In article <NYeI9.91978$g9.256699_at_newsfeeds.bigpond.com>, "Howard says...
>
>Pardon me for butting in, but....
>

No! :)
>
>"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.

So is editing the init.ora file and entering a completely illegal value for a parameter. I've brought a Production database to its knees after doing some index maintenance one night (thankfully many years ago), and forgetting to change the value for SORT_AREA_SIZE back to something reasonable. THe point is, of course, that using EITHER an SPFILE or an init.ora you can screw things up. Should the SPFILE be fixed so it doesn't allow this? Yes, and maybe in a future release it will be. But there's absolutely no way that I can see to stop you from screwing up an init.ora file, now or in the future.
>
>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.

I'd venture to say your ALTER SYSTEM command ain't a simple typo! And the instance is restartable, it just takes a couple of steps. To me, this is where a best practice needs to be defined anyway. Once you've changed a parameter in an SPFILE, you should do a CREATE PFILE command so you have a backup.
>
>> 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.

Agreed. I was thinking more of OS's without a CFS.
>
>> 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 you
>got 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.

You know for the life of me I can't find where I saw this. In any case, I shouldn't have said dynamic memory management. What I was referring to was Oracle's ability to dynamically change parameters WITHOUT using the ALTER SYSTEM command. ANd I still can't find that anywhere so maybe I was dreaming when I saw it!
>
>> 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.

Again, agreed. I'm so used to people not having a CFS that I keep forgetting when they do. Sorry, my bad!
>
>Regards
>HJR
>
>
>
>> HTH. Additions and corrections welcome.
>>
>> Pete
>>
>> SELECT standard_disclaimer, witty_remark FROM company_requirements;
>>
>
>

HTH. Additions and corrections welcome.

Pete

SELECT standard_disclaimer, witty_remark FROM company_requirements; Received on Tue Dec 10 2002 - 11:44:28 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US