Re: ORA-7445 and system completely unavailable
- From: Maureen English <maureen.english@xxxxxxxxxx>
- To: Seth Miller <sethmiller.sm@xxxxxxxxx>
- Date: Fri, 19 Dec 2014 21:48:02 -0900
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:
