Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: trivial pursuit - filesystemio_options
On Sat, 20 Mar 2004 17:19:19 GMT, "Anurag Varma" <avdbi_at_hotmail.com>
wrote:
>
>"Ed Stevens" <nospam_at_noway.nohow> wrote in message
>news:euom501jfnc6fuvjrtdidf4hmnsplgvv1c_at_4ax.com...
>> Platform Ora 9.2.0.1 on Solaris 8
>>
>> While doing some sanity check comparisions between two db's, I
>> discovered an oddity, a puzzler, a question, a head-scratcher . .
>>
>> In the following two queries, the two databases are on the same
>> server, under the same Oracle home, and the parameter
>> filesystemio_options is *NOT* explicitly set in the init.ora file of
>> either database. There is no spfile. So, two db's on the same server,
>> under the same Oracle Home, in both cases the parm says it is at
>> default value, but the actual value is different. Further, one of
>> them has a value that -- from what I read in the docs -- is not a
>> valid option for that parm.
>>
>>
>>
>> sql> connect system_at_cmdm1240
>> Enter password:
>> Connected.
>> sql> select value, isdefault from v$parameter where name =
>> 'filesystemio_options';
>>
>> VALUE
>> ------------------------------------------------------------------------------
>> --------------------
>> ISDEFAULT
>> ---------
>> asynch
>> TRUE
>>
>>
>> sql>
>> sql> connect system_at_cmqm1240
>> Enter password:
>> Connected.
>> sql> select value, isdefault from v$parameter where name =
>> 'filesystemio_options';
>>
>> VALUE
>> ------------------------------------------------------------------------------
>> --------------------
>> ISDEFAULT
>> ---------
>> asynchrval=99999999
>> lo
>> TRUE
>>
>>
>> sql>
>
>
>I remember running into the same exact problem. Oracle Support had no clue how that value could have
>been set.
>But basically they told me to do an alter system set filesystemio_options=asynch;
>to fix it.
>
>.. and that fixed the value.
>I cannot however explain how that value could have been set other than attributing it to some kind
>of memory corruption.
>The wrong value also did not seem to have any adverse affect on the system.
>
>
>HTH
>Anurag
>
Thanks. I'm glad someone else has seen this -- that I'm not going
totally bonkers!
Received on Tue Mar 23 2004 - 07:36:31 CST