2 Replies Latest reply: Feb 23, 2012 11:10 AM by Guest RSS

Downtime estimation for Export

Vishnu Singh
Currently Being Moderated

Hello All,


How to estimate or calculate downtime for source system export?


As i have two productive system (A+J) and one system (J) , and moving ahead for test migration/export.


Source Linux/Oracle-10205

ECC - running on oracle 10205 and DB size is 1.8 TB (A+J) - used db size is 1.62 TB

BI - running on oracle 10205 and DB size is 1.2 TB (A+J) - used db size is 980 GB

Portal - running on oracle 10205 and DB size is 45 GB (J). - used db size is 32 GB

Target HP-ux 11.31/Oracle 11202


These estimation is for sorted as well as unsorted export.


Looking forward for your kind response and suggestions.




  • Re: Downtime estimation for Export
    Syed Ershad Ahmed
    Currently Being Moderated

    Hi Singh,


    Downtime estimate has to be calculated by peforming an export.


    It cannot be predicted without performing a mock run.However export depends upon many factors.


    Server Configuration, Number of Cpus, Memory, Number of R3load process, Tablesplitting.


    So i would recommend you to copy the Production data on a similar hardware and perform the export.


    Kindly go through the system copy guide as all the steps are mentioned there.



    Ershad Ahmed.

  • Re: Downtime estimation for Export
    Currently Being Moderated



    Export Estimation is depend on Number CPU's, RAM and how you tune your database for export.


    Based on my experience.


    1.6 TB : with 16 cpu's, 32 gb ram and advanced tuning of oracle database (specific for migration), : It took me 6 hrs.


    The utilization of cpu was 97 % all time during our export. we have done advance tablespliting and package splitting for large tables.


    Defiinetly But this figure will be different in your case if not properly tuned.





  • Re: Downtime estimation for Export
    Surajit Das
    Currently Being Moderated

    Hello V,


    I believe 1 more parameter that you should look at is the I/O. If the I/O rate is poor , you may face a lot of issues with the write/read  time from the filesystem. Ideally you can use a simple formula for calculating the number of R3load processes you can run - ( No of processors * 3 ) . However any migration is an experiment . You can tune the migration procedure i.e increase/decrease R3load processes during the system copy by looking at the CPU consumption.


    Hope this helps a bit,