大数据导致DataReader.Close超时的异常

公司一个数据抓取的程序,数据量极大,读取数据的用IDataReader的Read方法来进行数据处理,
在测试的时候我想跑一部分数据后跳出循环,即break; 然后关闭datareader,但是在执行datareader.close()方法的时候出现了“超时异常”的错误, 查看了一下MSDN对Close方法的说明的备注 如下:

当使用 SqlDataReader 将关联的 SqlConnection 用于任何其他用途时,必须显式调用 Close 方法。

Close 方法填写输出参数的值、返回值和 RecordsAffected,从而增加了关闭用于处理大型或复杂查询的 SqlDataReader 所用的时间。 如果返回值和查询影响的记录的数量不重要,则可以在调用 Close 方法前调用关联的 SqlCommand 对象的 Cancel 方法,从而减少关闭 SqlDataReader 所需的时间。

原来执行Command的Cancel方法就可以解决这个问题。

 1 public void TestDataReader()
 2 {
 3     using (IDataReader reader = cmd.ExecuteReader(CommandBehavior.CloseConnection))
 4     {
 5         try
 6         {
 7             while (reader.Read())
 8             {
 9                 //处理数据
10                 //break;
11                 //处理数据
12             }
13         }
14         finally
15         {
16             cmd.Cancel();
17             reader.Close();
18         }
19     }
20 }

大数据导致DataReader.Close超时的异常,布布扣,bubuko.com

时间: 2024-12-20 06:27:45

大数据导致DataReader.Close超时的异常的相关文章

impala大数据量查询/tmp/impala-scratch创建异常

使用impala做大数据量查询distinct的时候报如下错误 WARNINGS: Create file /tmp/impala-scratch/24414dab2c19caca:e54b206c5ab149d_24414dab2c19caca:e54b206c5ab149f_91001337-9d70-4c93-84ce-e7916c1ae804 failed with errno=2 description=Error(2): No such file or directory Backe

大数据日知录:架构与算法

大数据丛书 大数据日知录:架构与算法(大数据领域专家力作,专注大数据架构和算法,全面梳理大数据相关技术) 张俊林 著   ISBN 978-7-121-24153-6 2014年9月出版 定价:69.00元 404页 16开 编辑推荐 这是一本心血之作,历时3年,质量上乘. 从架构与算法的角度,比较全面地分门别类梳理了大数据相关技术. 本书内容紧跟技术前沿,讲解深入浅出,适合大数据领域所有技术人员. 书中还列有作者优选的高质量文献,能为读者节省选择的时间,绝对值得一读. 内容提要 大数据是当前最

大数据战略需要数据中心基础架构作出的改变有哪些?

为大数据选择新的硬件.存储和其它数据中心基础设施,这是IT专业人员们所面临的新挑战.推行大数据战略的压力往往来自高层,因为管理者相信,能有效运用数据的企业将比落后者具备更大优势.大数据战略需要数据中心基础架构作出的改变主要有五点: 一.围绕大数据选择存储 在成功的大数据策略下,企业可以将来自内部的高质量数据与Hadoop挖掘自多个云供应商的低质量数据进行整合.这也就改善了业务相关数据的质量,让分散在各地的数据能组织成为具备一致和及时性的大数据资源. 大数据正在改变中央数据仓储和松耦合数据集市的决

POI读写大数据量excel,解决超过几万行而导致内存溢出的问题

1. Excel2003与Excel2007 两个版本的最大行数和列数不同,2003版最大行数是65536行,最大列数是256列,2007版及以后的版本最大行数是1048576行,最大列数是16384列. excel2003是以二进制的方式存储,这种格式不易被其他软件读取使用:而excel2007采用了基于XML的ooxml开放文档标准,ooxml使用XML和ZIP技术结合进行文件存储,XML是一个基于文本的格式,而且ZIP容器支持内容的压缩,所以其一大优势是可以大大减小文件的尺寸. 2. 大批

WCF传输过大的数据导致失败的解决办法

WCF传输过大的数据导致失败的解决办法 WCF服务默认是不配置数据传输的限制大小的,那么默认的大小好像是65535B,这才65KB左右,如果希望传输更大一些的数据呢,就需要手动指定一下缓冲区的大小了. 主要是为binding设置几个最大值属性就可以了,包括服务端和客户端均进行设置,不过配置都是一样的. <system.serviceModel> <bindings> <basicHttpBinding> <binding name="BasicHttpB

.Net中EF针对大数据量查询超时的一种优化

旧代码: --receiptIds   id集合,每次查1000左右 var mappingList = new List<FinanceSettlementMapping>(); mappingList.AddRange(SettlementMappingRepository.Entities.Include(o => o.ReceiptsTo).Include(d => d.FinanceSettlement).Where(d => receiptIds.Contains

asp.net mvc 4 json大数据异常 提示JSON字符长度超出限制的异常

今天客户突然过来找我说在后台添加了一篇超长的文章后,所有后台的文章都显示不出来了.后台的前端显示是用easyui的,返回的数据全是用json.根据客户的描述进行了同样的操作后,在firebug下发现ajax返回的异常 “序列化或JSON的JavaScriptSerializer过程中出现错误.字符串的长度超过上maxJsonLength属性设置的值” 这个异常是在执行MVC中的JsonResult的时抛出的,根据异常 的Message得知是序列化的字符串超出了maxJsonLength的限制.并

大数据平台常见异常-zookeeper

本文主要阐述大数据平台环境zookeeper常见异常和解决方案 1.Connection reset by peer异常 异常说明 我们现在项目有个任务OneMinuteDataSync是用spark将实时数据同步插入到hbase中,程序已经稳定运行很长一段时间,不过最近数据量增加比较多,任务运行一段时间后,突然僵死几个小时后,有恢复正常继续运行,如下图,任务正常运行情况下耗时15s左右,但2017-07-11 04:33:00这个批次运行了9486s,而凌晨数据量很少的,才13w左右,白天峰值

mongo大数据量更新服务端超时解决: Cursor not found, cursor id: 82792803897

默认 mongo server维护连接的时间窗口是十分钟 默认 单次从 server获取数据是101条或者 大于1M小于16M的数据 所以默认情况下,如果10分钟内未能处理完数据,则抛出该异常. 解决办法: 1. 修改每批次获取数据量的条数,即batch size: collection.find(condition).batch_size(5) 批量数需 估算十分钟内能处理的数据量 2. 延长超时时间 需显示的关闭cursor db.getCollection("unicom_jd"