Re: Crash Recovery

Kevin,

First off, I cc'd the list on this. When posting a question to the list, it's a good idea to include the list in any replies, as there's a lot of good folks there. The respondent ( me in this case :) may not have good information.

For instance, I don't have access to any 7.3 docs.

I 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 this, and I would expect 7.3 to act this way as well.

I've had this happen on a DW in 7.3.4 as well, though mine took significantly less time than yours is.

By the way, is it done rolling back yet?

You should be able to connect internal and examine the rollback status and see how many blocks there are to go via v$rollstat.

Jared

On Sunday 10 June 2001 11:40, Naik, Kevin K wrote:
> Hi Jared,
> We are using filesystems, and have only 1 db_writer
>
> Kevin N
>
> -----Original Message-----
> From: Jared Still [mailto:jkstill_at_cybcon.com]
> Sent: 10 June, 2001 20:23
> To: Naik, Kevin K
> Subject: Re: Crash Recovery
>
> On Sunday 10 June 2001 10:56, Naik, Kevin K wrote:
> > Hi,
> > Yup, sorry,
> > Its 7.3.4.5.0, Sun Sparc OS 5.6, its an E6000, 16 cpu's.
> > It has a recovery_parallelism of 16. The redo logs are 500 megs in size,
> > surely it would take this long ?
>
> Is your parallel_max_servers also at 16?
>
> Since you are on Solaris, you won't have asyn io unless you
> are using raw disk. If you are on filesystems, do you have
> multiple DB writers?
>
> Jared
>
> > Thanx
> > Kevin Naik
> >
> > -----Original Message-----
> > From: Jared Still [mailto:jkstill_at_cybcon.com]
> > Sent: 10 June, 2001 19:53
> > To: ORACLE-L_at_fatcity.com; Naik, Kevin K
> > Subject: Re: Crash Recovery
> >
> >
> >
> >
> > 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 version introduced this )
> >
> > The rollback is being done serially, and you'll just have
> > to wait for it.
> >
> > Jared
> >
> > On Sunday 10 June 2001 11:00, 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
> > > place as normal, but the problem is,
> > > its being running for more than 20 hours and the database is still not
> > > open.
> > >
> > > Does any body have any clues, thoughts, ideas ?? Is there anyway I can
> > > see what exactly the dbms is up to ?
> > > The instance processes running are completely idle
> > >
> > > Thanx
> > > K Naik
> > >
> > > ______________________________________________
> > >
> > > Disclaimer and confidentiality note
> > >
> > > Everything in this e-mail and any attachments relating to the official
> > > business of Standard Bank Investment Corporation (Stanbic) is
>
> proprietary
>
> > > to the company. It is confidential, legally privileged and protected by
> > > law.\ Stanbic does not own and endorse any other content. Views and
> > > opinions are those of the sender unless clearly stated as being that of
> > > Stanbic.
> > >
> > > The person addressed in the e-mail is the sole authorised recipient.
> > > Please notify the sender immediately if it has unintentionally reached
> > > you and do not read, disclose or use the content in any way.
> > >
> > > Stanbic can not assure that the integrity of this communication has
> > > been maintained nor that it is free of errors, virus, interception or
> > > interference.
> > >
> > >
> > > ______________________________________________
> >
> > ----------------------------------------
> > Content-Type: text/html; charset="iso-8859-1"; name="Attachment: 1"
> > Content-Transfer-Encoding: 7bit
> > Content-Description:
> > ----------------------------------------
> >
> > ______________________________________________
> >
> > Disclaimer and confidentiality note
> >
> > Everything in this e-mail and any attachments relating to the official
> > business of Standard Bank Investment Corporation (Stanbic) is proprietary
> > to the company. It is confidential, legally privileged and protected by
> > law.\ Stanbic does not own and endorse any other content. Views and
> > opinions are those of the sender unless clearly stated as being that of
> > Stanbic.
> >
> > The person addressed in the e-mail is the sole authorised recipient.
> > Please notify the sender immediately if it has unintentionally reached
> > you and do not read, disclose or use the content in any way.
> >
> > Stanbic can not assure that the integrity of this communication has been
> > maintained nor that it is free of errors, virus, interception or
> > interference.
> >
> >
> > ______________________________________________
>
> ----------------------------------------
> Content-Type: text/html; charset="iso-8859-1"; name="Attachment: 1"
> Content-Transfer-Encoding: 7bit
> Content-Description:
> ----------------------------------------
>
> ______________________________________________
>
> Disclaimer and confidentiality note
>
> Everything in this e-mail and any attachments relating to the official
> business of Standard Bank Investment Corporation (Stanbic) is proprietary
> to the company. It is confidential, legally privileged and protected by
> law.\ Stanbic does not own and endorse any other content. Views and
> opinions are those of the sender unless clearly stated as being that of
> Stanbic.
>
> The person addressed in the e-mail is the sole authorised recipient.
> Please notify the sender immediately if it has unintentionally reached you
> and do not read, disclose or use the content in any way.
>
> Stanbic can not assure that the integrity of this communication has been
> maintained nor that it is free of errors, virus, interception or
> interference.
>
>
> ______________________________________________

Content-Type: text/html; charset="iso-8859-1"; name="Attachment: 1"
Content-Transfer-Encoding: 7bit
Content-Description: 
----------------------------------------

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Jared Still
  INET: jkstill_at_cybcon.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).