| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: SQL*Net problem on production
The Oracle Apps concurrent manager stays connected for weeks/months at a
time, polling the FND_CONCURRENT_REQUESTS table for instructions to do
work, and then of course executing that work when requested.
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
* Nullius in verba *
Upcoming events:
- Performance Diagnosis 101: 3/23 Park City, 4/6 Seattle - Hotsos Symposium 2004: March 7-10 Dallas - Visit www.hotsos.com for schedule details...
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Ron Rogers
Sent: Friday, March 12, 2004 2:26 PM
To: oracle-l_at_freelists.org
Subject: Re: SQL*Net problem on production
Mike,
The tnsnames.ora like the lsnrctl only effects new connections. You
can change the tnsnames.ora and stop the listener and the connected
operations continue. What kind of connections remain up for 2 weeks
making reports?
That must be a long report. The users didn't realize that the response
or data was different? maybe you don't need the original server.
Ron
>>> HANDM_at_polaroid.com 03/12/2004 3:02:22 PM >>>
For those still using Sqlnet, will a change to the tnsnames.ora file be automatically used for any subsequent connections? The problem is our tnsnames file was overwritten in production. The new file was pointing to our reporting instance. I saw at least 24 connections to the reporting IP address that go back 2 weeks, and I dread breaking the bad news to our user community :(
Mike Hand
--
This transmission is intended only for use by the addressee(s) named
herein and may contain information that is proprietary, confidential
and/or legally privileged. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or use
of the information contained herein (including any reliance thereon) is
STRICTLY PROHIBITED. If you received this transmission in error, please
immediately contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.htmlput 'unsubscribe' in the subject line.
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request_at_freelists.org
 |
 |