July 30, 2015 at 8:15 pm
Comments posted to this topic are about the item How To Keep Up with SQL Server
July 31, 2015 at 7:23 am
Do you need to keep up with the latest features of the latest SQL Server? Why would I ask such a question?
Many organizations are conservative and budget conscience. You may be lucky enough to be in one that upgrades constantly or has skipped some versions. Or you may be a MVP that's giving a talk at PASS and need new material. 😛
Many of us are just now absorbing updates to SQL Server 2012 or are stuck on 2008R2. Or we have clients that don't have enterprise licenses for all the "fancy" features or can't put highly sensitive data on Azure. Or we deal with applications that just use the "bread and butter" features of SQL Server, so there's not yet a need to invest the time in features that may not help us.
Also jumping on the newest version requires extra awareness. See the issues that the users of Window 10 and .NET 4.6 have encountered this week. By waiting for the pioneers to collect the arrows in their butts, the wise avoid the pain of early adaption. (And it gives time for fixes and the second wave of books with the corrected examples. )
So if you are upgrading or playing with the latest software, you have my thanks! Please test and document your experience so I have a smooth path when I'm allowed to upgrade to 2016. (Sometime in 2021, probably...)
:hehe:
July 31, 2015 at 8:19 am
Chris, I've worked at those kinds of orgs, they certainly exist and their strategy isn't wrong. Spend money where it matters. But the reason for "keeping up" is to be employable for the next job, which might be a startup starting out at 2014/2016 or one that believes in staying on current or near current version. I think it's reasonable to tell the next prospective employer that your last one was sticking with 2008 and so you haven't used 2014 much, but I don't think it's reasonable to say you've spent no time learning the features of 2014 because your current employer doesn't use it.
July 31, 2015 at 9:02 am
We're still on 2008 R2 and don't see us leaving anytime soon. It's hard keeping up with features of new releases that you can never really practice with in your job.
July 31, 2015 at 9:42 am
chrisn-585491 (7/31/2015)
Do you need to keep up with the latest features of the latest SQL Server? Why would I ask such a question?Many organizations are conservative and budget conscience. You may be lucky enough to be in one that upgrades constantly or has skipped some versions. Or you may be a MVP that's giving a talk at PASS and need new material. 😛
Many of us are just now absorbing updates to SQL Server 2012 or are stuck on 2008R2. ...
So if you are upgrading or playing with the latest software, you have my thanks! Please test and document your experience so I have a smooth path when I'm allowed to upgrade to 2016. (Sometime in 2021, probably...)
:hehe:
Or are stuck on SQL 6.5 like some of my clients. So the upgrade to 2016 in 2021 seems like a warp-speed adoption rate for some of my clients.:crying:
But I do advocate staying abreast of the new features. It's one of the tools to use advocate adopting the newer versions of SQL Server for the clients. Or, in some cases, at least being able to speak to the topic when a client asks about the upgrade.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
July 31, 2015 at 9:47 am
Thanks for the great ideas on staying relatively current. New and changed feature lists are very helpful. Also very important are deprecated features. If these are at all pervasive in our applications a work around strategy is one of the first issues that need to be addressed.
July 31, 2015 at 11:32 am
You do need to at least be aware of new stuff, even your current employer is stuck in the past. Few reasons:
Firstly, if you're looking for a new job. One thing I'll often ask in an interview is what feature of the latest/next version the interviewee likes. It's a way of telling whether the person is someone who's going to learn on their own or someone who I'll have to force information on.
Second, as the data professional in your company, you may be asked to motivate for an upgrade. Or you may find that something the company's currently struggling with would be trivial with a feature from a newer version.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
July 31, 2015 at 12:50 pm
When I interview for a job, the up-to-dateness of SQL (and Office) is a big consideration.
I don't want my skills to go rusty by going back to SQL 2008. And, I don't want to be limited to technologies I was using 5+ years ago either.
However much they're paying, it's not worth the risk of dead-ending my career in a job that doesn't give me any new marketable skills.
Leonard
Madison, WI
July 31, 2015 at 12:50 pm
chrisn-585491 (7/31/2015)
Do you need to keep up with the latest features of the latest SQL Server? Why would I ask such a question?Many organizations are conservative and budget conscience. You may be lucky enough to be in one that upgrades constantly or has skipped some versions. Or you may be a MVP that's giving a talk at PASS and need new material. 😛
...
One reason why some organizations are reluctant to upgrade is that they are unaware of the benefits that a newer release has to offer. They are unaware, because their IT is unware. But you should consider it part of your job to keep up to date on SQL Server, so you can then sell the idea to executive management.
For example, if your organization has a data warehouse with huge flat tables, and your reports currently take hours to complete on SQL Server 2008, then upgrading to SQL Server 2014 and leveraging Clustered ColumnStore would be a game changer. I'm talking about 75% reduction in the size of your tables and 90% reduction in the runtime of your queries.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 31, 2015 at 7:52 pm
It used to be bad enough just to keep up with the new features and when to use them. Lately, a new wrinkle has been added to the mix that I have absolutely no appreciation for and, to be honest, wish that Microsoft would stop doing.
Here's one classic example that I'm doing a lightning presentation for...
First, we create some test data... a simple column of whole dates...
--===== If the test table already exists,
-- drop it to make reruns in SSMS easier
IF OBJECT_ID('tempdb..#MyHead','U') IS NOT NULL
DROP TABLE #MyHead
;
--===== Create a million random dates as the DATETIME
-- datatype for the 2010 decade and store them in
-- a Temp Table. This only takes a second.
SELECT TOP 1000000
SomeDate = DATEADD(dd,
ABS(CHECKSUM(NEWID()))
% DATEDIFF(dd,'2010','2020'),
'2010')
INTO #MyHead
FROM sys.all_columns ac1
CROSS JOIN sys.all_columns ac2
;
Then, we compare the FORMAT function to the classic CONVERT function...
PRINT '--===== CONVERT mm/dd/yyyy (101) ==========';
SET STATISTICS TIME,IO ON;
DECLARE @Bitbucket CHAR(10);
SELECT @Bitbucket = CONVERT(CHAR(10),SomeDate,101) --mm/dd/yyyy
FROM #MyHead;
SET STATISTICS TIME,IO OFF;
GO
PRINT '--===== FORMAT MM/dd/yyyy w/o Datatype Match =========='
SET STATISTICS TIME,IO ON;
DECLARE @Bitbucket CHAR(10);
SELECT @Bitbucket = FORMAT(SomeDate,'MM/dd/yyyy')
FROM #MyHead;
SET STATISTICS TIME,IO OFF;
GO
PRINT '--===== FORMAT MM/dd/yyyy w/ Datatype Match =========='
SET STATISTICS TIME,IO ON;
DECLARE @Bitbucket NCHAR(10);
SELECT @Bitbucket = FORMAT(SomeDate,N'MM/dd/yyyy')
FROM #MyHead;
SET STATISTICS TIME,IO OFF;
GO
... and the results clearly demonstrate my exasperation with many so called "improvements"...
--===== CONVERT mm/dd/yyyy (101) ==========
Table '#MyHead_____________________________________________________________________________________________________________000000000023'. Scan count 1, logical reads 2101, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
CPU time = 860 ms, elapsed time = 855 ms.
--===== FORMAT MM/dd/yyyy w/o Datatype Match ==========
Table '#MyHead_____________________________________________________________________________________________________________000000000023'. Scan count 1, logical reads 2101, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
CPU time = 39343 ms, elapsed time = 41775 ms.
--===== FORMAT MM/dd/yyyy w/ Datatype Match ==========
Table '#MyHead_____________________________________________________________________________________________________________000000000023'. Scan count 1, logical reads 2101, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
CPU time = 38782 ms, elapsed time = 40208 ms.
[font="Arial Black"]Seriously???? 44 Times Slower??? :sick:[/font]
Another fine example is for running totals. See the following URL...
http://blog.waynesheffield.com/wayne/archive/2011/08/running-totals-in-denali-ctp3/#codesyntax_1
Yeah, I know that's a while ago and I haven't tested it since Wayne wrote that but, seriously??? Running totals that are more than 7 times slower than a Quirky Update? What did they do behind the scenes? Write it as a recursive CTE??? :Whistling::sick:
--Jeff Moden
Change is inevitable... Change for the better is not.
August 1, 2015 at 7:48 am
Eric, I'm cautious about "advocating". Too often we in IT push version next "just because", where the because is often more about our own worry of falling behind on skills than any real needs. Certainly that isn't always the case. I find that changes the increase limits or remove limitations are things they like to hear, new capabilities less so unless they are code free changes. For example, backup compression was a nice win because we could show space saved and it required only a config change (and a minor one). But to your point, if you don't know what is there, you can't at least put it on the options to explore list when challenges arise.
August 1, 2015 at 7:51 am
Jeff, I appreciate you digging into stuff like that, it's why we need the early experimenters and the early adopters. I'd like to think that v.Next is always better/faster/stronger than v.Current, but there are exceptions and those exceptions can be a killer. We just had this conversation at work recently, one database left on 2008 that wasn't targeted to upgrade to 2012 and now a dependency has been discovered - can we just upgrade it? Sure! Odds are it doesn't use any deprecated feature, but we can't guarantee performance, it has to be tested. It would be nice to never have that worry about an upgrade!
August 1, 2015 at 5:10 pm
Thanks for the feedback, Andy.
Ironically, I love revisions of SQL Server that are out of date, like 2005 and 2008. Think about it. They're as stable as they going to get and you don't have to worry about an SP or CU that's going to be a real killer such as what recently happened with 2014 or like the online rebuild of databases in 2012 causing corruption. Yeah, I might miss out on the newest bright shiny object until sometime well into the future but I don't have to worry about that new object being slower or causing problems. I also hate it when something that's incredibly useful or something that has been a part of the system nearly forever is suddenly deprecated for one reason or another.
Since it would appear that they've fixed all the new and regression problems in 2012, we're finally upgrading from 2005 to 2012. We'll upgrade to 2016 sometime in 2018 or 2020 because I hate "death by early adoption". 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
August 3, 2015 at 2:50 am
I think this is a really good article. I'm a dev, not a DBA and I read SSC partly to keep up with changes to SqlServer, as well as to improve my SQL skills. I think I already mentally classify new features as don't care/interesting, but I love the idea of the page with description and drilll-down details .
August 3, 2015 at 6:40 am
Jeff Moden (7/31/2015)
It used to be bad enough just to keep up with the new features and when to use them. Lately, a new wrinkle has been added to the mix that I have absolutely no appreciation for and, to be honest, wish that Microsoft would stop doing.Here's one classic example that I'm doing a lightning presentation for...
...
CONVERT(CHAR(10),SomeDate,101) --mm/dd/yyyy
...
FORMAT(SomeDate,N'MM/dd/yyyy')
...
Apparently the implementation of the FORMAT() function is entirely differernt (and several orders of magnitude less optimized) than the legacy CONVERT() function. However, essentially these functions perform the same task: accepting a string and a formatting code. The design team for SQL Server could have used something like... I think it's called delegation (?)... so that FORMAT() would simply be a declarative wrapper for the CONVERT() function.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply