Gerald Sinkiewicz wrote:
> "DA Morgan" <damorgan_at_psoug.org> wrote in message
> news:1183301755.616247_at_bubbleator.drizzle.com...
>> Gerald Sinkiewicz wrote:
>>> "DA Morgan" <damorgan_at_psoug.org> wrote in message
>>> news:1183262863.121832_at_bubbleator.drizzle.com...
>>>> Gerald Sinkiewicz wrote:
>>>>
>>>>> The ORA-01115 references file 10. I cannot post file names.
>>>>> Ah, I did misspell "owner" and there are other messages related to the
>>>>> ORA-01115 that really just say Oracle could not read a certain block in
>>>>> file 10....
>>>> That is an entirely different matter that has nothing to do with what
>>>> you sent the storage admins chasing ... stop them.
>>>>
>>>> Oracle error messages are intended to be handled in a specific manner as
>>>> befits an enterprise database. First you go to
>>>> http://metalink.oracle.com and determine an appropriate actions plan:
>>>> Then you act precisely as instructed. What you appear to have done is
>>>> a guaranteed recipe for disaster ... not understand the message, not
>>>> research the message ... and start doing stuff hoping something will
>>>> fix it.
>>>>
>>>> So lets get back to basics ...
>>>>
>>>> Oracle can not read one or more specific blocks of a specific data file.
>>>> This is an indication of a specific problem with a specific solution.
>>>> Which blocks? In which tablespace? Being used by which objects? What
>>>> version of Oracle do you have and have you, as you should have, taken
>>>> backups with RMAN? If so what backups do you have, how were they taken,
>>>> and specifically what actions, if any, have been taken since the problem
>>>> was first discovered.
>>>>
>>>> While you are contemplating the above run an RDA and open an SR.
>>>> --
>>>> Daniel A. Morgan
>>>> University of Washington
>>>> damorgan_at_x.washington.edu (replace x with u to respond)
>>>> Puget Sound Oracle Users Group
>>>> www.psoug.org
>>> Of course, I did go to metalink, which directs me to see the storage
>>> guys.
>>> Since the errors of 6/27 the problem has gone away, that is the
>>> application is no longer getting the error.
>>> I have dbv'd the files in question and my backups are also verified and
>>> do not point to a problem.
>>> The problem is intermittent, which is one reason metalink sends me to the
>>> guys with the McData's.
>>>
>>> If the problem had shown up in my alert log I would have been able to
>>> submit an SR to oracle, but since it is
>>> in application logs that I cannot see, there is not much I can send in
>>> with the SR for oracle to look at other than
>>> an RDA. I really think the SAN guys need to chase something here because
>>> there is a history in errpt of SAN
>>> disk errors. It is possible the McData switch has intermittent problems,
>>> that could cause some strange errors, like
>>> this one. It is also possible there is a server problem I suppose, like
>>> memory, that could mess up a bit and cause
>>> a strange error. The only thing I am sure of is file 10 is not corrupt
>>> :-).
>>>
>>> But are there any references for "RISC System/6000 Error:1: Not owner"? I
>>> did request the system admins to
>>> contact IBM about the meaning, but have not heard a word, yet.
>> Given the clarification ... I'd be looking at hard disk controller cards
>> on the server and related hardware infrastructure on the SAN. Something
>> may be getting prepared to die.
>> --
>> Daniel A. Morgan
>> University of Washington
>> damorgan_at_x.washington.edu (replace x with u to respond)
>> Puget Sound Oracle Users Group
>> www.psoug.org
>
> I will agree with that, this box has not been well.
> In the recent past this box has died at least once (bad power supply is what
> IBM said)
> and hung a couple of times (once running out of pagefile space).
If it is under warranty ... send it back.
--
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
Received on Mon Jul 02 2007 - 02:08:36 CDT
