Voice of the DBA

Author: way0utwest

  • One Week to Music City Tech

    Next week is Music City Tech, a three day conference consisting of Coding, Agile, and Data tracks, takes place in Nashville on May 31-June 2. There are a lot of great sessions on the schedule, covering a lot of software development topics.

    I’ll be delivering two talks, one on DevOps and one on security/encryption on Saturday. I’m looking forward to the conference, with some great .NET and development talks on Thursday and Friday, with a nice spread of data talks on Saturday.

    If you’re near the area, you can get tickets for a very reasonable price for the conference. I hope to see you next week.

  • Lessons for all of us

    I write a fair amount about career issues. It’s one of the largest tags in my word cloud, and I’m proud of that. I’ve seen too many people in bad jobs for too long, had a few myself, watched my wife work far too hard at times, and lost friends because of a lack of time. All of those experiences have caused me to really think hard about life and how I approach work.

    Don’t get me wrong. I like work, I enjoy what I do, I have a great time writing code and queries and think technology is a great career choice. That being said, it can be a hard job. There are demands to work long hours and holidays, often to deploy changes when the workload is low. Some years, I’ve worked as many holidays and weekends in this business as I used to when working in restaurants.

    That being said, we often think of this as an “easy” job in many ways. We work in offices. We’re well compensated. We don’t have a lot of physical demands, and we can do this job will into our later years if we choose. If you’ve ever worked in a job that requires more physical effort such as construction, you appreciate the ease with which our days pass. If you’ve ever had a boring job, such as staring at the x-ray screen in airport security, you’ll likewise realize most of us are lucky that we get to exercise our brains.

    That doesn’t mean this job isn’t hard. In fact, burnout and high stress are real problems in technology. While some industries might worry about their people getting enough done when working remote, our industry has too many people that don’t know how to stop working. I thought about this as I was reading a post on burnout and looking out for yourself.

    Many of us that work in technology are too sedentary. We sit at desks, we work odd hours and often subsist on poor diets that we’ve built during a lifetime of late night coding sessions. We also accept more blame, demands, stress, and accountability than we should. While I don’t know too many people that have had serious health issues from this work, I do know a few. I also know far too many people that have passed away before they reached 50.

    The downsides of this work can creep up on you. I know I felt a little burned out last year, from too much travel, too many balls being juggled, too much pressure. I made a conscious effort to slow things down and I’m much happier this year. I try to exercise and eat (slightly) better on a regular basis, balancing that out as best I can.

    We work to live, not the other way around. Whether you need fewer responsibilities, more exercise, new hobbies, better connections with friends and family, strong mental health care, or something else, make sure you take care of yourself in this life. It’s the only one you get.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Jobs in PoSh to Create a Load

    I saw this from Argenis Fernandez, and thought it was wonderful.

    1..128 | % { start-job -name ‘job name’ -scriptblock { & sqlcmd -S instanceName -U sa -P ‘iLovePoSh’ -i /home/username/test.sql } }

    Create 128 threads, each running a background job in PowerShell to connect to an instance and run a script file.

    Start-Job is used to begin a job, and then you can get information from Get-Job and use Stop-Job to turn things off.

    Very cool. Looking forward to trying to use this in a demo and make things happen.

  • Pause and Backtrack

    One of the main functions for anyone that manages a database is ensuring that they can recover the system in the event of any issues. My view is that restores are the most important skill and task that need to be performed on a database. Since restores require backups, I’d then rank backups as a 1a important task. They’re a dependency and necessity to ensure that we can restore data. Having a set of the data, in a transactionally consistent state just feels critically important to me, over everything else..

    I saw this new feature from Amazon Aurora for their MySQL compatible database. You can use Backtrack to rewind your database to a previous point in time. On one hand that’s an amazing feature. Make a mistake, have an error, click a few buttons and get the database restored back to the minute (or second) when you made a mistake. On the other hand, if you delete a table, do you want to roll all tables back to that point in time?

    This seems like an amazing feature. Amazon takes some of the hassles of managing some backups backups. You determine how far back you want to go, in hours, up to three days. Depending on the activity in your database, they charge differently. To me, that’s interesting. It makes sense to me as a customer. I do more, they track more, I pay more. This also seems to be a way to capture more money for Amazon by cutting some of the consumer surplus that exists with flat fee pricing, which is something many of us prefer.

    The way this works is also different than Azure. The Azure point in time feature allows you to go back, but you can’t restore on top of your existing database. You’d need to restore elsewhere, then play the rename game or move data between databases. While that seems inconvenient, if you’ve ever had someone restore a local SQL Server backup over a database you needed, you might appreciate the safeguards of not allowing a restore on top of an existing database. While the process might seem like a hassle, this does help prevent mistakes during a stressful situation.

    Which of these do I like? I prefer the Azure one, though I’d like the restores to be more granular than a minute. The reason is that I rarely want to restore in a disaster over the existing database. In most applications I’ve managed, there are updates to multiple parts of the database. A mistake in one table doesn’t necessarily mean that data changed in other tables should be discarded. Even during deployments, when things go wrong, I’ve often just broken one set of tables and rolling back the entire database in a restore is painful. Usually I’d prefer to undo what I can and get the any missing data from a restored copy of my database.

    Perhaps it’s just me, but I find the idea of allowing clients, or even many technical people, to easily roll back an entire database after a mistake to be very dangerous. By the time we recognize the mistake, verify data, notify others, we might have lots of changes in many tables. Abandoning that data for the sake of convenience is something that’s unnecessary. I also worry many people trying this feature don’t think through the implications of rolling back an entire database. If you feel differently, let me know. There are cases this is certainly helpful, but I think I’d rather have a “restore to a new db and rename both” automated task instead of AWS Backtrack.

    Steve Jones

    The Voice of the DBA Podcast

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