Hello Freek, I think the problem resides usually their system technician says the problem is Oracle, and is our word against their word. The customers understands what is a slow and a faster server, but the virtual server is a more complex concept, so they must trust in what say their people. 2014-11-25 4:44 GMT-04:00 Freek D'Hooge <freek.dhooge@xxxxxxxxx>: > Juan, > > How do you deal with customers who have put the database on an > underpowered server or storage system? > In what way would such a situation be different from having a customer who > has put it on a wrongly configured virtual machine? > > Kind regards, > > -- > Freek D'Hooge > Exitas NV > Senior Oracle DBA > email: freek.dhooge@xxxxxxxxx > tel +32(03) 443 12 38 > http://www.exitas.be > > On ma, 2014-11-24 at 18:15 -0400, Juan Carlos Reyes Pacheco wrote: > > Thank you Tim, the problem is if you don't do that then the customer, will > expect you solve the problem that comes from the virtual misconfiguration, > doing some kind of magic in the database. > > I was thinking something like > > "In the case of the use of virtualization, the customer is aware it can > affect the support from Oracle, and in the case of a failure of performance > or bug, he accept he may need to move the production environment to an > standalone server to verify the bug or the performance problem is not a > problem in the virtual machine." > > > This keeps an open point, because in this moment that customer is > expecting we solve something comes from the virtual server. Because we > restarted the database, cleared the memory, etc. and only restarting the > server the problem is solved. And is the only customer who has that > problem, and other clients has identical software, and the database > configuration is standard. > > > 2014-11-24 10:28 GMT-04:00 Tim Gorman <tim@xxxxxxxxx>: > > Juan, > > There is an old saying that, "As soon as lawyers become involved, the > relationship is over", and this is certainly true in a vendor-customer > relationship. A lawyer will be glad to be paid to pursue such a case, but I > suspect it would only irritate your customer and it is messy and expensive > to amend contracts after the fact. Far easier to simply address the > technical problem, for that is what it is. That is how "trusted advisors" > are born. > > Virtual machines are usually allocated so as to "play nice" in a cluster, > which means that resources such as vCPU and vRAM are shared back and forth, > since each VM cannot always be allocated their configured amount at all > times. It is intended for the total resource allocated in a virtualization > cluster to exceed the physical capacity, at least in non-production > environments. > > But over-subscribing virtual resources in a production environment is > neither a good idea nor recommended, and that seems to be what has happened > here, perhaps? So, it is not that virtualization is inherently "bad" for > production, but badly administered. > > Think about it: demand for resources by the Oracle environment are peaking > when demand for resources by the other VMs are also peaking, if they are > supporting the same application. Unless otherwise configured, the > hyper-visor has no choice but to *reduce* resource allocation across the > board, due to the peak in demand by all. If the virtualization admins > likely have graphs and reports showing this happening already. > > It might be a good idea to work with the virtualization admin(s) to > diagnose whether this is happening or not, and decide whether to increase > resource capacity in the cluster (i.e. buy more hardware) or set > reservations on a minimal amount of vCPU or vRAM for the Oracle > environment? This will permit the issue to be escalated as the simple > technical issue of resource sharing that it is. > > At this point, IT management can be presented with the choices of A) > increasing the capacity of the cluster and solving the problem or B) > imposing reservations on certain VMs and micro-managing resource allocation. > > There is a further option "C" of tuning each of the critical virtual > machines to dampen the peaks in demand of course, and this list can help > with that. > > Hope this helps... > > -Tim > > > > > > On 11/24/14 6:46, Juan Carlos Reyes Pacheco wrote: > > Hello, please > does anybody includes in the contract something against the use of virtual > machines to install Oracle. > One of our customer has a virtual machine that degrades the performance, > and is necessary to restart the server periodically. > They expect we solve something we can't solve, because the problem is in > the virtual machine, other customer with the same software doesn't have > that problem. > > I was asking myself if there is a "standard" clause in the contracts for > the customer to free from problem related to virtual machines. > In example I read there is no support from oracle for vmware machines, if > you have a bug you have to demostrate this same bug happens in a physical > installation too. > > Thank you :) > > > > > -- > //www.freelists.org/ <//www.freelists.org/webpage/oracle-l> > webpage/oracle-l <//www.freelists.org/webpage/oracle-l> > > > > >