Discussions
Categories
- 196.8K All Categories
- 2.2K Data
- 238 Big Data Appliance
- 1.9K Data Science
- 450.3K Databases
- 221.7K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 550 MySQL Community Space
- 478 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 544 SQLcl
- 4K SQL Developer Data Modeler
- 187K SQL & PL/SQL
- 21.3K SQL Developer
- 295.8K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.5K Development Tools
- 107 DevOps
- 3.1K QA/Testing
- 646K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 155 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 18 Java Essentials
- 160 Java 8 Questions
- 86K Java Programming
- 80 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 204 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 437 LiveLabs
- 38 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 171 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 232 Portuguese
How to stop the below query from execution DELETE FROM SNP_SESS_TASK_LOG WHERE SESS_NO IN ( SELECT S

This is creating undo tablespace issue and I am not sure from where we can stop the same. Any help would be appreciated.
Answers
-
I can think of a very dirty method to stop it running - assuming the statement never changes and you have the SQL_ID - but it would be better to come up with a legal strategy for dealing with the problem.
You haven't told us anything about the undo tablespace issue (tablespace full, too much I/O from other sessions on the undo tablespace, this session crashing and rolling back, other sessions failing and rolling back, tablespace growing to ridiculously huge size, other) but we might guess that the delete is generating a lot of undo and that's producing an undesirable side effect.
If that guess is correct you might investigate what the statement does and do it by hand in several stages. For example if it has a clause like "where date_created < sysdate - 30" but this turns out to be 5 years worth of data, you might run a series of statement that start 5 years back and delete one months worth of data at a time so that the next time this statement runs there's only a little data left for it to delete. (And at that point you might try moving this table "online" so that the vast amount of empty space is released to the tablespace and any indexes are tidied up).
Regards
Jonathan Lewis
If you can see v$session when this statement is running then various columns in the view may give you some ideas about where it's running from - e.g. module, application, client_info, client_identifier, plsql_object_id, username, program.
If you can't get anything from the dynamic views you might find something in dba_source if you searched for lower(text) like '%snp_sess_task_log%'
And if you are after a way of killing it intermittently rather than working out how to deal with it then maybe Tanel's notes will help: https://tanelpoder.com/2010/02/17/how-to-cancel-a-query-running-in-another-session/ (the alter system cancal SQL bit, in particular)