Re: RAC on Linux

In article <N6rJ9.625$jM5.1790_at_newsfeeds.bigpond.com>, "Howard says...
>
>
>"Pete Sharman" <peter.sharman_at_oracle.com> wrote in message
>news:at595s02s9p_at_drn.newsguy.com...
>> In article <NYeI9.91978$g9.256699_at_newsfeeds.bigpond.com>, "Howard says...
>> >
>> >Pardon me for butting in, but....
>> >
>> No! :)
>[snip]
>> 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.
>
>Screwing things up isn't the issue. It's how easy is it to fix the problem.
>And it isn't easy with an spfile, because you need an instance to issue
>'alter system' commands. With an init.ora, you need a text editor.

Well, let's be totally fair. It IS relatively easy to do with an SPFILE, because even without an instance you can do a CREATE PFILE, edit init.ora, CREATE SPFILE. I'm not saying it's ideal, but I think you're not really telling the whole picture.

>
>> >
>> >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!
>
>Er, actually that example was taken from real life (Oh, OK. From the
>training room. Close enough). Slightly dodgy keyboard, I typed in 90M, the 9
>didn't register.

Training room? Real life? Huh! :)

>
>I'll give you another example from this week's DBA Fundamentals II course,
>which is being run for the first time on 9iR2. And they've set up all the
>student accounts to use an SPFILE. In Chapter 5, we get to put the database
>into MTS (sorry, "Shared Server") configuration. That requires setting the
>parameter
>
>DISPATCHERS='(PROTOCOL=TCP)(DISPATCHERS=1)'
>
>So I try:
>
>alter system set DISPATCHERS='(PROTOCOL=TCP)(DISPATCHERS=1)' scope=spfile;
>
>I get told that 'scope=spfile' is an invalid option for the alter system
>command:
>
>SQL> alter system set dispatchers='(PROTOCOL=TCP)(DISPATCHERS=2)'
>scope=spfile;
>alter system set dispatchers='(PROTOCOL=TCP)(DISPATCHERS=2)' scope=spfile
> *
>ERROR at line 1:
>ORA-02065: illegal option for ALTER SYSTEM
>
>We are reduced to export to a pfile, edit pfile, startup wth pfile, export
>to spfile. It ain't pretty.
>
>(And if you know the syntax for altering the spfile for this particular
>parameter, I'd be grateful. But whatever it is, it's not what you might
>reasonably expect when you know that 'alter system set shared_pool_size=32M
>scope=spfile' works perfectly well).

Known bug, bug # 2080569. Sorry!

Pete
>
>>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.
>
>Er... "a couple" of steps? It takes 4. It shouldn't.
>
>And I kind of object to having to create a pfile just to back up the spfile
>in a useable manner. The pfile has been automatically backed up for us since
>time immemorial in the alert log.
>
>> >
>> >> 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!
>
>Ah, OK. I don't think that's there yet. No doubt in 10i or 11.5i we will be
>taking that extra step towards a genuinely self-tuning database, and of
>course the spfile will be needed for that. That's why, much as I loathe it,
>I still force myself to use the spfile as often as possible, and have
>started making students use it to: best get the practice in now, I think.
>Doesn't mean I wouldn't rather just run for the hills whenever I see one,
>though!
>
>> >
>> >> 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!
>
>
>Hehe! I know the problem. 'RACing with RAW is for masochists'. I always
>assume there's a CFS, too!
>
>Regards
>HJR
>
>
>
>> >
>> >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;
>>
>
>

HTH. Additions and corrections welcome.

Pete

SELECT standard_disclaimer, witty_remark FROM company_requirements; Received on Wed Dec 11 2002 - 13:52:05 CST