RE: not including temp neither undo tablespace in full backup

>> Without undo tablespace, there is a very high potential for data corruption
>> Oracle support would let you set couple of parameters to open the database with corruption,

Yup! Have no idea how one would think that if the failure is in the RBS/UNOD datafile that one could recover *easily* without it. You would have to find and offline the corrupt rbs/undo segments. A crash when using session is using RBS/UNDO requires those tablespaces/datafiles (for recovery).

|| I think RMAN by default does not backup temp tablespace. Right...well temp ts using TEMPFILES.

|| How do I ask RMAN to backup temp datafiles in "backup database" command? As far as I know you can not.
Doesn't matter anyways. I learned after my own testing that even if you have or leave a good tempfile on the OS, Oracle/RMAN will not use it...will ignore it.

Not on the RESTORE syntax but on the RECOVER syntax in RMAN (and think in SQL> too!?) I have notes on this, but basically if;
You use tempfiles
and you use RECOVER syntax
that "RECOVER" is the trigger to Oracle to now ignore the existence of the tempfile. I think it is still be listed in the dictionary, but not used. HAVE TO add it back manually...that is why you see the tempfile syntax in crontrolfile backups to trace now.

hth

Chris Marquez
Oracle DBA

-----Original Message-----
From: oracle-l-bounce_at_freelists.org on behalf of Riyaj Shamsudeen Sent: Wed 10/12/2005 2:47 PM
To: Juan Carlos Reyes Pacheco
Cc: oracle list
Subject: Re: not including temp neither undo tablespace in full backup  

>>Riyaj You need redo files, but not undo neither temp tablespaces.

This is a dangerous and very misleading statement to make. Hopefully, newbies will read the full thread before accepting your advice.

Just because one test case is successful, does not mean that the theory is correct. As Jonathan Lewis would say "It takes only one test case to disprove a theory". Without undo tablespace, there is a very high potential for data corruption and instance will shutdown during SMON's instance recovery. In fact, Oracle support would let you set couple of parameters to open the database with corruption, if you don't have undo tablespace backup. But right after that you must rebuild your database if you want further support.

Database can not rollback the outstanding transactions without rollback segments during instance recovery. Consistent view of the data can not be recreated either. Expect corruption all around the database in a very active database.

Not satisfied? Read Tom Kyte's thread thoroughly:

do not, repeat, do not take this as a way to get out of backing up UNDO, just consider UNDO as important as your own tables. Always back it up. ALWAYS.

http://asktom.oracle.com/pls/ask/f?p=4950:8:12294222471961948103::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:5669213349582

Miniurl, in case, you can't access the above link:

http://tinyurl.com/97hq3

You want test case, try this:

Session #1:

   Create a table with say million rows.    Update say 25% of the table.
   Don't commit.

Session #2:

   Shutdown immediate;
   Take a backup excluding undo tablespace.    Remove data files and undo files..
   Restore..Startup.. Check alert log (Instance should fail when smon tries to do rollback portion of the instance recovery)..If not, just try to do count(*) from the table created in session #1..

You will then agree that undo tablespace is absolutely needed to be backed up!! Do NOT, I repeat, do NOT try this in any database, that you can not afford to lose!!

Thanks  

Riyaj "Re-yas" Shamsudeen
Certified Oracle DBA (ver 7.0 - 9i)
Allocation & Assortment planning systems JCPenney

Juan Carlos Reyes Pacheco wrote:

>Riyaj You need redo files, but not undo neither temp tablespaces.
>A few times I lose them and recreated successfully.
>
>You will need undo, if you abort your database, otherwise you don't need.
>(obviously I'm not talking in rac environment, I don't have idea about that)
>
>This is not a theory I tested it agains my will previously.
>:)
>
>
>

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