DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=BfmgToog4nI6W+97jaBnDO7SO256Fx/e4kfNq9P7KVNoitN56lYCRHC3izaWB1eEMG
         DrEW1cF9mtlokI/2ms78Qdb3gnERDVoLnBqRXVgGxiq9trt1ETCAc9GpoC0FlNnbbxyN
         OxI/1E1uXC25dHckFgy+EW2ZgXahI3ktgnHFg=
Message-ID: <b86c876f0806301843l4af86b7ds301e1c25c8e24ad7@mail.gmail.com>
Date: Mon, 30 Jun 2008 21:43:07 -0400
From: "Pedro Espinoza" <raindoctor@gmail.com>
To: jeffthomas24@gmail.com
Subject: Re: Solaris zone for production RMAN catalog?
Cc: oracle-l <Oracle-L@freelists.org>
In-Reply-To: <22131320806301627i75fa80f5w44a3424e870ca2b9@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <22131320806301627i75fa80f5w44a3424e870ca2b9@mail.gmail.com>
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-to: raindoctor@gmail.com

> My instinct and limited understanding is that a zone does not provide
> as much insulation from being
> a SPOF as we have been led to believe.    It's hard to have any degree
> of confidence when during failover
> testing CRS rebooted the box and took down both the global and local
> zones.   I don't know if that
> is a flaw in how we built the zones, or simply a limitation in Solaris
> zones itself.

There is no flaw. /usr, /lib, /platform, /sbin in non-global zones are
lofs mounted from the global zones. This behavior is similar to chroot
jails in the BSD world, along with resource management like capping
memory, cpu, etc. Zones don't protect you from hardware failures, but
can protect your box even if your application gets compromised. People
set up BIND servers in chroot jails; instead, they can run that server
in a non-global zone.


> So the question is,  for those using zones more extensively - would
> you put a production RMAN catalog
> on a zone local to the hardware where the production database resides?

Yes, we have all our instances running on non-global zones, but we did
that way not because that setup provides SPOF, but because we wanted
to consolidate 4 servers into one. Whenver we want to upgrade kernel,
we have to shutdown all 4 non-global zones along with the global zone.

Well, you can just put your rman catalog on different physical machine
(global or non-global zone, it doesn't matter).

As an aside, there is an interesting paper: Jails, VMS, Sandboxes by
Bill Cheswick and this paper deals with what kind of problems these
virtualizatoin paradigms provide, what problems they dont solve.


http://www.usenix.org/event/lisa07/htgr_files/cheswick.pdf
--
http://www.freelists.org/webpage/oracle-l