由於整體規劃的需要，需要將目前公司的
moss
伺服器遷移到工地去。
13臺伺服器要從深圳市區搬遷到
100多公里的外郊區。搬遷前我們應用方面已經將風險和相應的需要備份的東西提了出了。就我原來的理解，伺服器變遷不就搬過去，再啟起來就
ok了。為了確保整個過程的安全和穩定，公司還特意請了微軟的同事來做風險評估。遷移整個過程中讓人感覺還是比較順利，遷移過去後只進行了簡單的測試。
往往噩夢就是在這樣的平淡中產生，第二天下午收到使用者反饋某個站點中的某些文件出現無法開啟，去掉
ie的錯誤友好提示後顯示的是
500內部錯誤。
通過檔名在[alldocs]中找到出錯文件
id然後直接在資料庫中查詢
select [id]
,[siteid]
,[deletetransactionid]
,[parentid]
,[size]
,[level]
,[content]
from [wss_content_8500].[dbo].[alldocstreams]
where id ='a80ae532-ac04-4978-ba1a-01abccc397ae'
--where id ='f8632684-3ae7-42b1-aa80-b90af513ffe1'
測試了搜尋兩條記錄，一條是能正常開啟的文件，一條在應用層無法開啟的文件。
正常開啟的正常返回資料，不正常開啟的返回錯誤
網路故障
基本上可以排除應用層面的問題，應該從資料庫、硬體、網路、防火牆上去排查。
後在資料的日誌中發現
checkdb
出現1880
多個資料不一致性錯誤。當天已經將情況匯報給了我們的伺服器管理人員。
第二天管理人員開了微軟的
case
，當天晚上與微軟人員進行了檢查，最終發現目前我們有三個站點的資料出現了資料庫損壞，與微軟同事、領導進行了長達
2個小時的討論，最終還是只能還原，檢查搬遷前的備份，沒有問題，可以確定是搬遷過程導致的。那就只能恢復到周五資料，這兩天的資料就只能做增量的遷移。微軟不建議直接運算元據庫，也沒有很好的方案。對於資料量少的兩個站點決定採用手工的方式。有乙個站點天內更新了超過
1200
條記錄，
600條為列表、
600個位文件。立刻
call
我們的開發人員來寫乙個應急的遷移程式。
然後是兩個通宵的，留有一下經驗反饋以供參考
伺服器搬遷等等操作的具體步驟如下
1、先在資料庫指向
dbcc checkdb(
資料庫名
) 確保搬遷前的資料庫是好的
2、搬遷前做好相應的資料庫全備
3、搬遷後對資料庫進行
dbcc checkdb
確保資料庫在搬遷後的資料庫是好的
4、如果出現不一致性錯誤就算是乙個，不建議通過
checkdb
的修復命令修復，建議直接還原備份
5、在日常的巡檢中吧
checkdb
作為乙個必備的操作步驟
檔案作為資料流儲存在資料庫容易導致這樣的不一致性錯誤，據微軟的
sql工程師說最近已經處理了
3單類似的故障。所以還是盡早公升級
sql 2008
使用檔案流的方式來儲存檔案資料吧
面試真的很重要
首先我不是面試人員，不是hr，我只是普通寫 的，水平還不咋地。為啥給我個高階 的職位，總結了一下，原因只有兩個 一 面試時你的白胡水平 俗話就是扯淡，但一定時要帶技術含量的扯淡 二 簡歷。先說扯淡吧，這個我在行。由於面善，看起來比較容易讓大家接近，所以也就有了點資本 我有點自以為是了，呵呵 面試的時...
觀念真的很重要
這是為什麼呢？觀念真的很重要。因為觀念問題，我感覺我不需要了解這些資訊，我也不想花時間來打破我看似和諧的生活或者工作狀態，也許在某個時間，我發現我的朋友都在玩朋友圈，都在說一些網路熱詞讓我感覺恍如隔世 發現三國殺擴充套件版設計的非常精妙，也或者我與他們不期而遇讓我感覺有點相見恨晚，這麼好用 好玩的東...
索引真的很重要 ！！
索引用來快速地尋找那些具有特定值的記錄，所有的mysql索引都以b 樹的形式儲存。如果沒有索引，執行查詢的時候mysql必須從第乙個記錄開始掃瞄整個表中的所有記錄，直至找到符合要求的記錄。表裡面的記錄數量越多，這個操作的代價就越高。如果作為搜尋條件的列上已經建立了索引，mysql無需掃瞄任何記錄既可...