BlogJava-<b>逍遥游</b> -随笔分类-项目经验http://www.blogjava.net/magicdoom/category/22015.html<h1>南哥</h1>zh-cnSun, 21 Oct 2012 16:52:09 GMTSun, 21 Oct 2012 16:52:09 GMT60数据执行保护引起的一个怪问题http://www.blogjava.net/magicdoom/archive/2007/07/28/132961.html南哥南哥Sat, 28 Jul 2007 04:21:00 GMThttp://www.blogjava.net/magicdoom/archive/2007/07/28/132961.htmlhttp://www.blogjava.net/magicdoom/comments/132961.htmlhttp://www.blogjava.net/magicdoom/archive/2007/07/28/132961.html#Feedback0http://www.blogjava.net/magicdoom/comments/commentRss/132961.htmlhttp://www.blogjava.net/magicdoom/services/trackbacks/132961.html
 查了下OCR SDK的开发手册，手册中到是提到了这个问题，给出的解决方案是把DLL和exe都放在同一个目录下，二我当前就是这么做的。奇怪的，再测copy了DLL测试DLL本身并无损坏。把DLL都copy到system32下面也一样无济于事。把当然的路径加到系统的path里面，也无效。怪事了，某非设置path要重启之后才能生效。还好现在是下班时间，把服务器重新启动了下。

重启之后立刻弹出N个对话框，ocr.exe因为遇到问题被系统数据执行保护关闭。TNN的原来是数据保护惹的祸。到数据保护里设置为只为系统进程和服务启用，再次重启果然解决问题了。这让我想起以前在安装一些InstallAnywhere打包的程序时也会遇到问题就好似数据执行保护引起的。

把程序开起来进行识别，确发现识别数量一多就会报某某内存地址不能read的错误。kao，真是一bug刚灭一bug又起啊。调了半天也没有结果，算了先回去睡觉，明天再解决。
  第二天，也就是今天 呵呵，在msn向一个同事（VB高手）请教，他也说可能是数据执行保护的问题。我又查看了下程序的日志，突然来了灵感，发现出错的有规律，有的错误是在识别同一份文件时发生的，查了下原来这份图片是png格式的，测试了下果然是png不能识别。问题解决，特写本篇blog记录下。


南哥 2007-07-28 12:21 发表评论
]]>系统调优一则http://www.blogjava.net/magicdoom/archive/2007/04/04/113486.html南哥南哥Wed, 04 Apr 2007 15:11:00 GMThttp://www.blogjava.net/magicdoom/archive/2007/04/04/113486.htmlhttp://www.blogjava.net/magicdoom/comments/113486.htmlhttp://www.blogjava.net/magicdoom/archive/2007/04/04/113486.html#Feedback1http://www.blogjava.net/magicdoom/comments/commentRss/113486.htmlhttp://www.blogjava.net/magicdoom/services/trackbacks/113486.html分析原因，根据客户的实际情况，首先排除了并发量过大的问题，其次因为图像的文件并不大，平均一页也才几十K左右，又是在内外的环境下，所以排除网络的因素。
再者考虑上线一年会不会是磁盘上存储了大量的小文件导致磁盘碎片很多，远程连接上文件服务器查看一下，磁盘碎片并不多，这个原因也被排除了。
其他会是什么方面的原因呢，想了会，突然想到会不会是数据库的问题，一查浏览图像前会执行两条sql语句，把两条sql语句单独拿出来执行，果然是这个原因。一查表的记录数已经有78万条记录了，查查对应字段的索引，晕，居然这这张表的字段都没建索引，难怪会慢了。将两个查询次数最多的字段加上索引，果然速度回复到正常的水平。看来以后对数据库的索引也要重视起来。
文章来源:http://magicdoom.blogspot.com/2007/04/blog-post.html

南哥 2007-04-04 23:11 发表评论
]]>