access数据库过大导致IIS6出错.docVIP

ACCESS数据库过大导致IIS6出错 浙江 戴峰 出现问题 单位的网页服务器用的是windows2003企业版操作系统（全新安装，确保系统无问题），网页采用的是asp程序+access数据库，利用系统自带的IIS6提供服务，网页程序从原来的windows2000服务器版+IIS5迁移到现在的windows2003 + IIS6后，配置好IIS6，访问一切正常，一段时间以后，访问主页时就出现“Service Unavailable”的提示，网页无法显示，查看IIS6的配置，一切正常，只有重新启动系统才能正常访问网站。并且重新启动后登录windows2003系统时会出现一个消息对话框如图1，大概意思是com surrogate 程序由于数据执行保护已被windows关闭，按“关闭消息”按钮后，又会弹出一个错误报告对话框，如图2 。一般情况下如图1、图2这样的对话框会出现很多组，即不同的时间点产生的错误。 （图1） （图2） 问题解决过程 1、查配置：以为是IIS6的配置问题，于是调整IIS6里的应用程序池——defaultappPool的属性，包括回收工作进程的时间、内存回收等设置。更改设置后还是出现同样问题。 考虑到原来在IIS5平台上运行的还算稳定（偶尔出现asp网页无法访问的情况，重新启动一下服务器就行了），于是将IIS6配置成以IIS5的隔离模式运行（右键单击“网站”——选择“属性”——点“服务”标签，将“隔离模式”勾上）。运行一段时间后出现html网页可以访问，asp网页无法访问并提示“内部服务器错误”的情况，重新启动系统后又出现若干组如图1、图2的对话框，随后ASP网页又可以访问了。首先程序是肯定没问题的，因为已经经过了长期使用，只能又开始排查系统问题。 2、查系统：查看“事件查看器”，系统日志及安全性日志均无异常记录，只有应用程序日志里有很多条警告性的记录“来源：W3SVC-WP ，事件ID： 2337 ，描述：进程外应用程序/LM/W3SVC/1座机电话号码3/Root意外终止”，也就是IIS出现问题的记录。对解决问题没什么帮助。 由于重启后有提示是com surrogate 程序出错，于是上网搜索及到网管员世界论坛求助，根据搜索到的信息及论坛网友的说法，可能是vbscript.dll 有问题，于是到正常系统里重新拷贝一个vbscript.dll文件覆盖到系统目录下，并用命令 regsvr32 重新注册VBSCRIPT控件。试用后IIS6还是出现相同问题。 3、查访问日志：考虑到可能是受到网络攻击导致IIS出错，于是检查com surrogate 程序出错的时间点的网站访问日志，这里要注意的是网站日志文件中使用的是格林尼治标准时间，所以日志记录中的时间要加上8小时才跟计算机的系统时间吻合。仔细检查了程序出错时网站访问日志的对应时间点的记录，都是正常访问，未发现异常。 4、查网站内容：系统没问题，又不是网络攻击，只能把目光放到网站代码上。由于IIS6出错时是ASP网页无法访问，而ASP网页的代码是没有动过的，只有后台访问的ACCESS数据库文件是有更新的。于是开始检查网站的ACCESS数据库，网站平台用的是免费代码（由新闻、博客、论坛三个系统组成），主要有三个ACCESS文件，检查后发现博客系统的ACCESS数据库文件有500M多，超大，博客系统总共用户才100多个，而且经常在写博文的用户只有20来个，文章总数也就2000多，按道理是不可能占用这么大容量的。这个数据库文件肯定有问题，将它下载下来后打开，里面有20多个表，也不知道为什么占这么多容量，只有一个个打开来看一下，到底哪个表里的记录这么多，当打开oblog_trackback这个表时，电脑好长一段时间没有响应，一看，记录足足有80多万条，看过去都是一些垃圾信息。去OBLOG论坛咨询后得知，oblog_trackback这个表是用来存放引用通告记录的，可以在博客系统的后台管理里将引用通告功能关闭，就不会有引用信息存放到这个表中了。由于这个表中记录实在太多，多次尝试删除，电脑都处于无响应状态，于是新建了一个ACCESS数据库，将其他表拷贝到新的库中，oblog_trackback这个表就直接在新的库中新建一个，结构参照原表。完成瘦身后博客系统的ACCESS数据库才60M多，这才像样嘛。上传到服务器，覆盖原来500M多的数据库文件，并进入博客后台管理，关闭引用通告功能。经测试若干天后，网站访问一直正常，再也没有出现ASP网页无法访问的问题。 问题回顾分析 ACCESS是小型网站常用的数据库，而且免费的ASP代码系统都是采用ACCESS为后台数据库，虽说根据资料显示ACCESS最大容量支持到2G，但是考虑到脚本代码访问数据库的响应时间、内存需求等问题,网站的A