Have you ever thought about why you procrastinate about some tasks and run enthusiastically to do others? If you are like most people, you tend to procrastinate when the task at hand is something that may not go so smoothly.
Running SQL patches and upgrades is not anyone’s favorite IT task. But for some businesses, procrastinating about SQL Server patches and upgrades could lead to significant problems. So how can you know if it is time to take the challenge?
Let’s start by putting things in order. First, there are significant differences between patches and upgrades.
SQL Patches
There are two types of patches – service packs and service patches. Generally speaking, Microsoft discourages applying the latter, unless it addresses a specific problem that is affecting your system. On the other hand, installing service packs, is highly recommended. A system that is not on a current service pack level is considered a neglected system. A good illustration would be to liken it to how you maintain your car. The service pack is like a car tune-up, something that a good owner does regularly to keep the car running as well as it can. The service patch can be likened to an emergency service notification like a part recall from the car manufacturer. Such service announcements from car manufacturers explain that certain systems can be affected by a defective part and instruct the owner to take the car to a mechanic to determine if the vehicle has been impacted.
SQL Upgrades
Upgrades are much more complex than patches. An upgrade may include solutions to bugs or improvements to major features. It also carries a greater risk because problems can spring up for various reasons – anything from driver issues to database compatibility level issues , or a syntax that is no longer supported. No wonder that DBAs can become overwhelmed when it comes to upgrading.
The decision to install patches and/or upgrade your system is an economic decision that should take into account both Risk management and ROI.
Ask yourself if your organization can tolerate downtime? And if so, for how long? Can the organization tolerate issues that might arise from upgrades in a production environment? Is there a cluster technology in place that can assure minimal down time? If not, plan for and expect a longer outage.
New Bells and Whistles vs. Stability
The main reason to upgrade is typically to be able to take advantage of new features. Microsoft packs each new release with enough new features to peak your curiosity and to make you yearn to try them out. But even so, you can still find systems today using SQL server 2000. It all depends on the business’ needs.
A general good rule of thumb to follow is to never be more than one release behind the current SQL version. If you are running SQL 2005 now – you are not in good shape. SQL 2008? A bit better. Got SQL 2012 installed – you are the king of ensuring your organization is running as smooth and efficient as possible. Upgrading SQL server obviously doesn’t have to come at the expense of stability. Careful planning can easily eliminate a lot of pain that is often attributed to this process. Stay tuned for some tips on how to make your next upgrade smoother and safer.
