Sorry to press, but do you know if they had evaluated Data Guard or Golden Gate at all? Did they really make such a decision based on a single piece of sales collateral?
I'm always shocked at how Oracle Corporation (and other vendors) will publish a white paper such as this, including a section on the "benefits of <http://www.oracle.com/technetwork/products/clustering/overview/extendedracversion11-435972.pdf#page=6&zoom=auto,93,519>" without a balancing (and glaringly absent) "disadvantages of" section, which might include helpful cross-references to Oracle products Data Guard or Golden Gate. While there is brief passing mention of Data Guard in this paper, there is not a breath about Golden Gate. A "disadvantages of" section would have been the ideal way to steer customers for whom "extended RAC clusters" were not well-suited toward Data Guard or Golden Gate, both which are proven and widely implemented, which "extended clusters" are not.
The presence of only positive information about a product without any negative information ipso facto makes it a sales document, and worthless as a technical source.
On 4/16/2014 11:30 AM, Iggy Fernandez wrote:
Hi, Tim,The customer bought the story (in the Extended RAC white paper) that Extended RAC provides some measure of Disaster Recovery (with the emphasis on some). The white paper is at http://www.oracle.com/technetwork/products/clustering/overview/extendedracversion11-435972.pdf."Unlike classic Oracle RAC implementations, which are primarily designed as scalability and high availability solution that resides in a single data center, it is possible – under certain circumstances – to build and deploy an Oracle RAC system in which the nodes are separated by greater distances. For example, if a customer has a corporate campus, they might want to place the individual Oracle RAC nodes in separate buildings. This configuration provides a higher degree of disaster tolerance, in addition to the normal Oracle RAC high availability, since a fire in one building would not, if properly set up, stop the database from processing. Similar, many customers have two data centers in reasonable proximity (<100km) which are already connected by a direct, ideally non-routed, high speed link(s) and are often on different power grids, flood plains, and the like.""Oracle RAC on Extended Distance Clusters does not constitute a different type of cluster, neither is there a special installation option that one can choose from. This means that as far as the configuration of the system is concerned, the main goal is to hide the fact that Oracle RAC is now operating over distance. On the other hand, this means that the basic configuration remains the same, including its requirements. Attention must be paid when configuring the network and storage connectivity for Extended Distance Oracle RAC environments."Iggy -- Iggy Fernandez Email: iggy_fernandez@xxxxxxxxxxx <mailto:iggy_fernandez@xxxxxxxxxxx> Cellphone: (925) 478 3161Blog: So Many Manuals So Little Time <http://iggyfernandez.wordpress.com/> Author of Beginning Oracle Database 11/g/ Administration <http://books.google.com/books?id=pdSLnG66WQkC&printsec=frontcover#v=onepage&q&f=false>Editor of the /NoCOUG Journal <http://bit.ly/rC2gRA>/Lecturer at University of Washington Professional and Continuing Education <http://www.pce.uw.edu/biography/ignatius-fernandez/>------------------------------------------------------------------------ Date: Wed, 16 Apr 2014 09:36:25 -0600 From: tim@xxxxxxxxx To: oracle-l@xxxxxxxxxxxxx Subject: Re: Extended RAC and multicast Iggy,Not to open any cans of worms (and please feel free to not answer this question for any reason), but why did they choose an "extended RAC" deployment in the first place, as opposed to any of the Data Guard options? Do they already use Data Guard? Was there something that "extended RAC" (or "geographically-dispersed cluster" technology) does better than Data Guard (or database replication technology) in general?Just curious... Thanks! -Tim On 4/16/2014 9:21 AM, Iggy Fernandez wrote: Thank you very much Martin. We found additional information on the multicast requirement at the following link: http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/UCS_CVDs/cisco_ucs_oracle_rac.html#wp439295 Kindest regards, Iggy-- Iggy FernandezEmail: iggy_fernandez@xxxxxxxxxxx <mailto:iggy_fernandez@xxxxxxxxxxx> Cellphone: (925) 478 3161 Blog: So Many Manuals So Little Time <http://iggyfernandez.wordpress.com/> Author of Beginning Oracle Database 11/g/ Administration <http://books.google.com/books?id=pdSLnG66WQkC&printsec=frontcover#v=onepage&q&f=false> Editor of the /NoCOUG Journal <http://bit.ly/rC2gRA>/ Lecturer at University of Washington Professional and Continuing Education <http://www.pce.uw.edu/biography/ignatius-fernandez/> ------------------------------------------------------------------------ From: martin.a.berger@xxxxxxxxx <mailto:martin.a.berger@xxxxxxxxx> Date: Mon, 14 Apr 2014 20:46:39 +0200 Subject: Re: FW: Extended RAC and multicast To: iggy_fernandez@xxxxxxxxxxx <mailto:iggy_fernandez@xxxxxxxxxxx> CC: oracle-l@xxxxxxxxxxxxx <mailto:oracle-l@xxxxxxxxxxxxx>; kulkarniravi@xxxxxxxxx <mailto:kulkarniravi@xxxxxxxxx> Iggy, Ravi, from all my test I call multicast a requirement from 11.2.0.2 onwards. Take care about the different Multicast networks possible in different Patch-Sets! As you are talking about VLAN_S_ - I'd not do anything than pure switched private network. Everything else will lead to troubles sooner or later. My .02€ Martin On Mon, Apr 14, 2014 at 8:29 PM, Iggy Fernandez <iggy_fernandez@xxxxxxxxxxx <mailto:iggy_fernandez@xxxxxxxxxxx>> wrote: A friend asked me a question that I could not answer. He is in the planning stages of an "extended RAC deployment" and is looking for confirmation that multicasting is optional. Help would be appreciated. Kindest regards, Iggy-- Iggy FernandezEmail: iggy_fernandez@xxxxxxxxxxx <mailto:iggy_fernandez@xxxxxxxxxxx> Cellphone: (925) 478 3161 Blog: So Many Manuals So Little Time <http://iggyfernandez.wordpress.com/> Author of Beginning Oracle Database 11/g/ Administration <http://books.google.com/books?id=pdSLnG66WQkC&printsec=frontcover#v=onepage&q&f=false> Editor of the /NoCOUG Journal <http://bit.ly/rC2gRA>/ Lecturer at University of Washington Professional and Continuing Education <http://www.pce.uw.edu/biography/ignatius-fernandez/> ------------------------------------------------------------------------ Date: Mon, 14 Apr 2014 11:13:03 -0700 From: kulkarniravi@xxxxxxxxx <mailto:kulkarniravi@xxxxxxxxx> Subject: Extended RAC and multicast To: iggy_fernandez@xxxxxxxxxxx <mailto:iggy_fernandez@xxxxxxxxxxx> I am looking to setup extended RAC for my client. The details are as following: The two data centers are separated by a distance of less than 20 miles. They are connected by a high speed dedicated connection. Operating System: RHEL 6 64 bit Database version: 11gR2 (11.2.0.3) Hardware: Four servers with 4x16 configuration All the documentation I have reviewed so far says multicast should be enabled on the private interconnect between all the nodes of a RAC database. However, my network resources tell me that multicasting is not enabled across the data centers and VLANs do not span across the data centers. The only reference I have seen to multicasting requirement is in this Oracle document: http://docs.oracle.com/cd/E16655_01/install.121/e17888/networks.htm#CWLIN476 Specifically it makes the following assertion: "You do not need to enable multicast communications across routers" Does this mean, multicast is optional? Regards, Ravi Kulkarni
