2007/04/20

起笑的 Office Sharepoint Server Search

最近遇到一個 Sharepoint Server Farm 無法停止 Office Sharepoint Server Search Service。

會造成資料庫連線爆增,Search Server Winsock 壞掉(詳見 【茶包射手專欄】怪異的網路問題 http://blog.darkthread.net/blogs/darkthreadtw/archive/2007/04/19/719.aspx )

印象中是當初設定 Shared Service Provider 中的搜尋排程後,才發現會有"起笑"(台語)的現象發生。

 

詳細原因還不明,不過有一些蛛絲馬跡。

 

0.從茶包射手得知, mssearch.exe 一直建立 sql connection ,用 Process Explorer 看了一下,發現是 Office Sharepoint Server Search 啟動的 process

 

1.開啟 SQL Profiler 來看, filter Database Name 為 SSP Search DB 後,發現一直重覆著執行以下指令

select collationname(0x0904100000)

 

declare @p7 int
set @p7=NULL
declare @p8 int
set @p8=NULL
exec dbo.proc_MSS_Crawl 1,7,1,170,0,0,@p7 output,@p8 output
select @p7, @p8

 

2.複製至 SQL Management Studio 查詢後發現

什麼…一個預存程序 proc_MSS_AnchorFixTargetDocid 有問題,拜 google 大神也沒有結果…

3. 後來就先改了這個 SPS SearchDB 內建的預存程序 proc_MSS_AnchorFixTargetDocid

**Line 182:

INSERT INTO MSSCrawlChangedTargetDocs (CrawlId, DocId)
SELECT @CrawlId, DocID FROM #ChangedTargetDocs

改為…

INSERT INTO MSSCrawlChangedTargetDocs (CrawlId, DocId)
SELECT distinct @CrawlId, DocID FROM #ChangedTargetDocs

**Line 185:

INSERT INTO MSSAnchorPendingChangeLog (CrawlId, TargetDocId)
SELECT distinct @CrawlId, MSSAnchorText.TargetDocId FROM MSSAnchorText
JOIN #ChangedSourceDocs
ON #ChangedSourceDocs.DocId = MSSAnchorText.SourceDocId
WHERE MSSAnchorText.TargetDocId <> -1

改為…

INSERT INTO MSSAnchorPendingChangeLog (CrawlId, TargetDocId)
SELECT distinct @CrawlId, MSSAnchorText.TargetDocId FROM MSSAnchorText
JOIN #ChangedSourceDocs
ON #ChangedSourceDocs.DocId = MSSAnchorText.SourceDocId
WHERE MSSAnchorText.TargetDocId <> -1

**Line 191:

INSERT INTO MSSAnchorPendingChangeLog (CrawlId, TargetDocId)
SELECT distinct MSSCrawlChangedTargetDocs.CrawlId, DocId FROM MSSCrawlChangedTargetDocs
WHERE MSSCrawlChangedTargetDocs.CrawlId = @CrawlId

改為…

INSERT INTO MSSAnchorPendingChangeLog (CrawlId, TargetDocId)
SELECT distinct MSSCrawlChangedTargetDocs.CrawlId, DocId FROM MSSCrawlChangedTargetDocs
WHERE MSSCrawlChangedTargetDocs.CrawlId = @CrawlId

 

改完這個預存程序後… Reset Crawl Data 重設所有編目內容 (共用服務管理 > 搜尋設定 > 編目設定-重設所有編目內容)

Yeah~~~~ 不會無法停止搜尋,也不會一直無限量建立 SQL Connection ,將 DB 搞跨。

 

不過,這只是一個治標,並非治本的作法,目前搜尋也正常,還看不出副作用,累了,查了三天了,先這樣子吧,有空再查查看囉…

 

Technorati tags: , , ,

2007/04/17

KB-SPS 2007- Unable to connect publishing custom string handler for output caching

Event Type: Error
Event Source: Office SharePoint Server
Event Category: 發佈快取
Event ID: 5785
Date: 4/17/2007
Time: 3:33:33 PM
User: N/A
Computer: WEB02
Description:
無法連線輸出快取的發佈自訂字串處理常式。IIS 執行個體識別碼為 '944661008',URL 為 'http://WEB02/Notice/CheckNotice.asp'。

 -or-

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Publishing Cache
Event ID: 5785
Date: 08.01.2007
Time: 12:34:16
User: N/A
Computer: moss-dev
Description:

Unable to connect publishing custom string handler for output caching.  IIS Instance Id is '944661008', Url is 'http://WEB02/Notice/CheckNotice.asp'.

 

由於我們自行開發的 AP 會掛在 Sharepoint 底下,如果在 Sharepoint 開啟網頁輸出快取 Output Caching 時,如果有點閱的話,就會出現如上的問題。

追查的結果在 Steven Van de Craen's Blog 的這篇文章中提及,網頁輸出快取 Output Cacing 是透由實作 IHttpModule 的 PublishingHttpModule 來控制,我們可以用 web.config 停止網頁輸出快取 Output Cacing 這個功能。

web.config
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 
    <system.web>
        <httpModules>
               <remove name="PublishingHttpModule"/>
         </httpModules>
    </system.web>
</configuration>

 

我原本很懷疑… asp 跟 web.config 有啥米關係,但是我還查不出來,有空再來追查一下。

2007/04/13

[SQL] Long Running Script Timeout expired Issue

遇到資料量大(huge data)的 table 欄位變更或者是 DB Restore 時,會出現以下訊息

Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
The statement has been terminated.

原因為 Connection Properties / Execution Timeout 過短,請重新連線 Reconnect ,並重新設定 Execution Timeout (0=never timeout)

(如果大量作業完畢,建議可以調整回預設值)

SQL_Time_Expred_Solve

2007/04/04

SharePoint Best Practices Analyzer was Available

最近在 SharePoint Product blogWilliam Baer 看到這個消息

Microsoft Best Practices Analyzer for Windows SharePoint Services 3.0 and the 2007 Microsoft Office System

可以檢查 IIS Meta , Registry (機碼) , SQL Server 等問題,我覺得對於 Server Farm 的管理者是個福音,

使用方式如下:

1.下載 BestPractiveAnalyzer.exe

Microsoft Best Practices Analyzer for Windows SharePoint Services 3.0 and the 2007 Microsoft Office System

2. 執行 BestPractiveAnalyzer.exe 解壓縮

3. 開啟命令提示字元至解壓縮目錄,執行 sharepointbpa.exe -cmd analyze -substitutions SERVER_NAME <ServerHostingCentralAdminWebApp>. <ServerHostingCentralAdminWebApp> 是管理中心的主機名稱,例如 http://spsweb:56888 為管理中心,就填入 spsweb 即可。

4. 執行完後,就會在同目錄中出現 sharepointbpa.report.htm or sharepointbpa.report(n).htm

SharePoint Product blog

http://blogs.msdn.com/sharepoint/archive/2007/04/02/best-practices-analyzer.aspx

William Baer

http://blogs.technet.com/wbaer/archive/2007/02/16/microsoft-best-practices-analyzer-for-windows-sharepoint-services-3-0-and-microsoft-office-sharepoint-server-2007-available.aspx

2007/04/02

KB-STSADM.exe export "User cannot be Found" Problem

STSADM.exe 是 WSS / SPS 超級管理者工具,日前遇到一個 site export 問題,當執行以下指令時…

STSADM.exe -o export -url http://localhost/site/A -filename a.dat

會遇到錯誤訊息

FatalError: User cannot be Found.

at Microsoft.SharePoint.SPUserCollection.GetByID(Int32 id) at Microsoft.SharePoint.SPWeb.get_Author() at Microsoft.SharePoint.Deployment.WebSerializer.GetDataFromObjectModel(Object obj, SerializationInfo info, StreamingContext context) at Microsoft.SharePoint.Deployment.DeploymentSerializationSurrogate.GetObjectData(Object obj, SerializationInfo info, StreamingContext context) at Microsoft.SharePoint.Deployment.XmlFormatter.SerializeObject(Object obj, ISerializationSurrogate surrogate, String elementName, Boolean bNeedEnvelope) at Microsoft.SharePoint.Deployment.XmlFormatter.Serialize(Stream serializationStream, Object topLevelObject) at Microsoft.SharePoint.Deployment.ObjectSerializer.Serialize(DeploymentObject deployObject, Stream serializationStream) at Microsoft.SharePoint.Deployment.SPExport.SerializeObjects() at Microsoft.SharePoint.Deployment.SPExport.Run()

拜了 Google 大神後,竟然沒有解法,只有零星的 News 中,有提到是換 Domain 問題造成,再加入舊的 Domain 執行後就成功…之類的解法。

後來…與黑暗大哥討論了之後,決定從 內容資料庫 Content DB 著手。

找到了以下幾個資料表與欄位與 User 相關,供大家尋找失聯的 User 欄位

  • AllDocs.SetupPathUser
  • AllLists.tp_Author
  • AllUserData.tp_Author
  • AllUserData.tp_Editor
  • Webs.Author
  • Versions.UserName

以上的欄位都是 Integer ,真正 User 是存在 UserInfo ,可以將失聯的 User 找另一個取代

(1073741823 似乎是 SharePoint/SYSTEM 系統帳戶,可以用這個 ID 取代失聯 UserID)

另外,匯出之前,請先清除以下項目

  • 網站動作(Site Action)->網站設定->網站管理(Tab)->內容與結構記錄檔
  • 清除資料回收筒

這個問題,我拜了三天Google大神都沒有結果,後來是黑暗大哥銷假上班才獲救...