A little IT experience/study/share garden

倉儲物流業系統架構圖

這是以前幫一家物流公司所作的系統架構圖，我將所有的資訊系統切割成幾大塊，並標明其間的關係：
(1)倉儲管理
(2)配送管理
(3)流通業 ERP
(4)供應錬管理(Supply Chain Management)
(5)客戶服務入口網站
(6)DSS/BI
(7)OA (辦公室自動化)

思考的方向如下：

1.公司的核心競爭力在倉儲代管及物流，故 WMS(Warehouse Management System)成為最重要的系統，主要的交易(Transaction)均由此處輸入，ERP 只負責帳務的計算及成本分析.

2.大型物流業的業務，幾乎都與進出口或保稅有關，而關貿網路是國內最大的資訊服務提供者(Information Service Provider)，所以供應鍊平台的規劃，須將關貿網路及相關的合作夥伴(Shipper/Broder/Forwarder)包含進來.

3.客戶服務入口網站(E-Service Portal)部份，除了"貨況追蹤"的必備功能外，針對企業客戶，亦可
(1)在線上查詢庫存數
(2)線上下單改包(包裝變更)，轉 WMS 工單
(3)線上下單出貨
(4)B2B EDI
(5)客訴反應及處理狀態查詢

當時這間公司除了 WMS 外，其他系統幾乎全部付之闕如，如果要將這張架構圖實現，估計至少要花兩三年的時間，才能略俱雛型.

一個專案要導入, 有哪些階段及工作? 其間的文件或產出有哪些? 撰寫的大方向? 這裡以兩張簡單的slide 歸納個人的經驗.



專案推動生命週期

系統文件撰寫原則

原文出處 : http://www.ithome.com.tw/plog/index.php?op=ViewArticle&articleId=6287&blogId=620

淺談SQL Server的鎖定原理
neo_lin_42 | 02 Oct, 2006 10:21

在說明SQL Server的鎖定原理之前，首先來看一個基本的問題，為什麼要使用鎖定？我們可以從逆向思考的方式來回答這個問題，也就是不使用鎖定，會出現什麼問題，特別是當多人同時存取資料時，若不使用鎖定，可能會發生lost update、dirty read、nonrepeatable read與phantoms read等問題。這也是為什麼要使用鎖定的主要原因。

談到鎖定，就不得不談到交易處理(transaction)。所謂交易處理是指在一個工作單元中，執行的一系列資料操作。ATM跨行轉帳就是一個很典型的例子，這個工作單元中包含從轉出帳戶扣款與將金額存入轉入帳號兩個操作，這兩個操作必須有一致的結果，不是全部成功，確認最終狀態；就是全部失敗，回復原始狀態，沒有部分成功，部分失敗的情況，只有轉出沒有轉入或只有轉入沒有轉出都是不允許的。也就是交易處理具有不可分割性(Atomicity)、一致性(Consistency)、隔離性(Isolation)以及持久性(Durability)等特性。而鎖定機制便是為了實現交易的隔離性，好像此時資料庫系統是專屬你一個人的。

鎖定的範圍
在SQL Server可以鎖定哪些資源？依據鎖定的範圍可以分成RID 列級鎖定、Key 索引鎖定、Page 頁級鎖定、Extent 擴展鎖定(每8個Page為1個extent，用於SQL Server儲存空間的分配)、Table 表級鎖定，以及Database 資料庫級鎖定。

鎖定的範圍越小，耗用的資源越大；鎖定的範圍越大，耗用的資源越小。列級鎖定可以增加同時線上(concurrent)數量，但卻增加資源花費；頁級或表級鎖定則正好相反。SQL Server會衡量目前的concurrent數量與系統資源，自動管理鎖定的範圍，同時為了獲得最佳的鎖定效能，SQL Server提供一種動態鎖定的機制，也就適當列級鎖定耗用的資源達到某個程度時，SQL Server會自動將列級鎖定升級成頁級或表級鎖定。

鎖定的類型

SQL Server鎖定可以分成基本鎖定與特殊鎖定兩大類。基本鎖定又可分成共用鎖定(shared lock)與獨占鎖定(exclusive lock) 。一般而言，當Select資料時會使用共用鎖定，Insert、Update和Delete資料時會使用獨佔鎖定。特殊鎖定又可分成意圖鎖定(Intent lock)、更新鎖定(Update lock)、綱要鎖定(Schema lock)與大量新鎖定(Bulk update lock)。接下來，對常用的鎖定類型，簡單說明如下：

