June 10, 2015 at 8:14 pm
Comments posted to this topic are about the item Practical Hekaton
June 11, 2015 at 6:55 am
Microsoft has always, always released what they had and then improved it later. Every product they have has gone through this. The initial products were frequently derided, but after a few iterations, became worldbeaters. And this doesn't even deserve derision. This is a useful tool that isn't as useful as it could be. If we waited for everything to be perfect before release, we'd still be using typewriters.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
June 11, 2015 at 6:56 am
Just my two sense but we are a small implementation of SQL and now going thru justification for upgrading. The business won't benefit if its not complete, stable and usable. I'm sure for many it's knee-jerk comments center around the pains of upgrade justification (price structure) and the upgrade itself. When I attended the Orlando conference the In-memory OLTP table was a lot of the hype. Maybe I miss-read.
Michael
June 11, 2015 at 7:13 am
Sioban Krzywicki (6/11/2015)
Microsoft has always, always released what they had and then improved it later. Every product they have has gone through this. The initial products were frequently derided, but after a few iterations, became worldbeaters. And this doesn't even deserve derision. This is a useful tool that isn't as useful as it could be. If we waited for everything to be perfect before release, we'd still be using typewriters.
The first-ever typewriter was perfect? 🙂
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
June 11, 2015 at 7:18 am
Phil Parkin (6/11/2015)
Sioban Krzywicki (6/11/2015)
Microsoft has always, always released what they had and then improved it later. Every product they have has gone through this. The initial products were frequently derided, but after a few iterations, became worldbeaters. And this doesn't even deserve derision. This is a useful tool that isn't as useful as it could be. If we waited for everything to be perfect before release, we'd still be using typewriters.The first-ever typewriter was perfect? 🙂
Nope, but it wasn't software either.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
June 11, 2015 at 7:31 am
I agree that Microsoft should allow people to use a new product once it is stable. Software needs to be used to know what features users are going to want why spend a lot of time building in features you think users will want. If the software is not ready for your own use it will be as others use it and work to improve it for the rest of us. It also allows the core of the software to be used and tested in real world situations so any core improvements can be identified and fixed.
June 11, 2015 at 7:58 am
I've been reading over this.
SQL Server 2016 - What's New in Database Engine
https://msdn.microsoft.com/en-us/library/bb510411(v=sql.130).aspx#Feature
It seems that Microsoft is leveraging SQL Server's two-year release cycle to introduce new features with incrementally enabled functionality. This is good news for those who are the cutting edge with large scale data warehouse or OLTP systems, those for whom Clustered ColumnStore or In-Memory tables are game changer and those whose IT budget provides room for upgrades, research, and new development.
However, for most SQL Server users, it's confusing when attempting to keep tabs on all the limitations and asterisks surrounding things like: Heckaton's compiled procedures can only reference Heckaton tables or ColumnStore's lack of support for primary keys or unique constraints.
It's like walking into a shiny new office building, hitting the wrong button on the elevator, and finding yourself staring into a dark unfinished hallway with exposed wiring.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 11, 2015 at 8:39 am
There is a price in learning for users, who mentally hold on to limitations that no longer matter because they learned them in an earlier version. I'm too embarrassed to admit my own mistakes in this area, but think of the fellow who went through changing "IF EXISTS (select * from table)" to "IF EXISTS (select 1 from table)" long after the optimizer started treating them the same. Or kept using 8.3 filenames that would never go near a FAT filesystem.
I figure it's still totally worth it for all the reasons mentioned here, though.
June 11, 2015 at 8:41 am
The fact that Steve has to call for someone/anyone to step forward to share their experience says rather loudly that the technology isn’t widely used. It will be interesting to see if there is a quality response.
June 11, 2015 at 8:42 am
Eric M Russell (6/11/2015)
However, for most SQL Server users, it's confusing when attempting to keep tabs on all the limitations and asterisks surrounding things like: Heckaton's compiled procedures can only reference Heckaton tables or ColumnStore's lack of support for primary keys or unique constraints.
It's like walking into a shiny new office building, hitting the wrong button on the elevator, and finding yourself staring into a dark unfinished hallway with exposed wiring.
Completely agree here. The marketing often gets in the way of realities and many people are disappointed when they can't use something or don't realize it works in only certain ways
June 11, 2015 at 8:56 am
Steve Jones - SSC Editor (6/11/2015)
Eric M Russell (6/11/2015)
However, for most SQL Server users, it's confusing when attempting to keep tabs on all the limitations and asterisks surrounding things like: Heckaton's compiled procedures can only reference Heckaton tables or ColumnStore's lack of support for primary keys or unique constraints.
It's like walking into a shiny new office building, hitting the wrong button on the elevator, and finding yourself staring into a dark unfinished hallway with exposed wiring.
Completely agree here. The marketing often gets in the way of realities and many people are disappointed when they can't use something or don't realize it works in only certain ways
I'm not saying the two-year cycle is a bad idea; it makes sense from a financial and competitive perspective. By introducing ColumnStore and Heckaton into the market two years early; that no doubt gave SQL Server an edge for many organizations weighing it's features against Oracle. Releasing a set (or sub-set) of deliverables to production that are essentially complete (with known and documented limitations), and then following that up with another release (perhaps based on feedback), that's actually the same development cycle that most of us practice within our own IT shops.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 11, 2015 at 9:06 am
Last night at our PASS Chapter user group we had a gentleman that has moved many of his servers to 2014 and he did a great talk on the troubles and work around's.
Specifically queries that would run fine in 2012 and not in 2014.
His suggestion you could always go to compatibility mode 2012 and then when you are ready switch it back to 2014.
Another workaround was using a trace flag, which it would require higher privileges to run.
Is this common practice and should it be?
June 11, 2015 at 10:32 am
jwbart06 (6/11/2015)
Last night at our PASS Chapter user group we had a gentleman that has moved many of his servers to 2014 and he did a great talk on the troubles and work around's.Specifically queries that would run fine in 2012 and not in 2014.
His suggestion you could always go to compatibility mode 2012 and then when you are ready switch it back to 2014.
Another workaround was using a trace flag, which it would require higher privileges to run.
Is this common practice and should it be?
yes. Many companies might upgrade to the new version for various reasons, but have a db or two that cannot move. So they set it to a lower compatibility mode. There are trace flags for some things, not all,but those work as well.
June 11, 2015 at 10:54 am
jwbart06 (6/11/2015)
Last night at our PASS Chapter user group we had a gentleman that has moved many of his servers to 2014 and he did a great talk on the troubles and work around's.Specifically queries that would run fine in 2012 and not in 2014.
His suggestion you could always go to compatibility mode 2012 and then when you are ready switch it back to 2014.
Another workaround was using a trace flag, which it would require higher privileges to run.
Is this common practice and should it be?
Does anyone know of a resource that lists specific issues that prevent migration of a database from v2008R2 to v2014?
This lists several issues for 2012, but for 2014 it says only "No new issues".
Breaking Changes in SQL Server 2014
https://msdn.microsoft.com/en-us/library/ms143179.aspx#SQL14
This lists only one issue related to queries against an XML documents and lengths of strings more than 4020 characters.
Behavior Changes in SQL Server 2014
https://msdn.microsoft.com/en-us/library/ms143359.aspx
I guess Microsoft never went back and updated these lists in MSDN for v2014, but the preview release of v2016 is already out by now.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 11, 2015 at 11:09 am
I was just reading about upgrades to 2014 yesterday. Apparently the cardinality estimator changed for SQL 2014 and that can cause some queries to have degraded performance compared to how they ran in earlier versions. The only advice I have seen is to test important queries in both compatibility modes.
Note about it with links from Thomas LaRock:
http://thomaslarock.com/2014/06/upgrading-to-sql-server-2014-a-dozen-things-to-check/
I am also glad to hear that we are not the only ones with questions about Hekaton usage in the real world. I have read a lot of hype about it but have yet to see any real-world examples. I look forward to whatever info people can share on this.
Viewing 15 posts - 1 through 15 (of 23 total)
You must be logged in to reply to this topic. Login to reply