Re: Un set parameter in spfile

Mladen Gogala wrote:

> On Mon, 16 Aug 2004 08:31:17 +1000, Howard J. Rogers wrote:
>

>> Because not all parameters can be modified dynamically with an
>> unqualified 'alter system' command. The SID clause is compulsory, by the
>> way, even in a single instance environment.

Of course. That's why I didn't say the SID was compulsory, but the SID *clause* was. A formulation which, I hope, leaves it open to the reader to supply a valid value for the *clause*, of which "*" is indeed just one.

> Usuually, if the sid is not specified in 'ALTER SYSTEM SET PARAM=VAL
> SCOPE=SPFILE' command, the parameter is written down as '*.PARAM'.

Again, if you miss out the word 'clause', you end up formulating things this way, no doubt.

But in fact the SID clause is *always* specified. It's just that "*" happens to be the default, so if you don't specify it explicitly, you'll still get it supplied 'under the hood'. It amounts to the same outcome I suppose, but I prefer to think in terms of default values for compulsory clauses than to impute some sort of mind-reading to the system -which is what 'if you don't specify, the parameter gets written as ...' sounds like!

Regardless, my original point was that, in the case of resetting a parameter, it is insufficient to rely on the automatic and hidden supply of a default SID clause: the command fails unless you explicitly include the SID clause, even if you then only go on to supply it with its usual default value of "*".

That is, 'alter system reset parameter scope=spfile' will not work. But 'alter system reset exactly_the_same_parameter scope=spfile sid='*'' will.

> What I
> don't understand is why did oracle opt for the shell metacharacter '*'
> instead of the usual relational '%'?

Because, I suppose, the spfile has to be read in order to even get an instance up and running. It's parsed before there is an instance to think relationally.

Regards
HJR Received on Sun Aug 15 2004 - 21:08:43 CDT