Menu de navegação

[Andre LuizParticipante]

Obrigado por permitirem abrir expor as dificuldades aqui.

Bom tive que trocar um bando de dados Oracle 11G XE de maquina, onde os dois sistemas operacionais eram o CENTOS 6.4, mas ao fazer a importação dos dados por meio de insert’s pelo sqldeveloper para o novo servidor todas as palavras com acentos e com Ç foram substituídos por ¿ os dois bandos de dados foram configurados com o mesmo characterset:

NLS_CHARACTERSET WE8MSWIN1252
NLS_NCHAR_CHARACTERSET AL16UTF16

no servidor de origem as palavras estavam corretas

pergunta:

Como corrigir estas palavras sem ter que importar novamente os dados, visto que é um servidor de produção e os novos lançamentos estão sendo gravados também com os caracteres convertidos para ¿

Alguém pode me passar alguma dica de como resolver este?

Obs.: No SO do servidor de origem o characterset é pt_BR.utf-8 e o SO do servidor novo o characterset é en_US.utf8

Agradeço a atenção de todos.

[rmanParticipante]

@Andre Luiz

Se configurado a variável de ambiente NLS_LANG de maneira adequada no lado cliente a conversão de charset é feita automática e transparente.

Em ambiente windows geralmente é configurado como BRAZILIAN PORTUGUESE_BRAZIL.WE8MSWIN1252

Para os que já estão convertido errado, ou seja,com o simbolo ¿ vai ser um problema.

[José Laurindo ChiappaModerador]

Blz ? Então, não é só NLS_LANG, outras coisas podem estar influenciando, mas primeira coisa vamos tentar Identificar a causa do problema : vou repassar o que deveria estar setado na esperança que acompanhando vc identifique onde errou…
No caso, quando vc fala que “No SO o characterset é…” , Creio que vc está se referindo ao LOCALE , né ? A porção inicial do LOCALE indica a língua e o .characterset indica o charactertset – para a análise que estamos fazendo ref. acentuação, esse valor de .UTF8 funciona – UTF8 é um superset do WIN1252, a conversão rola na boa… Porém, embora a primeira parte (a linguagem) não influencie na acentuação em si o fato de estar diferente nos dois servidores indica que MUITO PROVAVELMENTE na hora de instalar o Linux no novo servidor escolheram linguagem e local DIFERENTE do servidor original, isso Não É Legal : pode levar a situações onde determinado pacote/configuração de utilitários do SO fique diferente…. penso que isso não Justifica per se uma reinstalação, mas se outros fatores levarem a isso, PLZ usa exatamente a mesma língua e local no novo servidor que já estava no server origem…
Ainda falando sobre Sistema Operacional, locale estando ok a próxima configuração é o ENCODING do software de terminal gráfico que vc está usando – vc TEM que o ajustar para que ele use ou UTF-8 ou WIN1252…. No meu Linux de teste estou usando Oracle Linux 6 com KDE como GUI, nele esse ajuste é feito na menu “Terminal” opção “Set Character Encoding” : não estou com um Centos 6 aqui pra testar, nem sei qual é tua GUI, mas Pesquise e Verifique como fazer esse ajuste se não estiver ok…

Avançando : vc disse que extraiu os dados pelo SQL Developer, gerando um scripts com os INSERTs necessários, né ? O que vc tem que checar é se as opções de ENCODING do SQL DEVELOPER estão apontando pra UTF-8 ** ou ** pra WIN1252… Confirme o ENCODING no menu “Tools” opção “Preferences” na seção Environment, em Code Editor/Font que esteja uma Fonte que possua caracteres acentuados, ** E ** quando usou a opção “Export” confirme que ESSE encoding estava apropriado, também…
SE tudo estiver OK, o arquivo com os imports vai ter sido gerado com o encoding correto :

[oracle@localhost ~]$ file -i export.sql
export.sql: text/plain; charset=utf-8
[oracle@localhost ~]$

E o conteúdo acentuado vai ser exibido corretamente :

[oracle@localhost ~]$ cat export.sql
——————————————————–
— DDL for Table TAB_ACENTOS
——————————————————–

