I’m really looking forward to getting a sneak peak as to what SQL Server 2011 will look like. 

I love this “not having to wait 5 years” for the next major version upgrade stuff

Microsoft SQL Server 2011 CTP1 Code Name Denali: Download Here

Enjoy!! (Follow me on Twitter: @ColinStasiuk )

Fellow SQL blogger (and Canadian) Aaron Bertrand broke the news on his blog here

Link to the Service Pack

Link to the bugs that are fixed in SQL Server 2008 SP2

Note (from Aaron re: SP2) : “The Service Pack only includes the fixes that were in SP1 CU 1 through 8.  So if you have already applied CU9 or CU10, I would hold off on deploying the service pack for now, especially if you are relying on any of the fixes in either of those CUs – because there is a chance that you will lose them.”

Now before you get all Service Pack crazy… make sure to slow down, review the changes, and apply the service pack using the same change process you do for any application release.  If you don’t have a change process defined this sounds like a great time to read:

http://benchmarkitconsulting.com/colin-stasiuk/2009/11/11/i-love-fights-that-i-cant-lose-separated-environments-and-security/

Thanks for posting the news Aaron… apparently I need to update where I look for this type of info cause my usual places still don’t have anything posted about it

Enjoy!!

So let’s first talk about a place… a savage place where there is ONLY PROD and developers have sysadmin access.

Scary huh?

Hopefully you don’t live in a place like this but if you do your first fight is a 2 round battle…

• Round 1: Get a DEV environment established
• Round 2: Remove all the security permissions from the developers in PROD

Now chances are if you had developers coding and making changes in PROD that you also don’t have any type of change management process… any type of process is going to seem like a pain in the butt for developers cause quite frankly once you’ve had the “keys to the kingdom” it’s hard to go back…. but you must.

Now the goal of this post is not to discuss the many different options for change management but if you were going to just leave it with a DEV and a PROD environment your change management process might look something like this:

1. Developer Scripts out their proposed changes in DEV
2. Developer Scripts out the PROD scripts of their changes
3. Developer or DBA restores a copy of the PROD database into DEV
4. Developer applies their change scripts from Step 1
5. Developer rolls back their change using the PROD scripts from step 2
6. Developer does a schema compare to make sure that their rollback scripts actually get them back to where PROD started
7. Developer lather, rinses, and repeats until they are satisfied with the change
8. Now the users can test in DEV(did anyone else get a cold shiver when I said that? lol)
9. The users sign off on the change
10. Developer creates an implementation plan, rollback plan, and a ticket to apply the changes.

So let’s go through and discuss why this is still not a world that I would want or feel comfortable in living in…

Step 1 and 2 are acceptable ( I wont go into a Source Control discussion here…. that’s a whole new blog post)

Step 3 is where the first problems start for me.  Restoring a copy of PROD over DEV could potentially have a negative impact if:

• Developer didn’t script out ALL their changes…. and now they’re gone
• You have other developers trying to work on their changes… which you’ve now just overwritten with a copy of PROD

Step 4 through 7 – As much as I love my developers… that is ALOT of trust that they are actually going to do these steps and not just skip to step 8 and have the users test.  Come to think of it… who knows if they’ve actually even restored a copy of PROD to DEV and reapplied their changes… they could of gone right to getting the users to test in DEV.

Step 10now becomes a run with an untested Implementation Plan, untested Rollback Plan, and at this point the only thing you’ve really done is make it so YOU (the DBA) are the one making the changes in PROD…. Great… so when things go horribly wrong I wonder who is going to get the call first. 

Trust me…. unless you’re Buck Woody and failure is as real as a unicorn… this is NOT where you want to be.

So now let’s talk a shiny happy place… or at least a place where you can go home at the end of the day and sleep at night.

@SQLCrotch …. this one is for you!

DEV -> UAT -> PROD

Ok let’s agree on some points right out of the gate:

• Developers have no access in PROD (other then read-only)
• Developers have the EXACT SAME permissions in UAT that they do in PROD… this is going to be a real sticking point but what you don’t want is developers promoting code to UAT and then when it doesn’t work… trying to fix it in UAT
• Developers have Full Access in DEV

Now with that understanding in place…. let’s look at how change management could go and why this is my happy place.

Step 1 – Developer develop in DEV… sounds easy enough but if you can get here from where you were (developers developing in PROD) then this is a HUGE win already.  Developers can request a restore or at least a schema refresh depending on whether or not they are comfortable that DEV is an accurate representation of what is in PROD

Step 2 – Developer creates an implementation plan

Step 3 – Developer creates a rollback plan

Step 4 – Developer submits a ticket to promote their code changes into UAT

Step 5 – DBA (or Release Manager depending on the size of your company) restores UAT with a copy of PROD

Step 6- DBA follows the Implementation Plan and releases the code into UAT

• If the release fails then it goes back to the developer at Step 1… If the release is successful…

Step 8 – DBA runs the Rollback Plan in UAT

• But it was successful??? Why do this?  There is nothing worse then having the false sense of security that just because you have a rollback plan that it will actually get you BACK to where you were.  Running the rollback plan will allow you to compare to PRODand make sure that you’re back to square one.

