Re: Transaction Gradually Slows to a crawl! (please help)

"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:<3ed6737d$0$1028$afc38c87_at_news.optusnet.com.au>...
> "Ryan Gaffuri" <rgaffuri_at_cox.net> wrote in message
> news:1efdad5b.0305291202.657dbf87_at_posting.google.com...
> > Sybrand Bakker <gooiditweg_at_sybrandb.demon.nl> wrote in message
> news:<pdf8dv0tnk92h7su850a04ij2stmugknh0_at_4ax.com>...
> > > On Wed, 28 May 2003 02:16:44 GMT, "Ryan" <rgaffuri_at_cox.net> wrote:
> > >
> > > >how do you disable redo logs? you can generate no redo? really? i have
> a
> > > >staging database also.
> > >
> > >
> > > Yes, you can. But the redo log mechanism still will be called, it only
> > > won't write. And of course: you render your database in an UNSUPPORTED
> > > state.
> > > Such act is only for the brave/stupid (cross all that apply), and is
> > > usually considered only by people who don't want cures but just
> > > figthing symptoms.
> > >
> > >
> > > Sybrand Bakker, Senior Oracle DBA
> > >
> > > To reply remove -verwijderdit from my e-mail address
> >
> > if I have an instance failure with this turned off, what happens on
> startup?
>
> Your database crashes. And it can never be re-started. An instance failure
> requires the application of redo from the current redo log. With
> _disable_logging=TRUE, then that redo won't be available, because it was
> never written to the current log in the first place. Therefore, you can't do
> instance recovery. Therefore, the database is toast. (I found this out the
> hard way once having demonstrated what _disable_logging does, finished the
> demo, changed my init.ora back to remove the parameter, and then -suffering
> a complete brainstorm- issued a startup force command to get the new
> init.ora re-read. Startup force does a shutdown abort... I had just crashed
> the instance. That wasn't just the end of the demo, but the end of that
> week's teacher's account!!).
>
> All you can do in such a situation is to delete every single log file, data
> file and control file, and restore the lot from the closed, consistent
> backup you took before invoking the _disable_logging=true option.
>
> And if you don't have a closed, whole database backup, you're going to be in
> deep, deep doo-doo.
>
> (I'm assuming that you'd have switched off archiving if you're going for
> _disable_logging. But if you've got a hot backup and some archives, you'd
> probably be able to get the database back to some sort of usable state using
> that. It would still be very messy, though, and very much an incomplete
> recovery).
>
> Regards
> HJR
I would probably just run a script to re-create the database and then import the transportable tablespaces that we keep copies of. Either that or keep a backup instance, that is just the base database with the system,tools, etc... tablespaces. then import tablespaces to that. We can do that in 30 minutes. Its just the I/O to copy the tablespaces over.

This is a throwable instance. Its strictly used for staging data, srubbing it and then shipping off the tablespace to the production system.

What kind of performance improvement can we get from this? Im wondering if any tried it and if its worth the hassle? Received on Fri May 30 2003 - 09:54:21 CDT