關於SQLServer2005的學習筆記（一）——前言

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE關於SQLServer2005的學習筆記（一）——前言

 

關於SQL Server，個人一直認為它是比較簡單卻又很神秘的資料庫；簡單之處在於他完全透過圖形化介面便可實現所有大型資料庫的安裝、維護、備份、最佳化等等；神秘呢在於它所有的一切都隱藏在了圖形化介面之下，讓人琢磨不透，當需要更深層次的去了解他的時候，卻無能為力。

我開始使用SQL Server自2002年起，做了一年多基於SQL Server資料庫的程式開發，然後04、05年又做了兩年基於SQL Server的資料倉儲，因為資料量太大和效能原因所以需要不斷進行效能最佳化和調整。

       印象最深刻的是05年在某移動公司實施基於SQL Server2000的資料倉儲專案。那臺資料倉儲機器的硬體配置也不高，4G記憶體，好像是4個CPU，跑的是Windows Server2003；當時每天的資料量為1.2GB，整個資料倉儲包括一年的歷史資料，總計達到了將近800GB，業務資料來源主要來自於一個oracle資料庫，當然還有大量的話務檔案，話務資訊總是以二進位制文字存在，並透過解析工具不斷的解析到資料庫中。

對於SQLServer2000來說，難點主要如下：

1、單表超過1000萬記錄，查詢更新刪除效能急轉直下

很不幸的是，話單資訊每天都要超過3000萬了，即使經過處理後的話單也將近1000萬；

2、SQL Server的鎖機制問題，SQLServer2000採用的是已提交讀的悲觀併發控制，在讀和寫之間非常容易造成死鎖。

3、業務邏輯處理複雜度太高，導致效能問題

一條話務可能會出現幾十條話單（最高記錄為50條左右，大概是IVR流程設定的問題），最終的話單會被一個長達七八百行的儲存過程解析為3條話單，而這個過程基本是連續的；這三條話單再經過ETL處理轉變成可統計的話務指標。

4、OLAP也存在嚴重的效能問題，當時的一個MOLAP就將近100GB了

5、系統穩定性不夠，總是莫名其妙的出現作業當掉的情況

針對以上情況，我做了不斷的嘗試和最佳化，例如最佳化表結構設計，把表做成當前表和歷史表，歷史表再切分成分月表；最佳化業務邏輯儲存過程；增加檢驗和處理死鎖；並針對穩定性問題向微軟上海進行諮詢和處理，最後下載了一堆的補丁和工具進行反覆實踐。

說實在的，用SQLServer2000做BI/DW專案，最大的好處是完全透過聯機幫助就可以上手，而最大的問題就是穩定性和效能問題，使用SQL Server的這段的經驗確實讓人很痛苦，因為你無從解決。

       再後來，轉向了Oracle一段時間，同樣我對Oracle的整體架構、效能最佳化和開發稍微瞭解一些，但無奈的是自己對linux的瞭解實在匱乏，所以很難專進去。個人認為自個對Oracle的體系架構認識的要比SQLServer更深刻一些。

       最近一段時間同步閱讀了一下《SQLServe2005技術內幕儲存引擎》、《SQLServe2005技術內幕程式設計》、《SQLServe2005技術內幕T-SQL查詢》，對SQLServer2005有了一些新的認識，總得感覺2005比2000有了質的飛躍，微軟也在與Oracle、IBM的不斷競爭中成長，而資料庫在競爭中不斷趨同。

       讀書第一遍只是為粗略的看一下，不敢去發表什麼個人觀點；讀第二遍的時候把自己熟悉的部分會做下實踐和印證；如果還是無法理解，再去讀第三遍；這是我對讀書的態度。

       我會在這段時間陸陸續續把自己對以上三本書的學習心得不斷記錄下來，並在SQLServer和Oracle之間進行比較，在SQLServer2000和SQLServer2005之間進行比較。