On the
Windows operating system platforms, Oracle
provides a command line utility for killing
sessions: orakill.
The reason is two-fold. First, Oracle on Windows
is implemented based upon threads rather than
processes. So when the Windows Task Manager is
viewed, all that will be seen is one ORACLE.EXE
for that database instance. The individual
threads for the sessions will not be visible
since Task Manager only shows the process and
number of threads. Look at the next screen
snapshot; there are two SQL*Plus sessions
connected to the database on this Windows box.
Even though two sqlplus.exe processes can be
seen, there is but one oracle.exe process. One
would need to dig deeper than the basic Windows
task management program to find the Oracle
dedicated database server process’ thread.
Figure 4.7:
ORACLE.EXE in
Windows Task Manager
Find a utility program, such
as the free QuickSlice (qslice.exe) and PStat
(pstat.exe) from the Microsoft's Resource Kit,
or Process Explorer (procexp.exe), also from
Microsoft. With tools like these, now open the
oracle.exe process and investigate into its many
threads. However, if one simply selects the 1176
thread using Process Explorer and presses the
KILL button, there could be a problem. These
tools do not inform Oracle’s PMON as to what
just occurred, so they do not always make a
hanging session and its locks go away. It still
may be necessary to also manually run oradebug
wakeup 1 to clear the locks, v$session and
v$process. Hence, it is advisable to always use
the Oracle- provided orakill utility instead.
Just be careful, because if the wrong thread,
such as a background process, is chosen, then
the entire database may crash. As was said
before, KILL is a four-letter word.
Figure 4.8:
Selecting 1176 Thread in Process
Explorer
The orakill command is very
simple. In fact, it is essentially the exact
same syntax as the ALTER SYSTEM KILL SESSION.
This means that it accepts two parameters – the
SID and v$process.spid – which represents the
thread number.
C:\Temp>orakill OR0310
1176
Kill of thread id 1176 in
instance OR0310 successfully signaled.
renice
On UNIX and Linux, there may
be occasions where increasing an Oracle process
priority may be contemplated. While some people
are dead set against this, the Oracle ADDM
report can, on occasion, suggest increasing the
priority of the GS processes in order to reduce
global waits in a RAC environment. Remember,
only the priority of a process that is owned can
be changed, so login as Oracle or root to make
these changes. The command syntax is as follows:
$ renice nice_value id
[options]
Where the options are:
|
-g
|
Force
who
parameters to be interpreted as process
group IDs
|
|
-p
|
Resets
who
interpretation to be (the default)
process IDs
|
|
-u
|
Force
who
parameters to be interpreted as user
names
|
The nice value can range from
-20 (fastest or highest) to 19 (slowest or
lowest).
 |
For more details on Oracle utilities, see the book "Advanced
Oracle Utilities" by Bert Scalzo, Donald K. Burleson, and Steve Callan.
You can buy it direct from the publisher for 30% off directly from
Rampant TechPress.
|
