static date

[Elena Leontieva]

Hi,

Our client wants to set a server to a static date for the duration of a project. For instance if the date is October 1, 2005, they want the date to remain October 1, 2005 till the project has been completed.

Can we schedule a cron job to run daily at 12:00 am, like "date -u 10010000"? Is it going to work because of setting time backwards?

Thanks,
Elena.

[Florian Heigl (new acc)]

Please reassure Your client really wants this in that exact way. :)

Moving the time backwards will cause large troubles (as in corruption / invalid data) for online databases.

[Pete Randall]

Well, the cron job approach is the only way I can think of to accomplish this, but, as Florian says, you need to very cautious. Setting the date backward can be very risky in a database environment because the rollback logs become totally worthless.


Pete

[Rick Garland]

databases are the most common reason to be aware of when setting dates backwards. A lot of applications relay on dates as well and these could be affected.

If you really want to do this, shutdown all databases and applications. Just setting a cron job will cause more troubles.

Databases will complain about duplicate dates.

[Pedro Cirne]

Hi Elena,

What is the purpose of this?

Why don't you create a fake "date" command that allways returns the same date? Would that be enough?

Enjoy :)

Pedro

[Elena Leontieva]

Hi,

This is for testing the upcoming project of Archive/Purge. The necessity is due to the program running based on months to purge in the program.

I am not sure they can take Oracle down ...if not I guess it is impossible to keep server at a certain date.

Pedro, can you explain more about a fake date?

Elena.

[Mel Burslan]

fake date is moving the actual date command to another name like:

mv /sbin/date /sbin.date.old
mv /usr/bin/date /usr/bin/date.old

echo "echo \"Sat Oct 1 00:00:01 PDT 2005\"" > /sbin/date
echo "echo \"Sat Oct 1 00:00:01 PDT 2005\"" > /usr/bin/date
chmod 555 /sbin/date /usr/bin/date


but this will only help to those programs, querying the the date by the date command, the system calls will still return the actual system date. And most large commercial programs, like databses, get the info via system calls.

[Pedro Cirne]

Hi Elena,

Mel already answered :)

Pedro

[Mel Burslan · Accepted solution]

I am not a database expert, hence I do not know the exact granularity of the database records timekeeping but for some reason, I think the records are kept by default by 1 minute increments. So, if you can keep the time in the same minute during the course of this project, you would theoretically be fine. And which is not too hard to do. Just not by cron as cron's granularity is a minute and if you skip that minute by 1 second and get a datbase transaction at that exact moment, you have inconsistency.

So, you will have a process running in the background all the time, sleeping less than 59 seconds and setting the date to the same value over and over until the cows come home :), something like this

while true
do
UNIX95= date 10010000
sleep 55
done

if you omit UNIX95=, when you set the time backwards, it will ask you if you are sure or not and you have to answer yes to that, in XPG4, question is not asked.

So, this might be something that you can use but again, check with a DBA for record timekeeping granularity first.

[TwoProc]

Since databases re: recovery seems to be the big issue - then the question could be:
Do you need archiving for recovery while the purge is going on? If not, then you may not have to worry. You could turn off archive logs before the purge begins, do a cold backup, run the purge, and then restart archive logs, then do a cold backup again before starting up in regular mode. In a big purge, this *might* actually be a faster process anyways.

[Bill Hassell]

Since you cannot take the database down, this must be a production server. If you change the date back, even once, your entire database may become corrupted. Virtually every database critically depends on accurate time to update/validate records. This project cannot be run on a production server, end of discussion. Purchase a test system and do your testing there. The problems with HP-UX commands like cron will be nothing compared to the mess you'll find in the databases.