Pregunta

Tengo 2 bases de datos y quiero transportar una tabla existente que contiene una columna CHAR desde la base de datos A a la base de datos B.

La base de datos A es Oracle 9i, tiene la codificación WE8ISO8859P1 y contiene una tabla " foo " con al menos 1 columna de tipo CHAR (1 char). No puedo cambiar la tabla en la base de datos A porque es parte de una configuración de terceros.

La base de datos B es mi propia base de datos Oracle 10g, que utiliza la codificación AL32UTF8 por todo tipo de razones, y quiero copiar foo en esta base de datos.

Configuro un enlace de base de datos de la base de datos B a la base de datos A. Luego emito el siguiente comando:

* crea una barra de tabla como select * from # link # .foo; *

Los datos se copian muy bien, pero cuando verifico los tipos de columnas, observo que CHAR (1 char) se ha convertido a CHAR (3 char), y al consultar los datos en la base de datos B, es todo Rellenado con espacios.

Creo que en algún lugar bajo el agua, Oracle confunde sus propios bytes y caracteres. CHAR (1 byte) es diferente de CHAR (1 char), etc. He leído todo eso.

¿Por qué cambia el tipo de datos a un CHAR rellenado (3 caracteres) y cómo puedo evitar que Oracle haga esto?

Editar: Parece que tiene que ver con la transferencia de CHAR entre dos niveles de parches específicos de Oracle 9 y 10. Parece que realmente es un error. Tan pronto como lo descubra, publicaré una actualización. Mientras tanto: no intente mover los CHAR entre las bases de datos como describí. VARCHAR2 funciona bien (probado).

Edición 2: Encontré la respuesta y la publiqué aquí: ¿Por qué Char (1) cambia a Char (3) al copiar sobre un DBLINK de Oracle? Lástima que no puedo aceptar mi propia respuesta, porque mi problema está resuelto.

¿Fue útil?

Solución

Este problema se debe a la manera en que Oracle (mis) maneja las conversiones de caracteres entre diferentes conjuntos de caracteres según la definición de longitud de columna original. Cuando define el tamaño de una columna de tipo de carácter en bytes, Oracle no sabe cómo hacer una conversión y la detiene. La solución es definir siempre la longitud de un tipo de carácter en caracteres .

Para obtener una explicación más detallada del problema y cómo descubrí esto, eche un vistazo a http://www.rolfje.com / 2008/11/04 / transporting-oracle-chars-over-a-dblink /

Otros consejos

Necesitas aprender la diferencia entre el WE8ISO8859P1 NLS (que almacena los caracteres en un byte) y el AL32UTF8 que almacena los caracteres en hasta cuatro bytes. Deberá pasar un tiempo de calidad con el Soporte de idioma nacional (NLS) de Oracle Documentación . Oracle realiza automáticamente la conversión a través del enlace de la base de datos, en un intento de ser útil.

Intente lo siguiente desde su indicador de SQL:

ALTER SESSION NLS_NCHAR WE8ISO8859P1 
create table bar as select * from #link#.foo;

Lo primero que intentaría es crear la tabla NO como CTAS, pero con una lista de definiciones de columna y tratar de realizar una inserción de las primeras miles de filas. Si eso no tuviera éxito, sería muy claro por qué ... y tendrías una rápida confirmación de que Thomas Low está en lo correcto.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top