SharePoint 2007 计时器作业“配置刷新”错误

cyc1111

　　错误描述：
　　今天打开服务器上的虚拟机发现SharePoint的日志文件膨胀的很厉害，几乎充满了系统盘的剩余空间，而且还在不断膨胀，有的日志文件大小超过了2G，明显这很不正常，我打开这个超大的日志文件发现很多相同的错误信息，是计时器作业的其中一个。
　　错误信息如下：
　　01/08/2009 10:34:12.04     OWSTIMER.EXE (0x0DB0)                       0x0ED8    Windows SharePoint Services       Timer                             5uuf    Monitorable    由于服务“{4719D413-87A9-45B8-A649-07A3D77D5B59}”上的 ID 为“{8366652D-5F5B-49B1-BB61-037E360219E3}”的计时器作业“配置刷新”的上一个实例仍在运行，所以将跳过当前实例。请考虑增加作业的间隔时间。
　　错误解决：
　　于是去查找解决的办法。解决办法有几个相关的文章。首先我重启了SharePoint的Timer服务，然后去观察日志的情况，发现还没来得及去实验里面的步骤，这个错误信息就不出现了-_-!。我还是将查到的链接放在下面，以后备查。
　　
　　参考内容：
　　这个问题描述和我的一致，下面有人提出了几个解决问题的办法：
　　http://www.eggheadcafe.com/software/aspnet/29904212/logs-filling-up-entire-di.aspx
http://blogs.msdn.com/josrod/archive/2007/12/12/clear-the-sharepoint-configuration-cache-for-timer-job-and-psconfig-errors.aspx
　　内容：
Clear the SharePoint Configuration Cache for Timer Job and PSCONFIG errors

　　If you experience issues with WSS and MOSS timer jobs failing to complete are receiving errors trying to run psconfig, clearing the configuration cache on the farm is a possible method for resolving the issue. The config cache is where we store information about timer jobs status as well as other info.  Sometime this data can become corrupted and need to be cleared and rebuilt from our store.  
　　To clear the config cache on the farm, follow these steps:

• Stop the OWSTIMER service on ALL of the MOSS servers in the farm.
  
• On the Index server, navigate to %ALLUSERSPROFILE% \Application Data\Microsoft\SharePoint\Config\<GUID> and delete all the XML files from the directory.
  
• Edit cache.ini and reset the number in the file to 1.
  
• Start the OWSTIMER service on the Index server and wait for XML files to begin to reappear in the directory.
  
• After you see XML files appearing on the Index server, repeat steps 2, 3 & 4 on the query server(s), waiting for XML files to appear before moving to subsequent servers.
  
• After the query servers have all been cleared, proceed to the WFE and Application servers in the farm, following steps 2, 3 & 4. for each server.
  

http://social.technet.microsoft.com/Forums/en-US/sharepointadmin/thread/f1aa4891-f56d-45e3-99e1-6224ae2b6950/ 　　内容：

　　Managing SharePoint 2007 (MOSS) application log size
　　The Problem:
　　SharePoint 2007 by default stores 48 hours worth of logs in a directory buried in your program files folder (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\ !). Very few events get logged to the application event log.  
　　Expect each log file to be at least 200 megs (a log file being generated every 30 minutes by default), or 19 GB of space at the minimum being used by SharePoint logs.  
　　Solutions:
　　Go to your central administration server web site, and open up the Diagnostic logging:  Central Administration -> Operations  -> Logging and Reporting -> Diagnostic logging

  
　　In the Diagnostic logging page, focus on the following categories:  

• Event throttling: how much you log
  
• Trace Log: where you store the logs
  

　　Event Throttling:

• For a Dev/staging server server, you should log all or "medium events"
  
• For a Production server, only log errors
  
• The search crawler will take up most of the log space
  

  
　　Trace Log:

• By Default, logs are sent to: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\
  
• Store the logs on a separate drive so that at worse your drive gets full and your application stops logging, but still functions. It's a pretty standard practice for SQL server installations for instance.
  
• Reduce the number of log files. The default is two days worth of logging (96 files x 30 min intervals). See if this is too much for you; it might depend on how much you chose to log in the Event Throttling.
  

  　　还有一个办法就是用管理中心来限制日志的记录方式和修改存储位置。在管理中心——操作——日志记录和报告——诊断日志记录。有两个比较有用的设置，我就贴出来了。
　　事件限制：

　　使用这些设置可控制 Windows 事件日志和跟踪日志中捕获的事件的严重级别。随着严重级别的降低，记录的事件数将会增加。
您可以更改任何单个类别或所有类别的设置。更新所有类别将会丢失对单个类别所做的更改。
　　跟踪日志：
　　如果已启用跟踪，则可能需要将跟踪日志转到某一具体位置。注意: 指定的位置必须在服务器场中的所有服务器上存在。
此外，还可以设置要维护的最大日志文件数，以及经过多长时间后开始将事件捕获到单个日志文件中。