OK,我知道你的意思了。
出现这个问题的原因是在存储过程中,你用了GO命令,这样的话
SQL Server会将以上的代码作为事务一次性提交,这就等于在执
行一个事务。事务的执行要经过处理通道,会使处理过程变得非
常之慢,但会给出详细的执行信息。(我曾经是过一个非事务存
储过程用了35秒左右,作为事务共用了1小时25分钟)
如果你能过保证这个存储过程在程序运行时的正确和健壮,去掉
GO,就可以将执行时间大大缩短!
出现这个问题的原因是在存储过程中,你用了GO命令,这样的话
SQL Server会将以上的代码作为事务一次性提交,这就等于在执
行一个事务。事务的执行要经过处理通道,会使处理过程变得非
常之慢,但会给出详细的执行信息。(我曾经是过一个非事务存
储过程用了35秒左右,作为事务共用了1小时25分钟)
如果你能过保证这个存储过程在程序运行时的正确和健壮,去掉
GO,就可以将执行时间大大缩短!
下例将锁超时期限设置为 1,800 毫秒。
SET LOCK_TIMEOUT 1800把这个@@LOCK_TIMEOUT 加大试试
GO 一编好存储过程,确定后系统就自动加上。怎么去掉?而用:
declare @now_time varchar(5)
set @now_time=convert(char(5),getdate(),8)
insert into web_send (phone,msgcontent,tocode) select mobile_id,msg_cont,tocode
from it_198 where send_time=@now_timeupdate project_send set al_send_time=it_198.info_data_uptime from it_198 where
it_198.send_time=@now_time and project_send.tocode=it_198.tocode
这几个语句在SQL查询分析器中运行则有正常结果。
SQL Server Scheduled Job '调度' (0xA2F559105C09B74E8FF1ED758AA82DDA) - Status: 失
败 - Invoked on: 2003-05-22 10:30:01 - Message: 作业失败。 调度 27 (1) 唤醒调用了
该作业。最后运行的步骤是第 1 步(1)。
按理好像不是超时引起,以下就是原先的存储过程,而且失败过:
CREATE PROCEDURE test
as
declare @mobile_id varchar(100)
declare @msg_cont varchar(200)
declare @tocode varchar(100)
declare @info_data_uptime varchar(100)
declare @now_time varchar(5)
set @now_time=convert(char(5),getdate(),8)
print @now_time
declare CustCursor scroll Cursor for
select tocode,mobile_id,info_data_uptime from it_198 where
send_time=convert(char(5),getdate(),8) and (substring(it_198.tocode,1,2)<>'01')
open CustCursor
fetch next from CustCursor
into @tocode,@mobile_id,@info_data_uptime
insert into web_send (phone,msgcontent) select mobile_id,msg_cont from it_198
where (send_time=@now_time) and (substring(it_198.tocode,1,2)<>'01')
while (@@fetch_status=0)
begin
update project_send set al_send_time=@info_data_uptime where tocode=@tocode and mobile_id= @mobile_id
fetch next from CustCursor
into @tocode,@mobile_id,@info_data_uptime
end
close CustCursor
deallocate CustCursor
GO当运行:
insert into web_send (phone,msgcontent) select mobile_id,msg_cont from it_198
where (send_time=@now_time) and (substring(it_198.tocode,1,2)<>'01')
看表web_send 的结果是看到的24000条记录进web_send 表仅用几秒慢的没超过20秒。
主要是后面的语句特别是
update project_send set al_send_time=@info_data_uptime where tocode=@tocode
and mobile_id= @mobile_id
语句在运行占时间。
set al_send_time=@info_data_uptime
where tocode=@tocode and mobile_id= @mobile_id
fetch next from CustCursor //游标使用肯定会很慢
into @tocode,@mobile_id,@info_data_uptime
to pengdali(大力 V2.0):
我的系统设置的“查询超时”就是0
as
declare @mobile_id varchar(100)
declare @msg_cont varchar(200)
declare @tocode varchar(100)
declare @info_data_uptime varchar(100)
declare @now_time varchar(5)
set @now_time=convert(char(5),getdate(),8)
print @now_time
insert into web_send (phone,msgcontent) select mobile_id,msg_cont from it_198
where (send_time=@now_time) and (substring(it_198.tocode,1,2)<>'01')
update project_send set al_send_time=a.info_data_uptime from it_198 a
where a.send_time=convert(char(5),getdate(),8) and a.tocode like '01%' and
project_send.tocode=a.tocode and project_send.mobile_id=a.mobile_id---两句搞定
在:
http://expert.csdn.net/Expert/topic/1846/1846518.xml?temp=.6306574
分给大力了。
结账!