Re: OCF(v2).

On Nov 7, 8:02 pm, "per.lan..._at_fouredge.se" <per.lan..._at_gmail.com> wrote:
> On Nov 6, 4:55 pm, DA Morgan <damor..._at_psoug.org> wrote:
>
>
>
>
>
>
>
> > per.lan..._at_fouredge.se wrote:
> > > On Nov 6, 3:53 am, DA Morgan <damor..._at_psoug.org> wrote:
> > >> per.lan..._at_fouredge.se wrote:
> > >>> On Nov 5, 6:32 pm, DA Morgan <damor..._at_psoug.org> wrote:
> > >>>> per.lan..._at_fouredge.se wrote:
> > >>>>> Hi,
> > >>>>> I need some advise from someone who knows alot about OCF and maybe CFs
> > >>>>> in general..
> > >>>>> Suppose you have two independent (A & B) database nodes share a
> > >>>>> database volume on a CF.
> > >>>>> Is it possible to have the CF queue (FIFO) requests (read / write)
> > >>>>> from either node in order to let them be executed in that order?
> > >>>>> Rgds
> > >>>>> /PL
> > >>>> Please define your terms.
> > >>>> 1. What version of Oracle?
> > >>>> 2. Are you discussing RAC? If not what are you discussing?
> > >>>> 3. If RAC have you read the concepts and architecture docs?
> > >>>> Which ones?
> > >>> Thanks for your reply.
> > >>> 10g, two stand alone DBs (not RAC) + proprietary cluster.
> > >>>> If you want serialization what you are saying is that if node 1
> > >>>> starts something that will take 15 minutes you want node 2 to
> > >>>> freeze. Does this make sense?
> > >>> Well, that's a good to begin with but if that's the starting point we
> > >>> would like to add nifty features such as.
> > >>> i) If a write process has been active for more than x seconds, pass
> > >>> through all read processes in the queue.
> > >>> And with even more intelligence added: ii) Write's could be passed
> > >>> through as well as long as they don't interfere with each other.
> > >>> Rgds
> > >>> /PL
> > >> Two separate 10g instances hitting the same database files without
> > >> the benefit of Oracle clusterware? Have you considered just dropping
> > >> a brick on your foot. Why? My expectation is that you are trying to
> > >> earn pain and will likely get a boatload of it.
>
> > > ((:
> > > Well, it's not easy but if the concept can be proven the idea has alot
> > > of potential.
>
> > > Rgds
>
> > > /PL
>
> > The brick takes less time and anyone that has studied Oracle RAC can
> > predict, with 99.99999999% certainty, the outcome.
>
> > It is one thing to waste time reinventing the wheel.
>
> > Quite another to think throwing yourself off a cliff is a good way to
> > learn to fly.
> > --
> > Daniel A. Morgan
> > University of Washington
> > damor..._at_x.washington.edu (replace x with u to respond)
> > Puget Sound Oracle Users Groupwww.psoug.org
>
> It's kinda obvious you're loyal to Oracle, chill ..

Well, he is but in this case he's got a point, carefully hidden in dramatics, bricks, cleaning consultants and other bungee jumping rubbish. In $2 he gave you there are two cents you may want to think about:
- "When one of your instances locks a table or offlines a tablespace what do you think is going to happen?"
- "You aren't even asking the right questions".

So you have two standalone 10g instances working with the same datafiles? Say, to save on RAC option for EE. Not gonna happen. The problem has nothing to do and can not be solved at a filesystem or clusterware level. You need _instances_ to know about each other and syncronise with each other. They are very complex inside with sequences, caches, logs etc. What you see at CFS level is just a part of what's really going on.

When RAC option is on, oracle _binary_ is different - instances talk to each other via interconnect, use voting disks etc. It's all necessary for a cluster database to work correctly and can't be substituted by serialisation at a datafile level.

Regards,
Igor

> Rgds
>
> /PL
Received on Wed Nov 07 2007 - 19:31:34 CST