OGG-03517 錯誤解決曆程

OGG-03517 錯誤解決曆程

環境介紹：

　　源端：sybase資料庫，伺服器字元集iso_1，資料字元集cp936；

　　目標端：Oracle11g，字元集AL32UTF8。 

replicat進程錯誤：

　　ERROR  OGG-03517  Conversion from character set zhs16gbk of source column CYXM to character set UTF-8 of target column CYXM failed because the source column contains a character that is not available in the target character set.

解決心路曆程：

　　一開始遇到這個問題，懵了，這是什麼鬼，CYXM這個欄位的字元轉換錯誤？不對啊，logdump看了一下資料，再去源庫看資料，沒什麼錯呀。goldengate發什麼瘋，行吧，那我就根據前人的經驗，使用SOURCECHARSET PASSTHRU這個參數。一重啟，行啊，夠給力的，進程不報錯誤了，資料庫資料亂碼了~呵呵噠。去看了官方介紹，原來SOURCECHARSET PASSTHRU這個參數是將我聲明的源端字元集參數（ZHS16GBK）去掉，直接就將源端伺服器字元集（ISO-8859-1）的資料插入進來，怪不得會亂碼。看樣子這個參數不能用。找了度娘好多次（目前還不會用Google），最後總結出現這個問題的原因可能是：

　　　　1. sybase的cp936字元集和oracle的zhs16gbk字元集是超集和子集的關係；

　　　　2. zhs16gbk 和 utf-8 字元轉換存在編碼問題。

　　故此，針對字元轉換的問題，我是暫時沒有解決方案了。但是突然想到，能不能跳過這個字元轉換的錯誤呢？跑到Goldengate交流群上提問：

廣州-tan()  11:28:33 請問各位，Goldengate的replicat進程設定了出現錯誤記錄到discart檔案中，但是，這次出現了一個OGG-03517的錯誤，它直接就Abend了，錯誤報表是這條記錄的一個欄位字元集轉換錯誤，我檢查了一下，應該是中文字元集超集與子集的原因 但是，目前Oracle的字元集對中文的支援就只能這樣了，所以我想讓它出現類似錯誤時，不Abend，先記錄discard檔案 可以實現嗎？ 隨風()  11:30:24 可以 廣州-tan()  11:30:34 請問怎麼設定？ PONG()  11:30:38 用這個參數應該可以 隨風()  11:33:45 reperror(-03517,discard) 廣州-tan()  11:35:46 @隨風 可以寫多個reperror參數嗎 隨風()  11:36:06 可以啊 廣州-tan()  11:36:21 reperror(OGG-03517,discard) reperror(Default,discard) 這樣寫？ 隨風()  11:36:23 兩個錯誤就寫兩個就行 隨風()  11:36:59 reperror(-03517,discard) 就這個寫法 廣州-tan()  11:37:42 那兩個錯誤，是寫兩個reperror，還是寫一個reperror 隨風()  11:37:53 兩個 寫上不同錯誤號碼就行 廣州-tan()  11:38:16 恩，多謝 @隨風  @PONG

　　然後我就嘗試使用REPERROR這個參數，想通過discard檔案去捕獲這個錯誤，不至於導致REPLICATE進程ABEND了，REPERROR的使用方式如下：

REPERROR { ({DEFAULT | DEFAULT2 | SQL_error | user_defined_error},{ABEND | DISCARD | EXCEPTION | IGNORE |RETRYOP [MAXRETRIES n] |TRANSABORT [, MAXRETRIES] [, DELAYSECS n | DELAYCSECS n] |TRANSDISCARD |TRANSEXCEPTION}) |RESET }

　　將prm檔案加入REPERROR參數後，我興高采烈的start replicat進程，呵呵噠，還是abend。然後又去上了度娘，發現，REPERROR是可以捕獲錯誤，但是OGG的錯誤，是沒法捕獲的啊~~~~。然後我又是一頓搜啊，最後在oracle的官方文檔找到：

REPLACEBADCHAR Valid For Extract and Replicat Description Use the REPLACEBADCHAR parameter to control the response of the process when a valid code point does not exist for either the source or target character set when mapping character-type columns. By default, the check for invalid code points is only performed when the source and target databases have different character sets, and the default response is to abend. You can use the FORCECHECK option to force the process to check for invalid code points when the source and target databases have the same character set. REPLACEBADCHAR applies globally. Default ABORT Syntax REPLACEBADCHAR {ABORT | SKIP | ESCAPE | SUBSTITUTE string | NULL | SPACE} [FORCECHECK] [NOWARNING]

　　MY GOD,我好像看到了救星，行了，就用你了。

　　我在prm檔案中加入：

　　　　REPLACEBADCHAR SKIP NOWARING

　　目的：當出現某些欄位的字元轉換錯誤時，跳過此條記錄，並不發出WARING資訊。

　　注意：雖然官方解釋道：如果使用skip選項，可能會導致資料不一致。但是吧，我這邊使用該參數後，進程不報錯了，資料也一致。我也在奇怪為什麼會這個樣子。不過現在進程至少不會因為這種字元轉換的問題abend了，全部表的資料也能即時同步了。但是以後還是需要注意字元轉換錯誤的那個表，看看資料是否一致，如果一致，那就不用鳥了。如果不一致，那隻能再次排查，尋求解決方案了。

　　by the way，至於我為什麼使用NOWARING選項，我喜歡，我高興！

 

直接解決方案（不想看我一大堆廢話的人兒）：

　　REPLACEBADCHAR SKIP NOWARING