Re: ORA-7445 and system completely unavailable
- From: Karth Panchan <keyantech@xxxxxxxxx>
- To: "maureen.english@xxxxxxxxxx" <maureen.english@xxxxxxxxxx>
- Date: Sat, 20 Dec 2014 14:28:09 +0530
What version oracle this issue?
We are facing this error in our production Oracle 11.2.0.2 in RAC causing
instance can crash.
This was causing by WITH statement.
Working with Oracle as they acknowledge there is bug with cursor sharing =
force in WITH statement in 11.2.0.2
Karth
Sent from my IPhone
> On Dec 20, 2014, at 12:18 PM, Maureen English <maureen.english@xxxxxxxxxx>
> wrote:
>
> Yes, I believe that was the case.
>
> After more research, it appears that the root cause may have been that one
> programmer was changing a package while another one
> was running utlrp. They normally don't have 2 people making changes at the
> same time....
>
> - Maureen
>
>
>> On Fri, Dec 19, 2014 at 12:25 PM, Seth Miller <sethmiller.sm@xxxxxxxxx>
>> wrote:
>> I assume this is the problem to which you are referring since the ORA-7445
>> was merely a symptom or result.
>>
>> "We allow programmers to do what we call migrations in the production
>> database"
>>
>> Seth Miller
>>
>>> On Fri, Dec 19, 2014 at 2:57 PM, Maureen English
>>> <maureen.english@xxxxxxxxxx> wrote:
>>> So, we think we found what might have been the problem...any comments are
>>> welcome!
>>>
>>> We allow programmers to do what we call migrations in the production
>>> database on Fridays.
>>> Migrations consist of things like modifying packages, adding columns to
>>> tables and apparently
>>> also changing the size of a column in a table. This is all while the
>>> database is up and
>>> available to users.
>>>
>>> After a programmer does a migration, he/she runs utlrp to recompile invalid
>>> objects.
>>>
>>> Normally, these migrations are done sequentially so only one person is
>>> running utlrp at a time.
>>>
>>> Today, it seems that 2 programmers were doing migrations at the same time.
>>> One of them
>>> was changing the size of 5 columns in a table that was likely being used at
>>> the time of the
>>> change. It also looks like they may both have been running utlrp at the
>>> same time.
>>>
>>> That said, we crashed the database since we couldn't even log in as sysdba
>>> to shut it down.
>>> Then we brought it up in restricted session, let the dust settle, shut it
>>> down and brought it
>>> up in restricted session again to verify that all was well, did some
>>> checking around and then
>>> restarted it normally. Things seem to be fine....
>>>
>>> - Maureen
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> On Fri, Dec 19, 2014 at 10:29 AM, Niall Litchfield
>>>> <niall.litchfield@xxxxxxxxx> wrote:
>>>> I don't believe that the most helpful advice ever. 7445 is indeed O/S
>>>> level code vs 600 which is db level code. Doesn't mean client. Does mean
>>>> call support. MOS also has a 00600/07445 troubleshooting tool which will
>>>> analyze the dump generated.
>>>>
>>>> This is a support better than the internet case.
>>>>
>>>>> On 19 Dec 2014 18:08, "Howard Latham" <howard.latham@xxxxxxxxx> wrote:
>>>>> I Done a google search - expect you did too but just in case - Good luck.
>>>>> Hi,
>>>>>
>>>>> ORA-07445 is mostly caused by the Incompatible oracle client making
>>>>> connection or trying to execute complex code causing huge memory dump.
>>>>> Search for "machine" in the trace file reported in the alert log to
>>>>> identify the user or application server & verify its client version
>>>>> compatibility with your newly patched RDBMS version
>>>>>
>>>>> Thanks,
>>>>> Ajay More
>>>>> http://moreajays.blogspot.com
>>>>>
>>>>>
>>>>> On 19 December 2014 at 18:01, Maureen English
>>>>> <maureen.english@xxxxxxxxxx> wrote:
>>>>> > Our prod system just became completely unavailable and we're getting
>>>>> > these
>>>>> > errors in the
>>>>> > alert log:
>>>>> >
>>>>> > Exception [type: SIGSEGV, Invalid Permissions for object] [ADDR:0x0]
>>>>> > [PC:0x4000000005CA0E20, $cold_kpkiiniPG()+16] [flags: 0x0, count: 1]
>>>>> >
>>>>> > Any ideas...yes we have a sev 1 ticket in with Oracle.
>>>>> >
>>>>> > - Maureen
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Howard A. Latham
>>>>> --
>>>>> //www.freelists.org/webpage/oracle-l
>
Other related posts:
