看我做的数据库包装器

yulihua49

原帖由 newkid 于 2010-8-5 09:04 发表
刚刚看到你补充的内容，32个物理连接也太少了吧！你这10次调用，其实一次就够了。我问你绑定变量值修改之后，CACHE会不会复制新的拷贝而你没有答复，我猜想你的缓存都是静态的字典表之类的。这些缓存解决不了什么问题，DB的BLOCK缓存就够好了，何况我还可以在PGA里面用PLSQL的全局数组。

这不是应用而是测试，10次是模拟压力。我试验的是简易的cache，离实用还差得远，只是验证一下。

32个链接是经过优选法测出最快的配置，经验值是CPU数的4-6倍。因为现在负载均衡不到前边来，实际上是数据库CPU数的4-6倍。

请推荐一下11g的结果集cache的使用最好是中文的。
另外：
原来10g的OCI，commit时间很长约30-40ms，把我全部优化成果吞噬殆尽，这边发现11g的oci，commit只需1ms，我以为是11g的新特点。但有人说是配置的策略。
配置是oracle的人做的，公司的人不知道，眼下也找不到他们。你知道配置方法吗？

还有本帖前边说的怪异现象，插入记录发生重码时，时间很长，在11g已经好转，没必要假修改了。时间已经等于假修改时间。

复习一下：原10g：
正常插入：5300条/秒，插入重码并放弃操作，25条/秒，重码后进行假修改（update ... set field1=field1 ....),1500条/秒

11g在放弃的情况，速度与假修改差不多，虽然不尽人意，也凑合了。
应该是与正常差不多的时间，甚至更快。

[ 本帖最后由 yulihua49 于 2010-8-5 09:56 编辑 ]

yulihua49

原帖由 newkid 于 2010-8-5 08:53 发表
你有没想过这些负担可能是你的编程方法引起的？如果用存储过程，你只需和数据库打一次交道；用你的方法，不得不频繁访问。
1000个连接是实际SESSION的数量？有没有用连接池？有时候你需要的物理连接并没那么多，几个客户可以共享，平均响应时间反而降低。
还是老规矩：把你的需求亮出来，我来写存储过程，你看看我的做法比你差多少！

一些集成操作放在存储过程应该更好。
有些算法过于复杂，就不方便存储过程。因地制宜吧。

DAU最近进展：
支持数组插入，带returnning的插入和修改。
可以在多线程和线程池环境使用。提供数据库连接池。

其中数组插入，在我们前边7552记录的数据达到0.31秒的水平，平均超过20000条/秒。数据库与文件不在一个机器上。前边演示的数组插入比较繁琐，现在包装了，简化使用，只需4个函数就可以处理任何表。
OAD *any_OAD;//Oracle Array Describe

OAD_init(&any_OAD,&table_DAU,data_array,MAX_NUM);
OAD_mk_ins(&any_OAD,stmt); //一次性生成语句并绑定变量。

whiile   OAD_exec(&OAD,0,num);//可以重复执行

OAD_free(&any_OAD);

一个程序，改OAD后从30秒变3秒，每次几个到十几个记录，批量不是很大的。

[ 本帖最后由 yulihua49 于 2010-8-5 10:45 编辑 ]

mdcpaulliu

学习了！

newkid

RESULT CACHE:
http://www.oracle.com/technology ... -sep/o57asktom.html

里面又分为SQL和PLSQL的结果缓存。
计算越是复杂的SQL(比如有大量分组聚合运算，复杂的连接)，逻辑越是复杂的PLSQL函数，效果越明显。
如果都是你那种单表SELECT, 不见得有多少提高。
如果底层的数据变化很频繁，用CACHE也没有意义，甚至更糟。CACHE的基本思想就是“再利用”，如果结果只用一次那就不如不要。
TOM写的英文都很通俗，如果哪里看不懂就提出来探讨。

关于COMMIT的问题，以前我们解决的是存储的配置，和数据库无关。我也不知道怎么解决的，是我们的DBA弄好的。
你可以试一下COMMIT WRITE NOWAIT;这个是10G以上的异步提交。

我看你鼓捣出来的东西也没什么新意，数组绑定是我当初在给你启蒙绑定变量的时候就建议了的，连接池、CACHE都不是新东西。你的系统压力最大的无非就是票务操作，没有什么“过于复杂”的算法，这是最适合用存储过程的了。

yulihua49

原帖由 newkid 于 2010-8-5 22:27 发表
RESULT CACHE:
http://www.oracle.com/technology ... -sep/o57asktom.html

