Re: NOLOGGING Option on Create Table

In article <3cb045d8.1516190_at_news.online.de>, marc_at_marcblum.de says...
>
>On 6 Apr 2002 11:17:49 -0800, Thomas Kyte <tkyte_at_oracle.com> wrote:
>
>>I see people say things like "and *I* will never need to recover them". That is
>>wrong. You will need to recover that many times in your lifecycle.
>>
>
>Hi Tom,
>
>I would be interested in your opinion concerning data warehousing /
>DSS / Analytic Databases which are used for querying only and say
>completely rebuild each night. I that case I tend to avoid archiving,
>logging etc. If the database crashes, well, users will be unhappy for
>not being able to work on it today, but 'til tomorrow it's fixed and
>NO data is lost.
>

depends on the level of unhappiness I suppose.

unhappy enough to throw tomatoes and rocks at me -- I'll be more proactive in making things recoverable.

unhappy enough cause they lose $200,000 an hour in lost worker productivity -- same as above

I might not run that database in archivelog mode -- but I might at least transport the tablespaces off after a build or make sure they are on the best raid (some protective level here) device I could get...

special case this data warehouse -- agreed. In this posters case however -- a system with a queue that generates lots of log -- they need the protection. In a datawarehouse, heck you could be in archive log mode and just choose to do unrecoverable operations on things more easily rebulit (eg: suppose you were a health care instiitution -- there is this "hipaa" (Healthcare Insurance Portability and Accountability Act) requirement for auditing coming along for them. Loss of the audit trail on all queries/questions asked would be a violation punishable by a large fine or jail time, point being that even in a data warehouse, recoverability might be a serious issue).

So, archivelog mode for a data warehouse -- can make great sense with the judicious use of unrecoverable operations and a combiniation of hot backup or transportable tablespaces (for read only data) to recover with.

>
>regards
>Marc Blum
>mailto:marc_at_marcblum.de
>http://www.marcblum.de

--
Thomas Kyte (tkyte@us.oracle.com)             http://asktom.oracle.com/ 
Expert one on one Oracle, programming techniques and solutions for Oracle.
http://www.amazon.com/exec/obidos/ASIN/1861004826/  
Opinions are mine and do not necessarily reflect those of Oracle Corp