Voice of the DBA

Tag: administration

  • Starting a New Job

    I’ve had practice here, and was reminded of this when I ran across this thread on starting a new job. In my career, I’ve had far too many employers. I’d like to think it’s not my fault, but after having double digit jobs, I have to take some of the blame. I’ve often been looking for positions that I expected to last for many years, but something always seems to crop up. Even the jobs I’ve loved have ended sooner than I would have liked.

    As a result, I’ve gotten used to starting new jobs, learning a new environment, and quickly getting familiar with people and processes. I thought of this when I ran across a thread that talked asked about the first few things you should do at a new job. There are some good answers, and it’s worth a read.

    For those of you that start new jobs regularly, or are consultants, do you have a routine? Do you have scripts you bring along? When I saw sp_Blitz presented a few years ago, it seemed like exactly the type of thing you would want to have with you and go through on each instance you encounter. Something that gives you a good overview of how things look. While each environment is different and the configuration and settings will vary, it helps to have a view of the situation you’re familiar with. Even if you don’t change anything, at least you understand how the systems are set up.

    There was a time when I had a complete evaluation routine similar to sp_Blitz and an install that would create jobs for backups and maintenance in a consistent way. I had more a few jobs switch to my way of managing things because it was very efficient. These days, I think I’d use tools that are tried and true, using sp_Blitz, Ola’s backup routine, and @SQLFool’s indexing routine. I wonder if the rest of you have similar preferences.

    Steve Jones

    The Voice of the DBA Podcast

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

  • You Better Learn to Work at Scale

    Early in my career, I worked on a large Novell Netware installation. We bought a server that was about 1/4 the size of a modern rack, which contained a number of blade slots each holding some type of hardware: CPUs, disk adapters, network adapters, and even disk drives. The disk slots held ~30MB drives, which were large for that time. Both in capacity, and physical size. Each of these monsters weighed a pound or more, and felt like it was built to withstand a fall from a table top.

    That’s one reason that I’m amazed by the 64GB storage in my phone and stunned by the 500GB mSata card I recently bought. The storage capacities we have available to us today, in small companies and startups, are truly stunning to us as data professionals, but not to the people that have the space available. It seems on a regular basis people easily fill up the space they have and clamor for more. Whether that’s valuable data or not, I do know that much of that data still requires management and takes effort from us as data professionals.

    We’re not going to get more help, so as our databases grow, we need to find ways to manage more data, of disparate forms. Not just rows in tables, but Excel files, binary files of all sorts, XML extracts, Office documents, Hadoop hives and who knows what else. We need to be better at working with varying patterns of data, and perhaps files, at scale in order to continue to efficiently manage our workloads.

    Just like system administrators that are starting to deal with hundreds or thousands of virtual instances, we have to be able to write code that helps us manage data in large quantities. I like PowerShell for more and more tasks, but without a doubt, writing efficient T-SQL that works with sets, learning SSIS, package design patterns, and more will become the skills that differentiate the valuable and capable DBAs from those that just keep the lights on.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Taking Care of Things Today

    I get the weekly SQLskills newsletter, which I always find interesting. There’s usually a video on a topic that teaches me something, and as an avid reader, I enjoy hearing about the books that Paul Randal has read. However the main part is called Paul’s Ponderings and often has some thoughts that really make me think.

    In one of the recent newsletters, Paul talked about carpe diem, seize the day, and how we shouldn’t let things slide to tomorrow if we can do them today. The examples relevant to DBAs are some maintenance or preparation items that can be tedious or onerous (Paul’s words), like practicing restores for DR, checking indexes, and tackling some documentation.

    Many of us procrastinate tasks at times. Some of us procrastinate constantly, and if we don’t have any impetus pushing us to complete an item, we may delay it indefinitely. I’ve certainly been guilty of that, but I also have learned that I need to tackle some of those tasks regularly. I certainly want to be sure that my instances are healthy, and for me that’s often meant the tedious tasks of checking backups, space, and indexes as well as practicing restores, even when things were running smoothly. These can be mind numbing tasks, especially when you have scripts that do much of the work, but they really do ensure things continue to run smoothly for long periods of time.

    There are plenty of methods for motivating yourself, but I’ve found that setting a few monthly reminders and bunching up smaller tasks allows me to get all the busy work over with at one time. Being a DBA requires some creativity and skills, but it can also require a nose to the grindstone on a regular basis, no matter how boring that may be.

    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.

  • T-SQL Tuesday #62 – Healthy SQL

    tsqltuesdayThe invitation for T-SQL Tuesday this month comes from Robert Pearl. It’s called HealthySQL and it’s a topic I like. I’ve spent a lot of time in my career being proactive with SQL Server databases, and keeping them healthy is important.

    If you’d like to participate in the party, just write a blog post and publish it on the second Tuesday of the month.

    However, if you’d just like to participate, take the topic anytime and write your post.

    Healthy SQL Server

    I would guess most of us would prefer to be healthy over being sick. While it’s hard to be extremely strict in taking care of ourselves, many of us do make efforts to eat better, exercise, etc. to maintain our physical health. If we don’t, then we get sick and are usually miserable.

    The same thing can happen to our SQL Server instances, and if they get sick, many of us are miserable as well. Mostly because we might be working late, working overnight, or being yelled at by managers.

    I learned a long time ago that no matter how well I take care of myself, I’ll get sick at some point. And no matter what I do for my SQL Servers, at some point they’ll have issues. However if the issues could have been easily prevented, it’s embarrassing and it calls into question my capabilities as a DBA.

    I’ve got lots of stories of how I’ve prevented issues by keeping my servers healthy, but there are really a few simple things I’ve set up and worked on. I included these in my Avoiding a DBA’s Worst Days with Monitoring talk. I need to blog about these in more detail, but here they are with a few notes.

    Backups

    The core of any data system is the backup. If you have the data in a backup (and the backup is good), then you can recover from any other issues. As a result, I’ve tried to be sure that I have backups setup, monitoring on the backup jobs, and a process to make a copy of the backup somewhere else.

    Space

    Running out of disk space is one of the simplest things to avoid and one of the most embarrassing to deal with. I’ve written about placeholders, but you should be monitoring space, have placeholders available, and proactively look for more space as you get low.

    Security

    Security is important, and we read about issues all the time. However apart from hackers, loose security often means that users, developers, or anyone else can cause issues in your database. Tight security can be a pain, but it really prevents a lot of issues.

    Resources

    Resources refer to the hardware and software that allow your systems to function. If you don’t have enough resources for your workload, no one is happy and you are listening to complaints. Being proactive, looking to tune queries, reduce fragmentation, add indexes, reindex, update stats, and more are important here.

    Deployment

    Face it, we’ll always be changing our systems with new patches, code, etc. Building a decent test routine is important as we want to prevent deployments that will make our servers unhealthy. However having a plan to deal with issues (because you will have issues) means thinking about rollbacks or other methods of undoing problems.