2007/12/25

KB-程式存取大量檔案資料夾的注意事項

最近遇到一個  case ,有一個資料夾中有超過10萬個檔案,記得檔案總管要開啟一個資料夾中含有 2 萬個檔案時,就已經無法回應,更別說排序了。

以前比較常的解決方案是從 DB 取得檔名後,直接 MOVE 檔案。

但是…如果沒有留存一份在 DB 呢?

.net 中有一個 System.IO.Directory 物件,有一個 Method 叫做 GetFiles ,可以回傳 Files 的 String Array ,

看來是很好用,不過,面臨到超過10萬個檔案的資料夾,在還沒有將 String Array 回傳時,應該就會將記憶體吃到滿載,

還可能會被 .net CLR 認為是一個發狂吃記憶體的豬頭程式,另外速度之慢,去吃一頓飯回來還不見得跑得出來。

看了一下 MSDN 中高手 Stephen Toub 的 NETMatter 專欄,有一段寫到 Directory.GetFiles 的問題與解決方式(註一)

主要是改用 Windows API 中的 FindFirstFile() 取得目錄中的第一個檔案後,再呼叫 FindNextFile() 遞迴存取檔案。

在這個專欄中,也有範例程式可以下載(註二)

實際使用後發現速度飛快,1000倍的差距一點都不誇張 (Y)。

改寫也蠻快的,由於 Stephen 了一個 FileSearcher Class ,首先很完整的 copy 至我的專案,

將原本的 Directory.GetFiles 一行打死的動作,改為 Foreach + FileSearcher.GetFiles 即可。

case 就這樣子透用 Stephen 的幫忙,很快就可以 Close ,不過裡面有很多可以再追根究抵的,例如:

SafeFindHandler , C# iterator performance (註三) .... 有空再研究囉~(掩面哭逃)

 

註一:http://msdn.microsoft.com/msdnmag/issues/05/12/NETMatters/

註二:http://download.microsoft.com/download/2/e/9/2e9bde04-3af1-4814-9f1e-733f732369a3/NETMatters0512.exe

註三:Recursive iterator performance , Recursive iterator performance, part 2 , Recursive iterator performance, part 3

 

2007/12/21

KB-ORA-14551: cannot perform a DML operation inside a query

當建立 Oracle Function 時,Build/complier 都沒有問題,但是執行就有問題,而且只有在 Select 中執行才會有問題。

create or replace function ufn_test return number is
    begin
        insert into testlog (d) values ('test');
    return 1;
end;
 
--execute
select ufn_test() as a from dual;

會出現以下訊息…

ORA-14551: cannot perform a DML operation inside a query

You need to write a separate procedure/function for executing the DML because oracle does not support executing DML inside the function.

or

cannot perform a DDL, commit or rollback inside a query or DML

後來在網路上找到很多同病相憐的人,整理一下,如果 Function 使用在 Select 語法中就會出現類似的錯誤:

  • Have OUT or IN OUT parameters
  • Commit or roll back the current transaction, create a savepoint or roll back to a savepoint, or alter the session or the system. DDL statements implicitly commit the current transaction, so a user-defined function cannot execute any DDL statements.

交易通常有幾種等級(以 COM+舉例):

  • 停用(Disabled)
  • 不支援(Not Supported)
  • 支援(Supported)
  • 必要(Required)
  • 需要新增(RequiresNew)

在 Oracle Function 中如果遇到交易的狀況,唯一的解決方式就是"需要新增"(RequiresNew),另起一個 Transaction,

可以使用 PRAGMA AUTONOMOUS_TRANSACTION; 來做。

CREATE OR REPLACE FUNCTION ufn_test RETURN NUMBER IS
    PRAGMA AUTONOMOUS_TRANSACTION;
    BEGIN
        INSERT INTO testlog(d) VALUES ('test');
    COMMIT;
    RETURN 1;
END;

 

問題就可以解決,不過要思考的地方是一致性的問題,如果會有這類的考量,建議改用 Store Procedure 來做會比較好。

