Re: backup without archivelog mode

Let's not.

You can carry on what-iffing and making exceptions here, there and everywhere. It really is very tedious. If you can't see the difference between having to type
insert into emp(7274,'Smith','Clerk',7382,1700.95,120.75,10)

...where you have to resupply every piece of information, and having to type

create index blah on emp(ename);

...where the source data for the index is readily available without user specification, then I'm not pursuing the subject with you, because you are just being awkward.

Yes, anyone can keep a record on a piece of paper about the insert into EMP. So yes, it's not just in their head. But do they have to re-key the data? Yes. Does anyone have to re-key the data inserted by SQL Loader? Or by an index creation? No. So there you go, yet again, seizing on a specific set of words and totally missing the actual point being made.

You go ahead an play such games if you want. I really can't be bothered anymore.

In case anyone missed it, the original point was that archivelog guarantees recoverability of transactions, not mandates a particular backup strategy.

HJR

--
----------------------------------------------
Resources for Oracle: http://www.hjrdba.com
===============================


"Sean M" <smckeownNO_at_BACKSIESearthlink.net> wrote in message
news:3C9D25A7.D33D010F_at_BACKSIESearthlink.net...
> "Howard J. Rogers" wrote:


> >

> > "Sean M" <smckeownNO_at_BACKSIESearthlink.net> wrote in message

> >

> > > Now who's nitpicking (are not unrecoverable transactions, by

definition,


> > > unrecoverable?)?  But fine, I'll play along.  If "by some other means"

> > > you're referring to repeating the original operation (direct

SQL*Loader


> > > jobs, direct load inserts, etc.), then I agree, you can "recover" it.

> > > But that's true of *any* transaction, logging or not.  Any transaction

> > > is "recoverable" under your definition by simply doing it over again.

> > > The trick is knowing/remebering what you did.

> > >

> >

> > But the point is that for a regular piece of DML, you would indeed have

to


> > remember it to reperform it.  The updated data doesn't exist anywhere

else


> > other than in the table.

>
> No.  Just because a peice of DML was logged doesn't mean you don't have
> a record of it elsewhere.  To play off your example, just think of a
> *non*-direct SQL*Loader job.  Or master -> slave replication.
>


> > Hence redo is needed to reperform it.  But Direct

> > SQL Loads don't need to be remembered at all.  The text file which was

the


> > source of the load still exists (we presume: at least, it's bad practice

to


> > delete it until a new backup of the relevant tablespace has been

performed).


> > All you'd need to do is re-perform the load.

>
> Ah, but therein lies the crux yes?  As I said, that's the trick.  But it
> has nothing to do with logging vs. nologging.  In either type of DML,
> nothing is stopping you from 1) keeping enough information around
> through "some other means" to recreate the lost information or 2)
> throwing caution to the wind and destroying the source immediately after
> the operation.
>


> > So no, not all transactions are "recoverable" under my definition.

Regular


> > DML is only recoverable through redo, since the source of the

transaction is


> > only in your head.  Transactions which respect the nologging keyword

don't


> > need redo, because the source data is available in tangible form

elsewhere.
>
> Plenty of assumptions there.  Again, regular DML needn't only be in
> someone's head, and the source nologging DML can certainly be lost
> before the next backup of the affected datafiles.
>
> As to the rest of your post, let's take it offline.
>
> Regards,
> Sean