自我反省系列
粗心導致GG同步失效
熊熊最近剛剛加入了一家新公司，與一個同樣有着OCM水平的哥們一起搭檔DBA，由於對GoldenGate操作不是很熟悉，因此在昨天的操作中有了一個小錯誤，特寫此文用以警示自己~
昨天一共收到了3封開發部發過來的數據變更的需求單，由於已經審覈通過，因此由熊熊來一一操作。
每次收到郵件以後，一定首先要仔細的查閱發來的SQL和PL/SQL是否合理，檢查每個對象，每個表是否有主鍵，有索引，索引是否合適等等，確定無誤纔可以進行操作。
前不久一個開發人員發來一個存儲過程的PL/SQL，簡單的一個主鍵問題，居然改了四五回，我都替他覺得他回覆的郵件不好看了，所以說，在日常工作中，技術能力只佔一小部分，更多的是態度問題，和謹慎操作~
說別人容易，到自己這裏又馬虎了，唉~
第一個請求所涉及的用戶無需同步到查詢庫，因此直接在覈心庫裏審覈SQL沒有問題後，進行操作即可，對線上業務沒有影響。很快就搞定了
第二個請求涉及GG同步，因爲安全性考慮，我們的GG沒有開啓DDL自動變更同步，因此每次涉及數據架構變更的時候，需要先關閉GG上相應的模塊，查看兩邊同步的對象是否存在，然後分別對主庫和查詢庫進行數據變更操作，確定無誤後重新開啓GG相應的模塊。
第三個請求有兩個步驟，都分別涉及了GG同步，第一個請求需要停止GG上相應的模塊，然後由開發人員在頁面上做好表的數據變更後，通知熊熊，收到通知後，熊熊desc兩邊的表，將增加的對象在查詢庫相應表下用命令一一增加（alter table table_name add column column_name type），嚴格注意增加列的順序，操作確認無誤後，重新開啓兩邊的GG模塊。
一直到這裏都沒有問題，第二個請求同樣涉及GG同步，由於是新對象，需要在相應模塊裏增加表，並且需要執行（add trandata user.table）來進行確定表傳遞（此步驟需要dblogin），在配置相應模塊裏增加該表名稱的時候，熊熊一開始少增加了標點符號（MAP USER.TABLE_NAME, TARGET USER.TABLE_NAME），結果熊熊少增加了逗號和分號，導致查詢庫模塊啓動時候報錯，修改以後OK了，但是主庫的相關模塊同樣少了分號（TABLE USER.TABLE_NAME;），但是GG啓動並不會報錯在此時，因此熊熊就沒在意。
一直到下班的時候，開發查看同步的表，發現數據沒有同步，給那個DBA哥們打電話，此時GG對這張表的同步已經失效了一個小時。那兄弟很快遠程登錄服務器解決了該問題，並重新抽取了數據，熊熊上線後看到了他的留言，感覺特別不好意思，唉~
所以，DBA是個非常謹慎的工作，每一步操作都要特別的仔細，這次僅僅是因爲一個標點符號，就導致了一張表一個小時的數據沒有同步，幸虧發現的早，熊熊一直認爲在這行做這麼久了，結果還是粗心馬虎了，實在是不該，特做此文，警示自己，也是提醒各位DBA朋友~