Improving Data Loading Performance from On-Premise Oracle to Fabric
Our team is currently working on a project that involves loading a substantial amount of data from an on-premise Oracle database to Fabric. During this process, we encountered performance issues related to the Oracle ODBC driver.
To ensure that the Oracle ODBC driver can meet our required performance levels, we conducted a series of tests focused on loading data to a parquet file. Our goal was to investigate the driver's capabilities rather than developing a production-ready solution.
After several attempts with various implementations and libraries, we successfully loaded the same dataset to a parquet file on the gateway server in approximately 120 seconds, using the ODBC2Parquet tool written in Rust.
However, when the load is initiated from Fabric, the same process takes between 300 seconds (with optimization of the fetch buffer size) and significantly longer without optimization. This performance discrepancy is a concern, given the substantial amount of data we need to load from our on-premise Oracle database to Fabric.
It is important to note that there is a difference between the array size and the fetch buffer size. The array size refers to the number of rows that can be returned in a single fetch operation, while the fetch buffer size determines the amount of memory allocated for storing the fetched rows. We believe that the array size, which can be set using the ODBC API function "SQLSetStmtAttr" with the attribute "SQL_ATTR_ROW_ARRAY_SIZE", plays a crucial role in the performance difference.
To rule out any potential bottlenecks, we conducted tests on the connection between the gateway server and Fabric and found no issues. Furthermore, the performance difference was also observed when loading the same table from the Oracle database to a local parquet file on the gateway server, with and without the array size parameter set. This confirms that the performance issue is related to the Oracle ODBC driver and the array size parameter, rather than any network or connectivity constraints.
Interestingly, we observed a similar performance improvement when working with the native Oracle driver. Although the method for setting the value differs, increasing the fetch buffer size resulted in a substantial performance boost.
We kindly request that this information be forwarded to your development team for evaluation. It would be highly beneficial if a feature could be implemented in the data gateway to set this attribute, potentially leading to significant performance improvements in our data loading processes from on-premise Oracle to Fabric.
1 Comment
- fbcideas_migusrNew MemberStatus added:New
Recent ideas
Allow NotebookUtils getSecret() to authenticate with Workspace Identity
Current behavior In Microsoft Fabric, notebookutils.credentials.getSecret() authenticates against Azure Key Vault using the identity of the user who executes the notebook. This behavior appli...tmihara4 hours agoNew MemberNew4Views0likes0CommentsSupport Synonyms in Fabric Warehouse
Microsoft SQL Server has a very powerful feature by the way of "synonyms." It allows users and DBAs to do all sorts of powerful magic such as rewiring objects under the hood (e.g. run the code agains...matthias-bi8 hours agoRegular VisitorNew1.3KViews18likes2CommentsExpose Refresh Warnings and Informational Messages via Notifications and API
When a Power BI semantic model refresh completes successfully, the status shows Completed, even when the refresh details contain warnings or informational messages that require attention. Please pro...Jashwanth_K10 hours agoMicrosoft EmployeeNew24Views6likes0CommentsInvoke Pipeline Task - Workspace Identity Authentication
Currently, the Fabric Data Factory Invoke Pipeline task uses the user's credentials who saved the pipeline to then authenticate to the Azure Data Factory to execute the ADF pipeline. When that user'...dzebrowitz14 hours agoAdvocate IPlanned1.8KViews61likes5CommentsFabric Pipeline should run as workspace identity
Currently, Microsoft Fabric pipelines run under the identity of the last user who modified them, which can cause disruptions when tenant administrators make changes to security policies, such as enab...pellitteris14 hours agoAdvocate IINew1.4KViews27likes3Comments