Au fur et à mesure que vous obtenez des pages de résultats, je suppose que vous avez démarré la session dans SQL * Plus. Si c'est le cas, la chose la plus simple à faire est de frapper ctrl + pause plusieurs, plusieurs fois jusqu'à ce qu'il s'arrête.
La ou les manières les plus compliquées et les plus génériques que je détaille ci-dessous par ordre croissant de férocité / mal. Le premier fonctionnera probablement pour vous, mais si ce n'est pas le cas, vous pouvez continuer à descendre dans la liste.
La plupart d'entre eux ne sont pas recommandés et peuvent avoir des conséquences inattendues.
1. Niveau Oracle - Tuez le processus dans la base de données
Selon la réponse d'ObiWanKenobi et la documentation ALTER SESSION
alter system kill session 'sid,serial#';
Pour trouver le sid , l'identifiant de session et le serial# , numéro de série, exécutez la requête suivante - résumée à partir d'OracleBase - et recherchez votre session :
select s.sid, s.serial#, p.spid, s.username, s.schemaname
, s.program, s.terminal, s.osuser
from v$session s
join v$process p
on s.paddr = p.addr
where s.type != 'BACKGROUND'
Si vous utilisez un RAC, vous devez le modifier légèrement pour prendre en compte les multiples instances, inst_id est ce qui les identifie :
select s.inst_id, s.sid, s.serial#, p.spid, s.username
, s.schemaname, s.program, s.terminal, s.osuser
from Gv$session s
join Gv$process p
on s.paddr = p.addr
and s.inst_id = p.inst_id
where s.type != 'BACKGROUND'
Cette requête fonctionnerait également si vous n'exécutez pas de RAC.
Si vous utilisez un outil tel que PL/SQL Developer, la fenêtre des sessions vous aidera également à le trouver.
Pour un "kill" légèrement plus fort, vous pouvez spécifier le mot clé IMMEDIATE, qui indique à la base de données de ne pas attendre la fin de la transaction :
alter system kill session 'sid,serial#' immediate;
2. Niveau du système d'exploitation - Émettre un SIGTERM
kill pid
Cela suppose que vous utilisez Linux ou une autre variante *nix. Un SIGTERM est un signal de fin du système d'exploitation au processus spécifique lui demandant d'arrêter de s'exécuter. Il essaie de laisser le processus se terminer normalement.
Si vous vous trompez, vous risquez de mettre fin à des processus essentiels du système d'exploitation. Soyez donc prudent lors de la saisie.
Vous pouvez trouver le pid , ID de processus, en exécutant la requête suivante, qui vous fournira également des informations utiles telles que le terminal à partir duquel le processus s'exécute et le nom d'utilisateur qui l'exécute afin que vous puissiez vous assurer de choisir le bon.
select p.*
from v$process p
left outer join v$session s
on p.addr = s.paddr
where s.sid = ?
and s.serial# = ?
Encore une fois, si vous utilisez un RAC, vous devez modifier légèrement ceci :
select p.*
from Gv$process p
left outer join Gv$session s
on p.addr = s.paddr
where s.sid = ?
and s.serial# = ?
Changer le where clause à where s.status = 'KILLED' vous aidera à trouver les processus déjà tués qui sont toujours "en cours d'exécution".
3. SE - Émettre un SIGKILL
kill -9 pid
Utiliser le même pid vous avez ramassé en 2, un SIGKILL est un signal du système d'exploitation à un processus spécifique qui provoque l'arrêt immédiat du processus. Encore une fois soyez prudent lorsque vous tapez.
Cela devrait rarement être nécessaire. Si vous faisiez DML ou DDL, cela arrêtera toute restauration en cours et peut rendre difficile la restauration de la base de données dans un état cohérent en cas d'échec.
Toutes les options restantes tueront toutes les sessions et rendront votre base de données - et dans le cas des serveurs 6 et 7 également - indisponible. Ils ne doivent être utilisés qu'en cas d'absolue nécessité...
4. Oracle - Arrêter la base de données
shutdown immediate
C'est en fait plus poli qu'un SIGKILL , bien qu'il agisse évidemment sur tous les processus de la base de données plutôt que sur votre processus spécifique. C'est toujours bon d'être poli avec votre base de données.
La fermeture de la base de données ne doit se faire qu'avec l'accord de votre DBA, si vous en avez un. C'est bien de le dire également aux personnes qui utilisent la base de données.
Il ferme la base de données, met fin à toutes les sessions et effectue un rollback sur toutes les transactions non validées. Cela peut prendre un certain temps si vous avez d'importantes transactions non validées qui doivent être annulées.
5. Oracle - Arrêter la base de données (la manière la moins agréable)
shutdown abort
C'est à peu près la même chose qu'un SIGKILL , mais encore une fois sur tous les processus de la base de données. C'est un signal à la base de données pour qu'elle arrête tout immédiatement et meure - un gros crash. Il met fin à toutes les sessions et n'effectue aucune restauration ; à cause de cela, cela peut signifier que la base de données prend plus de temps à startup de nouveau. Malgré le langage incendiaire, un shutdown abort n'est pas purement diabolique et peut normalement être utilisé en toute sécurité.
Comme avant, informez d'abord les personnes concernées.
6. SE - Redémarrez le serveur
reboot
Évidemment, cela arrête non seulement la base de données mais aussi le serveur, donc utilisez-le avec prudence et avec le consentement de vos administrateurs système en plus des administrateurs de base de données, des développeurs, des clients et des utilisateurs.
7. SE - La dernière étape
Le redémarrage n'a pas fonctionné... Une fois que vous avez atteint cette étape, vous feriez mieux d'espérer que vous utilisez une machine virtuelle. Nous avons fini par le supprimer...
