Noarchivelog Mode of Database Operation

• In noarchivelog mode, Oracle will overwrite the filled online redo logs, instead of archiving (saving)the online redo logs.
• In this mode, you’re protected only from instance failures, such as those caused by a power failure, for example, but not from a media failure. Thus, if there is a media failure, such as a damaged disk drive, the changes that were overwritten are gone forever, and the database won’t be able to access those data modifications to recover thedatabase up to the current point in time.
• The transactions made since the last backup are lost forever, and you can restore the database only to the point of the last backup you made.
  
  

If you are running your database in noarchivelog mode and you happen to lose a datafile, for example, you follow these steps to get back to work again:

• If the instance isn’t already shut down, first shut it down.
• Restore the entire database (datafiles and control files) from the backups.
• Restart the database by using the startup (open mode) command.

Users lose any data that was changed or newly entered in the database since you took the backup that was just restored. You can enter the data if you have a source, or you’re going to have a data loss situation.

If you are running a production database—or if you want to make sure that all the data changes made to any database, for that matter, are always protected—you must operate your database in archivelog mode. Only a database running in archivelog mode can recover from both instance and media failures. You can’t perform a media recovery on a database running in noarchivelog mode.

• If you’re running the database in noarchivelog mode, remember that you can make a whole-database backup only after first shutting the database down. You can’t make any online tablespace backups in such a database.
• A database in noarchivelog mode also can’t use the tablespace point-in-time recovery technique. Make sure you take frequent whole-database backups if an important database is running in noarchivelog mode for some reason.

Flashback Technology


Traditionally, restoring backed-up datafiles and recovering the database with the help of archived redo logs was the only way you could rewind the database to a previous point in time or view older data. Oracle’s flashback technology offers new techniques that let you recover from several types of errors without ever having to restore backup files. The key idea behind the flashback technology is to improve database availability while you’re fixing logical data errors. While you’re correcting the logical data errors in one or more errors, all the other database objects continue to be available to the users unhindered. Flashback technology actually consists of a half dozen specific features, most but not all of which rely on the use of undo data to undo the effect of logical errors:

Oracle flashback query (uses undo data): This feature lets you view results from a past period in time. You can choose to use this query to retrieve lost or wrongly deleted data.
Oracle flashback version query (uses undo data): This feature lets you view all versions of a table’s rows during a specific interval. You can use this feature for retrieving old data as
well as for auditing purposes.
Oracle flashback transaction query (uses undo data): This feature enables you to view all the changes made by one or more transactions during a specified period of time.
Oracle flashback transaction backout (uses undo data): This new Oracle Database 11g feature lets you back out unwanted transactions by using compensating transactions.
The Oracle flashback table (uses undo data): This feature lets you recover a table (online) to a previous point in time. You can recover a table or a set of tables to a past point in time
by using the contents of the undo tablespace. The database can remain online during this time, thus enhancing its availability.

Oracle flashback drop feature (uses the recycle bin): This relies on the concept of a recycle bin and lets you restore a dropped table. When you accidentally drop a table with the drop
table statement, information about the purged table is saved in the recycle bin (which is actually a data dictionary table) under a system-assigned name. Actually, the table’s contents
remain intact and in place, but the data dictionary marks the table as having been dropped. You can then “undrop” the table at a later time by using the flashback table
... to before drop statement, which recovers the dropped object from the recycle bin. The flashback table feature relies entirely on the recycle bin concept.

----- Reference : RMAN Recipes by Arun Nanda