才不會主程序沒有確認,在 Function 中就已經更新。

 

 

參考文章:

http://forums.oracle.com/forums/thread.jspa?threadID=598160&tstart=0

 

AUTONOMOUS_TRANSACTION Pragma

http://download.oracle.com/docs/cd/B10501_01/appdev.920/a96624/13_elems3.htm#32732

2007/12/18

KB-Toad v9 執行 Explain Plan 出現 ORA-00905 訊息

toad v9 與以前的版本有不太一樣,依之前的設定 KB-TOAD 執行 Explain Plan 遇到 ORA-0240 訊息 並不能解決問題,

仍是會出現 ORA-00905 Missing Keyword 錯誤,

經過使用 SQL Monitor 追查 Toad.exe 所使用 SQL Statment ,並與 Toad v8 做比較發現(如圖)…

SNAG-12-18-00

Toad v9 竟然會多一個 PUBLIC ,後來在 View->Toad Options-> Oracle -> General 中,將 Explain Plan 的 Schema 欄位,從原本的 PUBLIC 改為空白。

SNAG-12-18-01

 

"叮咚!!",令人感動的執行計劃就跑出來囉~

2007/10/17

KB-SPS 2007 User Profile 同步(Content and SSP)

困擾我許久的就是 <wssuc:welcome/> Welcome Control 中的顯示名稱,並不會跟 SSP(共用服務;Shared Services Provider) 中做連動,

IMG-07-10-16.002.png 

當 SSP 網站上  User Profile 做完整/累加匯入時,會寫入 SSP 資料庫(以下稱為 SSP_DB)的 UserProfile_Full 資料表中,

但是經實驗發現,Web 應用程式中頁面都是抓內容資料庫 (Content Database,以下簡稱 Content_DB)的 UserInfo 資料表,

經過與 Sharepoint MVP 十一(Andy-11) 討論後,發現 Sharepoint 2003 就有這樣子的問題,還有人寫了一個 SP 專門處理。

 

update b set b.tp_Title=a.PreferredName , b.tp_Email=isnull(a.Email,'')

from SPS_DB.dbo.UserProfile_Full a
join CONTENT_DB.dbo.UserInfo b
on b.tp_login = a.NTName and a.bDeleted='0' and b.tp_Deleted='0'
    and b.tp_Title<>a.PreferredName

 

以上跟大家分享一下 Sharepoint 2007  User Profile 同步的語法,希望大家不會用得到。

 

2009/06/25 更新

此部份,微軟已有 HotFix 修正此問題,謝謝十一的提醒

http://support.microsoft.com/kb/952683/ (2008/05/08)

The welcome name on a site is not changed as expected after you edit the name of a user profile in SharePoint Server 2007

2007/10/16

2007/09/04

KB - Oracle Client 8.05 與 10g Database Server

或許對大家而言,已經是 Common Sense ,我還是提出來分享,升級了 Oracle 資料庫後,才發現分公司許多用戶端電腦都是安裝 Oracle Client 8.05,

應該是說 8i 之前均是用 SID 連線,在 8i之後改採 SERVICE_NAME 的連線方式,偏偏10g 的資料庫天生就不支援 SID ,所以Oracle Client 8.05連線時,就會出現以下訊息:

ORA-12203: TNS:unable to connect to destination

翻成中文是

ORA-12203: TNS:未與目的地相連

接下來的 Action 就是要將 8.05 移除,接下來又接到了一堆電話,"無法移除 Oracle Client 8.05",以下提供"暴力"移除的方式,僅供參考:

 

(請先確認)已用開始->程式集->Oracle - NT版->Oracle Installer 卸裝所有Oracle產品
1.執行 regedit,選擇HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE,移除這個 key 值以下的機碼。
2.重新啟動電腦,重起後才能完全刪除 c:\orant 這個目錄(建議改名即可,日後再行刪除)

