What exactly does the user who is hitting the 'button'
experience...slownes, unresponsive server. Here is how I would start off
with it :
- enable 10046 at level 12 and connect using the tnsnames entry for node
1. Perform the task and logoff
- next enable 10046 at level 12 and use the tnsnames entry (the load
balanced one).
You would be better off with if you can reproduce the behaviour in
SQL*Plus...atleast aids in debugging.
Thanks, -Sudhi.
Obviously ... we got some experience with RAC, been running since 901 (well in those days it was more like trying to run). The tnsnames is configured correctly.
There are no errors, but the process which inserts and selects again (apprently in same session) to retrieve a schedule id, get no data back (no_data_found). You attempt it again, it works fine. But that isn't expected. for the heck we had them introduce a 0.3 (random draw from hat) second delay between select and subsequent insert. It worked. But introducing delay isn't favored. middle tier (m-queue) had 10 sessions to the db when it starts connected to both sides, java app uses one of these 10 sessions to do its work.
Raj
On 7/27/05, *Anand Rao* <panandrao@xxxxxxxxx <mailto:panandrao@xxxxxxxxx>> wrote:
Have you ever thought of something called tnsnames.ora?
have you configured it on the client and server side for a RAC database as opposed to a single instance?
>But that ain't the case when it connects user@database (i.e. no specific node is >specified, tns entry is load balanced, failover).
what do you mean? do you get any error messages?
anand
