Stored Procedures em Oracle - Oracle - Portugal-a-Programar
Stored Procedures em Oracle
Por Anjo, 4 de Dezembro de 2006 em Oracle
Tenho uma pergunta meio lixada...
Uma certa noite, um campónio de um banco ligou-me para o telemovel, a dizer que 1 processamento estava a demorar horas e horas. Eu quando cheguei ao banco de madrugada, liguei para o DBA para me matar o processamento que estava feito em Stored Procedure. O que o gajo fez foi deitar abaixo o oracle aplication server, e mete-lo acima.
Quando se mata uma conexão a uma base de dados, e se tiver um stored procedure a correr, ele mata essa execução?
O DBA diz que sim. E eu respeito muito a opinião dele, porque ele tem anos disto. Mas o que é certo, é que eu vejo dados na base de dados, que só é suposto estarem lá, no final da execução dessa SP. E quando foi dada ordem para matar conexoes fazendo restart ao OAS, o processamento ainda estava a meio.
A minha opinião sempre foi que quando se manda correr algo numa base de dados, o servidor aplicacional so fica a espera. E se matamos a conexão, simplesmente não temos o output da execução, e a SP/querie fica a correr por trás.
Enfim... duvidas filosoficas...
As coisas são mais simples do que isso. A ligação à base de dados é que não tem nada a ver aqui para o caso.
Se fizeres updates ou inserts numa base de dados eles ficam para todos os efeitos feitos.Ponto final. Em fazendo uma alteração ela está feita. Nao importa se a ligação da pessoa que a fez caíu ou nao.
Isto, A NÃO SER QUE... uses transações. Quando se usam transacções são criados checkpoints, seguidamente fazem-se alterações, estas ficam visiveis para quem as fez. As coneções exteriores podem ve-las, ou se fizerem uma operações dependente desse valor ficam em espera. Se houver problemas, a transacção falha e a base de dados volta a situação do checkpoint anterior.
As alterações tomam efeito de forma definitiva quando for dado o commando COMMIT.
Em linhas gerais é isto.
Eu tive agora com o DBA, e ele diz plenamente que quando 1 conexão é fechada, o processo associado vai à vida na BD. Daí eu ter mencionado a conexão à base de dados.
Eu vou ver o codigo daquele processamento. Mas acredito mais da teoria dele do que da minha.
A única coisa que dá vida à minha teoria, é essa histórica dos checkpoints... mas não sei. Ainda estou a estudar a situação.
Isto é mais curiosidadade do que propriamente utilidade.
Alias.. ele diz-me que quando 1 conexão vai á vida, é feito rollback... logo... essa historica dos checkpoints... não sei.. tenho que estudar o caso.
Penso que o caso roolback não se aplica da mesma forma em Oracle.
Se não estou em erro, por defeito todas as operações em Oracle são transacções, e o processo só resulta no fim do commit.
Se a ligação vai á vida o commit não é executado, logo o DBA pode muito bem ter razão. Mas é uma coisa que não tenho certeza já que não trabalho em Oracle.
Pergunta ao DBA em relação a este pormenor.
Já perguntem. A opinião dele é que é feito rollback. Eu acho é estranho ter a base de dados, como se o processo fosse concluido com êxito. Enfim.. Ainda não tive tempo para ver o código...
A minha dúvida era mm essa... de se nos matarmos 1 sessao/conexão à base de dados, o que acontece a 1 SP que foi parada a meio.
Matar o processo pode não querer dizer que parte do seu processamento não seja efectuado.
É possível que matar a ligação mate o processo, mas pode não ser bem assim, se, por exemplo, exactamente no caso da execução de um SP, como ele corre no servidor, matar o cliente pode não ser suficiente para matar a sua execução. E mesmo que se mate a sua execução há várias coisas a ter em mente, como por exemplo o SP tem check points para commit ou o transaction log que serve exactamente para recuperar em casos de falha, quer seja para fazer commits ou rollbacks.
Epa... está aqui uma pequena confusão. Em termos de processos não posso dizer o que acontece pois não sei. Mas tambem não penso que seja o importante.
Só para que não fiquem dúvidas: processos cancelados ou nao só se volta atrás caso estejamos no meio de uma transação. Claro que no oracle não são tudo transacções, porque se fosse não o eram... lol
Não estamos a complicar isto de mais? ser um procedimento ou não não interessa absolutamente nada para o caso.
Entretanto já descobri o porquê dos meus registos a mais na base de dados. É da forma como está feito o processamento, e a altura onde foram mortas todas as conexões á base de dados.
Relativamente à duvida que existia, do que acontece, quando matamos as conexões, a meio de uma execução de 1 SP, a resposta é simples. É feito o rollback.
Sobre os checkpoint, eu tentei perder uns minutos a investigar, e penso que talvez "checkpoints" não seja a palavra correcta. Mas se for aquilo que eu tou a pensar, isso não se aplica à morte da conexão do cliente, mas sim se a máquina de base de dados, for desligada por acidente (Falta a luz e a UPS vai à vida whatever!). Em que ele quando se levanta, retoma os processos que estavam a correr, no sitio onde ficou. Mas repito, penso que o termo para esta operação não seja "checkpoints" seja outra coisa qualquer.
Resumindo... Temos 1 SP a correr, matamos a conexão a meio da execução da SP, e o resultado é 1 rollback. Simple as that!
... Claro que no oracle não são tudo transacções, porque se fosse não o eram... lol
Tas a dizer isso porque sabes, ou tas a mandar á sorte?
É que nesse aspecto difere de MS SQL...
Ora pensa bem, se tudo é uma transacção então nada é uma transacção. É uma questão de lógica.
Não sei se toda a gente aqui sabe o que é uma transacção. Uma forma fácil de entender:
uma transacção é um bloco de operações que ou são todas executadas ou são canceladas e a situação inicial é mantida.
Um procedimento pode ser usado numa transacção e pode usar transacções. Esta dúvida que aqui colocaram inicialmente não faz sentido quando se refere a procedimentos. Commit e rollback são conceitos simples de transacções.
Se te estás a referir ao autocommint a resposta é: sim, sei que o oracle pelo menos por defeito não tem nada desse género activo.
pedrotuga.
Obrigaste-me a fazer pesquisas. Também é assim que aprendemos!
http://infolab.stanford.edu/~ullman/fcdb/oracle/or-nonstandard.html#transactions
Pelos vistos Oracle tem um AUTOCOMMIT OFF por defeito, o que torna todos os processos executados numa ligação parte de uma transacção. Até a ligação ser fechada correctamente (não é abortar a ligação), ou ser efectuado um commit/roolback.
E já agora se existir uma opção do genero para MS SQL 2000 era bem vinda!
FIXE. Pelos vistos também existe uma opção em MS SQL, mas que está OFF e que é invertido.
O SET IMPLICIT_TRANSACTIONS { ON | OFF }
Tal como te tinha dito.
Agora percebo o que querem dizer com "tudo é uma transacção". Claro que "tudo é uma transacção" é uma expressão paradoxal por si própria.
Estavam a referir-se a uma ligação ser uma transacção tal como disseste. Não é a ideia que tenho. Por exemplo, se um gajo abrir uma CLI do oracle quer dizer que todas as operações que alterem registos trancam aquilo por ali fora?