Re: Long Operation

your query against table A will not reflect the delete until the delete is committed, so that's not a good indication progress of a 'stalled' operation

check V$SQL_AREA to see if the statements got executed.

also, why not just truncate the tables? (are FK's the issue?)

do you have a locking problem?

are cascade deletes the problem?

do you have a rollback segment problem? check the alert file, you may need to add a commit after each delete if that is appropriate (ie. if the 4 deletes don't need to be grouped as a single transaction, which is doubtful

-- 
Mark C. Stock
email mcstock -> enquery(dot)com
www.enquery.com
(888) 512-2048


"Gordon T. Wu" <wutao19_at_yahoo.com> wrote in message
news:2zsqb.294$Er.31320_at_mencken.net.nih.gov...


> Hi Group:

>

> I have an operation that is running all night, and still running.  The

> operation involves deleting 4 tables:

>

> delete table a;

> delete table b;

> delete table c;

> delete table d;

>

> /*Rest of the code*/

>

> I have run query against v$session_longops and it is saying that the

> operation has already completed (sofar/totalwork = 1).

> But obviously it is still running since I'm not getting the sql prompt

back.


> Also, I have run a query against table a and it is showing that nothing

> actually got deleted.

>

> I have also run query against v$sgastat to monitor the free memory in SGA,

> it is showing the following:

>     shared pool free memory        163.4 MB

>     large pool free memory            16 MB

>

> Any help would be greatly appreciated.

>

>

>

> Gordon

>

>