Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12345»»»

How Long Before You Upgrade? Expand / Collapse
Author
Message
Posted Friday, April 11, 2014 5:48 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Sunday, November 9, 2014 7:21 AM
Points: 23, Visits: 73
We have been running on SQL2008 Standard edition (not R2) and recently upgraded our hardware to a relatively massive machine with two 12 core processors and 256GB of memory. Although we planned to upgrade to SQL2012 soon, we are seriously considering pushing it off until extended maintenance expires on SQL2008.

As it turns out, Microsoft didn't add a cap on memory and processor usage for Standard edition until SQL2008 R2. So if we want to upgrade and use all of the resources we currently have available, it will be a considerable cost increase to license 24 cores on Enterprise edition. That said, the server is definitely overpowered at the moment. We could upgrade and stick with Standard, but it would still be a pretty big increase in cost to license up to the 16 core cap on Standard and we would be limited to 64 GB of memory.

Up until now, the only thing delaying our upgrades was the time to schedule the work, but I'm really having a hard time justifying the extra cost based on the features that upgrading makes available this time.

--Andy


Post #1560836
Posted Friday, April 11, 2014 6:02 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, June 5, 2014 12:18 PM
Points: 44, Visits: 467
Currently running 2012 , will upgrade to 2014 this year or next.
Post #1560841
Posted Friday, April 11, 2014 6:12 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, November 10, 2014 7:17 AM
Points: 295, Visits: 284
I manage the Business Intelligence server for my company and we just started planning our upgrade to 2014. I expect that all our BI servers except the SharePoint/SSRS stuff will be upgraded by the end of August.

Again, we're very early in the planning stages but the rough outline goes something like this:
1. Developers upgrade to Visual Studio 2013 and SSDT-BI
2. Upgrade the SSIS servers
3. Upgrade the SSAS servers
4. Upgrade the Data Engine servers

We did an in-place upgrade of 2008 R2 to 2012 when it came out and didn't have a bit of trouble. This time we're doing side-by-side and will switch out Production servers over the weekend.

To be honest, we probably wouldn't be upgrading so quickly if it weren't for the In Memory Columnstore indexes. Nothing has really changed in any of the major SQL Server features except for the data engine but we have seen some fantastic results with the columnstores. We didn't get much traction with them in 2012 because of the extra work that needed to be done with the SSIS packages to add the DROP/CREATE steps wherever we needed them. Now it's a no-brainer.


Bryant E. Byrd, BSSE MCDBA MCAD
Business Intelligence Administrator
MSBI Administration Blog
Post #1560843
Posted Friday, April 11, 2014 6:20 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Today @ 4:20 AM
Points: 215, Visits: 877
I'd be more interested in the other half of the question. How will you prepare for your upgrade?

Places I've seen have no testing methodology for their LOB applications and basically "start it up, and if things appear to run, stick it in development, and if it doesn't fall over, give it to your smallest client, and if they don't die, deploy it to the rest."

I think you are MEANT to do a full backup, begin a trace to record a day of work, take another backup, and then use replays to compare the end results. Right? But, not many people appear to have gone into depth with examples of how to do the "best practice"... so few do it.
Post #1560851
Posted Friday, April 11, 2014 6:31 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Sunday, November 9, 2014 7:21 AM
Points: 23, Visits: 73
We do the trace-replay method of testing. However, you lose the original concurrency aspect. I think it would also be worthwhile to run some kind of load-test with your maximum concurrent users if possible.
Post #1560861
Posted Friday, April 11, 2014 6:34 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, November 10, 2014 7:17 AM
Points: 295, Visits: 284
Cody K (4/11/2014)
I think you are MEANT to do a full backup, begin a trace to record a day of work, take another backup, and then use replays to compare the end results. Right? But, not many people appear to have gone into depth with examples of how to do the "best practice"... so few do it.


