SQL Server 2005 Adoption
-
How fast is SQL Server 2005 being deployed and adopted? The President of PASS had an interesting blog about this topic recently. He noted that at TechEd Microsoft mentioned a 30-40% rate and then a few months later at the PASS Summit they talked about a 70-80% rate.
Mr. Kline talks about the low adoption rate he's encountered in meeting with users around the country. His experiences seems similar to what I have noted in my dealings with users. I don't talk to hundreds or even thousands of users like Microsoft, but I do talk with dozens and it seems that more often than not I hear that companies have not and are not planning on implementing SQL Server 2005 that soon.
A survey by Edgewood Solutions showed that about half of medium and small companies planned on waiting a year. That was last year and I wonder how many of them have moved to this platform as of now. A survey from PASS mentions 70% of 267 people surveyed were running SQL Server 2005.
I'm not sure exactly what that means. Does that mean that 70% of companies have someone running SQL Server 2005 on a laptop? Maybe it means 70% have at least one production system? It's not clear, but many surveys are intentionally presented that way to maximize the impact of the numbers.
However, I decided to see if you can help me gather some evidence. I put together a relatively short 10 question survey to try and gather some data. I'll run it for a week and get the results next week out here. So if you could spare 5 minutes, take the survey.
SQL Server 2005 Adoption Survey
Thanks for your time and your opinion.
Also, this week will be a collection of data warehousing articles, so I hope you enjoy them.
-
I like to wait about two years after a new version of a database engine becomes available before putting it into production.
That said, I do the same with Visual Studio's new releases. For example I am doing my first application with SQL 2005 and VS2005 at this writing.
Frameworks like Dot Net Nuke are a little different. In a framework, most of the code from revision to revision (EG, 4.1 to 4.2) is stable, so I will use the latest "released" version without waiting for service paks or a time to elapse after release. That said, when DNN moved from 3.x to 4.x I waited about 8 months before beginning a project with 4.x. A major change to the code base makes me a lot more cautious:-)
-
We have over 20 production SQL Server 2000 installations currently. I have a dev box running 2005. I have found a handful of bugs in the RTM and in SP1. I quickly installed SP2 thinking that this will be a rollup of hotfixes and bug fixes then I find the maint. plan delete bug. Yikes...
We are currently in a budget crunch for the next year plus. I cannot goto Senior Management and ask for a quarter million bucks to upgrade all of our SQL Servers as they will ask what do we get for the money. 2000 runs perfectly fine.... there are added features in 2005 but a quarter million dollars worth to the business in a time of an extremely tight budget and not to mention a few of our 2000 installs have very in depth DTS packages that will have to be completely rewritten. It just won't fly at this current time.
-
Personally I think the survey should be broken into two separate sections. One section for SQL software vendors (i.e. the people who build the non-inhouse software solutions to be sold to customers), and the other section for the customers who actually run the commerical and home grown solutions in production. This way we can see the various directions vendors and the end-customers are taking - they very well may not be identical!
My non scientific experiences are that a fair few people have moved over to SQL2005 for non-critical (not Tier 1) applications. Normally starting with home grown apps first. I believe the smaller commerical vendors are waiting for the customers to feel comfortable with the technology first.
To me the primary business reason to upgrade to SQL2005 is the native encryption, this is a strong benfit for PCI/HIPAA etc. Being fined is a compelling reason to upgrade! As Markus points out unless there is a compelling business reason to migrate to a new platform (besides having $250K burning a hole in managment pockets) I see it as generally being a slower migration of existing systems, in coordination with the vendors to produce solutions. New solutions I see as starting out of SQL2005 (that also helps with the budgeting fun).
-
Oracle is the dominant DBMS for major systems at our company. SQL Server is coming into greater use and we plan to have at least three 2005 machines in production in the first half of this year. We don't have any 7.0 or earlier versions of SQL Server so the migration to 2005 will probably go pretty smoothly; as applications are upgraded to versions that support SQL 2005, we will be moving the databases to 2005 machines and phasing out the 2000 servers. Our biggest hindrance to migration is the lack of support from software vendors. While in-house developers are eager to test their applications against the latest and greatest, the outside vendors are very slow to bring their systems into compliance.
[font="Tahoma"]Bryant E. Byrd, BSSE MCDBA MCAD[/font]
Business Intelligence Administrator
MSBI Administration Blog -
At the PASS SUmmit, Attendees were asked if they had at least ONE server in production that was on SQL Server 2005. About 70-80% of the attendees indicated YES. When I do webcasts, most people indicate that they have 25% of there servers on SQL Server 2005 when I ask a question about what they have running. This means that the adoption is wide but not deep.
MSFT estimates that 70% of the installed base is still SQL Server 2000.
Hope this helps!
-
There are two key issues for me...
1. General lack of documentation on upgrade paths...I've posted on this forum and have surfed SQL Server and just do not find many clear answers on how to best approach upgrading.
We ended up choosing clean install on new box (this is important key for #2)
2. Unable to execute DTS jobs migrated to Version 2005...Arg!!!!!! The learning curve for SSIS is VERY steep...I have to re-write every DTS package in 2005 before I can migrate.
Final migration may never happen.
That is my experience...good, bad, otherwise. It is what it is.
-
Regarding question 10 - would you adopt SQL Server 2008 within a year? I selected 'no', but the answer is, I have no idea. I'd need to see it first. I'd also be grumpy about a new release while I'm still working on porting Sybase 12.5 and SQL Server 2000 to 2005.
When asking questions about adoption, remember that we don't sit on our hands waiting for new releases. We have jobs to do. Porting everything to SQL Server 2005 is way up top my list but it takes time, coordination with other people, testing, etc, etc, etc. Meantime, if other priorities overtake it (we are opening a new office, bringing in a new app, this old app broke), I have to address my firm's needs first - asw much as I'd love to be left alone to move the remaining 39 Sybase dbs and the remaining 14 SQL Server 2000 dbs to join the 27 dbs already moved to SQL Server 2005.
By the way, the #1 frustration is installation of Windows 2003 on x64 (especially Sun) - the Opterons kick I/O like crazy once you get a working system; getting the working system is another story.
And the SQL Server 2005 installation is much improved when all is well: very straight forward. But if something goes wrong, you're cooked. For example: installing IIS from "Add or Remove Windows Components" instead of "Manage Your Server" (the second with configure ASP.NET correctly first. If you do Add/Remove and ASP.NET is not set up right, what happens depends on what *is* installed. You can end up with a 32 bit SQL Server in the end). The install needs One True Set of complete instructions - and a complete "uninstall" so we needn't keep repaving would be nice.)
Roger L Reid
-
PS - I notice for many, the lack of motivation is "2000 runs fine". For me, the motivation to switch is that 2000 does NOT run fine, without building entire servers for single apps. What pushes 2005 for me is the ability to run with 16 CPUs, 32 GB memory, and Opterons to avoid the front bus bottleneck.
I realize many folks have multiple servers, I suspect the fact that we started as a Unix shop is what made us so server-centric on SQL Server. I found needing to muck with AWE just to use more than 4 GB memory to be really silly. It was for me the last vestige of Windows as "toy OS" and SQL Servers as "toy RDBM".
Windows 2003 SP1 and SQL Server 2000 SP 3a was the point where we saw SQL Server as something we could trust our data to instead of Sybase. The lack of large memory and real 64 bit support was the last piece; 2005 feels like the Real Thing.
Just another perspective.
Roger L Reid
-
I guess another part of this upgrade path is, if we spend of this time and energy to upgrade all 20+ SQL Servers on 2000 to 2005 along with rewriting DTS packages and then 2008 comes out... jeesh.... all we will be doing is spending all of our time upgrading.... The learning curve for DTS packages to SSIS is HUGE. I have spent hours attempting to figure it all out... I don't like it. For basic stuff it is way to complicated and conviluted. If all I want to do is create a data import from one SQL Server to another and schedule it why do I have to involve Visual Studio ? I opened a informative case with MSFT to try and figure out some how to do's and get though some failures I had and from what I could tell nothing about all of this change from DTS to SSIS is straightforward.
-
I'm with Markus. It takes money, time and training to upgrade, and as soon as we get comfortable with SS 2005, MS will make it obsolete by coming out with SS 2008. As a community, we either need to find a way to persuade Microsoft to begin to show a little respect for our time and wallets or find a way to get off of their treadmill.
To Steve -- This survey was a great idea!
-
We have about 1/2 dozen copies of 2005 running including 2 clustered environments. This includes QA&Production. Our "upgrade" path is normaly to just install a new 2005 server (SP2) and re-install the application into it or just reload the databases into it. We haven't followed a true, in place upgrade. All in all it has worked out well. We have about 100 2000/7.0 servers and will be migrating into 2005 over the next couple of years. It would probably be quite awhile before moving to a new version (2008) at this point but things tend to change.
The only real hitch found has been the DTS/SSIS diffrence but overall it has been fine!!
-
Unable to execute DTS jobs migrated to Version 2005...Arg!!!!!! The learning curve for SSIS is VERY steep...I have to re-write every DTS package in 2005 before I can migrate
What problems are you experiencing with running DTS packages? I upgraded one of my servers from 2000 to 2005 last weekend and we have a large number of jobs with DTS packages that are all running fine.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverabilityWe walk in the dark places no others will enter
We stand on the bridge and no one may pass -
Above Quote of Gilamonster.
[Assumption] Do you mean that you are using SSIS to execute DTS packages? [/Assumption]
If this is the case are you really leveraging the full potential of SSIS - if there is actually a tangible improvement of SSIS over DTS - and if not would you say there was an obvious benefit to upgrading to SS2005 in say a data warehouse environment which relies heavily on DTS rather than a transactional system which might take advantage of other aspects of SS2005.
What i guess i am asking is if you use SSIS to run DTS why bother changing at all?
K.
-
Not sure if this is addressed to me or not, but I'll answer.
No, we're not using SSIS to exec the DTS packages. We imported the DTS packages as legacy objects and we're using dtsrun to run them, just as we used to in 2000.
The packages will get upgraded to SSIS in time, but the fist priority for us was to get things working on 2005 as-is.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverabilityWe walk in the dark places no others will enter
We stand on the bridge and no one may pass
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply