August 14, 2012 at 1:12 pm
Presently I have 2008R2 + Sharepoint 2010 on the same server hosting up BI.
Have a PowerPivot instance plus a default instance. Same for SSAS.
Have SSRS installed in Sharepoint Integrated mode
Now I want to move this environment to 2012.
The plan is to move Sharepoint and its databases off of the BI Server and give it its own server, leave SSRS, SSAS, SSIS, and SQL on the new DW server.
I'm debating one of two scenarios.
1. Install 2008 R2 on the new boxes, get them up and running with Sharepoint, etc, then do an in-place upgrade to 2012
2. Install 2012 and try to migrate everything over to it.
Which would folks recommend? If it was just a SQL instance, and not all this Sharepoint stuff, I'd just install 2012, and restore backups to it, but because of the Sharepoint integration and tools like PowerView, PowerPivot, etc, I'm not sure which way to go.
August 15, 2012 at 7:12 am
Normally, I completely prefer a side-by-side upgrade. Get 2012 on a different server then move things to it. I find it to be a much safer and more consistent operation. But with Sharepoint... I'd probably do the in-place upgrade. Backups and restores on Sharepoint are frankly a royal pain in the tucas. I've always dreaded having to go into a DR scenario with Sharepoint.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
August 15, 2012 at 11:22 am
I can't speak to the Sharepoint part, since I don't admin that, but on the rest of it, side-by-side is going to be easier to fail-back from, but takes a bit more work.
Plan for the extra work. You'll need to make sure server-wide settings are either parallel, or changes are tested properly. Things like parallelism cost settings, default collations, and so on. Make sure tempdb has the same set-up from current to new. Same for the model database. Migrating data from msdb over depends on what you plan to do with that data (like backup history, any SSIS packages that are stored there, and so on). That's all extra work compared to an in-place upgrade, but the ability to roll it back is much more certain if something goes wrong, compared to an in-place upgrade.
I've done quite a few side-by-side upgrades from various versions of SQL Server to various other versions. I've done a few in-place. I prefer the side-by-side.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply