THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Buck Woody

Carpe Datum!

What 5 things should SQL Server get rid of?

I’ve been “tagged” by my friend Paul Randal. It’s a high-tech way of making someone else do what you want, but since it’s Paul, well, I guess I’m OK with that. He’s asked in his recent blog entry “What five things would you get rid of in SQL Server if you were in charge?”

This is, of course, a delicate issue. After all, I work at Microsoft, so anything I say here might be taken as a criticism that would require action – but of course it really doesn’t. Interestingly, you may have more to do with what goes in to SQL Server than I did even as a Program Manager where I “owned” a feature. Unlike many places I’ve worked, Microsoft really does drive its products by what its users want – not every time, and not every user request, mind you, but overall I think we hit the mark pretty well.

So, with all of that said, and of course the obligatory statement of “these are my own opinions, and have nothing to do with any official Microsoft position in any way, and do not reflect the opinions of other Microsoft employees or management”, here goes.

1. Get rid of SQL Server Management Studio
Does that surprise you? After all, when I was a Program Manager, I actually owned the general architecture for SSMS. But those on my team probably would have been able to guess this one for you. I think that SSMS is a fine development tool. But I think that it does less of a good job for managing a system. It’s based on Visual Studio, probably one of the best development IDE’s around. And when I develop code, I really like it. But for a monitoring/management tool, I prefer a snap-in to the Microsoft Management Console (MMC). I know, the old one (prior to 3.0) was kludgy, difficult to use and program in. But that’s changed. Of course, when I bring this up, you’ll probably immediately say “But I don’t have that in XP.” And that’s one of the reasons we didn’t go there. (But I still don’t like SSMS for management.)

2. ShrinkDB
I think this discussion has been done to death, so I’ll leave it at that.

3. SQL Server Agent
Does that one surprise you as well? In my mind, since we ALWAYS ride on Windows, just use the task scheduler there, along with PowerShell. You could log the results in Windows logs, files, back into SQL Server, whatever. It’s just a complexity we don’t need in SQL Server.

4. SQL Server Error Logs
We have a full logging setup in Windows. They’re well done, easy to understand and ubiquitous. We should just use that.

5. Several SKU’s
I won’t say which, but we have a few SKU’s of SQL Server that need to go. And we need to figure out how to help you understand clearly where you need to go to Enterprise or Data Center.  Most folks are trying to push Standard edition to do things it isn’t designed to do, and then they think SQL Server won’t scale. I think we can do a better job of showing you where Standard Edition will hit the wall, and I think with fewer choices it would be pretty simple for you to pick the right one.

Well, once again I’ve probably puzzled some folks and angered others. I think my work here is done. :) Back to you, Paul.

Published Wednesday, May 12, 2010 7:28 AM by BuckWoody
Filed under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Michael K. Campbell said:

Yeah, #1 does surprise me. I've cursed your name a number of times in the past - now I guess I'll have to stop ;)

SSMS is a great dev tool. But, as you also believe, is a poor management tool. And it's not just the lack of instrumentation (though some of that has been bolted on of late - even if none of it really compares to that (yes, cheesy) task pad view from EM), but the 'studio' experience altogether that bugs. I hate that SSMS always thinks I'm working on a solution. Some times it's just adhoc queries or simple tests, tweaks, or peeking at stuff with some DMVs, queries, or what-not.

But, when the entire thing is build on top of devenv.exe, it's hard to get around those core, architectural, considerations. (And this is where I've cursed your name - yes, seriously ;) )

But another pain is that so many of the UI features just aren't implemented. This is starting to be less and less of a problem with SSMS 2008 and up. But what I'm talking about are things like... CTRL+A not working in some text boxes/areas to select all text, tabs not working and so on - because everything (apparently?) derives from 'stock' WinForms controlls and such that just aren't as intelligent as some of the older Win32 UI elements that we had previously or that we have in other apps.

May 12, 2010 10:33 PM
 

BuckWoody said:

Mike - great comments. Make sure you "bug" those issues in Connect.microsoft.com - we need to fix those.

May 13, 2010 9:44 AM
 

Eric Ness said:

Could you elaborate on #3 a bit?  We're setting up a server to run all of our SSIS packages.  The only reason that we'd install the database engine is for SQL Server Agent functionality.  Can all of that be done by the Windows task scheduler and Powershell?

May 13, 2010 11:59 AM
 

James Luetkehoelter said:

Actually to follow up on Eric's comment, I do see some use for the SQL Agent *if* you have need of the proxy/credential functionality.

May 13, 2010 12:18 PM
 

BuckWoody said:

Eric - classic DBA answer: It depends. I think you could, but you have to be able to code all that yourself.

May 13, 2010 1:10 PM
 

Eric Ness said:

I was thinking about this a bit more and realized it would take a lot of custom code.  The functionality is already there in SQL Server Agent and people know how to use it.  So for our needs going with SQL Server Agent will make maintenance easier.

May 13, 2010 2:17 PM
 

RichB said:

Disconnect the management functionality from the coding tools.

Concentrate on making a good, enterprise grade multiserver management, monitoring + scheduling environment.

Bring back a lightweight and fast, friendly coding environment, and do something about that code completion - its appallingly invasive, specially with large numbers of objects and cross database coding.

AGENT:

Keep the agent - or wrap it up differently.  We are DBAs not network admins.  Keep everything in SQL, accessible through SQL, portable through SQL.  That includes stuff like SSIS - everything for the server should be able to be backed up and restored through standard databases.

Getting rid of the SQL Agent will seriously hack off a lot of people. No one wants extra work, and if you make me rejig my whole SQL maintenance, backup, etls and gok what else systems the chances are thats going to can that upgrade.  If you do have to get rid of it, make sure that there is a clean way of porting existing jobs with no manual migration.

Error Logs:

I disagree entirely. The SQL Logs are a real boon, keeping relevant data in a seperately managed set of files.  I can cycle them daily and know that all the SQL related info is right there.  Sure I can go and check the system logs, or leave that to the sysadmins.

SKUs:

A good step would be to really improve the documentation that defines the differences. The matrixes seem to be in different places depending on what you want to know, and seem to have missing key information. Improve that and you are halfway there.

Biggest thing to get rid of:

Shipping half finished products. Like the installer. Really - how did that get released? Did you just take all the lessons from the last 2 decades of how to create userfriendly, convenient tools and think 'hey, lets do the exact opposite.  They're dbas, they'll appreciate the joke!'

No, we don't. We get extremely cross. And swear. A lot.  Thanks for that.

Other half finished, almost usefull stuff would include multiserver management, central management servers, almost all the management guis etc.  Stuff where you want to do something, but can't quite.  Like replication that sets up a linked server almost automatically - but with a version that causes - get this - a stack dump when you just want to see the metadata for it.  Really, wtf, did you not test this?

So, to recap:

Take out the process of screwing around with well established paradigms every release.

Remove the lack of testing.

Remove the half finished stuff - if its going to be useful, stick it up as a plugin or standalone.

Other than that, love it, love you, love the best DB platform out there.

Cheers all!

Rich

May 14, 2010 7:00 AM
 

Adam Machanic said:

I was tagged by master blogger Aaron Bertrand and asked to identify five things that should be removed

May 19, 2010 8:16 PM

Leave a Comment

(required) 
(required) 
Submit

About BuckWoody

http://buckwoody.com/BResume.html

This Blog

Syndication

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement