From oracle-l-bounce@freelists.org Thu Jul 7 08:46:23 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j67DkNBl029138 for ; Thu, 7 Jul 2005 08:46:23 -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 j67DkJIP029121 for ; Thu, 7 Jul 2005 08:46:20 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id A14C01C8953; Thu, 7 Jul 2005 08:46:00 -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 10206-10; Thu, 7 Jul 2005 08:46:00 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 1E57A1C92AD; Thu, 7 Jul 2005 08:46:00 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by Ecartis Subject: RE: VPD vs multiple schems vs multiple instance Date: Thu, 7 Jul 2005 09:44:07 -0400 Message-ID: <4001DEAF7DF9BD498B58B45051FBEA6502A520C3@25exch1.vicorpower.vicr.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPD vs multiple schems vs multiple instance Thread-Index: AcWCdPnMN1hH0LC5TN+AC0Wd6fT4xwAgsL5w From: "Goulet, Dick" To: , Cc: X-OriginalArrivalTime: 07 Jul 2005 13:44:08.0154 (UTC) FILETIME=[F2C743A0:01C582F9] X-archive-position: 22168 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: DGoulet@vicr.com Precedence: normal Reply-To: DGoulet@vicr.com X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at avenirtech.net X-mailscan-MailScanner-Information: Please contact the ISP for more information X-mailscan-MailScanner: Found to be clean X-MailScanner-From: oracle-l-bounce@freelists.org X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on air891.startdedicated.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Dennis, May I disagree? 1) Easier Security, yes if you like maintaining security in multiple instances. What a pain in the @$$. 2) Downtime: Yeah, sorta, unless the server crashes or needs an OS patch in which case your still in trouble. Are you recommending separate servers as well? 3) Patches: Yeah again sorta, if you have separate Oracle_Homes for each instance otherwise your doubly screwed as you've multiple instances to upgrade. If you have multiple homes then patching is a real pain because of the number of times you have to do the patching. And having multiple versions/patch levels is a real confusing matter, especially since many clients will take the "if it ain't broke don't fix it" attitude. My biggest headache, security patches because things aren't broke. 4) Move a client to a new server: So what, move the entire system. If one client needs a separate server then you've got bigger problems. Oracle patch sets are cumulative in nature. If one client wants a specific patch, which should NOT be their choice in a hosted environment they may well have to accept other patches that are not desired by their management. Face it if your hosting the application patching is for your benefit, not the client's. They just want the application to work and work in a secure and timely manner. Someone else stated that one client may want the database rolled back. WHY?? Their using the application, not managing it. If they messed up some of their data they can fix it themselves or pay your company to fix it for them. Rolling back the database is not an option. My druthers, one instance, possibly rac'ed and mirrored, with one owning schema, portioned tables. Several users accessing the common tables with their userid being part of the data and primary key, and each user in a separate partition. If you really need to allow adhoc query access use a set of view definitions, similar to Oracle's user_ definitions. It's a lot easier and simpler to create the views and instead of triggers for each view than to build all of those VPD triggers. -----Original Message----- From: oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] On Behalf Of Dennis Williams Sent: Wednesday, July 06, 2005 5:50 PM To: dubey.sandeep@gmail.com Cc: oracle-l@freelists.org Subject: Re: VPD vs multiple schems vs multiple instance Sandeep I would advocate separate instances for the following reasons: 1. Easier security. 2. When downtime is required, easier to meet each client's needs. 3. When Oracle needs patched or upgraded, easier to deal with each client. 4. If you decide to move a client to another server, easily done. For example, one client insists an Oracle patch be applied immediately. Another client insists that they can't possibly accept the downtime required. With a single instance, you are forced to choose between clients. With separate instances you can treat clients independently. There are advantages to a single instance from a shared pool perspective. However, in my experience the frustrations outweigh that gain. Dennis Williams -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l