Voice of the DBA

Author: way0utwest

  • The Home Server is Back

    After reading about the Amazon/Apple attack this morning, I grabbed a second cup of coffee and went in search of a monitor cord. We’d given a monitor to a friend recently, which was the one rarely used for the Home Server. It wasn’t a big deal since we always log into the Home Server remotely, but we had a power outage and the server went down. Since it’s virtualized, I needed a console to get it started again.

    After getting a monitor connected and my virtual server set back up, I immediately kicked off a backup. It’s been down a few weeks, and I’d hate to lose a bunch of work if something happened to the other machines on my network.

    I also enabled remote desktop access, so that I can more easily restart things in the future.

    Back up your systems. You never know when disaster will strike, which could something as cruel as a hacker or virus wiping your system. As data professionals, we should be more cognizant of the impact of losing information.

  • Learning C

    Head First C
    I think C is important to teach the basics of programming.

    Someone else gets it. Besides me, I mean. We should be teaching people the C programming language. An interview with David Griffiths, author of Head First C, says that learning C is a good idea. I concur, and I stand by my statement.

    It’s not that I think everyone should be a C expert, but I’d like to see more programmers spend 5 months, a semester, early in their programming careers. If you’ve written your own iOS app, this would be a piece of cake. If you’re a Python guru, it would broaden your horizons. Getting closer to hardware helps you write code in a more thoughtful way.

    I’d like to see a C programming course as a semester requirement for quite a few fields that might need to develop programs. Not only computer science majors, but also scientists that might need to deal with building their own algorithms. In the same vein, perhaps it’s worth a SQL class for everyone to better understand how to work with sets of data. A query class could also include some of the other query languages, perhaps MDX and XQuery would make sense as well.

    I know this sounds like busy work, but as we become more and more dependent on data and scripting for all sorts of jobs I think it makes sense to start setting a baseline of expected skill for knowledge workers. Those people that knew programming could potentially pass a C test,  and they would be exempt. As we evolve into the future, especially as we may move to more vocational type training, I think it would be good to still require some basics of people as they begin their journey to working with code and computers.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Milk

    cow
    It’s amazing how much knowledge goes into selecting cows for milk production.

    I love this quote: “[we] ran it through a fairly sophisticated computing gobbledygook. It spit out at the other end predicted transmitting ability, predicted genetic values of whatever sort.”  How would you like to explain your complex analysis to a business user using those terms? In most cases, those might be the best way to describe things to most users.

    However that quote comes from a scientist that has spent a lot of time and knowledge refining models and using lots of data to try and predict the bulls whose progeny will result in the best dairy cow performance. The article is very interesting and talks a bit about the complexity of using genome data on cattle and how far it is from the experiments Mendel performed on pea plants. I still remember the dominant/recessive gene explanations from biology, though that explanation seems simplistic now. Comparing it to the work done by scientists predicting cow performance is like comparing horse drawn carriages to Formula 1 race cars.

    Big data is in the news, with so many companies building products they want to sell to help you tame, analyze, and use the data your organization has available. However as this article hints, it’s much more than managing all that data. There is a tremendous amount of knowledge and intelligence needed to use those tools and actually generate useful information.

    As data professionals, we don’t necessarily need all that knowledge, but we do need to communicate with those individuals that may have the knowledge and work closely with them to ensure their ideas are accurately applied against data in the algorithms we write. In addition to writing code and understanding statistics, strong communication skills are important to moving your career forward.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • T-SQL Tuesday #33 – Trick Shot

    tsqltuesdayIt’s T-SQL Tuesday time again, and this is my post for #33. The host is Mike Fal and his topic is Trick Shots, which is an interesting one. I’m not a tricky guy, and I tend to lean towards common, practical approaches to problems. I’m not sure this post will be great, but I like participating, and so I will.

    The T-SQL Tuesday blog party takes place every month, and if you’d like to host, contact the originator, Adam Machanic(b|t) .

    Tricks Shots

    Once upon a time, I was a DBA. I worked with a number of developers who were, how can I say this politely, not terribly careful about which objects they changed or added. It was understandable since they had jobs and work to get done. However I was responsible for deploying their changes to our QA, and ultimately production, servers.

    Not knowing what to deploy is a pain. It leads to mistakes, broken features, and more importantly, long hours from me trying to determine what changed objects went with which features. Since I also want to deploy the same code to production as QA, I want to smooth out this deployment process as much as possible.

    Back in 2000/2001, we didn’t have SQL Source Control tracking changes by individuals. We had to manually check in and out of our VCS for all database changes, which was not a habit most developers had built. As a result, we would constantly have new objects appear, and old ones changed as developers needed to meet new requirements. I tried to handle all the database development work, but there were times I couldn’t keep up.

    As you might expect, when deployment time came, we had a lot of objects in the development database that weren’t in the production database. SQL Compare made it easy to find out which objects were different, but the problem we faced was that not all changes would be deployed at once. We needed specific code changes linked to specific objects, which wasn’t a simple task with 10-12 developers.

    A few months of mad scrambles to track down objects and try to meet our weekly QA and deployment goals had me working on a better solution. There had to be a way in the SQL Server metadata to track changes to objects. I dug around the SQL Server 2000 sysobjects views and found a creation date, but not an alteration date. However I did find a version number that was undocumented, but incremented on ever ALTER of an object.

    Using this information, I build a process that would capture the state of all objects in a table, and then compare this to the current state of sysobjects, returning differences to me. I built this as an hourly report, and had it send changes to me. This didn’t prevent changes, but it allowed me to quickly track down what had changed, and send a note to the developer to link this to a particular item in our project plan. A few minutes an hour (with no changes many hours), let me break out the database changes into a deployment project for the next week.

    The Trick

    The trick in this case was finding information I needed from SQL Server that wasn’t documented. It doesn’t apply any more and the metadata in SQL Server 2005 and later has grown so much that you can more easily find changes.

    What I Learned

    I learned a few things here. First, I could build my own systems on the SQL Server platform to help me out. I didn’t need to depend on what Microsoft provided, if I needed something different. This led me to view the management and administration of the instance as just another application. One I built on top of the platform the same as my developers.

    This also taught me that I needed to be like the reed, flexing and bending to survive in situations. My developers were willing to work with me, but they were human, and they had other priorities. I needed to work with them and get along, adapting some of my ideas and needs to work with them. I did get them to work on manual check ins and outs, but they slipped up, and my system helped both catch those mistakes, and remind them in a gentle way. My emails asking to link an object change to the project never complained they missed something, but they realized the reason I sent it and it helped reinforce the habit of checking objects out of VCS before editing them.