oracle-l Digest Fri, 22 Aug 2014 Volume: 11 Issue: 236
In This Issue:
Re: Oracle RAC on VM
Re: Oracle RAC on VM
Re: Oracle RAC on VM
Re: Oracle RAC on VM
Re: Oracle RAC on VM
Re: DCD dead connection detection in 12c
Re: Oracle RAC on VM
Re: Oracle RAC on VM
RE: Oracle RAC on VM
RE: Oracle RAC on VM
Calculate additional space needed to reduce percent used on
Re: Calculate additional space needed to reduce percent used
Re: Oracle RAC on VM
----------------------------------------------------------------------
Date: Fri, 22 Aug 2014 10:01:24 +0200
From: przemolicc@xxxxxxxxx
Subject: Re: Oracle RAC on VM
Pro VM:- snapshots before any patching, upgrade - very, very handy feature :-)- performance: we migrated some Oracle-s (EBS) to Vmware and nobody
is complaining (it is not very loaded though ...)RegardsP.Od: "Kevin Lidh" <kevin.lidh@xxxxxxxxx>Do:
oracle-l@xxxxxxxxxxxxx; Wysłane: 0:16 Piątek 2014-08-22Temat: Oracle RAC on VMAs a DBA, I never wanted to work on Oracle on VMware but it seems
to be the trend. Now that I’m a manager, I’m looking to propose moving to RAC for HA and also back to physical machines.
Since this goes against the strategic direction of our organization, I’m sure I’ll be asked why we can’t do RAC on VMs. I
have my personal opinions about this but I was wondering what the broader audience of experts believe. Factors I’m considering
are:1) Servers closer to the storage for performance. In virtualization, you have an
intermediary processing your requests and responses.2)  
; Access to all resources licensed. We keep a certain percentage of our hosts free to handle
the load in case one in the cluster fails. With RAC, you have access to all the resources all the time. And since
you have to pay for it all anyway, I see that as a good thing.3) Performance in
general. I don’t have any evidence but I can’t believe that another layer between my OS calls and the hardware could be as
fast as not having that layer. Thanks in advance, Kevin
------------------------------
Date: Fri, 22 Aug 2014 04:27:58 -0500
Subject: Re: Oracle RAC on VM
From: Justin Mungal <justin@xxxxxxx>
If you open an SR and Oracle thinks it's the hypervisor, they will tell you
to reproduce the issue in a non-virtualized environment in order to
continue getting support. This has never happened to me, but we don't have
that many virtualized systems running Oracle.
On Thu, Aug 21, 2014 at 5:14 PM, Kevin Lidh <kevin.lidh@xxxxxxxxx> wrote:
As a DBA, I never wanted to work on Oracle on VMware but it seems to be
the trend. Now that I’m a manager, I’m looking to propose moving to RAC
for HA and also back to physical machines. Since this goes against the
strategic direction of our organization, I’m sure I’ll be asked why we
can’t do RAC on VMs. I have my personal opinions about this but I was
wondering what the broader audience of experts believe.
Factors I’m considering are:
1) Servers closer to the storage for performance. In
virtualization, you have an intermediary processing your requests and
responses.
2) Access to all resources licensed. We keep a certain percentage
of our hosts free to handle the load in case one in the cluster fails.
With RAC, you have access to all the resources all the time. And since you
have to pay for it all anyway, I see that as a good thing.
3) Performance in general. I don’t have any evidence but I can’t
believe that another layer between my OS calls and the hardware could be as
fast as not having that layer.
Thanks in advance,
Kevin
------------------------------
Date: Fri, 22 Aug 2014 08:44:14 -0600
From: Tim Gorman <tim@xxxxxxxxx>
Subject: Re: Oracle RAC on VM
Kevin,
I had to endure debates 20 years ago when some people felt that RAID-0
striping in storage consumed more processing than it provided benefit.
Around the same time, debate about setting the Oracle parameter
TIMED_STATISTICS was rife. I argued that the additional processing in
capturing timings within the V$ views more than compensated the effort
to do so by getting rid of meaningless ratios and providing the best
tuning metric of all: time. Up to the late 1990s, I frequently
encountered production systems with TIMED_STATISTICS=FALSE set by DBAs
who felt they were wringing every last cycle from the database, when in
fact they turned the database into a black box which could not be
optimized scientifically. Before that, in the 1980s, I recall a debate
with a VAX VMS sysadmin who asserted that compiling a program with
certain optimizations enabled consumed more system resources than the
program saved over the program's lifetime. He also argued that
compiling a program more than 10 times during the course of development
was negative ROI as well, that developers should think long and
carefully before compiling. Almost 30 years later, I'm still coming up
with retorts that I wish I had thought of back then.
So I believe that the argument that the hypervisor as intermediary
processing sapping performance is likewise missing the most important
points and is disastrously incorrect. You have to break eggs to make an
omelette. As long as you're not using any of the 43 remaining Faberge
eggs or those from an endangered species, the omelette is worth it.
There is a misconception that virtual machines exist only in a
free-for-all environment involving a cloud of virtuals on a small number
of overworked physicals, resulting in unpredictable performance and
behavior. This can be true, and frequently is true.
Virtual machines used in production are often configured with vCPU and
vRAM reservations, so that the resources are reserved for their use only
and are never allocated to other virtual machines. Setting VM
hyperthreading to "none" is a way to prevent dilution of CPU as well.
And of course, virtual machines can always be configured 1:1 on physical
servers if desired.
Six years ago I was hired by a public transportation agency to assist
them implementing Oracle RAC and DataGuard. It turned out that none of
their applications consumed more than half the resources of their
servers, so there was no need for the scalability of RAC, and so I
talked them out of that. Then, with VMware VMotion replicating entire
virtual machines and not just the database (as with DataGuard) leaving
the necessity to replicate file-systems with rsync, it was easy to
convince them to use VMotion for fault-tolerance and high-availability.
As they had only one data center at the time, business continuance and
disaster recovery was not in scope. This allowed the government agency
to avoid the operate their Oracle databases as straight standalone
non-RAC non-DataGuard instances, applying the KISS principle where it
was needed most.
So, although it was cushy government contract in a downtown location
likely to last for years, I talked myself out of that contract within 6
months. My prime contractor was surprised and a bit disappointed, and
Oracle sales was angry enough to spit nails, but it was the right course
for them and I'd do the same thing again.
However, sometimes folks can't be saved; they later bought an Exadata,
so Oracle got their licenses back in the end. :-)
Hope this helps...
-Tim
On 8/22/14, 2:01, przemolicc@xxxxxxxxx wrote:
Pro VM:
- snapshots before any patching, upgrade - very, very handy feature :-)
- performance: we migrated some Oracle-s (EBS) to Vmware and nobody is
complaining (it is not very loaded though ...)
Regards
P.
Od: "Kevin Lidh" <kevin.lidh@xxxxxxxxx>
Do: oracle-l@xxxxxxxxxxxxx;
Wysłane: 0:16 Piątek 2014-08-22
Temat: Oracle RAC on VM
As a DBA, I never wanted to work on Oracle on VMware but it seems
to be the trend. Now that I’m a manager, I’m looking to propose
moving to RAC for HA and also back to physical machines. Since
this goes against the strategic direction of our organization, I’m
sure I’ll be asked why we can’t do RAC on VMs. I have my personal
opinions about this but I was wondering what the broader audience
of experts believe.
Factors I’m considering are:
1)Servers closer to the storage for performance. In
virtualization, you have an intermediary processing your requests
and responses.
2)Access to all resources licensed. We keep a certain percentage
of our hosts free to handle the load in case one in the cluster
fails. With RAC, you have access to all the resources all the
time. And since you have to pay for it all anyway, I see that as
a good thing.
3)Performance in general. I don’t have any evidence but I can’t
believe that another layer between my OS calls and the hardware
could be as fast as not having that layer.
Thanks in advance,
Kevin
------------------------------
Date: Fri, 22 Aug 2014 08:07:49 -0700
Subject: Re: Oracle RAC on VM
From: John Piwowar <jpiwowar@xxxxxxxxx>
I hear this argument often, and when I do, I encourage people to consider:
1) if you open an SR and Oracle thinks it's a hardware or OS problem, they
will likely direct you to the HW/OS vendor. No reason to expect anything
different with hypervisor problems.
2) If *Oracle* is your HW, OS, or hypervisor vendor in a situation where
one of this components of you stack is suspected, you can expect your SR to
be moved to an appropriate group. It's not "one throat to choke," it's a
hydra. ;-)
I'm a fan of virtualization in principle, but like any
platform/infrastructure decision, it's not a one-size-fits-all solution.
The licensing issue, already discussed in the thread, is a legit concern
with VMWare, but people also find a way to either live with it or work
around it. Performance *could* be an issue, but you really don't know that
until you run some tests with your workloads and can quantify the
differences. Then you (as an organization, not Kevin ;-) get to decide if
those differences are significant enough to impose the operational overhead
of introducing an exception to your strategic direction. Your best bet is
to be prepared for a data-driven discussion. :)
This is coming off sounding a bit lecture-y and jerky, and I apologize. I
blame email, lack of coffee, and typing with thumbs. ;) Good luck with the
decision/exploration.
On Friday, August 22, 2014, Justin Mungal <justin@xxxxxxx> wrote:
If you open an SR and Oracle thinks it's the hypervisor, they will tell
you to reproduce the issue in a non-virtualized environment in order to
continue getting support. This has never happened to me, but we don't have
that many virtualized systems running Oracle.
On Thu, Aug 21, 2014 at 5:14 PM, Kevin Lidh <kevin.lidh@xxxxxxxxx
<javascript:_e(%7B%7D,'cvml','kevin.lidh@xxxxxxxxx');>> wrote:
As a DBA, I never wanted to work on Oracle on VMware but it seems to be
the trend. Now that I’m a manager, I’m looking to propose moving to RAC
for HA and also back to physical machines. Since this goes against the
strategic direction of our organization, I’m sure I’ll be asked why we
can’t do RAC on VMs. I have my personal opinions about this but I was
wondering what the broader audience of experts believe.
Factors I’m considering are:
1) Servers closer to the storage for performance. In
virtualization, you have an intermediary processing your requests and
responses.
2) Access to all resources licensed. We keep a certain percentage
of our hosts free to handle the load in case one in the cluster fails.
With RAC, you have access to all the resources all the time. And since you
have to pay for it all anyway, I see that as a good thing.
3) Performance in general. I don’t have any evidence but I can’t
believe that another layer between my OS calls and the hardware could be as
fast as not having that layer.
Thanks in advance,
Kevin
