Re: urgent recovery question

A possible scenario for loading tabledata with nologging is to use a helper database (noarchivelog), do the load and then use the transportable tablespace trick to attach the tablespace to your operational database. If the helper database is on the same host you could leave the datafiles where they are (ie no copy) and just change ownership on database level though TTS.
This way your database of most concern can still use the FORCE LOGGING mode to override NOLOGGING set on segment or tabespace level.

Regards,
Andre

>
> On 05/11/2006 09:20:28 PM, Mark Brinsmead wrote:
>> Backing up immediately after a NOLOGGING operation may well be your best
>> bet. (Aside, perhaps, from not doing nologging operations in the first
>> place.) But the backup need not be a FULL backup; an incremental is
>> just as
>> good. Or, at least, so say the doc's.
>
> Mark, I like your remark about "not doing nologing operations".
> Unfortunately
> many people think that "nologging" is the best thing after the sliced
> bread.
> It does speed up things significantly. Also, as many a DBA on this list
> could
> tell you is messed up countless recoveries, both logical and physical
> standby
> databases and database clones.
> I recommend doing nologging operations only on derived things like
> indexes,
> aggregate tables or materialized views. If you use nologging operation to
> load
> data file into database, make sure that the table you load it into is
> immediately
> processed and the data is transferred into the proper tables with logging.
> Do not
> discard the original data file until the data is processed.
> --
> Mladen Gogala
> http://www.mgogala.com
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l