May 12, 2016 at 2:28 pm
Evening,
This might appear as a cross post, but its related to, but not a duplicate of:
http://www.sqlservercentral.com/Forums/Topic1785879-5-1.aspx
I was using the upgrade path of 2000 SP4 -> 2008R2 -> 2014
Is this the suggested way? Is there a better way?
Cheers All,
Alex
May 12, 2016 at 2:34 pm
in your other post you said "In the process of migrating a small DB to SQL Server 2014"
maybe if we know what your definition of small is....and what the db is actually used for...and what your max downtime between upgrade is.....and yadda yadda...
we can probably advise with more confidence
________________________________________________________________
you can lead a user to data....but you cannot make them think
and remember....every day is a school day
May 12, 2016 at 2:41 pm
Good Evening JL;
Small in this instance is 7GB.
Downtime wise, as long as I want really as it is to be (eventually) merged into our existing data. But wanted to get it onto "our" servers (which are 2014) - the data currently resides on a 2000 Server we have inherited through an acquisition.
Cheers
May 12, 2016 at 2:49 pm
alex.sqldba (5/12/2016)
Good Evening JL;Small in this instance is 7GB.
Downtime wise, as long as I want really as it is to be (eventually) merged into our existing data. But wanted to get it onto "our" servers (which are 2014) - the data currently resides on a 2000 Server we have inherited through an acquisition.
Cheers
"Downtime wise, as long as I want really".....is the data static then?
________________________________________________________________
you can lead a user to data....but you cannot make them think
and remember....every day is a school day
May 12, 2016 at 2:56 pm
yes static and readonly.
May 12, 2016 at 3:02 pm
alex.sqldba (5/12/2016)
yes static and readonly.
ok...so other than the "data"...which can be easily migrated to v2014 (I assume?)...what else do you need.....logins/jobs/dts packages etc etc
spose what I am really asking.....why do you think to need to "upgrade"?
________________________________________________________________
you can lead a user to data....but you cannot make them think
and remember....every day is a school day
May 12, 2016 at 3:11 pm
Nothing else. Quite literally just the database.
It should, on paper be easy - but have caused quite a challenge by applying SP4 🙁
May 12, 2016 at 3:31 pm
Oh, sorry forgot to add - upgrading because at some point it is going to be revived, made writable and brought into production - in an AG.
May 12, 2016 at 10:05 pm
Some more information: http://sqlmag.com/sql-server-2014/sql-select-steps-migrate-sql-server-2000-sql-server-2014
May 13, 2016 at 11:16 am
I was using the upgrade path of 2000 SP4 -> 2008R2 -> 2014
seems like the best way. Remember to script out any logins and jobs and if you have linked servers as well.
If it is a small list of tables and there is no RI involved you could simply script the DDL for the table creates, then use Import/Export wizard and copy the data that way. Probably isn't a small easy list of tables though. Just something to look at.
May 13, 2016 at 12:32 pm
Hi All,
Just to update and thus complete this thread for other who might be reading. I did the upgrade as discussed further up and also referenced in the link.
I had to add an extra step in as Source Server was on SQL 2000 SP3 and was not taking the installer to SP4 at all well, and rather than risk it. I built a VM with SQL Server 2000, SP4.
Then backed up from SQL2000SP3, restored to SP4 with recovery.
Then took a fresh backup after recovery upgraded the bits
Onto SQL Server 2008 R2. Another backup taken
and Finally, without issue onto SQL Server 2014
Bit convoluted but successful all the same.
Cheers all for your help!
Alex
May 13, 2016 at 12:52 pm
good to hear it all worked out ok for you.
________________________________________________________________
you can lead a user to data....but you cannot make them think
and remember....every day is a school day
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply