Re: wrong start_time and start_date in v$transaction

(soft) error starting up vktm (virtual kernel timer) sounds promising. Is that "if and only if" transaction start time is wrong. I can't remember which functions Oracle uses time from vktm and which ones it calls direct to the O/S, unfortunately.

Regards
Jonathan Lewis

On Tue, Sep 1, 2020 at 12:32 PM Noveljic Nenad <nenad.noveljic_at_vontobel.com> wrote:

> Jonathan,
>
> Sayan,
>
> Andy,
>
>
>
>
>
> "Doesn't change" - depends on the power of 10 in the (hypothetical) error
> and the amount of time Nenad watched (maybe the time stamp increases by one
> second every 20 minutes, or every 200 minutes).
>
>
>
> >start_time & start_date haven't changed within 24 hours.
>
>
>
> Anything in any of the alert logs about processes not starting up
> properly, or using some specific function that doesn't get mentioned in
> other alert logs?
>
>
>
> >The only startup error message is:
>
> ORA-00800: soft external error, arguments: [Set Priority Failed], [VKTM],
> [Check traces and OS configuration], [Check Oracle document and MOS notes],
> []
>
> Incident details in:
> /u00/oracle/orabase/diag/rdbms/acsi3_site1/ACSI3/incident/incdir_129660/ACSI3_vktm_9138_i129660.trc
>
>
>
> Are any of the funny instances running on virtual machines ?
>
> >Everything is running on Solaris containers. However, only a minority of
> the databases is being affected.
>
>
>
> I recall a case where running on vmware some processes would
> intermittently record a "tim=" value in a trace file that was millions of
> centiseconds wrong.
>
>
>
> >Tim in the SQL trace is correct:
>
>
>
> >..tim=11591151275421
>
>
>
> >get_t_hr0
>
> 1587367589894044
>
>
>
> >python convert_tim_to_localtime.py 11591151275421 1587367589894044
>
> 2020-09-01 13:12:21.169465
>
>
>
> >(The programs above are from
> https://nenadnoveljic.com/blog/high-resolution-time-human-readable/)
>
>
>
>
>
> Is there something like faketime, libfaketime, strange LD_PRELOAD?
>
>
>
> >Nothing strange.
>
> pargs -e 24032 | grep -i fake
>
> pargs -e 24032 | grep -i LD
>
> envp[17]: LD_LIBRARY_PATH=/u00/oracle/orabase/product/18.7.0.0.190716_a/lib
>
>
>
> >Besides that, sysdate returns the correct value.
>
> But thanks for the link - I didn't know about this!
>
>
>
> Are the instances that have the problem connected by DB links?
>
> >No.
>
>
>
> What about the others?
>
> >Some do have links some don't.
>
>
>
> Do you have similar wrongness with scn_to_timestamp?
>
> >No.
>
> SQL> select first_time,first_change# from v$log ;
>
>
>
> >FIRST_TIME FIRST_CHANGE#
>
> ------------------- -------------
>
> ...01.09.2020 02:12:54 12374018
>
>
>
> >SQL> select scn_to_timestamp(12374018) from dual ;
>
>
>
> >SCN_TO_TIMESTAMP(12374018)
>
> ---------------------------------------------------------------------------
>
> 01-SEP-20 02.12.54.000000000 AM
>
>
>
> >Can you replicate with a fresh instance using the same oracle home?
>
> No
>
>
>
> Thanks,
>
> Nenad
>
>
>
> https://nenadnoveljic.com/blog/
>
>
>
> ____________________________________________________
>
> Please consider the environment before printing this e-mail.
>
> Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.
>
>
> Important Notice
> This message is intended only for the individual named. It may contain
> confidential or privileged information. If you are not the named addressee
> you should in particular not disseminate, distribute, modify or copy this
> e-mail. Please notify the sender immediately by e-mail, if you have
> received this message by mistake and delete it from your system.
> Without prejudice to any contractual agreements between you and us which
> shall prevail in any case, we take it as your authorization to correspond
> with you by e-mail if you send us messages by e-mail. However, we reserve
> the right not to execute orders and instructions transmitted by e-mail at
> any time and without further explanation.
> E-mail transmission may not be secure or error-free as information could
> be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also
> processing of incoming e-mails cannot be guaranteed. All liability of
> Vontobel Holding Ltd. and any of its affiliates (hereinafter collectively
> referred to as "Vontobel Group") for any damages resulting from e-mail use
> is excluded. You are advised that urgent and time sensitive messages should
> not be sent by e-mail and if verification is required please request a
> printed version. Please note that all e-mail communications to and from the
> Vontobel Group are subject to electronic storage and review by Vontobel
> Group. Unless stated to the contrary and without prejudice to any
> contractual agreements between you and Vontobel Group which shall prevail
> in any case, e-mail-communication is for informational purposes only and is
> not intended as an offer or solicitation for the purchase or sale of any
> financial instrument or as an official confirmation of any transaction.
> The legal basis for the processing of your personal data is the legitimate
> interest to develop a commercial relationship with you, as well as your
> consent to forward you commercial communications. You can exercise, at any
> time and under the terms established under current regulation, your rights.
> If you prefer not to receive any further communications, please contact
> your client relationship manager if you are a client of Vontobel Group or
> notify the sender. Please note for an exact reference to the affected group
> entity the corporate e-mail signature. For further information about data
> privacy at Vontobel Group please consult www.vontobel.com.
>

--
http://www.freelists.org/webpage/oracle-l