Thanks, Raj.
--- "Jamadagni, Rajendra"
<[EMAIL PROTECTED]> wrote: > Boris,
>
> the example I gave you is 9012 RAC and I have 5
> other production systems
> that are 9202 RAC. BTW remember if you have
> cluster_database is true, then
> no matter how many instances, you will see GC
> traffic and
Thanks a lot, Tim. Enjoyable reading. Much
appreciated.
Just to clarify what data modeling vendor might mean
by "RAC-aware" model:
In one of the draft suggestions they had "activity"
class tables that would record all major steps in the
system like registration, signing a contract,
inventory repl
Hey Tim... In case we haven't said it lately, we appreciate all the effort
you put forth on the list... This is a fantastic thread...
Thanks again
Tim
-Original Message-
Sent: Wednesday, December 04, 2002 11:34 PM
To: Multiple recipients of list ORACLE-L
comments inline...
- Orig
Title: RE: Recipe for application design to run on RAC
Boris,
the example I gave you is 9012 RAC and I have 5 other production systems that are 9202 RAC. BTW remember if you have cluster_database is true, then no matter how many instances, you will see GC traffic and boy those numbers are
comments inline...
- Original Message -
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Wednesday, December 04, 2002 8:53 AM
> Whoa! Tim, thanks a lot for sharing this. Quite an
> insight.
>
> So SELECTs are not a concern.
>
Well, not directly. They do not directly
Thanks, Raj.
>> H... it is probably not an good example ...
Why not? On the contrary. I am sure damanagement here
would love to here this. Besides it fully supports
Oracle's statement that application can be migrated to
RAC "as is" (as I think Hemant mentioned).
Wait... did you say 9i? releas
Dennis, I hate to see do all this jumping up and down
but the dynamic re-mastering feature was not
implemented in 9i.
There is a view called V$GCSPFMASTER_INFO that is
supposed to show which node was the master, which node
is currently the master and how many times the
resource has been re-master
Title: RE: Recipe for application design to run on RAC
Greg,
FantasyFootball is a different beast and is not hosted on this database. This one deals with live scores and the bottomline ... .
There are only few tables that are shared by both schema, 50% ownership .. hasn't happened ye
I know I know (he says jumping up and down) Just did the 9i New Features
class.
The answer is "lazy dynamic remastering". Over time, resources are gradually
moved to the instance that is using them.
More quotes from the manual:
Should an instance leave the group, the background processes onl
Title: RE: Recipe for application design to run on RAC
So
when I access the fantasy football league on the espn web site-I go to schema2
because my team(s) are losing :-)
I guess thats what I get when I picked a group of guys
that are all on the injured reserve
Seriously though
Title: RE: Recipe for application design to run on RAC
H... it is probably not an good example but we too have a (couple of) mission critical app (affects on air production) running on 9i RAC. One of which has two major schema. We logically partitioned the application such that, for two
Whoa! Tim, thanks a lot for sharing this. Quite an
insight.
So SELECTs are not a concern. INSERTs are a "come and
see DBA" thing (physical design issue).
DELETEs are relatively infrequent and many get
translated into UPDATE (logical as opposed to physical
delete).
Application "partitioning" as yo
To be more precise, the real problems in application-partitioning for
OPS/RAC are UPDATE, SELECT ... FOR UPDATE, and DELETE statements due to
their WHERE clauses...
A SELECT statement does not force exclusive access to a database block and
so does not directly cause contention for a block in OPS/R
International, Sussex, WI USA
> -Original Message-
> From: Hemant K Chitale [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 29, 2002 9:54 AM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Recipe for application design to run on RAC
>
>
>
> No one her
endent? - costs $$ licensing but ...
-Original Message-
From: Hemant K Chitale
[mailto:[EMAIL PROTECTED]]
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 improv
7/2002 07:28 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
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
st ORACLE-L <[EMAIL PROTECTED]>
cc:
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 depend
Title: RE: Recipe for application design to run on RAC
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:[EMAIL PROTECTED]]
Sent: Wedn
Thanks for taking time to reply, Cary. Much
appreciated.
Did I understand it correctly that in active/active
setup it would be beneficial to give each node "it's
own virtual empire" so to speak.
Like one node to service say marketing and sales,
while the other to deal with say inventory and
autom
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
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 o
21 matches
Mail list logo
