From oracle-l-bounce@freelists.org Mon Apr 18 14:47:47 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j3IJllMZ019864 for ; Mon, 18 Apr 2005 14:47:47 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air891.startdedicated.com (8.12.10/8.12.10) with ESMTP id j3IJlk4Z019858 for ; Mon, 18 Apr 2005 14:47:46 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 3E5E6184900; Mon, 18 Apr 2005 13:45:29 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26740-02; Mon, 18 Apr 2005 13:45:29 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id B93D1184893; Mon, 18 Apr 2005 13:45:28 -0500 (EST) Message-Id: <200504181928.PQI15991@vmms9.netsolmail.com> Date: Mon, 18 Apr 2005 14:28:33 -0500 From: "Haroon A. Qureshi" Subject: Q: RAC and non-RAC databases on same servers To: oracle-l@freelists.org MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 18562 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: haroon@qureshi.name Precedence: normal Reply-To: haroon@qureshi.name X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at avenirtech.net X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on air891.startdedicated.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 greetings, we would like to implement RAC but have an issue with one application that is not RAC certified. can we have RAC and non-RAC databases on the same servers? we are currently running HP ServiceGuard for failover. my opinion is that we can, out of separate oracle homes (one RAC enabled and one not). we would also need to take the RAC enabled databases out of the cluster package so that only the non-RAC databases would failover using the cluster. does anyone see any issues with this approach? any that i maybe overlooking? thanks in advance, haroon -- http://www.freelists.org/webpage/oracle-l