- Este tópico contém 11 respostas, 2 vozes e foi atualizado pela última vez 9 anos, 8 meses atrás por
rman.
-
AutorPosts
-
18 de dezembro de 2014 às 2:45 pm #107235
acg1574
ParticipantePessoal é o seguinte
a empresa que trabalho contratou uma empresa de oracle para mudar nosso servidor de banco de dados, o banco de dados antigo estava com um charset, agora o novo ele criou com outro por causa do sistema da totvs exigir esse outro, mas os caracteres do banco de dados, vieram tudo bagunçado, cheio de caracteres especiais , interrogação de cabeça pra baixo, simbolos, etc…
e eles nao estao sabendo o que fazer agora, ja que o banco novo ja esta em producao a uns 15 dias, e agora que começou acontecer alguns problemas de algumas rotinas que começaram a ser rodadas, alguem pode me ajudar, me falar o que tem que ser feito, obrigado.18 de dezembro de 2014 às 3:04 pm #107236rman
Participante@acg1574
Como foi feita a migração dos dados? Quais são os charset em questão, origem e destino?
Creio que se configurar a variável NLS_LANG de forma adequada os dados serão apresentados de forma correta.
18 de dezembro de 2014 às 4:24 pm #107237acg1574
Participanteentao rman, hoje esta com esse charset NLS_CHARACTERSET WE8MSWIN1252,mas, fico com medo de mudar e dar algum problema sabe, tipo, parar o banco, a empresa tem mais de 100 usuarios conectados o tempo todo. entao prefiro me arriscar qdo tiver certeza.
isso tudo por causa do totvs.todos os parametros
NLS_LANGUAGE BRAZILIAN PORTUGUESE
NLS_TERRITORY BRAZIL
NLS_CURRENCY R$
NLS_ISO_CURRENCY BRAZIL
NLS_NUMERIC_CHARACTERS ,.
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD/MM/RRRR
NLS_DATE_LANGUAGE BRAZILIAN PORTUGUESE
NLS_CHARACTERSET WE8MSWIN1252
NLS_SORT WEST_EUROPEAN
NLS_TIME_FORMAT HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT DD/MM/RRRR
NLS_TIME_TZ_FORMAT HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT DD/MM/RRRR
NLS_DUAL_CURRENCY Cr$
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE18 de dezembro de 2014 às 4:34 pm #107238rman
Participante@acg1574
Quando me referi a variável NLS_LANG estava me referindo a variável de ambiente do WINDOWS, não a parâmetro de inicilização do Oracle Database.
Essa variável diz ao Oracle Client define o charset no lado cliente. Não importa qual é o charset que está no lado servidor, caso defina corretamente no lado cliente é feita a conversão automática caso necessário.
18 de dezembro de 2014 às 4:48 pm #107239acg1574
Participantebem, dei uma olhada pra fazer um teste na minha maquina, mas nao achei essa variavel de ambiente nao, mas a questao é por exemplo, erros na execucao de algum select da totvs, e isso roda no servidor né, e acontece os erros, nosso banco fica no linux.
18 de dezembro de 2014 às 4:53 pm #107240acg1574
Participantecomo faço para definir essa variavel no lado cliente ? vou fazer um teste aqui na minha maquina
18 de dezembro de 2014 às 5:04 pm #107241rman
Participante@acg1574
Depende do Client Oracle que você está usando, se for o instant client basta uma variável de ambiente do Windows, se for o client full é um registro do regedit.
Segue um artigo que aborda sobre o assunto:
http://www.oracle.com/technetwork/products/globalization/nls-lang-099431.html
Sobre erros no SELECT creio que isso seja outro problema que não está relacionado ao charset. Isso quem pode verificar é o suporte da TOTVS.
18 de dezembro de 2014 às 5:15 pm #107242acg1574
Participanterman, seguinte amigo, acho q nao consegui te passar o problema, o nosso servidor antigo de banco tava com um charset, qdo colocaram o novo servidor, configuraram para outro, e importou os dados, mas os dados dentro das tabelas estao com varios caracteres especiais, entao esta dando erro em um monte de relatorios, processamentos, pq nao esta conseguindo identificar esses dados, ate ai tudo bem , certo ? agora nao podemos voltar mais para o charset antigo, pq ja foram gravados dados com o charset novo, entao estamos nessa luta para ver o que fazer, por exemplo qdo eu faço um select na minha maquina pelo sqldeveloper ele me traz os dados todos cheio de caracteres especiais, e isso nao deveria esta la, te mostrar uma tela, vou anexar ela aqui.
18 de dezembro de 2014 às 7:26 pm #107243rman
Participante@acg1574
Qual era o antigo e o novo charset?
Como foi feita a migração? Datapump? Dependendo de como foi feito, os dados podem estar armazenados de forma correta mas você está visualizando desta forma devido o NLS_LANG não esta configurado de forma adequada. Ou na pior das hipóteses os dados já vieram sem conversão de charset. Se tiver o log do impdp da pra saber se houve a conversão do charset na importação.
18 de dezembro de 2014 às 8:03 pm #107244acg1574
Participanteagora vc chegou onde eu queria, os dados ja vieram sem a conversao do charset .
18 de dezembro de 2014 às 8:44 pm #107245acg1574
Participanteinicio do log do imp que os kras fizeram , foi o que achei aqui
[coopatos.srvora export]$ more imp0612.log
;;;
Import: Release 11.2.0.4.0 – Production on Sat Dec 6 02:57:43 2014Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
;;;
Connected to: Oracle Database 11g Release 11.2.0.4.0 – 64bit Production
Master table “SYS”.”SYS_IMPORT_SCHEMA_04″ successfully loaded/unloaded
Starting “SYS”.”SYS_IMPORT_SCHEMA_04″: “/******** AS SYSDBA” parfile=imp.par
Processing object type DATABASE_EXPORT/SCHEMA/USER
ORA-39083: Object type USER failed to create with error:
ORA-02380: profile PROFILEPASS does not exist
Failing sql is:
CREATE USER “VETORH” IDENTIFIED BY VALUES ‘S:2811B260047AD2A3ABE3B7AE9BD851F417234C2877AC61A395FF11E4CA01;95F23DD5BB6C3C0
7’ DEFAULT TABLESPACE “TSP_DADOS” TEMPORARY TABLESPACE “TEMP” PROFILE “PROFILEPASS”
ORA-31684: Object type USER:”TOTVS” already exists
ORA-31684: Object type USER:”SOFTSITE” already exists
Processing object type DATABASE_EXPORT/SCHEMA/GRANT/SYSTEM_GRANT
Processing object type DATABASE_EXPORT/SCHEMA/ROLE_GRANT
Processing object type DATABASE_EXPORT/SCHEMA/DEFAULT_ROLE
Processing object type DATABASE_EXPORT/SCHEMA/TABLESPACE_QUOTA
Processing object type DATABASE_EXPORT/SCHEMA/SEQUENCE/SEQUENCE
Processing object type DATABASE_EXPORT/SCHEMA/PROCACT_SCHEMA
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA
. . imported “TOTVS”.”CTK010″ 16.29 GB 18282235 rows
. . imported “TOTVS”.”CV3010″ 10.84 GB 18280054 rows
. . imported “TOTVS”.”SPED052″ 341.3 MB 428653 rows
. . imported “TOTVS”.”SPED050″ 5.253 GB 351023 rows
. . imported “TOTVS”.”CT2010″ 5.225 GB 5176589 rows18 de dezembro de 2014 às 10:16 pm #107246rman
Participante@acg1574
Como você concluiu que os dados já vieram com o charset sem conversão? O log do imp não diz nada, geralmente quando é necessário fazer a conversão o imp da um warning.
Eu arriscaria dizer que os dados estão ok, só falta configurar o NLS_LANG para você visualizar os dados de maneira correta.
-
AutorPosts
- Você deve fazer login para responder a este tópico.