谢谢你的细心观察,你述说的现象为我们技术支持提供了一个特殊的问题环境。我们的系统本来就加了一个机制(预先占用日志文件夹所在盘4M空间),防范因系统写数据操作日志时磁盘空间不足而导致最后操作失败问题。如果写日志文件时发现硬盘空间不足,服务器会将最后操作写入预留空间,并给前端返回系统挂起信息,拒绝前端再次操作服务器。
但这种方式,无法防范操作系统所在盘符空间不足引起的操作系统及其相关应用服务挂起的问题。所以,严格来说,务必保持服务器磁盘空间富裕以防范某些不可预知的错误。
那么,你反映的服务器C盘下有一个很大的日志文件,不知是什么文件?可惜你把它删除了。以后,遇到这类情况,最好将这个文件备份下来告诉我们,以便帮你分析是什么原因导致这个文件庞大。
提供几个可能性,请看是否跟你那边情况一致:
1、这个文件是否位于winnt目录下,名叫MEMORY.DMP?如果是它,这是一个操作系统记录系统某些故障、包括内存条等硬件故障的调试信息的转储文件(服务器蓝屏时,就会写入相关信息)——这个调试信息是为微软提供的,对于普通应用甚至编程人员来说,基本没用。但因你们的服务器陈旧,磁盘空间本来就比较紧张,服务器可能经常出现非正常故障,假如你们系统设置的是遇故障时“完全内存转储”,就可能导致这个文件积累的非常大。可以试着在“我的电脑”上执行鼠标右键菜单“属性”,在系统“高级”特性“启动和故障恢复”中,将“写入调试信息”设置成“无”。
2、另外,SQL的日志文件,也可能因某些特殊的原因导致文件庞大。
3、IIS的日志文件,也有可能因某些特殊的原因导致文件庞大。可以到WINNT\system32\LogFiles中把之前的大文件删除。删除前做好备份,万一需要分析原因就用得上了——比如分析是否有网站被攻击信息等。
再次提醒,遇到问题,一定要把导致问题的罪证及祸首保留下来,“毁尸灭迹”就不利于分析软、硬件故障。
并且,请配合我们完成以下工作,以便我们更有针对性替你们分析故障原因:
1、在服务器的管理工具“事情查看器”中,将“应用程序日志”、“系统日志”、“digitalplatform”三个日志信息都导出为文本格式(.txt)——在这三个日志节点上,执行右键菜单中的另存日志文件功能,选择保存类型为“文本(以制表符分隔)”。
2、打开我们系统的数据目录,比如图书馆应用服务的数据目录为dp2library_data,找到其中的log目录,将其中的所有文本文件拷贝出来。
3、将数字资源服务的数据目录,比如rms_data,中的log目录,将其中的log.txt文件拷贝出来。
4、把前三步得出的所有文件,压缩为一个文件,发到我电子邮箱中来。
最后,还是建议贵校为贵馆更换一个稍好点的电脑作服务器吧。