Oracle ODP.net Managed vs Unmanaged Driver

Question

Are there any performance benchmarks between the managed and unmanaged Oracle ODP.Net drivers?

(i.e. is there any advantage to moving to the managed driver other tha

Answer 1

The easier deployment and bitness independence are really nice benefits, but you should rather evaluate your typical driver usage thoroughly. I faced almost 50% performance handicap when using the new managed driver in 64bit processes. Other people are reporting memory leaks etc on Oracle forum: https://forums.oracle.com/community/developer/english/oracle_database/windows_and_.net/odp.net . It looks like it's kind of typical Oracle buggy product which needs some more months/years to settle back :/

Answer 2

Keep in mind that Custom Types are not supported yet. This could be a reason not to switch to the managed driver.

See this Oracle doc for the differences between the managed and unmanaged version:

http://docs.oracle.com/cd/E16655_01/win.121/e17732/intro004.htm

Answer 3

Here is a gotcha for all you folks. Took me a couple weeks to figure out why Oracle Managed drivers would not connect using ef6. If your database has the following data integrity algorithms then you MUST use the unmanaged drivers!!

buried deep in the oracle documentation!!! THANKS ORACLE!!!!!

Answer 4

Bullets from the quick start video:

• Fewer files (1 or 2 dlls at most)
• Smaller footprint (10 MB compared to 200 MB)
• Easier side by side deployment
• Same assembly for 32 and 64 bit (except for second MTS assembly).
• Code Access Security

I'm not sure about performance but I doubt it will be much different either way. My guess is that the two drivers communicate in an identical way over "Oracle Net." While there might be minor differences in the in-memory client side operations done to prepare a command and process the results, this overhead typically only represents a fraction of the time relative to the entire transaction. Most of the cost/time is spent on the server in physical IO and transferring the data back to the client. This simply isn't the same as going from the oledb provider or the System.DataAccess.OracleClient driver. This is another release from the same RDBMS company - they're going to exploit all the same performance tricks that their other client used. I wish I could post a study, but i'd guess such a thing doesn't exist because in the end it would be unremarkable. A case of no news is good news - if the new provider was somehow worse you would be reading about it.

Simplicity is enough reason to switch to this IMO. The vast majority of developers and administrators do not fully understand the provider and its relationship to the unmanaged client. Confusion about oracle home preference, version mismatch, upgrades, etc comes up constantly. To eliminate these questions would be a welcome change.

Answer 5

I would like to share some results. I think that the small lack of performance is worth compared to the easiness of deployment.

Note: seg means seconds. Sorry about that.

Of course that it is a simple test, and there are several topics that is not covered like connection pool, stability, reliability and so on...

It is important to mention, that the scenarios were executed 100 times. So the time quantities are the average of that 100 executions.