粗心致使GG同步失效 安全
熊熊最近剛剛加入了一家新公司，與一個一樣有着OCM水平的哥們一塊兒搭檔DBA，因爲對GoldenGate操做不是很熟悉，所以在昨天的操做中有了一個小錯誤，特寫此文用以警示本身~ 服務器
昨天一共收到了3封開發部發過來的數據變動的需求單，因爲已經審覈經過，所以由熊熊來一一操做。 架構
每次收到郵件之後，必定首先要仔細的查閱發來的SQL和PL/SQL是否合理，檢查每一個對象，每一個表是否有主鍵，有索引，索引是否合適等等，肯定無誤才能夠進行操做。 app
前不久一個開發人員發來一個存儲過程的PL/SQL，簡單的一個主鍵問題，竟然改了四五回，我都替他以爲他回覆的郵件很差看了，因此說，在平常工做中，技術能力只佔一小部分，更多的是態度問題，和謹慎操做~ ide
說別人容易，到本身這裏又馬虎了，唉~ spa
第一個請求所涉及的用戶無需同步到查詢庫，所以直接在覈心庫裏審覈SQL沒有問題後，進行操做便可，對線上業務沒有影響。很快就搞定了 orm
第二個請求涉及GG同步，由於安全性考慮，咱們的GG沒有開啓DDL自動變動同步，所以每次涉及數據架構變動的時候，須要先關閉GG上相應的模塊，查看兩邊同步的對象是否存在，而後分別對主庫和查詢庫進行數據變動操做，肯定無誤後從新開啓GG相應的模塊。 xml
第三個請求有兩個步驟，都分別涉及了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啓動並不會報錯在此時，所以熊熊就沒在乎。 blog
一直到下班的時候，開發查看同步的表，發現數據沒有同步，給那個DBA哥們打電話，此時GG對這張表的同步已經失效了一個小時。那兄弟很快遠程登陸服務器解決了該問題，並從新抽取了數據，熊熊上線後看到了他的留言，感受特別很差意思，唉~
因此，DBA是個很是謹慎的工做，每一步操做都要特別的仔細，此次僅僅是由於一個標點符號，就致使了一張表一個小時的數據沒有同步，幸好發現的早，熊熊一直認爲在這行作這麼久了，結果仍是粗心馬虎了，實在是不應，特作此文，警示本身，也是提醒各位DBA朋友~
