Voice of the DBA

Category: Editorial

  • Flight Data

    I'm hoping this isn't the flight board when I travel tomorrow.
    I’m hoping this isn’t the flight board when I travel tomorrow.

    I’m getting ready to fly tomorrow, heading to SQL Saturday #175 in Fargo, ND. I have a morning flight, to give me a little time in the afternoon to go see the woodchipper. That’s if I don’t have any delays. I am planning on working in the airport and on the plane, so I won’t be less productive if there are, but I might not get the chance to see the famous machine from the movie.

    I’ll have a quick turnaround after this trip as well, coming home for a little over 24 hours before I turn around and head to the UK for meetings at Red Gate next week and SQL Bits XI next weekend. I’m hoping that none of the airlines have data issues since those can severely impact my travel times. Last week American Airlines had computer issues, and while United hasn’t had any in awhile, my fingers are crossed that this won’t be the weekend their systems go down.

    We have gotten so computerized with many of our transportation systems that problems can interrupt service, usually just causing annoyances, but there is a potential for lives to be lost. Since we don’t often know why the systems fail, it’s hard to know to what extend we have poor coding issues, improper secure development, incorrect configuration, employees susceptible to social engineering or something else. We even had a computer failure in space, though I’m sure the astronauts weren’t annoyed by the alert.

    These days it becomes increasingly hard to roll back to manual processes, not because of the complexity of the systems, but also because the knowledge on how the processes should work is being lost as employees leave the company. This means more delays, but hopefully not important safety rules being ignored or forgotten. I know the airlines have invested heavily in IT, and flights record a lot of data, but I hope they’ve done so in a distributed fashion. Lots of caching, fault tolerance, and most importantly, communication to allow their operations to proceed when the real world interferes.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Natural Data

    Can you patent a gene, which is essentially data?
    Can you patent a gene, which is essentially data?

    Can you own data? In one sense, that’s what the arguments before the US Supreme Court over a Myriad Genetics patent are about. The company has patents for a few genes, which in and of itself, are really just data about a particular organism. There are a lot of technical issues here, and I’m not completely sure how I feel about this topic or who I’d like to see prevail in the case. I do think, however, that this does have lots of implications for how we might view other data in the future if the patent is upheld.

    As data professionals, we usually think of the mechanics of dealing with the various pieces of data in our organizations. We must protect data, ensure it’s integrity, make it available and more. A large part of our careers is spent manipulating or managing the bits and bytes stored in databases. We must extract information out, and often need to understand what the data represents to do this, but most of us haven’t been exposed to the issues of ownership or rights with data. I think that will increasingly change as government rules, regulations, and laws scramble to catch up with the digital world.

    Digital ownership is a very thorny subject, complex in its breadth and depth. We’ve seen technology companies fight against some laws, like CISPA, while supporting others. Often our government officials don’t understand the complexity of the topics, and I’m not sure that we in the technology business explain the the situation well. Even very intelligent people often don’t convey the implications of these complex topics, many of which often don’t have good analogies in the analog world.

    Ultimately I think we will find our jobs as data professionals becoming more and more complex as we must not only solve problems and manage data, but we will also end up being constrained by the legalities governing the data.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Accelerating Your Career

    Climbing the ladder isn't for everyone, but that doesn't mean you ignore your career.
    Climbing the ladder isn’t for everyone, but that doesn’t mean you ignore your career.

    I ran across an article on ways to accelerate your career and for the most part I think these are good ideas and suggestions. Networking, finding a mentor, and more will help you no matter what business or field you are working. Some of the advice is geared towards those people looking to climb the corporate ladder and move into management, which is not necessarily what many of us want. If that’s the case, ignore those items. There was one item, however, that I thought was particularly interesting for data professionals.

    The seventh item on the list notes that you should spend 10-15% of your time working on a project that’s outside of the scope of your job or team. That might sound crazy, and even dangerous, but it’s a good idea if your boss isn’t opposed to it. Having knowledge about the way your business works, the way they use data, or solve a problem, could be valuable in your existing job. You might notice a pattern or way in which you could improve either your job or someone else’s. Over time, helping in a variety of departments builds friendships, increases your networking, and might show your boss you deserve a raise.

    Many of us end up working with data as a widget. The job of a developer or DBA is writing code or managing data, and sometimes don’t often think much about the actual industry in which we are working. Gaining deeper knowledge of the way your particular business works means you can better understand why you are asked to solve a particular problem. That knowledge can lead to a better solution. It might also make your job just a little more interesting.

    For the typical US worker, that’s 4-6 hours a week. For the IT person, that might be a little more time, but I think it’s worth the investment. I wouldn’t be overly driven in this area, and if I were working on extra projects at work, I’d eliminate (or cut down) on the time I was spending learning new technologies. Life requires balance, and if you tackle something new in one area, make sure you know what you can give up.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • A Billion Transactions

    These are some of the sensors generating that half billion transactions/day.
    These are some of the sensors generating that half billion transactions/day.

    How long would it take your systems at work to process a billion transactions? You’d expect some, heavily used and highly visible systems to be involved. The stock market systems process billions of trades a day, but I’m sure most of the systems in single companies, even large companies, deal with fewer transactions on a daily basis. A billion transactions a day is 11,000+ transactions a second, sustained across the entire day. That’s a heavy load, but it might be the level of transactions that more and more of us will see over time as our systems gather more data.

    The Microsoft corporate headquarters in Redmond consists of over 100 buildings on 500 acres. It’s grown over the years from its original 88 acres, which is also the title of a story about Microsoft and the relatively unknown work in automating their infrastructure. Not the computer systems their software developers use, but rather their facilities and physical buildings. It’s a fascinating story that outlines the way in which Microsoft saves millions of dollars in maintenance and repairs by using software.

    Across those buildings, Microsoft collects a huge amount of data, from disparate systems, which is the presented to the facilities personnel. The sensors and systems don’t process a billion transactions day; they process half a billion. Still an amazing amount of data, just from physical buildings and the infrastructure that ensures Microsoft employees have a pleasant place to work every day. Using a combination of SQL Server, Office, and Azure, Microsoft has built a software system that corrects many faults itself within sixty seconds. Those that can’t be fixed remotely often end up generating one of the 30,000 work orders produced for personnel every quarter. The system is forecasted to save 6-10% of the energy that might otherwise be wasted with a less efficient system.

    It’s a great read, and perhaps is a good case study for an application that is well suited for cloud services. There are a few great quotes from the article as well that are particularly pleasing to a data professional. “Give me a little data and I’ll tell you a little,” he (Darrell Smith) says. “Give me a lot of data and I’ll save the world.” That ought to be the model for data analysts. As SQL Server professionals and developers, we should be helping others to do just that.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.