隨說秋色園從Access升遷到SQL過程
編者注：筆者在本文中講述了自身經歷的一個將Access數據庫升遷到SQL數據庫，又遷移回Access數據庫的過程；以及簡述了在這個遷移過程中，筆者的Team都經歷了什么問題，又是如何解決這些問題的。
秋色園的運行環境概況：
目前運行在國外godaddy的虛擬主機的一個子目錄中，數據庫為Access。
隨說Access分頁：
1：top max(id)
在CYQ.Data 數據框架支持上Access時，以top max(id)為分頁方式。
在秋色園沒有多少文章的情況下，基本上維持著正常的秩序。
直到秋色園在進化版本時，多字段排序的情況出現，如：order by 字段1，字段2。
原始的 top max(id)已無法正常的顯示分頁的數據了。
2：not in
top max(id)只適用于單字段排序，無法適用多字段排序，自然就無法通用了。
故CYQ.Data的分頁方式，從top max(id) 改成常規的 not in方式。
一開始沒有測試數據量，隨便點點感覺分頁也挺快的。
后經秋色園的文章上到三四千時，發現分頁奇慢，已無法讓它在存活了，于是把它給滅了。
3：3次top
滅掉not in方式，換上了3次top，分起頁來那是刷刷刷，速度快的不行。
于是這種方式，一直存到至今，當前3-4萬的數據中，分頁雖不快，但勉強也能接受。
雖然我一直想從程序上優化，讓Access堅持到10萬的數量級也能正常的表現，
不過有些事總來的太快，Access無法逃脫的弱點：并發。
Access在并發寫數據上，有著不可估計的錯誤，從秋色園的后臺異常日志記錄中，最常出現的錯誤：
Could not update; currently locked.SQL:Update Blog_User Set VisitCount=64359+1 where ID=111
這個異常一早出現次數比較多，后來通過程序優化之后，通過在內存計數，隨機概率才更新數據庫方式，每天平均就2-3次的情況出現。
按理這個也很好解決，在update之前lock一下即可解決，
不知咋的，我就是一直下不了手，難道是次數太少，總被我忽略了啊！
還有另一個打擊人的異常：
Unspecified errorSQL:select count(*) from Blog_Content where Year(CreateTime)=2011 and Month(CreateTime)=1 and UserID=67 and TypeID=0 and IsPub=true
這個異常平時不出現，一出現秋色園就基本打不開了，而且會占好長時間，網上搜索的答案好就是什么臨時文件滿了，擠不進去導致的。
這個我又控制不了服務器，也沒啥法子解決。
今天呢，在幾十個網友同時操作寫數據時，情況來了，基本上也是處于打不開的狀態。
于是呢，打算把秋色園從Access升到SQL了。
為啥不考慮SQLite數據庫呢？
其實一開始是有考慮用SQLite的，不過由于時間比較緊，而且框架對于一些函數的通用性，只處理了Access/SQL/Oracle三種，啥意思呢？
就是同一個函數，在不同的數據庫時，名稱，用法，都可能不同，好多其它支持多數據庫的系統，多數寫兩條或多條語句了，不同的數據庫版本提交不同的DLL復蓋。
而CYQ.Data在底層上進行了處理，可以讓1條語句，自動解析成不同數據庫類型的語句，這樣就達到一種寫法，多處兼容的狀態。
由于SQLite和MySQL是最近版本新加的，所以還沒做兼容處理，加上感覺從Access向SQLite導數據不好導，所以就沒用了。
不過我發現，SQL的數據導入導出功能，是有SQLite這一項的，前提好像就是我安裝過SQLite的驅動，有空再嘗試嘗試了。
好了，決定換數據庫了，Access數據庫在遠程服務器，咋整？
由于寄在人家子目錄里，所以除了FTP權限，其它啥權限都沒。
因此，最常見的文件夾壓縮也沒了。
所以呢，就用ICSharpCode.SharpZipLib.dll寫了個Zip在線壓縮，Access壓縮后還是能少好幾倍的大小的。
壓縮之前，要做點什么事呢？
一開始最基本的想法是：停止站點訪問，這樣就不會對數據庫產生讀寫操作。
后來靈機一動，用了另一種方法，什么方法？
秋色園由于自定義了生命周期，于是有很多的統一關口，我只要輕松的把OnPost事件關口給操作，改成操作輸出：
很抱歉：系統正在升級，無法提交數據。
這樣就輕松避開了用戶對數據庫的寫操作了，又保證站點的正常訪問。
接著壓縮了下，300多M壓縮成60多M，56K的網速，下載了十多分鐘，也就下載完了。
下面就接著導數據了：
嘗試把數據導到本機測試一下，發現很多Memo類型的字段，都導不進來！！
還得把數據庫對應字段都改成nvarchar(max)才能導進去。
導完又得把字段改回去，一改一導一動，花了不少時間。
再接著本地測試：
運行秋色園站點，發現首頁出不來，調度發現，少了個字段，重新導麻煩，只好寫sql更新。
再來發現秋色園的兩個系統分類失蹤了，花了不少時間查到原因，于是給補上了。
從本機向遠程導：
再后來，從本機的SQL向遠程的SQL導數據了，由于有數據庫鏈接，自然也能導了，
一開始發現兩邊的字段類型有點區別，還得修正一下。
然后接著導，一直到現在才導了1萬多，還差2萬，所以我就在這寫文章了。
導數據自增ID的問題：
過程中，小小遇到另一個事情，由于自增ID開啟時，是無法導入ID的，
所以在創建表時，只好把自增加ID去掉，想導完數據后再補上。
卻發現，用SQL要補上不是件容易的事，最簡單的方式自然就是用IDE。
不過SQL Server Management Studio鏈接遠程數據庫的話，幾百幾千的數據庫，
基本上夠卡死機子不用動了，更別說改好了。
原來還有VS：
好在發現Microsoft Visual Studio 2005的服務器鏈接，能只顯示單個數據庫，于是用它來修改主鍵和自增ID，的確省時又省心許多。
寫到現在，數據才導了11649條，還有2萬多條，我也得睡了，明早早點起來看了。
補充：
現在早上七點多，起床一看，發現：
錯誤 0xc0202009: 數據流任務: 出現 OLE DB 錯誤。錯誤代碼: 0x80004005。
已獲得 OLE DB 記錄。源:“Microsoft SQL Native Client” Hresult: 0x80004005 說明:“Could not allocate a new page for database 'cyqdata' because of insufficient disk space in filegroup 'PRIMARY'. Create the necessary space by dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.”。
(SQL Server 導入和導出向導)
由于事務回滾，開機導了一個晚上，一條數據也沒導過去，太讓人傷心了！！
再補充：
剛問了下以前的同事，SQL的空間是多大：答復：200M！
OH。。My ..God!!
目前又恢復到Access版本，在提交入口和計數器入口增加了兩個lock，但愿一切平安！！！
目前秋色園正式恢復寫數據操作，歡迎大伙繼續訪問。
原文鏈接：http://www.cnblogs.com/cyq1162/archive/2011/03/14/1983112.html
【編輯推薦】
