Voice of the DBA

Category: Editorial

  • Drop and Recreate

    Those of you that manage replicated environments have learned to have one thing handy: a script that recreates your replicated publishers, distributors, and subscribers. I was reminded of my past needs for those scripts recently when I saw this post on dropping and recreating all the synonyms for a database.

    It’s easy to depend on backup and restore to recover from issues, but how often do you face problems with an environment that aren’t related to data? If you lose a stored procedure, or have a problem with the configuration of jobs, or principals, can you easily drop and recreate an object? That code is usually tiny, but if the only copy you have is in a backup file, you have to restore a lot of data just to get some code.

    Certainly everyone should keep all this data in version control, and I’d encourage you to be sure that not only development code (tables, views, stored procedures, etc) are kept in there, but also configuration settings, jobs, roles, and the various other things a DBA is responsible for in a production environment.

    However I’d also go one step further and ensure that you have scripts to recreate all aspects of your environment if you need to do it. Many of the comparison tools will let you store a snapshot of database schema items in a folder and then easily help you recreate a script if needed. That covers the database, but for the instance level items, you need to be sure you have an easy way to checkout a copy from version control (you are using version control now, right?) and execute the scripts on a SQL Server. You can use T-SQL, PoSH, or even VBScript, but be sure you have the code handy.

    Do you?

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 1.8MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • The Last Job

    I was chatting with one of the more experienced SQL Server professionals I know recently and was surprised to know this person had actually retired, but come back to technology because they were bored with not working. I suspect that’s how I’ll be later in life, and am not really looking forward to retiring anytime soon.

    However I do think about jobs and employment as I age. I know that it can be tougher to keep a job over the long term. It seems the flexibility many of us appreciate as younger workers can be a detriment later in life when you value stability. With that in mind, here’s this week’s question:

    Is this the last full time, technology job you’ll have?

    I have an amazing job, perhaps the best one I could have imagined. I love what I do, but I do think about my options every year. I take some time to think about how my employment has gone in the past year, what else I might do and what I want to do in the future. I re-evaluate how I feel and try to be honest with myself about how I feel about my career. If I decide to make a change, I want it to be my decision, not something that’s forced upon me by a change in my employment status.

    I wonder if this will be my last job. I certainly think it could be, and the way it’s gone the last few years, I hope it is.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 1.5MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Citizen Programmers

    The Citizen Programmer, a piece at Simple Talk, really made me stop and think a bit. On one hand, the idea of building a platform that enables any end-user to perform rudimentary programming is a noble goal. If you can do that, then you can dramatically reduce the costs associated with waiting for developers to build applications.

    On the other hand, the article praises the Visual Basic of the 90s, which allowed almost any one to build an application.

    And that was a problem. Despite the tremendous number of applications built, far, far too many of them were poorly written, prone to crashing computers, unable to scale to more than a single user in many cases, and were almost un-maintainable over time. These applications removed people from their knowledge work, having them spend time programming instead of their regular job. That might be good in some cases, where people had talent and desire to build software. It certainly forced the person coding the system to better understand the idea behind the work that they were doing.

    However in many cases, I think we might have ended up wasting lots of time. Certainly the people spending more and more time maintaining an application weren’t necessarily getting more work done. People dealing with buggy software might have been doing their job more slowly overall. There were also the problems with turning a VB application over to professional programmers who were loathe to work on it, and perhaps did little work to keep the application running. A lack of responsiveness from technology departments might restart the whole process with another poorly written VB application, each one a custom work of art that stumbled along inside of a business.

    I do think that giving tools to enable end users to perform some of their own analysis and review of data is important. I like the idea of PowerPivot and other tools that let users query data and build their own reports. I don’t know if we need professional developers for every piece of software, though I am sure we need software to be written faster and in a more agile fashion. In all cases, however, I know we do need professional DBAs to manage data and ensure it’s protected and intact as the speed and scale of our systems continue to grow.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.7MB) podcast or subscribe to the feed at iTunes and LibSyn. 

  • Managerial Moneyball

    I really enjoyed reading Moneyball. Its a book about baseball and data and how information should be used to choose baseball players for the Oakland As. It’s an interesting approach, one that has rarely been used in the sport in the past, though it is gaining traction. It does seem that this approach has helped the As to high level of success given the constraint of their limited payroll. There’s even a great movie if you don’t want to read the book, but the book is really much better and goes into more detail on data points and how they are used.

    The idea of using data to make decisions has been applied to other areas, with “The Moneyball Effect” being talked about in other industries. Recently I also ran across an opinion piece on bad managers that also referenced Moneyball. The piece notes that most people make poor managers. They lack the skills, and more importantly, they really lack those innate qualities that motivate, inspire, and engage employees. Whether you agree with that last part, I think most of you agree that most managers are poorly chosen, trained, and certainly not qualified.

    The idea of using data to identify people that would make good managers, and perhaps even move people out of managerial roles. The premise of the piece is really the bad managers make their teams perform worse, so if you’ve got one of the seven-out-of-ten people ill suited to the work, you should move them out of that position. Then identify, promote, train, and support the others to manage your employees and help them to perform at their best.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.3MB) podcast or subscribe to the feed at iTunes and LibSyn. feed