# Oracle Fusion FBDI Load Time Estimator > Source: https://netray.co/tools/oracle-fusion-fbdi-load-time-estimator > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Estimate the duration of a bulk data load from the record count, throughput, batch size and expected error rate. ## Category oracle ## Erp Oracle Fusion Cloud SCM ## Audience - Data migration lead - Cutover manager - Oracle Cloud consultant ## Tool **Kind:** calculator **Inputs:** #### Records to load **Key:** rows **Type:** number **Default:** 250000 **Min:** 0 **Step:** 1000 **Unit:** rows **Help:** Total rows across the object, such as items or on-hand balances. #### Rows per file **Key:** batch **Type:** number **Default:** 50000 **Min:** 1 **Step:** 1000 **Unit:** rows **Help:** Rows you place in each file. Choose a size that respects the file limits for your template. #### Observed throughput **Key:** rate **Type:** number **Default:** 2000 **Min:** 1 **Step:** 100 **Unit:** rows/min **Help:** Take this from a mock load of the same object, not from a guess. #### Overhead per file **Key:** overhead **Type:** number **Default:** 15 **Min:** 0 **Step:** 1 **Unit:** min **Help:** Upload, scheduling, waiting and checking per file. #### Expected rejected rows **Key:** err **Type:** number **Default:** 4 **Min:** 0 **Max:** 100 **Step:** 0.5 **Unit:** % **Help:** Share of rows rejected at validation on the first pass. #### Time to correct errors **Key:** fix **Type:** number **Default:** 60 **Min:** 0 **Step:** 5 **Unit:** min **Help:** Analysis and correction time before the reload. **Outputs:** #### Files to load **Key:** files **Expr:** ceil(rows / batch) **Format:** integer #### Initial load processing **Key:** load_min **Expr:** rows / rate **Format:** minutes #### File overhead **Key:** over_min **Expr:** files * overhead **Format:** minutes #### Rejected rows **Key:** bad **Expr:** rows * err / 100 **Format:** integer #### Correction and reload **Key:** reload_min **Expr:** if(gt(bad, 0), fix + bad / rate + overhead, 0) **Format:** minutes #### Total estimated duration **Key:** total_hr **Expr:** (load_min + over_min + reload_min) / 60 **Format:** hours **Primary:** true **Description:** Add this to the cutover plan for the object. **Chart:** #### Load duration vs records **Type:** line **X:** rows **From:** 10000 **To:** 1000000 **Steps:** 30 **Series:** - total_hr **Disclaimer:** Throughput depends on object, environment, scheduled process load and your data. Use results from mock loads, and treat this as a planning estimate. ## Content **Intro:** Cutover plans fail on load times that were guessed. This estimator turns your record count, observed throughput and expected rejections into a duration you can put in the runbook. **Sections:** #### How to use it **Body:** Enter the number of records for one object, the rows per file you plan to use, and the throughput you saw in a mock load. Add the overhead per file for uploading, submitting scheduled processes and checking results. Set the rejected row percentage and the time your team needs to analyse and correct errors. The primary output is total hours, which belongs in the cutover plan. #### The formula **Body:** Files equal rows divided by rows per file, rounded up. Initial processing is rows divided by throughput. Overhead is files times overhead per file. Rejected rows are rows times the error percentage, and the reload adds correction time plus rejected rows divided by throughput plus one more file overhead. Total time is the sum, converted to hours. It assumes loads run in sequence. #### Reading the chart **Body:** The chart sweeps record count and shows how total duration grows. It is roughly linear, but the rounding of files adds steps. Use it to decide whether to split a large object across parallel streams, or to move static data, like item master, to an earlier preload before the freeze. **Bullets:** - Preload static data before cutover - Parallelise only independent objects - Honour dependency order - Re-measure throughput each mock load #### Common mistakes **Body:** Using throughput from a small sample, ignoring downstream steps such as accounting or planning refresh that depend on loaded data, and assuming errors drop to zero on the second pass. Add a contingency to the result and compare estimates with actuals after every mock cycle. **Cta:** If you want help profiling and cleansing source data to cut rejection rates before the first mock load, we can review the extract with you. **Faq:** #### What is FBDI? **Answer:** File Based Data Import is the Oracle Fusion method for bulk loading data from spreadsheet templates that are zipped as CSV files, uploaded and processed by scheduled processes into interface tables and then the application tables. #### Can loads run in parallel? **Answer:** Independent objects can often run in parallel, subject to environment capacity and Oracle limits. Dependent objects must follow order, such as items before structures. Test parallel runs in a mock cycle before trusting them. #### Why do loads get slower than estimated? **Answer:** Common causes are shared environment load, validation of large reference data, errors needing manual correction and extra post load processes. Capture timings per step in the mock cycles and use the slowest realistic case. #### How do I choose rows per file? **Answer:** Check the file size and row guidance for the specific template in Oracle documentation, then pick a size that balances manageable error analysis with fewer files. Smaller files make errors easier to isolate but add overhead. ## Search terms oracle fusion fbdi load time, oracle cloud data load duration, data migration load time calculator, erp cutover load estimate, fbdi file size limit planning, oracle fusion import throughput, data load planning calculator --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json