百分求:如何提高大事务执行效率 '时间太长,1个5w条左右的事务执行完毕平均3分钟以上(我的pc需要7分半,用户的服务器需要3分钟)'感觉楼主的这个速度已经不慢了,呵呵我们的软件,某些事务只有300行左右,也得20秒左右.似乎比楼主的还慢.另外,楼主的事务也太大了,没有别的方法解决吗? 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 zjcxc(邹建) //这么宠大的事务, 首先想到的已经是设计不合理了.邹哥: 是这样,每一条sql语句本身就是insert或者update一条数据,从用户拿来的内容是一个报文,报文本身就是平均几万行信息,而我们采取的就是把所有的翻译完毕以后一起执行,考虑到事务的完整性,我们可以不用保证提交的事务之间产生冲突.当然这个方案是可以修改的,我自己的思想是如何把事务变成小事务集合,且最终用自己的机制保证这个没有具体化的大事务.这个我想是可以实现的.//无论是否用事务, 这样大量的处理, 可能实现到这个要求吗?这个可能是我的经验不足,不知道服务器的性能极限是什么样子的,我把这个东西量化一下.我的破机器是sy2.4+512m,自己作sqlserver服务器,测试一个35000行语句的报文,一起提交执行不完就终止了,报内存不够的错误,而运行态cpu开始的时候饱和90%以上,后来常驻1G内存cpu很低,瓶颈明显是内存.而我单独拿出3000行一下代码执行,大概是每秒100行,线性分布.这样3w行代码的理论时间在我的机器上就是300″=5分钟在10块cpu以上10G内存以上的客户机器上,理论值可达到多少呢? netcup(茶杯) 见我上面的补充,呵呵,明显我对问题描述依然少了关键一句,一条语句仅insert或者update一条记录(非同表,最多可能20张表以上,树形层次结构的) 没有理论值, 因为你考虑的都是理想状况, 而且只跑你的这个事务处理, 另外, 你的语句还要求能在多个cpu上并行运行, 才能发挥多个cpu的功效 一次insert几万行不是难事吧? 直接用bcp导入, 不要insert一条一条插入一次update几万行, 如果每行数据量不大, update也不会太慢.而最关键的是, 这些似乎都只要一条语句就完成了, 怎么会需要多条语句呢? 你的方案不会是开启一个事务, 然后程序中翻译, 翻译完一条, 处理一条, 最终才提交事务吧? zjcxc(邹建)一次insert几万行不是难事吧? 直接用bcp导入, 不要insert一条一条插入一次update几万行, 如果每行数据量不大, update也不会太慢.而最关键的是, 这些似乎都只要一条语句就完成了, 怎么会需要多条语句呢? 你的方案不会是开启一个事务, 然后程序中翻译, 翻译完一条, 处理一条, 最终才提交事务吧?------------------------------------------------------------------------------------是这样的:我把整个背景讲一下我做的内容是EDI(电子数据交换).就是用户其它合作公司将其数据生成为平面文件(报文),用户接收到以后用我的程序把平面文件再次展开,生成对应的业务数据,双方合作公司的业务表完全不透明,无法直接导出导入,只能通过报文解析到数据库临时结构表中,再由翻译程序翻译到业务库中,而我做的内容就是把平面文件(报文)解析到数据库临时结构表中的工作.报文大小依合作公司业务内容大小来定,数量依sum(合作公司.办事处)来定,所以大公司,大点报文内容相当大.另一背景:报文结构随时可能变化,所以整个解析过程建立在结构定义基础上的,不能写死代码对报文进行逐行翻译.(此处可作为参考)由于整个临时结构库是树状的表结构,即总表对多个子表,每一个子表又可能对其它多个子表,层数和子表树均有报文结构决定,所以我用事务完成这个功能的时候使用了IDENT_CURRENT()系统函数,通过这个函数去知道当前上一级的id,然后进行整个树形结构深度和广度的遍历,正因为事务本身的特性,保证了IDENT_CURRENT()函数可以完成这个id的正确赋值,如果离开事务,这个就必然会产生冲突.而生成bcp恐怕是非常困难的事情,我们所作的事情本身就是去生成这些数据,如果有了这些数据生成的bcp文件,那么根本不需要再做上面的问题了.不知道这么解释你能不能更了解现在我面临的问题 我举个例子吧...因为不能透露太多内容,我只把一篇报文的前六行粘贴出来/////////////////////以下报文原文///////////////////////////////////UNB+UNOA:2+dcilxia+165014072+060603:1012+EB200606010080'UNH+EB200606010080+IFTMCS:D:96B:UN'BGM+786+KINNEB200606010080+9'DTM+182:20060603:102'TSR+11'RFF+BM:SYFZJHJX6217479::1'///////////////////以下是程序生成的语句/////////////////////////////insert into edi_iftmcs_head( edifile,UNH_0062,UNH_s009_0065,UNH_s009_0052,UNH_s009_0054,UNH_s009_0051) values (IDENT_CURRENT('edi_importrecord'),'EB200606010080','IFTMCS','D','96B','UN') ;update edi_iftmcs_head set BGM_c002_1001='786',BGM_c106_1004='KINNEB200606010080',BGM_1225='9' where id = IDENT_CURRENT('edi_iftmcs_head');insert into edi_iftmcs_head_dtm( parent_id, dtm_c507_2005,dtm_c507_2380,dtm_c507_2379) values (IDENT_CURRENT('edi_iftmcs_head'),'182','20060603','102') ;insert into edi_iftmcs_head_tsr( parent_id, tsr_c536_4065) values (IDENT_CURRENT('edi_iftmcs_head'),'11') ;insert into edi_iftmcs_head_g3( parent_id, RFF_c506_1153,RFF_c506_1154,RFF_c506_1156,RFF_c506_4000) values (IDENT_CURRENT('edi_IFTMCS_head'),'BM','SYFZJHJX6217479',null,'1') ;说明:报文结构由独力机构统一定义,我们只能做微调.报文结构相当庞大,光定义报文的元素现在只有6种格式的报文就由1750种不同元素的累加,所以,如果写死代码去维护报文导入是不可能的.很抱歉我无法将报文格式定义粘贴出来,不好粘贴,如果希望看到,可以google IFTMCS也许可以得到一定信息. 下班前顶一下,现在我在考虑是否可以把这个东西向bcp导入方向转了,如果可以的话速度就会不成任何问题,希望可以成功. 我决定先按照邹建的意见,用bcp进行导入,我把生成sql语句的函数进行一下改造,让它生成一系列的bcp数据文件,然后统一生成一个bcp的bat文件,然后顺序导入得了,估计这个工作要几天时间,等我完成以后回来报告一下结果,然后再给分啊!想看一下结果的就一下,我会尽量把函数贴出来,大家研究.也希望能给大家带来一点有益的东西.promise:周五出结果.这几天就do它了. 雏形已经做完了,其实就是一个生成bcp文件的过程,现在对于错误检验还没有实现,不过不准备在这个帖子中问了.基本问题已经解决,思路就是把原来生成sql脚本的功夫拿出来生成bcp文件,只要有数据的就暂时放在一个数组中,根据系统库中表的字段排序方式把这个数组重新排序,如果某字段没有数据则直接tab跳过,因为语法太具体,也没有啥经典之处,我就不帖了,如果有想交流的,可以给我发email:[email protected] 解决了吗？我也遇到类似的问题MSN:[email protected] 如何去掉年份相同而月份与天数不同的记录？不用临时表，就用select语句 sql2005实现行列转换问题 Select 怎样格式化输出字符串 一个复杂的sql语句，求指点 请教大侠一个有关视图的问题 高手求救：上次的提问没人能够解决，这次加分，关于大小写问题！在线等待！ .mdl是什么文件格式 怎样得到数据库里所有用户表的表名和各字段名? 怎样把 *.db的文件导入sql server 我问一个深一点的问题，关于数据库的。。。 不同服务器向同一个服务器发送相同的请求,结果运行时间相差巨大,不明白,在线=答案 求一存储过程，急！急！急！谢了，谢了，
//这么宠大的事务, 首先想到的已经是设计不合理了.
邹哥: 是这样,每一条sql语句本身就是insert或者update一条数据,从用户拿来的内容是一个报文,报文本身就是平均几万行信息,而我们采取的就是把所有的翻译完毕以后一起执行,考虑到事务
的完整性,我们可以不用保证提交的事务之间产生冲突.
当然这个方案是可以修改的,我自己的思想是如何把事务变成小事务集合,且最终用自己的机制保证这个没有具体化的大事务.这个我想是可以实现的.
//无论是否用事务, 这样大量的处理, 可能实现到这个要求吗?
这个可能是我的经验不足,不知道服务器的性能极限是什么样子的,我把这个东西量化一下.
我的破机器是sy2.4+512m,自己作sqlserver服务器,测试一个35000行语句的报文,一起提交
执行不完就终止了,报内存不够的错误,而运行态cpu开始的时候饱和90%以上,后来常驻1G内存
cpu很低,瓶颈明显是内存.而我单独拿出3000行一下代码执行,大概是每秒100行,线性分布.
这样3w行代码的理论时间在我的机器上就是300″=5分钟
在10块cpu以上10G内存以上的客户机器上,理论值可达到多少呢?
见我上面的补充,呵呵,明显我对问题描述依然少了关键一句,一条语句仅insert或者update一条记录(非同表,最多可能20张表以上,树形层次结构的)
你的方案不会是开启一个事务, 然后程序中翻译, 翻译完一条, 处理一条, 最终才提交事务吧?
一次insert几万行不是难事吧? 直接用bcp导入, 不要insert一条一条插入一次update几万行, 如果每行数据量不大, update也不会太慢.而最关键的是, 这些似乎都只要一条语句就完成了, 怎么会需要多条语句呢?
你的方案不会是开启一个事务, 然后程序中翻译, 翻译完一条, 处理一条, 最终才提交事务吧?
------------------------------------------------------------------------------------
是这样的:我把整个背景讲一下
我做的内容是EDI(电子数据交换).就是用户其它合作公司将其数据生成为平面文件(报文),用户接收到以后用我的程序把平面文件再次展开,生成对应的业务数据,双方合作公司的业务表完全不透明,无法直接导出导入,只能通过报文解析到数据库临时结构表中,再由翻译程序翻译到业务库中,而我做的内容就是把平面文件(报文)解析到数据库临时结构表中的工作.报文大小依合作公司业务内容大小来定,数量依sum(合作公司.办事处)来定,所以大公司,大点报文内容相当大.
另一背景:报文结构随时可能变化,所以整个解析过程建立在结构定义基础上的,不能写死代码对报文进行逐行翻译.(此处可作为参考)
由于整个临时结构库是树状的表结构,即总表对多个子表,每一个子表又可能对其它多个子表,层数和子表树均有报文结构决定,所以我用事务完成这个功能的时候使用了IDENT_CURRENT()系统函数,通过这个函数去知道当前上一级的id,然后进行整个树形结构深度和广度的遍历,正因为事务本身的特性,保证了IDENT_CURRENT()函数可以完成这个id的正确赋值,如果离开事务,这个就必然会产生冲突.
而生成bcp恐怕是非常困难的事情,我们所作的事情本身就是去生成这些数据,如果有了这些数据生成的bcp文件,那么根本不需要再做上面的问题了.
不知道这么解释你能不能更了解现在我面临的问题
因为不能透露太多内容,我只把一篇报文的前六行粘贴出来
/////////////////////以下报文原文///////////////////////////////////
UNB+UNOA:2+dcilxia+165014072+060603:1012+EB200606010080'
UNH+EB200606010080+IFTMCS:D:96B:UN'
BGM+786+KINNEB200606010080+9'
DTM+182:20060603:102'
TSR+11'
RFF+BM:SYFZJHJX6217479::1'
///////////////////以下是程序生成的语句/////////////////////////////
insert into edi_iftmcs_head( edifile,UNH_0062,UNH_s009_0065,UNH_s009_0052,UNH_s009_0054,UNH_s009_0051) values (IDENT_CURRENT('edi_importrecord'),'EB200606010080','IFTMCS','D','96B','UN') ;
update edi_iftmcs_head set BGM_c002_1001='786',BGM_c106_1004='KINNEB200606010080',BGM_1225='9' where id = IDENT_CURRENT('edi_iftmcs_head');
insert into edi_iftmcs_head_dtm( parent_id, dtm_c507_2005,dtm_c507_2380,dtm_c507_2379) values (IDENT_CURRENT('edi_iftmcs_head'),'182','20060603','102') ;
insert into edi_iftmcs_head_tsr( parent_id, tsr_c536_4065) values (IDENT_CURRENT('edi_iftmcs_head'),'11') ;
insert into edi_iftmcs_head_g3( parent_id, RFF_c506_1153,RFF_c506_1154,RFF_c506_1156,RFF_c506_4000) values (IDENT_CURRENT('edi_IFTMCS_head'),'BM','SYFZJHJX6217479',null,'1') ;
说明:报文结构由独力机构统一定义,我们只能做微调.报文结构相当庞大,光定义报文的元素
现在只有6种格式的报文就由1750种不同元素的累加,所以,如果写死代码去维护报文导入是
不可能的.很抱歉我无法将报文格式定义粘贴出来,不好粘贴,如果希望看到,可以google IFTMCS
也许可以得到一定信息.
promise:周五出结果.这几天就do它了.
MSN:[email protected]