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 [email protected], "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 [email protected], 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] > > >
