No.
Multiple application servers are for redundancy and load balancing at the
ApplicationServer level.
Thus, all 4 application servers do the same job and transactions coming
in to them
are "load balanced' by the application. However, all 4 come in
to the one database.
The idea is to use both nodes of the database server in the same
manner as using
all 4 application server nodes -- concurrently, instead of keeping one
idle.
Hemant
At 07:59 AM 27-11-02 -0800, you wrote:
Couldn't you
partitioned your database to accomplish the same thing and thus still be
application-independent? - costs $$ licensing but ...
-----Original Message-----
From: Hemant K Chitale
[mailto:hkchital@singnet.com.sg]
Sent: Wednesday, November 27, 2002 10:29 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Recipe for application design to run on
RAC
Hmm. Oracle says that with the improved Cache Fusion
in 9i,
any current application can be taken "as is" and
run on 9iRAC.
But yes, you are right. It really depends on the speed
at which
the two instances can share the same block and this can
never
be the same as two sessions accessing the same block in
one
instance [one SGA].
We are currently running and 8.1.5 OPS [ouch !]
environment
and testing 9iR2 RAC. The 8.1.5 OPS runs such that
the
Application Servers [Pro*C servers which get
transactions
from remote devices through a "message bus"] all
connect to
one node and direct PCs using VB/MSQuery connect to the
other.
Time and again I've asked for the PCs also to connect to the
same
node but no ... the effort to update the TNSNAMES.ORA and
ODBC
setup on the PCs would be too much I am told.
In 9iRAC we are testing both BASIC and PRECONNECT Failover
for
TAF and will most certainly be using both nodes of the
cluster for
transactions. Even the Application Servers will be
connecting across
both nodes.
Cross-fingers, touch-wood and wish me luck !
Hemant
At 03:59 PM 26-11-02 -0800, you wrote:
>If two or more RAC instances will be trying to cache the same data
>blocks, then this causes the performance problems that you'll see show
>up as lots of time spent on the event called "global cache cr request".
>If you can partition your application so that RAC nodes don't have to
>share blocks very often through the cache fusion mechanism, then your
>system will scale a lot better.
>
>
>Cary Millsap
>Hotsos Enterprises, Ltd.
>http://www.hotsos.com
>
>Upcoming events:
>- Hotsos Clinic, Dec 9-11 Honolulu
>- Hotsos Clinic 101, Jan 7-9 Knoxville
>- Steve Adams's Miracle Master Class, Jan 13-15 Copenhagen
>- 2003 Hotsos Symposium, Feb 9-12 Dallas
>
>
>-----Original Message-----
>Sent: Tuesday, November 26, 2002 3:34 PM
>To: Multiple recipients of list ORACLE-L
>
>Dear List,
>
>Number of times I've seen that one of prerequsites for
>switching from single node DB to OPS/RAC is to have an
>application specifically designed / architectured to
>run on RAC.
>Can somebody elaborate? Is it something "visible" on
>ERD? That is by looking at the model can RAC guru tell
>that it wouldn't work well on RAC?
>Or put it another way can one conclude based on the
>ERD that app was modeled to run on RAC?
>
>What's the recepie for app design for RAC?
>
>TIA
>
>______________________________________________________________________
>Post your free ad now! http://personals.yahoo.ca
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>--
>Author: Boris Dali
> INET: boris_dali@yahoo.ca
>
>Fat City Network Services -- 858-538-5051 http://www.fatcity.com
>San Diego, California -- Mailing list and web hosting services
>---------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail message
>to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from). You may
>also send the HELP command for other information (like subscribing).
>
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>--
>Author: Cary Millsap
> INET: cary.millsap@hotsos.com
>
>Fat City Network Services -- 858-538-5051 http://www.fatcity.com
>San Diego, California -- Mailing list and web hosting services
>---------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail message
>to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from). You may
>also send the HELP command for other information (like subscribing).
Hemant K Chitale
My web site page is : http://hkchital.tripod.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Hemant K Chitale
INET: hkchital@singnet.com.sg
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Hemant K Chitale
My web site page is :
http://hkchital.tripod.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Hemant K Chitale
INET: hkchital@singnet.com.sg
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Fri Nov 29 2002 - 09:59:00 CST
