Ответ 1
Поскольку вы продолжаете получать страницы результатов, я предполагаю, что вы начали сеанс в SQL * Plus. Если это так, легко сделать это bash ctrl + break много, много раз, пока он не остановится.
Более сложный и более общий способ (ы), который я подробно описываю ниже, в порядке возрастания свирепости/зла. Первый, вероятно, сработает для вас, но если это не так, вы можете продолжать двигаться вниз по списку.
Большинство из них не рекомендуется и могут иметь непреднамеренные последствия.
1. Уровень Oracle - Убейте процесс в базе данных
Согласно ответ ObiWanKenobi и документация ALTER SESSION
alter system kill session 'sid,serial#';
Чтобы найти sid, идентификатор сеанса и serial#, серийный номер, запустите следующий запрос - суммированный из OracleBase - и найдите свою сессию:
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'
Если вы используете RAC, вам нужно немного изменить это, чтобы учесть несколько экземпляров, inst_id что их идентифицирует:
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'
Этот запрос также будет работать, если вы не используете RAC.
Если вы используете инструмент PL/SQL Developer, тогда окно сеансов также поможет вам найти его.
Для немного более сильного "kill" вы можете указать ключевое слово IMMEDIATE, которое инструктирует базу данных не ждать завершения транзакции:
alter system kill session 'sid,serial#' immediate;
2. Уровень ОС - Проблема a SIGTERM
kill pid
Предполагается, что вы используете Linux или другой вариант * nix. SIGTERM - это сигнал завершения от операционной системы к конкретному процессу с просьбой прекратить работу. Он пытается позволить процессу закончить изящно.
Получение этого неправильного результата может привести к завершению основных процессов ОС, поэтому будьте осторожны при вводе.
Вы можете найти идентификатор процесса pid, выполнив следующий запрос, который также сообщит вам полезную информацию, такую как терминал, на котором выполняется процесс, и имя пользователя, которое его запускает, чтобы вы могли убедиться в правильности выбора один.
select p.*
from v$process p
left outer join v$session s
on p.addr = s.paddr
where s.sid = ?
and s.serial# = ?
Еще раз, если вы используете RAC, вам нужно немного изменить это:
select p.*
from Gv$process p
left outer join Gv$session s
on p.addr = s.paddr
where s.sid = ?
and s.serial# = ?
Изменение предложения where на where s.status = 'KILLED' поможет вам найти уже убитый процесс, который все еще "работает".
3. OS - Проблема a SIGKILL
kill -9 pid
Используя тот же pid, который вы выбрали в 2, SIGKILL является сигналом операционной системы к определенному процессу, который немедленно приводит к немедленному завершению процесса. Еще раз будьте осторожны при наборе текста.
Это редко бывает необходимо. Если вы делали DML или DDL, он остановится любой откат обрабатывается и может затруднить восстановление базы данных до согласованного состояния в случае сбоя.
Все остальные параметры уничтожат все сеансы и приведут к вашей базе данных, а в случае с сервером 6 и 7 - станут недоступными. Они должны использоваться только в случае крайней необходимости...
4. Oracle - Shutdown база данных
shutdown immediate
Это на самом деле политический, чем SIGKILL, хотя, очевидно, он действует на все процессы в базе данных, а не на ваш конкретный процесс. Всегда полезно быть вежливым в вашей базе данных.
Выключение базы данных должно выполняться только с согласия вашего администратора баз данных, если оно у вас есть. Приятно рассказывать людям, которые также используют базу данных.
Он закрывает базу данных, завершая все сеансы и rollback по всем незафиксированным транзакциям. Это может занять некоторое время, если у вас есть большие незафиксированные транзакции, которые необходимо отменить.
5. Oracle - выключение базы данных (менее приятный способ)
shutdown abort
Это примерно то же самое, что и SIGKILL, хотя еще раз для всех процессов в базе данных. Это сигнал к базе данных, чтобы немедленно остановить все и умереть - тяжелая авария. Он завершает все сеансы и не откатывается; из-за этого это может означать, что база данных снова займет больше startup. Несмотря на зажигательный язык, shutdown abort не является чистым злом и обычно можно безопасно использовать.
Как и раньше, сначала сообщите людям соответствующие люди.
6. ОС - перезагрузите сервер
reboot
Очевидно, что это не только останавливает базу данных, но и сервер использует ее с осторожностью и с согласия ваших системных администраторов в дополнение к администраторам баз данных, разработчикам, клиентам и пользователям.
7. OS - последний этап
У меня перезагрузка не работала... Как только вы достигли этого этапа, вам лучше надеяться, что вы используете виртуальную машину. Мы закончили его удаление...