經過這次事件後,我們發現不只是 Microsoft 新產品的向下支援度不夠,連 Oracle 也是如此,未來的軟體規劃,還是儘可能的朝向 WEB or WinForm + WEB Service ,讓用戶端的環境簡化。

2007/07/21

TIPS-如何大量設定共用資料夾權限

最近 file server 要重建一台,發現共用目錄設定真是一件很複雜的事,不多,

只有 20 多個 (),對於懶人的我來說,叫我一直按右鍵,選共用,設權限,

真是要命,找了一下,發現有一個偷懶的工具,叫做 RMTShare,是 Windows NT 4.0 Resouce Kit 中的工具集,

可以至 Microsoft FTP 下載(ftp://ftp.microsoft.com/bussys/winnt/winnt-public/reskit/nt40/i386/RMTSHAR.EXE)

 

這樣子可就輕鬆了,執行一個批次檔就完成了。(果然是「科技來自人類的惰性」啊!!)

 

 

順便也提一下,本機的檔案目錄NTFS權限要用另一個工具,叫做 XCACLS.exe/XCACLS.vbs,

XCACLS.exe/XCACLS.vbs 使用上要注意,記得加上 /E 才不會蓋掉所有的權限。

 

 

RMTShare 語法:

RMTSHARE  \\server
          \\server\sharename

          \\server\sharename=drive:path [/USERS:number | /UNLIMITED]
                               [/REMARK:"text"]
                               [/GRANT [user[:perm][ /GRANT user[:perm]]]]
                               [/REMOVE user]

          \\server\sharename=printername /PRINTER [/USERS:number | /UNLIMITED]
                               [/REMARK:"text"]
                               [/GRANT [user[:perm][ /GRANT user[:perm]]]]
                               [/REMOVE user]

          \\server\sharename [/USERS:number | /UNLIMITED]
                               [/REMARK:"text"]
                               [/GRANT [user[:perm][ /GRANT user[:perm]]]]
                               [/REMOVE user]

          \\server\sharename /DELETE

NOTE: If a sharename or path contains spaces, it should be enclosed in quotes:
            \\server\"with space"="c:\with space"

若要使用 Rmtshare.exe 工具在遠端伺服器上建立或刪除共用資源,請使用具有下面語法的指令:
rmtshare \\server[\sharename[=path [/printer]]]
                           [/grant [user[:perms ]]]
                           [/remove user][/users:number] [/unlimited] [/remark:"text"] /delete
上述指令的語法說明如下:

• 「\\server\sharename」語法是指伺服器以及您可以建立、檢查、修改或刪除的共用資源。
• 「/grant user:perms」語法會新增在伺服器上具有權限的有效使用者或群組的名稱,或是變更存取控制清單中使用者的權限。有效的使用權限如下:r=讀取、c=變更 (寫入)、f=完整權限以及 n=無權限。您可以輸入「read」,但是只有第一個字元會被使用。
• 「/remove user」語法會移除某個使用者的特定項目。然後,此使用者會繼承權限 (與拒絕使用者之任何存取的「/grant user:none」成對比)。
• 「/users:number」語法是對伺服器與共用資源具有特權之使用者的數目。
• 「/delete」語法會刪除由「\\server\sharename」語法所指定的共用資源。
注意:如果共用資源名稱或路徑有包含空格,請在共用資源名稱或路徑的前後加上引號,例如:\\server\"with space"="c:\with space"。

2007/06/14

[SPS2007]Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

SPS 2007 上線平行測試後,發現 event log 常常出現以下訊息

========================

事件類型: 錯誤
事件來源: Windows SharePoint Services 3
事件類別目錄: 計時器
事件識別碼: 6398
日期: 2007/6/13
時間: 下午 01:11:47
使用者: N/A
電腦: web1

描述:
工作定義 Microsoft.Office.Server.Administration.ApplicationServerAdministrationServiceJob (識別碼 xxxx) 的 Execute 方法發生例外狀況。

其他資訊如下。

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

=========================

拜了一下 Google ,發現有人有跟我一樣的病狀,在 2007/2 發作,在這裡(https://blogs.pointbridge.com/Blogs/gehard_mike/Lists/Posts/Post.aspx?ID=8)

=========================

Event Type:    Error
Event Source:    Windows SharePoint Services 3
Event Category:    Timer
Event ID:    6398
Date:        2/20/2007
Time:        8:39:23 PM
User:        N/A
Computer:    XXXXX

Description:
The Execute method of job definition Microsoft.Office.Server.Administration.ApplicationServerAdministrationServiceJob (ID 5566b384-4d29-4875-b09e-c72968449ac2) threw an exception. More information is included below.

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

==============================

看起來是 .net 2.0 的問題,以下的 KB 有 .net 2.0 framework 的 hotfix

FIX: Error message when you run a .NET Framework 2.0 Remoting application: "Unhandled Exception: System.AccessViolationException"

http://support.microsoft.com/kb/923028/en-us 

從更新的日期 2007/04/13 看得出來是熱騰騰的 FIX ,下載的方式要註冊什麼 Connect 的,有需要的話就循線下載服用吧~

http://go.microsoft.com/fwlink/?linkid=87454

hotfix 安裝時,特別注意會停止 IIS ,在正式機上要特別小心。

2007/05/17

[SPS2007] Install Application Template HelpDesk Problem

直接至微軟下載應用程式範本

HelpDesk 支援服務中心 (http://www.microsoft.com/downloads/details.aspx?displaylang=zh-tw&FamilyID=ce90d6d7-7b96-47bf-a22f-a7e8c5d40647)

安裝後,建立新網站時會出現以下訊息:

*********************************************************************************************************************************************************************************************

Feature '75a0fea7-12fe-4cad-a1b2-525fa776c07e' is not installed in this farm, and can not be added to this scope.

*********************************************************************************************************************************************************************************************

此伺服器陣列沒有安裝功能 '75a0fea7-12fe-4cad-a1b2-525fa776c07e',因此無法新增到此範圍

*********************************************************************************************************************************************************************************************

問題是 HelpDesk 這範本需要 ApplicationTemplateCore 才能運作,請再下載 ApplicationTemplateCore (http://www.microsoft.com/downloads/details.aspx?familyid=C1039E13-94DA-4D7D-8CAE-3B96FA5A4045&displaylang=zh-tw)安裝即可。

 

另外一個問題的原因就是…沒有好好的看網頁上的說明…Orz

 

附上 install batch script。

 

HelpDesk_install.bat

*********************************************************************************************************************************************************************************************

PATH C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN

stsadm -o addsolution -filename ApplicationTemplateCore.wsp
stsadm -o deploysolution -name ApplicationTemplateCore.wsp -allowgacdeployment -immediate

stsadm -o addsolution -filename HelpDesk.wsp
stsadm -o deploysolution -name HelpDesk.wsp -allowgacdeployment -immediate

REM please IISRESET

pause

*********************************************************************************************************************************************************************************************

2007/05/16

[SPS2007]Eventlog - ProfileSynchronizationDuplicateSiteIDException

當我將 SPS 從 A Domain 移至 B Domain 時,然後直接將 SSP 還原後,就會在 Eventlog 中出現這些訊息

***********************************************************************************************************************************************************************************************************************************************************

事件類型: 錯誤

事件來源: Office SharePoint Server

事件類別目錄: 使用者設定檔

事件識別碼: 5555

日期: 2007/5/16

時間: 下午 04:00:02

使用者: N/A

電腦: SPSWEB

描述:

嘗試同步處理 Web 應用程式 4583e17b-0a47-4a5a-b88b-ce600c72c257、ContentDB 962095e4-64f2-4539-9812-c0ab73b7b098 時發生錯誤 例外狀況訊息為 發現重複的網站識別碼 040771d5-1dde-490a-a5c3-b83b2254a0f4(http://10.123.66.88)。可能因為在將某伺服器陣列的內容資料庫還原到其他伺服器陣列之前,未先移除原始資料庫並執行 stsadm -o preparetomove。如果這是原因,則可使用 stsadm -o preparetomove 命令搭配 -OldContentDB 命令列選項,以解決這個問題。

***********************************************************************************************************************************************************************************************************************************************************

事件類型: 錯誤

事件來源: Office SharePoint Server

事件類別目錄: Office Server 一般

事件識別碼: 7888

日期: 2007/5/16

時間: 下午 04:00:02

使用者: N/A

電腦: EPEWEBPROD03

描述:

已偵到到執行階段例外狀況。詳細資料如下,

訊息: 發現重複的網站識別碼 040771d5-1dde-490a-a5c3-b83b2254a0f4(http://10.123.66.88)。可能因為在將某伺服器陣列的內容資料庫還原到其他伺服器陣列之前,未先移除原始資料庫並執行 stsadm -o preparetomove。如果這是原因,則可使用 stsadm -o preparetomove 命令搭配 -OldContentDB 命令列選項,以解決這個問題。

技術詳細資料:

Microsoft.Office.Server.UserProfiles.ProfileSynchronizationDuplicateSiteIDException: 發現重複的網站識別碼 040771d5-1dde-490a-a5c3-b83b2254a0f4(http://10.123.66.88)。可能因為在將某伺服器陣列的內容資料庫還原到其他伺服器陣列之前,未先移除原始資料庫並執行 stsadm -o preparetomove。如果這是原因,則可使用 stsadm -o preparetomove 命令搭配 -OldContentDB 命令列選項,以解決這個問題。

at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.RegisterSitesForSynch(Guid[] rgGuid, Int32 nGuids, Object dummy)

at Microsoft.Office.Server.UserProfiles.SynchCollection`2.FlushAdds()

at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.AddRemoveSites(String strFirstChangeToken, SPChangeToken lastChangeToken)

at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.SynchContentDB()

at Microsoft.Office.Server.Diagnostics.FirstChanceHandler.ExceptionFilter(Boolean fRethrowException, TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)

***********************************************************************************************************************************************************************************************************************************************************

以下是英文版的訊息

***********************************************************************************************************************************************************************************************************************************************************

A runtime exception was detected. Details follow. Message: A duplicate site ID e988d221-a48b-4ae8- ad91-6c6ca40548c3(https://my site url) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue. Techinal Details: Microsoft.Office.Server.UserProfiles.ProfileSynchronizationDuplicateSit eIDException: A duplicate site ID e988d221-a48b-4ae8- ad91-6c6ca40548c3(https://my site url) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue. at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.RegisterSite sForSynch(Guid[] rgGuid, Int32 nGuids, Object dummy) at Microsoft.Office.Server.UserProfiles.SynchCollection`2.FlushAdds() at Microsoft.Office.Server.UserProfiles.SynchCollection`2.Add(T objAdd) at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.AddRemoveSit es(String strFirstChangeToken, SPChangeToken lastChangeToken) at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.SynchContent DB() at Microsoft.Office.Server.Diagnostics.FirstChanceHandler.ExceptionFilter( Boolean fRethrowException, TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)

***********************************************************************************************************************************************************************************************************************************************************

後來在這裡(http://www.ureader.com/message/33224010.aspx)找到了解決方式,我轉貼過來…

After extensive research of all the SharePoint databases I figured the table “sistesynch” in the sharedservices database is responsible for the errors caused by the hourly profile synchronizations service. I looked in the table and found out the database id‘s in this do not match with the database id’s from the config database of the SharePoint. Site ID’s seems to be ok in this table. This table may not have been updated when the content databases where detached and attached (could be a bug in SharePoint). After deleting the rows from this table the errors gone away and the table is re-populated back with correct sites and database id’s next time when the service ran (usually hourly). I also found that you can actually run this stsadm command which also does the same thing mentioned above (deleting rows from site sync table) and is probably a better way since this is a command from MS. Run the following command . stsadm -o sync -DeleteOldDatabases 0 The results of this command will be a list of old database id’s that have been cleaned up and the sitesync table will be emptied. Note: Since there is no documentation on any of these commands .All the above fixes are based on my personal investigation so please makes sure this works for you in your environments before you run. Backup the sharedservices and configuration databases just in case if this don’t work for you. It’s been couple of days since we ran this in our environment and we haven’t seen any issues and all the event log errors gone away. Good Luck. Vikram Garlapati

 

在下這個指令(stsadm -o sync -DeleteOldDatabases 0)之前,請先備份 SSP DB 及 Config DB 哦~

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大神都沒有結果,後來是黑暗大哥銷假上班才獲救...

2007/03/30

Google Reader 有新功能 Trends

Official Google Reader Blog 看到有新增 Reader 功能 Trends

訂閱 Blog 的文章活動統計 => 太久沒更新的,就可以打個電話關心一下朋友

自己最常看那幾個 blog 包含"星號"及"分享"註記

如何開啟 Trends 功能:

在登入Google Reader 後點入 Home ,中間有一行字

A look at what's new

See personalized trends for your subscriptions and read items.

如果要了解 Google Reader 各種花式技巧,異塵行者幫大家做了整理,很棒哦~

電腦玩物: Google Reader各種特色技巧彙整

Technorati tags: ,

KB-TOAD 執行 Explain Plan 遇到 ORA-0240 訊息

TOAD 的愛用者如果遇到效能調校時,不能執行 Explain Plan 就像瞎子摸象般,

由於 TOAD 有一堆 Server 物件需要開啟,但是礙於權限等等問題,所以…

「改變不了別人,就改變你自己」

原本執行 Explain Plan (Ctrl-E)會出現以下錯誤:

ORA-02404: specified plan table not found

在設定中,設定一下,如下圖所示

TOAD_ORA-0240 訊息

這樣子,就可以跟 sqlplus 用一樣的 plan_table 。

KB-WSS V3 搜尋問題

之前遇到 WSS V3 使用搜尋時,會出現以下訊息

因為未將此網站指定給索引器,所以無法完成搜尋。

此原因的排除步驟如下:

*管理中心->作業->伺服器上的服務:啟動 Windows SharePoint Services 搜尋 服務

*管理中心->應用程式管理->SharePoint Web 應用程式管理->內容資料庫->選擇 搜尋伺服器

就可以正常使用搜尋了

如何在 Sharepoint 網站上加入自行開發的 .net web 應用程式

通常這個問題可以解決以下幾種徵兆:

* Sharepoint 2007 & Reporting Service 2000/2005 Install in the same Web Site.

* Enabling a custom ASP.NET Application in SharePoint 2007 (MOSS)

會出現以下問題

Required permissions cannot be acquired.

此問題為安全性問題,解決在 web.config 加上

<trust level="Full" originUrl="" /> 即可

Configuration Error : Cannot use 'partitionResolver' unless the mode is 'StateServer' or 'SQLServer'.

此問題為 Sharepoint 有用到 web.config 中 <sessionState /> 的 partitionResolverType 屬性,如果下層應用程式為自行開發的應用程式(非 Sharepoint 程式) 可以改為以下,只要額外加入 partitionResolverType=""

<sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false" timeout="20" partitionResolverType="" />

Session state can only be used when enableSessionState is set to true, either in a configuration file or in the Page directive. Please also make sure that System.Web.SessionStateModule or a custom session state module is included in the <configuration>\<system.web>\<httpModules> section in the application configuration.

此問題為 Sharepoint 預設 <pages/> 的 enableSessionState = "false" ,可以覆寫上層設定

<pages enableSessionState="true" />

 

<2007/08/29>補充說明

又遇到一個狀況,原本使用 Windows 驗證時,會再次出現登入畫面,形成二次登入的狀況,只要將 web.config 中以下的 tag attribute 調整即可。

<identity impersonate="true"/>

 

 

找了很多網站都沒有完整的處理過程,花了不少時間 :s。

Keyword: MOSS Sharepoint WSS partitionResolverType SessionState