里面又分为SQL和PLSQL的结果缓存。
计算越是复杂的SQL(比如有大量分组聚合运算，复杂的连接)，逻辑越是复杂的PLSQL函数，效果越明显。
如果都是你那种单表SELECT, 不见得有多少提高。
如果底层的数据变化很频繁，用CACHE也没有意义，甚至更糟。CACHE的基本思想就是“再利用”，如果结果只用一次那就不如不要。
TOM写的英文都很通俗，如果哪里看不懂就提出来探讨。

关于COMMIT的问题，以前我们解决的是存储的配置，和数据库无关。我也不知道怎么解决的，是我们的DBA弄好的。
你可以试一下COMMIT WRITE NOWAIT;这个是10G以上的异步提交。

我看你鼓捣出来的东西也没什么新意，数组绑定是我当初在给你启蒙绑定变量的时候就建议了的，连接池、CACHE都不是新东西。你的系统压力最大的无非就是票务操作，没有什么“过于复杂”的算法，这是最适合用存储过程的了。

收到，多谢。我这就去试验，结果晚上回来报告。

关于技术，我当然不会发明什么新方法。我所做的工作，只是“包装”，就是把别人的东西放在我的工具箱里，为的工作方便一些，如果我能够把更多的系统功能集成在一起，后人可以简单而透明的使用系统最优秀的功能。比如我想，如果用户提交的语句不含for update，可以考虑为他加上 /*+ result_cache */提示。于是他透明的使用这个功能。

不是吗？很多人在坛子上问这问那，你今天解答一个，明天继续解答几乎是同样问题。如果你把你的经验包装成一个产品，人们使用这个产品就是使用你的经验，不是更好吗？
就是这样，我在向你取经，也向所有人取经，然后，所有使用我的产品的人，都具有了丰富饭经验。这不就是你我的价值得到更大的延伸？

做一个工具箱，让使用者 简单、可靠、高效的生产软件而已，我的确没有发明什么方法。

[ 本帖最后由 yulihua49 于 2010-8-6 10:40 编辑 ]

newkid

原帖由 yulihua49 于 2010-8-6 10:25 发表

比如我想，如果用户提交的语句不含for update，可以考虑为他加上 /*+ result_cache */提示。于是他透明的使用这个功能。

这个千万使不得。要是有这种灵丹妙药，ORACLE早替你自动加上了。
如果你这个SELECT 的源数据被频繁修改，每次修改ORACLE都要把相关的CACHE失效，反而变成额外负担。这和FOR UPDATE没有一点关系。
所以，该不该用这个功能，必须先理解它的原理，再理解自己的应用需求，才能够决定。原则也很简单，只要一个查询结果能被反复使用，CACHE就有帮助；如果这个结果本身是千变万化的，那就用不上了。
工具箱、包装器的思想没什么问题；但我认为Oracle已经有了最好的包装器PLSQL, 它替你处理绑定、替你处理游标（隐性游标）、替你管理缓存，更重要的是它鼓励你多用SQL而不是避免用SQL。

yulihua49

原帖由 newkid 于 2010-8-7 03:41 发表


这个千万使不得。要是有这种灵丹妙药，ORACLE早替你自动加上了。
如果你这个SELECT 的源数据被频繁修改，每次修改ORACLE都要把相关的CACHE失效，反而变成额外负担。这和FOR UPDATE没有一点关系。
所以，该不该用这个功能，必须先理解它的原理，再理解自己的应用需求，才能够决定。原则也很简单，只要一个查询结果能被反复使用，CACHE就有帮助；如果这个结果本身是千变万化的，那就用不上了。
工具箱、包装器的思想没什么问题；但我认为Oracle已经有了最好的包装器PLSQL, 它替你处理绑定、替你处理游标（隐性游标）、替你管理缓存，更重要的是它鼓励你多用SQL而不是避免用SQL。