CREATE TABLE “SYSTEM”.”TAB_ACENTOS”
( “C1” NUMBER,
“C2” VARCHAR2(44 BYTE)
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE “SYSTEM” ;
REM INSERTING into SYSTEM.TAB_ACENTOS
SET DEFINE OFF;
Insert into SYSTEM.TAB_ACENTOS (C1,C2) values (1,’ÁÉÍÓÚÇ’);
Insert into SYSTEM.TAB_ACENTOS (C1,C2) values (2,’áéíóúç’);
commit;

[oracle@localhost ~]$

==>> SE até aqui vc chegou normal, a Suposição é que vc executou esse script de INSERTs com alguma tool de modo-texto (seja chamando o sqlplus manualmente, seja de dentro do SQL Developer abrindo o script e usando a opção de “Run as Script, que por trás da GUi chama o sqlplus) : se foi isso, além das configs de SO citadas, é ** OBRIGATÓRIO ** que a variavel de ambiente NLS_LANG esteja setada, em especial o componente final dela, o .characterset : sem isso é asumido que o caracterset é US-7 bits, o que VAI causar sintoma similar ao que vc reporta…

Tudo OK, para CONFIRMAR o resultado final vc pede um DUMP, assim :

select c1, c2, dump(c2, 1010) from TAB_ACENTOS;

Obtenho o seguinte resultado (pra um SQL DEVELOPER com encodig UTF-8, arquivo-texto em UTF-8, etc, conectado num banco com WEBWIN1252 como caracterset, após ter executado o script em questão no SQL DEVELOPER :

1 ÁÉÍÓÚÇ Typ=1 Len=6 CharacterSet=WE8MSWIN1252: 193,201,205,211,218,199
2 áéíóúç Typ=1 Len=6 CharacterSet=WE8MSWIN1252: 225,233,237,243,250,231

===>> Se vc for confirmar os códigos decimais dos caracteres acentuados cfrme https://en.wikipedia.org/wiki/Windows-1252 , vc vai ver que REALMENTE o A maiúsculo com acento é 193, o E maiúsculo com acento é 201, Ç é 199, etc, tá provado que a Gravação foi Perfeita, OKDOC ??

Muito bem, aí sim segue a sua resposta : com tudo configurado e verificado no SQL Developer e no SO, eu diria pra vc executar no SQL DEVELOPER a consulta com DUMP, que nem eu exemplifiquei acima, e DESCUBRA como está gravado os caracteres E qual foi o characterset exato , se não estiverem que nem acima, está PROVADO que vc falhou algum dos pontos de configuração acima… Nesse caso, DEPOIS de corrigir as configs, para vc Corrigir a lambança vc teria que descobrir QUAIS códigos foram usados ao invés do código correto E trocar os caracteres… Por exemplo, digamos que para Á ao invés de 193 o dump mostrou que estava sendo gravado, digamos, com código 128, vc faria :

UPDATE nomedatabela SET colunastring = replace(colunastring, chr(128), chr(193) ) ;
COMMIT;

E asim por diante para todos os outros caracteres acentuados, ok ? Mas de cara dá pra ver que é um tralaho danado, imho se é banco XE necessariamente o volume de dados é pequeno, então eu REFARIA a exportação, acho que daria muito menos trabalho… Blz ??

[]s

Chiappa

[Andre LuizParticipante]

Obrigado pelo esclarecimento, vou fazer este procedimento e ver se deu certo, não tem como eu fazer outro imp, pois o servidor antigo já foi formatado pelo TI e já tem lançamentos novos.

Meu erro, por falta de experiencia, foi não ter conferido se as configurações feitas pelo TI se estavam iguais à do servidor origem, conforme eu havia pedido para ser feito.

Mas é assim mesmo que aprendemos…..
assim que concluir as configurações e teste postarei aqui o resultado.

[José Laurindo ChiappaModerador]

Yep : só deixando Claro, porém, que como citei no texto há Realmente algumas configs que os syadmins/pessoal de infra deveriam ter feito (como a linguagem de instalação, as variáveis NLS do usuário Oracle, sim, entre outras) MAS há também várias outras (como o ENCODING do SQL Developer ** tanto na origem quanto no servidor destino**, a Checagem da codificação do arquivo-texto com os INSERTs, a Transferência do arquivo-texto com os INSERTs em modo binary, etc, etc) que via de regra são Total responsabilidade do time de DBAs, que creio é a sua área, ok ? Então não só vc não verificou o trabalho dos sysadmin QUANTO não verificou, imagino, o trabalho de config dos DBAs que estabeleceram esse ambiente…. Da mesma forma, import (parcial que seja ) dos dados para conferir imho é o ** mínimo ** que devia ter sido checado antes de considerar a transferência OK e formatar o servidor origem …. Falha total de Procedimento aí….

Bom, agora que vc está nessa situação sim : o primeiro passo é ** CONFERIR ** as configs todas que citei nesse servidor, no ambiente (principalmente fontes, encoding do terminal e variáveis de ambiente) e no SQL Developer (até para evitar probs no futuro E se assegurar que o ambiente é capaz de exibir corretamente os caracteres especiais)… Isso é Crucial, sim sim ???
Só Depois que Provou que o servidor, o ambeinte e o SQL DEVELOEPR estão CORRETAMENTE CONFIGURADOS, aí sim é pedir DUMPs das colunas string que contém caracteres especiais pra ver como está gravado, e se estiver com caracteres codificados incorretamente de acordo com o WEBWIN1252 é fazer o UPDATE manualmente – trabalhinho de louco manso, mas se os dados originais não estão mais disponíveis (ie, vc não tem mais nem o banco original pra um novo exp e nem o arquivo-texto com os INSERTs) não há outra maneira…

[]s

Chiappa

[Fábio PradoParticipante]

André, sugiro também a leitura do artigo http://www.fabioprado.net/2012/11/configurando-national-language-support.html.

[]s

[Autor]

Posts