看我做的数据库包装器

newkid

唉！叫我怎么说你呢！作为一个老程序员，你不知道什么是有价值的调试信息？我自己写的程序还需要你再贴吗？
我需要的是：
错误信息：SHOW ERROR PROCEDURE make_seats;

里面总共两个INSERT一个MERGE, 我猜测出在后面的INSERT和MERGE,无非就是表结构问题。
你需要把两个表的结构列出来：
seat
pre_seat_index

yulihua49

原帖由 newkid 于 2009-6-29 23:05 发表
唉！叫我怎么说你呢！作为一个老程序员，你不知道什么是有价值的调试信息？我自己写的程序还需要你再贴吗？
我需要的是：
错误信息：SHOW ERROR PROCEDURE make_seats;

里面总共两个INSERT一个MERGE, 我猜测出在后面的INSERT和MERGE,无非就是表结构问题。
你需要把两个表的结构列出来：
seat
pre_seat_index

编过去了，里边有两个字符是汉字的，改过来了。
现在还没运行，怕把席位库搞乱了。
一会把表exp出来试试。

yulihua49

原帖由 yulihua49 于 2009-6-30 09:09 发表

编过去了，里边有两个字符是汉字的，改过来了。
现在还没运行，怕把席位库搞乱了。
一会把表exp出来试试。

请教newkid,测试发现ORACLE服务器只有cpu0忙，其余都空闲，如何把负载均匀分布到4个CPU？

newkid

单个CPU的情况下表现怎样？我觉得是足以满足你的需求了，杀鸡焉用牛刀。
如果要利用多个CPU就把任务拆分。建立多个连接同时运行存储过程，给予互不交叉的参数，比如生成不同日期的票。
还有就是用PARALLEL HINTS, 但我觉得这个SQL用不上并行选项。
并行选项本质上是不可扩缩、不环保的，它的应用情景是单用户，比如你在维护时段运行大型DDL, 或大规模ETL操作，前提就是一个用户可以支配所有的资源。

yulihua49_cu

原帖由 newkid 于 2009-6-30 21:23 发表
单个CPU的情况下表现怎样？我觉得是足以满足你的需求了，杀鸡焉用牛刀。
如果要利用多个CPU就把任务拆分。建立多个连接同时运行存储过程，给予互不交叉的参数，比如生成不同日期的票。
还有就是用PARALLEL HINTS, 但我觉得这个SQL用不上并行选项。
并行选项本质上是不可扩缩、不环保的，它的应用情景是单用户，比如你在维护时段运行大型DDL, 或大规模ETL操作，前提就是一个用户可以支配所有的资源。

问了ORACLE了，他们说ORACLE没管CPU，是系统管的。应用太稀疏，一个请求完了另一个请求才来，所以总是使用1个CPU。
我用两个客户端，各放1000个请求过来。
TUXEDO服务器，CPU0=58% CPU1=38%。ORACLE服务器CPU0=20%，CPU1有时跳出个0.几%。
总之数据库负载很轻，这样的TUXEDO服务器，我这个数据库服务器可以轻松带动20个。

[ 本帖最后由 yulihua49_cu 于 2009-7-2 15:21 编辑 ]

newkid

闹了半天你是不是在说我的存储过程？我的写法运行起来到底效果怎么样？
你这种规模的应用，把所有计算逻辑放到数据库去也不会增加多少负载。一个应用服务器足矣，再多也是浪费。

qingyun

原帖由 newkid 于 2009-7-3 00:47 发表
闹了半天你是不是在说我的存储过程？我的写法运行起来到底效果怎么样？
你这种规模的应用，把所有计算逻辑放到数据库去也不会增加多少负载。一个应用服务器足矣，再多也是浪费。

