June 18, 2010 at 6:01 am
Hi all,
During the day I made the migration of databases of SQL 2000 to SQL 2008.
But now I would have questions to ask.
1) The level of compatibility I have to set to 100?
2) If compatibility is set to 80 what happens?
King regards.
June 18, 2010 at 8:37 am
Hey beppe_30,
This may not fully answer your question, but as a general rule, running any database in compatibility mode is simply saying that, although you have a higher version of SQL Server installed on the server, the database will only have the features and options available to the compatibility level you've chosen for it. To my knowledge (and experience) there's never a performance penalty or gain for running in compatibility mode. You just lose features.
This is particularly helpful when consolidating databases/servers and/or you need to run a 2000 or 2005 only supported database on a SQL Server 2008 platform, for example. Now, upgrading your databases to 2008 will obviously get you the latest/greatest features, so you'd always prefer to run in native mode (the level of the SQL Server binaries installed) to get the best bang for your buck.
So to answer your original question ;-), setting your compatibility level to 80 would just be like running your database on a SQL Server 2000 platform (albeit with better tools :cool:).
HtH,
-Patrick
June 19, 2010 at 8:25 am
An issue I noticed was, if for instance you were to go to compatibility 90 from 80 you would gain the ability for TRY..CATCH against your database but would lose the ability to execute queries using older SQL ANSI joins.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
June 19, 2010 at 2:01 pm
some DMV will not work in you are connected to a down-level db.
e.g.
use TheSQL2000db
select *from sys.dm_db_index_physical_stats(db_id(), object_id(NULL), null, null, null)
will not work on a level 80 (sql2000) db if you are connected to that db!
but
use master
select *from sys.dm_db_index_physical_stats(db_id('TheSQL2000db'), object_id(NULL), null, null, null)
will work.
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
June 19, 2010 at 4:16 pm
As the others have said, you may not be able to use some of the DMVs. I also have just migrated a lot of 2000 databases to 2008 and have left many of them in 80 compatibility mode. The applications continue to function as they did prior to the migration and I gain some of the benefits of SQL 2008 (like compression).
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
June 21, 2010 at 2:38 am
Thanks to all for the answers.
June 21, 2010 at 7:54 am
You're welcome.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
June 22, 2010 at 11:12 am
...and the SSMS reports won't work either if the database is still in 80 mode.
David B.
David B.
June 22, 2010 at 2:39 pm
I have 31Gb database that I have just set compatibility mode from 2008 to 2000 by first etting to single user mode then running:
ALTER DATABASE dbname SET COMPATIBILITY_LEVEL = 80
and it has been running for 10 minutes. Is this an action that usually takes a significant time period to complete? The server is a virtual server (a test server) and was low on memory. During execution I deleted some files to free up space. The command is still executing.
is this normal? Would it be faster if i had used the EXEC sp_dbcmptlevel dbname,80?
TIA
Even as a mother protects with her life
Her child, her only child,
So with a boundless heart
Should one cherish all living beings;
June 22, 2010 at 4:00 pm
You most likely have an open connection or query window to the database!
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
June 23, 2010 at 8:35 am
It was still running today when I came in. I exited out and reran it and it completed in a heartbeat. Go figure. Maybe the low memory was an issue or perhaps someone was connected to the server, which is unlikely as it was a test server and no one here tests...har har har
Even as a mother protects with her life
Her child, her only child,
So with a boundless heart
Should one cherish all living beings;
June 23, 2010 at 8:44 am
@mothinthemachine - Every time something like that happens it's like Perry said, something somewhere has a connection open to the DB and you can't modify it while it's in use. (9 times out of 10, you have the open connection because you execute the ALTER DATABASE from within the context of the database you're attempting to alter 😉 ).
June 23, 2010 at 8:48 am
Aha! How I did it was I remoted into the server and opened enterprise manager and ran the alter table statements there. Should I have run EM on my local machine and connected to the instance from there?
Thanks!
Even as a mother protects with her life
Her child, her only child,
So with a boundless heart
Should one cherish all living beings;
June 23, 2010 at 8:54 am
MothInTheMachine (6/23/2010)
Aha! How I did it was I remoted into the server and opened enterprise manager and ran the alter table statements there. Should I have run EM on my local machine and connected to the instance from there?Thanks!
Actually, it wouldn't really matter in this case where you "physically" ran the statement from. What most likely matters in this case (unless I'm wrong about the root cause) is that you execute your statement from the context of the master database (just needs to be any other database than the one you're trying to run the ALTER statement against). No matter where you run the statement, just use the drop down box in the Query Editor (Q/A or SSMS) and select master to be safe.
HtH,
-Patrick
June 24, 2010 at 8:17 am
oh..ha ha ha.. I'm such a dork. I'll give that a try.
Even as a mother protects with her life
Her child, her only child,
So with a boundless heart
Should one cherish all living beings;
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply