Database Upgrades
With the recent release of SQL Server 2012 you now have more opportunities with your installations. Now the questions of upgrades, support for earlier versions, multiple version support, reverse compatibility and much more emerge once again.
For those of you who have never experienced a release of a new version of SQL Server there is a lot to take into account. For example, what if you need to provision a new SQL Server instance? Do you use the new version, or use the previous release to keep you servers on the same version? How do you purchase a new license and still install a previous version?
What about your developers? What version are they using to develop software? For example, using SQL Server Developers edition has no limits on capabilities. Then if you try and use code written using the developers version there are features that will not work with SQL Server Standard. This issue is exacerbated when a new release comes out. Now not only do developers have the ability to code using features that may not be supported by your production version, but there even new features in the later release of the software.
A good example of new features that are of interest to developers would be Sequences. Sequences are the ability to have an automatic incrementing value, similar to an identity column, but not have that value associated with a single table. A sequence simply increments, and the value may be used in more than one table. What do you do when your developer uses sequences from SQL Server 2012 and you need to backward port that capability to a server not supporting Sequences?
Well, just wanted to get your grey cells firing on the event of a new SQL Server release. If I have succeeded then why not drop a note to btaylor@sswug.org with your thoughts.
Cheers,
Ben
SSWUGtv
With Stephen Wynkoop
Did you miss this episode of SSWUGtv with Paul Zikopoulus with IBM – talking about big data. We keep them ready for you when you are. Come on in and Watch the Show
$$SWYNK$$
Featured Article(s)
Avoid Becoming the Default Blame Acceptor
Often times, especially when you are a new DBA or an accidental DBA, you become the Default Blame Acceptor when it comes to performance issues or outages. I think this is even more prevalent when you are the only DBA in your shop and have limited other system administration experience. It’s not just that other sys admins see you as an easy target for blame; it’s that you may not know how to prove that your system is not the source of the performance degradation or outage. How do you, as a new DBA or accidental DBA avoid being the scapegoat? There are a few things you can do before an issue arises that will make it easier to pinpoint the source of your performance issues or outage.
Featured White Paper(s)
All-At-Once Operations
Written by Itzik Ben-Gan with SolidQ
SQL supports a concept called all-at-onc… (read more)