接受，不乱用/*+ result_cache */ 。
SELECT /*+ result_cache */ c.table_name Fld_Tlb_Name,c.column_name  Fld_Column_Name,decode(data_type, 'CHAR',1, 'VARCHAR',1, 'VARCHAR2',1, 'DATE',129,'TIMESTAMP(6)',129,'FLOAT',8,'LONG',126, 'RAW',0, 'BINARY_DOUBLE',8,'BINARY_FLOAT',7, 'NUMBER',decode(nvl(DATA_SCALE,0),0,decode(nvl(data_precision,0), 0,257, 1,2, 2,2, 3,3, 4,3, 5,4, 6,4, 7,4, 8,4,9,4, 10,6, 11,6, 12,6, 13,6, 14,6, 15,6, 16,6, 17,6, 18,6, 257),8),257) Fld_Column_Type,decode(data_type, 'CHAR',data_length+1, 'VARCHAR',data_length+1,'VARCHAR2',data_length+1, 'DATE',20,'TIMESTAMP(6)',27,'FLOAT',8,'BINARY_DOUBLE',8,'BINARY_FLOAT',4,'LONG',-1, 'NUMBER', decode(nvl(DATA_SCALE,0),0,decode(nvl(data_precision,0), 0,40, 1,1, 2,1, 3,2, 4,2, 5,4, 6,4, 7,4, 8,4, 9,4, 10,8, 11,8, 12,8, 13,8, 14,8, 15,8, 16,8, 17,8, 18,8, data_precision+2),8),data_length) Fld_Column_Len,decode(data_type, 'CHAR',null, 'VARCHAR',null, 'VARCHAR2',null, 'DATE','YYYY-MM-DD HH24:MI:SS','TIMESTAMP(6)','YYYY-MM-DD HH24:MI:SS.FF6','FLOAT','%lg','LONG',null, 'BINARY_DOUBLE','%lg', 'BINARY_FLOAT','%g', 'NUMBER',decode(nvl(DATA_SCALE,0),0,null,'%'||TO_CHAR(data_precision+2)||'.'||TO_CHAR(DATA_SCALE)||'lf'),null) Fld_Format,k.position Fld_PK FROM all_tab_columns c, (select table_name,column_name,position from all_cons_columns where owner= :1 and table_name=:2 and position is not null) k  where c.table_name = k.table_name(+) and c.column_name = k.column_name(+) and c.owner = :3 and c.table_name=:4 order by c.table_name, c.column_id
这个结果集是静态的，不怎么变。

这个没效果，可能是配置有问题。

[ 本帖最后由 yulihua49 于 2010-8-7 23:23 编辑 ]

newkid

如果绑定变量值在以前出现过，CACHE才能用上。新的值用不上。
如果你原来的SQL已经很快，效果也不明显。

yulihua49

被sqlldr忽悠了两年，它原来是成组插入的。
我的单条插入算法与他PK，达到83%的性能，我容易吗？
sdbc@jgbticket:~/sdbc5/demo/sql> time ./ldtj.sh

SQL*Loader: Release 10.2.0.3.0 - Production on Wed Aug 25 09:14:14 2010

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Commit point reached - logical record count 717
Commit point reached - logical record count 1434
Commit point reached - logical record count 2151
Commit point reached - logical record count 2868
Commit point reached - logical record count 3585
Commit point reached - logical record count 4302
Commit point reached - logical record count 5019
Commit point reached - logical record count 5736
Commit point reached - logical record count 6453
Commit point reached - logical record count 7170
Commit point reached - logical record count 7552

real    0m1.227s
user    0m0.368s
sys     0m0.012s
我一直以为717条是commit的数字。

实际上：
Table TJRB, loaded from every logical record.
Insert option in effect for this table: APPEND
TRAILING NULLCOLS option in effect

   Column Name                  Position   Len  Term Encl Datatype
------------------------------ ---------- ----- ---- ---- ---------------------
TJDATE                              FIRST     *   |       CHARACTER
    SQL string for column : "to_date(:tjdate, 'YYYY.MM.DD')"
UNIT                                 NEXT     *   |       CHARACTER
TABNAME                              NEXT     *   |       CHARACTER
FLG                                  NEXT     *   |       CHARACTER
DAT1                                 NEXT     *   |       CHARACTER
DAT2                                 NEXT     *   |       CHARACTER
DAT3                                 NEXT     *   |       CHARACTER
DAT4                                 NEXT     *   |       CHARACTER
DAT5                                 NEXT     *   |       CHARACTER
DAT6                                 NEXT     *   |       CHARACTER
DAT7                                 NEXT     *   |       CHARACTER
DAT8                                 NEXT     *   |       CHARACTER
DAT9                                 NEXT     *   |       CHARACTER
DAT10                                NEXT     *   |       CHARACTER
DAT11                                NEXT     *   |       CHARACTER
DAT12                                NEXT     *   |       CHARACTER
DAT13                                NEXT     *   |       CHARACTER
DAT14                                NEXT     *   |       CHARACTER
DAT15                                NEXT     *   |       CHARACTER
DAT16                                NEXT     *   |       CHARACTER
DAT17                                NEXT     *   |       CHARACTER
DAT18                                NEXT     *   |       CHARACTER
DAT19                                NEXT     *   |       CHARACTER
DAT20                                NEXT     *   |       CHARACTER
DAT21                                NEXT     *   |       CHARACTER
DAT22                                NEXT     *   |       CHARACTER
DAT23                                NEXT     *   |       CHARACTER
DAT24                                NEXT     *   |       CHARACTER
DAT25                                NEXT     *   |       CHARACTER
DAT26                                NEXT     *   |       CHARACTER
DAT27                                NEXT     *   |       CHARACTER
DAT28                                NEXT     *   |       CHARACTER
DAT29                                NEXT     *   |       CHARACTER
DAT30                                NEXT     *   |       CHARACTER
DAT31                                NEXT     *   |       CHARACTER
DAT32                                NEXT     *   |       CHARACTER
DAT33                                NEXT     *   |       CHARACTER
DAT34                                NEXT     *   |       CHARACTER
DAT35                                NEXT     *   |       CHARACTER
DAT36                                NEXT     *   |       CHARACTER
DAT37                                NEXT     *   |       CHARACTER
DAT38                                NEXT     *   |       CHARACTER
DAT39                                NEXT     *   |       CHARACTER
DAT40                                NEXT     *   |       CHARACTER
DAT41                                NEXT     *   |       CHARACTER
DAT42                                NEXT     *   |       CHARACTER
DAT43                                NEXT     *   |       CHARACTER
DAT44                                NEXT     *   |       CHARACTER
DAT45                                NEXT     *   |       CHARACTER
DAT46                                NEXT     *   |       CHARACTER
DAT47                                NEXT     *   |       CHARACTER
DAT48                                NEXT     *   |       CHARACTER
DAT49                                NEXT     *   |       CHARACTER
DAT50                                NEXT     *   |       CHARACTER

