Voice of the DBA

Tag: administration

  • SQL Server Should Work for Us

    failI ran across a post the other day from someone that was trying to find out why their maintenance plan failed. This person had received a failure notice from SQL Agent, which is good. We should all be aware of failed jobs from some sort of monitoring system. Like any good DBA, this person checked the job history, saw an error, couldn’t figure it out and posted a question at SQLServerCentral, looking for help. That’s a good plan for most anyone 😉

    Experienced DBAs know that to debug this issue, you need to look at the maintenance plan log, which has more details. The job history contains a minimal amount of information and usually doesn’t help. If you examine the maintenance plan log, it’s usually easy to determine which part of the plan failed since the plans are fairly simple constructs. The really exceptional DBAs don’t use maintenance plans and instead would rely on some sort of tool or well known script instead to handle their maintenance.

    However why do we need to go to the maintenance plan’s log? SQL Server includes the job history. It includes maintenance plans. Why doesn’t the job understand there is a maintenance plan, read it’s log, and return the information? Or give us a button on the job history that loads up the maintenance plan log? That’s a simple thing to do, and isn’t the job of software to make tasks easier?

    This is one of those places where SQL Server feels a bit immature and unrefined. I understand the complexity of the entire product and the limited resources that are devoted to enhancing and growing the product. However, where are the resources that make SQL Server easier for the average and accidental DBAs to use? Those are the majority of the people using the platform.

    SQL Server led the industry in producing tools that made it easy to manage and use. Other platforms are quickly catching up, however, and if SQL Server can’t continue to improve its toolset, in addition to its features, people will consider other platforms. The cost of SQL Server has risen, but so has the revenue. Do us, and yourself, a favor, Microsoft. Put a team of 50 people to work on usability and improving the tooling. It will be a great investment for the future.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Losing Data

    We hate losing data as professionals. We should not make the simple mistakes that make it easier for this to happen.
    We hate losing data as professionals. We should not make the simple mistakes that make it easier for this to happen.

    Most of us that work as data professionals hate the idea of losing data. When the developer calls and says his test database is gone and backups were never set up, we may shrug our shoulders and offer to help next time, but we feel bad. We will try everything we can do to recover the data, usually going out of our way to give it our best effort.

    We will lose data. There will be situations that are out of our control, and we have to accept that. However we should try not to make the easy mistakes ourselves that might cause data loss. I ran across a short piece on Five Sure Ways to Lose Data and I agree with the items, but I think there are a few more things we should watch out for.

    One of the easiest mistakes to make to forget is to set up backups. Too often we implement new databases under time pressure, dealing with software that is dropped in our laps at the last minute. Security permissions are never documented and during the frustration of just getting something deployed, we may forget to set up a backup system, intending to do it next week.

    Don’t do that. Get backups set up immediately. It’s quick, it’s easy, and you should have some automated process or script ready. As soon as you complete backups, invite yourself to a meeting to set up monitoring in the next day or two. That’s one of the other easy things to fix: ensuring your backup schemes are working by monitoring your servers. Your monitoring should include alerts for DBCC checks and high severity errors in addition to backups at a minimum. Automating this, or using a tool, are the best things you can do.

    There are lots of other things we might ignore that can cause data loss, but if you get your backups working, you should be able to recover from most any situation.

    Steve Jones

    Voice of the DBA Podcasts

    The podcasts will return tomorrow.

  • Quickly Copy Data

    How quickly can you copy data from one place to another?
    How quickly can you copy data from one place to another?

    There’s no magic solution for many of the problems we face in SQL Server. Whether we are trying to maintain concurrency under high write loads, restore databases quicker, or ensure extremely high availability we need to make trade-offs. Sometimes those tradeoffs are frustrating, and people look to other solutions like NoSQL, not realizing that they are just making different trade-offs.

    I see the frustrations and comments constantly on the SQLServerCentral forums, and one recent discussion was no exception. In this particular debate, a user was frustrated by the requirement to copy backup files across the Internet to another location. The transfers were taking too long and the poster were trying to find some magic way of decreasing the transfer time. Increasing the bandwidth, the simplest solution, wasn’t an option, and that usually isn’t easy to do in a corporate environment. The poster seemed to think there had to be some magic way of reducing the time it takes to copy large backup files, and there isn’t any magic solution. The things that help reduce transfer time are often the common things we think of.

    Compression is an obvious solution. There are numerous free programs to compress files and even software that will compress the backups as they occur. There are techniques in Windows for speeding up copies, though many are Windows version dependent. Beware, however, since copies from your server might cause you memory issues. However there might be other, more creative solutions that people come up with.

    Imagine that you track the transfers, keeping meta data about the process. Perhaps you can find a way to send less data overall the next time. In some sense, this is the idea behind log shipping. If you only send the changes (the transaction log backup), you might save a tremendous amount of time and resources. That assumes, of course, that the changes in a period of time contain less data than the overall database. That might not be the case in some  workloads.

    There are other services that might help. Imagine that you back up to the cloud, either because you use a tool, feature, or service if your application exists in the cloud. Spinning up a new instance with a copy of that data in the cloud might eliminate the need for transfers completely if the other location can just access the data in the cloud.

    I’m sure some of you have other ideas, and I’m sure many of us would like to hear what creative ways you might have for moving data between locations.

    Steve Jones

    The Voice of the DBA Podcast

    No podcasts today due to some personal issues. The podcasts should return tomorrow.

  • Fear Fear

    Are you too fearful or just paranoid enough?
    Are you too fearful or just paranoid enough?

    I’m a conservative DBA. I get nervous when backups aren’t running, code isn’t in source control, and developers have access to production systems. I’ve had too many late night pages and weekend phone calls, not to mention many extra hours spent in the office from changes to systems that didn’t go well. That latter item leads me to limit the number of changes I make to systems whenever I can, including avoiding applying Cumulative Updates to SQL Server.

    When I read an editorial from Glenn Berry, I had to stop and think of whether or not I had a healthy respect for the problems that can occur from change, or if I was being overly conservative (or fearful). Glenn makes a good point that so many people do not upgrade or change their drivers, firmware, or other software. People don’t patch their SQL Servers, even with Service Packs. I’m sure some of that is fear, but some of it is neglect as well.

    For me the decision usually comes down to examining the reward/risk ratio, trying to understand if improvements are balanced by the risk of downtime. I do value stability above new features, mostly because if problems do occur, I will be the person fixing them. That doesn’t mean I avoid all changes. I think Service Packs need to be installed, though not necessarily the first month. I’ve also come to embrace some of the continuous integration (CI) and continuous deployment (CD) ideas as ways to both reduce a software inventory as well as hold developers to a higher quality standard. However if you want to deploy (and perhaps patch) in a continuous deployment environment, then you should ensure that your CI process performs strong checks and make sure your developers are holding themselves to a high level of quality.

    We change the way we work, and the tools we use in technology often. Change is a concept we embrace, and we should since the ways in which our systems work are regularly changing. Bugs are patched, new techniques and tools are developed that should make us more efficient and productive. Those don’t always work, and we should be wary, but we should also not fear change. We should evaluate each new possibility with the attitude that our decision to move forward “depends.” It depends on the ease with which we can integrate something or apply a change, and the ease with which we can roll back our changes if they do not perform as expected. It also takes practice to ensure that all those things are easy.

    Steve Jones

    The Voice of the DBA Podcasts

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