Oracle ODP.net Managed vs Unmanaged Driver

38
votes

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 than for architectural/deployment simplicity)

5
oracleodp.net
No, nor from a similar question I asked on the OTN message boards. I basically concluded that the 12.1 unmanaged driver was essentially still a beta product and I'd wait until 12.2 before reevaluating it. – John Fedak

5 Answers

28
votes

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

enter image description here

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.

25
votes

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.

12
votes

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!!!!! enter image description here

3
votes

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 :/

2
votes

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