| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: RAC nodes
We managed to drive a interplanetary probe pretty deep into the surface of
Mars over much the same issue: A few hundred yards, a few hundred km. What's
the difference. Oh. K. 1000 meters. Ouch.
So 10K is about 6.2 miles and 300K therefore about 186 miles. (Please don't fly a plane by these approximations).
I'm still trying to figure out the proposed purpose of such widespread clustering. Without the details of the opertational characteristics you are trying to achieve, it is very difficult to give meaningful advice.
Certainly latency of writes to remote plexes of at least the on-line logs are one consideration. (Think mirror for plexes if you must.) If you're trying to establish an environment that continues running during a site disaster at the location of one of the nodes, then clearly the disks must be plexed remotely. For that purpose, it is usually much more cost effective to use one of the variety of technologies that provides a standby, if the service level can tolerate a non-zero possibility of losing a small amount of transactions that fail to get transmitted (unswitched log, unsent archive, unmined log "tailing", or whatever you're using.) That is indeed a distinct difference from remote plexing that refuses to answer "write complete" to the log writer until all the plexes are written. Anything less than that is essentially the same fuzzy completeness issue. (See Bertrand Russell regarding dickering over the price.) Analyzing the operational fallout from the difference and when it might make a meaningful difference in laboratory or business continuation can be quite interesting.
I'd go out on a limb here and guess the purpose of the geo-dispersed grid is *NOT* thoughput scaling. If it is, I think folks have already opined on latency issues.
Another purpose I've seen proposed is following the time zones with locality of service. In this topology (so far theoretical as far as I know), only one location is actively pursuing transactions at a time, with delayed writing to all but one set of remote plexes of the disk farm. Phasing from one center to another would involve a certain quiescence to migrate which plex (locality) requires guaranteed writing. This is merely a logout/login problem for interactive users, but becomes more interesting for batch jobs depending on job start time and job length variability. Batch jobs ever significantly longer than a workshift for a zone become problematic.
Now if you're at the level of a "cache fusion" implementation (ie. not old OPS with disk block pinging for coherency), then I suppose it might not be too much of a stretch for Oracle to implement a switch on an instance that says "I'm not writing" that would funnel all its dirty disk blocks to one of the instances that is "writing." This might even be an optimization compared to some implementations of shared disk. On-line logs might be logically separate regarding "writeability" so that transactions could be recorded locally with only a promise of remote readability later to recover a failed instance. This would essentially put the network throughput and latency issues all on memory-to-memory operations, where at least the answer back latency working on the remote mode should be less variable. I don't believe these capabilities exist at the moment, however. (Please someone point me at the manual section if I missed it.) This topology in theory supports adding nodes to a grid without true real time disk sharing. Don't hold your breath, but I think that would move us signficantly along the line of adding nodes dynamically to handle peaks on systems based on different databases, while also improving the feasibility of wide node dispersal.
regards,
mwf
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Pete Sharman
Sent: Thursday, July 15, 2004 5:45 PM
To: oracle-l_at_freelists.org
Cc: Peter Ross Sharman
Subject: RE: RAC nodes
Then your rep needs more knowledge. RAC works with geoclusters as well. D= epending on the clustering technology, clusters can now have nodes 10's of = kilometres apart. I know some of my colleagues got it to work on two lapto= ps separated by 300 km or so in England using the internal Oracle network. =Obviously not a production configuration though! :)
=
Pete
=
"Controlling developers is like herding cats."
Kevin Loney, Oracle DBA Handbook
=
"Oh no, it's not. It's much harder than that!" Bruce Pihlamae, long-term Oracle DBA
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] =
On Behalf Of Mercadante, Thomas F
Sent: Friday, 16 July 2004 3:32 AM
To: 'oracle-l_at_freelists.org'
Subject: RE: RAC nodes
Carol,
One of the biggest challenges you are going to have is, as someone else mentioned, sharing disk over the large geographical location. Last I spoke=
with an Oracle rep, this had only been done over a short distance - like a couple of hundred yards. Seems unbelievable to me that this *can't* be done, but it's what I've been told.
So someone in your organization needs to solve that problem first. If it does not exist, then you are stuck with either replication, or one database=
server shared by all.
Tom Mercadante
Oracle Certified Professional
-----Original Message-----
From: Carol Legros [mailto:clegros_at_orsis.ca] =
Sent: Thursday, July 15, 2004 2:24 PM
To: oracle-l_at_freelists.org
Subject: Re: RAC nodes
Raj,
I recently spoke with someone that is considering putting in RAC in this =
configuration.
We don't know of anyone that *has* done this, and on the flip side, we =
couldn't think of any other
reasons this solution might be problematic except for the network.
I'd like to hear about similar RAC experiences (servers split over =
geographic locations)
from others on the list if they have tried it. =
Carol
Raj Jamadagni wrote:
>Other than network latency and other outages, what more do you _want_ =
>??
>
>Raj
>
>--- Carol Legros <clegros_at_orsis.ca> wrote:
> =
>
>>I'm wondering if anyone out there that is using RAC has set up their =
>>nodes such that half of the nodes reside in one geographic location =
>>and the other half of their nodes in another geographic location (ie =
>>100 miles away).
>>
>>I can envision possible issues with network latency or outages, but =
>>I'm
>>wondering
>>what other problems/issues others may have found if/when they tried such =
a
>>configuration.
>>
>>Cheers
>>Carol
>>
>>
>>
>>
>>
>>----------------------------------------------------------------
>>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>>----------------------------------------------------------------
>>To unsubscribe send email to: oracle-l-request_at_freelists.org put =
>>'unsubscribe' in the subject line.
>>--
>>Archives are at http://www.freelists.org/archives/oracle-l/
>>FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
>>-----------------------------------------------------------------
>>
>> =
>>
>
>
>=3D=3D=3D=3D=3D
>Best Regards
>Raj
>---------------------------------------------------------
>select mandatory_disclaimer from company_requirements;
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com =
>----------------------------------------------------------------
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>----------------------------------------------------------------
>To unsubscribe send email to: oracle-l-request_at_freelists.org
>put 'unsubscribe' in the subject line.
>--
>Archives are at http://www.freelists.org/archives/oracle-l/
>FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
>-----------------------------------------------------------------
>
> =
>
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Fri Jul 16 2004 - 07:12:55 CDT
 |
 |