共用鎖定
當讀取資料時，SQL Server會使用共用鎖定，即使尚未結束，其他交易也可以獲得共用鎖定，也就是說多個交易可以同時讀取table、page、key和row。

獨佔鎖定
當修改資料時，SQL Server會使用獨佔鎖定。在交易結束之前，其他交易的鎖定請求都會被拒絕。一個資源只能有一個獨佔鎖定，當一個交易對某個資源進行獨占鎖定時，其他交易無法讀取該資源，由此可知，這種鎖定會限制了同時線上數量。
更新鎖定是共用鎖定與獨占鎖定的混合體。在修改之前會使用共用鎖定，其他交易可以讀取被鎖定的資料，但不可以修改。一旦開始修改時，就變成了獨占鎖定，其他交易無法讀取和更新被鎖定的資料，直到交易結束。

一個鎖定可以與另一個鎖定同時使用，這種特性稱為鎖定的相容性。相反的，若一個交易正在操作而鎖定資料，另一個交易必須等前一個交易結束後，才能繼續，則稱為不相容。相容性越好，表示支援的同時線上數量越大。哪些鎖定式相容的？哪些鎖定又是不相容的？一般的原則如下：
共用鎖定可以與獨占鎖定之外的其他鎖定相容。多個交易可以在相同資料上獲得共用鎖定，但沒有一個交易可以在已經獲得共用鎖定的資料上獲得獨佔鎖定。

獨占鎖定不可以其他鎖定相容。

更新鎖定只能與共用鎖定相容。

我們可以使用交易的隔離級別來設定鎖定的策略，以防止前面提到多人存取所可能出現的問題。SQL Server提供下列4種交易隔離級別，其特性簡單說明如下。
read uncommitted 會出現dirty read、non-repeatable read與phantoms等問題。
read committed 會出現non-repeatable read與phantoms等問題。
repeatable read 會出現phantoms的問題。
serializable 無

若未指定SQL Server預設使用read committed。在SQL Server 2005，提供了另外兩個基於資料版本的隔離級別，snapshot與Read Committed using Statement-level Snapshot(RCSI)，使得讀取與更新的操作不會互相影響，加快交易的執行速度。

除了隔離級別的鎖定策略之外，您也可以使用鎖定提示來控制資料表的鎖定行為，以及覆蓋目前交易的隔離級別的鎖定策略。當隔離級別的鎖定策略與鎖定提示相衝突時， SQL Server是採用級別越小越優先的處理原則。例如，使用serializable隔離級別，若在交易中使用with (nolock)讀取資料，SQL Server會允許其他交易讀取資料。可用的表級鎖定提示摘要如下：
holdlock：當交易開始之後，交易結束之前，不允許其他交易讀取被holdlock的資料。
nolock：不使用任何的鎖定。
使用rowlock、paglock，tablock與tablockx來指定資料表的鎖定類型和大小。例如使用tablockx表示當讀取資料列時，在資料列所在的資料表上使用獨占索定。
readpast：忽略鎖定的資料列
updlock：當讀取資料使用更新鎖定，而不是預設的共用鎖定。當交易尚未結束前，不允許其他交易更新被updlock的資料，可避免non-repeatable read。

您可以根據個別的需要來組合這些鎖定提示，以獲得更加靈活、更有彈性的應用。例如，with (paglock, holdlock)表示在資料列所在的資料頁上使用hold lock。

有關SQL Server的鎖定原理，拉哩拉喳地介紹到此，相信大家對SQL Server的鎖定已有初步的認識。至於進一步的實作細節，還是那一句老話，多翻翻SQL Server的線上叢書囉!!

Dirty Read (以下簡稱DR)在MS SQL 的Help 裡解釋如下:
"第二筆交易選擇的資料列已經被其他交易更新時，會發生未確認依存性 (Uncommitted Dependency)。此時，第二筆交易讀取的是尚未認可且可能被更新資料列的交易變更之資料。

例如，有一位編輯人員正在修改一份電子文件。進行變更時，第二位編輯人員複製了包含目前所有變更的文件，並將文件散發給預期的讀者。此時，第一位編輯人員認為截至目前的變更均有誤，所以移除了原先的變更後儲存文件。散發的文件包含不存在的修改，但這些修改不應該存在。如果能在第一位編輯人員決定不再進行變更後才允許其他人員讀取修改過的文件，即可避免這個問題。"

坦白說, 我一向看不太懂這些詏口的翻譯文, 不過大致可以推斷出, 當 DR 發生時, 表示我們的select 的資料, "可能"是錯的.

想對MS SQL 的鎖定機制有進一步認識的人, 可以參考這一篇

