Voice of the DBA

Tag: sql server

  • Consolidating Again and Again and Again

    This editorial was originally published on November 12, 2009. It is being re-run as Steve is on holiday. 

    In reading about virtualization, one of the main things that drives its acceptance is cost. It’s the reduction in actual physical resources needed to run multiple servers that makes it popular with many IT departments. It doesn’t help with administrative costs, at least not the costs of the system administrators because you still have the same number of servers to manage. There are just less physical servers to buy, less power needed, less cooling, and probably other savings if you virtualize.

    Virtualization is really a one-time cost savings. Once you’ve virtualized a server, you can’t do I again, so there are no repeat savings from this event. Is consolidation the same? After all, the main driving force for that process is also cost, and once you’ve consolidated a server you can’t do it again.

    Or can you?

    There’s a great white paper by Allan Hirt that talks about the process of consolidation, and I’d urge you to read it before beginning a consolidation project. However I don’t know that consolidation is, or should be, a large, one-time project.

    If I consolidate 3 or 5 SQL Server instances onto one machine, I have a choice of how I can do this. It can be by moving databases to a new instance, having multiple instances, or even using virtual machines. But is that the end? It’s not because I can add more databases later, or I could even move a database that is receiving a heavy load back to its own server and find other instances to consolidate onto this one.

    Consolidation, unlike  virtualization ought to be something you periodically examine in your environment. On a regular basis review your baseline for all instances and see if it makes sense to perform some consolidation. Server sprawl can creep up on you, but with a little management and the multi-instance nature of SQL Server, you can keep it under control.

    And if you don’t have a baseline to examine, consider setting one up.

    Steve Jones

  • How Often Does Production Drift?

    One of the new products that Red Gate Software is working on is SQL Lighthouse, which is designed to track and alert you on “database drift“, which are the changes in your schema. I hadn’t really heard the concept in the past, though I’ve found there are a few people using the term to describe the changes being made to production that aren’t inline with the development project that created (and updates) the database.

    Vendors that sell products backed by a SQL Server database, like Microsoft Dynamics, often consider database drift to be a violation of their EULA. When a customer changes the database, even by just adding indexes, it causes them support costs, though arguably those costs are lower than if no indexes were ever added by enterprising DBAs.

    However this also happens in databases built by companies. It seems there’s no shortage of “quick fixes” in production, in addition to the “improvements” that DBAs and others seem to make to their live databases in order to solve some short term issue. I know there’s a need for this, and even seen recommendations to ensure production differs from development schemas. However I haven’t had many issues with this in the past and I’ve tried to prevent any drift.

    Maybe because I’m a controlling DBA, or maybe because I’ve been lucky. In either case, while I’ve had to implement hot fixes and changes in production, it’s been rare. Most of the time I’ve been able to backfill these changes in development (and test) environments, or delay the fix until it could be tested.

    However I’m sure there’s a need for a way to manage drift, and detect it as the number of databases you manage grows, so I’m excited by SQL Lighthouse and hope it helps DBAs avoid those late night phone calls by being aware of what’s changing in their systems.

    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.

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

  • 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