Voice of the DBA

Tag: administration

  • Backup Responsibility

    One of the most important things that you can do as a DBA, or really as any sort of system administrator, is back up your system.Ensuring that you have have backups, and of course, that you can restore them, is the number one priority for sysadmins. Everything else that you need to do is second to backups. After all, backups ensure you still have a system after a disaster. If you can’t do that, then security, performance, features, none of that matters.

    I have worked in large and small environments, and in all cases, I’ve assumed that as the DBA, I need to be checking that backups are occurring, and that I can restore them in case of any issues. Often this has meant I need to work more closely with others that have the actual responsibility for performing backups. This week, I’m wondering how many of you work in similar situations.

    Who is responsible for backups in your company?

    Is it the sysadmin of each particular application? Does the DBA ensure database backups while the Exchange administrator handles mail backups? Do you have a centralized system for backups? If backups fail, who’s going to get yelled at? Or perhaps more importantly, who will notice that backups have failed?

    There are any number of ways to handle backups, and honestly, the best way I’ve seen had a centralized person responsible for running backups every day and checking on automated tasks, but the individual system owners (DBAs, Exchange admins, application managers) checking that backups had been made. These individuals also test restores periodically. In this way there was always someone to double check the person responsible.

    Let us know this week how things work in your environment.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • No Handwaving Away the DBA

    There’s a great quote I read, at the end of this article. It says: “…if you think that switching to NoSQL will just let you hand-wave away all of the challenges of running a database, you are terribly misguided.” The context is that all too often people looking to move away from some of the hassles of working with RDBMS platforms, which includes working with the DBA, haven’t completely thought through the issues.

    I do think NoSQL has a place in the world. There are domains of problems that I’m sure Riak, MongoDB, and others, solve in a more efficient way than SQL Server, Oracle, MySQL, and other relational systems. I’m not sure what they are, and to some extent, I haven’t seen good guidance on where particular platforms excel. Most of the articles and pieces on choosing NoSQL seem to be trying to sell me “why a particular platform can replace my other one”, and telling me to add in things like transactions, but not explaining the drawbacks.

    However in all platforms, we often forget that there are really two frames of reference that matter. We need quick ways to work with data, insert it, update it, query it, etc. This is the development frame of reference, and it often dominates discussions of platforms. For good reasons, as developers are expensive, but that’s only part of the system. We also need to consider the operational portion of managing data and applications. When I have those needs to rebuild indexes in relational platforms, or the requirement to periodically merge/remove old versions of documents, or even manage clustered, horizontally scaled resources, we need operational maturity.

    In some sense the DevOps movement is built around merging these two frames of reference into the minds of all those involved. I hope that movement continues to grow and mature, and we learn that developers and operational staff are both necessary, and both need to function in a symbiotic, harmonious fashion.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Consolidation Matters

    Throughout my career I’ve been looking to consolidate SQL Servers when I find them. The typical employer I’ve had usually grows their IT infrastructure over time and many projects look like this:

    • Build or buy a software package
    • Buy a new server
    • Install SQL Server and one database for the application

    Over time this means I find lots of individual servers running at much less than full capacity. That’s something that DBAs like, because it means that we can handle the inevitable spikes in resource usage that our workloads will encounter. However that’s not what the rest of the business, especially the financial management, wants. Underused resources mean money that isn’t spent well.

    As a result, I’ve often looked to consolidate instances where possible. Often I let an instance run by its own hardware for a period of months, perhaps even a year, during which I can get a good idea of what level of resources the database and application require. Once I have that, I try to match up the needs with an existing SQL Server that might be underutilized by at least that amount of resources. Typically I’m looking at RAM and CPU since disk resources can often be transferred to a new piece of hardware. It’s not quite as simple as it sounds as I also need to look at workload patterns and potentially match up instances whose workload peaks occur at different times.

    I’ve successfully consolidated many instances this way, often reducing the amount of physical hardware in data centers substantially. As hardware cycles turn over and newer machines are purchased, I can usually repeat the process again and again. The advent of virtualization has made this even easier as bad guesses can usually be reversed or corrected by moving the database to a different instance.

    I suspect that virtualization will become more important in the future, especially as licensing changes in SQL Server make it much more expensive to add the ad hoc instance on its own hardware. I’d encourage you to plan on consolidating new databases from the beginning to ensure that your organization gets the most performance out of the hardware that it has purchased.

    Steve Jones

    Podcast: http://traffic.libsyn.com/voiceofthedba/consolidation_56_v1061.mp3

  • Your First Week as a DBA

    Summary: There are many accidental DBAs as well as people new to SQL Server who are assigned the responsibility of managing a database system. Learn about the most important things for you to examine on your first week.

    Abstract: Developers, system administrators, junior DBAs, and even managers often find themselves responsible for a new SQL Server system without knowing what things they need to worry about. Since a SQL Server instance can run for months without issues, these accidental DBAs don’t realize that they are neglecting maintenance and other operations that will ensure their systems are protected and running smoothly. This session will teach you the most important things you should do on your first week with a new instance.

    Length: 60 minutes

    Slides: (coming soon)

    Code: (coming soon)