不用存储过程，也是通过SQL来访问数据库，大部分开销都是在数据查询或存储上；
我怎么也搞不明白，用存储过程或通过其他手段操作数据库有什么本质区别；
我个人认为的本质区别是：
   存储过程可以一个复杂的业务通过封装成成百上千条SQL一次性提交给服务器执行后返回结果；
   而其他手段，比如中间件之类， 执行一个复杂的业务，就是只不过把这些成百上千条SQL封装一下(比如HiberNate，本质也是SQL)；一条一条的在数据库服务器和中间服务器之间而回传递；数据库服务器和中间服务器都是上千次的来回传递加大了彼此的消耗；何来的资源节约，效率提高，CPU的负载平衡(可能也只是中间层的平衡而已)；

这就好比领导分配一件事情：
   存储过程的做法，就是接受命令后，自己埋头去一步一步的做；做好了后把结果告诉领导；
   而所谓的中间件做法就是，领导下达一个命令后，员工做一步要提交文档告诉领导，领导看好后再下达下一个指示，以此往复多次，最终完成这件事情；
  第一种做法，没有大量的中间反馈；效率高，领导很轻松，员工也不累；
  第二种做法，大量无谓的中间过程；领导和员工都很累；
  而且如果这件事以后有了改进做法，也是第一种做法方便改进；

[ 本帖最后由 qingyun 于 2009-7-3 09:06 编辑 ]

〇〇

5分钟内如何插入40万条以上的数据？
用sqlldr

〇〇

原帖由 qingyun 于 2009-7-3 09:03 发表


不用存储过程，也是通过SQL来访问数据库，大部分开销都是在数据查询或存储上；
我怎么也搞不明白，用存储过程或通过其他手段操作数据库有什么本质区别；
我个人认为的本质区别是：
   存储过程可以一个复杂的业务通过封装成成百上千条SQL一次性提交给服务器执行后返回结果；
   而其他手段，比如中间件之类， 执行一个复杂的业务，就是只不过把这些成百上千条SQL封装一下(比如HiberNate，本质也是SQL)；一条一条的在数据库服务器和中间服务器之间而回传递；数据库服务器和中间服务器都是上千次的来回传递加大了彼此的消耗；何来的资源节约，效率提高，CPU的负载平衡(可能也只是中间层的平衡而已)；

这就好比领导分配一件事情：
   存储过程的做法，就是接受命令后，自己埋头去一步一步的做；做好了后把结果告诉领导；
   而所谓的中间件做法就是，领导下达一个命令后，员工做一步要提交文档告诉领导，领导看好后再下达下一个指示，以此往复多次，最终完成这件事情；
  第一种做法，没有大量的中间反馈；效率高，领导很轻松，员工也不累；
  第二种做法，大量无谓的中间过程；领导和员工都很累；
  而且如果这件事以后有了改进做法，也是第一种做法方便改进；

一位网友的签名
优选语言顺序
sql plsql java c 放弃，tom也是这么说的

yulihua49_cu

原帖由 newkid 于 2009-7-3 00:47 发表
闹了半天你是不是在说我的存储过程？我的写法运行起来到底效果怎么样？
你这种规模的应用，把所有计算逻辑放到数据库去也不会增加多少负载。一个应用服务器足矣，再多也是浪费。

你的存储过程今天有了测试结果。我把库清了测的。
time ora <sql/exseat.sql

SQL*Plus: Release 10.2.0.3.0 - Production on Fri Jul 3 15:04:59 2009

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL>   2    3    4  
PL/SQL procedure successfully completed.

SQL> SQL> Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

real    0m4.580s
user    0m0.012s
sys     0m0.012s

我的程序：
tuxticket@jgbticket:~> time xwfb.sh

real    0m4.071s
user    0m0.812s
sys     0m0.448s

二者都是发布了22556个席位，你的程序没有发出余额，我的有228个余额记录。速度算是差不多吧。每次执行时间都不同，离散度超过了我们的差别。
但我的程序CPU开销明显大。
因为这是一个库对库的程序，存储过程具有明显优势。

你的程序，计算量非常小，基本都是IO(<4.556)，我的计算量较大，IO(<2.757)相对小一点。

[ 本帖最后由 yulihua49_cu 于 2009-7-3 15:58 编辑 ]