Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
Ondrej Zizka asked whether Informix uptime exceeding OS uptime after restoring a VM snapshot could cause harm. Art Kagel, Andreas Legner and khaled Bentebal said uptime is just the time since engine start, so it is informational only. Andreas noted time-based behaviour may differ after waking an engine, especially if the clock moved back.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Ondřej Žižka — source: IBM Community (ConnectedCommunity.org) Informix forum
Hello,
This is not an issue for me now, just a question if anybody has already seen that and what your experience is...
I was playing a bit with the Informix server, and because I expected the Informix would have been destroyed, I created a VM snapshot. After some time I restored the VM snapshot and saw that Informix uptime is higher than the OS uptime.
Informix is running, I can connect, I can read data, but may it cause any issues? Checkpoints? Warm restores?
Restart of the database will solve the "issue", but in this situation... May it cause any harm to any database process?
Thank you
------------------------------
Ondrej
------------------------------
↪ replying to Ondřej Žižka
Art Kagel — source: IBM Community (ConnectedCommunity.org) Informix forum
Ondrej:
The difference in "uptime" should not make any difference or have any effect on the Informix instance. The reported uptime is for you. The engine does not care how long it has been online.
Art
------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com
------------------------------
↪ replying to Art Kagel
Andreas Legner — source: IBM Community (ConnectedCommunity.org) Informix forum
What the engine remembers is its start time, and what onstat displays as "Up" time simply is the difference between that and current time.
Not much indeed depends on that start time, so I'd agree with Art there probably won't be any problems arising from this calculation.
Things might be slightly different wrt. the gap that will have occurred when waking a live engine from such artificial OS sleep - quite a few things do depend on time of day and e.g. distance to events of the past, but I think most of these would quickly adjust to the new time and forget or not even notice any gap. (It might be quite different if waking the system with the system clock turned back into the past.)
BR,
Andreas
------------------------------
Andreas Legner
------------------------------
↪ replying to Ondřej Žižka
khaled Bentebal — source: IBM Community (ConnectedCommunity.org) Informix forum
Hi Ondrej,
The UPTIME at the informix instance level is the elapsed time from when you started your engine (instance). If you bring the engine down and restart, the UPTIME starts from 0 again. It is not based on the system time. As long as the instance is up, the UPTIME increases; the longer the better since the data caching in the bufferpool (instance memory) stays available for users and avoids going to disk to get them. So no issues from the usage (checkpoints, etc). The system time (that could be different from time zone to another and can be modified) impacts the date and time that you see in the messages in the "ONLINE.LOG", but that is only for information; the only thing is that you might be confused when reading yourself the times of each logged message. No impact though on the way the instance functions.
So the UPTIME at the instance level is only indicative, and each instance will have its own UPTIME.
Cordialement, Regards, Khaled Bentebal Email:
khaled.bentebal@consult-ix.fr
Site Web:
www.consult-ix.fr
Le 12/02/2024 à 08:15, Ondřej Žižka via IBM TechXchange Community a écrit :
↪ replying to Ondřej Žižka
Ondřej Žižka — source: IBM Community (ConnectedCommunity.org) Informix forum
Thank you all for your answers.
------------------------------
Ondřej
------------------------------
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.