為了避免這種錯誤發生, 我們只有運用lock 的機制去避免, 但這往往必須用系統效能的降低來交換, 只不過, 在一個設計良好的系統中, 這種兩難可以達成一個平衡(trade-off balance).

但如果是發生在一個已經每天都滿載甚至超載(overload)的MS SQL 資料庫上呢? 我們會發現, 由於大量的Lock, 將會導致系統始終遊走於崩潰邊緣!

我在 sql-server-performance.com 這個網站上翻閱了一些文章, 其中這篇寫得不錯; 作者針對上述問題(row lock/page lock/table lock/...), 提供了兩點方案:
1) turn option "NOLOCK" on while SELECT
2) turn option "ROWLOCK" on while UPDATE and DELETE

關於"NOLOCK"及"ROWLOCK", 在此不再詳述, MSDN 裡都翻得到.

由於這種方法可能會造成DR, 筆者也特別說明, 進行重要的交易(如會計結帳), 不可用此方案.

以一個 ERP 而言, 絕大多數(往往超過50%)的查詢或報表, 並不一定需要"最及時"(updated)的資料; 如果我要查目前的庫存量, 那麼30秒前的庫存, 和目前的庫存, 即使有所差異, 那差異量和整月的交易量比起來也是微乎其微; 諸如此類的select statement, 其實是可以忽略 DR 的風險! 如果我們對這些 sql statement 加上 "NOLOCK"及"ROWLOCK", 可以使 DB 的效能超死回生, 那麼何妨一試!?

曾與人爭論"資料正確性"與"效能", 孰重孰輕!? 理論上, 提供100% 的資料正確性是MIS 的天職, 但實務上若遇到設計不佳的 DB 存取方法, 常造成使用者操作時要忍受無窮無盡的等待, 三不五時的"作業逾時",換算成全公司浪費的人力, 絕對比DR 的成本更加驚人 (何況前者是"一定會有"的顯性成本, 後者只是潛在成本),遑論使用者對系統的抗拒感造成日後的怒氣爆發! MIS 宜從多個角度思考何者為佳(對公司最好), 而非固執地抱著理論不放.

現在企業流行外包(Outsourcing ); MIS 部門也不例外. 最常見的是, 台灣的MIS 負責談需求 & 開 SA/SD 規格書(Specification), 然後交給大陸的IT 寫程式, 最後再由台灣驗收及上線.

於是乎, 主管會跟我們說: 「請大家要提昇自己的層次, 不要一直埋頭寫程式, 要學會作PM(專業管理)呀! 」、「你知道你一個人可以在大陸找幾個人嗎? 公司可不是請你來寫程式的」、......

於是乎,「 號稱 」PM(專案工程師? 專案副理?)的人愈來愈多了, 連剛進這行只有一兩年的人, 也整天開著 Word/Visio/..., 想著如何遵循所謂標準的"樣版"(Template), 來寫出一本洋洋灑灑令人讚嘆的文件......

這種兩岸分工的方式, 背後所依據的前提條件是:

1.寫程式沒前途, 作 PM(or SA)才高尚

2.只要有心, 人人都是PM. 所以每位MIS, 不分男女老少, 眾人扶老攜幼, 朝 PM 的大道邁進



可惜實情往往不是如此.

第一, 除了少數天才以外, 每位(AP Team 的)MIS 都要歷經至少 3~5 年以上的基本功, 才有資格作SA! 新鮮人在前期大概只能維護舊的程式, user 的需求單要花較長時間才能理解並想出系統中應修改的部份, 同時因為對實務的不熟悉, 往往被user 牽著鼻子走; 到了中後期, 反應快了, 流程也熟了, 才有能力慢慢寫出"夠格"(Qualified)的系統文件, 如 ERD/System Flow/成本效益評估/Function Spec. /... 等; SA 的經驗夠了,"軟性技能"(soft skill, 比如溝通及人際關係)也有了, 才俱備去規劃及推展一個專案的基本能力.

第二,一個人能不能扮演好(或適不適合)PM 或 SA 的角色, 除了經驗外, 天生的「個性」也佔極大的影嚮!

-->內向寡言的人, 要他去主持跟 user 的會議? 去跟催(follow)各單位的進度?

-->喜歡鑽研網管技術或寫程式的人, 硬要他離開電腦, 整天忙著聯絡廠商及寫評估報告?

齊頭式的平等, 等於是種罪惡! 而有太多MIS 的不滿, 都是起緣於此.

主管該時時思考, 如何適才適任, 讓各人將興趣與工作結合, 讓不同專長的人互補有無?