This content has been marked as final. Show 11 replies
Check the system requirements in the installation guides, you won't find any reference to VMware. There's also a dedicated MOS note:
Support Position for Oracle Products Running on VMWare Virtualized Environments [ID 249212.1]
But Oracle has its own VM software, Oracle VM , which is fully supported.
user12243721 wrote:That has been bandied about for a while now, and I've even mentioned it myself. I believe there was a MataLink note on it, but it also needs to be tempered a bit. At Open World last year (2010) VMware had one of the prime real estate sites in the exhibit hall. I think the bottom line is that if there are issues on a VMware platform, oracle reserves the right to request that the SR issue be replicated on a physical server, not that they will refuse to work with you.
Oracle doesn't support VMware, that is certainly news to me and very dissapointing, where did you get this information? Thanks
I see it also on XE, but good luck trying to get that supported! Re: vktm time drift detected.
The event does seem to cut way down on the notifications. I would be much more comfortable with an actual explanation, especially since I don't see it on another machine.
When you restart Oracle, does it list the event in the non-default options?
Edit: I only just found out my machine in question is actually a VM - it seems that must have happened after the last time I directly asked if it was. lol Only clue I've noticed so far is the disk drives are all virtual.
Edited by: jgarry on Dec 15, 2011 11:34 AM
user12243721 wrote:I get this as well on Windows 64-bit with a multi-CPU machine, with the VM set up with 2 virtual CPUs.
Running 18.104.22.168 on windows 64 bit virtualized..
VKTM, oracles virtual keeper of time is throwing a lot of warnings in the alert log. According to my research this is not a great concern (if someone could explain why that would be great as well) but you should be able to supress the trace file if you are at 22.214.171.124 by setting event = "10795 trace name context forever, level 2" in the the paramater file. I am using a spfile and did not use "alter system", i cretaed pfile and edited it , opened with it and created a new spfile then opened with that. I am however still receiving the trace files and the messages in the alert log, I am getting approximately 10 a day now so the alert log is filling rather quickly. Has anyone else encountered this or have any advice on how to solve this? Thanks
Since it's not a production machine it hasn't bothered me, but there are three other side effects
a) the "tim=" values in 10046 trace files look as if they have two parallel clocks running out of synch with each other - with the reported values jumping from one clock to the other every few milliseconds.
b) sometimes the database refuses to restart with "vktm didn't start in time" error messages
c) a couple of times a call to dbms_lock.sleep(0.01) has slept for a very long time - possibly because the timer started on the faster of the two clocks, and the system then jumped to the slower.
I never trust the machine for performance tests, so the timing anomalies aren't a big issue for me, so I haven't followed it up; but I'd guess it's a vmware issue with the way it has virtualised the multiple CPUs.
Author: <b><em>Oracle Core</em></b>
I suspect this explains it: http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf
Even though I'm on a different vm, I expect the issue is the same. Must guess when you can't know.
I suspect this is the basis of Oracle's general skittishness on the vm support side, the arrow of time must be implicit throughout the code on any given machine.