記一次資料同步需求的改進(三)

在之前的博文中分享過兩篇關於資料同步的問題，連結如下：
http://blog.itpub.net/23718752/viewspace-1817817/
http://blog.itpub.net/23718752/viewspace-1819981/
最開始開發的同事也是提出想讓我做一個資料的增量同步，起初他們是希望能夠根據時間戳來得到增量的資料，這種方案有一個缺點就是對於update,delete的操作，這種資料變更就很難從源庫中去甄別。所以最後我還是建議他們通過物化檢視的增量重新整理來實現這個需求，對於dml的操作情況得到的增量資料都可以很輕鬆同步。
下面的圖是在改進前和改進後資料庫層面歸檔日誌的切換頻率，可以看到使用物化檢視的增量重新整理之後，redo生成量大大降低，已經從統計圖中看不到日誌切換的影響了。

那麼這種方案是不是一定是最好的呢。實踐和時間真是檢驗這些的一把標尺。
首先修改前和修改後這個同事進行了確認，一切都在計劃之中，資料重新整理速度很快，而且他們這邊也沒有任何的影響，但是當天下午又有幾個部門的同事就開始主動找我了，一部分說他們的程式端開始報錯了。另一部分說他們訪問不到這個表了，希望我來看看。所以問題看似解決了，還是需要一步一步來，我們來總結一下。
第一個問題是程式端開始報錯，是因為在重建表的過程中，我也不知道會影響到他們的部分，所以這個時候會有一個改進之處就是在做這類變更的時候還是需要發一個公告，或者維護宣告，這樣可以提前安排，提前告知，不過因為是統計業務，簡單溝通之後，他們重新檢視，程式裡就恢復正常了。
接著第二個問題，是另外的同事說程式裡提示表找不到了。
我再簡單說說問題背景，這個表做了分庫分表，所以目前存在12個使用者，4個資料庫中存在同樣名字的表，但是裡面的資料是不同的。在統計庫1中是目前是建立了物化檢視，然後對外顯示是一個檢視，其實這個檢視就是包含了這十二個物化檢視的資料。結構如下所示。

而目前的情況是現在存在一個統計庫2需要訪問統計庫1中這個表的資料。這個時候情況就是下面的樣子。
統計庫2是通過db link來訪問統計庫1中的這個”表“的，為什麼一定需要在統計庫2中也要這個表呢，為什麼不能放在統計庫1裡直接查呢，我也帶著這個疑問和開發同事進行 了確認，得到的反饋是因為統計庫2中也存在一個表，假設為表2,表2和統計庫1中的這個”表“需要關聯。

如果按照這樣的情況，為什麼在統計庫2中訪問不了了，關鍵的原因還是在於這個檢視，在統計庫2中是無法直接訪問統計庫1中這個檢視的。儘管建立了同義詞，存在db link，但是統計庫1中的基表沒有相應的db link在統計庫2中。
所以一種思路就是在統計庫2中也建立12個db link的同義詞，然後在統計庫2中也建立出一個檢視來。所以實現方式如下圖所示。

這種方式這是解決了這種訪問的問題，而且看起來確實還比較繁瑣。統計庫1要做的事情，統計庫2也需要再做一遍，統計2中需要基於統計庫1中的12個物化檢視在統計庫2中也建立出12個同義詞來，然後在統計庫2本地建立出一個檢視。
那麼還有什麼改進思路呢，而且還需要保證效能和可用性。
其實還有一種思路，那就是統計庫2中也使用物化檢視來增量重新整理，但是這個增量重新整理不是取四個分庫的資料，而是直接從統計庫1中增量重新整理即可。每次統計庫1重新整理之後，統計庫2再重新整理一次，得到的就是增量的資料了。採用下面的方式即可。

這種方式能夠保證在本地的方式，所以說其實本地的才是最好的。當然也需要一定的空間，而且這個空間需要應該還是需要的，而且也算是合理的。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-1875693/，如需轉載，請註明出處，否則將追究法律責任。