Summary: Large Oracle DB's in Zones?

Many thanks to the following folks for taking the time to respond to my
question:

Adrian Koester
Tim Bradshaw
Joe Fletcher
David Magda
William Brown
Antony Pavlenko

Original question:

On Thu, Mar 18, 2010 at 10:34 PM, Romeo Theriault
<romeotheriault@gmail.com>wrote:

> Hi Folks, I'm looking for some general advice on moving large Oracle (ERP)
> databases into Solaris zones. The DB's currently run on Solaris 9 (E20K) but
> we are planning on upgrading hardware and moving to Solaris 10. Some
> questions I have are:
>
> * Does it make sense to move large resource intensive DB's in containers?
> Obviously we'd need to have the appropriate horsepower on the box to deal
> with the load but I'm wondering what kind of hit in performance we are going
> to see by putting the workload in a container.
>
> * All of our Oracle DB's currently reside on our Netapp SAN which we access
> from the HBA's/FC using vxvm and vxfs. I've seen multiple ways to make the
> disks/mount points available to the containers (e.g. lofs, assigning the
> whole device to the zone), but which makes the most sense from a performance
> perspective?
>
> * Any big gotchas I should know about?
>
>
> One of the benefits we hope to be able to capitalize on by using zones
> would be to have the ability to move the zone around amongst boxes, in case
> of emergency or to reduce maintenance outages, etc... So any thoughts on how
> well this works would be great too.
>



Summary:

* General consensus is that running large Oracle DB's in zones should work
just fine.

* There is a bit of disagreement about what kind of performance impact
running a Oracle DB in a container will have. Some folks said there should
be none while others suggest there will be some. I did find this blog post
though that shows there will likely be some performance impact:

http://blogs.sun.com/JeffV/entry/virtual_overhead

 * Running Oracle RAC nodes in containers is a no go since the clusterware
software requires lower level access than the container allows.

* One suggestion to dump Sparc in favor of X64 sun boxes.

* While no-one disagreed that it is possible to move zones from machine to
machine if needed it was suggested that I look into Sun Cluster or Veritas
Cluster to do a similiar thing but in a much more automated way.

* You can use solaris zones resource controls to limit the licensing costs
of Oracle by limiting the number of cpu's a zone has access to.

* Be aware of how you are going to backup the databases in the zones. As
they are all sharing the hosts network resources you can quickly run into
throughput bottlenecks during backup windows.

* One comment that the best way to divide the cpu's out is via CPU pools and
that it doesn't really matter if you use dynamic pools or not. The
recommendation was not to use the FSS scheduler. Also recommended not to
split out the memory among the zones due to some issues with resource caps.
(I don't have all the details on this yet.)

* About mount points.
>
In fact from performance point of view any type looks the same.
>
But there are some other problems. For example file system's which is added
> to zone cnfig and mouned when zone start will skip fsck procedure even if
> they are corrupted ( it is a bug ). And so on.
>
So I think that the best way is to mount vxfs file system in /etc/vfstab to
> /zones/<zoneroot>/fs/<mount_point> and then mount it like lofs in zone
> config.
>


Romeo
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers