System date change

[Cara Tock]

I have been asked to change the system date on my N4000 running HP-UX 11.0. I was asked to roll the date back one month. I am running my application on Oracle 8.1.6.
Has anyone attempted to do this? I am very worried about what might happen.

[T G Manikandan]

The oracle instance does not depend on the system time even if it is adjusted.
But if you are using a time based recovery scenario you get into trouble of double time stamp.
So a time based recovery scenario becomes a problem but you can still use the SCN and CANCEL based recovery scenarios for recovery.
The SCN(system change number) time stamps does not depend on the system time.

But it is better to have a cold backupi.e.complete consistent shutdown of the database and a backup of it before doing into any system time change.

But still the incremental exports,PL?SQL jobs and the cron jobs running on the system should get affected.

Thus changing the system time will not affect the Oracle instance except the time based recovery option.


thanks

[A. Clay Stephenson]

This is normally a bad thing to do. Setting your system data ahead is generally not too bad but setting it backwards can confuse many applications. For example, in many database applications it is common to have a sequential transaction number of some sort. In your case, after setting the date back, transaction 1000 could occur earlier than transaction 999.

Probably the most serious consequence is on development boxes which depend upon the make utility. Make uses the file datestamps to determine which objects need to be compiled and linked. For example, if myfile.o depends upon myfile.c, you could modify myfile.c but because myfile.o appears to be newer than myfile.o, myfile.c would not be recompiuled eventhough you just changed the source.

[Cheryl Griffin]

Rolling the date forwards and backwards (or backwards then forwards) can cause filesystem corruption (because files with future dates would be unknown by the system).

If you must do this, you should make a complete system backup prior to rolling the date. Be prepared to do a full system restore when finished testing the date.

If you have any documents from testing for Y2K you could use them for this task.
Cheryl

[Cara Tock]

What kind of effect does this have on the operating system?

[Cheryl Griffin]

Rolling the date can reak havoc on your system. Think about all the places that dates are used (password aging, timestamps in files, sar data, at jobs, licenses which might be based on date, etc.) The system is currently at one date, then you change the date back. So now what was the current date is now a future date to the system.

When this was an issue for y2k, everyone was testing by rolling the dates forwards then backwards, unless you had a backup from prior to rolling, you were advised to reinstall the operating system.

It is not advised, especially not in a production environment.

Cheryl

[Paula J Frazer-Campbell]

Damon

Yes as already stated you can have problems so a full system backup/ignite is advised before you do it.

But one of my test servers running Universe has the date rolled backwards and forwards on a regular basis and has had no problems.



Paula

[Cara Tock]

I would like to see what would happen, but I think I have to chicken out on this one. If someone tells me they have done this with HP-UX 11.0 and Oracle and haven't had any problems, then I might give it a try. The system isn't in production yet, but it is close and having it down for a week for a rebuild is not an option. Thanks for your replies.

[doug hosking]

"filesystem corruption" sounds a bit more frightening than may be warranted here. I'm not aware of any situation where, for example, setting the date backward would create problems that fsck could find. It certainly is true that it could cause problems with 'make' dependencies not working as expected, or incremental backups not containing the expected data. It's also quite possible that bad things could happen with any scripts that, for example, create files with names based on the current date, or that you might confuse cron/at or the jobs run by them.

It's nearly impossible to say what all the risks are without having a much more detailed understanding of what runs on the system in question. Given any reasonable choice, setting the date backward on a production system should probably be avoided. Skewing time with ntpd, adjtime(), etc. is generally a lot safer. Since you're talking about a delta of a month, I assume that's not a practical solution in your case.

[MANOJ SRIVASTAVA]

Hi Damon


Like you even I have never tried , but if I was you I owuld first try it on a test server and see what happens , ideally there shouldnt be any problems .


Manoj Srivastava

[Tim Medford]

Hi Damon.

I used to roll the date back and forth all the time on our development server. We had to do this in order to thoroughly test an application that had date sensitive code. It did wreak havoc with some of my maintenance routines which deleted files based on age.

We later found a way that you can change the date within an oracle instance without having to actually change the Unix system clock.

If you add this line to the init.ora, you can fake out oracle.

fixed_date = "2002-09-30-12:00:00"

If you then select sysdate from dual it will return sept. 30th, 2002 regardless of what Unix says.

Hope this helps,
Tim

[Bill Hassell]

On a production server, I would never allow more than a few minutes change and *ONLY* when rebooting, *NEVER* change the date/time on a running system. I would go so far as to wrapper the date command so that only queries are allowed (no changes).

Now, will this affect HP-UX? Probably not. Unless you are using time-specific services like cron. But what can you do with HP-UX? Not much. You have applications and support tools and even middleware that may be crucially dependent on time moving in one direction. If you assume that the database will be corrupted and all supporting config files will have to be rebuilt, then you'll make the right decision. There are some awful programs that store date and timestamps in the database as links and index items.

If you like to take chances, change the date but polish up your resume' just in case.

[Wayne Yu_1]

During the y2k period of time, we had developed a utility for people to roll the clock back and forth to test the Y2k bugs. We learnt from that system/OS normally is okay without problem.

However, you need to be careful with Oracle, since the Oracle trnsaction logs could get confused and no longer work properly. If you need to roll clock back for some special task, you would better of to create separate instance, stop you normal instance running in the normal clock and start this special instance at roll backed clock.

Hope this help.