Voice of the DBA

Author: way0utwest

  • The SQL Server Container

    I’ve been hearing about Docker quite a bit lately. It’s a piece of software (and a company) that builds containers that provide isolation for an application, allowing a more lightweight way to separate our applications than virtualization. Right now the containers only run on Linux, but they allow a Docker container running PHP to run on a machine as though it were the only process running on the Linux host. Other Docker containers running on the same host could contain different versions of PHP and not have conflicts. Or you could have multiple versions of MongoDB, MySQL, Java, etc. that provide separation in a much less resource demanding way than virtualization does.

    It makes me think back to the idea of having stripped down, lightweight database machines. We’ve gotten the Windows CORE OS, but I wonder if Microsoft would ever take this a step further and package an even more stripped down Windows OS, with SQL Server embedded in it. Rather than have to install Windows, SQL Server, and then potentially have administrators want to install other software on the host and incur the overhead of sharing resources, could we have a single installation that includes a bare bones, stripped down and optimized Windows/SQL Server combination that only functions as a SQL Server database machine?

    I doubt Microsoft would ever move in that direction, but perhaps they might use a similar concept. It seems the push from Microsoft is for more services and hybrid solutions involving cloud type services. Perhaps smaller companies might want an appliance device that contains a SQL Server, or an application like Dynamics, with hybrid bursting power in the cloud. Certainly containers might make deployment of software easier in a PaaS environment.

    Either way, Docker is coming to Windows, and it’s going to be another tool that developers should consider incorporating into their application development processes.

    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.

  • MY Data

    Data is merely a set of numbers. However when data is given context, it allows conclusions to be drawn and many of us make a living managing some part of that process every day. Most of us deal with data that is viewed as somewhat public, related to our interactions with businesses and organizations. However we see some of this changing as employers start to gather more data on us through social media and other sources, beginning to use that data to make hiring decisions.

    It can get worse. As Shane Battier says in this article says, “big data is scary.”

    Most of us don’t aren’t hired for our physical performance. While our health can make a difference in how well we write code over time, the regular, subtle decisions of drinking juice or soda don’t affect our performance much on a daily basis. We could argue about that, but from the employer’s perspective, I’m not sure those things matter.

    Or do they? If the cost of employees rises over time, especially with regard to health care or sick time, should employers start to make decisions based on the data? Are we confident in the conclusions from data, which are really probabilities, not actualities? Would you want aspects of your life, perhaps outside of your health (think driving, finance, etc) to be part of the evaluation (or negotiation) process for your employment?

    Perhaps a lighter question, would you be comfortable managing and writing applications that work with employee data and try to analyze, perhaps even strongly recommend, changes in peoples’ live? I’m not sure I would, and I certainly hope we don’t get to the point where the data about our personal lives directly impacts the way we are managed.

    Steve Jones

     

    The Voice of the DBA Podcast

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

  • Prepping for Winter

    Living on a ranch in Colorado means that we have to prepare for winter in a way that we don’t worry about other seasons. Taking care of livestock when the weather gets cold (and snowy) presents challenges, and since it can be a matter of survival, we have to think about potential issues in advance and work to mitigate them before they occur. My return from the PASS Summit last weekend had me outside working on shed with my daughter to prep for this week’s winter storms.
    When working with computers, we don’t usually need to make special preparations for seasons, but we do need to be ready for difficult times. I was reminded of this with a post this week about 12 Things to Check to Prepare for Winter. These aren’t necessarily things you need to check as the temperatures drop, but they are things you might want to examine periodically in your environment.
    In many businesses, we are aware of the time periods when our systems get stressed, and great DBAs plan for those times. In one large organization I worked for, we knew that the end of quarter and end of year periods were very stressful and busy for many people in the company. As a result, any maintenance or preparation needed to occur at least a month early to ensure systems were at peak performance. In another job, at a power plant, the refueling process that occurred on a semi regular basis was the busiest time of year and we needed to ensure we were aware of when it was coming and double check everything before it was too late to do so.
    Good preparation is one of the keys to avoiding any of a DBA’s worst days. After all, if things go wrong for you at work, it’s unlikely The DBA Team will be available to save the day.
    Steve Jones

  • Use -eq in Powershell

    I was writing a quick script to work with files and I only wanted to process one file for each execution of a loop. I could have done this multiple ways, but I threw this together:

    $fileEntries = [IO.Directory]::GetFiles(“d:\placeholder”);
    $delete = 1;
    foreach($fileName in $fileEntries)
    {
    if ($delete = 1)
    {
    # do something
    $delete = 0;
    }
    }

    When I ran it, it kept deleting everything in the folder. That was really annoying, and it took me a few minutes to spot the problem. I kept thinking my variable wasn’t getting set to a new value, but it was. The problem was it kept getting reset.

    I first changed to this, but that produced a PoSh error. That’s because I’m working in PoSh and not C.

    $fileEntries = [IO.Directory]::GetFiles(“d:\placeholder”);
    $delete = 1;
    foreach($fileName in $fileEntries)
    {
    if ($delete == 1)
    {
    # do something
    $delete = 0;
    }
    }

    Eventually I remembered that I need to compare things with -eq, so I ended up with this, which worked perfectly.

    $fileEntries = [IO.Directory]::GetFiles(“d:\placeholder”);
    $delete = 1;
    foreach($fileName in $fileEntries)
    {
    if ($delete -eq 1)
    {
         # do something
    $delete = 0;
    }
    }