your database is in archivelog mode? So if your redo log is full it will generate a archivelog file. You should backup them to. If the archive log destination is full it will generate a archiver error. As long this not occur your redologs will switch from the first to the last and will then begin from the first.
yes my database is in an archivelog mode, my concern is what is happening when we issue the alter tablespace tablespace_name begin backup command
and about the redo logs, you have to backup theme as well because during the backup period, a switch logfile may have occurred so you need to backup theme too
>it tills oracle to not update the underlying data files to the
That is Incorrect. Oracle does keep updating the underlying datafiles when a tablespace is in BEGIN BACKUP mode.
You DO need to backup all the archivelogs generated during the backup PLUS at least the first archivelog after the END BACKUP. You will need these Archivelogs to RECOVER the database if you RESTORE it.
Hemant K Chitale
Three things happen when you put a tablespace in hot backup mode:
1. A checkpoint is issued, so that dirty blocks belonging to that tablespace are flushed to disk
2. The header of the datafiles associated with the tablespace are locked from further update by CKPT.
3. The first insert/update/delete that affects a data block that is part of the tablespace being backed up, after the 'begin backup' command is issued, causes the entire block to be written to the online redo logs. Second and subsequent changes generate the same amount as redo as normal, though.
That's it. As Hemant mentions, the really important bit is number 2 in that list: whilst the header of the datafile(s) is locked, the datafiles themselves are not, and are written to as much as they always are. The idea that somehow the datafiles are not written to and that the redo logs are the only place that stuff is written to during the backup is completely and utterly wrong. CKPT is not allowed to write to the header, because that way, we know the earliest "age" of the datafile copy when it went into backup mode, and thus know the point from which redo needs to be applied during a recovery. But DBWR writes to the rest of the datafile perfectly normally.
Number 3 is also important, because it's why we don't leave tablespaces in hot backup mode more than we can help: the amount of redo generated increases because we need a 'starter image' for any block that's modified during the backup.