If you want to know how long you could be waiting, work it out like this: (it will show all active sessions, you can finetune to select only the session you are interested in)

SELECT sysdate, a.sid, a.username, b.xidusn, b.used_urec, b.used_ublk
FROM v$session a, v$transaction b
WHERE a.saddr = b.ses_addr;

Run this same query after a specific amount of time (for example 10 minutes).

Then do the following:

select first_used_urec_result / ((first_used_urec_result – second_used_urec_result)/time_difference_in_minutes)/60 from dual;

Real example:

SELECT sysdate, a.sid, a.username, b.xidusn, b.used_urec, b.used_ublk
FROM v$session a, v$transaction b
WHERE a.saddr = b.ses_addr;

SYSDATE             SID USERNAME                       XIDUSN USED_UREC USED_UBLK
03/29/2012 12:53:13 241 USER1                          39     1274002   35704

Rerun query 10 minutes later:
SYSDATE             SID USERNAME                       XIDUSN USED_UREC USED_UBLK
03/29/2012 13:03:13 241 USER1                          39     1232582   34545

select round(1274002/(( 1274002 – 1232582 )/10)/60,2)  from dual ;

5.13

So this transaction will take another 5 hours or so to finish rolling back…ouch.

select j.sid,
s.spid,
s.serial#,
j.log_user,
j.job,
j.broken,
j.failures,
j.last_date||’:'||j.last_sec last_date,
j.this_date||’:'||j.this_sec this_date,
j.next_date||’:'||j.next_sec next_date,
(j.next_date – j.last_date) interval,
j.what
from (select djr.SID,
dj.LOG_USER, dj.JOB, dj.BROKEN, dj.FAILURES,
dj.LAST_DATE, dj.LAST_SEC, dj.THIS_DATE, dj.THIS_SEC,
dj.NEXT_DATE, dj.NEXT_SEC, dj.INTERVAL, dj.WHAT
from dba_jobs dj, dba_jobs_running djr
where dj.job = djr.job ) j,
(select p.spid, s.sid, s.serial#
from v$process p, v$session s
where p.addr = s.paddr ) s
where j.sid = s.sid;

• Make sure your environment is set: ORACLE_SID and ORACLE_HOME ( set it in /etc/oratab first for ease of use ).
• Use this template to create an inittestdb.ora (presuming your db name is testdb) and place it in $ORACLE_HOME/dbs, remember to change path values

  control_files = (/u01/oradata/testdb/control1.ctl,/u01/oradata/testdb/control2.ctl,/u01/oradata/testdb/control3.ctl)
  undo_management = AUTO
  undo_tablespace = UNDOTBS1
  db_name = testdb
  db_block_size = 8192
  sga_max_size = 1073741824
  sga_target = 1073741824

• Create your password file in $ORACLE_HOME/dbs:     orapwd file=orapwtestdb password=thepassword entries=4
• Start the db in nomount mode :
  sqlplus / as sysdba
  startup nomount
• Create cr_testdb.sql and run it:

  create database testdb
  logfile group 1 (‘/u01/oradata/testdb/redo1.log’) size 100M,
  group 2 (‘/u01/oradata/testdb/redo2.log’) size 100M,
  group 3 (‘/u01/oradata/testdb/redo3.log’) size 100M
  character set WE8ISO8859P1
  national character set utf8
  datafile ‘/u01/oradata/testdb/system.dbf’ size 500M autoextend on next 10M maxsize unlimited extent management local
  sysaux datafile ‘/u01/oradata/testdb/sysaux.dbf’ size 100M autoextend on next 10M maxsize unlimited
  undo tablespace undotbs1 datafile ‘/u01/oradata/testdb/undotbs1.dbf’ size 100M
  default temporary tablespace temp tempfile ‘/u01/oradata/testdb/temp01.dbf’ size 100M;

  SQL> @cr_testdb.sql

• Create the catalog
  SQL>@?/rdbms/admin/catalog.sql

  SQL>@?/rdbms/admin/catproc.sql

• Change your sys and system passwords and also remember to set up the listener and tnsnames.ora if you want to access your testdb over the network.

