Oracle Database Backup and Recovery Essential
Due to expanding size of database and it becomes bigger and larger, recovering time duration is also extending and it takes hours and hours. Such high downtime is unacceptable in any 24x7x365 round the clock running environment. Accordingly, it is essential for the database administration to evaluate and apply the right unit of recovery, such that overall downtime is minimized.
Oracle allows recovery at different levels like database level, tablespace level, data file level, schema level, segment level and last is block level. Off course block level recovery only possible in RMAN a recovery manager tool. Each level has varying effects on database availability and mean time to recovery MTTR. For example, the database has to be shut down in order to perform database recovery, causing zero availability during database recovery. However, the database can be open and only the specific tablespace or datafile recovery respectively. Of course, the SYSTEM tablespace or SYSAUX tablespace with active rollback segments are exceptions and the entire database has to be closed while recovery these types tablespaces. Depending on the outage situation, each level can expedite or delay the recovery process, thus affecting MTTR. For instance, during database recovery, you cannot have multiple sessions applying recovery in parallel, but you have parallel recovery threads in the same session. In the case of tablespace or data file recovery; you can have multiple sessions with multiple recovery threads for each session, working in parallel on different tablespace or data files.
As a general rule of thumb, however, it should be noted that the lower the level of recovery, the higher the availability, because lower recovery levels such as for tablespace and data file recovery allow portions of the database to be open and available for users. Accordingly in any outage situation, always consider data file recovery first. If that is not appropriate, then consider tablespace recovery, and if that is not appropriate either, then try database level recovery as the last resort. Also, make it a point not to violate referential integrity or point in time consistency across segments, while attempting a lower unit of recovery. This may cause logical corruption with database. Avoiding such critical situations requires robust knowledge of the application model from the DBA.
Always check alert log after finishing recovery process. Using this idea, you will be able to analysis any corruption or any critical database level or bug related error was throwing during recovery process. If you are monitoring constantly alert file during database recovery process then it is best idea but after finishing task, you should need to check again for further analysis.