Re: New behavior in 11g?
- From: David Ramírez Reyes <dramirezr@xxxxxxxxx>
- To: Maureen English <maureen.english@xxxxxxxxxx>
- Date: Fri, 29 Nov 2013 08:23:33 -0600
Interesting problem, am having the same (with less impact) on our db
migrated to 11g (we were on 8i, -don't ask why-).
Please let me know if you find something on that side.
Regards
David Ramírez Reyes
Profesión: Padre de Familia
On 28 November 2013 16:37, Maureen English <maureen.english@xxxxxxxxxx>wrote:
> Phillip,
>
> Yes, there definitely is a firewall between the app server and the
> database server. I thought it was
> the same firewall as is between the app server and the old database
> server, but that may not be
> true. Or, the rules may not be the same...or....
>
> I didn't think of this as possibly being a firewall issue, but now that
> you mention it, we also use
> IP tables on the new database server. Even though we did the same on the
> old database server,
> this one could easily be set up differently.
>
> Thanks! Now I have another direction I can go for troubleshooting this
> problem.
>
> - Maureen
>
>
> On Thu, Nov 28, 2013 at 10:32 AM, Phillip Jones <phil@xxxxxxxxxx> wrote:
>
>> Hi,
>>
>> 'LOGOFF BY CLEANUP' occurs when a session hasn't explicitly closed the
>> connection & Oracle has to clean the session up itself.
>>
>> Sounds like your new server is behind a firewall that drops connections
>> after 2 hours, causing the above. Talk to your network admins and ask what
>> network hardware is between the app and database server.
>>
>> Thanks,
>>
>> Phil
>>
>>
>> On Thu, Nov 28, 2013 at 7:19 PM, Maureen English <
>> maureen.english@xxxxxxxxxx> wrote:
>>
>>> We have an application that has been using a 10g database for years. We
>>> just
>>> created a new 11.2.0.4 RAC database on a new RHEL5 Linux server.
>>>
>>> The audit trail, however, shows the last
>>> entry for that user as doing a 'LOGOFF BY CLEANUP'. I'm 95% sure that
>>> there had
>>> been no communication between the application and the database for this
>>> user for
>>> the 2 hours before it disappeared...I was monitoring netstat output and
>>> the audit trail.
>>>
>>> I'm also sure that this is related to either some kind of timeout on the
>>> new database
>>> server, or some kind of timeout in the database. IDLE_TIME for the
>>> profile is set to
>>> UNLIMITED, so it's not that. No alert log info and no trace file info
>>> to show anything
>>> is wrong.
>>>
>>> It really looks like something is killing the Oracle process, but I
>>> don't know where
>>> else to look. Is there some kind of system parameter that may have been
>>> set that
>>> kills processes that are essentially inactive?
>>>
>>> - Maureen
>>>
>>>
>>
>
Other related posts:
