2026年4月13日 星期一

SSAS 作業已因鎖定衝突而取消


SSAS在process 與 mdx query並存應用時,如果mdx 語法含crossjoin或維度member很多時,就容易顯示錯誤【作業已因鎖定衝突而取消。】

當然,SSAS應是process與 query分開時段執行,但因種種先知後知原因,專案就是有需要這樣應用,即使是已將cube 切割到最小範圍的Partition,但複雜的mdx語法就容易跑不出來。

也是透過claude一問一答後,對於這個需求造成的問題有了較明白的理解。

Cube 開始處理 (Process) >> 需要取得 Write Lock >> 等待 CommitTimeout 秒 → MDX 查詢仍在執行 (Read Lock 未釋放) >> ForceCommitTimeout 到期 >> 強制取消 MDX 查詢 >> 看到丟出來的錯 >> 取得 Write Lock,Cube 處理繼續。

在以process為優先完成的考量下,決定給予mdx查詢較多等待的時間。

在 SSMS 連線 Analysis Services >> 右鍵屬性 Properties>>勾選顯示進階(全部)屬性Show Advanced Properties 。

將ForceCommitTimeout 改為 90000 (90秒) 給查詢更多時間完成再強制取消(毫秒) ,原先為0表示立即取消。

截一下AI回應的圖,



還有另外的建議....待測...




沒有留言:

張貼留言

SSAS 作業已因鎖定衝突而取消

SSAS在process 與 mdx query並存應用時,如果mdx 語法含crossjoin或維度member很多時,就容易顯示錯誤【作業已因鎖定衝突而取消。】 當然,SSAS應是process與 query分開時段執行,但因種種先知後知原因,專案就是有需要這樣應用,即使是已...