Quarkman <quarkman_at_myrealbox.com> wrote in message news:<oprsr56csfr9lm4d_at_haydn>...
> On 23 Jul 2003 11:28:05 -0700, JEDIDIAH <jedithezealot_at_yahoo.com> wrote:
>
> > Quarkman <quarkman_at_myrealbox.com> wrote in message
> > news:<oprsqa790tr9lm4d_at_haydn>...
> >> On Tue, 22 Jul 2003 15:01:10 -0400, Ryan <rgaffuri_at_cox.net> wrote:
> >>
> >> > why would implementing RAC increase I/O? is that because of the 2
> phase
> >> > commit? So you have to write to multiple datafiles?
> >>
> >> No.
> >>
> >> It may increase I/O for a number of reasons. A buffer in Instance A may
> >> have to be flushed for no other reason than Instance B has a past image
> >> of that buffer, and *it* needs to over-write its contents. The problem
> >> of forced disk writes (one instance making another instance do some I/O
> >> it wouldn't necessarily want to do on its own) has not been abolished in
> >> RAC (but it's better than it was in OPS).
> >>
> >> Secondly, the interconnect is not of infinite bandwidth, therefore
> >> reserving it for the transport of buffers which really, really need to
> >> be shipped to other instances in the shortest possible time may be quite
> >> important. Therefore, you use GC_FILES_TO_LOCKS to switch off cache
> >> fusion
> >
> > Can you elaborate on this please for those of us that have only
> > experienced RAC as spectators? Can you provide some meaningful
> > examples?
> >
> > [deletia]
> >
>
>
> Elaborate on what bit? The interconnect being a bottleneck? Or using
> GC_FILES_TO_LOCKS to switch off cache fusion? Or forced disk writes?
>
> I'm not sure what would qualify as a meaningful example, either!
GC_FILES_TO_LOCKS
How could someone use this parameter to their benefit? How have you used
this parameter to your benefit?
Received on Thu Jul 24 2003 - 14:46:13 CDT