Step 9 – DBA runs a schema compare between UAT and PROD to ensure that the rollback steps will actually return the environment to where it was.

• If the Schema Compare shows differences after running the rollback then it goes back to the developer at Step 1… If the release is successful…

Step 10- DBA follows the Implementation Plan and releases the code into UAT

Step 11 – User tests in UAT

• Now if the user does NOT accept the changes… You don’t keep band-aiding UAT until the developer gets it right.  If the user fails the UAT test it goes ALL the way back to step 1. Now if you want to give SOME flexibility (due to timelines, etc) here you can.. and allow the developer to give you new scripts to apply, etc… but at the end of the day before you go to the next step you HAVE to go back to Step 1 to ensure a clean UAT run.

Step 12 – UAT PASSED… then you schedule the release to go into PROD

Step 13 – Release into PRODusing the exact same implimentation plan

Feel all warm and fuzzy yet?

Let’s discuss what we’ve gained…

• Developers develop in DEV – fantastic
• The Implimentation Plan is tested in UAT – fantastic
• The Rollback Plan is tested in UAT – fantastic
• The separation of duties adds a level of auditability and process that auditors will WAY MORE comfortable with – fantastic
• The user does not have to test in an ever changing DEV environment or in PROD – fantastic
• The change (and the process) that is being put into PROD has been tested one or many times to minimize downtime or potential problems – fantastic

Now this was a braindump of information for me and I’ll probably end up writing a multipart article on the value and process of established DEV, UAT, and PROD environments but hopefully until that time comes this will help some win their battles on why it is SO important to have separated environment and security.

At the end of the day this is a great fight to be in… cause you should NEVER lose

Enjoy!!

If you haven’t played around with SQL Server 2008′s new Central Management Server please take some time to read this great article by Brent Ozar about it:

SQL Server 2008′s new Central Management Server – Brent Ozar

OK so now after reading that article you should be “in the know” about the new CMS.  Some of the groupings I have in my CMS are called DEV, UAT, and PROD.  So if I highlight the PROD group and select “New Query” the first thing I see at the bottom of my Management Studio Window is:

So there is my first “sniff test” that all my SQL Server Instances in my PROD group are alive and well… but what about the SQL Server Agent service… is it running as well?

Copy the code below into your Management Studio query window (UPDATED to include @@SERVERNAME):

IF EXISTS (  SELECT 1 

           FROM MASTER.dbo.sysprocesses 

           WHERE program_name = N'SQLAgent - Generic Refresher')

BEGIN

   SELECT @@SERVERNAME AS 'InstanceName', 0 AS 'SQLServerAgentRunning'

END



Your result set should have all the instance names in your PROD CMS Group along with a True/False column as to whether or not the SQL Server Agent Service is up and running.

In utilizing a Central Management Server and running this script you now have a good indication as to whether or not you can connect to all your SQL Servers as well as the status of the SQL Server Agent Service on each of those instances.  Obviously we’re just scratching the surface of the great things you can do with CMS but if you haven’t played around with this new feature this should give you a good place to build from.

Enjoy!!

First off for the love of all things good and pure in the world please make use of the Upgrade Advisor.  This has been around since SQL Server 2005 and it has proven time and time again to be an amazingly helpful tool when doing an upgrade.  On a side note about Upgrade Advisor… don’t just run it against your instance… take the time to run TSQL Replay traces (for an appropriate sample size of normal activity) and run those through the upgrade advisor as well… this will capture the commands that are run against the database that do not exist in an object.

Next… use the community… there are ALOT of keeners out there that have written some great articles on things to watch out for and have documented their upgrade experiences so if this is your first upgrade (or if you’re an upgrade pro) take some time, read what others have written cause it could spark a thought or idea on how to make your upgrade experience that much smoother.

If you’re a speed reader and/or have a tonne of time to do an upgrade there is a Microsoft published SQL Server 2008 Upgrade Technical Reference Guide  that is about 500 pages of upgrady goodness.

Try to install and setup all the “pre-setup” stuff before doing your upgrade.  Things like cumulative updates, .net framework, etc can all be done before hand so that you minimize the amount of time (and potential problems) when actually installing/upgrading SQL Server 2008

If you’re doing an inplace upgrade make sure that you know what version and service pack level of SQL Server can be upgraded to SQL Server 2008.   Take a peek at this and make sure that you’re on a supported path for upgrade.  If you’re not then your first priority should be getting your current environment onto a supported version before considering an upgrade to SQL Server 2008.

Anyways like I said… not a comprehensive list but more of a warning and a “sneak peek” into some of the things you should look out for and tasks you should perform when thinking about taking the plunge into SQL Server 2008.  Microsoft has done a good job at providing tools and documentation for upgrading to SQL Server 2008, make use of them and you should find your upgrade experience to be a smooth less painful experience.

Enjoy!!!

• 51% of the people who voted indicated that they currently have no SQL Server 2008 instances running in production.
• 37% indicated that they have a quarter or less of their production SQL Server instances running on SQL Server 2008.

