Re: question concerning backup, archive logs and recovery

"Jose Nicolau" <jose.nicolau_at_clix.pt> wrote in message news:3ACA8BD1.3AA758B7_at_clix.pt...
> "Howard J. Rogers" wrote:
>
> > "Jose Nicolau" <jose.nicolau_at_clix.pt> wrote in message
> > news:3AC72298.FA19DE83_at_clix.pt...
> > > "Howard J. Rogers" wrote:
> > >
> > > > I'll keep it short and sweet: No.
> > > >
> > > > And this a cracking demonstration of why housing two separate
 applications
> > > > within the one database is a really, really bad idea.
> > > >
> > >
> > > I desagree.
> > > You can have as many applications as you want with all data in one
 database.
> > > I said 'you can', not 'you should'...
> >
> > No argument so far (but hold your breath). The subjunctive is very
> > important in this discussion, however.
> >
> > > If one application needs some parameter in init.ora that 'conflits'
 with
 the
> > > others applications, ok, it's a good reason to chose another database
 for
 that
> > > application.
> >
> > Ah, so you actually agree with me then. Good. (Incidentally,
> > log_archive_start *is* an init.ora parameter).
> >
> > > More: O9i is intended to support, no only diferent applications, but
 from
> > > diferent companies.
> >
> > Nice. Glad you know all about 9i, which is vapourware currently, and
> > irrelevant to the discussion. If Unix ever got to the point of working
 as
> > easily out of the box as Windows, I'd switch in a minute... but it isn't
> > right now, so I won't. And 8i right now is not intended to support
 multiple
> > applications in the one database, and so I won't force it to do so.
> >
> > As for 9i, until it invents memory structures which mean you can access
 the
> > one application without ANY impact on the second, then I will beleieve
 that
> > support for different block sizes and the rest are clever cludges to
 satisfy
> > the mass of loonies out there trying this stuff than a real addressing
 of
> > the issues.
> >
> > Silly me... that functionality is *already* available -different
 Instances,
> > different databases.
> >
> > >
> > > This reason, that we are talking about, is not a good example to
 change
> > > database.
> > >
> >
> > Excuse me? One application doesn't need redo, but the other one does?
 And
> > that doesn't qualify, according to you? You're stark, staring bonkers
 if
> >
>
> ...if one application doesn't need redo, just creat those tables without
> loging...

Please don't be silly. A table created 'nologging' still generates redo for all normal inserts, updates and deletes. Only certain classes of DML have their redo generation suppressed by that keyword (direct SQL Loads, for example, or direct inserts), and some rare cases of DDL, too (create index ... nologging).

So, you are posting totally incorrect information, based on a slim understanding of how Oracle actually works.

Sorry to say so, but it is true.

HJR
>
> > you believe that. The redo subsystem is the absolute key to good
> > performance. Knacker that, and you knacker the application. And ARCH
> > churning away when it doesn't need to sounds like a good case of
 application
> > knackering to me.
> >
> > Regards
> > HJR

[Snip] Received on Wed Apr 04 2001 - 05:50:52 CDT