You're spot on Cody. Here are some of the things that I did when I performed the upgrade to 2012 and plan to do it all again for 2014. It's really not that hard. Just a little time consuming.


  • Trace replays against Data Engine and Analysis Services databases. I collect queries for a couple weeks and play them back as fast as the new servers can handle them. A little load testing while you're at it never hurts.

  • Process all the Analysis Services databases. It's real easy to write a PowerShell script to loop through all the DBs and process them. I'll try to remember to post my script when I find it (or rewrite it ).

  • Run a good cross-section of the SSIS packages. Really, you should run them all if you can. We have very fine-grained packages and last time I counted there were over 1,700 of them. I work with the developers to identify a batch that exercises all the special cases and custom components we use.

  • Reporting Services is probably more of a manual process. Our SSRS implementation is using SharePoint Integrated Mode so our SP team manages that and I don't have to get involved too much there.



Bryant E. Byrd, BSSE MCDBA MCAD
Business Intelligence Administrator
MSBI Administration Blog
Post #1560865
Posted Friday, April 11, 2014 6:51 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Wednesday, November 19, 2014 9:47 AM
Points: 96, Visits: 483
I work for a health system (2 hospitals) and I support over 20 servers with SQL 2000 on them. Of course I support over 200 servers........
Post #1560872
Posted Friday, April 11, 2014 7:17 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: 2 days ago @ 12:57 PM
Points: 1,314, Visits: 2,897
Yep. I am in this boat. We have 7 dbs still in SQL 2000, 5 of which will be moved to 2008R2 next week. We still have a small amount in SQL2005 and a few of these we have upgrade plans for this year and a few more next year. We don't have SQL2012 yet here at all except for a sandbox play server. As far as home grown dbs why should we upgrade to SQL2012 now, might as well wait till SP1 comes out for SQL2014... as far as purchase apps our hands are tied to what is certified and when we decide to have a project, have the $$ and manhours to upgrade. We have over 300 prod dbs here now with 500 more in the next 2 years. As I have told my boss, if we did absolutely nothing except upgrade dbs to SQL2014 beginning today we would never have them all upgrade by the time the next version comes out. I thought Microsoft said each new version would be 3 years apart.... From my notes SQL2012 came out in May 2012, and SQL2014 came out in April.... that isn't three years! Our one store facing SQL Server had 50 databases on it and we began the upgrade project of moving/upgrading or replacing the 50 dbs from SQL2000 on it in Nov 2011 and will complete it next week. When you are dealing with a 24X7 highly avail. system that is critical to the business it isn't easy or quick to upgrade. We basically took each app/database one at a time and went through DEV, TEST and PQA and then Prod. The easiest ones first and the last group the most difficult.

I have been telling everyone that this over 2 year upgrade project took us from two versions old to today of now being two versions old. Kind of sad when you think about it in those terms.



Post #1560891
Posted Friday, April 11, 2014 7:27 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: 2 days ago @ 8:22 AM
Points: 1,310, Visits: 781
We are running all 2008R2, with plans to begin upgrade to 2014 Q4 or 2015Q1. But we are doing the upgrade to SQL at the same time we also introduce new hardware and go fully virtual. Just makes sense to get all the testing and upgrades done in one sweep.

Last year I did quite a few interviews as part of changing job. One place I interviewed (company and location withheld to protect the guilty), when I asked them what version of SQL they where running: "Well..... we have some 2012, some 2008R2, some 2008, mostly 2005, quite a few 2000 and 7. Oh and I think there are some 6.5 servers around here somewhere." I politely declined the position.
Post #1560900
Posted Friday, April 11, 2014 7:35 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: 2 days ago @ 12:57 PM
Points: 1,314, Visits: 2,897
A LOT of companies are going to be in the mixed versions of SQL Server boat. I know of many myself.

I think going forward over the next 10 years this is only going to get worse. Reason I say that is as more SQL Servers pop up and more become critical systems the more time and $$ it is going to take to upgrade them all. Pile on top of that tighening IT budgets and very quick turnaround from Microsoft on new versions too.

5 years ago we only had about 120 SQL Server DBS, now we are about 300 and within 2 years we will be at 500.



Post #1560910
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse