Vc falou MUITA coisa mas NÂo esclareceu as dúvidas : SERÁ que vc pode ter white space ou não ( ie, a tabela sofre deleçoes maçicas) ???? SERÁ que o high-water mark está ultra-alto, com muito espaço não usado, ou não ?? SERÁ que a tablespace é DMT (o que possibilita extents de tamanhos esdrúxulos) ou não ??? O PCTFREE/PCTUSED tá coerente com o uso ?? SERÁ que o fato de vc ter mais de 255 colunas está sendo significativo, os WAITs por continued row que isso causa são importantes ou não ??? O fato de ter índice *** NÂO *** impede que esteja sendo feita um FTS( Full-Table Scan) ou um FFIS (Fast Full Index Scan), ambos FAZEM I/O multibloco do tamanho do extent, extents com tamanhos impróprios podem influenciar... Aliás, falando em planos, levantei a possibilidade de que estejam sendo gerados PLANOS diferentes pra execução na tabela "boa" e pra execução na outra tabela, é o caso ???? Só vc pode nos dizer isso, e SÓ sabendo disso é que a gente pode palpitar em cima, E como eu disse a maneira mais simples de provar ou desprovar as hipóteses dependentes de armazenamento incorreto é criar uma tabela-teste correta e ver se dá diferença, o que é outroponto que apenas VOCÊ pode fazer...... Sendo PL/SQL a sua rotina , vc tem também a chance de fazer um PL PROFILER nela, de fazer anbálise baseada nos waits events/session events, é outra alternativa a ser explorada...
Sobre o que vc disse, eu teria ainda dois comentários : a) POR QUE, se o volume de dados é significativo e o teu objetivo é transferir o mais rapidamente possível (imagino) , vc abre um cursor PL/SQl (com bulk, tá, mas abre cursor) AO INVÈS de fazer um INSERT diretamente ????? pesquisa nas msgs anteriores do grupo, no asktom e nos melhores sites sobre Oracle, que vc vai encontrar N+1! casos aonde o SQL direto deixar os Cursores comendo poeira em termos de performance ?/ Com INSERT direto até talvez seria possível DIMINUIR ENORMEMENTE a geração de redo com a cláusula /*+ APPEND */ , há alguma Restrição a isso ?? Se vc não usa standby/dataguard ou features que transportam o redo entre as bases (o fato de serem Edições totalmente diferentes pode indicar que realmente não usa) , pode ser um ponto... b) há limites nos protocolos de rede quanto à qtdade de dados possíveis num pacote, no próprio PL/SQl há limites internos, então via de regra o limite considerado apropriado para um bulk collect é por volta de poucas centenas (vide http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:177628700346350496#205210700346878806 e busque no no mesmo site site para mais refs), SERÁ que esse teu limite de 2000 não tá atrapalhando ??? []s Chiappa --- Em [email protected], welvis@... escreveu > > Olá., > > Bom vamos esclarecer as dúvidas... > > Aqui em nosso RAC rodava o ERP da empresa, e o software contabil/fiscal > MasterSaf, sendo assim o ERP passava as informações para o MasterSaf via > insert/grants. Com o passar dos dias o MasterSaf ficou um tanto quando > pesado, não podendo continuar mais no mesmo RAC com o ERP. Sendo assim o > MasterSaf foi para a IBM e o ERP tem que continuar mandando informação > para ele (MasterSaf). > > Então, mantive os metadados do MasterSaf no RAC, e continuei colocando as > informações do ERP nele, sendo assim fiz uns Jobs que copiavam as tabelas > via dblink (apenas as de integração) para o MasterSaf na IBM, controlando > por flag o que já havia sido transmitido. > > Eu faço um cursor, filtrando tudo ainda que precisa ser enviado, o campo > tem índice, e também limito o cursos em 50.000 linhas ou mais dependendo > do caso.. > > Sendo assim faço um BULK COLLECT de 2000 e faço o insert , insert into > tabelas@msaf_dest as lista de campos(array). > > > > Att, > > > De: [email protected] [mailto:[email protected]] Em > nome de José Laurindo > Enviada em: sexta-feira, 20 de maio de 2011 13:01 > Para: [email protected] > Assunto: [oracle_br] Re: Baixa Performance dbLink > > > Sim, esse volume para o evento de wait sql*net é suspeito... Será que > simplesmente não há uma ineficiência na estrutura de armazenamento da > tabela "ruim" , que não existe na tabela "boa" ? Por exemplo, white space, > extents de tamanho ridiculamente pequeno e/ou não múltiplos do máximo de > I/O possível (supondo que esteja sendo feito operações de scan tipo um FTS > ou um FFIS).... Uma ineficiência que pode ser batata pelo que o colega > descreve é table fetch continued row - em vc tendo mais que 255 columnas é > um Fato da Vida que vai ser exigido mais que um acesso pra se ler o > registro, ver > http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1560606453047#149200500346579115 > .... > Pra se testar essas possibilidades físicas, eu recomendaria que fosse > criada uma tabela com volume idêntico MAS com menos de 255 colunas, numa > tablespace LMT ( com extents uniform-sized múltiplos do máximo de I/O > possível no ambiente se for feito acesso via scan), com PCTFREE/PCTUSED > corretos pra se ter dados compactos no bloco, E que só tenha sofrido > INSERTs pra popular os dados (impossibilitando assim white space) : SE a > performance for nitidamente Superior, tá comprovada a hipótese... > > Outra possibilidade´que o colega lá não diz se é possível é simplesmente > que o INSERT INTO tabela (SELECT * FROM datasource@dblink) ** NÂO ** seja > com UMA tabela só, que a query interna seja complexa, com várias tabelas, > aí pode ser apenas um caso de plano de execução errado/inapropriado, não > uso de índice, etc & tal .... > > []s > > Chiappa > > > --- Em [email protected], Ricardo Almeida <ricardo.almeida@> > escreveu > > > > Olá, Welvis. Tudo jóia? > > > > O P2 dos eventos SQL *NET more data from client e message from client > > corresponde ao total de bytes. > > > > Fazendo umas continhas, os valores do seu exemplo correspondem a 1,3GB e > > 1,0GB. Não sei se quando você tirou estas "fotos" seu processo estava no > > início, no meio ou no fim, mas replicar esse volume através de INSERTs via > > uma WAN pode não ser a melhor alternativa. > > > > Aproveitando, só a quantidade de colunas não é um bom indicador para o > > tamanho médio da linha, já que o tamanho delas, tipos de dados e quantidade > > de NULLs podem fazer esse tamanho variar muito. > > > > Abraços, > > > > -- > > > > Ricardo D. Almeida > > Engenheiro de Desempenho de Bancos de Dados > > ricardo.almeida@ > > > > YAMAN - Gerenciamento de Desempenho de Aplicações > > > > > > > > > > > > Em 20 de maio de 2011 09:35, <welvis@> escreveu: > > > > > > > > > > > Bom dia pessoal, estou com um problema. > > > > > > Eu tenho 2 bancos de dados Oracle em sites diferentes, um na IBM (sabe-se > > > lá Deus onde está a máquina) e ou outro local. Eu tenho um dblink para > > > fazer a comunicação entre os dois, estou usando o dblink pois uma é a > > > versão standart e outro a EE, e não tenho as feature de replicação. > > > > > > Neste caso eu tenho diversos insert via dblink, mas apenas um destes é > > > lento, a tabela tem 265 campos. Bom para fazer o insert na tabela 07 no > > > site onde tenho um Oracle 10G r2 RAC, e o Wait da sessão mostra o evento > > > > > > SID STATE EVENT > > > SECONDS_IN_WAIT P1 P2 P3 > > > ---------- ------------------- ------------------------------ > > > --------------- ---------- ---------- > > > 232 WAITING SQL*Net message from dblink > > > 3 0 1 0 > > > > > > Na máquina de destino site da IBM temos um Oracle 11g r2 (RuWindows) e > > > temos as seguintes informações de Wait, para as informações que estão > > > vindo do site principal. > > > > > > SID STATE EVENT > > > SECONDS_IN_WAIT P1 P2 P3 > > > ---------- ------------------- ------------------------------ > > > --------------- ---------- ---------- > > > 7 WAITING SQL*Net more data from client > > > 0 1413697536 4 0 > > > 7 WAITING SQL*Net message from client > > > 577118 1111838976 1 0 > > > > > > O estranho é que eu tenho a mesma coisa mas para a tabela 08, que tem > > > muito mais linhas, só que ela transfere muito mais rápido. A única > > > diferença é que a tabelas 07 tem 265 campos e a 08 tem apenas 211. E > ainda > > > para ajudar, o pessoal do hardhare diz que o link MLPS está hiper > > > tranqüilo, pesquisei ontem sobre dblink mas não achei muita informação. > > > > > > alguem tem alguma sugestão? > > > > > > Att, > > > > > > Welvis Douglas da Silva Moretto > > > OCP DBA 10g - OCE Sql > > > Fone: (41) 9997-6297 > > > E-mail: welvis_douglas@, welvis.meta@ > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > >
