SharePoint 2007 計時器作業“配置刷新”錯誤

錯誤描述：

今天打開服務器上的虛擬機發現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.