The regular session background processes can normally be killed. Where addr not in (select paddr from v$session) The following SQL can be used to identify the processes that have no session tied to it: select pid, spid, pname, program If a database gets - logically - corrupted it would mean that the client did not make use of the regular transaction mechanism. Would be a bit strange since this would mean that if a client crashes it would corrupt the rdbms. The state of the database does not depend on a client that gets killed. Oracle is very robust and if anything should be recovered, smon takes care of that, if needed. You can find the OS pid for these processes by checking the processes that are not The process of the killed session remains in v$process. When you kill a session, the connection between v$session and v$process is gone. If the client is gone, this will never be acknowledged so the dbms will wait forever. Most of the time the session tries to tell the client something nasty happened. I don't think these sessions take resources. If the client itself has already left or the network communication has been severed, the killed session may stay indefinitely until you restart the instance. This is often because Oracle is waiting for the client to return a relevant error message, such as: ora-00028 your session has been killed Some session, after being killed, will remain in the v$session view, even after all their changes have been entirely rolled back. The rollback is handled by smon, I wouldn't try to kill it. If you shutdown ABORT, the database will be left in an inconsistent state (uncommited data written to disk) and Oracle will resume the rollback as soon as the database is restarted. If you shutdown the database normally (or transactional or immediate), Oracle will wait for the process to complete so that the database is left in a consistent state. shutdown the database in the hope that this will terminate the session.You have few means to accelerate the process. This explains why rollback can take a lot of time. For instance a delete which is a relatively cheap DML becomes an insert in reverse (which is more expensive). Some changes are more expensive in reverse.The rollback is not as well optimized, in particular multi-row operations can take a lot longer than regular DML.This can take longer than the initial DML for several reasons: The uncommited transaction is read back from the undo tablespace and each and every change is undone in reverse order. One of the consequences is that rollback needs to undo the changes. This is also why you almost never wait for a commit in Oracle, even for multimillion-row DML. This is also one of the reasons that allows Oracle to have arbitrarily large transactions (limited only by the size of the undo tablespace). Most sessions should rarely rollback so Oracle anticipates by writing preemptively the changes. This is done because Oracle is optimized for commit. The other sessions don't see these changes yet thanks to multiversion read consistency but the actual physical block may already be overwritten with your uncommited work. When you do DML on a table, Oracle may make the changes to the base table almost immediately, even if you don't commit. Outstanding work must still be cleaned up. The session is killed but it is being cleaned up. Session is killed immediatelly: system KILL altered.From a thread on AskTom, when a session is killed: You can force Oracle Database to kill session immediatelly: alter system kill session 'sid,serial#' immediate Oracle Database marks the session for kill and ends it and rolls back all transactions that are associated with it as soon as possible. In our example we will kill session sid=99, serial#=98. Now we will use session identifier (sir) and serial# to kill the session. My session sid=58, machine=ls-michalwrobel You can see session list on our test server. module - name of the currently executing module as set by calling the DBMS_APPLICATION_INFO.SET_MODULE procedure.program - operating system program name.machine - operating system machine name.osuser - operating system client user name.We do it by listing all sessions on the server with this query: select sid, Find session IDįirst we will identify the session we want to end. Please note that you need dba privilege to access the data in v$session view and kill a session. Oracle Database provides command to kill specific session on a server.