Voice of the DBA

Category: Editorial

  • The 2016 Home Lab

    Everyone needs a home lab. At least, everyone that works in technology and wants to grow their career or get better at their craft. I’d hope that’s most of you, but if not, that’s fine. If you’re happy with just cruising along at work, I wish you the best.

    For many people, especially those wanting to learn, they need some lab. There are plenty of free software choices you can make to build a lab. SQL Server, SSMS, Visual Studio Code, Virtual Box, you can get these for free. The thing you’ll need to provide is the hardware. From my own experience, to learn about many features, you’ll want at least 2-3 VMs, or instances that can run different versions, provide some separation, and even a spare instance when you blow one up. If you want to experiment with the AlwaysOn technologies, you might want 4 or 5 spaces. You can do lots of this in Azure, but many people don’t want to commit, or have open ended costs. Or they don’t want to eat up bandwidth.

    I’m not a hardware geek, and honestly don’t care what I run. It just needs to go fast and work well. I rebuilt my desktop, on advice from Glenn Berry, but I just followed advice. I didn’t try to determine if part A was slightly better or worse than part B. I just needed the SSD/MB/CPU/etc. to work.

    I’m sure plenty of you might be considering a lab, or might need to upgrade. I ran across two great posts that give you a few ideas on what might work for you. Allan Hirt showcases a great portable lab, which I may adopt as a traveling companion. However, if you want another desktop that might run a slew of VMs for experimenting with SQL Server features, Glenn Berry from SQLskills has his own post that you can use for advice.

    If you’ve got recommendations or ideas, or questions, please add them to the discussion. If you’re proud of your own setup, let us know. If you have found Azure (or AWS) to be a friendly, cost-effective place for a lab, I’m sure people would love to know that as well.

    Steve Jones

     

  • Developer Deployment Frustrations

    This editorial was originally published on Sept 7, 2012. It is being re-published as Steve is at DevConnections.

    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 Express (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

     

  • DBA Support

    This editorial was originally published on Oct 28, 2012. It is being republished as Steve is out of the office.

    There was a time when I managed two production databases on SQL Server. Two. I had a development version of one database where we paused development for testing, and only two production databases to manage. Since I had to also handle development, application support and hardware repair/replacement, that seemed like plenty to me. I was the accidental DBA, with database administration being the lowest priority of my day.

    After that I moved on to administer databases in a number of jobs, sometimes as a priority, sometimes not, but in each case, I learned to work more efficiently and effectively. My goal was to automate as much as possible of the routine work so that I could spend my days adding value to the company. I learned to use scripts, alerts, jobs, and more to keep systems running while I was doing other work.

    I’m sure many of you work in a similar manner, or at least I hope you do. This Friday I wanted to ask you at what scale do you need to become efficient, based on the size of your organization. The question this week is:

    How many databases does each DBA in your organization manage?

    I know some of you manage lots of databases in raw numbers, but also let us know if you need to do much with these databases. Is maintenance automated, or is there much active management you need to do in order to ensure these databases are running on a weekly basis. Let us know the size of your load as well, perhaps the amount of data is a better way of measuring the DBA load.

    Steve Jones

     

  • A Software Warranty

    This editorial was originally released on Oct 21, 2012. It is being re-published as Steve is traveling.

    Years ago I worked in a large company on the operations team. We were responsible for all production issues for the 6,000 people and the assorted machines, devices, and applications that come with a large workforce. There was a department that was aligned with our group that focused on engineering and various development groups that built different applications. The engineering group was good at working closely with the production team to ensure smooth deployments, but they weren’t on call and would at times respond slowly to develop solutions when problems occurred. They were, however, better than the development groups who often sent code to be deployed, and accepted bug reports back, but provided little support or assistance for problems with their code.

    I ran across this link from a DevOps person called You Write It, You Support It in the Brent Ozar, PLF newsletter. The piece makes a case for the problems that occur with some deployments, like a lack of, or surplus, of logging, switches to turn features on/off, error handling, and more. It’s a pretty good description of typical problems I’ve often seen, and it calls for developers to support the features that they write, even in production systems.

    I like this idea, though I don’t think that it should be a continuous expectation with developers required to support their code forever. I would like to see developers giving their code a “warranty” of sorts, perhaps a couple months of priority support when code is deployed into live environments with developers taking responsibility and responding to calls, even after hours.

    There are arguments to be made that developers’ time is better spent enhancing applications and applying their creativity to new ideas, but this leads to a human frailty. Too often we view a job finished as a job completed, and that’s not always the case. Doing a job well means more than completion. It implies a level of craftsmanship and pride in the finished product, both from the developer and the client.

    Developers should write code that works. If it doesn’t, then it’s not really finished and should be fixed. With that contract in place, we usually find that the developer spends a bit more time ensuring the product is built in a quality way that reduces the need for much support.

    Steve Jones