July 5, 2007 at 5:25 pm
Comments posted here are about the content posted at http://www.sqlservercentral.com/columnists/sjones/3094.asp
July 10, 2007 at 9:55 pm
A strong second on that recommendation to hold out till 2008.
My only disagreement with anything Steve wrote is regarding the stability of SQL Server 2005. Yes, the data engine of 2005 is surely stable, but the development integration -- where they seemed to focus -- is less reliable than it should be given the beta cycles they went through. The best example of this is the horrendous management tool interfaces, which on many development boxes were seriously hamstrung. And requiring a development tool upgrade to VS 2005 just to get at some features was a problem in terms of deployment, since VS 2005 was not backward compatible. It produced an added layer of swkward management, and that affecte dproductivity.
I'm not saying SQL Server 2005 was a bad release, though, just that when you analyse their development process, beta cycles, and so forth, it just wasn't really a solid release. The same is true of VS 2005, which wasn't really usable in many scenarios until SP1.
My biggest fear for 2008 is that a trio of upgrades will create a slew of isolated platform bugs, and an unpleasant batch of integration-bugs. MS needs to consider slowing down and committing to point releases and optimisation for a few years after 2008, or it will cut their bottom line.
July 10, 2007 at 11:16 pm
While I don't necessarily disagree with anything in the article, he has provided no concrete reasons as to why you shouldn't upgrade - only opinions and speculation.
Personally, we won't be upgrading to 2005 but will rather skip to 2008 but that's merely due to 2008 being released within our upgrade time frame.
July 11, 2007 at 2:35 am
Sounds compelling to me, esp. the '2 versions to get it right' argument (6/6.5, 7/2000). Also I can now say that leaving most of our Servers on 2000 was part of a clever strategic plan rather than lethargy and a reluctance to work weekends!
July 11, 2007 at 3:32 am
Well,Nobody talked here about the costs.This is another reason for companies not upgrading now to another SQL release.
But anyway,i believe there's also a need to keep the technological wakefulness so,not migrating to SQL2K5 might also be a problem if you do not have an efficient test environment.
The hen and egg issue?
July 11, 2007 at 4:00 am
I don't have any great "concrete" reasons and even if I did, they would apply to me, not to your individual systems. It's just that as a general rule, I think that the pairs of releases, which you could argue are SQL Server 9.0 and 9.5, you'd be better off with the new version.
My guess is that there is a team working on SS2K8 and a separate team doing patches/SPs for SS2K5. Some of the stuff that gets fixed moves over to SS2K8, but I'd agree that it's probably a stability v9.5, but with new features, like the policy based management, it's pushed as a v10.
July 11, 2007 at 5:48 am
We have only one SQL 2005 install here and about 20 servers on 2000. I have been disappointed in several bugs or things broken by SP1 and SP2 and some of the Ent. manager ease of use things for daily DBA tasks are gone or horribly rewritten in Mgt Studio. Mgt. Studio is TOO SLOW. I am very disappointed on how difficult it is to simply set up a job to bring data into a SQL Server table from another RDBMS. DTS was not the greatest but it was simple to use.
We are in a budget crunch here and I cannot goto Management and ask for $250,000k + to upgrade all of our SQL Servers to 2005 and then say oh, next March there will be a new version and we have to rebuy SQL Server all over again.
July 11, 2007 at 6:02 am
Well, I think it is horses for courses. And I get the impressions Steve does intend that as well. Some of the new things in SQL 2005, however, may mean you don't want to wait (.. or didn't wait, as in our case - we've been on SQL 2005 since... 2005). That said, we also have several SQL 2000 servers, and some 7's as well. Upgrade where you need to, for good reasons, is my opinion.
Some of the performance and stability issues we (by we, I mean our core client) had was around a massive caching system that aggregates and presents data from several hundred SQL servers, and then makes this available to our customers (somewhere in the order of 500 million to 750 million 'tuples'). Towards the 2nd half of 2006, the SQL 2000 DB cluster had frequent problems - to the level that the cluster was failed over on a near-daily basis. Now I am sure many people will think that this is due to bad code, I should point out that what was done here was reviewed by MS, and was considered by Ms as a very good, innovative solution to a very challenging problem. After upgrading from SQL2000 to SQL2005 (with virtually no code changes), this server now runs at an average CPU of around 10% and has not needed a fail-over in 9 months.
Not everyone will have these needs, but the performance improvement can be significant, as can the 24x7 enhancements.
I should also say that SQL 2005 is not the panacaea for all SQL problem, either. In some areas, I'm not sure it is that stable a product - SQL 2005 SP2 and SP2a debacle a prime candidate. We still have assertion errors on 1 of our (5) live SQL 2005 server clusters, and have had them for 2 weeks now... we are on build 3175 with no resolution. Fortunately, is doesn't appear to have an impact (yet) on our service, but it is very concernign to see 80-100 assertion errors a day, on a server.
July 11, 2007 at 6:50 am
Hmmm .. I'm not sure I agree, the biggest advantage of sql2005 is 64bit and I'd hope we were all heading this way very quickly - I accept I tend to work in large companies who benefit from such advances.
There's just so many advantages with sql2005, security, tuning, analysis - waiting until sql 2008 would likely mean another 18-24 months, as I'm sure most would wait for sp1 before an upgrade ??? , by then you'll be running on 9 year old technology.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
July 11, 2007 at 6:56 am
We have a mixture of high end, medium and very tiny dbs here on 2000. The cost to upgrade is astronomical for us being in a budget crunch. When we upgrade we typically get new hardware too so when we switch it all out our fallback would be to simply shutdown new server and power up the old one. Considering an upgrade to 2005 includes new hardware and with 2008 around the corner I cannot sell an almost half a million bucks to upgrade them all even with some consolidation in a budget crunch year especially when i tell them next year there will be a new release.
July 11, 2007 at 6:57 am
I believe the author is dead on with not rushing to implement any Microsoft releases that are hot off the presses..........unless there is a viable BUSINESS reason to do so....my concern is certification........my take is that the introduction of CLR and XML functionalities alone have made the 2005 skillset significantly more distinct and .NET centric than that of its predecessor versions. The million dollar question at this point for me is......does the 2008 version introduce a great deal more?
July 11, 2007 at 7:15 am
I completely disagree with his recommendation. What I see in the article is a conflict in reasoning. What I mean is that on one hand he talks about the stability of SQL2K5, but then recommends going to 2K8 based partly on promised features and a CTP release. What happened to the stability argument?
And here's the core of my disagreement. We're talking about a year's delay in an upgrade based on Microsoft's plan to release 2K8 at a certain time. That's a pretty dicey plan. Microsoft has a well-documented history of delays and feature reductions on new products (i.e. Vista, for one example). Let's suppose that Microsoft has challenges and pushes back to Q4 2008 or Q1 or Q2 2009. That's 6 months to a year that you've gone without even the features in 2K5, much less the new 2K8 features. These are features you could have now with an upgrade to a tried and tested product.
Another major issue I have is the recommendation to not only plan an upgrade for as soon as it comes out, but to make that plan before even a beta has been released. Is that really a recommendation for stability? I don't see how it could be.
My personal recommendation would be to upgrade to SQL2k5 SP1 right now. It's very stable and it has some very, very good features that most organizations would benefit from right away. Heck, SSIS alone is a reason to upgrade. It's so much better than DTS as to not even be funny. Then I would recommend planning on upgrading (if necessary) to SQL2k8 some time in 2009 once it's been deployed en mass.
I can tell you that there's no way I would personally upgrade a production SQL Server to anything that's been out for less than 6 months. It's just too big of a risk.
July 11, 2007 at 7:17 am
Steve,
Your comments are, unfortunately, a year late for me to use. I'm already months into migration.
The learning curve is REALLY steep going from 2000 to 2005.
Some things for the community to consider...
1. You might want to upgrade at least one server just to make the learning curve to 2008 a little shorter.
2. Reporting Services is a more mature product
3. Analysis Services has the ability to offset a $100,000+ investment in SAS/SPSS data mining and econometric servers and applications. Microsoft plowed a lot of internal Ph.D resources into this tool to get it up to snuff with these other stat/econometric/data mining apps.
Ah well...maybe I'll skip SQL Server 2008 and upgrade to 2011 when it is released.
July 11, 2007 at 7:35 am
Steve makes his points well (as usual) - and cases vary. I would counter-argue
that this does NOT derail my current efforts to get all my SQL 2000 and Sybase databases
onto 2005.
As usual, I am not going to move to 2008 the day it is released. I no doubt will
spend 2009 moving from 2005 to 2008. I don't like the 3 year release cycle; it means
I will never have a stable platform, I will always be moving. This of course
bolsters Steve's point, instead of refuting it.
But here's why I am continuing to move 2000 to 2005, and let 2008 fall as it may.
My shop needs the cache sizes that you need 64 bit versions to use well. As a matter of
policy, we only want to support one database platform. I can tell you my old 2000 servers do not get managed proactively (Sybase doesn't really need to be managed - the old story:
MS management tools are far superior to Sybase's - a good thing too, since in SQL Server
you need to manage!)
Why do I still have 2000 servers? Because vendors won't get off the stick and deal with it. It amazes me how many vendors still are not supporting 2005. Hopefully, the threat
of the end of support will get them moving.
Roger L Reid
July 11, 2007 at 7:36 am
I too had several issues with the recommendation. But I'll only tackle one, the DTS migration.
Virtually the only piece of SQL 2005 migration that is causing us headaches is the DTS to SSIS issue. While those migrations will cause some pain, Microsoft also give an "out" to ease that pain by having a 2005 package install that allows the use of the Management Console to create/edit DTS packages. According to all documentation, this package will not be available at all for SQL 2008. So if you delay until SQL 2008, you will need to REWRITE all of those DTS package right out of the gate!
Viewing 15 posts - 1 through 15 (of 39 total)
You must be logged in to reply to this topic. Login to reply