Existem situações inusitadas no dia-a-dia do DBA, uma delas é administrar um banco de dados que atendem diversas aplicações pequenas e outra é quando o desenvolvedor de uma aplicação, que vamos dar o nome de Mendonça, elabora um novo programa que ficará nesse banco. O Mendonça tem um super notebook e nele tem todos os programas necessários para exercer sua função. No note, tudo funciona que é uma maravilha né Mendonça?
-Sim, aqui no note, tudo funfa, Fabalves.
Engraçado, algo me dizia que ele não falaria algo diferente.
Após meses de suor, lágrimas e muito café, o trabalho do Mendonça vai ganhar o mundo, ele vai pro ambiente de produção e aí começa o período de tempestades para quem? Tenho certeza que você imaginou que era para o Mendonça não é?
Mas não, esse período nebuloso é para o DBA, pois no período embrionário desses projetos, alguns detalhes passam despercebidos, um deles é o padrão de caracteres do banco, o assunto nem é sequer mencionado ou na maioria das vezes o dba nem sequer é chamado.
Mas agora temos um problema e o Mendonça lembrou que existe dba e lhe perguntou:
-Meu amigo dba, após a importação dos dados, tudo aparentemente correu bem, mas eu estou com um problema no retorno de um query, você pode me ajudar?
Bom, vamos lá, a característica do erro, indica que há diferenças de caracteres no banco onde foi desenvolvida a aplicação e no banco onde foi realizada a importação dos dados.
O primeiro passo é checar o NLS_DATABASE_PARAMETERS do banco de produção e comparar com o banco de dados que está no notebook do Mendonça. Eu utilizo a query abaixo:
SQL> select * from nls_database_parameters;
Algo similar a figura abaixo será exibida:
Verifiquei parâmetro por parâmetro e identifiquei que o NLS_CHARACTERSET das bases estavam diferentes. Isso pode causar esse tipo de problema? Pode, depende dos data types envolvidos.
Como estávamos em fase de identificar o causador do problema, cogitamos mudar o NLS_CHARACTERSET das bases e pesquisando no metalink da Oracle, encontrei o CSSCAN.
Esse utilitário realiza uma análise e lista os impactos da mudança dos NLS_CHARACTERSET. Funciona assim:
Você precisa executar o script csminst.sql, ele fica no ORACLE_HOME/rdbms/admin
Ex:
No prompt do sistema operacional, execute o comando CSSCAN, no exemplo abaixo, vamos analisar as tabelas do usuário SCOTT, simulando os impactos de mudar o NLS_CHARACTERSET WE8ISO8859P1 para o WE8ISO8859P15
Ex:
O CSSCAN gera logs no diretório corrente onde foi executado.
Ex:
O scan.txt lhe trás as informações sobre a análise, atentem para o item [Scan Summary]
Ex:
Database Scan Summary Report
Time Started : 2010-09-24 20:20:18
Time Completed: 2010-09-24 20:20:21
Process ID Time Started Time Completed
---------- -------------------- --------------------
1 2010-09-24 20:20:19 2010-09-24 20:20:20
---------- -------------------- --------------------
[Database Size]
Tablespace Used Free Total Expansion
------------------------- --------------- --------------- --------------- ---------------
SYSTEM 476,75M 3,25M 480,00M ,00K
UNDOTBS1 4,81M 20,19M 25,00M ,00K
SYSAUX 249,25M 768,00K 250,00M ,00K
TEMP ,00K ,00K ,00K ,00K
USERS 448,00K 4,56M 5,00M ,00K
FABALVES 5,06M 95,94M 101,00M ,00K
------------------------- --------------- --------------- --------------- ---------------
Total 736,31M 124,69M 861,00M ,00K
[Database Scan Parameters]
Parameter Value
------------------------------ ------------------------------------------------
CSSCAN Version v2.1
Instance Name fabalves
Database Version 10.2.0.4.0
Scan type User tables
User name scott
Scan CHAR data? YES
Database character set WE8ISO8859P1
FROMCHAR WE8ISO8859P1
TOCHAR WE8ISO8859P15
Scan NCHAR data? NO
Array fetch buffer size 1024000
Number of processes 1
Capture convertible data? NO
------------------------------ ------------------------------------------------
[Scan Summary]
All character type application data remain the same in the new character set
[Data Dictionary Conversion Summary]
Datatype Changeless Convertible Truncation Lossy
--------------------- ---------------- ---------------- ---------------- ----------------
VARCHAR2 0 0 0 0
CHAR 0 0 0 0
LONG 0 0 0 0
CLOB 0 0 0 0
VARRAY 0 0 0 0
--------------------- ---------------- ---------------- ---------------- ----------------
Total 0 0 0 0
Total in percentage 0,000% 0,000% 0,000% 0,000%
[Application Data Conversion Summary]
Datatype Changeless Convertible Truncation Lossy
--------------------- ---------------- ---------------- ---------------- ----------------
VARCHAR2 367.371 0 0 0
CHAR 0 0 0 0
LONG 0 0 0 0
CLOB 0 0 0 0
VARRAY 0 0 0 0
--------------------- ---------------- ---------------- ---------------- ----------------
Total 367.371 0 0 0
Total in percentage 100,000% 0,000% 0,000% 0,000%
[Distribution of Convertible, Truncated and Lossy Data by Table]
USER.TABLE Convertible Truncation Lossy
-------------------------------------------------- ---------------- ---------------- ----------------
-------------------------------------------------- ---------------- ---------------- ----------------
[Distribution of Convertible, Truncated and Lossy Data by Column]
USER.TABLE|COLUMN Convertible Truncation Lossy
-------------------------------------------------- ---------------- ---------------- ----------------
-------------------------------------------------- ---------------- ---------------- ----------------
[Indexes to be Rebuilt]
USER.INDEX on USER.TABLE(COLUMN)
Nesse teste, a alteração não causaria problemas nos dados do banco. Por curiosidade, realizei o mesmo teste, agora forçando o erro. Simulei a alteração do NLS_CHARACTERSET WE8ISO8859P1 para o AL16UTF16.
Ex:
Na log scan.txt:
Database Scan Summary Report
Time Started : 2010-09-24 20:30:02
Time Completed: 2010-09-24 20:30:15
Process ID Time Started Time Completed
---------- -------------------- --------------------
1 2010-09-24 20:30:02 2010-09-24 20:30:14
---------- -------------------- --------------------
[Database Size]
Tablespace Used Free Total Expansion
------------------------- --------------- --------------- --------------- ---------------
SYSTEM 493,75M 6,25M 500,00M ,00K
UNDOTBS1 5,06M 19,94M 25,00M ,00K
SYSAUX 249,25M 768,00K 250,00M ,00K
TEMP ,00K ,00K ,00K ,00K
USERS 448,00K 4,56M 5,00M ,00K
FABALVES 5,06M 95,94M 101,00M 2,50M
------------------------- --------------- --------------- --------------- ---------------
Total 753,56M 127,44M 881,00M 2,50M
[Database Scan Parameters]
Parameter Value
------------------------------ ------------------------------------------------
CSSCAN Version v2.1
Instance Name fabalves
Database Version 10.2.0.4.0
Scan type User tables
User name scott
Scan CHAR data? YES
Database character set WE8ISO8859P1
FROMCHAR WE8ISO8859P1
TOCHAR AL16UTF16
Scan NCHAR data? NO
Array fetch buffer size 1024000
Number of processes 1
Capture convertible data? NO
------------------------------ ------------------------------------------------
[Scan Summary]
Some character type application data are not convertible to the new character set
[Data Dictionary Conversion Summary]
Datatype Changeless Convertible Truncation Lossy
--------------------- ---------------- ---------------- ---------------- ----------------
VARCHAR2 0 0 0 0
CHAR 0 0 0 0
LONG 0 0 0 0
CLOB 0 0 0 0
VARRAY 0 0 0 0
--------------------- ---------------- ---------------- ---------------- ----------------
Total 0 0 0 0
Total in percentage 0,000% 0,000% 0,000% 0,000%
[Application Data Conversion Summary]
Datatype Changeless Convertible Truncation Lossy
--------------------- ---------------- ---------------- ---------------- ----------------
VARCHAR2 40.815 67.945 258.611 0
CHAR 0 0 0 0
LONG 0 0 0 0
CLOB 0 0 0 0
VARRAY 0 0 0 0
--------------------- ---------------- ---------------- ---------------- ----------------
Total 40.815 67.945 258.611 0
Total in percentage 11,110% 18,495% 70,395% 0,000%
[Distribution of Convertible, Truncated and Lossy Data by Table]
USER.TABLE Convertible Truncation Lossy
-------------------------------------------------- ---------------- ---------------- ----------------
SCOTT.DEPT 3 5 0
SCOTT.EMP 11 17 0
SCOTT.F1 67.931 258.589 0
-------------------------------------------------- ---------------- ---------------- ----------------
[Distribution of Convertible, Truncated and Lossy Data by Column]
USER.TABLE|COLUMN Convertible Truncation Lossy
-------------------------------------------------- ---------------- ---------------- ----------------
SCOTT.DEPT|DNAME 1 3 0
SCOTT.DEPT|LOC 2 2 0
SCOTT.EMP|ENAME 11 3 0
SCOTT.EMP|JOB 0 14 0
SCOTT.F1|GENERATED 0 40.815 0
SCOTT.F1|OBJECT_NAME 3.506 37.309 0
SCOTT.F1|OBJECT_TYPE 23.610 17.205 0
SCOTT.F1|OWNER 40.815 0 0
SCOTT.F1|SECONDARY 0 40.815 0
SCOTT.F1|STATUS 0 40.815 0
SCOTT.F1|TEMPORARY 0 40.815 0
SCOTT.F1|TIMESTAMP 0 40.815 0
-------------------------------------------------- ---------------- ---------------- ----------------
[Indexes to be Rebuilt]
USER.INDEX on USER.TABLE(COLUMN)
No Scan Summary, o aplicativo informa que haverá problemas se convertermos o banco para esse novo NLS_CHARACTERSET.
Já ia me esquecendo do Mendonça, bom o problema dele resolvemos com o alter session, assim apenas quando a procedure dele era chamada, havia a alteração em tempo de execução.
Bom, fica a dica sobre esse utilitário, um dia pode ser útil.
Um abraço
Nenhum comentário:
Postar um comentário