Voice of the DBA

Author: way0utwest

  • Performance Tuning Through Panic

    We’ve all been there at one time or another: panicked by a performance issue. I once upgraded a FoxPro for DOS application to a VFP front end with a SQL Server back end. We had a much more powerful server, generations ahead of the previous file server share. When the first users logged in and searches ran slower, I was in a panic. My team worried about the size of our inventory data in memory and quickly upgraded our 4GB, 1996-era server to 8GB of RAM, hoping for improvement. We also hurriedly split out queries and separated some data in an effort at quick tuning. It wasn’t much above a knee-jerk reaction, but we had users, and management, yelling at us on an hourly basis.

    I’m sure many of you have had other performance problems that resulted in some panic during your career. I’ve had more since then, and will probably have more in the future. Many of us do, and many of us perform knee-jerk performance tuning. However you can, and should, avoid tuning in a panic, as pointed out by Paul Randal. Doing so usually doesn’t fix the problem, and when it reoccurs, it’s more embarrassing with people less likely to listen to your next great idea.

    Tuning a system is a science, but it’s a complex science. Without experience, without having knowledge about all the complex interactions, and a deep understanding of how all the parts fit together, it often looks like a hopeless task. Who can keep all that information in their head and relate all the various components of the application? The network, the OS, the SAN, clients, all can cause problems that appear to be in the database.  As Paul points out, failing to understand the actual root cause can lead you to make changes that will have no effect on the actual underlying issue. You’ll often realize this when the problem re-occurs in a short time.

    I think one of the best reason to hire consultants is that they see so many problems that they can recognize patterns in performance that many of us don’t see. What they do appears to be an art because they can seemingly understand what information is relevant, and what isn’t. They walk down a list of potential issues, gathering evidence in a logical way, but one that can appear random to someone with much less knowledge and experience.

    All of us can learn more, we can read about problems others have had and learn how they solved the issue. However we often face the same reaction that many consultants do: no one wants to implement the advice. Until clients and vendor are willing to tune their code, many problems will only be masked by hardware.

    For a time. Then they’ll reappear.

    Steve Jones

     

  • Top Talent Leaves

    Derek Jeter will likely play his entire career with the New York Yankees. LeBron James has already left one team, and might leave another soon. Both are Hall of Fame players that have had extreme success in their chosen professions. They are recognized as some of the most talented players in their sports. Why did one stay and one leave? Probably for a variety of reasons, but it seems more and more that organizations are realizing there is some value in the retention of their players and are trying to find ways to improve their success at retention.

    In the business world outside of sports, we have much more freedom to change employers whenever we want. Most of us are glad we have that choice. Sometimes we move on when we don’t want to, but in the majority of cases I think technology workers leave companies because they aren’t happy about something.

    There was an article about why the top talent leaves a company and I think it presents a number of issues that many employees experience within their own organizations. People aren’t engaged, respected, valued, challenged, and more. In short, they really don’t like their jobs. Many of the issues are often easy to fix, but only if you could fix two of the major items mentioned (#7 and #10). Those are leadership issues, often systemic ones that occur when upper management doesn’t care about culture or doesn’t make an effort to hire and train good managers.

    I don’t know if I’d prefer to see people in technology working only a few jobs during their careers, spending decades at each, or if we are better workers with the exposure to differing environments and businesses. All I know is that I am glad that I’ve had the ability to leave bad jobs in the past, usually because of bad managers.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Virtual Lab – Design and Setup

    This is part of a series where I set up a virtual lab for testing and misc work. The other parts in the series are here: Building a Virtual Lab with Hyper-V.

    I haven’t had a good lab set up since I moved from VMWare to Hyper-V on my systems. Since then I’ve had a number of random VMs set up, but none connected in any meaningful way as a domain. They were all standalones, but that needs to change.

    I wanted to do some additional testing with a few Windows and SQL features that needed a domain. So I decided to set one up with Hyper-V.

    I googled around and found a few references:

    I decided to try to do some of this myself, using these as guides, but also incorporating some of my new Powershell knowledge along the way. I won’t claim this is the best way to build a virtual lab, but this is the way I did it by cobbling together various piece of information.

    With that in mind, here’s what I’m looking to do. I want to create a domain with a few servers and a client for testing. I plan on making this setup on a separate network, using the 10.10.10.x address space as I don’t expect to run into networks with that one at home, or work.

    The machines I’m looking for are as follows. The role, OS, and then names are listed below:

    • DC (WS2K12 R2 Core) – DenverDC
    • SQL Server instances (WS2K12 R2 Core and Standard) – Broncos, Nuggets, and Rockies
    • File Server (WS2K12 R2 Standard) – Avalanche
    • Client (Win 8) – Keystone

    I’ll be running through the process and trying to document this for myself, and others.

    First Steps

    The first steps here are easy. I have Hyper-V setup, but if you don’t, it’s an easy confg item you can see at the beginning of this article.

    Next, download software. I didn’t have Windows Server on this machine, so I accessed MSDN and downloaded Windows Server 2012 R2. I have an MSDN license, so I get a few licenses. As this was downloading, I made not of the product keys.

    I’ve had a space on my machine setup. Since I used to use VMWare and Hyper-V, I have a space on my spare drive where I separate Hyper-V and VMWare. Inside the Hyper-V folder are my VMs for quick copying to my external drives and laptop as backups. In this case, I’m setting up a “WS2K12 Lab” folder.

    virtlab_g

    The Parent

    This is a standard setup I’ve seen in all the tutorials. Create a VM, create a new hard disk (I used defaults), install Windows Server, and run “sysprep” on the VM. I did this with both Core and Standard Server. This gave me two hard disks that had images of the server systems on them.

    virtlab_h

    I first set these disks to “read only” and then deleted the parent VMs. This gets me the base systems on which I will build things. I’ll deal with the Win 8 client later.

    That’s all I’m talking about here. I’ll move into the rest of the steps in future posts.

  • The Cloud

    I like the cloud. It’s very handy for a lot of the things I do. I like having backups restored for my iPhone upgrade. I appreciate having my documents synced through Evernote, Dropbox, and OneDrive (formerly SkyDrive) automatically moving to new machines. These services are incredibly convenient and handy. I expect that my mail will be accessible from multiple machines and my blog posts can be created, edited, and published from anywhere. Many of us work in a similar fashion, using the cloud as a service construct in much of our lives. In fact, many of us expect our own knowledge will be supplemented by the cloud. We use Google to search, getting us syntax,  solutions, or ideas from sources that we expect to just be there.

    Someone was talking to me about their concerns with the cloud recently. This person thought the cloud would be a fad that passes quickly and businesses will get back to owning, hosting, and managing their servers from the bare metal up to the network connection. I disagreed, and not because I use the cloud personally.

    I remember setting up a web server in 1996 for a company. I remember installing an email server in 1999. I would never do either of those things again for my own company, and I wouldn’t expect it from most companies. These days we’ve learned that email can easily be handled by a third party and more and more companies are using email services instead of managing their own systems. Web servers are mostly a shared service that we rent from any number of other companies, sometimes even stitching together a presence across multiple providers. Even many companies that want to manage their own host operating system are turning to third party companies to manage the hardware and networking. More and more we accept renting the things we need from others.

    We’ll get there with databases as well. Not all databases, but more and more of them will be hosted at third party companies. Whether this is in some type of VM environment or a service that hosts data, it will still be hosted at a third party. We will have concerns and we will have reasons to not do this, but I think for more and more of our data, we won’t care.

    Companies have lots of systems in place. They have legacy investments in infrastructure and facilities. In those cases, it’s hard to justify the cost of cloud computing. However as we grow into new areas, or with new companies, we’ll have to re-evaluate whether it is a good idea to continue to make those investments. As the management of software grows to allow the quick scale up and down of assets, I think we’ll be much more likely to consider moving applications into the cloud than ever before.

    We’ll never be 100% in the cloud, or out of it, in the future, but increasingly, we’ll be partners with the cloud.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.