RAC, SELECT FOR UPDATE, connection pools

I'm wondering if I could get a little more detail about what Martin listed 
below: 

'"select for update" as soon as a user modified data.  This was in a connection 
pool... That obviously wasn't too great.'

I'm supporting a 10.2.0.2 env on Linux, involving a 4-node RAC with matching 
DG.  It's an OLTP db with app servers using connection pools, where I'll see 
unbalanced batches of connections coming in (2000 on 1 node, 80 on another), 
which eventually even out across the servers.  I also see frequent "SELECT ... 
FOR UPDATE" statements.

I'm relatively new to this env and really struggle in getting details on how 
the apps are working, so when I saw the quote above from Martin I figured I'd 
jump at getting more details on other's experiences with this type of 
situation.  

I think to start I'm just looking for issues you've run into, as again, I get 
very little detail out of the app team in terms of what they're doing and how 
things are configured.

I realize this is really directed towards Martin Bach, but I figured I'd post 
to the group in case anyone has a similar setup.  I'm pretty much having to 
reverse engineer the whole app to know what's going on, which is such a treat. 
:-(

Thx.

Dave Herring  | DBA, Global Technology Services
A c x i o m  C o r p o r a t i o n
630-944-4762 office | 630-430-5988 cell | 630-944-4989 fax
1501 Opus Pl | Downers Grove, IL, 60515 | U.S.A. | www.acxiom.com
Service Desk: 888-243-4566, https://servicedesk.acxiom.com, GSCA@xxxxxxx



-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Martin Bach
Sent: Thursday, February 04, 2010 6:00 AM
To: mwf@xxxxxxxx
Cc: veeeraman@xxxxxxxxx; 'Guillermo Alan Bort'; 'Thomas Roach'; 'ORACLE-L'
Subject: Re: RAC for dev env

I can only second that email from Mark!

Developing against single instance when prod is RAC - I can't count the
number of times I have seen developers code against single instance
Oracle (and maybe even a subset of production data only), release the
new code which then promptly fails to scale/work in RAC?

I dealt with an application development "framework" once that
dynamically changed to "select for update" as soon as a user modified
data. This was in a connection pool... That obviously wasn't too great.

Also don't forget that you might actually _have_ to invoke DR and then
you could be hit big time for not running in a RAC configuration. I only
hope that has been figured into the equation or somebody from high up
acknowledges that.

Regards

Martin
--
Martin Bach
OCM 10g
http://martincarstenbach.wordpress.com
http://www.linkedin.com/in/martincarstenbach


On 02/03/2010 08:44 PM, Mark W. Farnham wrote:
> So I believe your management dictated constraints are: RAC for prod,
> single instance databases for everything else.
> 
>  
--
http://www.freelists.org/webpage/oracle-l


***************************************************************************
The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be legally
privileged.

If the reader of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.

If you have received this communication in error, please resend this
communication to the sender and delete the original message or any copy
of it from your computer system.

Thank You.
****************************************************************************

--
http://www.freelists.org/webpage/oracle-l


Other related posts: