完成了容災恢復：多層結構下分散式資料庫資料容災概要性設計，待概要設計論證無誤後將進行詳細設計部分。
一、概念：
物件與表的對應關係：
學校有學生表，市裡有學生表，省裡有學生表，它們的表結構應該是完全一致的，只不過學校的學生表只有自己學校的學生資訊，市裡的學生表包含了全市所有學生的資訊，
省裡的學生表包括了全省的學生資訊，其它無差別。以CITY_ID,SCHOOL_ID分別記錄是哪個城市，哪個學校的學生資料。
這樣的設計，在學校上報資料時，只需按時間戳將學生資訊儲存到此表即可。
時間戳：
考慮到江西學籍共540所學校+11個市+1個省，如果使用資料庫時間戳技術可能會造成不一致的情況，使用NTP同步也基本不現實，
初步想到的是MAXID+1的解決辦法，因MAXID+1產生的併發問題，將想辦法盡力解決。
select isnull(max(id),0) + 1 from 表,以下為說明方便，也將MAX_ID+1的方式說明為時間戳方式。需要特別說明的是這個MAX(ID)+1是指對學校為單位的，
就是說比如1234這個學校，它下面有記錄號，6,7,8,9，在學校2345下，也有記錄號6,7,8,9，不是全表唯一的。
刪除：
在設計時沒有刪除的概念，只能是打上刪除標記，設定B_DEL=1，這樣才能把這條記錄的時間戳進行修改，上下一致
副本：
需要在學校、市、省三級都完整快取的學生基本資訊、學生異動資訊表，三處快取的表是一模一樣的，互為副本。
實現方式：
因為WEB程式的無狀態性，長時間執行的大事務的能力有限，所以採用 FLEX+ASP.NET+WEBSERVICE的方式進行實現。
策略
1、完整快取策略
就是全部快取一次。
2、時間戳同步策略（增量同步策略）
每條記錄在同步到另一個主機時，記錄了這條記錄轉存為副本的時間戳。以後兩臺主機進行資料交換時，互相報一下自己的最大時間戳，決定是A向B傳遞資料，還是
B向A傳遞資料，這裡需要在表設計時避免既存在A到B，也存在B到A的情況，這樣的東西設計為兩張表。
行為日誌：
通過業務撰寫（或通過觸發器）等方式對使用者進行的操作進行完整記錄。目前沒有想到此功能具體有哪些實際應用價值，先放到這裡，以後遇到問題再說。
下面以一個學校學生表錄入後上報為例進行具體流程說明：
1、WEB程式在進入系統前，檢查取T_BASE_STUDENT的時間戳，就是最大的變化 MAX ID，將時間戳上傳到市端WEBSERVICE上，WEBSERVICE返回市端此學校的時間戳。
2、程式負責進行對比，是學校比市裡新（），還是市裡比學校新。
如果學校比市裡新（如果存在未上報資料），那麼把比時間戳大的那些資料取前100條上報給市端，市端儲存到資料庫中。遞迴呼叫此函式，再上報100條，直到資料上報完成，上下時間戳一致為止。
如果市裡比學校新（學校資料丟失，需要市裡提供前100條資料，學校將資料儲存到資料庫，遞迴呼叫，直到上下資料完全一致）。
此處可能會出現長時間與市端伺服器進行資料交換的情況，用JAVASCRIPT進行表現可能不太合適，可以考慮使用FLEX+ASP.NET WEBSERVICE的方式進行比如進度條等友好提示資訊的開發。
參考：http://www.oschina.net/code/snippet_153403_10076
3、確定此表上下一致後，學校根據報名庫，錄取庫，收集了學生資訊，然後又手工錄了十名學生。
4、教師檢查後，認為無誤，點選了上報按鈕。我們將表中這些學生資料的需要上報標識為1。
5、程式將需要上報標識為1，同時上報到市端的列記錄為NULL的資料進行上報。上報完成後修改NULL為上報時間。
6、至此，上下資料是完全一致的，副本儲存成功。
7、市端對學生的資料進行了修改，比如幫著把姓名修改了（當然，這不是實際業務，只是為了說明問題），那麼這條記錄的時間戳將進行修改，修改為此學校此表記錄的MAXID+1。
8、學校端再次進入學籍系統前，檢查是不是有需要更新的資料，有需要的直接下載，保持與市端資料副本一致。
總結：
基於時間戳的增量副本辦法，基本上可以解決資料不一致、容災等問題，但也可能因為各種原因造成資料副本快取失敗，那時我們的備用辦法將生效，就是使用完整快取策略進行一次全新快取。
因為可能資料量大等問題，完整快取可以考慮採用FLEX+WEBSERVICE程式實現之。