Oracle Data Integrator (ODI) Reviews

Our primary use for this solution is a data integration and merging tool. It easily connects to many databases like MySql, SQL Server, etc. It's completely user-friendly. We can easily manage packages, ETL, and Procedures.

Before adopting this solution we used to work hard. We now feel better because our manual work is completely over. 

We can easily create ETL processes and schedules. We can check logs on a daily basis. It handles multiple routines very smartly.

Overall the product is fine, but sometimes its reports unknown errors while we compile ETL scripts.

My impressions are good in terms of the stability.

I find that the scalability of this solution is good.

Interaction with technical support is not my area.

Before this solution, we were using SQL Server.

I think that the initial setup is amazing.

We used a completely internal team to implement this solution. 

We found that the cost compared to other integration tools is a little high, but the solution works great.

We evaluated SQL Server prior to choosing this solution.

We use ODI to integrate data from the OLTP database to the data warehouse. The source database systems including Oracle, MySQL, flat files... Our business background is OTA and the total data is about 100T.

In our DW/BI solution, ODI is the main tool to integrate the data as a daily batch. Besides loading data, we do most of our transformations in ODI. ODI is quick to use.

Most of the functions are very straightforward, like the data model, mapping, package, and load plan. Thus, a new user could get started very fast. 

The ODI scheduler for agent sometime fails with no sign, which impact the ETL solution severely.

The property window in the ODI studio always does not refresh as it should. 

Sometimes, the mapping or package automatically gets edited.

The stability of the ODI studio is not strong enough. It crashes occasionally. 

Informatica and SSIS are also good ETL tools besides ODI.

The installation of the client tool: ODI studio is easy.

Basically the ETL tools is determined by the database.

It is a clever integration tool to extract data from every possible source, and it can transform the source data to a format the targets can handle. It is suitable for data warehouses and data migrations.

We replaced many manual actions and tasks with mappings in Oracle Data Integrator, and created schedules, and then used SOA Suite services to automatically transfer large data amounts between different systems.

The integration between the Oracle Repository and versioning tools like TortoiseSVN.

We’ve used 11G for four years, and 12.1.3 for two years.

One of the benefits of it is the usage of the principle ‘write once, execute anywhere’. You set up the architecture in the topology within Oracle Data Integrator.

We've experienced no issues with performance.

We haven't needed to scale it yet.

We haven't needed to use it yet.

Previously we used Oracle Warehouse builder, and custom made PL/SQL data warehouses. We’ve chosen Oracle Data integrator over other solutions because it is the successor of Oracle Warehouse builder, and Oracle Data Integrator provides a more structured working-method, and the data warehouse is easier to maintain.

The installation is rather straightforward, with the available documentation it must be possible to do the installation by yourself. You must have sufficient knowledge of Oracle Data Integrator to make the correct decisions during the creation of the architectural setup.

We used an in-house team but hired interim experts, and created a team with combined knowledge levels, from rooky to expert. The initial setup is rather complex, and needs an experienced architect to make the correct decisions. The change of success is highly depending on the decisions that are made during the setup.

I have no info on the ROI or the licensing, but I know the license costs are high, so Oracle Data Integrator is only suitable for the larger companies.

To benefit the most of Oracle Data Integrator it is important to assemble a team with the experience to make the project a success.

An area for improvement would be the lack of SQL compatibility - ODI has no ability to interact with SQL unstructured types and data types.

ODI is a proven product with high performance in large-scale data processing.

ODI comes included when buying the cloud version of the Oracle database license.

ODI is very friendly to those who have been traditionally writing a scale PL/SQL. It has lots of connectors to many different sources, although the target databases it supports are relatively limited compared to Informatica. It's also easier to understand, very developer-friendly, and has a big forum community and lots of documentation for support. I would rate it as nine out of ten.

I have found most of the Oracle Fusion middleware and hardware to be valuable.

We are Oracle partners. We have our clients and they need this solution. We implement it according to the clients' requirements.

I think that the Oracle Fusion Middleware stack could be improved.

I have used it for almost ten years.

I had some deployment issues. Sometimes, issues will be erased if the OS and the system do not meet the system requirements and prerequisites before deploying a specific application.

I did not encounter any stability issues.

I did not encounter any scalability issues.

I would give technical support a rating of 10/10.

We have always used Oracle because we are Oracle partners.

The initial setup was straightforward.

I performed the implementation. If there was something that I was unsure about, I contacted the support team for clarifications and update patches. Overall, it depends on the situation and the time frame.

I have seen a decent ROI for the Oracle and Veritas Backup Exec products.

We looked at alternatives, but they could not provide us with the complete set of features.

This is a good solution if they are trying to move to fusion stack.

ODI is a very accessible tool, especially since the mapping functionality has been added.

We added DevOps to ODI.

You can use the ODI versioning or our component, and complement both with lifecycle management, fully-automated deploy and integration with issue tracking.

Three years.

Not with ODI itself, but with deploying programs written in ODI. That is why we developed our solution.

No issues.

No issues.

It could be better.

It could be better.

OWB: We switched because the this tool was at the end of its life.

It was straightforward.

It was implemented in-house by experts.

Not applicable.

It is OK.

No.

It is a great tool to work with.

The ability to build integrations that process large amounts of data (in GBs), be it file transfers ,DB operations, and web service calls, etc.

ODI has made it possible for our organization to rapidly build robust integrations that process large data. The learning curve of this technology is also very smooth and can be picked up by any one with minimal programming experience.

ODI's "in-memory RDBMS" is still a black box for programmers as there are no tools/dashboards to monitor/administrate this in-memory database. As a result, inconsistent data processing issues generally force us to restart the ODI server.

There were no issues with the deployment.

We've experienced no issues with performance.

It's been able to scale for our needs.

The product may not be as evolved as Informatica, but still has a lot to offer in the Fusion Middleware Product Suite. Keeps all the promises of an ETL/ELT tool, but when it comes to Administration and maintenance the product still leaves a lot to be desired.

To have a common ETL tool in the DW team, start a common way of ETL development, set up a process registry, and daily process flow.

• It increased ETL development efficiency 1/3 in time.
• It has a short learning curve for newcomers, compared to previous MS DTS packages and scripting.

• Reusing existing ETL development pattern in the next similar tasks.
• It's flexible to add new common procedures.
• Knowledge modules can be modified to fix small issues.

• ETL process registry solution is missing.
• To manage dependencies between loading packages.
• Versioning logic and release process are not well supported.