Voice of the DBA

Category: Editorial

  • Developer Deployment Frustrations

    Why don’t developers like SQL Server? Probably a few reasons, but I’m sure this is one that really frustrates them. I found a Connect Item that was titled:  Why is Deploying SQL Server 2008 R2 sooooo FRUSTRATING?!! There really is a question there, asking for guidance on  which versions of SQL Server are available and recommended for developers to include in their applications.

    When SQL Server MSDE was released, it seemed that Microsoft was looking for it to be included in small applications that might then be upsized to a Standard or Enterprise edition of SQL Server. It seems to me that this is really the market for Exsoftpress (the evolution of MSDE) and that it ought to be simple for a developer to not only deploy this with their application, but also setup basic maintenance easily.

    I sometimes think that the software developers at Microsoft get lost in their own specialty and forget just how frustrating it can be for the rest of us trying to use their product in new ways. They forget that many of us want to deploy simple solutions easily, and not spend a lot of time working out the nuances of software setup.

    I’d like to see Express not only have a very simple setup that works across multiple versions of Visual Studio, but also baic maintenance plans built in that allow full and log backups (if needed), along with index rebuilds with a simple switch set as a part of setup. A few registry keys or XML config changes could set paths or frequencies.

    Making life simpler for developers is a worthwhile investment for the SQL Server team. It makes them more likely to include it in their applications. If you can add a one-switch replication to sync to a Standard or Enterprise SQL Server, they might think Express is required in every application.

    Steve Jones

  • Appliances – Just Add Data

    The first release of a large data appliance from Microsoft is the SQL Server 2008 R2 Parallel Data Warehouse Edition in which you buy a rack of pre-configured servers that you access with tools and perform limited management on. I was reminded of this as I read about Teradata’s new product strategy, it seemed that they have integrated an appliance in there as well.

    Appliances bring some value to customers by supposedly reducing some of the tuning, configuration, setup, etc. costs in setting up a system. Hopefully the also reduce some ongoing costs that might come from mis-configuration, things running slowly, etc. How many times has an inexperienced person setup a server in a way that causes issues for an application?

    However appliances tend to be expensive. They have to be if there is any level of support from the vendors in custom tuning. That limits how many places will purchase them, and there is also some level of distrust and fear from IT workers that worry about being displaced by a machine. Almost funny when you think about many of our systems displacing other jobs.

    Appliances haven’t had great success in the past, outside of network devices, but I wonder if we might be better off examining them more in the future. Rather than trying to have general database instances put together by IT groups, should we have small, modular appliances that handle various database services and then just write the code and supply the data. For this Friday, let me know what you think:

    Would you like to see small, modular data appliances that you connect to storage and then just add data?

    Steve Jones

  • Check Twice, Update Once

    I was reading through this blog from the SQL Server PSS team (a must-follow), and found this note about the SQL Server Best Practices Analyzer (BPA). This isa tool that can examine an installation of SQL Server and report on any deviations from best practices according to Microsoft, as well as warn you of potential issues with your configuration. I had used it with previous versions of SQL Server and it helped me quickly determine if I’d missed anything during setup.

    Now I haven’t much thought about running this regularly. I’d assume this is something I just run once after installation to be sure I’ve configured, but the blog gives me a good reason to run this regularly, and especially whenever I have an issue. In the entry, it talks about not only noting that an error being returned by SQL Server and noting it’s fixed in a CU, but that a trace flag is also needed. Running the BPA would inform the user that the trace flag needs to be enabled.

    I think it’s great that this type of feature is being designed into a tool like the BPA that can really help a DBA. Knowing that this trace flag needs to be enabled is the type of knowledge that someone might gain with experience, but it’s short lived. At least it should be as I would hope the issue is corrected in a Service Pack w/o the need for a trace flag.

    Tools like this don’t eliminate the need for DBAs. We still need people that can make the decision about whether to apply this, perform testing, and more. These tools just make it easier for us to do our jobs more efficiently.

    Steve Jones

    Update: as noted in the discussion, the MS Baseline Configuration Analyzer is required for the BPA tool. MS BCA v2.0

  • Where Are the Programmers?

    When I was growing up, I thought I wanted to be a computer programmer. I had my own Vic-20, and various other machines, and I wrote code that was used to solve problems. I programmed the computer to handle various calculations or manipulations for school or fun and thought that was very cool. I solved many chemistry labs with the help of my computer.

    The other day someone asked me what I did for a living and I said that I used to work with computers, but now wrote about them. They asked me if I was a computer programmer in the past. That was something I hadn’t heard in a long time.

    I’m not sure when we changed from programmers to developers. Fundamentally we do the same thing, though I’ll admit that developer sounds more important, or more talented. I’m sure at some point a programmer wanted to separate their job from everyone else, called themselves a developer, and the trend caught on.

    I haven’t worried about titles for a long time, but at one point in my career I did press to get the senior DBA title after working with SQL Server for about 6 or 7 years. At that time I felt I knew more about SQL Server than the majority of people that I met, and I deserved to be “senior.” I’m still not sure if I had earned it at that time, but it was a title I was proud of.

    It seems that us data professionals have tried to separate ourselves from the average DBA with database architects and database developers and any number of other database specialties that sound more important than just DBA or developer.

    It makes me wonder what’s coming next. Will we start to advertise ourselves as DSS (data security specialist) or DTS (data transformation specialist) or even BIDS (Business Intelligence developer specialist)? Who knows, those acronyms are already well known in the SQL Server world. They might just impress a manager who knows just a little about SQL Server.

    Steve Jones