Skip to main content
commvault.com commvault.com
Solved

Anybody else seen issues with the start of Daylight Savings Time?

N
Byte
Forum|alt.badge.img+3

I realise that here in the UK we start daylight savings later than they do in the US, but has anybody else experienced any problems with it?

 

Over the weekend, the majority of our commserves running 11.32 saw a large number (between 40 and 60) SQL Server processes killed within 10 minutes of the start of British Summer Time. This largely went unnoticed as far as the Commvault event log was concerned, although one of them did log a couple of 19:152 errors.

 

This only happened on the commserves running 11.32 - all the ones running 11.24 saw no spids killed.

 

I’ve opened a support case, but was wondering if anybody whose clocks changed last week could check their commserve’s SQL Server errorlog for me for the period immediately after the clocks changed (between 02:00 and 02:10 on 31st March for those in the UK).


Thanks
Neil

 

Best answer by Neil S

Latest update on the support case I opened with Commvault for this issue:

“The Development team informed us that the SQL Agent Job does not consider the time change currently.  Starting SQL Server 2022 can access the time zone via CURRENT_TIMEZONE_ID() and be independent of the Commserv database, but earlier releases require the Commserv database to determine the server time zone.

The development team informed to create a CMR”

CMR 441661 has been created and has a current status of “On Roadmap”. Hopefully a fix will be delivered by next Spring.

Neil

 

 

View original
Did this answer your question?

4 replies

A
Vaulter
Forum|alt.badge.img+15

Hello @Neil S 

Thanks for the great question and flagging these issues you have seen.
I have done a quick review of the tickets over the past week to see if there as any trend and i could not see anything. 

If anyone else has seen similar issues lets hope they find this thread and share their experiences. 

This was a one off event? It has not reoccurred and is resolved as of now?

Kind regards
Albert Williams

The best way to learn anything, is to question everything
N
Byte
Forum|alt.badge.img+3
  • Neil S
  • Author
  • Byte
  • 5 replies
  • April 3, 2024

Hello @Albert Williams

 

Thanks for taking the time to review the tickets. Yes, as far as I can see this was a one-off event that affected multiple commcells within a few minutes of the start of daylight savings. There has been no recurrence and, again in so far as I am aware, no lasting impact.

 

Regards

Neil

A
1 person likes this
  • A
    Albert Williams
N
Byte
Forum|alt.badge.img+3
  • Neil S
  • Author
  • Byte
  • 5 replies
  • Answer
  • April 8, 2024

Latest update on the support case I opened with Commvault for this issue:

“The Development team informed us that the SQL Agent Job does not consider the time change currently.  Starting SQL Server 2022 can access the time zone via CURRENT_TIMEZONE_ID() and be independent of the Commserv database, but earlier releases require the Commserv database to determine the server time zone.

The development team informed to create a CMR”

CMR 441661 has been created and has a current status of “On Roadmap”. Hopefully a fix will be delivered by next Spring.

Neil

 

 

A
1 person likes this
  • A
    Albert Williams
A
Vaulter
Forum|alt.badge.img+15

Thanks for the update @Neil S 

 

Really appreciate keeping the post updated so in the future people will see this. Love your work.

Can you mark this post as answered. 

 

Kind regards

Albert Williams

The best way to learn anything, is to question everything

Reply


Most helpful members this week

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings