Skip to Main Content
  • Questions
  • Oracle upgrade through daylight savings clock change

Breadcrumb

Question and Answer

Chris Saxon

Thanks for the question, Graham.

Asked: October 07, 2020 - 10:20 am UTC

Last updated: October 07, 2020 - 6:15 pm UTC

Version: 11.2.0.4

Viewed 1000+ times

You Asked

Here in the UK, we are due to change our timezone back to Greenwich Mean Time (GMT) from British Summer Time (BST) on 25th October. My company usually takes this evening as an opportunity for more in depth routine maintenance and software/hardware upgrades as our main application will be offline throughout this period. Due to time constraints, my senior managers were exploring ways in which they perceived that time could be saved in order to fit the required work into a much smaller time frame - one key piece of work we were scheduled to complete was the upgrade of our database and grid infrastructure to Oracle 19.8.

My managers asked me whether there would be any issues with performing this upgrade during the moment of the clock change itself because we'd gain an extra hour and would help them alleviate their time constraints. The clock change itself occurs at 02:00 BST which then becomes 01:00 GMT. Regardless of the precise moment the upgrade began, they were asking whether there would be any implications with actual, technical upgrade steps (either clusterware or database) happening at the moment of the clock change. In my ten years of being a DBA, I've always scheduled my work of this nature around such a moment "just in case" by finishing or pausing by 01:00 BST and then resuming after 01:00 GMT but I was unable to give my managers a technical reason or justification as to why work cannot carry on through this moment. I simply, albeit very strongly and as diplomatically as I could stress, said that it would most likely go against good practice and could put us on a very sticky wicket with support if we were to need their help should anything go wrong.

I'm fully aware of the SCN within the database as its internal clock but with clusterware and its interaction with networking, storage and other such things I would have thought time would have a greater importance, most certainly during such a major piece of work like an upgrade. I did raise a support question with Oracle support themselves but I think they may have misunderstood, perhaps they don't often receive such questions.

My question to you, and certainly the advice I'd like to receive, would almost not be whether this is technically possible to achieve (although I'd still very much like to know) but what your opinion would be regarding such a situation. Is it something you have performed elsewhere or do you avoid such tasks during moments like this "just in case"?

As a result of other issues, we are actually postponing this upgrade for this time and will complete it on another date so overall my point is moot for another year but I'd really like to know your thoughts, if only from a philosophical perspective!

Thanks again for all your work.

Kind regards,

Graham

and Chris said...

I see no issues with this approach, sounds like a neat way to give yourself a "free" hour to complete the upgrade. Though it's worth noting you get this extra hour whether you're upgrading during the clock change or not. For example, if your agreed outage is between say 10pm - 6am, you still have 9 hours instead of the usual 8 regardless of when you actually do the upgrade. It only truly makes a difference if you're being given just a two-hour window covering the repeated 1am-2am times (UTC 00:00 - 02:00).

But to be sure, I reached out to Mike Dietrich, Master Product Manager for Oracle Database Upgrade and Migrations who has a wealth of experience with database upgrades. He has this to say:

The database won't be affected in any way. Simple reason is that database transactions work on SCNs. And the SCN does not care about the OS clock jumping back an hour.

Internally, in my understanding, the database works in UTC - and hence, won't have an issue either.

Do you know this MOS note describing several typical issues:

Oracle Support Document 1627439.1 (How to Diagnose Wrong Time ( SYSDATE and SYSTIMESTAMP) After DST Change , Server Reboot , Database Restart or Installation When Connecting to a Database on an Unix Server) can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=1627439.1

But generally, I have never seen anything problematic.


So sounds like you're good.

I'd also add upgrading during the clock change means it's less likely you'll run into issues double-running scripts scheduled for 1:30am, as presumably the database will be unavailable at 1:30 +1:00 and/or +1:30 +00:00.

Rating

  (1 rating)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Graham, October 07, 2020 - 2:21 pm UTC

Hi Chris,

Thank you so much for your quick response and for taking the time to ask around within Oracle.

I guess it was more to do with my cautious approach than anything else but I'm pleased I double checked - although I may have to hold back on telling my managers they had a good idea, wouldn't want them to get carried away with themselves!

It's also interesting about the UTC element and how it could play a role when performing clusterware upgrades and/or patching when it doesn't have an SCN as such to keep track of time.

Thanks once again for your work, you've been a big help.

Graham
Chris Saxon
October 07, 2020 - 6:15 pm UTC

:)

Happy to help.

Like I said, you're getting the extra hour that night anyway. So unless management is explicitly asking you to do this during the clock change or similar time constraints, it's up to you when you use it ;)

More to Explore

Administration

Need more information on Administration? Check out the Administrators guide for the Oracle Database