Voice of the DBA

Author: way0utwest

  • Why DevOps? Employee Satisfaction

    DevOps is being embraced by more and more companies, but still a minority of organizations that perform software development. There are plenty of software developers, project managers, and operational staff that are comfortable with their own process, even as they may struggle to produce software for their customers. I think DevOps is a better way to build software, and today I want to look at a benefit beyond faster releases. Today, let’s talk employee satisfaction.

    The State of DevOps report shows that companies who have implemented a DevOps process have more engaged and happier employees. According to the eNPS (e Net Promoter Score), the employees are more likely to continue to work there, and recommend the company to their friends. That endorsement of the organization comes with two benefits. Employees are more productive, and they bring other good employees to work. After all, how many employees recommend someone they don’t want to work with or don’t think can do the job?

    More deployments, easier deployments, the ability to get your code used by customers while you still remember how it works. These are the keys to helping employees enjoy their jobs. When employees are more engaged, and when they are satisfied with their jobs, they work in a more focused manner, trying to ensure their work produces results that help others in the company. In other words, more valuable code.

    DevOps isn’t new; it’s a name given to a number of productive, effective practices that the best software developers have been following for years. The idea of DevOps is being more and more widely embraced, resulting in better software, along with happier employees.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Using Trace Flags

    At SQLServerCentral, we recently published a list of all the trace flags from Konstantin Taranov. It’s a great list, and thanks to Konstantin for compiling it. While I haven’t often used trace flags, there are some that have really helped me at various times when I needed to change SQL Server behavior. If you aren’t sure what trace flags are, Erin Stellato of SQLskills wrote a great post recently. I see trace flags as feature flags. The development team can allow us to experiment, test, and use functionality at our discretion, or ignore it.

    This week, I wanted to ask how many of you are using Trace Flags right now. Do you have any running in code or set for startup on your instances? If you don’t know how to do this, we’ve got a short piece to help you.

    In Erin’s post, she notes that SQLskills only recommends three trace flags (depending on version) for their customers. In general, I think that’s good advice. There is a risk with using flags, and certainly I would be wary of using without substantial testing. I do think Erin’s list is good, and you might consider using those. I also become wary about trace flags that aren’t embedded directly in code. I think these trace flags end up being hidden from anyone troubleshooting issues. After all, how many of you actually go to the Configuration Manager or the Services Applet and look for parameters?

    I expect that most of you don’t run trace flags on your instances. There may be some of you that have never heard or, or used, a trace flag in your career. That’s fine, though I hope you use today to a) let us know, and b) educate yourself to ensure you know how to enable a flag you need one. If nothing else, add one to a test instance, and ensure you have the skills to actually make the change.

    Steve Jones

    The Voice of the DBA Podcast

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

  • SQL Bits in less than a month

    I’m getting excited, and you should as well. Join me at a fantastic conference in the UK this spring. Register today and come to a training day and learn something. I might just see you there, as I’m thinking to take one or two myself.

    I’ll be presenting “Including Your Database in a DevOps CI/CD Process” on Friday. I’ll be looking at how you can deal with the challenges of database code in a software development process.

    There are lots of great sessions, and whether you come for 1 or 2 training days, just the Friday sessions, or on the free Saturday even, this is my favorite SQL Server conference and I’m sure you’ll find it to be an amazing event.

  • Global v Session Trace Flags

    I wrote a short article on enabling and disabling trace flags. You can read it, but I didn’t really discuss the implications of session v global trace flags, which is something I’d like to do here.

    In the article, I set trace flag 3226 for my session. This showed that a second backup wasn’t in the error log. Note the image below doesn’t have a backup message after (above) the trace flag change entry. You’ll have to trust me that I ran the backup, enabled the traceflag, and then re-ran the backup to get this image.

    2017-03-02 11_54_50-Log File Viewer - ._sql2014

    However, if I have a backup job, as I do here, does the trace flag affect this? This is, after all, run by SQL Agent, which would be a different session.

    2017-03-02 12_36_08-Job Step Properties - backup

    It turns out that the session trace flag doesn’t affect this. I ran the backup job and there was a message in the error log.

    2017-03-02 11_56_19-Log File Viewer - ._sql2014

    To suppress this, I’d have to use DBCC TRACEON (3226, –1) or put this in the startup parameters to ensure none of these messages appear.