cat alert_DBID.log | grep ORA- | sort | uniq

That’s all there is to it..

For example, if you want to kill all processes associated with one particular SID, but have multiple SIDs running on your server,
don’t grep for ‘oracle’ as the list that is returned is for ALL oracle processes on the server.

In this example, I need to kill all processed associated with the Oracle management agent (emagent) on a server.

I do not need to worry about being careful as I only have one agent home on the server and can not accidentally kill irrelevant ones.

$ps -ef | grep emagent

oracle     395 14244  0 15:10 pts/1    00:00:00
 grep emagent
oracle    3905     1  0 13:45 pts/1    00:00:00
/home/oracle/product/agent10g/perl/bin/perl
/home/oracle/product/agent10g/bin/emwd.pl
agent /home/oracle/product/agent10g/sysman/log/emagent.nohup
oracle    3922  3905  0 13:45 pts/1    00:00:08
/home/oracle/product/agent10g/bin/emagent
oracle    3928  3922  0 13:45 pts/1    00:00:00
/home/oracle/product/agent10g/bin/emagent
oracle    3929  3928  0 13:45 pts/1    00:00:00
/home/oracle/product/agent10g/bin/emagent
oracle    3930  3928  0 13:45 pts/1    00:00:00
/home/oracle/product/agent10g/bin/emagent
oracle    3931  3928  0 13:45 pts/1    00:00:00
/home/oracle/product/agent10g/bin/emagent
oracle    3932  3928  0 13:45 pts/1    00:00:00
/home/oracle/product/agent10g/bin/emagent
oracle    4019  3928  0 13:45 pts/1    00:00:00
/home/oracle/product/agent10g/bin/emagent
oracle    4233  3928  0 13:46 pts/1    00:00:00
/home/oracle/product/agent10g/bin/emagent
oracle    4235  3928  0 13:46 pts/1    00:00:00
/home/oracle/product/agent10g/bin/emagent
oracle    4236  3928  0 13:46 pts/1    00:00:00
/home/oracle/product/agent10g/bin/emagent
oracle    4237  3928  0 13:46 pts/1    00:00:00
/home/oracle/product/agent10g/bin/emagent
oracle    4238  3928  0 13:46 pts/1    00:00:00
/home/oracle/product/agent10g/bin/emagent
oracle    4239  3928  0 13:46 pts/1    00:00:00
/home/oracle/product/agent10g/bin/emagent
oracle    4240  3928  0 13:46 pts/1    00:00:00
/home/oracle/product/agent10g/bin/emagent
oracle    4241  3928  0 13:46 pts/1    00:00:00
/home/oracle/product/agent10g/bin/emagent
oracle   14736  3928  0 14:41 pts/1    00:00:00
/home/oracle/product/agent10g/bin/emagent

$ps -ef | grep emagent| awk '{print $2}' | xargs kill -9
$
$ps -ef | grep emagent
oracle   27931 14244  0 15:26 pts/1    00:00:00 grep emagent

Oracle creates implicit cursors for all SQL DML (data manipluation language) statements, even for select statements returning one row.

If your query returns more than one row, you can explicitly declare a cursor in PL/SQL to process the rows one by one.

Here is a simple example of using a cursor in a ‘cursor for loop’ (which automatically opens, fetches from and closes the cursor for you) :

Your client application may hit the following error :

This means that your application’s session has hit the database-wide limit of the maximum number of open cursors which one session is allowed to have.

The database parameter which governs this limit is : open_cursors

You can change this parameter in real-time, but you should ask yourself the question if the value is really too low, perhaps the application code should be rewritten, to either do better housekeeping (close cursors when they are done), or rewrite the code so that many DML statements can be recoded to be used in one cursor.

Never set this to an excessive value, you want to keep open cursors in check.
Rather let a new, untuned application hit this error so that the code can be tuned.

Setting this value higher does not cause performance overhead on the database.

If you do decide to change the value , this is how to do it :
(the default value of 50 is usually too small, so you will probably change it sooner or later).

