Voice of the DBA

Category: Editorial

  • The Giving Back Workload

    One of the amazing things about the #sqlfamily is that we often help each other in a very giving way. Certainly other technical communities have lots of sharing and helping, though often with more of an RTFM attitude. I don’t know how well many other industries share information with each other, but the nature of being connected with technology through blogs, free events, #sqlhelp and more certainly seems to facilitate lots of sharing.

    When SQL Saturday first started, Andy Warren and I worried that we would struggle to get speakers to donate time for a number of free events. The first year we had discussions about how to find speakers if we were to get 10 events scheduled in a year. That proved to be a non issue. It’s amazing to think that these days we have 6 or 7 events on a single date, and I’m looking forward to the time when there are actually 10 events on one Saturday.

    Our speakers donate a lot of their own time and money to give back to others. In 2018, I’m particularly impressed by Kevin Feasel, who I was lucky enough to see at a number of events and even share a bus ride on a double decker in Cambridge. I’ve also met a number of volunteers and attendees who have had similar schedules during a year or two, where they have lots of excitement. What often happens is that after a few years, they scale back, some of them even giving up on all of their efforts.

    It’s wonderful that people give back, but I do worry about sustainability, both for events and individuals. Andy Warren wrote recently about volunteer time and the load in life. I haven’t tracked my time, but I know that it sometimes is quite a load. While Redgate often covers my expenses, the time away from home to speak at events comes out of family time as I still need to work a normal week when I’m speaking on Saturday.

    I do think it’s important to volunteer and give back to others. Help those getting started, those less fortunate, or those that are inspired to move forward in life. There’s a time and place for all of us, and I do hope all of you think about where and how you can help others, either in this field or in other ways. If not now, then at some point in the future.

    Time is a valuable resource, and while I think Andy underestimates the amount spent on his endeavors, I think it’s good that after many years of helping others, he is trying to quantify the time spend and perhaps inspire some of you to think about where you might do the same. 50 hours a year is both a lot and a little. What are your plans for the coming year and could you spare 50 hours to help others? Leave a comment here, and let Andy know what you think of his plans.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Lack of Memory

    I was reading Brent’s look at “normal memory” for his SQL ConstantCare® clients. It’s a look at some stats from quite a few servers that customers have set up and he is monitoring. Since most of us only have a limited set of instances to examine, it’s nice to see what a wide variety of installs are using. Even though this doesn’t necessarily mean we should change anything in our environment, it does help me to understand some general trends, and perhaps think about how to recommend settings for new installations.

    When we build a server, we expect it to work a certain way. Over time, we are almost always adding data to the system, but often we don’t add more RAM. This would be like buying a vehicle and loading it up with supplies you need for work. If the amount of supplies kept growing, would you keep piling them on or buy/rent/borrow a bigger vehicle? Some would, some wouldn’t.  I’m always amazed by how far people will push a situation, especially when fairly small and inexpensive changes might make a big difference.

    Data size isn’t always a good indicator of how much memory you should allocate, but it can be. Certainly the more data we query in a workload, the more memory makes a difference. Bad code is more likely to surface issues, but memory is often cheaper than paying developers, or usually, finding and training developers to write better code. For a DBA, this might be one of the relatively few differences we can make in the short term that has a far reaching effect. Adding memory might cover up some poor coding and speed up the experience for clients in the short term. In the long term, things will likely tip over again.

    If you manage an instance, you can’t usually change code, and it can be hard to get developers to prioritize changing existing code. Most developers are pressured to move forward with new work, not refactor old work. One of the reasons I like moving clients to a database DevOps flow is that DBAs with query tuning skills can spend more time tuning some queries and giving code to developers. It’s much easier to get developers to fix bad code if you give them better code than ask them to find time to rewrite things.

    Getting the best performance out of your database server often a balancing act among various choices that each only solve a portion of the problem. Don’t be hesitant about asking for more memory over time, but also be careful that you don’t just depend on this one technique to reduce the number of customer complaints. Learn to write better code and teach others to do the same.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Thinkers and Doers

    When I was first starting work in the data space, we had an architect at the large company that employed me. This individual reviewed new application proposals, decided on platforms and technologies, and mostly went to a lot of conferences. I think this was a smart person, but they never seemed to do much work, mostly just talk about technology and ideas. As a young person in a career, I both coveted the job (good pay and hours), and thought it ought to be eliminated.

    These days I think architecture is important, at least at a coordinating level. I don’t know that it needs to be a full time job, but we need a person not too distracted by daily work examining how we build our systems. Perhaps this is the type of position that someone with a lot of experience that wants to work part time ought to hold. If you have such a position, call me in about 15 years.

    In this blog from Stitch Fix, who gets way too much money from my family, an engineer talks about the data science world, with scientists, data engineers, and infrastructure engineers. This is written as an ideal way to structure the data science/analysis part of your company, though not necessarily what is happening at Stitch Fix. The idea here is that the work of writing ETL pipelines isn’t something that anyone really wants to do, at least not as a full time job.

    I saw a note on Twitter, asking what Andy Leonard thinks of this. If you don’t know Andy, he’s one of the #sqlfamily data professionals that focuses on ETL work for clients. Andy disagrees with the piece, noting that he likes writing ETL flows. I hope so, because Andy has made a living producing data import and export routines for clients, and he’s written a number of Stairways at SQLServerCentral (SSIS, Biml, ADF). Andy really likes this stuff, though perhaps he’s an outlier.

    What I think is that most people like a little variety at work. Even if you are an expert at a very niche skill, I’m sure you look for ways to express some creativity and change your job just a bit on a regular basis. Most of the very talented craftspeople I know, whether in technology, construction, medicine, etc., like a bit of variation in routine. Even as a developer or DBA, I’ve enjoyed breaking up my job on occasion to handle some other task, from firewalls to email to project management.

    Where I see people not enjoying a change is when they are focused on a solution and their skills are not up to the task, or perhaps their skills are rusty. I think SSIS is a great platform at times, but it’s also not very intuitive to use and easy to get frustrated with the interface when trying to set up some data movement. I suspect that many data engineers that really want to focus on problem solving do hate writing ETL pipelines, if their focus and interest is in some other area.

    If you don’t enjoy most of your daily work, then perhaps you need to change. While the article has good points about engineers improving and providing ways to efficiently move data in a scalable manner, I’m not sure I want them trying to produce too many “Lego blocks” for data movement. Rather, I think they ought to be building those pipelines with patterns and best practices, providing ways for others to consume their work, or even adapt it where needed. Just avoid building bespoke work for every new request. That’s tedious, it certainly might make an engineer dread their work, and it’s a poor way of working.

    All of us in technology need to learn to be the thinkers. We need to find ways to improve processes and adopt better ways of working as computers and technology become more and more embedded in our organizations. This isn’t chasing the shiny new technologies every year, but it is ensuring that you are not working the same way year after year if there are better techniques out there.

    Steve Jones

    The Voice of the DBA Podcast

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

  • My Favorites from 2018

    Recently we had a webinar with Grant, Kathi, Kendra, and myself to discuss the year in review. We talked about our favorite things from the year and made a few predictions for 2019. I like to do this myself every year, usually in a general sense, looking over the entire data platform and technology world. In our webinar, Kendra asked us about some favorites, and I thought I’d look back at memorable items for me in 2018.

    I was lucky to attend a number of events this year. My speaking schedule was 25 events and 37 talks, a few of them virtual events. Around this I managed to get to 4 other events where I didn’t speak, 2 volleyball tournaments, and went on 5 family trips. A busy year, but with some exciting highlights. My two favorite talks were at security events in Cork and Washington DC. I had the chance to speak to a different audience about Database DevOps, and they were very interested and anxious to spread the word to their organizations.

    My wardrobe didn’t get quite the same upgrade as Grant’s, but I did get one new shirt this year. Only one?? (perhaps more next year) Still, I had a great time at our SQL in the City Summits, which we’re planning to repeat next year. Stay tuned for dates, but we’ll likely run a number in the US, the UK, and one other country. Fingers are crossed as this will be a new country that I’ve never visited. I missed SQL Bits this year and will next year, but that’s my recommendation if you get budget to attend an event. With lots of flight deals, you might even find it costs as much to go to the UK as attend one of the large conferences in the US.

    I have a great job with Redgate, and I really enjoy talking about our products when I can. This past year, with the GDPR coming into enforcement, has had me focused on our Protect and Preserve area. While I enjoy talking about Database DevOps overall, I gave quite a few SQL Provision demos, which is one of those amazing products that really changes how you proceed with development. I’m hoping this is a continued area of growth, both because I like the topic and product, but also I do think we need better data handling practices as an industry. Next year I hope to do more work in this area, and add in some container talks as well. I’m also thrilled with making a difference with suggestions and lobbying for the product teams. Clone Resets and Installed Versions were two of the items I’ve heard from you and suggested myself that were implemented. Keep the feedback and votes coming.

    My least favorite moments of the year were losses in the community. I took a moment to mention this in an editorial, at the PASS Summit, and in the webinar. I didn’t know Stephen Hawking, but I do miss chatting with Tom Roush, Robert Davis, Aaron Lowe, and Naomi Williams. Unfortunately part of aging is losing friends and family. I added a section to Database Weekly for obituaries, and while I don’t relish adding links, let me know if someone passes.

    I’m also excited about the new version of SQL Server 2019 coming. There are some fundamental changes coming in how we might process and query lots of data. I don’t know what I think of the Big Data Clusters and some other features as they’ll be 1.0 releases next year, I do think that this is a shift in how we might think about SQL Server that will affect us in the next decade. I certainly am looking forward to a more robust Linux feature set as well as how containers will change the way we work. If you haven’t looked at them, now might be the time to start.

    Hopefully you’ve had a great 2018 and are looking forward to ringing in 2019 tonight. Stay safe and enjoy yourself.

    Steve Jones

    The Voice of the DBA Podcast

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