Foi explicado algumas vezes antes e não tenho certeza do porquê ainda parece ser um mistério que às vezes as sessões não são canceladas imediatamente (ou nunca).
Do meu livro
Administração do SAP HANA | Livro e E-Book - por SAP PRESS:
10.2.4 Cancelar uma sessão
Às vezes pode ser desejável não apenas cancelar uma declaração em execução de uma sessão, mas também desconectar completamente a sessão. O comando para isso é ALTER SYSTEM DISCONNECT SESSION '' e pode ser usado de forma semelhante ao comando CANCEL SESSION. A diferença entre isso e o comando CANCEL WORK é simplesmente que não apenas a declaração atual será cancelada, mas a sessão em si será encerrada.
Nota
Desconectar a sessão não é uma forma "mais forte" de forçar o término de uma declaração em execução. Com qualquer uma das opções, a declaração em execução primeiro deve reconhecer a flag de cancelamento e em seguida o rollback da transação deve ser realizado, o que também pode levar um tempo considerável. Se o comando CANCEL WORK não conseguiu parar uma declaração em execução, então não faz sentido tentar DESCONECTAR SESSÃO.
10.2.5 Problemas com o Cancelamento de Sessões
Como você viu, a capacidade de interromper comandos em execução e desconectar sessões depende da ideia de que a sessão a ser cancelada verifica ativamente se a flag de cancelamento está definida. Esse abordagem tem a desvantagem de que há situações em que a sessão não pode verificar a flag e, portanto, nunca pode ser cancelada.
Por exemplo, uma sessão poderia abrir uma transação e atualizar uma tabela, mas não confirmar a atualização. Em vez disso, a sessão não faz mais nada e simplesmente mantém um bloqueio no registro modificado (por exemplo, imagine um usuário que tem um formulário de entrada de dados aberto e sem salvar sai para almoçar). Se outras sessões precisarem alterar esse registro também, elas terão que esperar até que a primeira sessão libere o bloqueio.
Nessa situação, cancelar a sessão do detentor do bloqueio não ajuda, porque a sessão atualmente não está executando nenhum código que possa verificar a flag de cancelamento. Essa situação, em que a sessão está INATIVA, só pode ser resolvida desconectando a sessão.
O problema com isso é óbvio: e se o aplicativo cliente estiver processando legitimamente os dados e precisar gravar os resultados de volta no banco de dados? Nesse caso, o trabalho será perdido e a sessão terá que ser reiniciada. Portanto, é importante investigar por que a sessão está inativa enquanto uma transação está aberta e decidir caso a caso se desconectar a sessão. (Veremos como encontrar quem está executando uma sessão na Seção 10.3).
Um segundo problema é que às vezes leva vários minutos até que o rollback de uma sessão seja concluído com sucesso. Durante esse tempo, não há sinais visíveis, no monitor de Threads, por exemplo, de que o thread específico está marcado para término. Isso poderia levar os administradores de banco de dados a tentar executar o comando CANCEL SESSION repetidamente até que funcione. Claramente, isso é inútil.
Para garantir que os comandos de controle de sessão sejam compreendidos, você pode examinar o arquivo de rastreamento do servidor de Índices no Listagem 10.4.
[...]
[12351]{301610}[-1/-1] 2013-12-19 03:03:05.410801 i SQLSessionCmd
Statement.cc(03254):
o comando de controle de sessão é realizado por 301610,
usuário=LARS, usuário de aplicação=I028297,
fonte de aplicação=csns.sql.editor.SQLExecuteFormEditor$1$1
.run(SQLExecuteFormEditor.java:796);
, consulta=ALTER SYSTEM CANCEL SESSION '301611'
[...]
Listagem 10.4 Extrato do Arquivo de Rastreamento do Servidor de Índices
No caso de uma declaração ou cancelamento de sessão não ter sucesso de forma alguma, pode ser que o SAP HANA esteja atualmente executando uma rotina que ainda não verifica a flag de cancelamento. Para encontrar essas rotinas e melhorá-las, o desenvolvimento do SAP HANA precisa conhecê-las. Essas informações podem ser coletadas por meio de um dump em tempo de execução. A Nota da SAP 1951590 cobre isso.
Nesse caso, infelizmente, as únicas possibilidades de interromper a sessão em execução são forçar o cliente a liberar o bloqueio (se possível), interromper o processo do cliente ou, como último recurso, interromper e reiniciar todo o processo do servidor de Índices, o que também encerrará todas as outras sessões.
Portanto, antes de dar esse último passo, considere se o cancelamento pode esperar, por exemplo, até que a maioria dos usuários tenham encerrado a sessão e os trabalhos importantes tenham sido concluídos. Além disso, você deve abrir um chamado com o Suporte da SAP para essa situação e garantir que o dump em tempo de execução seja coletado para que a causa raiz possa ser analisada mesmo que o sistema seja reiniciado. Em resumo, não se apresse em cancelar threads reiniciando o sistema!
<
