Voice of the DBA

Category: Editorial

  • Do Less

    When I read this blog post, I was transported back to simpler times, when I learned to develop applications on 8088 processors. Back then, to make the system go faster, we learned to do less. It’s certainly true that the less work a system performs, the faster it can complete the limited set of things it must do. Working within C code, most programmers I knew back then tried to optimize algorithms by reducing the amount of work that our CPUs needed to perform.

    In T-SQL, we don’t have the low level of control we might have in other languages. In fact, our language has a relatively small number of instructions that we we use to build queries and applications, though that number continues to grow and expand over time. I am grateful for that, but also realize this brings with it additional chances for developers to write code that does more work than necessary.

    For much of our work, optimization consists of finding ways to group our operations together. Building a set-based solution takes advantage of the way in which SQL Server most efficiently processes instructions. Far too often there are developers that write inefficient code because they apply techniques they’ve learned from programming applications in some other language, or even from some other relational database.

    For a given system, there is a known amount of work that can be done in a period of time. There are also restrictions on the various resources involved (disk, CPU, network, etc). Reducing the load for each of these resources, especially in multi-user systems, can dramatically increase the performance of your system. SQL Server is built to manage concurrency in a variety of ways, but poorly written code is a great way to overwhelm the system.

    Do less. Get more performance.

    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. 

  • BYOD

    This editorial was originally published on Jan 18, 2012. It is being re-run as Steve is on vacation. Some minor edits were made

    As laptop prices have plummeted over the last few years to the point where most technical people can afford to purchase their own machine for around $500. Unless you want a really high end machine, in which case you’ll be looking at something over $1000. I have even used Macbooks for my work. There are quite a few people working with SQL Server on OSX, however, so if you want one for work, you can make the switch, and here are a few blogs for you (Aaron Bertrand, Brent Ozar, Joe Webb)

    As computers become a commodity, and we use them more and more to live our lives as well as work, does it make sense for workers to purchase their own machines and use them in a corporate setting? I know some companies give workers a computer allowance and the workers can take the machine with them if they quit, presumably if they work at the company for longer than a few months. Other companies give their employees money for technology, which can be exciting for technical people that might want to upgrade their monitors or other accessories regularly.

    There are definite security and data concerns, but with cheap memory, disks, and hypervisors, it’s possible to get around those issues, and allow employees to work with the tools they are familiar with. I ran across this blog that talks about workers owning their own devices in the future, even being required to provide them. Just like many other professions where the workers must own their own set of tools.

    On one hand this seems crazy. Employers should provide computers, and as a young worker in this business, I would have struggled to purchase a $1500-2000 laptop. Or maybe I wouldn’t have. Maybe I would have seen it as an investment in my career, just like college was. These days, we have even more devices, and while IT departments struggle to secure them, that doesn’t stop people from using them, or wanting them. I think I’d like to provide my own smartphone and laptop, and get some sort of allowance from my employer each year to offset the cost.

    I don’t know how we’d handle the data/security pieces of this scenario, but I’m there would be no shortage of ideas from the various software vendors.

    Steve Jones

     

  • The Matrix

    Do you want the red pill or the blue one?

    Many of us know the famous scene in The Matrix where Neo decides if he will come out of his dream. We also see the exciting moments in the movie where he has various martial arts downloaded to his brain, and discovers he “knows kung fu” in a small fraction of time. Certainly he doesn’t ever need to physically practice the art, but much of learning is comprehending and understanding a subject in our brains.

    We aren’t at the point of desiring a skill and purchasing a download. Yet. However there is research into using various types of stimulation to actually help improve learning and training. Using pilots and flight training, a complex and varied skill involving both physical coordination and mental understanding, the researchers think they can affect learning. Which is amazing.

    This is barely scratching the surface of learning directly in the brain, but it is interesting to see people researching the topic. After all, this is an area that ought to be of great interest to those of us working in technology, where the acquisition of new skills is important. Few of us do it well, and any improvement that could dramatically improve our capabilities to adapt and grow as technology rapidly advances, would be welcome.

    Unless it involves electrical shock potential. In that case, I’ll stick with my slow read-and-practice method for learning new skills.

    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. feed

  • The Math on Automation

    I wrote a piece on automation and time savings, and of course, Derik Hammer had to point out another post and xkcd cartoon that splashes some reality on automation. I’ve included it below, and certainly there are some good points made in the cartoon. It is incredibly easy to underestimate the amount of time it takes to complete a software project, especially when you include maintenance. Make no mistake about it, scripting little tasks and adding code into SQL Agent jobs is building software.

    The decision to undertake automation shouldn’t be strictly made on the math of time savings. There are a number of other gains to consider. The post linked above notes that the fact that interruptions can be minimized through automation can be very valuable. I know many people discount the cost of disruptions, but they can be high, especially for knowledge work. This reason alone might be worth spending time on automation.

    I feel that building some automated processes is a great way to actually practice skills you might use elsewhere. Automating tasks is practical, and even if the exact method isn’t a technology you regularly engage in, the mental practice of working through a problem and developing a solution is valuable. Just engaging your brain on a problem can be a good use of some time.

    Those people that have followed the ideas in DevOps for years know that one of the main powers of automation is consistency and repeatability. We know that humans are bad at being consistent and reliable, and those are the places we should use computers. Even if the time savings don’t directly add up, I’m sure the chance of you breaking something, forgetting a step, or even neglecting a task are likely work a little bit of automation time in your job.

    You don’t want to get caught up cerating a large side project to automate something, but little scripts to save time are definitely valuable.

    Steve Jones

    The Voice of the DBA Podcast

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