November 20, 2015 at 6:29 am
Brandie Tarvin (11/20/2015)
Nothing like staying up late two nights in a row to do releases, get called back ten minutes after the second release to be told I forgot to move scripts, and then have a brisk discussion with everyone involved to explain why those scripts didn't get moved.ME: "Those scripts weren't on the move sheet and I don't move anything that I wasn't told to move."
Others: "But the scripts are in X folder."
ME: "Lots of scripts are in that folder. I am not going to run every script in that folder because some of them aren't ready to be moved yet. And you haven't given me a list of scripts to run, and there is nothing from the Y team indicating that there are additional scripts to run. Sorry. Not breaking production on your say so."
It wasn't quite that bad, but I'm exhausted this morning and everyone's running around here in semi-panic mode. "Where are the scripts?"
Sounds tough. Sorry.
Move sheets, drop folders... Love to do a class on deployment methodologies and best practices. More automation is better than less automation.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
November 20, 2015 at 6:41 am
So, it's looking like we're going to get our first snow of the year tomorrow night or so...
3-6", and it looks like they're predicting it'll be that nasty rain / snow mix that you can't really shovel...
yay
November 20, 2015 at 6:43 am
jasona.work (11/20/2015)
So, it's looking like we're going to get our first snow of the year tomorrow night or so...3-6", and it looks like they're predicting it'll be that nasty rain / snow mix that you can't really shovel...
yay
And then it'll be that nasty ice / snow mix that you can't really make snowballs with, unless you want to take someone's eye out. @=(
November 20, 2015 at 6:48 am
jasona.work (11/20/2015)
So, it's looking like we're going to get our first snow of the year tomorrow night or so...3-6", and it looks like they're predicting it'll be that nasty rain / snow mix that you can't really shovel...
yay
Just looking at flurries here.
In about four months spring!
November 20, 2015 at 6:52 am
Brandie Tarvin (11/20/2015)
jasona.work (11/20/2015)
So, it's looking like we're going to get our first snow of the year tomorrow night or so...3-6", and it looks like they're predicting it'll be that nasty rain / snow mix that you can't really shovel...
yay
And then it'll be that nasty ice / snow mix that you can't really make snowballs with, unless you want to take someone's eye out. @=(
Yup, it's going to be lovely out tomorrow. It's time to welcome to winter to Michigan. The recent NOAA winter weather watch is putting it at 5" or more, which isn't as much as Steve got earlier this week.
November 20, 2015 at 8:56 am
Brandie Tarvin (11/20/2015)
Nothing like staying up late two nights in a row to do releases, get called back ten minutes after the second release to be told I forgot to move scripts, and then have a brisk discussion with everyone involved to explain why those scripts didn't get moved.ME: "Those scripts weren't on the move sheet and I don't move anything that I wasn't told to move."
Others: "But the scripts are in X folder."
ME: "Lots of scripts are in that folder. I am not going to run every script in that folder because some of them aren't ready to be moved yet. And you haven't given me a list of scripts to run, and there is nothing from the Y team indicating that there are additional scripts to run. Sorry. Not breaking production on your say so."
It wasn't quite that bad, but I'm exhausted this morning and everyone's running around here in semi-panic mode. "Where are the scripts?"
This is why we preach the pipeline and automation at Redgate (and I've done at other jobs). This is the type of stuff that should be caught in QA or a staging/pre-prod environment. Then whatever is run there is run in prod.
November 20, 2015 at 11:41 am
jasona.work (11/19/2015)
Just for Jeff Moden:How to get the date from SQL Server.
Sample data required: None
Queries:
SELECT SYSDATETIME();SELECT SYSDATETIMEOFFSET();
SELECT SYSUTCDATETIME();
SELECT CURRENT_TIMESTAMP();
SELECT GETDATE();
SELECT GETUTCDATE();
:hehe:
Was the syntax error deliverate? :hehe:
Of course having seen the st of 6 I had to run them, and something rather strange showed up. (Please forgive an injection of technical trivia into the thread.)
The interesting thing about this lot if that if you run them (with the error corrected) like that using SSMS with SQL Server 2014 you almost always (on my laptop more than 99% of runs - less that 1% of the time the values are the same) get two different values - the first three functions give one value, and the second three another. Of course the second set of three calls round to 3ms (ms not mcs - at least one threadizen has misinterpreted my ms as mcs in the past) and they always round down, so the value from the first three is later than the value from the second three, which is not at all surprising. What is surprising is that the first three often deliver a value more than 3ms later than the second three which ought to be impossible if they are run in the given order.
The frequency of large differences fluctuates a lot when I test for it - typically a run of 1000 measurements will turn up 20% or a little more differences lying between 3 and 4 ms and less than 1% higher than 4 ms, but the difference was more than 8ms in 3% of my last trial of 1000 measurements, and more than 10ms in 1.8%; I've observed differences as big as 16ms, but those are seem to be very rare, and had runs of 1000 checks where two thirds of the differences exceded 3ms. Is something somewhere adjusting the order in which separate queries in a batch are run - that would seem to be very dangerous if it is happening - or are three of these six current time functions frequently inaccurate by more than 3 milliseconds?
Tom
November 20, 2015 at 11:54 am
TomThomson (11/20/2015)
jasona.work (11/19/2015)
Just for Jeff Moden:How to get the date from SQL Server.
Sample data required: None
Queries:
SELECT SYSDATETIME();SELECT SYSDATETIMEOFFSET();
SELECT SYSUTCDATETIME();
SELECT CURRENT_TIMESTAMP();
SELECT GETDATE();
SELECT GETUTCDATE();
:hehe:
Was the syntax error deliverate? :hehe:
Of course having seen the st of 6 I had to run them, and something rather strange showed up. (Please forgive an injection of technical trivia into the thread.)
The interesting thing about this lot if that if you run them (with the error corrected) like that using SSMS with SQL Server 2014 you almost always (on my laptop more than 99% of runs - less that 1% of the time the values are the same) get two different values - the first three functions give one value, and the second three another. Of course the second set of three calls round to 3ms (ms not mcs - at least one threadizen has misinterpreted my ms as mcs in the past) and they always round down, so the value from the first three is later than the value from the second three, which is not at all surprising. What is surprising is that the first three often deliver a value more than 3ms later than the second three which ought to be impossible if they are run in the given order.
The frequency of large differences fluctuates a lot when I test for it - typically a run of 1000 measurements will turn up 20% or a little more differences lying between 3 and 4 ms and less than 1% higher than 4 ms, but the difference was more than 8ms in 3% of my last trial of 1000 measurements, and more than 10ms in 1.8%; I've observed differences as big as 16ms, but those are seem to be very rare, and had runs of 1000 checks where two thirds of the differences exceded 3ms. Is something somewhere adjusting the order in which separate queries in a batch are run - that would seem to be very dangerous if it is happening - or are three of these six current time functions frequently inaccurate by more than 3 milliseconds?
The syntax error was a goof on my part when I posted it...
If I recall from the MSDN page, the first three are a higher precision than the latter three, so that may account for some of the differences.
November 20, 2015 at 12:08 pm
This is what I looked at:
SELECT CURRENT_TIMESTAMP- SYSDATETIME() 'CURRENT_TIMESTAMP- SYSDATETIME()',
SYSDATETIME() 'SYSDATETIME()',
SYSDATETIMEOFFSET() 'SYSDATETIME()',
SYSUTCDATETIME() 'SYSUTCDATETIME()',
CURRENT_TIMESTAMP 'CURRENT_TIMESTAMP',
GETDATE() 'GETDATE()',
GETUTCDATE() 'GETUTCDATE()'
CURRENT_TIMESTAMP- SYSDATETIME() was either
1899-12-31 23:59:59.997
or
1900-01-01 00:00:00.000
412-977-3526 call/text
November 20, 2015 at 1:03 pm
jasona.work (11/20/2015)
If I recall from the MSDN page, the first three are a higher precision than the latter three, so that may account for some of the differences.
The lower precision of the latter three can account for a discrepancy of up to 3ms. The problem is that there are sometimes higher discrepancies, which could only be accounted for if either the later function call is rounding to a time more than 3ms earlier than the earlier function call or the queries were executed in an order different from that in which they were written.
Tom
November 22, 2015 at 12:20 pm
robert.sterbal 56890 (11/20/2015)
This is what I looked at:SELECT CURRENT_TIMESTAMP- SYSDATETIME() 'CURRENT_TIMESTAMP- SYSDATETIME()',
SYSDATETIME() 'SYSDATETIME()',
SYSDATETIMEOFFSET() 'SYSDATETIME()',
SYSUTCDATETIME() 'SYSUTCDATETIME()',
CURRENT_TIMESTAMP 'CURRENT_TIMESTAMP',
GETDATE() 'GETDATE()',
GETUTCDATE() 'GETUTCDATE()'
CURRENT_TIMESTAMP- SYSDATETIME() was either
1899-12-31 23:59:59.997
or
1900-01-01 00:00:00.000
You are reading all the functions in a single query, rather than in separate queries, so (a) the optimiser is free to do a reasonable amount or reordering and (b) the data engine may read the clock only once for all three items and also your subtraction does implicit type conversion between datetime and datetime2 with a result that supports only abut a third of the millisecond values.
I tested with consectutive queries, assigning the function's return value to datetime2 variables, and then looked at the microseconds difference between the two using datediff - so (a) the optimser should not have been free to reorder the statements, and hence should not have reordered the function calls and (b) the function calls being in different queries should ensure that the clock was read at least twice (but maybe not six times), and also I could see the cases where the more precise functons delivered times with something other than the lower precision functions returned.
I would have been happy if my results had been similar to yours (in that all the discrepancies were small enough to have been caused by rounding ms to 10x+0, 10x+3, or 10x+7 in the low precision functions); the worrying thing is that they weren't. The precision difference could be expected to generate diffenences greater than 3ms and less than or equal to 4ms about 10% of the time, but it's consistently higher than that and there's no way the precision difference can account for any discrepancies at all larger than 4 ms.
Tom
November 22, 2015 at 1:18 pm
I think the spam bomb went off again today.
November 22, 2015 at 1:48 pm
Ed Wagner (11/22/2015)
I think the spam bomb went off again today.
I guess you are not referring to TT's posts:-D
😎
November 22, 2015 at 3:52 pm
The spam this weekend is insane... is the filter taking the weekend off?
November 23, 2015 at 6:15 am
Hey, guys, we have a language conversion question over here. Can anyone assist with this?
Viewing 15 posts - 51,556 through 51,570 (of 66,738 total)
You must be logged in to reply to this topic. Login to reply