-
KB-在Office 2007中找不到要用的選單嗎? 看這裡!!
-
Excel 2007的Ribbon式選單固然有其方便性，但許多慣用的功能選單整個大風吹，深藏各個角落裡，每次都讓我找到想罵髒話。
今天想在Excel 2007上插入個Button觸發巨集，卻遍尋不著加入表單控制項的選單，找到肝火上升，快要砸鍵盤之際，試了一下Office Online Help，沒想到找到救星了。
Office Team似乎知道自己做了虧心事，針對Office 2007系列都提供了互動式的Flash動畫，如下圖，Flash中有一個Excel 2003的選單UI，可以真的展開及點選，點選到某個功能時，它會用文字說明與動畫告訴你在Excel 2007中該怎麼做。功德無量呀!!
Excel 2003各選單功能在Excel 2007的對應
http://office.microsoft.com/zh-tw/excel/HA101491511028.aspx
Word 2003各選單功能在Word 2007的對應
http://office.microsoft.com/zh-tw/word/HA100744321028.aspx
PowerPoint 2003各選單功能在PowerPoint 2007的對應
http://office.microsoft.com/zh-tw/powerpoint/HA101490761028.aspx
-
Windows Live Failure
-
2007/08/08 07:30 UTC+8發現部分由MSN檢視部分連絡人分享空間的過程出現Server Unavailable Error(似乎是MS Passport Authentication過程有問題)，由於這種國際級大站出現故障並不常見，特地拍照留念。
寫這篇Blog的另外一個目的是預備萬一自己寫的網站掛點時用來辯護及脫罪，不過07:39再試一次時，網站就恢復正常了。咳... 這代表我的網站也只能Unavailable十分鐘嗎? orz...
-
KB-Catch Deadlock Event in SQL 2005
-
Transaction (Process ID 60) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
之前開發的一個糸統，隨著使用負荷逐步增加，開始出現一些Deadlock的狀況。所謂的Deadlock，簡單來說，就是兩個個體分別鎖定了對方下一步要變更的資源，在等待對方讓步釋出資源的過程中形成僵持，此時多半由管理機制強迫其中一方作為犠牲者(Victim)，成全另一方。在DBMS裡，被挑中犠牲的Process就會得到如上的Database錯誤訊息。[延伸閱讀: SQL Server 系統效能調校(Part III) by 胡百敬]
在一般的設計準則中，針對可能發生Deadlock的場合，應安排稍後Retry的邏輯。但Deadlock會引發Exception、Rollback及Retry，是相當凶狠的效能殺手，真正的上策還是應設法避免Deadlock的發生。於是一個重要的課題來了--得先知道Deadlock怎麼發生的，才談得上預防!
追蹤Deadlock的發生點以往算是高難度的工作，但SQL 2005 Profiler裡的Deadlock Graph卻把它簡化到像用傻瓜相機拍照一樣簡單。
開啟SQL 2005 Profiler，指定要捕捉Lock相關事件，剩下的就是等待或故意製造Deadlock。有一點要注意的是，Lock:Deadlock Chain的LoginName是空白，Deadlock:graph的LoginName是'sa'，Lock:Deadlock的LoginName才會是你連線使用的Login身份，在設Filter條件若只限定連線用的Login身份，會錯失Dead Graph等重要線索。搞懂這點之前，我做了幾次虛工。
一旦抓到Deadlock Graph，一切盡在不言中，兩個Process互相挾持了什麼Resource，一目了然。
如上圖，Process 81對PK_WorkList做了RangeS-U Key Lock後準備要新增WorkItem，而Process 60則先對PK_WorkItem放了RangeS-S Key Lock後，打算更新WorkList，二者僵持不下，倒楣的Process 60上的藍色大叉叉代表它在這場衝突中壯烈犠牲了，這就是前述Deadlock Exception的由來。[註: 關於RangeS-S這類Index Range Lock的深入說明，可以看這裡]
由此可以得知，Process 60在Transaction中先讀取WorkItem再更新WorkList，而Process 81則先更新了WorkList，再打算新增WorkItem，如果將二者調成一致，均先WorkItem再WorkList，Deadlock的情況便可大幅改善。
最後補充一點，上圖中Deadlock Graph的Extract Event Data可以產生一個XML檔案，其中包含Deadlock更完整的資訊，甚至有出問題的T-SQL可以看，對於找出Deadlock的精確位置非常有幫助!