Distal fetching and target side replication configuration are as follows: the setenv (nls_lang=american_america. Zhs16gbk)
The source side oracle user nls_lang=american_america zhs16gbk, db character set zhs16gbk
Target side oracle user nls_lang=american_america al32utf8, db character set al32utf8
Target character field length have done 3 * the original length/2, extended length
Now run into two problems:
One is a lot of the char type field, target side copy part of the field will be submitted to the field length not enough error: ora - 12889 value too long for the column XXX,
The key is whether target side length extended to how to use!! Or to the same mistake!!!!!! Finally think of a way to use=@ strtrim colmap XXX (XXX) c processing can be used, is this why???????????
Second question, even with a method of processing is not an error, but there are few Chinese char fields, will be garbled!!!!! But the rest of the same records in Chinese also not gibberish? The code field is not all the records are garbled, only a small amount of noise, for the hair????????
Two questions may be the same!!!!!!!!!!
O great god answer!!!!!!!!!!!!!!
CodePudding user response:
Tried this?The source side fetching the setenv (nls_lang=american_america zhs16gbk)
Target side copy as the setenv (nls_lang=american_america al32utf8)
CodePudding user response:
OrThe source side fetching the setenv (nls_lang=american_america al32utf8)
Target side copy as the setenv (nls_lang=american_america al32utf8)
CodePudding user response:
Are tried, not on the second floor of the method, finally saw the oracle of the official document, finally determine the way I said above, it turns out to be one of the most close to success, in addition to the problem of char), and other Chinese have no problem, is the Chinese char type and char processing has this problem! Third floor saw some posts saying to other users to set the environment variable nls_lang=american_america. Al32utf installation ogg, then this configuration, I did not use other user is just in the original oracle users, nls_lang in fetching specified in the configuration file, the result also not line!!Increased trimspaces parameters also no Mao Yong!!!!!!
Worry about...
CodePudding user response:
According to the metalink advice: Replicate Chinese Characters AMERICAN_AMERICA. ZHS16GBK to target charset AL32UTF8, Oracle to Oracle, 11.1 and 11.2 (1469735.1) Doc ID beforeThe source side
The setenv NLS_LANG=AMERICAN_AMERICA. ZHS16GBK
End goals:
The setenv NLS_LANG=AMERICAN_AMERICA. ZHS16GBK
In addition to see you in the ogg configuration was also set as originally, but try the following Suggestions such as the user environment variable as follows:
Oracle user nls_lang=AMERICAN_AMERICA ZHS16GBK
CodePudding user response:
Now from this configuration is sent to the target oracle user nls_lang, because the little machine is not only a library, there will be other libraries, another library also have a key to ogg replication, is uf8 to utf8, so oracle user nls_lang is definitely can't change, is not only with other users back up a copy ogg try see!!CodePudding user response:
Is only a field has a problem, with a new user to set the nls_lang=AMERICAN_AMERICA. ZHS16GBK environment variables, replication process inside the same configuration the setenv (nls_lang=AMERICAN_AMERICA. ZHS16GBK), the field still has a problem, there is a problem still not solve the problem!!!!!!!!!!Actually, according to the official copy process configuration would cover system environment variable!!!!!
Sorry I didn't say clear in front of the is only a field has a problem!!!!!!!!!!!!!!!!!!!! This field involves four tables, and the four tables of this field is the same source, now wonder if the source had problems!!!!!!
CodePudding user response:
Key is the key: initialization data use dblink directly insert, the fields are no problem, wait until the ogg automatic synchronization problems will emerge, didn't like the source of the problem!!!!!!!!!!! Big!!!!