Oracle Data Integrator (ODI) Reviews

The most valuable feature is being able to schedule the jobs, especially when they're multi-step.

I don't know why we have different database environments, but we do. The business wants the data to be collected in one place, so they can do reporting and so on.

I don't know if this is because of us or because of the tool, but sometimes I had a problem with the agent getting held up. I would come in and my jobs would be failing. Now I have implemented a script to bounce the agent nightly and this problem no longer occurs.

Now that I am balancing my agent, it's been running for 2-3 months without any issues. It's been pretty stable. Prior to that, the agent was falling. I was having to check it all the time to see if the jobs ran.

One other thing that I would like to be improved – it might just be me, probably user error – is when I try to set up the feature to have it email me the notifications of what happened; I haven't been able to figure that out. I set it up but I don't get an email when it does fail.

When I initially set it up, I did open several tickets with Oracle support. I'm going to give them a middle-of-the-road rating. There were a couple of tickets where I just closed and said, "Forget it". I found a workaround; I did it a different way. There were a couple of tickets where I got really helpful people and I was very happy.

Probably because of user error – as I’ve mentioned, I had no prior experience with it – my first attempt was a bust. I was fortunate enough that I worked someplace where they sent me to training. The second time around was very easy; maybe the training was what I needed. For somebody like me, I recommend training first.

I think some people have that ability to just look online. I thought I followed all the instructions, and it would not work. It might help that, the second time around, I used the more up-to-date version. I know they change things on the install process sometimes. Second time easy; first time headache.

When I came on board, I believe we had already purchased the licensing for this. I got to be the lucky person to implement it.

Good luck. I do think the training was beneficial but I know everybody doesn't have that as an option. If you do have the option to do some training, I think that could be a really big help; it helped me.

I don't feel like I am fully utilizing it but based on the things I do use, once you get the hang of it, it's a pretty cool data integration tool.

The Knowledge Module is the most valuable feature in our experience with it.

This product can be installed on a desktop or a server to be operated. v10 has a local database that allows you to train a client for its use. This, of course, provides good knowledge transfer.

v12 has good features, but it needs to be certified with Hyperion EPM. Also, the Knowledge Module needs to be improved because it is the backbone of ODI. When we change the Knowledge Module, Oracle will not support the change in production.

There have been no issues with the deployment.

We have had no issues with the stability.

We have had scalability issues that were mainly due to a bad environment. Also, if ODI is not setup for scalability, load balancing becomes an issue.

7/10 because it is hard to find someone who has ODI knowledge on the first line of support. Oracle takes a long time to respond and to provide a fix for issues. It takes, sometimes, up to eight weeks before Oracle will say that the issue is a bug.

We previously used Informatica when it was used with Hyperion, but it is not certified for Hyperion now. ODI is less expensive, and it can be installed on a desktop or a server for implementation. With ODI, you can do transformations on the source, staging or target databases.

For me, it was straightforward if installing it on a desktop. There is more complexity when installing it on a server. Agents are involved and in v10, it was not easy to install even the agents.

We implemented it with a vendor or sub-vendor team with help from the client.

The ROI is good.

Oracle has increased the licensing price for ODI.

Before implementing or designing, please have someone familiar with the product give their input. If your network is weak, the implementation may take more time.

High volume batch loads to move data from transactional systems into the decision support warehouse.

It worked fine, but we needed a tool that would include quality and master data seamlessly.  This is more of a standalone ETL tool.

I found nothing overly amazing about this tool, although I appreciate its ability to easily load slowly changing dimensions.

It lacks a suite of tools suitable for fully processing data and moving it into decision support warehouses.

It is an ETL tool, which does the extract, transform, and load. 

At this point we are seeing what we need, so I don't know if there is anything, any big improvements that are needed. This is basically just transforming and loading the data. It's doing its job.

I rate it a seven out of 10 because there is room for growth because ODI is still new, in comparison to Informatica, which is a mature product.

We have been using it now for two years.

So far it has provided what we need, it's working fine.

It's scalable. Right now, we have a pilot project that we started with ODI, which went fine. We will be ramping that up for the other integrations and hopefully that will all go fine.

I think the support at Oracle is tremendous. We have a whole stack of Oracle products and the support with Oracle has always been very good.

We chose ODI because we have the Oracle Stack and we wanted to be in the Oracle space. We wanted a tool that will work long-term for Oracle, so that's why we chose ODI.

All ODI, all the ETL tools, they have mappings and knowledge bases and the like. Based on that, I don't think it is too complicated. It is fine. There is a learning curve, but this is going to be orchestrated by IT, not by business users, so I think it's fine.

I would definitely recommend the ODI. The reason is that now Oracle, after a long time, has put its weight behind an ETL tool, which is ODI, and so Oracle is going to stand behind it, which means that it has a long life. That's another reason which we chose it. 

Informatica is a gold standard in ETL and, before ODI, Informatica used to be the king of the ETL. Now, because Oracle is putting its weight behind this tool we think that, long-term, ODI will have a better future. When we had the option of choosing an ETL tool, we went with ODI because we wanted to choose something for the long-term.

The ODI topology and designer are the most valuable features. The topology gives me total freedom in switching between technologies / ETL agents. The mapping designer gives me a good graphical overview of ETL mappings.

The speed in which we create/generate our ETL mappings has increased by at least a factor of four as compared to Oracle Warehouse Builder.

Overall performance needs improvement. Especially when running ODI clients on Windows desktops. ODI seems to generate a lot of network traffic.

