На базовом уровне базы данных вы не можете убить отдельные запросы. Вы убиваете отдельные сессии. Из вашего вопроса я заключаю, что ваш конкретный вариант использования находится внутри приложения, а не такого инструмента, как Sql Developer или Sql Plus.
Убийство сеансов может выполняться пользователями, имеющими специальные права доступа к базе данных для уничтожения сеансов. Если вы находитесь внутри приложения, выполняющего несколько запросов в одном сеансе, его уничтожение фактически убьет ваше приложение и потребует либо a) перезапуска приложения, либо b) изящной программной обработки отброшенного сеанса.
Если вы используете n-уровневую платформу ORM, которая обрабатывает взаимодействия с базой данных для вас, вы можете оказаться в ситуации, когда уничтожение сеанса не окажет никакого влияния на ваше приложение, кроме текущего выполняющегося оператора.
Еще один способ в вашем приложении обрабатывать изолирующие сеансы и запросы - запускать многопоточное приложение. Каждый запрос порождает новый поток, и этот поток можно уничтожить, не обязательно прерывая сеанс.
По сути, короткий ответ: вы можете убить запрос, только убив его сеанс. Ваш подход к просмотру v $ session является правильным и необходим для нахождения идентификатора сеанса для любого оператора givel sql, вам просто нужно, чтобы ваш администратор БД предоставил ваши привилегии синонимам v $ session и v $ sql.
Обновление, специфичное для Sql Developer, на основе комментария ОП для уточнения:
Sql Developer имеет возможность разрешать параллельные запросы, используя преимущества потоков и нескольких соединений. Этот параметр находится в меню «Инструменты»> «Установки»> «База данных»> «Рабочий лист». Независимо от настройки, когда вы нажимаете кнопку отмены запроса, приложение все еще отправляет запрос на удаление сеанса. Графический интерфейс обычно будет изящно начинать новый сеанс, и конечный пользователь не знает об этом. Но иногда что-то не получается, и графический интерфейс зависает, или вы в конечном итоге не подключаетесь, и вам приходится вручную подключаться.
Чтобы добавить к сложности, поведение зависит от драйвера / клиента, используемого вашим приложением. OCI, толстые клиенты и тонкие клиенты в прошлом демонстрировали разное поведение, когда дело доходит до уничтожения запросов. На самом деле, в Sql Developer у вас есть возможность заставить его использовать OCI или толстый драйвер, чтобы вы могли избежать определенных действий.
Я бы настоятельно рекомендовал получить права на просмотр v $ session и поэкспериментировать с этим. Интересно узнать больше о том, как Oracle управляет сессиями.
Я только что обнаружил, что последняя версия, Oracle 18c, позволяет убивать отдельный запрос в течение сеанса. Я на 12c, поэтому я не пробовал это. https://docs.oracle.com/en/database/oracle/oracle-database/18/admin/managing-processes.html#GUID-7D8E5E00-515D-4338-8B86-C2044F6D2957
Соответствующие детали из документации.
5.10.5 Отмена оператора SQL в сеансе Вы можете отменить оператор SQL в сеансе с помощью оператора SQL ALTER SYSTEM CANCEL.
Вместо завершения сеанса вы можете отменить высоконагруженный SQL
заявление в сеансе. Когда вы отменяете оператор DML, оператор
откат.
Следующие пункты необходимы в SQL ALTER SYSTEM CANCEL
заявление:
SID - идентификатор сеанса
SERIAL - серийный номер сеанса
Следующие пункты являются необязательными в ALTER SYSTEM CANCEL SQL
утверждение:
INST_ID - ID экземпляра
SQL_ID - идентификатор SQL оператора SQL
Вы можете просмотреть эту информацию для сеанса, запросив GV $ SESSION
вид.
Ниже приведен синтаксис для отмены оператора SQL:
ALTER SYSTEM CANCEL SQL 'SID, SERIAL, @INST_ID, SQL_ID';