We ported a database server from SQLServer 2005 to SQLServer 2008 (SP1). The new server has more Processors (4 Quadcore versus 1 Quadcore ) and more memory (4GB versus 64GB).
Processors are 2.1Ghz(new) versus 2.0Ghz(old).
The new OS is Windows Server 2008 and the old is Windows Server 2003.
The databases were transfered via backup/restore and run in native SQL Server 2008 mode (not in SQLServer 2005 compatability mode ).
Some queries on the new server run slower than before. These queries use indexed views. The queryplan looks the same on both systems.
Most of the queries perform equal.
My task is now to decide if we have a problem with our SQLServer installation, if the we have a problem with the database or if this is an expexted result.
I first want to compare performance of both
Sytems
SQLServer installations.
Is there an easy way to do this?
Has anybody had comparabele results on new SQLServer installations?
Before you check your hardware/OS, make sure you:
update statistics
rebuild all indexes
and then run your tests again. Also, are the editions of SQL Server identical? There are differences in how you have to write queries against indexed views based on the edition (Standard vs. Enterprise) of SQL Server.
Also, confirm that your indexed views are still indexed properly by selecting 1 row from them and observing the query plan. You should see only one table in the resulting plan.
The easiest way to collect performance of both systems is to run a PAL, and collect the approriate data.
PAL has extra counter sets for SQL Server. It will collect and analyse the data, and let you know where you have an issue.
PAL can be found here
http://www.codeplex.com/PAL
Also an important issu is to location of the filegroups. How is the underlying storrage system defined? It usually has a huge impact on the SQL Server. (You should talk about spindels here, and not raw size...) Make sure your database files are not sharing the resources with anyone else
Related
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.
I have to move an entire database from a SQL Server 2008 machine to a SQL Server 2000 machine.
I created a backup using Management Studio 2008, copied it to the hard drive of the 2000 box, and from withing Management Studio 2008, I choose Restore Database to the 2000 box.
I get an error message stating, "The media family on device ... is incorrectly formed. SQL Server cannot restore this media family".
If I use Enterprise Manager 2000 I get the same error.
Is there a way to move a whole database from the newer SQL server to the older?
The only thing I can think of is to recreate the whole structure and then copy data from a live database. So, create scripts that will create the tables, views, and sp's, and then create scripts to copy the data from the existing database.
As others already said there is no default way to do this. It’s just not supported. Here are more extensive details on how to do this properly and avoid any migration issues.
You need to generate scripts for structure and data and then execute these on SQL 2000 (like others already said) but there are couple things to take into account.
Generate scripts in SSMS
Make sure to check option for scripting data for SQL 2000 to avoid issues when trying to create something like geography type column on SQL 2000.
Make sure to review execution order of scripts to avoid dependency based errors
This is a great option for small to medium size databases and requires some knowledge of SQL Server (dependencies, differences between versions and such)
Third party tools
Idea is to use third party database comparison tools such as ApexSQL Diff or Data Diff
Good side is that these will take care of script execution and differences between versions
Not so good is the fact that you’ll need to pay for these after trial ends
I’ve used these two tools successfully but you can’t go wrong with any other tool on the market. Here is a list of other tools in this category.
you can't move backups from a newer version to an older, in that case you can script your database, execute it in the 2000 box, then you can use the standard data transfer to transfer any data you want
Provided you have a network connection between the machines use SSIS. Much easier and a lot less messing around.
You can use Script Generator for your database and then select in the properties form : General-> Script for server version : SQL Server 2000.
The script generator will show you things which not compatible with your server version.
I've heard you can only do it by generating the SQL statement dump from the DB administrator tool and re-running those queries on the target older database.
You can generate a script that will recreate all the objects and transfer all the data...as long as everything in the db is valid in SQL 2000. So no ROW_NUMBER(), no PARTITION, no CTEs, no datetime2, hierarchy or several other field types, no EXECUTE AS, and lots of other goodness. Basically, there's a pretty good chance it's not possible unless your db is pretty basic.
We got a similar situation. A very low-tech but handy solution is:
backup and truncate the tables in SQL 2000.
create a LINKED server in SQL 2008, pointing to SQL 2000
run a select query at sysobjects to generate a query script for insert into LINKED SERVER.table select * from table
execute query script.
Microsoft Access is a slick way to access data in a MS SQL Server backend database, but I've always had problems accessing (so to speak) large tables of data, especially when trying to toggle between results and design mode in Access.
Access gives me a number of nifty things, not the least of which is Crosstabs, but this hung connection to the server drives me a little crazy!
Does any MS Access gurus know how to optimize the ODBC connection so it isn't doing what appears to be full table scans when I just want to tweak and build my queries?
The ODBC driver will pass as much work as possible to SQL Server but as soon as you use a vba function like Nz or non-SQL Server syntax like PIVOT then the ODBC driver must pull back more data and indexes to get the work done on the client side.
As per other answer either build your views in SQL Server and link to the views or else use an Access Data Project.
NB: PIVOT queries with unknown number of columns cannot be handled in SQL Server in the same way that Access will do this natively - so if you run a pivot in Access against SQL Server data you will likely pull the whole table back. Pivot queries must be built in SQL Server using dynamic SQL techniques or else pre-saved views that have all the columns hard coded. Check out this link for one way to do this:
http://www.sqlservercentral.com/articles/Advanced+Querying/pivottableformicrosoftsqlserver/2434/
As others have said, the only way to improve performance on large tables is to have the SQL Server database engine do the work for you. A method of doing this which hasn't been mentioned is to use a pass-through query, which will enable you to keep all your code in MS Access, without having to create objects on the SQL Server:
http://support.microsoft.com/kb/303968
You will have to write SQL Server T-SQL rather than the Access dialect; however, SQL 2005 (when running in compatibility mode 90) does support a PIVOT command.
My similar problem was that the ORACLE ODBC connection hung after selecting the Link table/ODBC connection. Task manager said not responding after 10's of minutes. The connection then pings ORACLE for all available tables. I had turned on logging on the ORACLE ODBC Administrator, so it had to write all these things to the log, slowing any results by perhaps hours. The log was 60 MB one hour later, when I turned it off, then everything was fine!
To turn it off go to the Oracle installation/Network Administration/MS ODBC Adminstrator/Tracing tab and turn it OFF!
A good resource on ODBC is here: http://eis.bris.ac.uk/~ccmjs/odbc_section.html
Unfortunately Access is not able to push a lot of that work to the server, and yes, it will do huge table scans when designing queries against multiple tables or views in SQL Server.
You can build and tweak queries (views) in SQL Server using SSMS and store the views in SQL Server for a massive performance boost and still use Access for your front end.
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.
I have a SQL Server 2005 machine with a JDE DB2 set up as a linked server.
For some reason the performance of any queries from this box to the db2 box are horrible.
For example. The following takes 7 mins to run from Management Studio
SELECT *
FROM F42119
WHERE SDUPMJ >= 107256
Whereas it takes seconds to run in iSeries Navigator
Any thoughts? I'm assuming some config issue.
In certain searches SQL Server will decide to pull the entire table down to itself and sort and search the data within SQL Server instead of sending the query to the remote server. This is usually a problem with collation settings.
Make sure the provider has the following options set:
Data Access,
Collation Compatible,
Use Remote Collation
Then create a new Linked Server using the provider and select the following provider options
Dynamic Parameters,
Nested Queries,
Allow In Process
After setting the options change the query slightly to get a new query plan.
It might be a memory issue on your SQL Server machine. I recently learned that linked server queries use memory allocation by the OS. Whereas native SQL Server queries use memory pre-allocated by SQL Server. If your SQL Server machine is configured to use 90% or more of the server's memory, I would scale that back a bit. Maybe 60% is the right place to be.
Another thing to check is the SQL Server processor priority. Make sure "Boost SQL Server priority" is not enabled.
I assume you are going through ODBC for access. Remember that you are not writing native db2 queries here, but instead ODBC sql queries. If you only need read-only data, you may want to try configuring your ODBC datasource to read-only mode (if that is an option).
In a project with DB2 integration, I replaced every query via direct select or view by stored procedures calling the OPENQUERY function.
My interpretation is that SqlServer fetches the whole table before applying the WHERE conditions, whereas OPENQUERY passes the SQL statement directly to the db driver.
Anyway, performance was acceptable after the modifications.
My first thought would go to the drivers. Years ago I had to link DB2 to SQL Server 2000 and it was extremely difficult to find the correct combination of drivers and setup parameters that would work...
So maybe I'm biased because of that, but I would try upgrading or downgrading the driver or changing the setup so that the DB2 driver can run INPROC (if it's not already doing so).
I've had several issues with DB2 as a linked a server. I do not know if it will address your problems, but here is what fixed mine:
1) Enabled lazy close support and pre-fetch during EXECUTE in the ODBC settings
2) Add "FOR FETCH ONLY" on all selects
3) Query using the SELECT * FROM OPENROWSET(LinkedServerName, 'SQL Command') method