Voice of the DBA

Author: way0utwest

  • Programming

    programmingTechnology is here to stay, and those of us working in this business probably realize more than most people how dependent and integrated our lives are with technology. Even in countries that don’t have the infrastructure or economies of first world nations are using more and more technology in their lives. Mobile technology seems to be at the forefront of much of what we do, but I’d argue that data is fast becoming more important than the software itself.

    The one thing I’m becoming more convinced of is that this article is right: programming is a core skill. It doesn’t matter if you’re a developer building mobile apps, or a contractor scheduling workers, or a homemaker that wants to balance a budget. While there is software that might help, it seems many people are quick to open a spreadsheet, add some data, and start building formulas. These days the jokes about people not understanding how to program a timer on a DVR are fading quickly as more and more non technical people are using technology to make their lives easier, or perhaps, more complex, as they manipulate data and software.

    I suspect the fundamental skill of logically analyzing a problem and coming up with a set of steps to solve it is becoming more important all the time. In many businesses the ability of workers to think for themselves and handle a variety of situations is more desirable than the ability to follow orders. Even in industries where workers need to follow instructions, those instructions might be coming from computers more and more often. There will be a huge gap between workers that can think for themselves, perform data manipulation and make business decisions and those who cannot. That gap might take the form of compensation differences, opportunities, or something else, but in many industries, those that can build their own programs, whether in code or processes they follow, will advance faster and further.

    Not everyone will want to be a computer developer, but most everyone can benefit from understanding how calculations and instructions can be chained together to build a process or workflow. With newer generations becoming familiar and comfortable with technology from early ages, my vote would be that we should add programming to the three Rs for future generations.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Reporting on Data

    I would think that most DBAs and SQL developers out there realize they need to understand some basic statistics and mathematics to write meaningful reports for their customers. Since many of us write our reports in T-SQL, if we correctly write the formula for one row, it expands to work the same way for all rows returned from the database. That should hold true in Excel, if you cut and paste the formulas across the all the rows or columns. However since each cell could have a different formula, you can’t always be sure that the calculations for all rows are the same.

    This was brought to light in a blog that looked at the problems with a public policy analysis based on an Excel worksheet. The audit-ability problem of validating results in Excel was one issue, and it comes about because you would have to manually verify the formulas in every cell to be sure they were correct. I’m not sure how many people want to do that, though I like the transparency of providing the formulas with the data. Someone will verify them.

    The other part of the blog talks briefly about other issues. One is that to accurately represent the meaning of data, we need to do more than show simple aggregates like range or average. The reduction of a set of data to a single or small group of representative values may not describe the information in the data. An average without knowing the variance or standard deviation may not be the data you want to base a business decision on.

    As we seek to provide more accurate information to our customers and clients, we need to better understand the data we are querying. At some point it won’t be enough to understand the basic aggregates in order to report on data. Big data can provide many false patterns, but tiny data suffers from a similar problem. We need to learn more about statistics and analysis to ensure that as we work with business people to query data, we understand what information we are extracting out of data sets.

     

    The Voice of the DBA Podcasts

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

  • T-SQL Tuesday #44–Second Chances

    tsqltuesdayIt’s T-SQL Tuesday time again. This is the monthly blog party, started by Adam Machanic. If you’d like to participate, write a post on the topic and publish it on the second Tuesday of the month. If you’d like to host, contact Adam.

    This month the topic is hosted by Bradley Ball and his subject is Second Chances.

    Second Chances

    We all make mistakes. I ask the question of people in some of my talks, and note that I make mistakes all the time. I do, and while most of them are fairly small and easily recovered from, some aren’t. Some are easy to brush off, and some are very, very embarrassing.

    In my career, when I think about the big mistakes I’ve made, I’ve got a few choices. There have been times I’ve deleted all the data in a table.

    secondchance

    There have been times I’ve restarted a SQL Server without telling anyone. There have been “fixes” to the system I’ve made without running through the proper channels. However there is one item that stands out for a few reasons.

    SQL Slammer

    I’d let patching slip. We had a large SQL Server environment (hundreds of Standard/Enterprise versions, thousands of MSDE versions) and while we’d been trying to stay patched, it was a hassle and we let some things slip in the fall of 2002.

    I’d gone to the mountains for the weekend to ski with my family. We returned late on a Sunday night to find numerous voice mail messages at home and on my cell phone. I was actually called again while I was checking messages on the way home from a friend at work that said I needed to come in. After dropping off my wife and kids, I headed to the office.

    Our analysis of the worm showed that it was wrecking havoc on our network. It constantly bottlenecked the network, and we had shut everything down. For a 5,000 person company, with a central network presence and hundred of software developers, this was not ideal. We were up most of the night, waiting on someone from Microsoft to fly in and help us rebuild the patch that Microsoft had released. Since we’d installed many instances of MSDE in non-standard locations, the patches wouldn’t work.

    Our network was down Mon and Tues, but we learned some valuable lessons, like email and file shares weren’t so critical to the business that we couldn’t function for a day. We also learned that allowing developers to ignore patches was a bad idea as the majority of the delays after Mon afternoon were due to MSDE instances.

    My lesson? Myself and the other DBA received a stern talking to from our boss about patching. We had delayed some of the patches for a few months, but there wasn’t a good excuse for getting almost six months behind. Microsoft had been sending lots of patches, but we didn’t have a good reason for not getting them installed quarterly.

    I still don’t like the every other month patches that MS releases as cumulative updates, and I don’t recommend them, but I have learned the security updates are worth getting installed ASAP.

  • Your Frame of Reference

    sql_cat_logo_smIs a database snapshot in SQL Server update-able? Most of us would say no, but I ran across a blog from the Microsoft SQLCAT team that proposes a method of issuing an insert, update, or delete statement in a database snapshot context. You can read the article for the details, and we could argue if this is really allowing a snapshot to be read/write, but that’s not what I noticed as I read this.

    This is a very creative way of approaching a problem. It changes the frame of reference slightly so that we rethink what the customer is trying to accomplish instead of what the technology limitations are. There might be more elegant, or more easily maintained solutions, but I found this to be creative, and perhaps useful, approach for solving a certain domain of problems.

    I think quite often we get caught in viewing problems in terms of our frame of reference, or in terms of common technology implentations without thinking through the problem from the customer’s frame of reference and working on an effective solution. That’s our job most of the time: being effective as we solve problems. If we view all problems within the narrow range of our past solutions, we are relying on our experience, but that may prevent us from building applications that work better than our past work, go beyond what our customers want and get them excited about using the end result.

    However it’s a balance. I’ve seen hacked solutions that didn’t perform well, or didn’t scale and ended up causing problems for years. Looking at the problem from the customer’s viewpoint needs to be tempered with the requirement of building a solution that performs well and fits within the framework of the environment. Ultimately I think the way to get better at building applications (and databases) is to increase your knowledge and experience. Learn more about other people’s solutions, and engage with the rest of the community to sanity check your approach.  Learning new techniques that have worked for others, and experimenting in your environment to build better software over time.

    The Voice of the DBA Podcasts

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