Voice of the DBA

Category: Editorial

  • Baseball Analytics

    I love baseball. In fact, for the last ten years I’ve participated in an adult league each summer, playing 12-20 games each year against other 40 year olds. While we play the same game with the same rules as the professionals, we have a much different outlook on the game, with many of us enjoying the competition and distraction, but often viewing avoiding injury as a higher priority than winning.

    Baseball is an interesting game as the professional season is so long and for over a century there have been a huge amount of statistical data captured about each team. Prior to the fantasy sports popularity explosion, people had leagues that competed against each other solely based on this statistical data. I even wrote a program with a friend on an Apple II that allowed us to set up teams of random players, read in statistics, and then compete against each other using pitching v batting statistics, just showing us text results.

    I ran across an interesting post from a consultant that examined a hypothesis he had about winning baseball teams playing better at the end of the season. Using a free data set, the R language, and a Jupyter Notebook, he was able to perform an analysis that proved he was right. Whether or not you agree with him, I would guess that this analysis didn’t take that long to complete, and was fun as well.

    With R coming to SQL Server and the increasing call from organizations to perform more complex analysis on our data, I think this is a great way to get started. In fact, I’m thinking that I should load up some of the datasets myself and see what kinds of things I can prove or disprove about my knowledge of the game. If nothing else, looking at baseball stats is probably a fun way to brush up my statistics skills.

    BTW: Congratulations to the Kansas City Royals for their World Series win (and to the #sqlfamily in KC).

    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.

  • Virtual Failback

    I saw a very interesting tweet from Scott Stauffer asking this: “… looking for quick’n’easy way to make workload virtual w/ fail-fast method to physical if performance doesn’t meet expectation.” This was part of a conversation Scott was having in looking to move to a virtual environment from his current physical one. That’s something I think more and more people are being asked to do, whether they do in inside of their own data center, or they move to some type of hosted or cloud environment. There is increasing pressure from management to consider using cloud-type environments to reduce the capital expenditures for new systems and move to an operating cost model.

    I don’t have a fundamental problem with cloud environments, though I think it is important to carefully consider the pros and cons, but I can certainly appreciate Scott’s concern. No matter how well we architect things or prepare for the movement of a physical environment to a virtual one, there could be problems. Having a fall back plan becomes important, and even more important if we discover problems when some time has passed.

    While there are utilities that can move a physical machine to a virtual environment, there aren’t any (or any I know of) to reverse the process. Honestly, though, I think virtualization has so many advantages, that if I really had performance issues and needed to return to a physical host, I’d continue to virtualize my instance, but I’d have only one VM on my physical host, with access to almost all the resources on the hardware. Today’s hypervisors have so little overhead, I wouldn’t hesitate to run one virtual machine on a host.

    Ultimately, moving to a virtual environment is very much like moving to new hardware. There are definitely different configuration options you may need to set, but you can contract for some help with configuring your system. In the worst case, just use a single VM on a host, get hardware abstraction, and manage the machine like any other. Just don’t forget to have the hypervisor and your guest start up automatically after a reboot.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Secret Software Security

    This might not be the best title, but I like the alliteration for a the problems we have when governments seek to prevent security researchers from releasing information about software vulnerabilities. This is nothing new, as vendors have tried to prevent this for years, arguing that criminals will exploit the information and target users before a patch can be built. The other side of the argument is that many software companies don’t bother building patches if the issues are kept secret.

    What might be different in this case is that we aren’t talking about database software, devices, or banking websites. Certainly those systems may need secure software, but here we have the US Department of Transportation arguing that security details about automobile software shouldn’t be released. There is some leeway in that potentially limiting details might satisfy the government, but apart from that, how do you feel?

    Many of us use vehicles every day. We might use private cars, but we might use public buses, trains, and airplanes, all of which are making more and more use of software over time. I don’t know, but I suspect, that much of this software is being developed with an eye towards ensuring it works as intended much more than with a view towards how malicious users might take advantage of vulnerabilities. Far too often it seems that we have new systems where control data is allowed to transit the same networks and computing structures as less secure data, with minimal security across the entire system.

    I certainly think that some researchers might not appreciate the dangers of random people experimenting with the issues they disclose, but I also truly believe that the pressures of getting software released overwhelm the concerns and dangers that exist overall. There are no shortage of people with time to spare, abundant computing resources, and substantial intelligence devoted to finding flaws in software. They work at “hacking” the system to change behaviors. While it’s a game to many, there are very real consequences to the world if strong security isn’t built into vehicle software.

    I don’t know that I expect much to change, but I suspect that we will see more and more issues over time, more lawsuits and more highly technical and forensic analysis performed when we a system is attacked. I can only hope that we actually disclose poor security practices so that vendors do learn that their embedded systems need better, and more secure, software engineering practices implemented.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Leave Developers Alone

    This editorial was originally published on July 25, 2011. It is being republished as Steve is at the PASS Summit.

    A computer deals with interrupts all the time. They are the mechanism by which it can simulate multi-tasking among many different programs in a modern operating system. However those interruptions have a price, and too many of them can affect performance. As hardware grows larger, we have other issues from interruptions that we try to mitigate with techniques like soft-NUMA affinity or multiple pipelines built into hardware. All of these are designed to prevent a computer from spending any significant time on non-productive tasks because of interruptions.

    In the real world, many of us deal with regular interruptions from work. They might be emails, instant messages, phone calls on a cell phone, or the old fashioned someone-stopping-by-your cube-to-chat. All of these things add up to less productivity, especially for developers. One study finds a 10 point IQ drop from regular email and phone interruptions. I don’t know about you, but I’m not sure I can afford a 10 pt drop in IQ when I’m working.

    Some companies are starting to realize that developer’s brains are a scarce resource, and interrupting them can dramatically impact productivity. I have found some places, like this one, that are setting aside quiet time for developers to work without being bothered. Similar to the technical debt that Steve McConnell has talked about, there seems to be an interruption tax that some development shops are loathe to pay.

    Even if you don’t gain any productivity, or have fewer bugs, or ship more often, I think that your developers will appreciate it. It could be an easy way to increase happiness, improve retention, and even sell your company as a good place to work. And it’s easy to implement: just leave people alone a few hours a day.

    Steve Jones