August 26, 2009 at 12:41 pm
Scott Jacobson (8/26/2009)
Robert Hermsen (8/26/2009)
http://msdn.microsoft.com/en-us/library/ms143506.aspx -- "SQL Server 2008 is not supported on Windows Server 2008 and Windows Server 2008 R2 Server Core installations."Unfortunately SQL Server 2008 is not compatible with the Windows Server 2008 Core only installation. Maybe it is part of MS long term upgrade strategy.
That specifically says "not supported". In MS-ese that is not the same as "not compatible". I'd guess this stems from the fact that .NET is required for SQL to install. Initially, .NET was not supported under Core installations either. But I think this might have changed: http://blogs.technet.com/server_core/archive/2008/12/19/net-3-0-and-3-5-in-windows-server-2008-r2-server-core.aspx%5B/quote%5D
More research on my part would have found the procedures to do the install as well... so while not supported.... well neither was mirroring initially right?
August 26, 2009 at 1:07 pm
ammo (8/26/2009)
At my last job they were just starting to consider a "DW appliance" from Netezza(http://en.wikipedia.org/wiki/Netezza). I guess the DW world got it first due to the massive amounts of data being processed.
And maybe I'm wrong, but isn't Project Madison aimed at making a DW-specific appliance as well?
Project Madison stems from Microsoft's purchase of Netezza's competitor, Datallegro. And, for all intents and purposes, Teradata fits in this category as well (although much larger). This is largely possible in Data Warehousing because query patterns in this type of application are fairly constant accross implementations (bulk writes and reads) so we can standardize hardware and optimize the underlying OS for it.
I think transactional databases work a bit differently, and a true appliance doesn't quite fit as well. I agree with an earlier posting that we should leave the hardware interaction and driver management out of the SQL OS, but do give it an opportunity to understand that it is on a dedicated server and does not have to play nicely with other applications.
I see this as a more likely scenario using Enterprise Edition and Windows Server Core in conjunction with a Project Madison. Use these pieces to build a large, multi-node, RDBMS environment and dramatically reduce costs by having less of the OS administration involved.
August 26, 2009 at 1:07 pm
blandry (8/26/2009)
When you go to these Microsoft "talks" Steve, do you ever ask the people giving those talks if they have done any research on the ideas they are presenting?
I never said that this was presented as an idea from MS. You're reading into the editorial a bit much. This was something I've wanted for a long time, since NT4 actually when we got the "basic tuning" for the server that let you decide if this was primary a server by putting GUI tasks in the background as low priority.
Many of the talks I've heard from MS engineers were on various things. I have heard talks about the memory management, NUMA, the schedulers and how they are spun up based on resources, etc. In many of these talks the people have done research in their areas, and they know what they are presenting on. Even in the talks where they are giving something new, it's not that they haven't researched it, but that they have a different perspective.
Lots of companies look to apply old ideas in new ways, or to their own products. There are lots of reasons to bash Microsoft, but this isn't one of them. I don't even think them applying "old" ideas as something "new" in their product is a reason to complain.
August 26, 2009 at 1:14 pm
August 26, 2009 at 1:42 pm
A stripped down version of Windows to support SQL Server is a great idea. It's a rather proven concept (as many others have pointed out) that would simplify administration and improve performance. But then, no one at MS is concerned about performance when you can just raise the minimum hardware level to a point where it "appears" to be running efficiently!
One of my pet peeves is taking bloated, poorly written code and then throwing it on newer, faster, bigger hardware as a "solution" to performance issues. In the days when you had to do your own memory management and truly had limited resources, code was generally written in a much more efficient manner. Of course, some folks threw good coding techniques out the window in favor of shaving an additional few bytes or microseconds from execution.
LinkedIn: https://www.linkedin.com/in/sqlrv
Website: https://www.sqlrv.com
August 26, 2009 at 2:05 pm
Aaron N. Cutshall (8/26/2009)
One of my pet peeves is taking bloated, poorly written code and then throwing it on newer, faster, bigger hardware as a "solution" to performance issues.
As painful as it is, it's hard to dispute throwing hardware at the problem as a viable solution. I participated in discussions where a memory leak in the application resulted in a new server with more memory being ordered. In that specific situation, I disagreed with the resolution, but I guess it was a perfectly fair option.
August 26, 2009 at 2:23 pm
well .... as per licensing goes ... this could lead to a Windows Data Center Edition kind of a solution. You pay a huge sum, but the OS comes bundled with SQL Server. Essentially you would have an just OS Kernal with a GUI link to its configurator - Inside SSMS -> where you could configure OS services/ parameters/SAN admin/Cluster admin etc.. that are used by SQL Server. This eliminates all the frills of GUI and all features of OS not reuired for SQL Server - an effiencient truck - not two clunkers hatched together 🙂
SQL Server on such a bundle could be classified into different versions and types like standard , enterprise along with OLTP/OLAP etc...
Microsoft could then work with its hardware vendors like Dell or HP and get this thing bundled up at the factory itself ... so you go to Dell's website .... and choose your configuration of hardware and the OS/SQL bundle ..... so it comes off the shelf for you. Dell/Microsoft can then give you driver update packages. no need to deploy OS patches only for things that are NOT AT ALL related to SQL Server reducing the amount of reboots required per yr ......
Just thinking aloud 🙂
-------------------------------------------------
-Amit
Give a man a fish and he'll ask for a lemon. Teach a man to fish and he wont get paged on weekends !! :w00t: - desparately trying to fish [/size]
August 26, 2009 at 3:23 pm
Michael Ross (8/26/2009)
As painful as it is, it's hard to dispute throwing hardware at the problem as a viable solution. I participated in discussions where a memory leak in the application resulted in a new server with more memory being ordered. In that specific situation, I disagreed with the resolution, but I guess it was a perfectly fair option.
I would still hesitate to call that a "solution" since it's really more of a work-around. Of course, IT is rife with work-arounds that masquerade as fixes and solutions perpetuating forever.
LinkedIn: https://www.linkedin.com/in/sqlrv
Website: https://www.sqlrv.com
August 26, 2009 at 8:54 pm
Microsoft already puts out "storage server" and "web server" editions so I think Steve's idea of "Sql Server server" is quite realistic in that light. It's a matter of enough customers hassling MS to convince them there is a viable market for such a release. Every time you talk to your friendly MS rep, be sure to mention this idea.
On a tangent note, does anyone here use SS on the installation of Windows server that is command line only? I forget what they call that ("core" installation or somesuch) ? That might be the closest thing in the meanwhile.
August 27, 2009 at 12:17 am
How would this work with security, firewalls and antivirus etc? And don't tell me that is not needed.
August 27, 2009 at 8:13 am
Hey trucks have locks just like the family car. Security and stability are of primary concern on all our servers. But, going back to the truck analogy, I don't see the need for a fancy system with child locks, a trunk latch, Panic button all bundled into a wireless device connected to my key ring, when a good old metal key and lock will do.
I recently read an article about a NIC that stayed awake while the server went to sleep. It had it's own memory and cpu and ran a lightweight version of Linux. How about using that microcomputer as the firewall instead of building it into the operating system. That makes sense to me.
I can't argue that firewalls, antivirus, backups, aren't needed. But they may be simpler, smaller and easier to use. Right now we start with a generic, "do everything pretty well" kind of server and then customize it to be a better database server. I just think if, from the beginning of the design process, the targeted goal of a database server didn't have to compete with the other possible roles our generic servers might perform, a better product would be the result. I am pretty sure that if Microsoft announced it was considering a SQL Server OS, the public would demand the appropriate security features.
People by SUV's because the can be the family car, and the truck at the same time. Sure they use to much gas to be the perfect family car and they are quite powerful enough to be the perfect heavy hauler. But most of the time the SUV is a good compromise. I am by no means market expert or a computer expert, but I think there are enough organizations out there have chosen to dedicate a Server as a SQL Server database server, that a specialized SQL OS might be a welcome and profitable addition to Microsoft family of server operating systems. I think the same can be said of Microsoft exchange. I also think that virtualization will cause organizations to want to encapsulate more and more server roles into dedicated single purpose server instances in the future. I am not saying I would virtualize every server, just that virtualization will cause us to think more readily about a single server for a single purpose.
August 27, 2009 at 6:24 pm
Funny, but this instantly reminds me of all the other flavours of database in the world, running under *ix... Postgres, MySQL, Oracle, ...
It's standard practice to have a totally stripped down, DB server optimised *ix environment for hosting these.
Can't help thinking, one day when Google OS finally squelches windows as a viable OS (and we're all booting straight to our lightweight browser 'OS' from the BIOS, and running locals apps off the filesystem through a lightweight webserver), MS might finally follow Apple's lead and switch to *ix as an OS.
This would have innumerable benefits, not the least of which would be being able to do exactly what you suggest.
Personally, I'm just looking forward to having all my email stored in a useful format (ie. text), so I can use Perl to convert my mail files between outlook versions instead of the gymnastics I have to go through now.
B
August 28, 2009 at 12:32 pm
Wouldn't a "SQL OS" add many of those things that Windows Admins do, to the SQL DBA job - like drivers upgrades, etc.
And then there is all the other software that we all use on most of our servers - like LiteSpeed, Anit-Virus, etc. etc. Seems like it would ake all their lives more difficult, and thus also the DBA's ?
August 29, 2009 at 12:55 pm
Awesome idea. It would be interesting to see something like this. Like you, I think its perfectly possible. While our database servers are just that (aside from LiteSpeed), it would be interesting to see how a SQL OS tuned server would boost SQL Server.
To add to the car analogy, it's kind of like world of Touring Cars (a racing series in the UK). A factory car, stripped back and tuned for racing - All of the bells and whistles have been removed but it's been tuned for the specific purpose.
Let's hope MS browse these editorials!
August 29, 2009 at 1:20 pm
That might be nice but I'd rather see them spend the time on improvements to SQL Server itself. For example... some better IO functions for T-SQL. Why is it that we have to use xp_CmdShell to write to a text file? Why isn't there a BULK EXPORT to go along with BULK INSERT? Why is BULK INSERT so flakely in that it counts delimiters instead of EOR's when it comes to skipping rows? Why is it that you need to train BULK INSERT with a format file to do a simple "true" CSV import with text qualifiers? Why is it that aggregate functions such a SUM still don't work the way they're supposed to? Why is it that we still have to build Tally Table splitters to split parameters and the like instead of there being a nice machine language level function to call to do such a thing? Why is it that we still use ROW_NUMBER() to build a list of dates instead of there being a ROW_DATE() function? Why is it that we still use the Tally table to build a list of dates/times to do an Outer Join to instead of their being a GenDate(start, end, increment) function that returns a table? Why is it that we still have to write Cursors and While Loops with dynamic SQL or concatenated SQL to do something across multiple tables or databases instead of simply being able to use variables in the FROM clause or in a USE statement? Why is it that we have to resort to trickery such as the undocumented xp_DirTree just to get a simple list of files? And lord help us if we actually wanted to get the date of creation and file size. There should be a full blown DIR function that returns a full directory structure complete with levels and everything else we need. Don't say no one would use it, either. I've answered a huge number of posts that say otherwise.
I'd suggest that an SQL OS is the least of our worries at this point. The 8 cylinder car is currently only firing on 6. Even if the underlying road were as flat and smooth as a pancake and downhill all the time, we're not getting good mileage. In fact, they keep removing cylinders through deprecation.
Forget the OS... make T-SQL better, instead. And I'm not talking about improving all these idiotic GUI's like SSIS that, judging from the number of posts on them, really haven't made life simpler.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 16 through 30 (of 50 total)
You must be logged in to reply to this topic. Login to reply