Menu de navegação

[MottaParticipante]

Cenário meio “gasoso” mas vou tentar explicar.

Oracle versão 19c , migrado recentemente de um 11g , usamos um ERP de um fornecedor famoso.

Temos muitas user functions que funcionavam perfeitamente na versão antigo.

Na versão nova e ERP não lê as saídas char/varchar2 como o tipo char correspondente, nas saídas number não há problema.

Alguém tem algumas ideia do que pode ser ?

Grato

[José Laurindo ChiappaModerador]

“Gasoso”, “indefinido”, “genérico” e outras expressões similares é o mínimo pra isso… Bom, minha Sugestão é , PRIMEIRO, fazer a validação do lado do database, ie : pega algumas dessas FUNCTIONS, abre elas num editor (pode ser o do Oracle SQL Developer), Confirmar que elas estão VÁLIDAS, CONFIRMA que o datatype de Retorno é ** MESMO ** CHAR ou VARCHAR2, e (se puder) executa alguma delas no sqlplus , com um código tipo :

SET SERVEROUTPUT OZ MAXSIZE UNLIMITED;
DECLARE
v_retorno VARCHAR2(tamanhodele);
BEGIN
v_retorno :+ funçaõasertestada(argumentos);
dbms_output.put_line(v_retorno);
END;
/

e veja se roda ok – Se esse teste funfar ok, está Absolutamente Provado que do lado do banco tá tudo ok, aí isso passa a ser um problema que vc tem que ver com o SUPORTE da aplicação….
Claro, só o pessoal do Suporte da sua app é quem pode NEGAR ou COMPROVAR isso (e também ELES é que podem confirmar se o tal ERP está Homologado e roda em banco 19c, E podem indicar eventuais pré-requisitos, como mudar versão de client Oracle digamos) , mas pra tentar te ajudar, algumas diferenças de banco entre 11g e 19c que costumar causar incompatibilidades são :

1. CHARACTERSET : no 19c o default na instalação passou a ser AL32UTF, que é um characterset multibyte, onde um único caracter especial (ie, acentos e símbolos) PODE ocupar até 4 bytes/32 bits, AO CONTRÁRIo do banco 11g, onde o characterset default era de 8 bits – não é Incomum que aplicações antigas/mal-feitas não estejam Preparadas para alocar o espaço a mais que o characterset multibyte exige, aí dá erros os mais estranhos e diversos na manipulação de strings….
2. TAMANHO MÁXIMO DE UMA STRING : nas versões de banco Posteriores a 11g (iirc começou no 12c), a Oracle criou um parâmetro novo chamado MAX_STRING_SIZE, que permite que as strings na linguagem SQL (e em colunas de tabelas do database) passem de 4000 bytes para um máximo de 32767 bytes – não é Raro apps antigas serem Incompatíveis com esses novos limites
3. versão de Client Oracle antiga/incompatível com SGBD 19c: é absolutamente DOCUMENTADO na nota de Suporte Oracle “Client / Server Interoperability Support Matrix for Different Oracle Versions” (Doc ID 207303.1) que a versão MAIS ANTIGA de software client Oracle que consegue conectar num banco 19c é a 11gR2, e para isso ela TEM QUE ESTAR COM O PATCHSET que a deixa com release 11.2.0.4.x – não é difícil que a sua app (e/ou as máquinas por onde vcs acessam a app) esteja(m) usando versão antiga e incompatível de client Oracle, aí isso dá uma instabilidade geral, erros os mais malucos e estranhos…

   São essas 3 coisas que eu mais vejo de issues após uma migração de versão super-antiga tipo 11g ou 10g para versões mais modernas, veja lá se vc consegue com o Suporte da sua app validar esses pontos….

   Abraços,

   Chiappa

[MottaParticipante]

Chiappa,
Muito grato pela resposta , e mais uma vez desculpas pelo “gasoso” problema.

Foi e cenário (2) , quando migrou pedi ao DBA para já levar este parâmetro pois ajuda em implementações PL/SQl.

Conseguimos contornar o problema.

Não chegamos a ter nada em 32K mas nosso DBA disse :

Que esta opção é DEFAULT mas pelo “doc” que vi não é.
Não é possível voltar para 4000 bytes, sem “reimportar” a instância.

Não sei se isto procede, mas se alguém ler isto antes de alterar o MAX_STRING_SIZE

*** TESTE O SEU LEGADO ***

Abraço.

[José Laurindo ChiappaModerador]

Perfeitamente, ambas as coisas (ie, a Impossibilidade de voltar à situação original E a possível incompatibilidade) estão ** Claramente Documentadas ** no manual correspondente, online em https://docs.oracle.com/database/121/REFRN/GUID-D424D23B-0933-425F-BC69-9C0E6724693C.htm#REFRN10321 , eu cito :

“STANDARD means that the length limits for Oracle Database releases prior to Oracle Database 12c apply (for example, 4000 bytes for VARCHAR2 and NVARCHAR2, and 2000 bytes for RAW).

EXTENDED means that the 32767 byte limit introduced in Oracle Database 12c applies.

The COMPATIBLE initialization parameter must be set to 12.0.0.0 or higher to set MAX_STRING_SIZE = EXTENDED.

You can change the value of MAX_STRING_SIZE from STANDARD to EXTENDED. However, <bold> you cannot change the value of MAX_STRING_SIZE from EXTENDED to STANDARD </bold>.

By setting MAX_STRING_SIZE = EXTENDED, <bold> users are taking an explicit action that could introduce application incompatibility in their database </bold>. Applications that do not want to use the expanded data types can be rewritten for compatibility with either setting; for example, these applications could use explicit CASTs to fix the length of VARCHAR2 expressions during CREATE TABLE AS SELECT.
”

Abraços,

Chiappa

[MottaParticipante]

Mais uma vez grato , espero que este post ajude outrem.

[Autor]

Posts