Backup with Oracle

Use

You must always have a recent and consistent copy of Oracle database data that can be used to recover the database in the event of failure involving data loss.

For more information about backup options, including a description of integration with the Recovery Manager (RMAN) and of support for incremental backups, see BR*Tools for Oracle Database Administration

The Oracle database management system (DBMS) supports the following types of backup:

You can perform offline or online backups, as follows:

• Offline

  During an offline backup the whole database, or parts of it, are unavailable for use. Offline backups are normally done at the database level. Offline backups at the tablespace or data file level are not advisable in an integrated environment like the SAP system, because the application modules require access to data in several tablespaces. If one of the main tablespaces is unavailable, most application modules cannot continue.

  For an offline backup at the database level, you must close the database. Then you should do a full backup, that is, you must back up all data files, all online redo log files, and at least one control file.

  The advantage of such a full backup is consistency. This backup could be restored and the database could then be opened without needing to do a recovery.

  The major disadvantage is that the database cannot be used while the backup is running.

  BRBACKUP (the SAP backup tool) supports offline backups at all levels.

  

  Oracle Offline Backup with BRBACKUP

• Online

  An online backup is more appropriate for large databases. An online backup can be a complete, a partial, or an incremental backup. The backup includes all or some of the data files and a control file. For the backup to be usable, the offline redo log files generated while the backup was done also need to be available.

  The advantage is that the database is available for normal use while the backup is taken. Online backup has the following disadvantages:

  • Performance deteriorates

    If you do not use Oracle Recovery Manager (RMAN), database performance worsens because more redo log information is generated while the backup is going on. Therefore, it is best to do online backups when system load is low. For example, an online backup running alongside a background job with batch input causes the runtime of the background job to increase.

  • Backed up data files are inconsistent without the redo log files

    If used for a recovery, the online backup must be supplemented with the redo log files archived during the backup. To safely archive the last online redo log file from the backup, perform a redo log switch immediately after the backup. An online backup done with SAP's BRBACKUP tool does this automatically.

    You could perform an online backup by first running BRBACKUP to save data files and then running BRARCHIVE immediately afterwards, to save the archived redo log files belonging to the backup.

  

  Oracle Online Backup with BRBACKUP

Process

1. You decide what kind of backups to do, as follows:

   • Whether to use offline or online backups or both

     Only offline backups cause system downtime. Use online backup if downtime cannot be tolerated or if your database is large and would take too long to back up offline.

   • What level of backup to use

     If you have decided that a complete backup takes too long, use backups at the tablespace level (or use incremental backups). For example, if the database is comprised of 20 tablespaces, back up four of them every night Monday to Friday (that is, equivalent to one full backup a week). Then the worst case would be that a tablespace damaged on Sunday would have to be recovered from last Monday's backup.

2. You consider the frequency of backups, if possible increasing the frequency.

   More frequent backups lead to shorter recovery time and therefore shorter downtime. A good compromise is to make:

   • Less frequent full backups - for example, one full backup on Sunday

   • More frequent partial or incremental backups - for example, back up one third of all tablespaces Monday, Tuesday, Wednesday and again Thursday, Friday, Saturday

   Then the worst case is a backup that is three days old. The following diagram shows an example of this approach:

   

   Oracle: Example of Partial Backup Schedule

3. You consider parallel online or offline backups to increase throughput.

   For example, if partial online backups of tablespaces are done (see example above), you can also schedule the backups of several (groups of) tablespaces to run in parallel, utilizing multiple devices. BRBACKUP supports parallel backups.

4. You adjust the backup frequency by performing tests.

   If possible, perform a complete database backup every day. If this is not possible due to the size of the database or the time required, try to perform complete database backups every two or three days. At the minimum, perform a complete database backup once a week.

   Always make sure that you have at least three generations of backups.

5. You consider backing up to disk first if you have enough disk space.

   A disk backup is usually faster than a tape backup because disk devices tend to be faster. You can then copy your backups from disk to tape without incurring downtime. If possible, retain the disk backup copy since a restore from disk is faster than from tape. Note that this assumes that the disks are not mirrored. Other options are available with mirrored disks (see below).

6. You consider using mirrored disks to reduce the downtime for an offline backup.

7. You consider using hardware compression with backup.

   This cuts down backup time by as much as 50 %. If the backup must go to tape directly and be done online, consider using multiple tape drives for parallel backups to shorten backup time.

8. You assess your tape devices.

   Think about what kind of tape devices you are using for backing up your database since this determines the downtime in the case of offline backups. To give you some idea of this, the capacity of tapes currently ranges from 20 to 200 GB and the speed of data transfer ranges from 10 to 100 GB per hour.

9. You verify that your backup tapes are readable for a restore.

   Regularly verify backups to make sure that the files from the backup are readable and consistent. You can do this with the Oracle tools DBVERIFY or RMAN. We recommend you to verify backups weekly or at least once in the backup cycle.

   A good option is to use a separate system from the live production system. To perform a test, you might want to restore the data files of the system tablespace, rollback segment tablespace, temporary tablespace and a tablespace of your choice, plus control files, online redo log files, and archived redo log files. Mount the database, take offline all data files that were not restored, recover the database, and then open it. If successful, this is proof that the restored files can be used.

10. If you use the Oracle backup tool RMAN, you consider using incremental backups

    Incremental backups are only possible if you use RMAN. They can help you to dramatically reduce the size of backups. You should start with a level 0 incremental backup, because this backs up all data blocks of the data files. Then you can use incremental backups with a level greater than 0 to back up only data blocks that have changed since the last incremental backup of the same or a lower level. BRBACKUP supports you in performing level 0 and level 1 cumulative incremental backups.

Result

You always have an up-to-date backup of your database. This allows you to quickly recover the database in the event of a failure involving data loss. Therefore, the availability of your SAP system improves because downtime due to the absence of a suitable database backup is kept to a minimum.

More Information

BR*Tools to Back Up the Oracle Database , which you can find as follows:

https://www.sap.com/community/topic/oracle.html