value used for ROWS parameter changed from 10000 to 717

Table TJRB:
  7552 Rows successfully loaded.
  0 Rows not loaded due to data errors.
  0 Rows not loaded because all WHEN clauses were failed.
  0 Rows not loaded because all fields were null.


Space allocated for bind array:                9989244 bytes(717 rows)
Read   buffer bytes:10000000

Total logical records skipped:          0
Total logical records read:          7552
Total logical records rejected:         0
Total logical records discarded:        0

Run began on Wed Aug 25 09:14:14 2010
Run ended on Wed Aug 25 09:14:15 2010

Elapsed time was:     00:00:01.21
CPU time was:         00:00:00.36

这一句：
Space allocated for bind array:                9989244 bytes(717 rows)
明明白白是绑定数组。

[ 本帖最后由 yulihua49 于 2010-8-25 10:03 编辑 ]

yulihua49

要练数组插入，就用数组的程序，这样才公平：
time ./t_OAD -f ld.ini tjrb <TJ.txt

real    0m0.565s
user    0m0.140s
sys     0m0.020s

它是1.22秒，我是0.565秒，我已超过了它。可见DAU的性能。

我是1000条一组，可能不太公平，待会PK一个公平的。
5 t_OAD:16077 08/25 09:29'29 OAD_mk_ins sth=0,INSERT INTO TICKET.tjrb (TJDATE,UNIT,TABNAME,FLG,DAT1,DAT2,DAT3,DAT4,DAT5,DAT6,DAT7,DAT8,
DAT9,DAT10,DAT11,DAT12,DAT13,DAT14,DAT15,DAT16,DAT17,DAT18,DAT19,DAT20,DAT21,DAT22,DAT23,DAT24,DAT25,DAT26,DAT27,DAT28,DAT29,
DAT30,DAT31,DAT32,DAT33,DAT34,DAT35,DAT36,DAT37,DAT38,DAT39,DAT40,DAT41,DAT42,DAT43,DAT44,DAT45,DAT46,DAT47,DAT48,DAT49,DAT50)
VALUES (TO_DATE(:1,'YYYY-MM-DD'), :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :14, :15, :16, :17, :18, :19, :20, :21, :22, :23, :24, :25, :26, :27,
:28, :29, :30, :31, :32, :33, :34, :35, :36, :37, :38, :39, :40, :41, :42, :43, :44, :45, :46, :47, :48, :49, :50, :51, :52, :53, :54)
2 t_OAD:16077 08/25 09:29'30 loadasc:load 7552 rec's time=266200,buf=2006.01.31
5 t_OAD:16077 08/25 09:29'30 loadfile:7552 commit TIMEVAL=633,ret=0

从日志看，操作只用0.227秒，比他的1.21秒快了N多倍。
它在加载这样一个中等规模的数据记录的表，带着一个复合主键的批量插入性能达到了每秒33268行。
备注：这次使用了新选项：alter session commit_write =  NOWAIT
还需要用存储过程PK一下？

当然，高性能应该归功于OCI，但可以说明，DAU的包装效率要高于sqlldr的包装效率。
而且，sqlldr只是个实用程序，DAU是个开发平台，它可以让你写出许许多多的高效率应用程序。

[ 本帖最后由 yulihua49 于 2010-8-25 10:00 编辑 ]