Bom, antes de tudo necessariamente se observa que " banco de dados extremamente crítico (para o negócio) e 24x7" mas em "10.2.0.3.0" (com o .0 indicando que NENHUM patch foi Aplicado, E sendo 10gr2 absolutamente sem bugfix e PROVAVELMENTE sem Suporte nenhum, já que dificilmente alguém se coça a pagar Suporte Extendido), é uma Contradição em termos - sorry, mas não parece ser tão "crítico" assim, se neguim se habilita a rodar na bamba, sem Suporte algum se der pau....
Isso posto, a resposta : primeira coisa, não sei se vc sabe quando vc faz um ALTER SYSTEM KILL SESSION vc ** não ** está matando a sessão, e sim está mandando ela se matar - assim que puder, ela se matará cfrme vc mandou... A questão é que o KILL foi designado para ser graceful, ie, AVISAR gentilmente o usuário, dando uma mensagem Clara e Auditável para ele tipo "ORA-xxx your session was killed", e para isso ele só encerra efetivamente quando o processo do usuário responde que recebeu e exibiu pro usuário final a mensagem - o "problema" é quando, por qualquer exceção/problema imprevisto o processo que atendia o usuário morreu/ficou bloqueado/ficou irresponsivo : nesse cenário logicamente o RDBMS vai ficar Eternamente esperando a resposta que nunca vai vir... É por isso que se vc ** não tem certeza ** se está tudo OK, o ideal via de regra é pedir um ALTER SYSTEM DISCONNECT SESSION , esse cara não fica esperando por resposta nenhuma, sim ?? Pra este caso que vc já usou o KILL não adianta mais, mas fique sabendo para os próximos... Outra coisa a Avaliar para o futuro é vc avaliar a viabilidade de diminuir o timeout de TCP (que normalmente é longuíssimo no Windows), e no banco implantar DCD e via profile um LIMIT máximo de x horas para as sessões - muitas vezes isso melhora Muitíssimo o tempo que o RDBMS leva para 'perceber' que uma sessão/processo está zumbizando... Continuando : antes de discutirmos , sobre as suas opções ANTES do recycle do database, primeiro de tudo veja em http://www.oracle-base.com/articles/misc/killing-oracle-sessions.php como identificar a sessão e o processo envolvidos. Feito isso, consulte repetidas vezes (com vários minutos de intervalo) a GV$SESSION (veja as colunas de waits/eventos), GV$SESSION_LONGOPS (com um WHERE TIME_REMAINING > 0) e a GV$TRANSACTION para ver se está havando algum progresso no rollback ou seja no que for que a sessão a ser morta tá fazendo... Vale também ver GV$TRANSACTION_ENQUEUE, DBA_PENDING_TRANSACTIONS (se vc usa transações remotas) e GV$LOGSTDBY_TRANSACTION/GV$LOGSTDBY_TRANSACTION/GV$XSTREAM_TRANSACTION se vc usa tais features... Com essa informação na mão : SE não está havendo progresso nenhum, acho que a opção que te resta é tentar matar a task diretamente no SO, sem confiar no ORAKILL : o busílis é que o ORAKILL apenas sinaliza para o process ORACLE.EXE no Windows eliminar a thread especificada... A idéia é (** JUNTO COM SEU SYSADMIN!! **) tentar matar diretamente a thread em questão via Process Explorer : esse cara é um utilitário Externo que a m$soft comprou, veja em http://technet.microsoft.com/en-us/sysinternals//bb545021.aspx ... Eu só não sei se eu Arriscaria meu pescoço fazendo coisas do tipo num ambiente sem Suporte nenhum, como Creio que deve ser o caso : pensa aí se é viável ... []s Chiappa
