Oracle Data Integrator (ODI) Reviews

Multiple data sources: "Most" of them, Oracle databases (some MS SQL, some Sybase, lots of files and some web services). Because the environment was overwhelmingly Oracle, ODI (we started from OWB) was a much better and cost-effective solution for us than Informatica.

Far more efficient and robust than OWB, (it was the natural evolution for us).

Separate environments for dev, test and prod from one management facility.

• Click intensive on mapping
• Lots of mouse clicking
• GUI could be improved.
  

It can do so much more than just load data. It can basically automate any task that you can think of, such a executing scripts for servers outside of your Oracle environment, executing any task that the IT team wishes to execute can be done via ODI. I created a button on a user’s machine once, this button executed only her job in ODI regardless of all the other jobs that were created. I love working with ODI because it tests your thought limits and creativity and the possibilities are endless when it comes to innovative tasks.

I work in a consulting role but I believe that by implementing it a lot of organizations’ manual processes have been automated

With ODI there is a lot of manual work to be done with the initial setup.

I've been using it for four years.

There were no issues with the deployment.

We've experienced no issues with performance.

It's been able to scale for our needs.

99% of the time we do our own trouble shooting.

I started with this product.

The initial setup was rather complex but I knew what I needed to do to achieve the end result. There are also allot of reading material on these products if you get stuck

We used an in-house team. My advice would be to know what you want to achieve with the tool because it is very flexible.

Their code-once-use-everywhere approach for coding data flows. Unlike other ELT solutions, ODI allows for creating scripts ("modules") which are then shared across multiple data load processes. If you find a bug, you fix it once, and it is fixed for everyone. It is the same if you need to code a new feature. It is also worth mentioning that ODI supports over a dozen of scripting languages. Chances are that your favorite language is amongst them.

The main improvement was unifying and standardizing ELT processes. For example, each table in the EDW solution has a set of standard columns used solely for auditing, data lineage and debugging purposes. Because the code to support those columns is shared across the whole solution, we are now capable of getting the auditing information for every single piece of data in the entire solution, without having to code it individually for each stream.

The GUI is Java based, and is less than friendly. It feels a little bit like being in the late 1980s when I started using it. So I would say: hey, Oracle guys! Improve the GUI. Make it more intuitive. Snappier. Sleeker.

I've used it for three years.

Not really. There were some caveats when upgrading from one major release to another but that's expected with tens of thousands of highly customized ELT streams. Nothing that could not be resolved within a day or two.

It is Oracle. So, you get what you pay for. We used their customer support once or twice (for instance, when resolving incompatibility with certain versions of the JDBC driver) and got all our issues fixed.

I used DTS/SSIS, Cognos DM, and Informatica previously. They all have their little pros and cons. For ODI, the killer feature was the shared code. Plus, the whole EDW solution is built upon Oracle databases so it simply makes sense to use Oracle ELT tool.

Well, it is certainly not the "Run the installer, click Next Next Next Next and have it up and running" kind of an install. There are many types of ODI agents that need to be installed and tweaked on uncountable number of servers so it does take a while to get the whole thing functional. It is all well documented though. Don't expect any major issues here but make sure you book enough time for the initial setup.

We have implemented this with an in-house team. The main thing is to get one or two ODI gurus into your DEV team. ODI is built with unique philosophy in mind and if you try to start implementing your solution using your past (non-ODI) knowledge, you will get into trouble very quickly.

I have no idea. I was not involved in ROI related discussions. I can assume that because the tool is extremely stable and, once correctly implemented, runs practically without supervision, it is a good investment in a long run. But that's just my private guess.

Make sure you understand differences between ETL and ELT (ODI is the latter). Have a well-structured source data. And if you don't know anything about ODI, find someone who does before diving into your data-warehouse project. You can learn SSIS or Informatica yourself in days. This approach is not going to work for ODI.

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.