2012-02-29 2 views
4

SQL Server 2005에서 2008R2로 업그레이드하기 전에 연결된 서버가 제대로 작동했지만 특정 테이블에서 쿼리 할 때이 오류가 발생합니다 (다른 테이블에서도 여전히 작동 함).SQL Server에서 Oracle 연결된 서버에 대한 문자 인코딩

"linked server "PROD" reported an error. The provider did not give any information about the error...Cannot fetch a row from OLE DB provider "OraOLEDB.Oracle" for linked server "PROD".

내가 한 행에 문제를 좁힐 수 있습니다 내가 그 행이 쿼리를 실행할 때 다른 오류 얻을

:

select * from openquery(PROD, 'SELECT ID, NAME FROM ITEMS WHERE ID = 5437') 

오류 :

OLE DB provider "OraOLEDB.Oracle" for linked server "PROD" returned message "01".

OLE DB provider "OraOLEDB.Oracle" for linked server "PROD" returned message "ORA-29275: partial multibyte character".

그리고 다음과 같이 덤프로 잘못된 NAME 열을 조회 할 수 있습니다

select * from openquery(PROD, 'SELECT DUMP(NAME) FROM ITEMS WHERE ID = 5437') 

반환 :

Typ=1 Len=16: 77,73,88,84,69,67,79,32,68,69,32,84,73,68,65,193

다음 SELECT CHAR (77) + CHAR (73) +를 사용하여 다시 빌드합니다. .. 그리고 나는 "MIXTECO DE TIDAÁ"를 얻는다. 요점은 Oracle 데이터의 CHAR (193)이 내 쿼리를 실패하게 만드는 것입니다. 하지만 어떻게 수정해야합니까? RAW로 ... 나는 ... "확인"하는 방법을 모르는 나는 '읽는 방법을 모르는, 그러나

ORA-29275: partial multibyte character

Cause: The requested read operation could not complete because a partial multibyte character was found at the end of the input.

Action: Ensure that the complete multibyte character is sent from the remote server and retry the operation. Or read the partial multibyte character as RAW.

:

오라클 (https://forums.oracle.com/forums/thread.jspa?threadID=551784)이 수수께끼의 단서를 제공 ".

SQL Server는 64 비트 Windows 서버 2008R2 시스템에서 실행되는 64 비트 버전이며 64 비트 Oracle 11gR2 클라이언트가 설치되어 있습니다. SQL에서

열 : NAME의 NVARCHAR 오라클 (60) NULL 열 : NAME의 VARCHAR2 (60)

SQL에서

, sp_helpsort를 반환 : 오라클에서

Latin1-General, case-insensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 52 on Code Page 1252 for non-Unicode Data

의 NLS_CHARACTERSET은 다음과 같습니다 AL32UTF8

도움이되는 이유 :이 기능이 작동하지 않는 이유는 무엇입니까? 추가 정보가 필요한 경우 알려주십시오.

답변

3

Oracle 데이터베이스에 저장된 193은 UTF-8 문자 세트에서 유효한 문자가 아닙니다. UTF-8은 단일 바이트를 사용하여 처음 128 자 (0-127)를 인코딩하지만 7 비트 ASCII를 초과하는 항목은 2 바이트 이상의 저장 공간을 필요로합니다. 어떤 응용 프로그램이든이 데이터가 잘못 삽입 된 것처럼 보입니다. 클라이언트와 데이터베이스간에 데이터가 전송 될 때 발생하는 문자 집합 변환을 우회하도록 잘못 구성 되었기 때문일 수 있습니다.

Oracle 데이터베이스에 데이터를 삽입 한 응용 프로그램은 어떤 언어/프레임 워크/API입니까? 클라이언트 NLS_LANG 매개 변수는 무엇입니까?

+0

감사합니다. 팁을 기반으로 문자 인코딩에 대해 좀 더 연구했습니다. 데이터가 어떻게 거기에 들어 왔는지, 동료가 아닌지 확실하지 않습니다. 아마도 어딘가에서 가져온 오래된 데이터 일 것입니다. 또한 NLS_LANG는 'AMERICAN_AMERICA.AL32UTF8'입니다. –

+0

두 테이블에서 쿼리가 실패했습니다. 우리는 각 테이블에서 한 항목의 데이터를 변경했으며 모든 것이 작동했습니다. 흥미로운 것은 오래된 설정 (SQL Server 2005, Oracle 공급자 10g)이 불량 데이터를 질식시키지 않았다는 것입니다. 한 경우에는 대체 문자 (U + FFFD)를 대체하고 다른 경우에는 문제가되는 문자를 잘라 냈습니다. –

+0

@JoeMcCarthy - 클라이언트'NLS_LANG' 문자 세트가 데이터베이스 서버의 문자 세트와 일치하면 Oracle은 클라이언트와 서버간에 데이터가 이동할 때 문자 세트 변환을 무시합니다. 즉, 클라이언트 응용 프로그램은 실제로 유효한 UTF-8 데이터를 데이터베이스에 보내야합니다. 클라이언트 응용 프로그램이 다른 인코딩 (Windows-1252, ISO-8859-15 등)으로 데이터를 보내는 경우 데이터베이스에 유효하지 않은 데이터가 생성됩니다. 클라이언트'NLS_LANG'가'AL32UTF8' 문자 세트를 지정해야한다는 것은 매우 드뭅니다. –

관련 문제