秋色 園的運行環(huán)境概況： 目前運行在國外godaddy的虛擬主機的一個子目錄中，數(shù)據(jù)庫為Access。 隨說Access分頁： 1：top max(id) 在CYQ.Data 數(shù)據(jù)框架支持上Access時，以top max(id)為分頁方式。 在 秋色 園沒有多少文章的情況下，基本上維持著正常的秩序。

秋色園的運行環(huán)境概況：

目前運行在國外godaddy的虛擬主機的一個子目錄中，數(shù)據(jù)庫為Access。

隨說Access分頁：

1：top max(id)

在CYQ.Data 數(shù)據(jù)框架支持上Access時，以top max(id)為分頁方式。

在秋色園沒有多少文章的情況下，基本上維持著正常的秩序。

直到秋色園在進化版本時，多字段排序的情況出現(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ù)量，隨便點點感覺分頁也挺快的。

后經(jīng)秋色園的文章上到三四千時，發(fā)現(xiàn)分頁奇慢，已無法讓它在存活了，于是把它給滅了。

3：3次top

滅掉not in方式，換上了3次top，分起頁來那是刷刷刷，速度快的不行。

于是這種方式，一直存到至今，當(dāng)前3-4萬的數(shù)據(jù)中，分頁雖不快，但勉強也能接受。

雖然我一直想從程序上優(yōu)化，讓Access堅持到10萬的數(shù)量級也能正常的表現(xiàn)，

不過有些事總來的太快，Access無法逃脫的弱點：并發(fā)。

Access在并發(fā)寫數(shù)據(jù)上，有著不可估計的錯誤，從秋色園的后臺異常日志記錄中，最常出現(xiàn)的錯誤：

Could not update; currently locked.SQL:Update Blog_User Set VisitCount=64359+1 where ID=111

這個異常一早出現(xiàn)次數(shù)比較多，后來通過程序優(yōu)化之后，通過在內(nèi)存計數(shù)，隨機概率才更新數(shù)據(jù)庫方式，每天平均就2-3次的情況出現(xiàn)。

按理這個也很好解決，在update之前l(fā)ock一下即可解決，

不知咋的，我就是一直下不了手，難道是次數(shù)太少，總被我忽略了啊！

還有另一個打擊人的異常：

Unspecified errorSQL:select count(*) from Blog_Content where Year(CreateTime)=2011 and Month(CreateTime)=1 and UserID=67 and TypeID=0 and IsPub=true

這個異常平時不出現(xiàn)，一出現(xiàn)秋色園就基本打不開了，而且會占好長時間，網(wǎng)上搜索的答案好就是什么臨時文件滿了，擠不進去導(dǎo)致的。

這個我又控制不了服務(wù)器，也沒啥法子解決。

今天呢，在幾十個網(wǎng)友同時操作寫數(shù)據(jù)時，情況來了，基本上也是處于打不開的狀態(tài)。

于是呢，打算把秋色園從Access升到MSSQL了。

為啥不考慮SQLite數(shù)據(jù)庫呢？

其實一開始是有考慮用SQLite的，不過由于時間比較緊，而且框架對于一些函數(shù)的通用性，只處理了Access/MSSQL/Oracle三種，啥意思呢？

就是同一個函數(shù)，在不同的數(shù)據(jù)庫時，名稱，用法，都可能不同，好多其它支持多數(shù)據(jù)庫的系統(tǒng)，多數(shù)寫兩條或多條語句了，不同的數(shù)據(jù)庫版本提交不同的DLL復(fù)蓋。

而CYQ.Data在底層上進行了處理，可以讓1條語句，自動解析成不同數(shù)據(jù)庫類型的語句，這樣就達到一種寫法，多處兼容的狀態(tài)。

由于SQLite和MySQL是最近版本新加的，所以還沒做兼容處理，加上感覺從Access向SQLite導(dǎo)數(shù)據(jù)不好導(dǎo)，所以就沒用了。

不過我發(fā)現(xiàn)，MSSQL的數(shù)據(jù)導(dǎo)入導(dǎo)出功能，是有SQLite這一項的，前提好像就是我安裝過SQLite的驅(qū)動，有空再嘗試嘗試了。

