Boa tarde a todos!
Gostaria de ter um exemplo de uma query que faça UPDATE no oracle e que tenha JOIN. Agradeço antecipadamente Silvio. De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de J. Laurindo Chiappa Enviada em: quarta-feira, 24 de abril de 2013 20:14 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Re: Existe algum insert que segura a inserção de dados na tabela inserida E só complementando : execuções paralelas visam principalmente a diminuir o tempo de processamento, e CLARO que sempre existe a possibilidade de, ao invés de vc ter n sessões simultâneas cada uma lendo um arquivo, via EXTERNAL TABLE com parallel SQL vc poderia ter n slave sessions lendo/processando/inserindo dados do MESMO arquivo, que logicamente ia terminar de ser processado mais rápido e aí mais rapidamente ia ler o próximo... Processando-se um arquivo por vez Elimina-se a necessidade de controle que é necessária se vc for processar múltiplos arquivos.... []s Chiappa --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> , "J. Laurindo Chiappa" <jlchiappa@...> escreveu > > Colega, veja bem : é um FATO que que, se vc abre várias SESSÕES num RDBMS, naturalmente os dados inseridos por uma SESSÂO x mas ainda não comitados ** não ** podem/não vão poder ser 'enxergados' por uma outra sessão y, EM ESPECIAL no RDBMS Oracle aonde nunca, jamais, em tempo algum, existe leitura "suja", de dados não comitados em outra sessão.... SE a pessoa não conhece conceitos tão fundamentais e está desenvolvendo um aplicativo com RDBMS, my god..... > Bom, sobre o seu cenário de ter diversos arquivos de dados a carregar em paralelo (em SESSÔES diferentes no database) temos que : > > a. se existe INTEGRIDADE DE DADOS (por exemplo, constraints de PK/FK) entre dados de diferentes arquivos, OU vc assegura que os arquivos com as PKs serão processados/inseridos primeiro, OU vc temporariamente (durante a carga) desliga as constraints e as religa no final da carga (verificando os dados antes, é claro) OU se viável usa delayed constraints > > b) se o problema é que a sessão x está carregando o arquivo 1 e nesse momento entra uma sessão y que tenta carregar o mesmo arquivo, CLARO que para o database isso são sessões DIFERENTES : para vc controlar isso, vc TEM que colocar na procedure uma "inteligência" que registre que o arquivo está sendo processado, e portanto a sessão y TEM que "pular" ele - a maneira COMUM no RDBMS Oracle é ter uma tabela de controle que vc locka (LOCK é o meio de se assegurar acesso serializado, uma sessão por vez, a um dado recurso)... > Poderia existir uma tabela LISTA_DE_ARQUIVOS, com uma coluna só NOME_DO_ARQUIVO, e essa tabela ser carregada num pré-processamento com a lista toda dos arqs a carregar, aí a procedure teria uma lógica tipo : > > BEGIN > for r in (select nome_do_arquivo from LISTA_DE_ARQUIVOS FOR UPDATE SKIP LOCKED) loop > ... > lê o arquivo registrado na coluna NOME_DO_ARQUIVO e faz os INSERTs necessários > ... > delete from LISTA_DE_ARQUIVOS where current of; > end loop; > commit; > END; > > > okdoc ?? Aí se uma sessão y ser disparada enquanto uma sessão x está lendo um dado arquivo 1, a linha correspondente à ele está LOCKADA e portanto vai ser pulada e a sessão vai processar o arquivo 2.... > > ==> é CLARO, eu estou supondo que o que vc quer é evitar que as próximas sessões processem o mesmo arquivo : não há necessidade, imagino, de usar a restrição mais rígida que vc cita (ie, PROIBIR as próximas sessões de executarem enquanto a sessão x inicial tá rodando), MAS é plenamente possível se fazer isso, aí vc usaria um LOCK TABLE numa tabela de flag... > > []s > > Chiappa > > OBS : é claro, vc tem que ter CERTEZA que não há os mesmos dados, com a mesma chave, em arquivos diferentes : é ULULANTEMENTE óbvio e conhecido que se duas sessões fizerem simultaneamente INSERTs do mesmo dado com a mesma chave, em condições normais de uso (ie, constraints não-delayed, etc) uma delas (a segunda, normalmente) VAI ficar em WAIT, sim ??? E esse WAIT só será satisfeito quando a sessão original comitar, só então a constraint vai ser ativada e o registro é rejeitado com duplicated key.... > > --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> , Carlos Silva <carlos-csilva@> escreveu > > > > Ola pessoa! > > Estou usando o oracle 10g ... Tenho uma procedure que recebi via webservice arquivos, segundo informação de um rapaz que trabalha comigo, ele abre varias seções no oracle, e quando entra a primeira informação já entra a segunda, e essa segunda não consegue achar as informações da primeira que nao foi processada ainda. Existe alguma forma de controlar a linha de chegada dessas informações. Tipo, enquanto nao foi dado commit no primeiro insert nao entrar nenhum registro na procedure ou insert. > > At.: > > > > [As partes desta mensagem que não continham texto foram removidas] > > >
