最近一直很忙，家裏的，工作的。工作上的事情，也是很凌亂，或者叫多線程，一會幹個這，一會幹戈那。現在有了點時間，也該寫點東西了。前幾天做了件事情，覺得還是有點收穫的，應該記錄下來，爲自己沉澱點東西。也可以分享給好多一直還在用站短問候我的朋友們。
前段時間碰到這麼樣一個事情，有封從外部組織發送到公司某客服賬戶的郵件，按預期，應該根據傳輸規則，將此郵件複製一份並密抄給另一個郵箱賬戶，作爲備份數據。但客服系統的管理員發現，出現了郵件丟失的情況。就是說，按照預期會生成的郵件，沒有收到，導致客服系統，和備份賬戶中的郵件不一致。這個時候需要查看這封郵件的跟蹤日誌，來確定郵件到底是在哪個過程中，丟失的。。郵件系統的管理員接到這件事情以後就開始檢查，Exchange裏面已經做了郵件跟蹤日誌，但結果發現不全，一個星期以前的，都沒有了。因爲之前有個習慣，就是定期將跟蹤日誌拷貝出來保存在另外一個地方，進行存檔。目的有兩個，一個是避免佔用空間過多導致服務器資源緊張以及性能問題。第二個原因就是一旦對郵件系統進行備份，日誌將會自動清除，也就意味着使用exchange的管理工具，只能看到上次備份以來的郵件跟蹤信息。
關於這件事情，就不多說了，反正最後的結果是，我們通過找到之前備份的郵件跟蹤日誌，查出了問題所在。但問題解決之後，我有了一個想法。Exchange的跟蹤查詢工具，是可以滿足我們最基本的跟蹤查詢需求。但是限制因素很多，比如日誌的路徑，文件類型的數據等。當然，不排除像 塵封メ心 或者 cashcat 那樣的Exchange高手，可以通過很多手段，甚至PowerShell等專業工具來實現郵件的跟蹤查詢。。但是我想，如果能將跟蹤日誌做成一個數據庫，是不是更好呢？比如放到SQL裏面，大家都知道光是SQL的查詢，就可以做到非常豐富。還有報表服務，可以做出一個非常友好的查詢界面，供一些非IT專業人員來進行查詢。如果需要更專業的分析，SQL還有一個強大BI功能，絕對滿足任何要求的查詢。甚至可以變態的分析出每天公司裏面哪個男同事跟哪個女同事溝通最密切，他們的郵件都說了什麼。。
所以，我的想法就是，利用SQL強大的查詢、分析功能，實現對郵件的跟蹤。
根本的需求有了，下面就得對需求，進行分析了。首先，把握住需求的核心對象，就是跟蹤日誌，更準確的說，是某一條用於描述郵件傳遞過程的日誌信息。。其次，要理清思路，想清楚整個信息傳遞的過程。這個過程，簡單來說的話，就是，最初的數據是生成於Exchange跟蹤日誌目錄，然後需要被導入到SQL數據庫中，最後通過SQL查詢被檢索出來。。
對象搞清楚了，需要進行處理的過程搞清楚了，下面就是搞清楚應該怎麼辦。第一，日誌數據的生成，沒有問題，Exchange本身就會生成.log的日誌文件，或者配置Exchange啓用跟蹤日誌功能。第二，將.log文件的內容導入到SQL數據庫當中，這一步是關鍵。第三，進行信息檢索，這個也不是問題，SQL很容易被查詢。所以，整件事情的唯一需要做的，就是把.log的文件內容導入到SQL中。
這裏我就不Step-by-Step的講怎麼一步一步操作的了，因爲整個過程相對來說，步驟還是很多的。我這裏就簡單介紹一下如何實現的，只要大家對SQL有基本實際經驗，應該都不是問題。
先來用一句話概括：通過SQL的BCP語句，實現數據的批量導入。。當然，前提是要先建表，.log文件中的每個列，作爲表的列，就可以了。
BCP語句的語法，可以查SQL的聯機叢書，或者微軟的TechNet網站進行查詢，語法還是很簡單的。我就不多介紹了，這裏我只把我用到的貼上來。。
bcp ExchangeLogs.dbo.[MessageTracking] in "D:\Exchange Logs\Unicode\MSGTRK20100703-1.txt " -T -Slocalhost -t, -r\n -w -e"D:\Exchange Logs\Bulkinsert\error_MSGTRK20100703-1.txt"
看起來很簡單吧？但是我還是碰了很多釘子。。所以，我覺得比寫Step-by-Step的步驟更重要的事情，是把我遇到的這些釘子拔出來給大家看看。
釘子一：文件格式
有心的朋友可能已經看到上面的BCP命令當中，是“MSGTRK20100703-1.txt”而不是“.log”的。更有心的，可能發現路徑裏面有個Unicode的文件夾。這都不是意外啊，這就是最大的一顆釘子。
其實SQL DB本身就支持從某個文本中批量的導入數據，可以直接用Studio的圖形界面，也可以用“bulk insert”，或者是我用到的BCP命令。但是我碰到了一個頭疼的問題就是，死活數據導入不成功，各種方式都用過了。後來發現，Exchange自動生成的.log文件，文字編碼是使用的UTF-8標準，而SQL報錯說不支持。。怎麼辦？答案是，轉！
先轉格式。。一個很土的辦法就是，用記事本打開log文件，然後什麼別改，直接另存爲.txt，注意這時有個“編碼”選項，記得要選成“Unicode”。。但是這個土辦法，轉一個兩個還行，一個Exchange環境運行個幾年下來。。那得有多少.log文件啊？所以說土嘛。。那怎麼樣能夠批量的進行編碼轉換呢？
釘子二：批量進行格式轉換
附件裏有個工具，是網上下載的，怕有毒的，就自個去找Google它老人家要吧。。批量轉格式的方法，我相信不止一種，我也相信這個工具絕對不是最好的，如果哪個以後找到更好的，記得回來通報一下。。
因爲這個工具，確實是個小工具，經不起大的工作量。我第一次的時候，一次性選了一個文件夾，大概4G左右的日誌，有好幾百個.log文件吧。。結果小工具直接罷工了，試了好幾次，終於摸出門路來了。。一次選的，不能太多，1G左右的量最好，要不然就把它撐爆了。。呵呵。。
釘子三：生成.bat腳本
經過幾個回合，我的所有的UTF-8編碼的.log文件，都被轉成了Unicode編碼的.txt文件。剩下的，就是往SQL裏面導入了。土人的做法是，一次一次的在CMD裏面運行BCP的這個命令（題外話：記住，那個叫CMD，命令提示符，不要再說是DOS了，很土的），每次都把另外一個文件名複製到上一次運行的命令參數裏面，修改掉之前的。
那麼多的文件，一次一次運行，會死人的啊。。於是出現了一個神人，他主張用.bat腳本，把這條命令在一個TXT文本里面複製個萬八千行的，一次執行完所有命令。這時又面臨一個問題，就是腳本里面，每一行當中的那個文件名，都是不一樣的，這時他想到一行一行修改文件名。。但是，如果面對成千上萬個文件，就意味着要Copy上萬次文件名。。所以說，能幹出這事的，都是神人啊。
那我們不是神，是人，是人就會使用工具，這時我們想到了Excel。利用Excel的文本函數，可以很方便的將一排文字，切割成幾列，然後修改其中一列，最後再組合成一個完整的文本內容。。
如果非要知道怎麼做，可以參考這裏《巧用Excel函數，簡化批量導入AD用戶及密碼修改》 http://bisheng.blog.51cto.com/409831/182286 ，雖然內容不一樣，但異曲同工，靈活運用嘛。
好，三顆釘子拔完，此事基本搞定。其實，其間也走過一些彎路，一些回頭路，還有好多小的釘子。反正最終，成功的將.log文件的內容，導入到了SQL數據庫當中。後面的事情就好說了，我試過select語句，還是很好用的，而且把幾個常用查詢語句保存了下來。
其實，關鍵是，只要數據進入到SQL，後面就都好辦了。無論是查詢語句，報表，甚至是BI，能夠將郵件跟蹤的分析做到什麼樣一種高度，就看你對SQL的研究深度了。
再說說遺憾。。遺憾的事情就是，這所有的過程，除了Exchange或者SQL本身可以完成的工作以外，其他的操作，必須由人手動完成。。只不過我們是用了一些自動化的方式，進行了一些批量的處理，簡化了一些工作量而已。。真正的全自動化的過程，還需要進一步完善。當然，再想進一步，光靠SQL已經是不夠了。。
最後，我再展望一下，如果希望做到全自動化，至少有幾個方面的問題需要解決。
第一，需要對Exchange生成日誌的那個目錄做監控，一旦發現有日誌生成，自動將其進行轉化。當然具體的過程，可能還需要考慮是否先判斷文件已寫完，或者考慮先複製到另一文件夾，再做處理。
第二，文件格式的轉換，就不能用我們那個小工具了，必須通過標準的文字編碼轉換方式進行。
第三，需要自動的出發SQL的數據導入進程，並校驗整個過程中的完整性和正確性。
如果能做到這三個方面的自動化處理，基本上，就完美了。
可能有人此時聽得有點犯暈，也可能有人已經有所感悟。。這不就是數據交換麼？這不就是中間件麼？這不就是Biztalk麼？？
人云：查詢個日誌，把Biztalk都請出來了？？殺雞焉用牛刀呼？？我曰：閒來之時，可以一試。。
全文完。。。^_^....