Hi,
In fact, in your case, adding larger TEMP is not the solution. Solution
is the adding TEMP with larger extent size.
Because, Oracle cleans up segments extent-by-extent. If you have more
extents, cleaning-up them will make more dictionary look-up and this will
eat CPU.
regards...
Charlie
Title: Crash Recovery
Hi All,
I have an interesting problem, on one of my databases, a data warehouse, a killed session was taking too long
to rollback. It was time for the backup, and I had to do a shutdown abort.
No its time to open the database, instance parallel recovery is taking place
It's always a good idea to include your platform, OS version
and most importantly, your Oracle version.
Since it's a DW, I'm guessing that the session in question
was doing parallel DML, and it's an older version of Oracle,
which does not have parallel rollback capability. ( forget
which
of applying redo to roll forward (crash
recovery), followed by rolling back failed transactions (transaction
recovery).
you might have had better luck with killing the user process/thread than
simply issuing the shotdown abort.
Paul
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
Naik, Kevin K wrote:
Hi All,
I have an interesting problem, on one of my databases, a data
warehouse, a killed session was taking too long
to rollback. It was time for the backup, and I had to do a shutdown
abort.
No its time to open the database, instance parallel recovery is taking
Title: RE: Crash Recovery
oops, forgot that,
Sun Solaris 5.6, its an E6000, 16 cpu box, running dbms 7.3.4.5.0
the online redo logs are 500 megs in size
the transaction used -+ 4 million records
-Original Message-
From: Paul Drake [mailto:[EMAIL PROTECTED]]
Sent: 10 June, 2001 21:10
Hi,
Oracle was doing full recovery in older version during crash recovery
( I guess pre
7.3, but I'm not sure). But now, Oracle does not do full database recovery
during
crash recovery. Some un-recovered blocks are recovered when a user
tries to use
them later. So, if your online log files
I've had something like this happen to me.
My solution was to make TEMP larger;
after enduring the LONG wait for recovery
to complete.
"Naik, Kevin K" wrote:
Hi All,
I have an interesting problem, on one of my databases,
a data warehouse, a killed session was taking too long
to rollback. It was
think that with one db writer on Solaris with
filesystems, you're going to wait a long time for
a rollback on a large DML operation during crash
recovery, regardless of the recovery_parallelism
setting.
If you had async io, it would be different, but
you don't really.
The docs for 8i address
