Oracle ODP.net 托管驱动程序与非托管驱动程序
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/17583289/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Oracle ODP.net Managed vs Unmanaged Driver
提问by John Fedak
Are there any performance benchmarks between the managed and unmanaged Oracle ODP.Net drivers?
托管和非托管 Oracle ODP.Net 驱动程序之间是否有任何性能基准？
(i.e. is there any advantage to moving to the managed driver other than for architectural/deployment simplicity)
（即除了架构/部署的简单性之外，迁移到托管驱动程序是否有任何优势）
采纳答案by gustavodidomenico
I would like to share some results. I think that the small lack of performance is worth compared to the easiness of deployment.
我想分享一些结果。我认为与易于部署相比，性能上的小不足是值得的。
Note: segmeans seconds. Sorry about that.
注：seg表示秒。对于那个很抱歉。
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.
值得一提的是，这些场景被执行了 100 次。所以时间量是这 100 次执行的平均值。
回答by b_levitt
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
- 更少的文件（最多 1 或 2 个 dll）
- 占用空间更小（10 MB 与 200 MB 相比）
- 更轻松的并行部署
- 32 位和 64 位的相同程序集（第二个 MTS 程序集除外）。
- 代码访问安全
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.
我不确定性能，但我怀疑无论哪种方式都会有很大不同。我的猜测是这两个驱动程序通过“Oracle Net”以相同的方式进行通信。虽然为准备命令和处理结果而执行的内存中客户端操作可能存在细微差别，但这种开销通常仅代表相对于整个事务的一小部分时间。大部分成本/时间都花在服务器上的物理 IO 上，并将数据传输回客户端。这与来自 oledb 提供程序或 System.DataAccess.OracleClient 驱动程序的不同。这是同一 RDBMS 公司的另一个版本——他们将利用其他客户端使用的所有相同的性能技巧。我希望我可以发布一项研究，但我猜这样的事情不会“ 之所以存在，是因为最终它会变得不起眼。没有消息的情况是个好消息 - 如果新的提供者不知何故更糟，你会读到它。
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.
简单是切换到此 IMO 的充分理由。绝大多数开发人员和管理员并不完全了解提供程序及其与非托管客户端的关系。关于 oracle home 偏好、版本不匹配、升级等的困惑不断出现。消除这些问题将是一个可喜的变化。
回答by WingMan20-10
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!!
这是给你们所有人的一个陷阱。我花了几个星期才弄清楚为什么 Oracle Managed 驱动程序不能使用 ef6 进行连接。如果您的数据库具有以下数据完整性算法，那么您必须使用非托管驱动程序！！
buried deep in the oracle documentation!!! THANKS ORACLE!!!!! 
深埋在oracle文档中！！！感谢甲骨文！！！！！！
回答by Buthrakaur
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 :/
更容易的部署和位独立性确实是很好的好处，但您应该彻底评估您的典型驱动程序使用情况。在 64 位进程中使用新的托管驱动程序时，我面临近 50% 的性能障碍。其他人在 Oracle 论坛上报告内存泄漏等：https: //forums.oracle.com/community/developer/english/oracle_database/windows_and_.net/odp.net。看起来它是一种典型的 Oracle 有缺陷的产品，需要几个月/几年的时间才能恢复：/
回答by Richard
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:
有关托管和非托管版本之间的差异，请参阅此 Oracle 文档：
http://docs.oracle.com/cd/E16655_01/win.121/e17732/intro004.htm
http://docs.oracle.com/cd/E16655_01/win.121/e17732/intro004.htm
