curso oracle (3)

Backup and Recovery Considerations

Define requirements for a backup and recovery strategy

1. A thurough understanding of the business,operational, and technical requirements this will help develop an effective backup and recovery strategy that will protect the database from different types of failures and insure high availability, minmal downtime and complete data recovery.
2. Regularly test the backup and recovery strategy, because it ensures integrity of backups, the validity of the backup and recovery methods,and the reduction of problems before they occur in a production database.

Articulate the importance of management concurrence for the strategy

It ensures that there will always be an on-line duplicate (hot backup) of the database and also helps avoid a CLI (Career Limiting Incident) !!.

Identify the components of a disaster recovery plan

A disaster recovery plan consists of preparing for unlikely events, but depending on what part of the world you are, this could be more than likely. Some of them might be:

1. Natural Disasters(Floods,Hurricanes)
2. Blackouts
3. Hardware Failure
4. Key Personnel departure
5. Viruses
6. Theft

It is recommended that you make a Disaster Recovery Plan that contemplates the previously mentioned contigencies you might encounter. The recovery plan should at a minimum consider Data, Equipment, Personnel and Facilities . If you are knowledgeable in spanish: "Backups" might be of interest to you.

List Oracle Server features in the context of high availablilty

The Oracle backup and recovery functionality relies on many components of the Oracle server architecture, including memory strcuture, background processes, and the physical database structure. (The following objectives pretty much cover these features)

List the strengths of different database configurations for recoverability.

The two main configurations for running a database are ARCHIVELOG and NOARCHIVELOG. Assuming a recovery operation is needed the following scenarios could arise:

If the database is in ARCHIVELOG there are two possibilities:

1. Complete-Recovery : The database is restored and recovered through the applicaion of ALL redo information (this includes both the online and archived redo log files) since the last backup. This type of recovery is performed normally when one of more data files or control files are damaged, the damaged files are recovered using al the redo information generated since the last full backup.
2. Incomplete-Recovery: In this scenario the database is restored and recovered through the application of only SOME of the redo information generated since the last backup. This type of recovery is normally used when an on-line redo log file is lost due to hardware failure or a certain user requires to backup to a certain point in time,in simpler terms, an incomplete recovery only rollsback certain transactions without the need to involve ALL the redo-log files.

If the database is in NOARCHIVELOG:

You benefit from not having to save all the on-line redo log files, on heavily accesed systems this type of configuration alleviates disk-space usage,because in ARCHIVELOG every on-line redo log file is eventually backed-up; these archived redo-log files can easily fill up a WHOLE disk (10-12 GB) in a matter of hours. However the disadvantage of running this configuration is that in the event of a failure your only means of backup is by your last backup tape, Oracle cannot help in this case because it does not have a history of previous redo-log files , the ones that are ARCHIVED in ARCHIVELOG mode.

Discuss the importance of testing a backup and recovery plan

Testing the backup and recovery plan ensures:

1. That the backup and recovery methods are sound
2. Integrity of backups
3. Ensures that the backup and recovery strategy meets business needs.
4. It minimizes problems before they occur in a production environment.
5. It ensures that personnel can react quickly and effectively in case any errors arise,avoiding a crisis situation.

Oracle Recovery Structures and Processes.

List Oracle Processes, memory, and file structures relating to recovery

Online redo log group archiving is performed by either the Archive (ARCH) background process when automatic archiving is started or by a user process that issues SQL statements to archive the online redo log groups manually. The ARCH process archives a redo log group after the group becomes inactive and the log switch to the next online redo log group has completed.

At this point the record is created in the databases control file identifying the archived redo log file. The group of online redo log files being archived cannot be reused and written to by the LGWR process until the ARCH process has concluded and released a lock on the redo log files. This ARCH locking process guarentees that the LGWR process does not accidently overwrite online redo log file that needs to be archived. When the ARCH process has completed archiving the redo log files, a second record is written to the databases control file identifying the success of the archiving process.

The archive process uses the LOG_ARCHIVE_DEST parameter to specify the destination of the archived redo log files. This destination is usually a storage device separete from the Oracle database. The ARCH process can write out two copies of an online redo log group - the duplexing feature . The initialization parameter LOG_ARCHIVE_DUPLEX_n specifies the location of the archived redo log file. The parameter LOG_ARCHIVE_MIN_SUCCEED_DEST specifies the number of archive log destinations to which redo log group must be successfully arhcived. A missing archived redo log file renders all subsequent archived redo log files usless.

Identify the importance of checkpoints,redo logs, and archives

1. Checkpoint: A checkpoint synchronizes the write operations of the DBWR and LGRW processes.A checkpoint can occur at:
1. A log switch
2. The time specified in the LOG_CHECKPOINT_TIMEOUT parameter passed after the last checkpoint.
3. The number of OS blocks specified in the LOG_CHECKPOINT_INTERVAL parameter have been written since the last checkpoint.
4. A DBA manually uses the ALTER SYSTEM CHECKPOINT command.
5. A tablespace is taken offline
6. An online backup is initiated
7. During an instance shutdown when the NORMAL IMMEDIATE, or TRANSACTIONAL option is specified.
2. (On-line)Redo Logs:Record all changes made to the database and are used to recover the database at a desired point in time. Redo Logs are stored in groups (named redo log groups ), these groups are composed of copies of the same file, however the creation of groups ensures high-availablity and throughput for the database, at least two redo log groups should exist with each group having the same size and the same number of members(copies).
3. Archives: Are created each time an redo log group becomes inactive and the log switch to the next redo log group has completed. As mentioned previously these archived logs allow full recoverability without the need to go back to tape, Oracle can access these archived log files and update the database. The creation of these archived log files is recorded in the database control file.

