Voice of the DBA

Tag: administration

  • The Robot DBA

    Manna, a fun, and scary, sci-fi story.

    This is the story of Manna, the manager of a fast food restaurant. It’s a great read, and perhaps a little shocking. Manna is a piece of software, reading sensors, reacting, and letting employees know what to do with a synthesized voice through a set of headphones that the everyone wears in a fast good restaurant. In this tale, Manna evolves into a software system that is spread throughout many industries, essentially displacing managers and many workers at all levels in all industries. With the ability of these different “Manna” variants to communicate and negotiate contracts among themselves, the US devolves into an Orwellian nightmare place to live.

    It’s a science fiction story, but the fears that it evokes are similar to those I’ve heard expressed from many people in the IT field across my two decades in this industry. A friend of mine left IT a decade ago, while working as an Exchange admin for a company with 50,000 mailboxes. He was sure in 5 years his job would be automated and eliminated. I knew a few people that moved out of DBA work in the early 2000s, after Microsoft released SQL Server 7 and 2000, with some marketing messages that the products didn’t require a DBA. A few years ago I heard a few people arguing that PowerPivot would kill most BI development jobs because it was so easy for end users to build their own analysis applications.

    The one constant in all of those stories is that they never came true. I hope that Manna never comes true either, but I’m not worried. I’m very confident that if there’s one truth to all the computer development we do, it’s that we make constant mistakes and there is very little chance that we will be able to automate any significant percentage of IT jobs away.

    We do build better software, and we do allow an administrator to manage many more systems than in the past, but we also seem to constantly eliminate most of the efficiencies in two ways. One is by adding many more systems and applications, and the other is by introducing more complex systems that create new problems that need to be solved.

    The bar for IT knowledge needed is always being raised, but I just can’t see us getting to the point of having automated or robot DBAs running SQL Server in my lifetime.

    Steve Jones

    The Voice of the DBA Podcasts

  • Measurements

    Measurements are important to growth.

    “If you cannot measure it, you cannot improve it” – Lord Kelvin.

    That’s a quote that comes from this blog post, talking about ways in which you might measure your performance. Numbers are not the only important thing to measure, and you certainly don’t want to just pick one measure. The blog post talks about performance of employees, looking at different ways to not only measure the performance of one job, but also using different measures for different jobs.

    The idea of measurement is applicable to both people and systems. Having a constant way to measure performance, track those measurements, and perform analysis of the data is an important way to know if you are actually making strides toward building better performance and more efficient systems.

    However it seems that even though many people know these things, they don’t actually capture the measurements regularly. As I talk to people, asking them if they know things like the backup growth for their critical databases, they don’t. I’ve asked people if they know how much time they spend on blogging, or if they are reaching more people, or really for any metrics, and they often don’t have any idea.

    Numbers aren’t everything, but they ought to be a thumb-in-the-air measurement that guides you to find ways to improve over time. You can be on the schedule that works in your environment, and on the pace to improve things that fits the situation, but if you don’t measure yourself or your systems regularly, it’s hard to know if you’re actually moving forward or backward.

    Steve Jones

    The Voice of the DBA Podcasts

  • Shrinking Databases

    Every time you shrink a database, an angel gets its wings torn off. Or Paul Randal feels a disturbance in The Force. In other words, don’t do it.

    But people continually do shrink databases. Despite the constant advice and guidance from Microsoft, MVPs, and more, the fact that shrink is available easily in maintenance plans and with a DBCC command, people do it. I understand it since it’s natural to not waste space and so many other tools, like Access and Outlook, have files that only use the spaced needed.  Why not SQL Server?

    It’s Friday, and I thought I might see if there might be a oslution tht makes sense. For this poll, I want to ask you about shrink:

    Should shrink be removed or fixed?

    By removed, I don’t mean completely take it out of SQL Server, but make it harder. Maybe require a trace flag, maybe something else that might reduce the regularity with which it’s run. I’d certainly recommend it be completely removed from maintenance plans, both the wizard and the designer.

    Is there a better solution, however? Should perhaps shrink be fixed to be a more intelligent operation that doesn’t cause lots of fragmentation? Even if it’s slower, or maybe an operation that requires more resources to complete, would it be better to actually “fix” shrink?

    Put your answers in the discussion and let us know what you think

    Steve Jones

  • Enterprise Management

    One of the things that I’ve had to do in my career is manage large numbers of servers. There was a time when two of us managed several hundred instances of SQL Server, and managed to do it very well with a lot of automation. Recently I saw someone post a note about having 400+ servers to manage, and they were wondering how to perform enterprise management. In Oracle environments, they mentioned using OEM, RMAN and other tools to manage backups centrally and wanted to know what SQL Server solutions were out there.

    I know things have changed quite a bit from the SQL Server 2000 days when we had to build all our own tools, so I wanted to ask the question as a poll this Friday:

    What do you do for central management of lots of instances?

    If you have more than 50 instances, what tools do you use to try and ensure you have a well managed environment. With the addition of the Central Management Server and Policy Based Management  to SQL Server, it definitely is easier to handle a larger load of instances

    This Friday I’m wondering what tips and techniques you think work well for managing lots of instances. Any tricks you’ve used? Any third party products that are very handy? Share you knowledge this Friday.

    Steve Jones