EBS migration to new servers

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

EBS migration to new servers

satish
Dear Erman,

EBS version:R12.1.3
database version:11.2.0.4

While migrating EBS to new servers with same os version ...can we perform the database migration first and then after few days,go with application migration?

Is there any challanges with above process.From your experience,Can you share the best methods we can follow to reduce the downtime

Thank you
Reply | Threaded
Open this post in threaded view
|

Re: EBS migration to new servers

ErmanArslansOracleBlog
Administrator
Yes you can.
You already mentioned that the OS versions will be the same.
So, only the hardware will be changed..
I don't see any challenges in this method..

Reply | Threaded
Open this post in threaded view
|

Re: EBS migration to new servers

ErmanArslansOracleBlog
Administrator
As for the reducing the downtime, you will choose the right method and implement it properly.
Build a DR environment (synched with dataguard and rsync) on the new servers and switchover to that environment. This method will minimize your downtime.
Sri
Reply | Threaded
Open this post in threaded view
|

Re: EBS migration to new servers

Sri
In reply to this post by ErmanArslansOracleBlog
Dear erman,

First we will migrate the database.We will use rman level 0 backup to perform this migration.do we need to shutdown the application until database migration is done? to avoid users to enter any transactions in source database.

Thanks for the support
Sri
Reply | Threaded
Open this post in threaded view
|

Re: EBS migration to new servers

Sri
Thanks for the update and your valuable suggestion

Just wanted to know in case if we are not using dataguard method,Then do we need to shutdown the application until database migration is done? to avoid users to enter any transactions in source database.

Reply | Threaded
Open this post in threaded view
|

Re: EBS migration to new servers

ErmanArslansOracleBlog
Administrator
Yes.

What you will do is as follows;

You will create a clone database in the target env.
Then you will keep it synch with the source by recovering it using incremental backups.. ( in a loop .. maybe once per day.. till the planned migration time)
Once you reach the planned migration time, you will stop your application.
Then you will synchronize your target db once again -- the last time (while the apps tier is stopped)
Once your target db is in synch with the source , you will shutdown your source db and open your target db
As the last step you will configure your application tier to connect to the target db and startup the application services.
Sri
Reply | Threaded
Open this post in threaded view
|

Re: EBS migration to new servers

Sri
Erman,

Many thanks for the information.It really helps

Thank you for all the support.
Sri
Reply | Threaded
Open this post in threaded view
|

Re: EBS migration to new servers

Sri
Dear erman,

If I am not wrong,we cannot use rman duplicate for this migration right?as the duplicate database will have unique dbid.

Thank you
Reply | Threaded
Open this post in threaded view
|

Re: EBS migration to new servers

ErmanArslansOracleBlog
Administrator
You can.
you will migrate your database and configure your application to connect to this migrated database.
Reply | Threaded
Open this post in threaded view
|

Re: EBS migration to new servers

satish
Dear Erman,

Could you please provide any references to implement this.Do we have to build both new application and database to perform this migration and to reduce the downtime

As for the reducing the downtime, you will choose the right method and implement it properly.
Build a DR environment (synched with dataguard and rsync) on the new servers and switchover to that environment. This method will minimize your downtime.


Thank you
Reply | Threaded
Open this post in threaded view
|

Re: EBS migration to new servers

ErmanArslansOracleBlog
Administrator
Downtime depends on the method..
Migrating DB and App tier at the same time is a choice..

If you can migrate the Database and apps tier at the same time, during the same downtime in parallel, then it is ofcourse better to migrate them at the same time.

These kinds of things all depend on the migration method.

There are My Oracle Support documents for these kinds of migrations;

Also check my blog by searching the keyword "migration"
I have written several real life stories about this subject.

MOS documents:

R11i / R12: Oracle E-Business Suite Upgrades and Platform Migration (Doc ID 1377213.1)
Application Tier Platform Migration with Oracle E-Business Suite Release 12 (Doc ID 438086.1)

Document 1070033.1 Business Continuity for Oracle E-Business Release 12 Using Oracle 11g Physical Standby Database

Document 341437.1 Business Continuity for Oracle Applications Release 11i Using Oracle Real Application Clusters and Physical Standby Database

Document 729309.1 Using Transportable Database to migrate Oracle E-Business Suite Release 11i Using Oracle Database 10g Release 2 or 11g Enterprise Edition                                

Document 734763.1, Using Transportable Database to migrate Oracle E-Business Suite Release 12 Using Oracle Database 10g Release 2 or 11g Enterprise Edition

EBS R12 - Migrating the Oracle E-Business Suite Database to Oracle Exadata Database Machine Using Transportable Tablespaces

EBS R12 - Using Transportable Tablespaces for EBS Release 12 Using Database 11gR2 [1311487.1]

EBS 11i - Using Transportable Tablespaces to Migrate Oracle E-Business Suite Release 11i Using Oracle Database 11g Release 2 Enterprise Edition [1366265.1]                                
Oracle E-Business Suite Rapid Clone Source platform must be Linux x86-64
Document 230672.1 Cloning Oracle Applications Release 11i with Rapid Clone*
Document 406982.1 Cloning Oracle Applications Release 12 with Rapid Clone*
Document 559518.1 Cloning Oracle E-Business Suite Release 12 RAC-Enabled Systems with Rapid Clone
Oracle E-Business Suite Install and Cloning Best Practices

RapidClone from single node to Exadata and then convert to RAC is supported if the source system meets the requirement 'Source platform must be Linux x86-64'