We have an SQL Anywhere 12 DB running on a Solaris server and today we noticed that the syncing of the time has never worked and the database server is showing a time 5 minutes in the future. Is there any problems with setting the time on the DB server backwards? Do you need to shut down the DB first to do this? Something tells me that in version 7 this would cause problems with checkpoints etc. I would really like to be able to just set the time without bringing down the DB as it is a 24x7 system. Version 12 has been flawless in performance for our application. It has gone 1 year without a restart so far (maybe I shouldn't have said that :) )

Bob

asked 01 Feb '12, 10:25

Codecranker's gravatar image

Codecranker
391192228
accept rate: 0%

edited 01 Feb '12, 10:36

Mark%20Culp's gravatar image

Mark Culp
22.9k9129269

Have you found the time syncing problem? If not, check that the ntpd daemon is running and that UDP port 123 is not blocked.

(01 Feb '12, 15:33) Graham Hurst

You should not need to shutdown the database server when you reset the computer time - the DB server should handle the time change appropriately (we have tested this situation in the past).

For the future I would recommend creating a cron job ( or other similar ntp daemon technology ) that runs regularly (e.g. once per day) to synchronize the computer time to an NTP server. Most modern computers have this set up by default but some need configuration before they actually doing anything useful (e.g. define the NTP servers that are to be used). Another thing that can cause problems is network firewalls. In any case it is always a good idea to check that your computer has the right time. :-)

permanent link

answered 01 Feb '12, 10:35

Mark%20Culp's gravatar image

Mark Culp
22.9k9129269
accept rate: 41%

edited 01 Feb '12, 15:52

If your server's clock regularly drifts into the future, you may be in for interesting times (pun intended).

At the very least, you may get a chuckle out of this: http://sqlanywhere.blogspot.com/2011/07/beware-current-timestamp.html

permanent link

answered 02 Feb '12, 12:14

Breck%20Carter's gravatar image

Breck Carter
25.6k427586844
accept rate: 20%

May not be that related to this, but the "last request time" in the sa_conn_info area of the database seems to be notoriously inaccurate, at least in a few of the versions of ASA that we've been using. It doesn't respond to timezone changes very easily and I have often clocked it moving into the future at around three seconds per second. Comparing last request time of your current connection to "current timestamp" often results in some rather weird answers for me...

(02 Feb '12, 13:07) Erik Anderson
Replies hidden

Yes, I have seen last request times in the future, most recently with a busy V9 server... rather useless when looking for long-running requests.

(02 Feb '12, 16:01) Breck Carter

Older versions of the server could produce timestamps in the RLL (and other logs) in the future if the system clock slowly drifted forward but was then reset disciplined regularly backwards. AFAIK this issue has been fixed in more recent software (but can't remember exactly when this change was implemented) - the fix was to regularly monitor the system clock and reset the DB server's internal time which used for printing timestamps to the logs.

(02 Feb '12, 17:05) Mark Culp

Willya look at that: "reset disciplined"... I didn't know anyone else was interested in BDSM actually read my stuff!

(02 Feb '12, 17:52) Breck Carter
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×409
×2

question asked: 01 Feb '12, 10:25

question was seen: 663 times

last updated: 02 Feb '12, 18:42