请比较一下pro*c和存储过程的效率。

fromeast

[B]不知道这些描述的出处？请指明。[/B]
具体的出处不记得了，应该是ORACLE官方教材或在线文档吧

[B]1。存储过程的代码是整个存储在shared pool中，比起pro*c中的单条sql占用的空间肯定大的多。[/B]
你的意思是说，100页的书占的空间，肯定比1页纸占的空间大。同意。

[B]2。存储过程确实一次编译后就驻留内存[/B]
偶不同意这个观点。偶认为存储过程编译后放在数据字典里乐。

[B]pro*c的sql和任何sql没有区别，只有被客户端发出执行，都会被oracle分析，其执行计划也会保存在shared pool,下次有同样的语句调用时，直接执行分析了的代码。原理和存储过程没有区别。[/B]
同意

[B]只是不清楚在shared pool中的sql、存储过程是否也和data buffer 中的数据一样用LRU管理。 [/B]
我认为用LRU管理。
另：如果shared pool条目越多，latch冲突的机会就越大。

jxc_hn

2。存储过程确实一次编译后就驻留内存
偶不同意这个观点。偶认为存储过程编译后放在数据字典里乐。



是这样的：

存储过程编译后的源代码是放在数据字典中的。但每次instance启动时，都会将存储过程从数据字典中倒入内存。

fromeast

最初由 jxc_hn 发布
[B]2。存储过程确实一次编译后就驻留内存
偶不同意这个观点。偶认为存储过程编译后放在数据字典里乐。



是这样的：

存储过程编译后的源代码是放在数据字典中的。但每次instance启动时，都会将存储过程从数据字典中倒入内存。 [/B]

每次instance启动时，都会将存储过程从数据字典中倒入内存？那ORACLE岂不很累？并不是每个存储过程都是常用的。

存储过程和普通SQL一样，都是第一用的时候调入内存。

THUNDER2

最初由 fromeast 发布
无论pro*c还是存储过程，其实都是在执行一些SQL，只不过执行方式和组织方式不同：
1.pro*c的SQL是分别传递、执行的，每个SQL占用shared pool空间中的一个条目。存储过程是作为一个整体保存在shared pool中的，一个存储过程只占一个条目。所以存储过程能较少地占用内存shared pool空间。

编译后的pl/sql 与sql 都放在library cache,但是分开放的
– Shared SQL area
– Shared PL/SQL area
编译后的pl/sql 包含的sql语句执行时仍然要放到Shared SQL area中,你的意思是存储过程中的所有sql 在Shared SQL area中只占一个条目吗?  对此我有些疑问,能否进一步解释一下或提供相关的资料呢?

uje

“无论PRO*C再怎么快,它的程序只是一个ORACLE的客户端“是一个错误概念。
    请教galebird ，pro*c的程序已经和oracle的运行在系统的不同进程中了，不能共享资源如何还能不是client端。原理上由于pro*c的程序没有本地的pl/sql解释引擎，所以凡是pl/sql的语句传给都是由oracle的pl/sql引擎执行后再把结果传会继续处理。原则就是本地能做的处理就再本地做，本地不能做的就由oracle做。所以proc的程序和develop2000的程序在执行模式上的不同就是pro*c没有本地的pl/sql引擎而develop2000有，所以有很多不需要由oracle端pl/sql引擎做的事情可以由develop端做，减少了网络传输的开销。
    我已经说过，判断是否是否client端原理就是看能否共享资源，如果是你的application和oracle不能共享资源对oracle而言就是client端。

   "存储过程编译后的源代码是放在数据字典中的。但每次instance启动时，都会将存储过程从数据字典中倒入内存。"
    由于sga的空间有限，所以不会是instance启动时，都会将存储过程从数据字典中倒入内存.而是在你调用这个过程时在调入内存中，调用完毕后并不会立刻清调，由于sga资源有限，由最久未使用算法来决定将那个过程remove.当然你也可以配置那些procedure是常驻sga的。

biti_rainy

通常来说
这点内存不是关键的，通常足够

内存不足，解决不了的是  hard  code  的问题

galebird

to UJE:
首先引用thunder 2 因为下列文字我现在找不到原始文档，但和我的记忆一致。不过需加上SP
sp--> SQLLIB CALLS --->| UPI ---> SQLNET ---> SERVER.
(PRECOMPILER --> SQLLIB CALLS --->| UPI ---> SQLNET ---> SERVER.
OCI CALLS----------------------->| UPI ---> SQLNET ---> SERVER.)
从你的描叙中，非要把proc分离出来，从上面流程可见，proc 程序经过了SQLNET，是客户端。
但sp也一样。为什莫sp 不是客户端。我在这里是强调用这种方式对比proc 和sp 是不对的。
另通常我们把sp or proc 看成服务端，因为它属于数据介入层。因为client / sever 从不同的角度看是不同的。
感谢uje的讨论。

uje

同意“client / sever 从不同的角度看是不同的",我强调pro*c和sp的不同是只在执行时能否和oracle的instance共享资源，也就是说这两者执行时是否能和oracle instance共享堆和栈的资源。
举个例子把：我现在需要对一个集合操作。用pro*c的方式处理一般是需要报记录集取到本地的buffer中处理的。这里是oracle instance取出这个集合后通过net8传到这个pro*c的进程中的，如果这个程序在很多地方运行，那么这个网络传输的开销不会太小（当然看应用和频度而言）。如果是sp方式处理就不会有这个过程，sp和oracle instance在一个进程中处理直接共享资源，不需要再有别的开销。
  不过我想我和你对这个问题有不同的看法可能是应为我和你对于client的定义一样把。你侧重处理流程而我侧重操作系统。感谢你的讨论，和大家的讨论总能学到很多东西.

galebird

Thank you UJE
After some discussion, It let me know that I have some misunderstanding in sp , precompiler and oci.
But I have said in preview dialogue, sp<>pl/sql.
As the example you give,You can use pl/sql in Proc to resolve the problem.
Sp is a object of database which stored in dictionary of database.
but the pl/sql translated to database server by applition is stored in sga not in dictionary of database.
So maybe It's faster than sp.
Another thing is there are pl/sql engine in client side. I am not familar with this, would you have time to tell me.

liuzp

各位最好举个示例，说明测试的软硬件环境，说明在各种调用的区别，最好有完整的测试数据及测试结论，大家来提出改进意见。
另： lander 兄的“在Oracle中，首先应该考虑能否用SQL实现，如不能实现则应考虑PL/SQL，如PL/SQL不能实现才考虑PRO*C。”见TOM的Expert one-on-one Oracle.
补充：TOM书中：最好的方法是接触尽可能少的数据。