How to find out which cursors are open for a session ?

Get the session’s sid from v$session, then get the sql_text from v$open_cursor :

Recommended reading for more information on oracle cursors :

Oracle online documentation: Oracle® Database Application Developer’s Guide – Fundamentals

Use top on the unix command line to see which process is the main culprit:
(use shift+M to sort the list in order of highest memory consumption)

Make sure the top process is a client connection shadow process:

Inside the database, find out who this is :
(formatted result)

Kill the user:

The user will receive this message either immediately or at the next attempted SQL statement:

Recommended reading:

Warning, it is unsupported by Oracle, so don’t base your mission-critical alerts on this method.

Let’s say you are creating a stored proc as user scott, and instead of writing your
trapped error message to a table, an error file or sending an email, you would like it to be reflected
in the database’s alert.log.

The steps below show you how.

If not documented, this is guaranteed to make you unpopular with DBAs who manage your database in your absence…
First, grant execution privileges to scott:

as sys:

Now run and test a procedure which will write to the alert.log

This is how it reflects in the alert.log (ORA-0000 because there is no error.)

Lastly : implement it in your procedure’s exception handler section:

The solution is to use the dbms_utility package as a DBA user.

Example, if you want to recompile all procedures,functions, packages and triggers belonging to scott
here is how to do it:

If you only want to recompile all invalid options, execute it like this :

If you want to use each object’s session settings instead of the calling user’s settings:

To see if any errors were generated
(you must run this command immediately after executing dbms_utility) :

Another way to see if the compilations were successful :

Recommended reading:

You can use it to share disk space amongst servers, so that each server ‘sees’ the shared filesystem as if it is local.

If your network is fast enough, you can backup your oracle database to a shared filesystem, or just keep

any required software on the shared filesystem so that you do not need to install the software

numerous times on different servers.

In this example, we are sharing a filesystem called orabackup on server share01.world.com, and then

we will mount that on a database server called prod01.world.com.

Steps to take on share01:

Log in as root.

Add prod01′s IP to /etc/exports

If there is more than one entry, make sure there is a space between IP addresses.

Send a hangup to the mountd process to force it to reread the /etc/exports file.

Steps to take on prod01:

Log in as root.

Create /orabackup

Edit /etc/fstab, add line to the bottom:

Mount the filesystem :

Once that is completed, you will be able to access it like a local filesystem.

To find large directories, use the du command and sort the output.

For example, to output the 10 largest directories in /var, sorted in ascending size order, use the following command:

du -ko /var|sort -n | tail -10

To avoid crossing file system boundaries, that is, to see the directory usage in / but not in the other mounted files systems (/var, /opt, and so on), add the d option to the du command:

du -kod /var|sort -n | tail -10

Finding Large Files

To find large files, use the find command and sort the output.

Example 1: To find all plain files (not block, character, symbolic links, and so on) in a file system larger than 200,000 512-byte blocks (approximately 100 Mbytes) and sort on field 7 (file size) while numerically ignoring leading blanks, do this:

find / -size +200000 -type f -ls | sort -k 7,7 -n

Sourced from: http://wikis.sun.com/display/BigAdmin/Finding+Large+Files+and+Directories+in+the+Solaris+OS

Here is the method to follow to clean it up while your listener is still running.

Log into your listener from the command prompt (make sure your Oracle environment is set to that of where the listener is started from, the commands below assume there is only one (default)  listener running ) :

$lsnrctl

..

LSNRCTL>  set log_status off
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC)))
LISTENER parameter “log_status” set to OFF
The command completed successfully

(Now go delete/rename $ORACLE_HOME/network/log/listener.log to something else in another OS session )
LSNRCTL> set log_status on
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC)))
LISTENER parameter “log_status” set to ON
The command completed successfully
LSNRCTL> quit

Permalink — click for full blog post

Related Blogs

• Related Blogs on kill oracle process

• Related Blogs on oracle process

Permalink — click for full blog post

Permalink — click for full blog post

Permalink — click for full blog post

Permalink — click for full blog post

Permalink — click for full blog post