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