This content has been marked as final. Show 12 replies
Those trace messages can be turned off with a trace level setting, the fix is supposed to be in 18.104.22.168 but not enabled.1 person found this helpful
Are you using time.windows.com for "internet time"? (Control panel/Date and time/Internet Time tab). Last time I looked that one was broken, since the 2005 DST updates. Really.
And the weekly "internet time" update schedule was not very well thought out for Windows, IMHO. Try using the ntp.org servers, at least they work.
clcarter wrote:Yeah, I saw that, I'm just wondering if anyone can clarify what is really happening. I also later saw some more things on MOS like "it is still happening in 22.214.171.124 with the event set," so I was hoping to elicit more info from someone with a non-XE that could maybe shed more light.
Those trace messages can be turned off with a trace level setting, the fix is supposed to be in 126.96.36.199 but not enabled.
Are you using time.windows.com for "internet time"? (Control panel/Date and time/Internet Time tab). Last time I looked that one was broken, since the 2005 DST updates. Really.lol there is no Internet Time tab, I presume the admins have a site master clock of some sort, is there any magic words I should ask them? They're smart people, I don't know much about windows. I do communicate better with them if I have some clue about their terminology before I ask. Since I do have privileged access greater than my knowledge, I'm real careful not to work at cross-purposes administrivially.
And the weekly "internet time" update schedule was not very well thought out for Windows, IMHO. Try using the ntp.org servers, at least they work.I am innocent of all network topological knowledge. There's a whole team for that.
1 person found this helpful
Whoops, I only saw "XP", didn't see the "2002" bit. Sorry, was on a bit of a tangent since it kind of sounds like a timer or time sync error, something similar, thinking it might have something to do with NTP.
lol there is no Internet Time tab
Yeah, apparently the event just turns off the errors, or is supposed to. We've only got a small handful of 188.8.131.52 instances but that error is a new one to me, but we're not using any RDBMS hosts on windows at all, just *nix.
OK, well, I'll leave this open in case someone else has more info about vktm or also seen it, and give the event a try. This has the feel of a simple goof leaving some debug info on, but I'd rather be sure, since I and obviously many others don't see it elsewhere. Where's BAAG when you need them?
vktm is a new 11g process <bla bla>
Edited by: laurent on Dec 15, 2011 1:53 PM
Was that post perhaps meant for another thread?
I'm sure XE does not exist for AIX platform.
sorry, I thought it could relate to the same "vktm time drift detected" error, apologize for the confusion
Maybe. But I don't see from your post that the same error occurred. If it did, please adjust your post, adding the left out info and clarification.
lol, I noticed it there before I noticed this comment here.
Edit: And I've only just found out it is actually a VM. Marking answered, assuming it has something to do with VM time drift.
Edited by: jgarry on Dec 15, 2011 11:38 AM
I encountred same problem on physical server with Oracle 184.108.40.206.
It's not a VM issue.
It is not just VMWare issue.1 person found this helpful
I encountered it on both physical machine (M4000, Solaris 10 U10, Oracle DB Ent. 220.127.116.11), and on T4 partitioned by OracleVM for SPARC 2.2 (Solaris 10 U10, Oracle DB 18.104.22.168)
On physical machine I had:
kstmchkdrift (kstmhighrestimecntkeeper:lowres): Stall, backward drift ended at 1340583976 drift: 1
kstmchkdrift (kstmhighrestimecntkeeper:lowres): Time stalled at 1340772250
*** 2012-07-23 20:31:15.437
kstmchkdrift (kstmhighrestimecntkeeper:highres): Time jumped forward by (1341033)usec at (618783244703) whereas (1000000) is allowed
In addition to this, on T4, database startup time was around 4 minutes.
Both issues were solved by disabling AMM (automatic memory management) - I just added pga_aggregate_target and sga_target instead of memory_target. Database startup time improved to 15sec and no more time drift warnings.