Re: RAC on Linux

From: Howard J. Rogers <howardjr2000_at_yahoo.com.au>
Date: Wed, 11 Dec 2002 06:28:28 +1100
Message-ID: <N6rJ9.625$jM5.1790@newsfeeds.bigpond.com>

"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.

> >
> >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.

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).

>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;
> Received on Tue Dec 10 2002 - 13:28:28 CST