The Upgrade Question
-
The Upgrade QuestionWe've been debating some upgrades here at SQLServerCentral.com, especially the upgrade to SQL Server. Like any other company, we periodically look at the infrastructure to see if there is a compelling reason to make a change. In this case, SQL Server 2005 has been one of the items discussed. We're kind of in a unique position in that an upgrade just makes some sense because of the marketing impact. Much like Microsoft performing the upgrades on their internal systems, if we do it, there's some marketing value in us sharing the experience with you. I guess there's some marketing value for Microsoft as well if the largest SQL Server community decides it's worth upgrading. Maybe they'd like to fund some of the work 🙂
It's a tough decision. Early on we were concerned about some of our third party add-ons, specifically some search components, if we upgraded. Those issues have been resolved and now we're in the spot where there's no reason not to upgrade.
Except that there's no reason to upgrade.
Sure SSIS is very useful and vastly more powerful than DTS, but we only have a couple simple packages that export to Excel, so there's nothing we really gain. The 64-bit support is cool and I'd love to get a server with 8GB or 16GB of RAM and see how much faster things run, but that means a substantial hardware upgrade cost. Service Broker is pretty cool for loosely coupling systems, but that's work to rebuild some of our processes as loosely coupled.
There are numerous other features that are cool or work better/faster/easier than they did in SQL Server 2000, but the reality for both this company and many others is that a bunch of work is needed to take advantage of those cool features. In some cases it's substantial development work in addition to DBA resources to make it a compelling case for upgrading.
I'm not trying to say that you shouldn't upgrade. Or that SQL Server 2005 isn't a better product than SQL Server 2000. I think that it is better, but it's not necessarily better in a way that many companies need it to be. If you're starting from scratch, then I think it makes sense to build on SQL Server 2005 and be prepared for a 9 year support cycle for the product. However an upgrade is a more complicated decision and you do want to be sure that all of the work required for the upgrade is considered and that it makes sense for your company and meets your business goals.
The discussion wasn't a total loss, however. I did get to buy more drives and added a RAID 1 array to the RAID 5 array on my database server. It was a little too much downtime to rebuild it as a RAID 10 array, which was what I'd like, but I did take a short downtime last week to move transaction logs for some of our larger databases to the new RAID 1 array. And I did it without ever rebooting the server.
Hot-add is cool.
Steve Jones
-
I agree 100%, we have a 2TB database (which is growing by 25GB-30GB a week) and are in the process of evaluating the performance gains that are there to be had by switching to 2005.
It's a lot of work and more importantly it's a lot of money. In the end it's going to be the business case for the upgrade rather than just because it's cool
If it doesn't look like it will deliver a lot of additional benefit to our company then there's other things we can spend the £60K (4*single processor licenses) on that could improve things too.And speaking as somone that is running a highend clustered 64-bit environment it's good to know that I have 32GB of ram to play with. Not that i'm blowing my own trumpet here, ok, maybe a little
-
It has taken Microsoft so long to upgrade SQL Server that we have mostly grown used to making do with what we have got. Or is it that even with shiny new SQL 2005 Microsoft is just not keeping up with the technology improvements introduced by its competitors. My view is that it is a bit of both.
I think the main driver for upgrading to SQL 2005 will be the decline in availability of new 32-bit hardware. Time will tell, but I would expect by the end of 2007 that 64-bit hardware has a definite cost and availability advantage over 32-bit, and by the end of 2008 it will be very hard to get a new 32-bit server. If your software don't run on the kit you can buy, then you have to move to the new version that does work.
Having said this, I also see a market opening for good emulation software that can give a 32-bit environment on 64-bit hardware. There are a number of applications that simply will not be upgraded to 64-bit, maybe because the vendor has closed or to allow historical reporting of old data. It would be strange if SQL 2000 (or even SQL 6.5) lives on for many years running under 32-bit emulation software on some 50 TB 1024 processor 128-bit laptop of the future.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
-
Hi,
I agree! a SQL 2005 upgrade in our case will also be done on a business case basis, I think we will do it nour datawarehouse and migrate to a 64 bit platform in the same go.
But our company have never upgraded just for the upgrade, that´s also why we currently still have one old business application running sql 6.5
-
Good Thread... Thanks All...
In my case, software development requires that I keep programming with the most stable IDE and database while learning what's new. That said, it's always been a battle finding the time to train on all the great new tools that keep coming down the road.
Am I complaining, not really, it's a great problem to have...
-
Auditing is probably going to have a big voice in whether we upgrade or not. The ability to enforce complexity rules and password expiration on SQL accounts is seen as a big plus over SQL 2000. I doubt that really applies to Steve but it is one more part of the SOX compliance problem at my company.
-
Steve brings up one really significant point which surprises me coming from an editor (and I'm not being insulting, I come from a long line of journalists).
And at the same time other points point out the problem with getting technical advice from magazines.
I am committed to getting all our stuff running on SQL Server 2005 on 64-bit Windows 2003 running on Sun 4600 servers. We are starting with 16 G memory and 4 dual core Opterons [benchmarked against a similarly configured Xeon system it did twice the work in half the time using half the memory - and the Sun's power consumption is amazingly low.]
This is coming from Sybase 12.5.3 and SQL Server 2000 32-bit.
From my POV, SQL Server 2000 SP3a running on Windows 2003 SP1 was the first production ready version of SQL Server, that is, ready to handle the kind of work one throws at Sybase or Oracle.
SQL Server 2005 however is the truly mature version. But it is also the native 64-bit that makes the call; we will SAVE money doing this because we can put thousands of simultaneous users using dozens of unrelated and related applications, internal and external, legacy and new, on a single [pair of redundant] servers, and simply add memory and CPU as needed, expecially now that the Opteron mitigates the front bus bottleneck.
So where does journalism come in? As good as the SQL Server press has become, no longer just being a "rah rah" Microsoft crowd, they still need copy to fill issues. And during the 2000 years, the magazines started printing editorials about "this is too long between major releases" and "Yukon is delayed again - they have to stop delaying it"!
No! 2000 3a on the right OS with enough memory and good disk systems was good enough, I did not want to be thrown into upgrade for the sake of upgrade, especially if it meant the old "after 3 service packs it will settle down" routine.
Microsoft has really started to get a lot of things right. I am very glad they held 2005 till it was ready and didn't play the old "let's ship it and then we'll fix it - maybe" game they played for so long.
OTOH, now that its here, I need its resources.
The other "magazine" issue is that so much coverage reflects trivial installations and aren't terribly informative to the folks who most need information on hot rodding it. You're running a RAID 5 on a dataserver? Fine, if that works for you. What I would lose in disk i/o as a result would make me buy another server. With the price of disk drives continuing to drop and drop, why are people still saving nickels and dimes by short-changing thier arrays?
Aside from performance issues, what about the risk? Raid 10's combined stripping and mirroring is a sure win; RAID 5 is only a single disk farther away from extended downtime than no raid at all. What does your downtime cost?
So yes, I'm moving it all to SQL Server 2005. I am laying out a fair chunk of the boss's change for the new server, but will quickly recoup that in not having to deploy a few more Dell 2850s. I will also recoup it in the power bill and, given our location, the cost of rent for the physical space the server consumes.
It will take me several more years to get everything off 2000 and Sybase; and then if I have not retired it will be time for the next port.
I agree that upgrading just because it is there is not a good decision, but in the end you also must take into account both vendor and community support for the platform. I need to be off 2000 before MS EOLs it - because I know the support for it will start to wither before that. I also will be less and less able to get good advice from the community on 2000 as time goes on because it will more and more be people running systems of a different scale and criticality than mine.
For all that, as much as I enjoyed learning about SSIS etc, I doubt I'll use it anytime soon any more than I ever used DTS - Perl and sqsh are such a lingua franca for me, and work with ANY of my systems, so I'll probably never be motivated to learn some of the cool extras.
Roger L Reid
-
Good editorial that touches on all of the relevant business points. All of the reasons presented are ones that make the case why our site will not go to SQL 2K5 soon. Now we add 2 more relevant issus as well.
The first is 3rd party vendor applications. At present our site is all 3rd party applications. We are a healthcare facility with 19 county-wide locations and 1500 user community that is unsupported by 150+ servers. We even have one system still running on 'vanilla' SQL v7 !. We are tied to our vendors and their software. At present we even have vendor applications that are not certified for Win 2K3 as well.
The second reason is 64 bit. At present we have no need for it. Granted there are issues with RAM on SQL 2K (AWE, PAE, etc.). But we have some servers dealing with it. I think that the 'scare' of not being able to find 32 bit servers is more hype than fact at present. These HW vendors (we use IBM and HP) are not going to stop producing and selling them tomorrow. It will take a year or two more yet. Again, we have to wait for 3rd party vendors to certify their applications.
Now let me add some slightly relevant and more subjective points. I'm old school having worked with SQL Server since v4.21. There are lots of good things that MS has done to improve its quality in delivery. I do have 2 applications on 2K5 and they still have not sold me on changing my belief of waiting until SP2 or SP3 before upgrading. I'm sorry, they hyped it right again, data base mirroring and snapshots were 2 of the biggest marketing points. Alas mirroring was delayed till SP1 (a good call) but not a big media point after that. Database snapshots, well it sounds great but under the covers it's really not a great help. Then you add in all of the 'little' things, one of the most notable in my mind, like defaulting all new columns in the 'studio' to varchar(50), and not including the deletion of old files in maintenance plans as a default. Really, now that seems like very basic functionality in the development and DBA areas. Sure there is SSIS and the Broker and finally adding SMTP email support. But we don't use DTS nor do we need it. As for SMTP mail we've had this solution (workaround for SQL Mil) for quite a while now. In some instances 'old school' is better than the latest and greatest. I'll take my environments stability and quality of user services over the hype any day.
P.S. I still reboot my SQL Servers after any OS or SQL SP application !
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
-
Do you realize that 2000 and all it's versions will not run on Vista/Longhorn server? This means that lots of vendors are scrambling to upgrade their apps with only three weeks until Vista RTM. This probably doesn't matter much to most of you, but for those of us that are early adopters it is a big deal. We take the view that if our vendors want us to keep using their software, they will make it work with SQL 2005.
Joshua Perry
http://www.greenarrow.net -
That's great Joshua, however the healthcare industry and many, many of the big software players involved there are not in that league at all. So the 'bush' leagues it is as opposed to the 'bigs'.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
-
I often find that I am usually alone in my cursing of microsoft when they break fundamental aspects of SQL Server with each new release. Probably because nobody cares as much about the fundamentals.
MS does bad, bad, bad, bad, bad things when they add features. Note that new features are not bad, just how microsoft decides to implement them is stupid or evil. (Like getting rid of the database specific syserrormessages table, for example. Yeah, it's neat to be able to link a specific error message to an email alert, but now I cannot run two separate applications/databases with overlapping error message numbers on the same box.)
The bottom line is that each new release of SQL Server is fundamentally a different product. As such the upgrade question is not a question of upgrading. It is a question of a full software revision to any application/database. Thinking of it as an upgrade (as if it were simply buying new server hardware) is a recipe for disaster and cost overrun.
So, it is better to think of moving to SQL2005 in the context of "Am I ready/do I want to (potentially) perform a complete software revision of all of my current applications?"
On the flip side there is the other question, "Am I prepared for the ratbastards at microsoft to break my existing applications by breaking my existing SQL Server version with their next 'critical' OS patch?"
-
I work right down the road from Epic Systems, Esker is right around the corner and GE is across the street. I talk with those guys on a regular basis, so I know that's not true. Most of the healthcare IT industry is pushing the edge. If your vendor is not, it may be time to find a new vendor. That's the point!
Joshua Perry
http://www.greenarrow.net -
There are many, many more that provide software as well. GE I have no faith in whatsoever. We have a GE system totally supported by them on a separate domain and separate vlan. It is 6 SQL servers (one real server and 5 workstations) using replication. They run no SQL maintenance, no SQL database backups and use PC anwhere via dialup to connect from the server to the workstations for support - we do have a great VPN. PC anywhere is used because thier application does not play well when RDP is used (it crashes the server !) ... oh .. it's Win 2K SP3 and SQL 2K 'vanilla' ... we are looking fo a new vendor to ptovide the medical funcionality we need. For 3.2M we can do far better.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
The Upgrade QuestionViewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply