Advantages of 2005 Over 2000 ? 3

[JohnBates]

hi everyone,

I plan to recommend to management that we purchase our first SQL Server 2005 server license. We have several 2000 servers running.

Knowing that they will want to justify the expense, can you give me some tangible benefits of using 2005?

We mostly use fairly basic features such as dts packages and replication. I know 2005 offers better security but that's not really a benefit to an organization that allows most people to connect with sys admin permissions

Thanks for your ideas. John

 

[micha123]

I think that the major enhancement that will interest your managers is the performance improvements.
From collegues I've heard of 10-20% improvement by only moving to SQL 2005.
You can also read and read a lot of stuff about the enhancements in SQL 2005.
For example:

http://www.microsoft.com/sql/prodinfo/overview/whats-new-in-sqlserver2005.mspx

Just GOOGLE:
"sql server 2005" improvements
or
"sql server 2005" enhancements
and you will discover the world...



"A long life is when each day is full and every hour wide!"
(A Jewish Mentor)
M.

 

[JohnBates]

Thank you Micha. Improved performance - now that's something management can appreciate!

John

 

[micha123]

You can also rely your recommendations on the TPC results:

http://www.tpc.org/tpcc/results/tpcc_results.asp?orderby=dbms

"A long life is when each day is full and every hour wide!"
(A Jewish Mentor)
M.

 

[micha123]

Sorry...
This is better:

http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=all&version=5&currencyID=0

"A long life is when each day is full and every hour wide!"
(A Jewish Mentor)
M.

 

[Catadmin]

Also, SSIS offers much more benefits than DTS ever did, including abilities to pull individual bad records out of an import data set and ignore those (or do whatever you want with them) while processing the rest of the data set. How's that for a benefit of 2005?



Catadmin - MCDBA, MCSA
"No, no. Yes. No, I tried that. Yes, both ways. No, I don't know. No again. Are there any more questions?"
-- Xena, "Been There, Done That"

 

[JohnBates]

Thanks Catadmin. In 2000, it is not too easy to detect and handle dts package failure. Is is easier with 2005?


John

 

[Catadmin]

Yes, actually. First because you can now use the VB .NET Try...Catch statements to find errors. Secondly, because you can have the package mail you from inside itself with errors or other issues.

Also, the debug tool in Business Intelligence Design Studio is actually pretty comprehensive. Takes a little getting used to, but it will tell you everything when you're testing the package.



Catadmin - MCDBA, MCSA
"No, no. Yes. No, I tried that. Yes, both ways. No, I don't know. No again. Are there any more questions?"
-- Xena, "Been There, Done That"

 

[JohnBates]

...These are some comments by other SQL Server professionals at sswog.org about their reasons for not yet
using SQL Server 2005, or various obstacles they have encountered:

"I've now done [and consulted on] three migrations, and in all three cases code that was migrated directly over was absolutely slower. Query optimization seems slower, and complex joins are definitely not as speedy. Scalar user-defined functions are also quite a bit slower (a really big deal for one customer, who totally over-used them), and that's easy to prove with a quick test. In addition to those problems, I've found issues with statistics updates and FTS really slowing down the system, much worse than similar behaviors in SQL Server 2000.

Now the flip side: all three migrations were carried forward, and once the performance problems were fixed SQL Server 2005 definitely performed better than SQL Server 2000. These issues can be mended, but a migration does require a lot of work upfront. People should not expect to just copy over the databases, start up the server, and have things work great. The jump from 2000 to 2005 is quite huge. A lot changed -- including performance techniques -- and what used to work in 2000 won't necessarily be optimal in 2005.

[People] should read up before acting -- I've done a couple of webcasts and articles on the importance of testing before migrating, and have seen and read several others..."

Jason: "The main reason we have not yet moved to SQL Server 2005 is that the applications that sit on top of SQL have not been verified as 2005 ready.... Otherwise I think we'd already be there. I've personally been to road shows, used the CTP versions and our Data Warehouse Team even has the fully licensed copy of standard edition, but we can't move forward in our department because of these constraints...."

Charles: "Simple reason for not moving forward - Framework 2.0 requirements that necessitate a complete rewrite of the front end applications (okay, not complete in most cases, but some level of rewrite). DBA's get the vote on data issues, but pushing for a major effort out of my .Net developers just leads to whining from them about how many months of effort it will take - even though a quick test on my 2005 platform showed that the front end would in fact work with some minor tweaks under 2.0 with what amounted to a weekends spare time work worth of my inexperienced recoding (I've self certified .net with NetG online training).

That leads to: Simple reason #2 How many DBA's do you know that are trained in .Net development? MS has done a good job of advertising 2005 with it's .Net integrated IDE - which scares the bejesus our of DBA's with no background (or training budget).

Speaking of budget; simple reason # 3 SS2000's #1 selling point over Oracle for most companies was cost, both up front and for the # of DBA's, and that those DBA's accepted salaries lower as compared to Oracle [dba]'s. These aren't companies that are willing to spend 10k in salary difference, yet alone 10k in training costs.

#4 reason; years of building DTS based ETL packages - resources to rebuild them is simply not there and with industry turnover being what it is the people that developed them are long gone.

Most DBA's I talk to (I'm a independent contractor, so that's a lot) want to make the change, but don't simply can't push it forward. I've been asked to evaluate DBA or 'Data Manager' written migration plans a 3 times in the past year - want to guess how many of them had actually run the migration wizard to see what needed done? One 'senior data manager' thought it would be as easy as back up and restore the db's to the 2005 server! He had a nice 2 day migration plan."

 

[Catadmin]

Good point to all of the above. In fact, the new SQL Server does require DBAs to become part developer.

I forsee a future in which T-SQL is not the only language DBAs will be required to know. Soon, job postings will require us to know either Visual Basic .Net or C# .Net or both before we can get our foot in the door for a new DBA position.

Time to pick up some Sam's "Learn a language in 24 hours" books. @=)




Catadmin - MCDBA, MCSA
"No, no. Yes. No, I tried that. Yes, both ways. No, I don't know. No again. Are there any more questions?"
-- Xena, "Been There, Done That"

 

[BoulderBum]

From a development perspective, the ability for CLR stored procedures is very convenient (though T-SQL is still preferable if it will work) and the XML data type gives you a lot of power (we use it to store serialized objects and XHTML fragments validated with an XSD file to guard against XSS).

 

[sqlcasey]

I have found replication to be MUCH more stable! If your company relies on replication, that is a big deal.