Re: ORA-600 after July PSU apply -- production down.

Hi Ian,

Yes, we run ASM in all our environments. They are also all on the same patch versions, so that can be excluded. The only difference is the problem box is an ODA, the others are HP Proliants and ExaData. I tend to blaming ODA - any patching session on the PoS so far has included several sev1 SRs. It's hardly normal...

Next year it will be replaced with another ExaData - can't wait!

Cheers,
Tony

On 25/08/17 03:33, MacGregor, Ian A. wrote:
> I was curious and ran
>
> oracle_at_fermi-oracle02 $ find ./ -name "kgfm*” the top directory was $ORACLE_HOME
>
> a typical response was
>
> ./.patch_storage/18522509_Jun_30_2014_08_14_42/files/lib/libasmclntsh11.a/kgfm.o
>
> This on a server with internal disks and not using ASM so there is no GI applied. It seems the problem may lie
> with ASM. Do the servers which did not fail also use ASM.
>
> Ian MacGregor
> SLAC National Accelerator Laboratory
>
>
>> On Aug 24, 2017, at 8:32 AM, De DBA <dedba_at_tpg.com.au <mailto:dedba_at_tpg.com.au>> wrote:
>>
>> Even starting in nomount mode gives ORA-600.
>>
>> I just attempted to create a dummy instance with a init.ora file with only 1 line in it (db_name = ORCL) - no ASM, no spfile in play. Starting that also failed with the same ORA-600 [kgfmGetCtx0].
>>
>> Cheers,
>> Tony
>>
>> On 25/08/17 01:11, Powell, Mark wrote:
>>> >> ORA-01078: failure in processing system parameters <<
>>>
>>> Have you in fact verified that your spfile parameters are in fact valid? Startup nomount and full the spfile into a pfile then review it carefully.
>>>
>>>
>>> Mark Powell
>>> Database Administration
>>> (313) 592-5148
>>>
>>>
>>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>> *From:*oracle-l-bounce_at_freelists.org<oracle-l-bounce_at_freelists.org>on behalf of De DBA<dedba_at_tpg.com.au>
>>> *Sent:*Thursday, August 24, 2017 10:51:24 AM
>>> *To:*oracle-l_at_freelists.org
>>> *Subject:*ORA-600 after July PSU apply -- production down.
>>> HI,
>>> I've tonight applied the July PSU to the last environment - production. All other environments, including DR, went swimmingly, but after applying the patches when I tried to startup upgrade to apply the in-database part, I was regaled with the following fine errors on both nodes:
>>> 00:28:52 [25-AUG-17][SYS_at_MyProd]$ startup upgrade
>>> ORA-01078: failure in processing system parameters
>>> ORA-00600: internal error code, arguments: [kgfmGetCtx0], [kgfm.c], [2840], [ctx], [], [], [], [], [], [], [], []
>>> The parameter files of course do still exist. The MOS lookup tool has no information and my 24/7 db is down. Any clues?
>>>
>>> I've already attempted to roll-back the OCW part, but that had no effect. Although now opatch lsinventory no longer lists the original version of that patch (11.2.0.4.5) either.
>>>
>>> Environment:
>>> ODA X4-2
>>> RDBMS 11.2.0.4
>>> ASM 12.1.0.2
>>> Database PSU 11.2.0.4.170718
>>> OCW PSU - no longer shown
>>> OVJM PSU11.2.0.4.170718
>>> Thanks,
>>> Tony
>>
>>
>

--
http://www.freelists.org/webpage/oracle-l