Closing on One Year
-
Closing on One Year
With a few years of buildup, SQL Server 2005 was released last November, just after the PASS 2005 Summit, and with a series of events taking place around the world in the months after. There was so much press, many articles, speculation, and writing on the features that were in it, the ones that got dropped, and all the wonderful new enhancements that would change the SQL Server paradigm.
And here we are, three quarters of a year later, and ...
Things are fairly quiet. The buzz isn't necessarily on SQL Server 2005 as I get almost as many SQL Server 2000 related articles here as I do SQL Server 2005 ones. There's lots of talk about SQL Server 2005, but the excitement seems to be gone. And other than SSIS, I don't see much of the technology being given a lot of press. So I'm wondering
When are you upgrading to SS2K5?
One server, all servers, any server, new servers. I'm looking for a rough poll on your SQL Server 2005 plans. Are you upgrading? Do you have budget? If it's upgraded, how did it go?
Also, do you think it's worth it?
A freind and I have had this debate a few times. We used to work together and now at our weekly softball games we'll ask each other if we're upgrading. He's looking to move one server, mostly waiting on budget, but not in a hurry. His SS2K servers are rock solid, so he doesn't see a compelling reason to move.
I'm kind of in the same boat. I'd like to upgrade the SQLServerCentral.com servers, but I need to be sure things will run smoothly and I haven't had spare hardware for really good testing yet. Plus I don't need to find more things to do. The training center along with all my other work has me plenty busy.
But more than that, I don't think I'd take advantage of many of the new features. I've been working with Ss2K5, writing about it, and trying out new features, but I've yet to reach a place in my daily SSC work where I wished we had upgraded to use a new feature. Our SS2K servers run great and there's no compelling reason to move.
I used to think that maybe Microsoft should just wait 5 years between every version. Let us sit on the technology we know, learn it, get comfortable with it, and every 5-6 years we can upgrade. Now I think from a business standpoint and even a customer standpoint, that's not a great idea. Maybe a new version every 3 years makes sense.
With most of us upgrading to every other version.
Steve Jones
-
The last shop I worked at had the same perspective - they were doing some testing of 2005 but didn't want to convert yet. Their biggest hesitation was the DTS - SSIS conversion path.
My current contract is for a Sybase 12.5 to SQL Server 2005 conversion. This place needs the higher availability / performance enhancements of 2005.
I've been looking for (and have just found) my newest contract. I've been targeting the 2005 shops but have also talked to some that are still on 2000. The hesitation generally falls into two categories: questions of stability and the learning curve.
The overall theme seems to be new projects = 2005, maintenance / upgrades / enhancements = stick with 2000 for now.
(the new contract is for a big 2005 SSIS project and I can't wait to get started
) -
Like you Steve, our numerous MSSQL 2000 servers are very stable. Whilst there are new features in 2005 which we would like to use (perhaps most tempting is the TRY-CATCH statement), from a business point of view there is nothing that we cannot achieve using 2000.
When we consider the extra work involved in upgrading, and the cost (our M$ Select licence means we would have to buy new full licences) it really does not make sense.
Lastly, we have used replication quite extensively between our various databases. The rules governing which servers we would have to upgrade first, and the complications of breaking/recreating snapshot and merge replications, just makes upgrading a huge uphill task.
Last week I finally received the MSSQL Server 2005 Upgrade Resource Kit, which includes 7 full days of video presentations alone. When I've watched all of that, and read the various technical papers, I might be ready.... Maybe 5-6 years between upgrades is a bit optimistic
-
We looked at the implications of upgrading to SQL 2005 earlier this year and decided it was too much effort to fit into our business plans this year, and possibly next year also. Since then our volume forcasts have been revised upwards (i.e. we are doing more business!) and have decided our data warehouse will run out of steam on SQL 2000.
The biggest problem we have is with partitioned views. Some of our queries aimed at the partitioned views join more tables than SQL can support. We have done some workrounds by having subsets of the partitioned views that cover a smaller date range, but the large numbers of tables often results in SQL materialising intermediate data befoer filtering it, rather than pushing the predicates down into the base tables. We have done some tests that by using SQL 2005 table partitioning, the significantly reduced number of tables in a query does give better access plans.
The conclusion is that to meet the business performance targets, we will have to move our DW data to SQL 2005 by the end of this year. That just leaves the DTS (ugh!). We simply do not have the time or budget to re-work the DTS to SSIS this year. At present it looks like we can use the DTS add-on from the SQL 2005 resource kit to give us the DTS functionality we need in a SQL 2005 environment. If further testing shows that some of the DTS does not work properly, our fallback is to keep a named SQL 2000 instance to host the DTS, but target the connections to the SQL 2005 databases.
So, the end result is that the business had higher priorities than spending time and money standing still in a move to SQL 2005 that was not needed, but now a need is accepted the DW should move this year. Our remaining LOB applications look set to stay on SQL 2000 for at least 1 more year.
Personally, I think that 5 years between releases is too long. It results in a major step from 1 release to the next. The continual delays in releasing what was originally to be called SQL 2003 resulted in a decision to budget for the upgrade only after the product hit the streets. We have a major application that runs on DB2 for AIX, and the 2 to 3 year release cycle for DB2 is far easier to cope with - smaller, more frequent, and predictable steps allow pro-active budgeting for change. The result is that our DB2 application moved from DB2 V6 to DB2 V8 over the last 5 years, with a move to the new DB2 V9 likely next year.
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
-
We have one servr running 2005, mainly for Reporting Services. We needed Report Builder, something not available with 2000's Reporting Services.
-
As a consultant, my existing installations, aren't even being targeted for conversion, and all of my new installations will be 2005. I find some very small clients like to start with MSDE, and if nothing else, the ease of install for 2005 Express will be nice.
The main thing I look forward to is putting .NET assemblies in there as opposed to extended stored procedures ...that will be nice, but I'd say only 1 in 4 or 5 of my installations requires more than what you can do in a T-SQL stored proc. anyway.
In short, going forward, I'm going to be using it and enjoying it, but what's there will probably remain 2K.
-
We have 19 production SQL Servers here running SQL 2000. I have 2005 on a DEV server and have played with it enough to become familiar with it. I have to say I am unimpressed with the GUI, so many things are difficult to find and take longer to do. We are going through a severe budget and headcount reduction so upgrading the servers to SQL 2005 is out of the question. We do have one new project that has certified 2005 so we will probably go with that. Also, there is some consideration going on to moving our data warehouse from AIX DB2 to SQL2005 and MSFT has been on-site trying to sell the conversion which would be 2nd quarter next year.
-
As developers we MUST upgrade to Yukon.
We will have another headache - in near future we will have clients working with different versions of our system.
Just as we had with 2K.
Long cycle is good because we do not need to spend our time for upgrading?, long cycle is bad because it's too many differences between versions.
-
As a software developer I will use SQL Server 2005 Express for a update of a Paradox database from 1998 with 30 users (its amazing that this is possible). In this way I earn some experience on the 2005 Sql Server environment. But all my other programs (4) remain on 2000 (smallbussiness server version) as they function very stable and I don't need the new features.
There are some wishes I had, e.g. time fields, a TRIM function (not L and R TRIM apart), a pivot table (not the current implementation), etc. but I miss them in 2005. Most of the new stuff in 2005 is for heavy users, not for simple users as me.
But SQL Server 2005 EXPRESS with Management studio is great.
-
We are getting a new server with 2k5 for reporting services. Our other servers will remain 2k for the foreseeable future.Like you mentioned our current implementations are rock solid; why change just for changes sake~
That being said, I am using the MS for managing servers/running queries...just to get used to the new tools. I haven't got the add on yet; still editing DTS in EM.
-
We are looking at upgrading to SQL2005, probably in the next six month of so.
I have been using Management Studio to do most of my database work, and I like it better for many things.
The one glaring problem I see is that the Database Design GUI does not work!
For example, try changing the PK_Customer index from clustered to nonclustered and you get Drop failed for index 'PK_Customers'. This change is no problem in SQL2000, and you can just as easily change it back to clustered again. Just one example. It is easy to find more.
This is a serious problem for anyone doing database design or just making changes to an existing database.
I cannot be the only one who has experienced this problem, can I?
Please send me some feedback.
-
Probably not until support of 2K is withdrawn, unless I find some compelling reason otherwise (though I doubt I will).
As others have said, our SQL 2K environments are running quite nicely thank you, and I see no business need to upgrade at present.
Some of our customers still run comfortably enough on version 7!
-
We are also happy with SQL2K. And are now getting some requests from the business areas for SQL2K5... mostly because they are revising their applications and want to go with the latest SQL edition.
One thing I have found so far as a compelling reason to move to SQL2K5 for next year (working out the strategy and details now) is to run it on 64bit. Is anyone else doing this?
We are running one server for proof of concept, an HP BL20p with dual Intel HT 3.6Ghz chips and 4GB RAM with 64bit Win2K3 and SQL2K5 64bit standard edition. And although I've only had one day so far to really 'kick the tires' each test I've done far shows that it surpasses our one production SQL2K5 server (bl45p with dual AMD dual-core 880's with 4GB RAM - 32bit OS and SQL) by 50%.
If this performance gain is consistent, that would be a great reason to move to SQL2K5 (if the ooh-ahh features don't sell the decision makers). Think about it:
- There is no cost difference going from 32bit Win2K3 to 64bit
- Same holds true for SQL2K5
- The hardware we're buying today BL20p's and BL45p's arlready support 32-bit or 64-bit
- achieve potentially 50% performance gain
Obviously I've got more testing and due dilligence to do, but if it pans out, it's an easy sell to my management. Plus SQL2K5 supports 2-node clustering for standard edition out of box... which means, my nirvana looks like potentially consolidating my several farm servers down to one or two clustered 64bit farms....
Just my two cents...
PS - I'm still not crazy about Management Studio.. but after getting a memory upgrade the other day, it's definately got some more pep, which helps.
-
Done on one server which is 2005 development plus some Sharepoint databases.
Reporting services will be big as we can move off Crystal bodges (crystal enterprise is too expensive) and we are working on this.
No rush to ditch 2K though.
-
We've actually hit a bit of a blocker on the upgrade to SQL2k5 due to some replication features being deprecated (alternate Sync Partners), and no reasonable alternative being offered by MS. Have done my Sharepoint testing already and am happy to go and migrate there, and we're also getting the some naggings from area's that they want to use 2k5 ... alhough in reality, this is only cos it's the latest tech and not for any specific new feature! Personally, i want to upgrade and we're licensed to do so straight away as our current SQL2k architecture is under 2k5 licensing, because that's all we could buy at the time!
... and i dont know what ur all on about WRT the Management Studio ... I really like it!!
Viewing 15 posts - 1 through 15 (of 28 total)
You must be logged in to reply to this topic. Login to reply