Printable View
Hi,
My current database is on an Alpha Server. (Digital Unix).
I need to move it to an HP-Ux server. The Oracle Versions remain the same which is 8.1.6
Can someone tell me how to relocate the databases the OS being different. Do we need to recreate/migrate the database or can we simply copy the datafiles and recreate the controlfile.
One thing for sure we cannot do an Export/Import because it is a production database whose size stands to around 300GB.
Thanks
well since it is a different OS you cant just take the files and copy them over or it wont work.
ok.could you suggest then what would be the best way to carry out movement of the database then.Any idea .
different platform, export-import
Hi Pando,
Is export / import the only viable alternative. Can't the data be moved by any other means. Why i am saying this is because the database is around 300 gigs, as result of which the exp/imp will take ages and this being a oltp production database there'll be constant changes happening, in that case there's going to be inconsistencies. isn't it.
hmm you must be joking? you pretend migrate platform and not stopping the database...?
if you want go faster use db link or copy
No, actually the idea is to shutdown the database for 3 hours and get over with the job withing that time. Hence i don't think it would be possible to be over with the exp/imp in 3 hours. Yes i could use Copy or DBlink mode by putting the database in Read-Only Mode. That would be the only feasible state in this case.
Thanks for the info Pando.
well even with db link I doubt it very much you can migrate 300gb in 3 hours
In that case what do you think should be the best approach method. any suggestion ? we cannot afford more that 3 hours downtime.
Set up DB on ur HP UX as the one one on our ** Digital Unix **Quote:
Originally posted by dsuva
In that case what do you think should be the best approach method. any suggestion ? we cannot afford more that 3 hours downtime.
COPY the data using COPY command & and you can do simulateously in N sessions..when data is copied switch over the DBs and change tns entries in Global Tns path..will that require 3 hour dowtime?
Abhay.
First off, migrating a 300G database in three hours is quite a challange. Even if you could move the data that fast (which you can't), that wouldn't give you any time to perform any checks on the imported data. Pure suicide.
That being said, somebody in this forum came up with an idea to use Quest Shareplex and setup replication between two different platforms. I think I remember seeing that it worked and the switchover time was minimal. However, Shareplex is not cheap, especially if you are looking at using it for a limited time.
In 10g you can clone via RMAN from one OS platform to another. And RMAN cloning is the fastest method!Quote:
Originally posted by marist89
First off, migrating a 300G database in three hours is quite a challange. Even if you could move the data that fast (which you can't), that wouldn't give you any time to perform any checks on the imported data. Pure suicide.
That being said, somebody in this forum came up with an idea to use Quest Shareplex and setup replication between two different platforms. I think I remember seeing that it worked and the switchover time was minimal. However, Shareplex is not cheap, especially if you are looking at using it for a limited time.
Just out of curiosity...you talking about OS copy or SQL copy?Quote:
COPY the data using COPY command & and you can do simulateously in N sessions..when data is copied switch over the DBs and change tns entries in Global Tns path..will that require 3 hour dowtime?
Also, I'm thinking there's no way he's going to be able to get that amount of data copied over and up and running in three hours. Think about it gentlemen a 100 gig per hour. Your managemnt needs to step back and rethink thier acceptable down time. Geeesh you don't even have any room for a fudge factor with that time.
What I would suggest in this case since time is of the esscence (for switch over purposes), would be to create a standby database from your existing prod on your new HP box. Then when it's time to push the button simply let it fail over to the new box. That way depending on the way you've setup your standby your down time could be very minumal.
Thoughts??
Oracle Standby across platforms? I'm not sure that would work. Maybe a logical standby. Definitely replication would work, but there are limitations on replication...
OS has to be the same for physical standby database. And this being 8.1.6 system, logical standby is not an option (and btw, logical standby requires same OS on both sides too).
What is your new hardware configuration and Storage type? you can do only 300gb data move in 3 hours, but it is depending up on your hardware conf.
Asa generic point, which may be obvious, try and get as much done as you can prior to the "live" switchover. This means users, tabelspaces, tables, ndexes, contraints, grants etc.. sequences will have to be reset at the time of switchover, but that's not too much of a challenge.
If you can find data that is static, then migrate that beforehand. For data that will only change "a little" you can consider auditing changes to the tables, migrating the table data, then migrating changes only at the time of switchover.
Also, you'l want al your constraints disabled and indexes unusable at the time you switchover the system. Indexes can be rebuilt parallel & nologging in multiple sessions (for each table, rebuild all the indexes at the same time using multiple sessions to gain the advantage of having table data in the block buffers). If confidence is high, then constraints can be reenabled with the novalidate option.
Oh also, for the love of God do at least two test runs prior to the live switchover, with the same people running the process as for the final switchover, and thoroughly document the timings, processes, results, and get the user community to sign something to say that the result is correct.
Then, stick to the documented procedure for the final run. Partly, it'll tell you whether you can make the three hour window, and whether you really are going to in the live event.
Quote:
Originally posted by jmodic
OS has to be the same for physical standby database. And this being 8.1.6 system, logical standby is not an option (and btw, logical standby requires same OS on both sides too).
ohhh yea that's right I forgot about that. Good call!
Quote:
Originally posted by Chandra
What is your new hardware configuration and Storage type? you can do only 300gb data move in 3 hours, but it is depending up on your hardware conf.
Hmm I wonder what hardware can do "platform swith"
Don't know your hardware conf and bandwidth you have but I don't think you can export then move and import the database in the new machine with in your 3 hours window. How about testing after the mogration As slimdave mentioned ask the users to sign for the response time and accuracy of the results. It is very important to check in the Migrations. I have a very bad experience with response time after the migration.
vbadba
Hi pando,Quote:
Originally posted by pando
Hmm I wonder what hardware can do "platform swith"
If you use db link or copy with multiple sessions and if you have slower disks that will be a problem
hi all,
we are using a HP Superdome server (24 CPU 32 GB RAM) and the storage is on emc SAN.
We currently migrated a database on the same server of 225GB in 4 Hours using PL/SQl scripts with mainly using db_links . So i am being a bit optimistic that using copy i might just be able to achieve the result on time.
the scripts are all tested, so the factor of any in-consistency creeping in is very minor, but still we do have regular verification scripts which are run after the migrations.
errrr export / import 300gb in 3 hours...? when that happens my dream will come true :oQuote:
Originally posted by vbadba
Don't know your hardware conf and bandwidth you have but I don't think you can export then move and import the database in the new machine with in your 3 hours window. How about testing after the mogration As slimdave mentioned ask the users to sign for the response time and accuracy of the results. It is very important to check in the Migrations. I have a very bad experience with response time after the migration.
vbadba
what I mean is some hardware clonign mechanism, like snapshots (but AFIAK that is for same OS)Quote:
Originally posted by vbadba
Hi pando,
If you use db link or copy with multiple sessions and if you have slower disks that will be a problem
we are using a HP Superdome server (24 CPU 32 GB RAM) and the storage is on emc SAN.
We currently migrated a database on the same server of 225GB in 4 Hours using PL/SQl scripts with mainly using db_links . So i am being a bit optimistic that using copy i might just be able to achieve the result on time.
the scripts are all tested, so the factor of any in-consistency creeping in is very minor, but still we do have regular verification scripts which are run after the migrations.
db link + insert /*+ APPEND */ is faster than copy
MAN, you can do it with in 3 hours.
'specially with the tables set to nologging, ofcourseQuote:
Originally posted by pando
db link + insert /*+ APPEND */ is faster than copy