I'm looking for the benefits of upgrading from SQL Server 2000 to 2008.
I was wondering:
What database features can we leverage with 2008 that we can't now?
What new TSQL features can we look forward to using?
What performance benefits can we expect to see?
What else will make management go for it?
And the converse:
What problems can we expect to encounter?
What other problems have people found when migrating?
Why fix something that isn't (technically) broken?
We work in a Java shop, so any .NET / CLR stuff won't rock our world. We also use Eclipse as our main development so any integration with Visual Studio won't be a plus. We do use SQL Server Management Studio however.
Some background:
Our main database machine is a 32bit Dell Intel Xeon MP CPU 2.0GHz, 40MB of RAM with Physical Address Extension running Windows Server 2003 Enterprise Edition. We will not be changing our hardware. Our databases in total are under a TB with some having more than 200 tables. But they are busy and during busy times we see 60-80% CPU utilisation.
Apart form the fact that SQL Server 2000 is coming close to end of life, why should we upgrade?
Any and all contributions are appreciated!
Besides all the features MatthewPK mentions, I also really like:
Common Table Expressions (CTE) (which I find extremely helpful) - see Using Common Table Expressions, SQL Server CTE Basics or SQL Server 2005 Common Table Expressions for more details
Ranking functions like ROW_NUMBER, RANK, DENSE_RANK and NTILE - see Ranking Functions (on MSDN) or New Ranking Functions in SQL Server 2005 for more details
OUTPUT clause in SQL statements to output information about e.g. rows you've deleted with the DELETE statement, or updated with your MERGE statement - see the SQL Server Books Online for more details.
I'm taking care of an old SQL Server 2000 solution, and boy, how many times have I missed those features!
There are a number of reasons to make the migration, I'm sure.
My favorites are:
New DATE datatype (no more having to format strings to compare timestamped dates)
New Spatial Data types (geometry, geography)
New MERGE statement is great for upserts or any other "if exists" type logic
FILESTREAM gets you out of the blob problems (enforced DB integrity on filesystem directories!)
IMHO, from a developer's perspective, the most important upgrade is the TVP
The only shortfall I've personally encountered is that I had to rewrite my DTS packages to SSIS packages (but I think SSIS is great... just more work)
From a purely practical perspective, the most compelling advantages for me are several powerfull TSQL commands that are not available in 2000, e.g. PIVOT/UNPIVOT, and the addition of the intelligent syntax expansion to the 2008 Management Studio that made working with this tool substantially more productive.
Related
We're building an application for a client with the assumption that they'd be upgrading to a minimum of SQL Server 2005 from SQL Server 2000. We're finished our application, built on 2005, and are ready to integrate. Turns out that they're not going to upgrade their DB server.
So, now we're stuck with trying to sort out what will break.
We don't have access to SQL Server 2000, so we can only change the compatibility of the database to 80.
Aside from complete testing and reviewing every stored procedure (and I've read that changing the compatibility mode is not foolproof - so testing wouldn't be bombproof), is there any other way to determine what will break? Any tools out there? Scripts?
Edit
I'd prefer not to try restoring this onto their production DB server to see what errors are spit out, so that's not a good option.
Suggest you look in Books online for the page that spells out the differences between the two and look for those things. YOu can look over the list and then search for some new keywords in the table where the sp text is stored. That will give you a beginning list.
#rwmnau noted some good ones, I'll add two more
SQL Server 2000 does not have varchar(max) or nvarchar (max), use text instead.
SQl Server 2000 also does not have SSIS - if you are creating SSIS packages to import data or move data to a data warehouse or export data, all of those need to be redone in DTS.
Also it looks to me like you can still download the free edition of SQL Server 2000:
http://www.microsoft.com/downloads/details.aspx?familyid=413744d1-a0bc-479f-bafa-e4b278eb9147&displaylang=en
You might want to do that and test on that.
I wouldn't be worried about your ANSI-SQL (setting the database compatibility level should take care of most of that), but there are a few big features you may have used that aren't available in SQL 2000 (there are many more, but these are the ones I've seen that are most popular):
Common Table Expressions (CTE) - http://msdn.microsoft.com/en-us/library/ms190766.aspx
TRY...CATCH blocks
CLR-integrated stored procs
Also, though you shouldn't be, any selections directly from system tables (objects that begin with "sys" or are in the "sys." schema) may have changed dramatically between SQL 2000 and 2005+, so I'd see if you're selecting from any of those:
SELECT *
FROM syscomments --I know, using a sys table to figure it out :)
WHERE text like '%sys%'
Also, it's worth noting that while extended support is available for a hefty fee, Microsoft has officially ended mainstream support for SQL 2000, and will end extended support in the near future. This leaves your client (and you) without any updates from Microsoft in the case of security patches, bugs, or anything else you discover. I'd strongly encourage them ot upgrade to a newer version (at least 2005), though I suspect you've already been down that road.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Has anyone used all three of these databases? What are your experiences with them? PostgreSQL looks pretty tempting for a project but I'm curious to learn more about it (We're a .NET Shop). I've also heard of quite a lot of people being satisfied with DB2.
I work in a very large organization that uses DB2 primarily on Linux (Red Hat). We have a number of large databases and have investigated moving to other RDBMS solutions, such as Oracle and SQL Server. I did a lot of work on the SQL server end of that.
We found that SQL server performs much better and requires less tuning than DB2, especially when tables frow larger than 1M records. HADR is also difficult and bulky, to say the least.
We found many differences between DB2 and SQL Server, and too many to list here. I was responsible for doing a lot of the engineering behind code conversion from one platform to another, and can't say I found anything in DB2 to be superior to SQL server, but did find many things I liked better about SQL server. Here are some off the top of my head:
Better selection data types in SQL Server, such as MONEY and SMALL MONEY.
Mixed character encoding in SQL Server. Some columns can be ANSI and others UNICODE (char and nchar, respectively). Setting this up in DB2 is neither straightforward nor easy.
Better tools in SQL server, mainly SSIS for ETL (As opposed to the insanely priced IBM Data Stage).
SQL server has more forgiving syntax. For example, you don't need semi-colons everywhere. Maybe just a personal preference but I found it much easier to code in T-SQL.
Many advanced features seem to work better in SQL server. For example, SQL server lets you do page-level compression, where DB2 is limited to row-level compression.
It was easier to tune SQL Server queries with the SQL Server IDE
There are more, but honestly I suggest that anyone who is considering one over the other should set both up and spend some time working with both systems. Right now it seems like SQL server is a better overall solution, but DB2 may one day take the crown.
Lastly, when dealing with data warehousing, SQL, SSIS, and SSAS made a much better solution than InfoSphere, DataStage, and DB2. I could write a whitepaper on it, but my suggestion here is to set it up on your own and spend a week or to playing with each solution. Microsoft's solution here was faster and cheaper than IBM's. I don't know of any other basis upon which to make a decision.
Platform shouldn't be an issue since databases generally run on their own machines, but there are always those "no microsoft!" and "no linux!" shops around. It's a shame, really. I'd recommend SQL server.
As a DB2 person, I can offer a few details about what you could expect from running DB2 for Windows and developing .NET applications for it. The following details were current as of version 9.7, which was released in June 2009.
Drivers and API support for just about any Windows programming language and IDE, including .NET and Visual Studio extensions
A no-cost, production-ready database engine (Express-C) that has no database size limit and is the least restricted when compared to Oracle Express and SQL Server Express
A self-tuning database engine for Windows that automatically handles the sizing of several memory buffers that are critical to good performance
Rock-solid support for XML as a native datatype, handled by its own dedicated query engine that is optimized for XML's hierarchical nature. Queries can access any combination of XML and tabular data with any combination of SQL and XQuery expressions
Avoid microsoft like the plague. Always push to use PostgreSql even on windows, way better support for developing applications for e.g. Java/Python and still has good support in .NET. Also of course is completely free which given the current license fees for SQL Server is nothing to be sniffed at even if you're a multi-million dollar company.
For the cost of 1 SQL Server license you are going to save £30,000 (say $40,000) or more - buy better hardware to run Postgres on and still have a net benefit.
As far as performance, really if this is such a massive issue we should not be using either DB2, SQL Server or Postgres anyway. The difference between the three is negligible for their design purposes.
Edit: On the .NET integration, actually this is really poor in SQL Server anyway, it does have more features than Postgres/DB2 admittedly but it's not really hugely advantageous over SSIS or stored procedures. I could see the main use case in my work as accessing classes and functions from a CLR .dll but then you're implementing logic in the database which may or may not be a good idea for you.
If you're a .NET shop, and are either using a small database (i.e. Sql Server Express), or have the money for the full SQL Server, use it. SQL Server will perform better than PostgreSQL for most actions, and about the same as DB2.
PostgreSQL is fantastic if you need multi-platform support, are Linux-based, or need a free product that's not Microsoft.
I haven't used DB2 in over 10 years, other than running an in-house performance test vs. other databases (where it was about the same for a transactional database as Oracle/SQL Server, where were better than MySQL, PostgreSQL, etc).
If you are a .net shop stay with SQL Server.
Using any other database platform would require non-Windows to get the best out of it. On Windows, SQL Server is king simply because MS own both OS and SQL Server (Like Oracle/Red Hat).
One of our clients is upgrading their servers because the old machines can't handle the load of the database anymore. They have been using sql 2000 for the last 6 years and the db has grown to hold a few GB of data.
Will it be worth upgrading to 2005 or 2008? What are the major benefits of the new versions compared to 2000?
In addition to the CLR integration mentioned by Galwegian, the main pluses for me are:
there is much better XML support in 2005
Common Table Expressons
Another difference to note is that instead of the DTS packages that you would have been used to Sql 2005 uses Integration Services, which while similar is a whole different ball game.
Depending on what edition of SQL Server you are using, SQL 2005 have less restrictive hardware limitations/caps than corresponding editions in SQL2k.
For example, SQL 2000 Standard Edition won't use more than 2Gb (in practice 1.7Gb) while SQL 2005 Standard Edition is not capped (allows up to OS max).
See:
http://msdn.microsoft.com/en-us/library/aa933149(SQL.80).aspx
...and...
http://www.microsoft.com/sqlserver/2005/en/us/compare-features.aspx
So: if you're running standard edition + your SQL Server 2000 instance currently uses ~1.6Gb RAM + your server has 3Gb or more physical RAM then it is probably worth upgrading just for the benefits increased memory usage brings... (more cached table data, indexes, plans etc)
I you are planing to upgrade from SqlServer 2000 I would skip 2005 and go directly to SqlServer 2008
It has all the features of 2005 plus some extras (for example an option to pass a table variable as a parameter to stored procedure, new date types, spatial data handling,etc.)
You can refer to Advantages of MS SQL Server 2008 over MS SQL Server 2005 question for the comprehensive list of features
EDIT
I can see that the question has been updated and now SqlServer 2008 is included in the question.
MS SQL 2005 and 2008 have a lot of hyped technologies, one of them is the ability to stuff CLR code into Stored Procedures. DON'T DO THIS!
Another "feature" is the ability to expose your database as WebServices, yet again; DON'T DO THIS!
A third feature is the ability to use "notifications" from your database and into your application layer, yet again; DON'T DO THIS...!
You database is a bucket and it should "store data", period. A lot of the features Microsoft put into 2005 and 2008 I feel sure they did because they wanted to complicate the usage of O/RM libraries which abstracts away the actual database vendor so that people can change databases as they wish. Then by adding a lot of "stupid features" which goes against every single Best Practices we've learned about databases since the 70s they managed to create a new lock-in which removed the vendor locks by making people use stuff they really shouldn't use anyway...
A part from that there might be a lot of cool features in 2005 and 2008 (like one mentioned here; support!) and things like optimalizations, bugfixes and such. But be careful so you don't start using stuff that craps down your app and makes it impossible to use best practices and locks you in... :(
The main benefit is CLR integration to be honest - it allows you much more flexibility in the way you code your database, giving you the option of including procedural C# or VB.NET in your procedures instead of set-based T-SQL.
There are some new features that are useful, like service broker for example, but in performance terms you aren't going to see huge improvements in moving from 2000 to 2005. You would be much better off a) tuning your DB and b) investing in new hardware.
I think that SQL Server 2000 is no more supported by Microsoft. If I'm wrong, it will be soon...
Separation of users and schemas is another goodie. In SQL 2005, if you want schema separation by logical/functional area or similar rather than by user in your database, you can create schemas such as "hr", "sales", "accounting", "production" and then create user tables under the respective schemas.
In SQL 2000, the schema name was identical to the table owner/creator.
Online index rebuilds are a nice feature to have. I think it might only be an option in Enterprise edition though.
Could somebody please name a few. I could given time, but this is for somebody else, and I'd also like some community input.
Some differences:
CLR (.NET) stored procedures
SSIS instead of DTS
Management Studio instead of Enterprise Manager, with more functions (2008 version is even better)
VS integration
better replication
SMO and AMO (extensions to handle the server from applications)
table and index partitioning
XML as data type
XQuery to handle XML data type
Service Broker
Notification Services
Analysis Services
Reporting Service
I have now these ones in mind. There are a lot of other small nice stuff, but I cannot name more.
Also, Common Table Expressions and exception management in TSQL. Very useful.
Two things make it much better for me:
1 - Great XML support.
2 - Partitioned Tables. No more multiple-tables and views - just define your partition schema and you can easily manage HUGE tables with far improved performance.
Snapshot Isolation
Also known as readers don't block writers.
The Data Type varchar(MAX)
In SQL Server 2000 and SQL Server 7, a
row cannot exceed 8000 bytes in size
... To solve this problem, Microsoft
introduced the VARCHAR(MAX),
NVARCHAR(MAX), and VARBINARY(MAX) data
types in SQL Server 2005. These data
types can hold the same amount of data
BLOBs can hold (2 GB) and they are
stored in the same type of data pages
used for other data types. When data
in a MAX data type exceeds 8 KB, an
over-flow page is used.
From http://www.teratrax.com/articles/varchar_max.html
CLR stored procedure support
Better clustering/replication facilities
Schemas - Okay, 2000 has owners, but they can be a real pain to get permissions right on.
Something very important is the TRY CATCH statement - SQL2005 supports such statement while SQL2000 does not.
sample:
BEGIN TRY
-- Generate divide-by-zero error.
SELECT 1/0;
END TRY
BEGIN CATCH
-- Execute custom error retrieval routine.
END CATCH;
It depends if you're talking about just the DB engine or the product as a whole. SQL Server 2000 didn't have anything like Analysis services and Reporting services. As for the DB engine - if you use it for a simple application, I don't think you should bother. Also, I think the SQL Express edition introduced in 2005 became valuable for one-man-show companies and investigation/testing small projects
SQL Express has larger database capacity than the previous MSDE product (4Gb vs 2Gb), so it's great as Slavo said for testing and small apps. SQL Server 2005 is updated via Microsoft Update, which is good or bad depending on your point of view.
The PIVOT/UNPIVOT operators have been a big win for me.
PIVOT rotates row-based output into columns, which is a huge help in a lot of our reporting needs. We had to roll our own functions for PIVOT prior to SQL 2005.
It seems like the generation of SQL scripts from the SQL Server Management Studio is terribly slow. I think that the old Enterprise Manager could run laps around the newer script generation tool. I've seen a few posts here and there with other folks complaining about the speed, but I haven't seen much offered in the way of alternatives.
Is there a low-cost/free tool for scripting an entire SQL Server 2005 database that will perform better that SSMS? It would be hard to do worse.
See the Database Publishing Wizard that is part of the SQL Server Hosting Toolkit. It generates a single SQL file for both schema and data.
We are using the tools by RedGate which I personally find very useful in any aspect of work with databases. For scripting I would recommend the SQL Compare (you need a pro version for scripting). The SQL Compare is a must have for deploying schema changes from the deployment DB to the live Server and a real timesaver.
Those tools are not free but I think they could save you money in a long run
What kind of scrpt generation are you talking about now?, generating create scripts from the objects in the database is way faster in SSMS compared to EM.
But if you are running an select or something that gives you lots of rows in the grid, it is crazy slow.. like scripts generating inserts statements of all rows in an table, if you got lots of data, it is almost not doable.
I don't know what is "terribly slow" for you, but I have a decent performance with SQL 2005 Management Studio. In either case, RedGate products are very cool. Unfortunately they are not free.