Combined that’s 88% that either have no instances or less than a quarter of their production instances on SQL Server 2008.

So what are some of the reasons for this?

•  The stigma of Microsoft products and NEVER installing them in production until Service Pack 1 is released?
•  The cost associated with an upgrade project? 
•  Too many 3rd party applications still don’t support SQL Server 2008?
•  Too many Databases that are still on SQL Server 2000?
•  The new features/functionality in SQL Server 2008 doesn’t warrant an upgrade at this time?

I’ve seen (and been involved in) arguements on most of these reasons in the environments I’ve been exposed to and support.  Maybe it’s because I have been trying to do as much with SQL Server 2008 during all the CTP releases, RC0, and RTM that I feel more comfortable and confident with SQL Server 2008 than when SQL Server 2005 first came out. 

Steve Jones posted an article in March of 2008 (almost a year ago) about the adoption rate of SQL Server 2005.  The poll that he ran was much more indepth than my “mini-snapshot” view of the world but the two questions that I want to draw attention to are:

1)  Which SQL Server platforms are you running?
 v4.2 – 0%
 v6/6.5 – 1% (9/610)
 v7 – 12% (73/610)
 v2000 – 92% (563/610)
 v2005 – 59% (357/610)

2)  Will you upgrade to SQL Server 2008 within a year of its release?
 Yes – 32% (198/610)
 No – 68% (416/610)
So this was March of 2008.  Almost 3 years after SQL Server 2005 RTM was released only 59% of the people polled indicated that they have SOME level of SQL Server 2005 adoption and only 32% of people polled indicated that they plan on upgrading to SQL Server 2008 within the first year of it’s release.  With SQL Server (planning on) releasing new versions every 2 years and support ending on versions that are more than a version old something has to give.  Will adoption of the new versions happen sooner? Will companies run on non-supported versions of SQL Server?

I don’t want to become a “poll-whore” so please feel free to comment as to your experiences and reasoning for upgrading or not upgrading to SQL Server 2008 as well as if you think in the future that the adoption of a new version will happen quicker than what we’ve seen with SQL 2005 and SQL 2008 to date.

Enjoy!!

http://support.microsoft.com/kb/959195/en-us

and with the usual disclaimer of making sure to test in your dev and UAT enviornments before applying to production

Happy Holidays!

SQL Server 2005 SP3 is now available for download and includes the following updates:

• Roll-up of Quick Fix Engineering (QFE) updates completed since SQL Server 2005 SP2, as well as fixes to critical issues reported through the SQL Server community. Per revised servicing strategy for SQL Server releases, SP3 does not introduce major new features.
• Feature Pack for SQL Server 2005 SP3 has been refreshed along with this release.
• SP3 can be used to upgrade from any previous instance of SQL Server 2005
• For customers who will be upgrading from SQL Server 2005 SP2 CU#10 or SP2 CU#11, you will have to install the latest CU on SP3 after upgrading to SP3 release to get all the fixes.
• SP3 applies to:
  • SQL Server 2005 Enterprise Edition
  • SQL Server 2005 Enterprise Evaluation Edition
  • SQL Server 2005 Standard Edition
  • SQL Server 2005 Workgroup Edition
  • SQL Server 2005 Developer Edition

Note: Service Pack 3 includes SP2 CU 1 to 9,  therefore If you are upgrading from SQL Server 2005 SP2 Cumulative Update 10 or from SQL Server 2005 SP2Cumulative Update 11, you must apply a post-SP3 cumulative update after you upgrade to SP3 to obtain all the fixes.

As always make sure to test the release in your development environments before applying to production

http://www.microsoft.com/downloads/thankyou.aspx?familyId=66d3e6f5-6902-4fdd-af75-9975aea5bea7&displayLang=en

This looks like the all encompassing upgrade document for SQL Server 2008.  Major points include:

• Preparing to Upgrade
• Developing an Upgrade Plan
• Post Upgrade Tasks
• Feature Changes

Pretty crazy document but I can see it being a great resource when trying to put together checklists and plans for upgrading.

Happy Reading!!

Anyways… with an planned release of the first half of 2010.  Quentin Clark, general manager of Microsoft’s SQL Server group, said Kilimanjaro is not the next version of SQL Server. 

In an interview he was quoted: “Kilimanjaro is really an add-on kind of release. It’s not really a major release, it’s not a new database,” Clark said. “We will do bug fixes and other minor stuff but it’s not a major release of the database engine.”

So I guess Microsoft is trying to make good on it’s promise to release a new version of SQL Server every 2 years… it will be interesting to see the trend in the industy and how quickly companies adopt the new releases.  To this point Microsoft will only “offically” support the current version and 1 previous version (Currently SQL 2008 and SQL 2005).  Smaller 3rd party vendors are going to a tough time keeping up as well.  I’ve seen a tonne of databases that are finally on SQL 2005 but running in backwards compatibility mode because they cannot fully migrate to SQL 2005 without some major redevelopment.

Fun fun fun… but hey… I’ll take this over having to wait 5+ years for drastic improvements