好了，決定換數(shù)據(jù)庫了，Access數(shù)據(jù)庫在遠程服務(wù)器，咋整？

由于寄在人家子目錄里，所以除了FTP權(quán)限，其它啥權(quán)限都沒。

因此，最常見的文件夾壓縮也沒了。

所以呢，就用ICSharpCode.SharpZipLib.dll寫了個Zip在線壓縮，Access壓縮后還是能少好幾倍的大小的。

壓縮之前，要做點什么事呢？

一開始最基本的想法是：停止站點訪問，這樣就不會對數(shù)據(jù)庫產(chǎn)生讀寫操作。

后來靈機一動，用了另一種方法，什么方法？

秋色園由于自定義了生命周期，于是有很多的統(tǒng)一關(guān)口，我只要輕松的把OnPost事件關(guān)口給操作，改成操作輸出：

很抱歉：系統(tǒng)正在升級，無法提交數(shù)據(jù)。

這樣就輕松避開了用戶對數(shù)據(jù)庫的寫操作了，又保證站點的正常訪問。

接著壓縮了下，300多M壓縮成60多M，56K的網(wǎng)速，下載了十多分鐘，也就下載完了。

下面就接著導(dǎo)數(shù)據(jù)了：

嘗試把數(shù)據(jù)導(dǎo)到本機測試一下，發(fā)現(xiàn)很多Memo類型的字段，都導(dǎo)不進來！！

還得把數(shù)據(jù)庫對應(yīng)字段都改成nvarchar(max)才能導(dǎo)進去。

導(dǎo)完又得把字段改回去，一改一導(dǎo)一動，花了不少時間。

再接著本地測試：

運行秋色園站點，發(fā)現(xiàn)首頁出不來，調(diào)度發(fā)現(xiàn)，少了個字段，重新導(dǎo)麻煩，只好寫sql更新。

再來發(fā)現(xiàn)秋色園的兩個系統(tǒng)分類失蹤了，花了不少時間查到原因，于是給補上了。

從本機向遠程導(dǎo)：

再后來，從本機的MSSQL向遠程的MSSQL導(dǎo)數(shù)據(jù)了，由于有數(shù)據(jù)庫鏈接，自然也能導(dǎo)了，

一開始發(fā)現(xiàn)兩邊的字段類型有點區(qū)別，還得修正一下。

然后接著導(dǎo)，一直到現(xiàn)在才導(dǎo)了1萬多，還差2萬，所以我就在這寫文章了。

導(dǎo)數(shù)據(jù)自增ID的問題：

過程中，小小遇到另一個事情，由于自增ID開啟時，是無法導(dǎo)入ID的，

所以在創(chuàng)建表時，只好把自增加ID去掉，想導(dǎo)完數(shù)據(jù)后再補上。

卻發(fā)現(xiàn)，用SQL要補上不是件容易的事，最簡單的方式自然就是用IDE。

不過SQL Server Management Studio鏈接遠程數(shù)據(jù)庫的話，幾百幾千的數(shù)據(jù)庫，

基本上夠卡死機子不用動了，更別說改好了。

原來還有VS：

好在發(fā)現(xiàn)Microsoft Visual Studio 2005的服務(wù)器鏈接，能只顯示單個數(shù)據(jù)庫，于是用它來修改主鍵和自增ID，的確省時又省心許多。

寫到現(xiàn)在，數(shù)據(jù)才導(dǎo)了11649條，還有2萬多條，我也得睡了，明早早點起來看了。

補充：

現(xiàn)在早上七點多，起床一看，發(fā)現(xiàn)：

錯誤 0xc0202009: 數(shù)據(jù)流任務(wù): 出現(xiàn) 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 導(dǎo)入和導(dǎo)出向?qū)?

由于事務(wù)回滾，開機導(dǎo)了一個晚上，一條數(shù)據(jù)也沒導(dǎo)過去，太讓人傷心了！！

再補充：

剛問了下以前的同事，MSSQL的空間是多大：答復(fù)：200M！

OH。My ..God!!

目前又恢復(fù)到Access版本，在提交入口和計數(shù)器入口增加了兩個lock，但愿一切平安！！！

目前秋色園正式恢復(fù)寫數(shù)據(jù)操作，歡迎大伙繼續(xù)訪問。

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com