''Various flavours of Linux''
and then mention a few distros; no mention of hardware platform. Red Hat, for instance, runs on x86, power PC, IBM mainframe, ARM -- is it available on all of these or just Intel compatible ?
“It’s a big milestone for us as a company,” general manager Rohan Kumar told us, referring to the release of SQL Server on Linux, “the biggest server product from Microsoft”, announced here at the Ignite event in Orlando. SQL Server 2017 is being released simultaneously for Windows and various flavours of Linux: Red Hat …
usually the compatibility problems between different 'flavours' (or 'flavors' if you're in the U.S.) is caused by linking with shared libs. If you static link instead [my preference] you can simply load the binaries into the correct places because Linux is Linux except for userland.
So, in theory, they could link static "everything" and then release as a tarball with a shell script to install it.
All of that Linux shared lib "DLL HELL" is like a bad echo of "what's wrong with Windows" anyway...
[if this potentially violates the GPL they can use clang instead of gcc, or ship their own binaries for their own shared libs along with the source for those libs]
Not sure where all the downvotes derive from. At least in my industry, static linking as much as possible (ie everything but libc+pthread/msvc*) is the sensible thing to do. But thats a highly regulated industry where post final build, a new version can take weeks to months and i guess six or seven figure monies until it can be shipped in any market. After that it should be frozen, but with the bad bad internet you still have to accept that turning off o/s security updates is probably not the best option and hope for the relevant authorities to accept the o/s somewhat changes underneath (bar APIs, i hope).
"We are going to go aggressively, with the value of SQL Server and the price point compared to, for example, Oracle.”
Yeah, I think SQL Server on Linux is great, it works OK and the base product is as usable as it's Windows cousin, minus the features already mentioned in the article. However when it comes to Linux you're going to have to compete at the price point of PostresSQL, MySQL and obviously with the big data NoSQL boys like Hive, Mongo and CouchDB!
Don't know about the others, but I have used Postgresql for over 10 years (20?), including for telecomms billing, and have never had any reliability issues. The documentation is accurate too, although sometimes it was not so easy to find what you want, its getting much better.
I would not touch Oracle with a barge pole at any price (I have one in the back yard for exactly that purpose, and so far, it has been there for over 10 years). Their Y2K response was the last straw for me.
Yes I do use Mariadb too. I have a long spoon handy for that.
Anyway, why on earth would you put your data in a closed source environment where you could be subject to vendor lock-in? (Oh, never used Oracle then).
MS probably expects to profit from big Oracle installations which may change to SQL Server. These people can pay. If the choice is between earning 5,000,000$ for install from 1,000 users or 1,000$ from 50,000 (numbers are random), obviously the first is far more profitable for MS.
Besides, it would be difficult to compete on a different basis on Linux than Windows, while keeping feature parity - or do you expect SQL Server to compete on features on Windows, while on Linux to competes on price?
It is really good news that MS seems to be serious in bringing SQL Server to Linux. I worked with Oracle 5.1 on a Sperry U5000/30 in 1989, and today with Oracle 11 on Linux.
Except from some standard views, it did not change much, including lacking command line editing features in sqlplus, which MySql offers by default. New is the support by support engineers from India, which do their best, even when trying to speak understandable English through an over allocated ip-phone connection is a challenge. The NATO alphabet is a great assistant for solving technical Oracle issues.
But hey, what can one expect for $ 5,000-$10,000/cpu license.
Competition is good, maybe Oracle will one day start to make its stuff better, and provide better tooling for the sysadmin instead of sqlplus from the early 80's.
Completely agree. Other than at the very top end where all bets are off (e.g. banking, 1000s of simultaneous writes a second), Oracle seems overly fiddly and expensive to set up and run, especially when RAC is in the mix, and RAC is often upsold when it's really not needed.
Honest question - not wishing to troll here.
Microsoft will never put as much effort into the Linux variant as they do for Windows, and when running on Linux, SQL Server will always be calling the OS through a translation layer. Perhaps on the same hardware SQL Server + Translation Layer + Linux will be faster than SQL Server + Windows 10 but it's in Microsoft's best interests to make sure this isn't true.
So what's the point?
To a certain extent that might be true. They did not port older windows libraries to Linux, so existing SQL Server databases can not be ported to Linux/SQL Server without breaking compatibility with existing windows applications.
In case someone needs to build a reasonably sizable web application which needs a database, Sql Server on Linux provides a very welcome middle of the road solution, somewhere between MySQL and Oracle/IBM DB2.
On the other hand, Microsoft realized times are changing fast, and it needs to move beyond the desktop monopoly they still have, since desktops are becoming increasingly irrelevant. It seems improbable that they would release sub-par Linux products just to prove that "Windows is better" since that is a discussion which was already moot 10 years ago.
They however will continue to limit full compatibility not to endanger the existing windows installed base.
Hi this is Tobias Ternstrom from the Microsoft Database Systems product team.
First of all, I want to assure you we are working hard on bringing the missing features from Windows to SQL Server on Linux, having any features missing in our Linux version was something that we really wanted to avoid. The reason we did not get all features into the SQL Server 2017 database engine on Linux is really simply about the amount of engineering work needed, i.e. do we push out the release date or release iteratively. For our first release on Linux we prioritized performance & scale, security, app compatibility, and having a solid Linux sysadmin experience. Compatibility is a huge area (i.e. between Windows and Linux) and as you see we decided to go with an iterative approach. Given how our PAL is architected most features make it in without special "Linux-work", however features that integrate with the operating system or other processes require additional work. Good examples of such features include our HA/read-scale-out feature Availability Groups as well as Active Directory integration which both are in this release. The missing features are also such features, for example Machine Learning involves us integrating with the R or Python runtimes on Linux.
At any rate, we are working hard on closing the gaps and are determined to have an equally great database experience on Linux and Windows Server :-)
Hope this makes sense!
"Microsoft will never put as much effort into the Linux variant as they do for Windows, and when running on Linux"
"However, not everything has been ported. There are no Reporting Services or Analysis Services, nor Machine Learning Services (formerly R Services)."
"Replication is not supported, other than in the context of high availability, nor is Stretch DB, for hybrid local/Azure database storage. File Table, which exposes a SQL Server table as if it were part of the file system, does not work on Linux. Management tools remain for the most part Windows only, though command-line tools work."
So MS arn't planning on kicking Windows off the top table anytime soon it would seem.
@ John Sanders
Loads of reasons:
- You have a bunch of MS SQL DBAs that are currently only managing half your estate
- You are getting pissed off with paying Oracle for stuff that SQL is quite capable of at a lower price
- You have a technical roadmap to go Linux for OS but don't want to have to migrate all your SQL onto a Linux compatible database product
I could probably come up with a few more. Anyway - best get going or will be late for my Spanish lesson :-)
Why would Oracle be available cross platform if its a silly idea for SQL to be the same?
I think the real point is not to lose customers who are going cloudy by prefer Amazon to being locked in to Azure.
SqlServer is certainly a good enough database to compete with Oracle and cheap enough to be a viable alternatve to PostGress et all.
The MS only syntax and extensions would make porting an application from SqlServer to Postgress or MySql a fairly painful process -- so paying for an SqlServer license and porting to a Linux environment is quite doable.
"I think the real point is not to lose customers who are going cloudy by prefer Amazon to being locked in to Azure"
For most uses AWS is far more of a lockin than Azure. For instance if you write for Amazon's DB you can't run it anywhere else!
"when running on Linux, SQL Server will always be calling the OS through a translation layer"
As it says in the article, it's already doing the same on Windows:
"Even on Windows, SQL Server does its own memory and thread management via a piece called SOS (SQL Operating System)"
So I guess their claim of similar performance sound possible.
As for why someone would use it, my first thought was that people would be using it as a way of backing up or clustering their existing SQLServer databases, but they say there's no replication, so I guess not (yet).
Either way though, I think most of the people who will run it on Linux will be those who already use it on Windows and want to set up a new DB server without needing a Windows license.
I would say M-shaft sees the writing on the wall, and their server OS business (especially as a VM in a cloud-based thingy) is losing _BIG_ to Linux. The only thing that might be keeping VMs running as a windows OS is, perhaps, an instance of SQL Server... and they're losing to DBMS's that CAN run on Linux, and they're once again "leading from behind" and trying desperately to catch up.
Because the Linux file system and kernel I/O handling is SO much better than windows [and has been for a VERY long time] it's extremely lkely that SQL Server plus Translation Layer on Linux _WILL_ be faster than SQL Server on _ANY_ version of windows.
And Micro-shaft KNOWS this.
In the mean time - amazingly, a LOT of developers swallow Micro-shaft's coolaid whenever they do a massive market campaign of their latest "new, shiny". How many people drank the ".Not" and "C-Pound" coolaid? How many drank the "Silverlight" coolaid? How many are currently drinking the "UWP" Coolaid?
So if your product/business is _ALREADY_ locked into some feature that ONLY SQL SERVER has, like the way they do stored procedures, or something equally similar [I haven't followed their development direction at all since they stated deviating from NORMAL SQL stuff] that can't be done (easily) with PG or MySQL or even Oracle, and it would be WAY TOO EXPENSIVE to "re-develop" everything, then you'll have an inclination to consider running SQL Server on "something that actually has performance" like Linux.
Otherwise, for new products, I'd suggest going with the lowest common denominator on the SQL side, so that ANY DBMS can be used with your product, thus eliminating the lock-in to any ONE. But not everyone thinks the way _I_ do, unfortunately.
"Perhaps on the same hardware SQL Server + Translation Layer + Linux will be faster than SQL Server + Windows 10 but it's in Microsoft's best interests to make sure this isn't true."
That seems unlikely as Windows Server generally outperforms Linux on the same hardware in benchmarks.
"That seems unlikely as Windows Server generally outperforms Linux on the same hardware in benchmarks."
not the ones _I_ have done.
As I recall Linux and FreeBSD were around 25% faster by my own measurements. It's been a while since I tested it, but I doubt this has changed. (I used Samba 3 when I did it, on equivalent hardware). But of course, the license agreements for various windows products [even back then] had something about "not publishing the results" without approval in the EULA. But how hard is it to do a simple file copy operation across a network using equivalent hardware? Anyone can benchmark THAT, and reproduce the kinds of results I saw.
and on winders, I'd run the test by using XCOPY from the command line, and not the GUI. That'd be "more fair". Then use "smbclient" on the Linux end. That way you test both client AND server operations. Windows to Linux, Linux to Windows, Windows to Windows, Linux to Linux, with the same file, NTFS vs EXT4 (or whatever) in addition to all of that, using Samba vs Windows' internal SMB stack.
Yeah, not hard. And since then, I haven't seen nor heard of any changes in relative performance that would justify me re-running that test.
"not the ones _I_ have done."
Personally I trust posted reproducible benchmarks on the internet far more than some random commentard...
"As I recall Linux and FreeBSD were around 25% faster by my own measurements."
Well a quick Google of benchmarks on say web serving or copying large files, or file serving (inc NFS!) tend to favour recent versions of Windows...
"But how hard is it to do a simple file copy operation across a network using equivalent hardware?"
Not very, but to show all of Windows advantages you would ideally be using ReFS, an SMB 3.1 client / server and network hardware that supports TCP offloading and SMBDirect over a 10Gbit or faster connection. Then you will see lower CPU and / or better performance on Windows than Linux.
"I'd run the test by using XCOPY from the command line, and not the GUI. That'd be "more fair"."
Well there is your problem. Xcopy is not particularly performance tuned or multithreaded. Had you have used Robocopy with suitable settings I expect Windows would have come out on top.
Not really free- in my company's case, it's part of our enterprise agreement. And we pay dearly for it, I can tell you that.
I am supremely disappointed in microsoft for switching to a 'per core' licensing model for SQL server, as opposed to a per socket. (and it's really complicated- it's not how many virtual cpus you've allocated to the VM running SQL server, it's the number of cores on the hardware running the VM. (Obviously they are taking the Oracle model of licensing))
If you are _really_ into pain and suffering, you can always do 'per seat' user licensing, that model is still in effect as well.
This is the same company that decided that for running a single virtual desktop on Hyper-V, you'd need no less than four licenses/CALs: one for the server, one for Hyper-V, one for the VM, and one for the client. (They may have merged the Hyper-V license back into the server, but still... I thought the idea behind VDI was to simplify licensing costs, not complicate then to the point where the account executive has to call in a specialist who still gets it wrong...)
"you'd need no less than four licenses/CALs: one for the server, one for Hyper-V"
Hyper-V Server is and has always been completely free with all features enabled and requires no licensing.
"They may have merged the Hyper-V license back into the server"
There never was a "Hyper-v license". It's free. If you choose to run it under Windows Server you need to license Windows - but not Hyper-V. And if you run Hyper-V Server without Windows it's totally free.
don't think they haven't looked at this a lot harder than you might expect...
Windows has a built-in "license API" for things *LIKE* SQL Server. I have only looked at it in a cursory manner so I'm no expert. However, being as such a thing does NOT exist in Linux [and probably never will], and it's most likely VERY easy to circumvent any such thing on a Linux system, MS basically throws in the towel knowing that this is a battle they cannot win.
Otherwise, they'd put some kind of kernel-enforced per-seat licensing in it. You KNOW they would.
"Even on Windows, SQL Server does its own memory and thread management via a piece called SOS (SQL Operating System)"
That doesn't say anything good about the standard Windows functionality. Also - if its really doing this down to the metal and not just grabbing a thread pool and virtual memory from the OS at startup then it must be plugged deep into the kernel with ring 0 privs, which is never a good thing for an application to have, tho it seems to be a lesson microsoft never learn.
If it does this on Linux - presumably via a kernel module - I wouldn't touch it with a 20 foot pitchfork wearing a hazmat suit.
FYI - you don't need a kernel module to manage threads. You'd just need a customized version of the 'pthreads' library, or (more likely) a wrapper around it.
I once wrote a threading library for 16-bit windows 3.x that used cooperative sharing (you'd have to call a function periodically that did cooperative thread switching). It was convenient enough to allow multi-thread solutions and to keep the UI working while you did background things, though Windows 3.x was always a single core. All you really needed to do was maintain a thread context and a separate stack for each thread, then prioritize and switch to them at the correct time, handle messages, yotta yotta. If you were waiting for UI, the thread switcher would happily run background tasks until you did something, and then it would dispatch the appropriate message to the handler like a normal windows application. So the UI was fast and responsive at the same time.
I expect that SQL Server's thread manager just does similar kinds of things, in userland. Windows now has something called 'fibers' that (as I understand) are very similar to the way I did cooperative threading. I also believe that SQL Server makes use of these a LOT. And Windows has a limit to the total number of threads per process, but an SQL Server thread manager could greatly increase this by use of its own stack/context switching method [which, again, could be done in userland].
Anyway, that's my take on it. I see no reason for a kernel module here. It would be better to avoid that anyway, so I guess I agree with the original premise of "wouldn't touch it with a 20 foot pitchfork" etc..
SQL databases - at least high performing one - are always like that. A kernel simply doesn't know enough about the database, so it would tend to make dumb decisions like employing read-ahead when you wanted to select only one record, trying to cache parts of the database in memory competing with the database's cache, giving priority to the wrong queries based on 'fairness' (assume for simplicity each query has its own 'thread') and so on.
A database knows so much more about current and future use so it needs to override much of the libc and kernel's default handling (open all files directly, use light-weight 'threads' and so on). Eventually the functions are abstracted to utility functions and from there to a layer between an OS and the database. SQLOS is probably a misnomer - AFAIK SQL Server doesn't use a kernel module even on Windows.
"the aim is that core database engine features will be equivalent, with the exception of File Table which is closely hooked to the Windows file system:"
WinFS is supposed to stand for Windows Future Storage. This is one of the core parts of Windows Longhorn and it will include the SQL server database, integrated into the file system hierarchy. Release date unknown.
Not sure if that's a trolling comment, but WinFS is NOT the Windows file system they are talking about. WinFS died about 10 years or more ago, it never saw the light of day.
https://en.wikipedia.org/wiki/ReFS might be more appropriate - at least it's their current "future" file system
Biting the hand that feeds IT © 1998–2019