Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
andriancruz
Starting Member
38 Posts |
 Posted - 2010-10-21 : 23:04:06
|
| Hi guys,I'm planning to migrate our database from 2000 to 2005. currently, my database setup has a log shipping, DTS and scheduled jobs. if i migrate my database to 2005 version, i can achienve this settings without do anything? i mean just to backup and restore the db. how about the master & msdb database. i can still restore this system database to sql 2005 version? so, no need for me to do some settings. how about some port, the port using of sql 2000 is the same port use by 2005? if you guys know any documentation regarding database migraratio from 2000 to 2005, pls. let me know, so i can read as reference.Thank you in advanced for the help guys.Regards, |
|
|
russell
Pyro-ma-ni-yak
5072 Posts |
Posted - 2010-10-21 : 23:23:09
|
| are you planning to do an in-place upgrade, or are you migrating to a new server with SQL 2005 installed?Also, why not go straight to SQL 2008?As for your dts packages, depending on what they do, they may or may not work. We kept a SQL 2000 box around for more than 2 years after an upgrade to 2005 because there were a few hundred dts packages.Don't bother restoring a 2000 master to 2005. Just build the 2005 instance (assuming this is a migration) then restore your user databases. As for msdb, I'll script out the jobs that I want to move to the new server and apply the scripts.You do need to have a look at SSIS. I am one of the few who loved DTS. I spent years with it and got good at it. SSIS is a good bit different, but not that difficult to learn at all. If you have a lot of DTS packages, another option is to save 'em all as binary files and put 'em on an app server that you install the SQL 2000 client tools (dtsrun.exe in particular) to run em til you can re-write them as SSIS packages.Again, I can't fathom a reason to migrate to 2005 now. Go straight to 2008.Oh yeah, and of course, the default port # is the same: 1433 but you can change it if you need to |
 |
|
|
andriancruz
Starting Member
38 Posts |
Posted - 2010-10-21 : 23:39:05
|
| Hi Russell,I think the reason why we choose 2005 is because of the cost.I believed, we doing it in a new server.Thank you again for the reply, its very helpul to me. :) |
|
|
|
russell
Pyro-ma-ni-yak
5072 Posts |
Posted - 2010-10-21 : 23:42:54
|
You're welcome. Be sure to post back with any other questions as you continue planning your migration.More planning = less problems  |
|
|
|
russell
Pyro-ma-ni-yak
5072 Posts |
Posted - 2010-10-21 : 23:48:43
|
| saw your edit. cool. you will enjoy the advantages and new features of sql 2005 over 2000.also, i forgot to say, I never did log shipping on sql 2000, so I can't answer that part, but i am sure you will need to recreate that on the new server.migrations are a lot of work but really fun -- they make us look important lol. |
|
|
|
andriancruz
Starting Member
38 Posts |
Posted - 2010-10-21 : 23:56:40
|
| Thank again Russell, your the best |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2010-10-22 : 02:01:03
|
| http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=138230 - it relates to upgrading to SQL2008, but as is indicated in that thread: most also relates to SQL2005 migration.I'm with Russell on moving to SQL2008. The "cost" of changing the application, performing a complete regression test, and so on, is the same whether you move to SQL2005 or 2008 and you would have the benefit of a) not having to do another regression test / migration soon-ish and b) the opportunity to use the SQL2008 features.You mention cost, and you obviously need Log Shipping, but we moved from Enterprise SQL 2000 to Standard SQL 2008 because the features we needed (principally access to large amounts of memory) were in Standard version, which was relatively cheap (in our case, YMMV of course ... but maybe a check on Features [I expect you've already done that though]).You may want to perform some of your regression tests against a Trial version of SQl2008 (and, for example, use the SQL 2008 Database Advisor) to find & fix any issues that would come to light in SQL 2008 whilst actually deploying against SQL2005 if you must. |
|
|
|
|
|
|
|
|
Database Migration 2K - 2005