ODI Studio can be very slow. Objects (mappings, packages, tables, etc.) can take minutes to open for editing when you are running ODI Studio on a Windows client when you have your repository database running on a server. It gets even worse when you are working on the same repository with multiple developers, which is not uncommon. :) The solution to this problem is running the ODI Studio in a virtual desktop on the same database server.

I have used it for over two years.

Migrating from 12.1.2 to 12.1.3 did not go as smooth as it should.

Sometimes the ODI agent shows running in WebLogic (middleware), while it cannot be reached by the ODI clients.

More than six or seven developers working in the same repository is the maximum.

Oracle support does not always seem to deliver. At one time during the migration of 12.1.2 to 12.1.3, we had issues taking over six months to resolve.

We previously used Oracle Warehouse Builder, which was discontinued by Oracle. Oracle Data Integrator is Oracle's strategic choice for ETL tooling going forward. We could not risk running out of support. That is why we had to buy licenses for Oracle Data Integrator (whereas Oracle Warehouse Builder came free with the Oracle database - until version 11.2).

The initial setup is really not straightforward. You really have to think about the architecture in which you want to use ODI (i.e., agent(s), repository setup, topology). But this makes the software as flexible as it can be.

As with all Oracle products, you need a licensing specialist to look at your needs.

We considered moving forward with Oracle Warehouse Builder, but dismissed OWB because it was running out of support.

We also considered Informatica PowerCenter, but it seemed to be even more expensive an option than ODI. With ODI, we could still use some of the present Oracle skills (mapping design), so the learning curve seemed less steep compared to Informatica.

• Think about the architecture in which you are going to use ODI very well.
• Think about where to place an agent and, if possible, put your ODI repository as close to this agent as possible.
• If possible, run your agent closer to the target than to the source.
• Try splitting up your repository into multiple work repositories for groups of developers of no more than five developers.

I'm not very comfortable with ODI, but it is one of the Oracle product that we use. I know the interfaces and that it's used for financials. The ODI client can be configured so that Excel data can automatically be pumped into Oracle Forms directly.

It requires a client, which I don't think is the best way to go about connecting data. Basically, you need to establish a connectivity between the client and the database, so when you launch something through Reports, in can be shown in the Excel.

Also, I think they should have something like Google Docs, where an engine opens up a document directly instead of having to depend on a client for connectivity. That would make working with it much more efficient and better.

If you are applying it on more clients, it becomes a thick client because to have the client installed, it needs memory from the desktops. This slows down deployment.

If it has a client that demands more thick clients than thin clients, that means that you need to give more memory and more CPU for your desktops that are also using those same resources.

We haven't had problems with scaling it.

I wasn't involved in the implementation, but I haven't heard that it was particularly complex.

I believe we implemented it with our in-house team.

In my opinion the notable difference between ODI 10 and ODI 11 is the possibility to keep multiple interfaces open at the same time. This makes it very comfortable to work with. Another technical feature that I like, is the possibility to create a dataset. This is the Oracle set operator inside the interfaces such as UNION, INTERSECT, MINUS. It has a friendly interface where you can see all tools very clearly because the designer tab shows the operator, topology and security workflow together and you can access them at the same time without any problems.

With ODI 11, I have spent time developing different interfaces at the same time instead of developing them one by one. ODI doesn't have an interpretable language in its architecture, so if you know Oracle you can write mapping SQL statements that you need for getting the data. This allows you me to have a greater adaptability.

I would like more different tools of transformation. In the current version I have only worked with lookup and filter, and sometimes is not good enough for what I use it for.

I've been using it for seven months.

There were no issues with the deployment.

We had issues with the early versions but lately the product is performing well.

It's been able to scale for our needs.

Oracle provides good support for this tool.

The initial implementation was simple, and there are no issues to report.

I tried PowerCenter a few months before Oracle Data Integrator. I wanted to try the Oracle ETL to compare it with the tools of PowerCenter.

ODI is a great ETL tool that you can use for implementation. It’s not complicated to use, and with knowledge of SQL and PLSQL you can customize it a lot.

• Direct infusion of statements to the database, which allows the full use of database capability
• Ease of creating data flow and transformation
• Flexibility on technology on transformation

My customers started to increase their ETL performance with great margins. This was especially the case when ODI was used with Exadata, which allows each statement to be executed much faster.

The main problem with ODI is that you have to create each step of the transformation as a new interface. A big data flow can have more than 100 interfaces, which can make it difficult to trace the data. However, in v12, this approach changed to become more flexible.

Another complaint is with the user interface performance -- as the work repository gets bigger, issues arise.

I've used it for seven years now.

We have had no issues with the deployment.

There have been no stability issues.

It has been able to scale for all our needs.

7/10

I have a lot of experience on Oracle environments. I've started to have projects with my client using Oracle solutions. In my experience, ODI is a tool that is 100% compatible with all Oracle environments.

I can say that the level of complexity of the initial setup is medium. It is not straightforward because each customer may need specific logic on ETL approaches, so this means that your Knowledge Modules are mostly customized. Although except after the first installation and environment definitions, it is pretty easy to do after that.

I am a part of a vendor team. I think the most important thing is to decide where to reside this tool and its agent. This architectural question will help in the future to execute ETL processes. Secondly, the naming standards of all projects, immediate tables, Knowledge Module and folder names etc. are pretty important. Thirdly, versioning is crucial. All these standards should be done at the beginning of your use.

The product has a wide range of options on licensing.

The Knowledge Module is the heart of this solution. If you have nicely written Knowledge Modules, then you will not have any performance issues. The language should be kept as common as possible and all in one solution. You can write in many different languages, but the maintenance will need a wide variety of knowledge in the future. This can be very tricky in the long term. Do not forget to clean temporary tables after each execution of ETL. Otherwise, the database will be full of unnecessary data.