Multiplex controlfiles and redo log files.

To multiplex the controlfiles:

1. Once the database is shutdown, it is necessary to copy the control files via the OS to the desired (mirrored) locations.
2. Modify the init.ora parameter CONTROL_FILES and indicate where the new mirrored (multiplexed) control-file can can be accessed.

To Multiplex redo log files :

The multiplexing is specified while the database is in mount and is done through the alter database command , the following creates a new log group.

 alter database
>add logfile group 5
> ('/u02/app/oradata/OSMOSIS/log_1c.dbf',
>  /u05/app/oradata/OSMOSIS/log_2c.dbf') size 5M;

To add a new log file to an existing group:

 alter database
>add logfile member '/u05/app/oradata/OSMOSIS/log_3c.dbf'
>to group 3;

When adding a file to a redo log group there is no need to specify the size, because the group has already been indicated , besides all the redo log files in the group must be of the same size.

List the types of failures.

The following are types of failures:

1. User Process Failure : When an Oracle user process ends abnormally, the PMON process takes care of this failure.
2. Instance Failure : When the Oracle instance fails. The SMON process performs instance recovery at startup using the online redo log files.
3. Media Failure : When files needed by the database are no longer accessible due to a hard disk crash, controller failures,etc.

Describe the structures for instance and media recovery

Describe the deferred transaction recovery concept

Oracle Backup and Recovery Configuration

Identify recovery implications of operating in NOARCHIVE mode.

Describe the differences between ARCHIVELOG and NOARCHIVELOG modes.

Configure the database for ARCHIVELOG and automatic archiving

Use init.ora to configure multiple destinations for archived log files and multiple archive processes.

Perform manual archive of logs.

Physical Backup without Oracle Recovery Manager

Describe the recovery implications of closed and opened database backups.

Perform closed and opened database backups.

Identify the backup implications of the logging and nologging options

Identify the different types of control file backups

Discuss backup issues associated with the read-only tablespaces.

List the data dictonary views useful for backup operations.

Complete Recovery without Recovery Manager

In NOARCHIVELOG and ARCHIVELOG mode: Note the implications of a media failure.

In NOARCHIVELOG and ARCHIVELOG mode: Recover a database in different situations.

In NOARCHIVELOG and ARCHIVELOG mode: Restore files to a different location if media failure occurs

List the dictionary views required to recover database after a media failure

Incomplete Recovery with Archiving

Determine when to use an incomplete recovery to recover the system

Perform an incomplete database recovery

Recover after losing current and inactive nonarchive redo log files

Oracle Export and Import Utilities

Use the Export utility to create a complete logical backup of a database object

Use the Export utility to create an incremental backup of a database object

Invoke direct-path method export

Use the import utility to recover a database object.

Perform a Tablespace point-in-time-recovery (TSPITR) with or without the transporatable tablespace feature.

Additional Recovery Issues

List the methods for minimizing downtime:perform parallel recovery, start recovering a database with missing data files, re-create lost temporary or index tablespaces.

Reconstruct lost or damaged controlfiles.

List recovery issues associated with read-only tablespaces.

Oracle Utilities Troublshooting

Use log and trace files to diagnose backup and recovery problems

Detect corruptions by using different methods

Detect and mark corrupted blocks by using DBMS_REPAIR package

Use DBVERIFY utility

Use the LogMiner utility to analyze redo log files to recover by undoing changes.

Oracle Recovery Manager

List the capabilties of Oracle Recovery Manager (RMAN)

Describe the components of RMAN

Connect to RMAN without a recovery catalog

Start up and shutdown a target database using RMAN

Oracle Recovery Manager

List the capabilties of Oracle Recovery Manager (RMAN)

Describe the components of RMAN

Connect to RMAN without a recovery catalog

Start up and shutdown a target database using RMAN

Oracle Recovery Catalog Creation and Maintanence

Describe the considerations for using a recovery catalog

Describe the components of a recovery catalog

Create a recovery catalog

Maintain the recovery catalog using RMAN commands

Query the recovery catalog to generate reports and lists

Create,store,and run scripts.

Backups using RMAN

Describe backup concepts using RMAN

Describe types of RMAN backups

Perform incremental and cumulative backups

Tune backup operations

View information from the data dictonary

Restoration and Recovery using RMAN

Restore and Recovery considerations using RMAN

Restore a Database in NOARCHIVELOG mode

Restore and recover a Tablespace

Restore and recover a Datafile

Incomplete recover using RMAN

Oracle Standby Database

Explain the use of a standby database

Configure initialization parameters

Create,maintain and activate a Standby database

Describe Managed Recovery Mode

Set a standby database in read-only mode

Describe the process of propagating structural changes to a standby database

Describe the impact of nologging actions on the primary database