Tag: Friday Poll

  • How Virtualized?

    I went to a talk recently where I saw this statistic: “50% of all workloads were virtualized in 2009. That number is 72% today.”

    That’s a really big number, at least in my mind. That implies the vast majority of all servers, file, print, database, email, etc. are virtualized. Inside of companies that have their own data centers and machines, they must be heavily virtualized. I’m sure that all those instances in the “cloud” also count, but still, 72%? That’s big.

    However I’m sure that’s skewed towards those machines that don’t require a lot of resources, like file and print servers, DNS hosts, etc. This week, I thought I’d see what the percentage is inside of your organization.

    What percentage of your SQL Servers are virtualized?

    Give us numbers of physical v virtual if you can. I’d combine all instances, from development to test to production, not worrying about size or workload. If you have a single guest on a host, using almost all the resources, that’s a virtual server.

    My suspicion is that the percentage of SQL Servers is much lower than that of other workloads, but I’m curious. With the low overhead of modern hypervisors, and the free (or low) cost, it makes sense to virtualize servers. If for no other reason than to remove any weird hardware dependencies for DR purposes. However I’m sure that there are large workloads that require more resources than the current hypervisors can expose, at least for some database instances, and those need to remain on physical machines, but my guess is more often than not, it’s the human concerns or lack of confidence that prevents virtualization.

    Let us know this week how your organization is doing in the trend towards virtual servers.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Common Mistakes

    At times I am rather dismayed by the quality of code I see written today. I’m not sure it’s worse than the poor code compiled early in my career, but there are so many more people writing code in our industry that it seems there is more and more poorly written code.

    We suffer from the chef problem. As more companies look to become software companies, they need to hire more software people. To meet the staffing demand, more and more marginally skilled people will be chosen, and software quality goes down.

    Part of what we do here is to try and educate the SQL Server professionals on how to become better at their jobs. That’s really the core mission that started SQLServerCentral and continues today thanks to the belief in that mission by Red Gate Software. As we look to do that, we want to bring to light the things that aren’t good ideas and can cause problems.

    What common mistakes do you see T-SQL developers making?

    The question this week is based on a post by the talented Doug Lane, who wrote about the top three mistakes T-SQL developers make. Doug has a good list, and I’d urge you to read it, along with some sage advice from Brad McGeHee. However I’m sure many of you see different common issues in your own work.

    What things need to be fixed later? What code regularly causes performance issues? The more specific problems that you can share, along with their solutions, the more you might help another developer build better code in the future.

    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.

  • The Express Choice

    There are a number of editions of SQL Server, each of which has different capabilities, features, and restrictions. Over the years, the mix has changed, and it can get confusing for customers trying to decide what to purchase and use. Fortunately things seem to have become simpler the last few years, but you still have to make a few choices.

    The Express Edition has the most restrictions, including a database size restriction, but in many ways, it’s a very capable database server. It’s the evolution of the “desktop database”, MSDE, that was designed to take the place of Access for desktop software that needed a database.

    Recently I ran across a discussion on using Express in production, and I was surprised that many people didn’t think it was  a version capable of acting as a production server. It’s the same code base as the other versions of SQL Server, with more restrictions. This week, I wanted to see how most of you feel.

    Would you use Express Edition for a production database?

    I would. In fact, given the way licensing costs have soared for SQL Server, I’d be tempted to use Express in many places, especially for departmental sized applications. I wouldn’t care whether they were web based or client/server. As long as the database would remain below the 10GB limit and the 1GB RAM limitation didn’t kill performance, I think Express is a fine choice.

    Of course, outgrowing Express can be quite expensive and a shock for someone using it, but if you need a more powerful server, you need one. I just prefer to defer that cost if I can.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Where Do You End Up as a DBA?

    I saw this question pop up on the forums: Where do senior DBAs land finally? It’s an interesting question, and for people that are searching for the next challenge, I would guess that they’re interested in an answer. Here’s what I think:

    There is no landing, senior or not. There are only stops along the path of your career.

    As you gain experience, and talent, you will have both more, and fewer, choices. If you expect to constantly gain salary, you will find that harder and harder over time. That’s the nature of any business. The best artist/athlete/programmer/whatever will reach a point where they can’t necessarily raise the market price for their services. The more you want to get paid, the fewer people that will afford you.

    If you look at money as a measure, you will be disappointed at some time. Not that money isn’t important, but I recommend you keep things in perspective. Money is important, but as you earn more, I would hope that value would start to diminish.

    At the same time, the challenges and opportunities at a job may matter to you. If you always want a harder problem to solve, a more complex system to manage, you’ll find the same limitations at some point. Fewer and fewer extremely complex (or very large) databases exist. You have less choice if this is important to you.

    Some people are restless and want to look for new opportunities on a regular basis, no matter what their situation. If that’s you, I would think you should consider consulting, either with a company or by yourself. Which you choose probably depends on your tolerance for the non-technical parts of a business, as your own consulting business will have lots of non-technical work to manage.

    Some people value stability, and if you value that highly, you’ll sacrifice some challenge and excitement. However stability is very relative these days, and you need to keep that in mind. You always work for yourself and no job is guaranteed for the rest of your career.

    I have moved back and forth from consulting to FTE, and like both, but I tend to value the co-workers I have and environment more than other things. I have to enjoy going to work. I find the DBA/developer job to be pretty much the same in most places, but my co-workers make the difference.

    It’s good to investigate and consider other options, but don’t think of this as the game of Life, with a few choices and an ending point. There are many paths, many directions to go. Some routes may cross, but many do not. You choose the one that matters to you, but don’t be afraid to cross to another one if you find yourself wanting.

    Where do you think Senior DBAs end up?

    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. feed