Don't Upgrade to SQL Server 2005
-
I would not plan against the targetted RTM time frame from 2008. Not only is this date likely to slip (based only on the fact that all RTM dates are), but do you really want brand new RTM bits?
After making the case for only the very highest levels of stability I find it hard to believe that you would recommend SQL 2008 before its SP1 has been out a few months.
-
I would like to add some weight to the idea that one of the greatest benefits of upgrading to SQL 2005 is 64 bit. I’m at a relatively small company, but the last server we bought to run SQL Server on was 64 bit. As I remember, it was cheaper than a comparable 32 bit machine with older 32 bit technology. We are currently running it on 32 bit Windows OS and SQL 2000, but moving to SQL 2005 and Windows 64 bit OS would be a big step forward, I believe.
-
Great arguments, especially the DTS one (which I wasn't aware of), and I appreciate the feedback. It's definitely an individual decision and your support and arguments are good for everyone to read.
First let me clarify that I don't think that you should ignore 2005/2008 if you haven't upgraded. On the contrary, you should work with the 2005 bits (and 2008 if you have time) to learn how the product works.
Next, my argument for 2008 is that it's like 2000. It's really a ".5" release in terms of stability. Don't let the marketing fool you. This is really SQL Server 2005 R2 and so I think it will be more stable out of the gate. I think SSIS will work better, the core 2005 features that have been hot fixed or have issues will be more stable, and you'll have a few more features. My argument for waiting on upgrading SS2K servers (assuming the DTS issues don't bite you) is that if you upgrade to 2005 now, you'll have the platform for 4 more years and then you'll be pushed to upgrade. If you wait one more year, while testing on 2005 and getting ready for 2008, you'll have 7 years you can run on that platform.
Lastly, I think unless you need the new features on SS2K5 and instead are happy on 2000, you definitely should wait and be rewriting your DTS packages on SSIS to prepare for the move.
I'd also add that since you have support for 2 versions, if you're going to be on the "upgrade every other version" cycle to remain stable but not try to constantly keep up, you'd want to be on the v6.5/2000/2008 cycle, not the 6.0/7/0/2005 one.
-
You can not run 64-bit version of 2000 on non-Itanium CPUs. This forces us to upgrade to 2005.
ThomBeaux
Thomas LeBlanc, MVP Data Platform Consultant
-
At first thought, I saw the logic in what Steve outlined with the incremental versions. However, server and development software Microsoft has been releasing of late is of much higher quality than the garbage they put out in the late 90's - 2003.
Now that MS is back on track with putting out software on a reliable schedule, I believe it is generally best to remain 1 version behind the current version (at least for servers and os).
SQL 2005 has been a pretty stable product since it's beta, and a very stable product upon release. It has a much better foundation and history than something like SQL version 7. You really cannot compare the two at all.
Another thing about 2005 is that it was rewritten in .NET, so as long as they keep improving up .NET via updates, and sending out SP for 2K5, I think SQL 2005 will be a product you can use many years to come.
-
looks like the MS hype machine is in full swing. few years ago they were hyping sql 2005 as the next best thing, now it's don't buy 2005 since 2008 is it.
we upgraded some servers over the last 8 months to 2005 due to the online maintenance which has been amazing. last month we upgraded to 64 bit on a few of the servers because our data doubled over the last 6 months and the old hardware could not handle it. over the next year our devs will start to use the new sql 2005 features.
2008 sounds nice but it's going to be another multi-year upgrade cycle so unless there is a need for it there is no need to buy it over sql 2005. with 64 bit we are OK until MS stops support for windows 2003. we are running 32GB of RAM and if we need to we can buy new servers that support up to 128GB of RAM
we might deploy a 2008 server for BI but otherwise this is crazy having a new db server every 3 years. no one in their right mind upgrades that often unless you are on the rent a software licensing scheme
-
Good point about the 7 year issue.
As far as the "upgrade every other version" cycle, I don't think you can be oin either one of those two options due to the major time (and technology) gaps between them. Instead, and I know some of you veterans will disagree, I think that it's best to start your version cycle over with SQL 2005 as the baseline. There's just too many differences between Pre-2005 versions and SQL 2005. The technologies are comepletely different animals and should not even been seen as the same product.
If you can manage this, and assuming MS keeps up with their release schedule, you will eventually be in much better shape. The same rule applies for ASP to ASP.NET. Sometimes you just need to make the jump.
-
Are the people that have been complaining that it took Microsoft 5 years to get out a new release of SQL Server now the same people who only want to upgrade every 7 years? There seems to be a double standard here. Why do we want Microsoft to put out more frequent releases if we are not going to implement them?
-
in a smaller environment frequent upgrades are easier. in larger ones there are enough bugs in sql 2005 with backward compatibility to make it a challenge. then there are application issues.
-
As SQL Server matures more and more companies are putting mission critical large databases on SQL Server. Also, there are more complicated installs now since it will scale unlike in the SQL Server 6.5 days when it was tagged as a departmental only RDBMS. With that said larger 24 X 7 systems can not withstand bugs and CEO's put up with less outages. The knowledge curve went up substantially from 2000 to 2005 and from what I have seen more functionality is there but the downside is alot of complaints have been some stupid bugs in original release, Sp1 and SP2 not to mention the Management Studio is very slow and lost some functionality.
-
Agree with Mr. Buchan's assessmemt; plus an additional observations that SQL Server 2005 is much slower in terms of performance from SQL Server 2000.
SQL Server 2005 has become a much more complex to administer DBMS; no doubt a result of it's integration into .NET and its increased scope and functionality.
-
I agree that you need to do a little studying on the new administration model of 2K5, and will even go as far to admit that Management Studio is on the slow side. However, from everything I've seen, the 2005 engine is faster than 2000. There are things that work faster in 2000 than 2005, and that may make the engine seem slower, but if you research it, there's usally a better way to implement whatever is causing the lag.
I don't know your situation, but when people tell me a db engine is slow, it's often a result of poorly created indexes (or not having any - or having too many), not using seperate controllers for your logs, data and indexes, outdated statistics, software raid, etc. Once they wake up to some of these things, their performance stories change dramatically.
Here's some articles on SQL 2K5 vs 2000 (non-Microsoft propaganda)
http://sqljunkies.com/Tutorial/077C7BEB-EB31-4A07-923D-BE309F59D0F8.scuk
-
Other than the lead in statement, SQL 2005 has been released nearly three years ago when in fact it was released in November 2005 making it only 20 months I agree with the sentiment expressed in the article, upgrades should be driven by needed feature sets and not Microsoft support cycles which are more aligned to growing its own revenue.
My company is a third of the way through an 18 month SQL 2000 to 2005 upgrade project and there hasn't been a noticeable difference in performance from a business user perspective for any of the databases upgraded. At the end of the day as would be expected the 2005 database application functioned exactly the same as the 2000 database application the only difference has been the 7 figure price tag for the project and all the time spent not working on projects that actually provide real business value.
As several people pointed out SQL Server is used as an enterprise level database, well its about time Microsoft starting acting accordingly. Give me longer support cycle, Solaris gives me 12 years on some of their OS levels. Give me point releases like Oracle R1 and R2 instead of "new" product levels like SQL 2008. In short give me support cycles that help my business and extend SQL 2000 support beyond April 2008 now.
-
I have a couple interesting observations.
1) When I looked at Steve's article, I saw it right next to an article about upgrading to SQL '05. (did anyone else see the humor in that?)
2) As for skeptics of performance in SQL '05, Full text catalog rebuilds are 100's of times faster in '05! From days to hours... I could go on and on about performance gains. The other thing to keep in mind for performance is performance of troubleshooting and development time. Development is a lot faster w/ VS/SQL '05. Also, I can narrow down a problem a lot faster in 2005.
Back to the original point, keep in mind that (as mentioned before) new SW is best when combined with new HW. Going from 32-bit to 64-bit and all of the multi-core improvements, SQL '08 is not going to have too much exciting HW to go with it, whereas the 64-bit upgrade is a huge improvement (CPU and memory). Anyone else know of exciting HW on the horizon that SQL '08 will support that '05 won't?
-
The SME I work for sees no reason to upgrade to 2005, they have, in their view, a perfectly stable working 2000 environment. I suspect they will apply the same logic to 2008 when it comes out, and will only consider an upgrade if their parent company forces them to do it.
David
If it ain't broke, don't fix it...
Viewing 15 posts - 16 through 30 (of 39 total)
You must be logged in to reply to this topic. Login to reply