Stored Procedures em Oracle

[Anjo]

Ois!

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.

A minha questão:

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...

[pedrotuga]

anjo,

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.

[Anjo]

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.

[Anjo]

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.

[shumy]

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.

[Anjo]

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.

[M6]

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.

[pedrotuga]

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.

[Anjo]

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!

[shumy]

... 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...

[pedrotuga]

... 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.

[shumy]

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!

[shumy]

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 }

[pedrotuga]

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!

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?