c**t
发帖数: 2744 | 1 If you're a sql server dba; user "needs" CLR UDF, what will you do? |
a9
发帖数: 21638 | 2 为什么反对呢？
【在 c**t 的大作中提到】
: If you're a sql server dba; user "needs" CLR UDF, what will you do?
|
B*****g
发帖数: 34098 | 3 大牛DBA请绕行。
I am not a sql server dba and also not an oracle dba.
Most oracle DBAs will not allow developers to create java store procedure on
oracle as they say oracle pl/sql is faster.
Actually the reason is they do not know java, and they almost cannot do any
programming even in plsql.
基本原则，我不会的，也不许别人用。
当然也有会点乃特的sql server DBA，也有会家挖的oracle DBA，版上就有。
【在 c**t 的大作中提到】
: If you're a sql server dba; user "needs" CLR UDF, what will you do?
|
a9
发帖数: 21638 | 4 我原来有这么一个应用。
将数据入库，其中datetime一列用的是getdate(),插入数据后，要对原始数据+
datetime做数字签名，更新到另一列中去。
我就用.net做了个存储过程，把这些数据传进去做数字签名。
我实在不太信任用asp.net页面启动事务，插入数据，签名，更新，再提交事务这个过
程。
说到这儿问个问题，asp.net里的finally块，肯定会执行到吗？我以前的应用里，进入
try块后，如果遇到某些问题,finally块是不会执行的。出的问题原因不是try块中的异
常，最后我也没想出来是啥问题。
【在 a9 的大作中提到】
: 为什么反对呢？
|
j*******7
发帖数: 6300 | 5 CLR object run多了会使内存不被释放，只能restart sql service. Mission
critical的系统尽量别用。 |
u**d
发帖数: 211 | 6 oracle 说的是有道理的
根本问题是 udf 对于 optimizer 来说就是 black box
如何优化、有什么特性 optimizer 完全不知道
一个很简单的 udf 很可能完全 mess up query plan
到头来还是要用各种 hints 来强行指定 plan
pl/sql 无非就是把 udf 用 db 自己的 operator 描述一遍
每一步对于 db 都是透明的，也可以优化
on
any
【在 B*****g 的大作中提到】
: 大牛DBA请绕行。
: I am not a sql server dba and also not an oracle dba.
: Most oracle DBAs will not allow developers to create java store procedure on
: oracle as they say oracle pl/sql is faster.
: Actually the reason is they do not know java, and they almost cannot do any
: programming even in plsql.
: 基本原则，我不会的，也不许别人用。
: 当然也有会点乃特的sql server DBA，也有会家挖的oracle DBA，版上就有。
|
a9
发帖数: 21638 | 7 clr udf 无非就是.net，如何优化看你自己了。
procedure
【在 u**d 的大作中提到】
: oracle 说的是有道理的
: 根本问题是 udf 对于 optimizer 来说就是 black box
: 如何优化、有什么特性 optimizer 完全不知道
: 一个很简单的 udf 很可能完全 mess up query plan
: 到头来还是要用各种 hints 来强行指定 plan
: pl/sql 无非就是把 udf 用 db 自己的 operator 描述一遍
: 每一步对于 db 都是透明的，也可以优化
:
: on
: any
|
c*****t
发帖数: 1879 | 8 Just curious, in Oracle, does the database server and .NET
UDF run in the same process?
If not, there is a significant IPC cost.
【在 u**d 的大作中提到】
: oracle 说的是有道理的
: 根本问题是 udf 对于 optimizer 来说就是 black box
: 如何优化、有什么特性 optimizer 完全不知道
: 一个很简单的 udf 很可能完全 mess up query plan
: 到头来还是要用各种 hints 来强行指定 plan
: pl/sql 无非就是把 udf 用 db 自己的 operator 描述一遍
: 每一步对于 db 都是透明的，也可以优化
:
: on
: any
|
B*****g
发帖数: 34098 | 9 ding。其实要比较过才知道，不过结果肯定是case by case。不过DBA不take risk也是
对的，毕竟自己不懂，出了问题也解决不了。
【在 a9 的大作中提到】
: clr udf 无非就是.net，如何优化看你自己了。
:
: procedure
|
B*****g
发帖数: 34098 | 10 好久没见呀。这个贴子适合在group里讨论。
http://download.oracle.com/docs/cd/B19306_01/win.102/b14306/int
【在 c*****t 的大作中提到】
: Just curious, in Oracle, does the database server and .NET
: UDF run in the same process?
: If not, there is a significant IPC cost.
|
|
|
a9
发帖数: 21638 | 11 另外我不觉得有内存释放问题。我上面说的那个应用，跑了3年了，sql server从来没
重起过。
一定要找个能养我的PPMM */
【在 B*****g 的大作中提到】
: ding。其实要比较过才知道，不过结果肯定是case by case。不过DBA不take risk也是
: 对的，毕竟自己不懂，出了问题也解决不了。
|
B*****g
发帖数: 34098 | 12 我老板总是说"can you guaranty?"
我心想"关我屁事"
hehe
【在 a9 的大作中提到】
: 另外我不觉得有内存释放问题。我上面说的那个应用，跑了3年了，sql server从来没
: 重起过。
:
: 一定要找个能养我的PPMM */
|
a9
发帖数: 21638 | 13 像我这个就是没有dba的好处了，developer想怎么弄就怎么弄。
来没
一定要找个能养我的PPMM */
【在 B*****g 的大作中提到】
: 我老板总是说"can you guaranty?"
: 我心想"关我屁事"
: hehe
|
B*****g
发帖数: 34098 | 14 这是oracle和sqlserver的区别。咱公司的sql server／mysql俺也是想怎么弄就怎么弄。
【在 a9 的大作中提到】
: 像我这个就是没有dba的好处了，developer想怎么弄就怎么弄。
:
: 来没
: 一定要找个能养我的PPMM */
|
c**t
发帖数: 2744 | 15 if your app exit CLR in try block, finally will NOT be executed.
【在 a9 的大作中提到】
: 我原来有这么一个应用。
: 将数据入库，其中datetime一列用的是getdate(),插入数据后，要对原始数据+
: datetime做数字签名，更新到另一列中去。
: 我就用.net做了个存储过程，把这些数据传进去做数字签名。
: 我实在不太信任用asp.net页面启动事务，插入数据，签名，更新，再提交事务这个过
: 程。
: 说到这儿问个问题，asp.net里的finally块，肯定会执行到吗？我以前的应用里，进入
: try块后，如果遇到某些问题,finally块是不会执行的。出的问题原因不是try块中的异
: 常，最后我也没想出来是啥问题。
|
c**t
发帖数: 2744 | 16 我觉得主要的问题是 replication；在server挂掉的重建情况下，CLR UDF容易被漏掉
【在 a9 的大作中提到】
: 另外我不觉得有内存释放问题。我上面说的那个应用，跑了3年了，sql server从来没
: 重起过。
:
: 一定要找个能养我的PPMM */
|
c**t
发帖数: 2744 | 17 oracle you can have compiled store proc..
弄。
【在 B*****g 的大作中提到】
: 这是oracle和sqlserver的区别。咱公司的sql server／mysql俺也是想怎么弄就怎么弄。
|
a9
发帖数: 21638 | 18 呵呵，那就是人为原因了。
来没
【在 c**t 的大作中提到】
: 我觉得主要的问题是 replication；在server挂掉的重建情况下，CLR UDF容易被漏掉
|
a9
发帖数: 21638 | 19 没有人为的退出，可能是asp.net，连接断掉后，iis把它给exit了？
个过
进入
的异
【在 c**t 的大作中提到】
: if your app exit CLR in try block, finally will NOT be executed.
|
u**d
发帖数: 211 | 20 优化的核心在于 data-sensitive
动态选择(认为)最优的 execution plan 是 optimizer 的长处
特别是非常复杂的操作
从开发的角度，用 high level operators 不仅减少代码量
而且还减少 debug 的时间，不易出错
另外如果 query 本身就包含了 udf，比如
R JOIN T on R.a = f(T.b)
不知道 f 的特性，选择 hash join，还是 merge join，还是 nested loop
optimizer 就是一头雾水
【在 a9 的大作中提到】
: clr udf 无非就是.net，如何优化看你自己了。
:
: procedure
|
|
|
B*****g
发帖数: 34098 | 21 optimizer 怎么根据f 的特性优化join？没听说过。有没有source？
【在 u**d 的大作中提到】
: 优化的核心在于 data-sensitive
: 动态选择(认为)最优的 execution plan 是 optimizer 的长处
: 特别是非常复杂的操作
: 从开发的角度，用 high level operators 不仅减少代码量
: 而且还减少 debug 的时间，不易出错
: 另外如果 query 本身就包含了 udf，比如
: R JOIN T on R.a = f(T.b)
: 不知道 f 的特性，选择 hash join，还是 merge join，还是 nested loop
: optimizer 就是一头雾水
|
c*****t
发帖数: 1879 | 22 其实 UDF 是可以 optimize 的。但是根本问题是执行 UDF 的 cost 太高。
1) Expression Index 可以直接储存 UDF(column) 的结果
2) Collect Statistics 也可以比较容易的改成执行 UDF 。
F(T.b) 很简单，因为只有一个 column 。复杂点的其实也可以，不过要有
点 restriction :
a) Columns 只能来自一个 table 。
b) 要不就是 constant 。
其中 a) 可以用 join index 绕过。
其实从另一方面来看，multi-column statistics 其实就是用一个内部的
F(...) 来将多个 column 的值变成一个值来搞 statistics 。
但是执行 UDF 的 cost 太高。依此得到 statistics 似乎有点得不偿失。
如果 UDF 在另外一个 process 里执行的话，不管是 C 写的还是 Java，.NET
都会比同一 process 里的 UDF 慢上 10-20 倍。但是同一 process 里面执行
的话，security 和 availability 方面都大大降低。
我知道一 Teradata 系统 collect statistics 是在 replicated system 上
执行 3.5 小时。然后每天再把 statistics 拷到 production server 上。如
果上面是弄 UDF 的话，这个估计难以按时完成。
【在 u**d 的大作中提到】
: 优化的核心在于 data-sensitive
: 动态选择(认为)最优的 execution plan 是 optimizer 的长处
: 特别是非常复杂的操作
: 从开发的角度，用 high level operators 不仅减少代码量
: 而且还减少 debug 的时间，不易出错
: 另外如果 query 本身就包含了 udf，比如
: R JOIN T on R.a = f(T.b)
: 不知道 f 的特性，选择 hash join，还是 merge join，还是 nested loop
: optimizer 就是一头雾水
|
u**d
发帖数: 211 | 23 我的意思是，如果 udf 是用 sql 在 db 内部定义的
udf 完全可以看成一个宏，query compilation 的时候替换掉
整个 query 就是一个 sql
比如 f(x) = x + 1
R JOIN T on R.a = f(T.b)
编译的时候就等价于 R JOIN T on R.a = T.b +１
optimizer 完全没有问题
但是如果 f 是用 .NET 写的 udf，f(T.b) 就是一个 black hole
但是 sql 自己提供的 operators 是有限的
很多 function 都无法实现
没办法，扩展性和效率很多时候都是矛盾的
和 sql server 和 teradata 的人都聊过，udf 都是一个很头疼的问题
udf 的调用效率问题，几乎也是因为 query engine 根本无法把 udf
抽象成 high level operators，所以只能按照 semantics，一遍一遍的调用
cost 很高
【在 B*****g 的大作中提到】
: optimizer 怎么根据f 的特性优化join？没听说过。有没有source？
|
u**d
发帖数: 211 | 24 看来是空间换时间，不过 maintenance cost 看起来挺高的
【在 c*****t 的大作中提到】
: 其实 UDF 是可以 optimize 的。但是根本问题是执行 UDF 的 cost 太高。
: 1) Expression Index 可以直接储存 UDF(column) 的结果
: 2) Collect Statistics 也可以比较容易的改成执行 UDF 。
: F(T.b) 很简单，因为只有一个 column 。复杂点的其实也可以，不过要有
: 点 restriction :
: a) Columns 只能来自一个 table 。
: b) 要不就是 constant 。
: 其中 a) 可以用 join index 绕过。
: 其实从另一方面来看，multi-column statistics 其实就是用一个内部的
: F(...) 来将多个 column 的值变成一个值来搞 statistics 。
|
