Files in Support of Backup and Recovery Operations - Oracle RMAN for Absolute Beginners - page 44

Be aware that if redo isn't logged for a table or index, and you have a media failure before the object is backed up,
then you can't recover the data; you receive an ORA-01578 error, indicating that there is logical corruption of the data.

■ you can also override the tablespace level of logging at the object level. For example, even if a tablespace is
specified as NOLOGGING , you can create a table with the LOGGING clause.

Note

Changing a Tablespace's Write Mode
In environments such as data warehouses, you may need to load data into tables and then never modify the data
again. To enforce that no objects in a tablespace can be modified, you can alter the tablespace to be read-only. To do
this, use the ALTER TABLESPACE statement:

SQL> alter tablespace inv_mgmt_rep read only;

One advantage of a read-only tablespace is that you only have to back it up once. You should be able to restore
the data files from a read-only tablespace no matter how long ago the backup was made.
If you need to modify the tablespace out of read-only mode, you do so as follows:

SQL> alter tablespace inv_mgmt_rep read write;

Make sure you reenable backups of a tablespace after you place it in read/write mode.

■ you can't make a tablespace that contains active rollback segments read-only. For this reason, the SYSTEM
tablespace can't be made read-only, because it contains the SYSTEM rollback segment.

Note

Be aware that in Oracle 11g and above, you can modify individual tables to be read-only. This allows you to
control the read-only at a much more granular level (than at the tablespace level); for example,

SQL> alter table my_tab read only;

While in read-only mode, you can't issue any insert , update , or delete statements against the table. Making
individual tables read/write can be advantageous when you're doing maintenance (such as a data migration) and you
want to ensure that users don't update the data.
This example modifies a table back to read/write mode:

SQL> alter table my_tab read write;

Dropping a Tablespace
If you have a tablespace that is unused, it's best to drop it so it doesn't clutter your database, consume unnecessary
resources, and potentially confuse DBAs who aren't familiar with the database. Before dropping a tablespace, it's a
good practice to first take it offline:

SQL> alter tablespace inv_data offline;