| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
Home -> Community -> Usenet -> c.d.o.server -> Re: UNDOTBS + ARCHIVE LOGS
chris_f_clark wrote:
>
> I am a 'Newbie' to Oracle (we have 9i) and have been doing a lot of
> reading about these two features but still can't get a clear idea
> about them.
What documentation have you been reading. We may be able to recommend alternates or secondary choices.
> My understanding is that UNDOTBS is automatic undo segment generation
> that ORACLE now recommends and REDOLOGGING is the manual rollback
> segment option. If ARCHIVELOGGING is set on, archvive log files are
> created when the REDO LOGFILES are filled up. Does this still happen
> if you are using the automatic UNDOTBS way? or does it mean that
> ARCHIVELOGGING is only possible when you have selected the manual
> option. Therefore if this is correct this would mean using the
> automatic UNDOTBS option would only cater for instance recovery and
> not allow a full media restore.
> In essence my question is, can you have the automatic UNDOTBS and also
> have ARCHIVELOGGING?
UNDO and ROLLBACK are equivalent. Undo is the new, automatic mechanism. Rollback is the old, manual mechanism. Both are there to be able to 'rewind' an active transaction. Both are 'inside' the database, the UNDO being kept in the 'UNDO Tablespace' whereas the Rollback is kept in 'Rollback Segments' that can be located in most other tablespaces. (UNDO is automatic and generally preferred.)
A transaction will ALSO be logged, unless you go through some hoops to avoid logging. The log will be kept in the REDO Log file. The Redo log is considered 'external but related' to the database. The original purpose of the REDO was to replay and/or rewind all 'current' transactions in case of an instance crash or computer, although the information is not available for all sorts of other neat purposes (such as streaming replication). The redo is kept in a circular buffer consisting of at least 2 files, each of which is replicated.
Redo is the primary mechanism for instance recovery, not undo
Finally, Archive logging is simply 'tucking away the *redo* logs for safe keeping'. This allows replaying older transactions in case of media failure. However, with the other neat things that are available using the log miner, archives of the redo logs can now have a number of secondary uses.
In general, it is not advised to blindly turn off logging. There are reasons for using no-logging, but an understanding of the reasons and implications is encouraged. Received on Sat Jan 17 2004 - 19:28:46 CST
![]() |
![]() |