Forum Stats

  • 3,734,524 Users
  • 2,246,998 Discussions
  • 7,857,368 Comments

Discussions

problema na leitura de View de Sql no Oracele

Prezados,

Tenho a seguinte situação: possuo uma view num dblink de SQL-Server para o Oracle, porem existe um campo que na origem é nvarchar(max) que quando chega no Oracle não consigo enxergar todo seu conteudo, somente 4000. o conteudo é muito mais que isso. o que preciso fazer para ver todo o conteudo no Oracle?

Best Answer

  • J.Laurindo Chiappa
    J.Laurindo Chiappa Member Posts: 28
    edited Nov 26, 2018 11:00AM Accepted Answer

    Blz ? Bom, provavelmente vc deve estar vendo o efeito de que no RDBMS Oracle (por default em todas as versões, e OBRIGATORIAMENTE nas versões antes de 12c) as strings fixas na linguagem SQL e no database  tem no máximo 4000 bytes, seja CHAR, VARCHAR2, NCHAR ou NVARCHAR2...

      Então, explica melhor : QUAL é o datatype dessa coluna na view ?? Qual a sua versão de banco Oracle ?? Dependendo das suas respostas, as suas opções são :

    a) se o conteúdo dessa coluna lá no banco remoto for garantidamente sempre <= 32767 bytes E sua versão for >= 12c, considere usar o datatype VARCHAR2 na sua SELECT que alimenta a view (provavelmente vc vai ter que usar um CAST, para assegurar que o banco remoto envie o datatype correto) E ativar o parâmetro  MAX_STRING_SIZE = EXTENDED no seu banco, fazendo com que strings fixas do datatype VARCHAR2/NVARCHAR2 possam ter até 32767 caracters, vide  https://docs.oracle.com/database/121/SQLRF/sql_elements001.htm#SQLRF55623

    OU

    b) se a versão por inferior a 12c e/ou essa coluna puder ter mais do que 32767 bytes de conteúdo, vc VAI ter que passar a usar um datatype CLOB nessa view : o 'problema' aqui é que CLOBs são modelados mais ou menos cfrme arquivos, precisando de file handle locais , E vc diz que está usando dblink....

    Muito provavelmente se vc PRECISAR continuando a usar views, muito provavelmente vc vai ter que usar alguma adaptação, tipo o mostrado em https://asktom.oracle.com/pls/apex/asktom.search?tag=clob-column-over-db-link ...

    Abraços,

       Chiappa

Answers

  • J.Laurindo Chiappa
    J.Laurindo Chiappa Member Posts: 28
    edited Nov 26, 2018 11:00AM Accepted Answer

    Blz ? Bom, provavelmente vc deve estar vendo o efeito de que no RDBMS Oracle (por default em todas as versões, e OBRIGATORIAMENTE nas versões antes de 12c) as strings fixas na linguagem SQL e no database  tem no máximo 4000 bytes, seja CHAR, VARCHAR2, NCHAR ou NVARCHAR2...

      Então, explica melhor : QUAL é o datatype dessa coluna na view ?? Qual a sua versão de banco Oracle ?? Dependendo das suas respostas, as suas opções são :

    a) se o conteúdo dessa coluna lá no banco remoto for garantidamente sempre <= 32767 bytes E sua versão for >= 12c, considere usar o datatype VARCHAR2 na sua SELECT que alimenta a view (provavelmente vc vai ter que usar um CAST, para assegurar que o banco remoto envie o datatype correto) E ativar o parâmetro  MAX_STRING_SIZE = EXTENDED no seu banco, fazendo com que strings fixas do datatype VARCHAR2/NVARCHAR2 possam ter até 32767 caracters, vide  https://docs.oracle.com/database/121/SQLRF/sql_elements001.htm#SQLRF55623

    OU

    b) se a versão por inferior a 12c e/ou essa coluna puder ter mais do que 32767 bytes de conteúdo, vc VAI ter que passar a usar um datatype CLOB nessa view : o 'problema' aqui é que CLOBs são modelados mais ou menos cfrme arquivos, precisando de file handle locais , E vc diz que está usando dblink....

    Muito provavelmente se vc PRECISAR continuando a usar views, muito provavelmente vc vai ter que usar alguma adaptação, tipo o mostrado em https://asktom.oracle.com/pls/apex/asktom.search?tag=clob-column-over-db-link ...

    Abraços,

       Chiappa

  • 78510ca1-2c03-4f4b-96a9-627dd19b77fd
    edited Nov 26, 2018 12:40PM

    Obrigado pela presteza.

    minha view do SQL o campo é NvarChar(max) e seu conteudo maximo é de 5.141.505. estamos usando o Oracle 12i

    Grato. mais uma vez.

  • J.Laurindo Chiappa
    J.Laurindo Chiappa Member Posts: 28
    edited Jan 2, 2019 4:52PM

    Tudo bem ? Conseguiu resolver esta dúvida ??

    Se não conseguiu :  como eu havia dito pra mim esse limite de mostrar só os 4000 bytes duma coluna string que na origem é muito maior é ** SUSPEITOSAMENTE SIMILAR ** ao limite de 4000 bytes duma coluna VARCHAR ou VARCHAR2 numa tabela Oracle, acho Muito Possível que o SELECT from dblinkqueconectanoSqlServer esteja na verdade convertendo essa coluna NVARCHAR(MAX) no SqlServer para VARCHAR/VARCHAR2 no Oracle, aí como ambos datatypes são limitada a 4000 bytes no Oracle, por isso vc só vê os 4000 primeiros bytes de dados.... A partir do momento em que vc começa a trabalhar com múltiplos RDBMSs diferenças de limites, datatypes, sintaxes e defaults acontecem MESMO....

    SE for isso, experimente ter no SqlServer uma view tipo :

    view vs is

    select  convert(varchar(4000), substring(nomedacoluna,     1, 4000)) as col_1,

            convert(varchar(4000), substring(nomedacoluna,  4001, 4000)) as col_2,

            convert(varchar(4000), substring(nomedacoluna,  8001, 4000)) as col_3,

            convert(varchar(4000), substring(nomedacoluna, 12001, 4000)) as col_4,

    etc

    from tabela.....

    => aí no Oracle vc declara a coluna da tabela onde vai gravar esse dado NVARCHAR(MAX) como CLOB, e na hora de inserir vc faz :

    INSERT into colunaclob(TO_CLOB(col_1 || col_2 || col_3 || col_4... etc ....

    é mais ou menos o que foi feito no artigo https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:9536421900346563332 .....

    Ou ainda, vc pode ler diretamente os dados do SQLSERVER via PL/SQL (PL/SQL é capaz de chamar as APIs de CLOB diretamente, vide https://jiri.wordpress.com/2010/06/04/query-clob-across-db-link-with-in-simple-view/), ou ainda vc pode inverter a ordem, ie, ao invés do Oracle conectar no SQLSERVER para ler os dados, o SQLSERVER (via linked server) conecta no Oracle e grava o necessário....

    Blz ? tenta essas diversas opções, depois nos conta qual foi a adotada....

Sign In or Register to comment.