變更追蹤和資料還原

需要同步處理的應用程式必須考慮已啟用變更追蹤的資料庫還原成舊版資料的情況。當容錯移轉到非同步資料庫鏡像,或是當使用記錄傳送而發生失敗時,從備份還原資料庫之後可能會發生此情況。下列案例說明這個問題:

  1. 資料表 T1 有進行變更追蹤,此資料表的最小有效版本為 50。

  2. 用戶端應用程式會同步處理版本 100 上的資料,並取得版本 50 與 100 之間所有變更的相關資訊。

  3. 版本 100 之後會對資料表 T1 進行其他變更。

  4. 在版本 120 上發生失敗情況,而且資料庫管理員會還原有遺失資料的資料庫。在還原作業之後,資料表會包含直到版本 70 的資料,而最小的同步處理版本仍然是 50。

    這表示同步處理的資料存放區包含了不復存在於主要資料存放區內的資料。

  5. T1 會更新許多次。這會將目前的版本帶到 130。

  6. 用戶端應用程式會再次同步處理,並提供上一次同步處理的版本 100。用戶端將會成功驗證這個號碼,因為 100 大於 50。

    用戶端會取得版本 100 與 130 之間的變更。此時,用戶端不會意識到 70 與 100 之間的變更與之前不同。用戶端與伺服器上的資料不會同步處理。

請注意,如果資料庫復原到版本 100 之後的某一點,同步處理就不會有任何問題。用戶端和伺服器會在下一次同步處理間隔期間正確同步處理資料。

變更追蹤不支援從遺失資料進行復原。但是,有兩個選擇可用來偵測這些類型的同步處理問題:

  • 將資料庫版本識別碼儲存在伺服器上,並在每次復原資料庫或是遺失資料時更新這個值。每一個用戶端應用程式都將儲存這個識別碼,而且每一個用戶端在同步處理資料時,都必須驗證此識別碼。如果發生資料遺失,識別碼將不會相符,而用戶端也將重新初始化。但是有一項缺點,就是當資料遺失未跨越上一次同步處理的界限時,用戶端可能會執行不必要的重新初始化。

  • 當用戶端查詢變更時,請在伺服器上記錄每一個用戶端上一次同步處理的版本號碼。如果資料有問題,上一次同步處理的版本號碼將不會相符。這表示必須重新初始化。