087 Saez

7/30/2019 087 Saez

1/16

Overviewing Windows NT/Database Backup and Recovery

Introduction

1996 SAP Technology, Inc. 871

Chapter 87: Overviewing Windows NT/Database Backup and Recovery

Contents

Intr oduc tion ............................................................................................................................................................................................. 87Offline and Online Backups............................................................................................................................................................... 872

Recommendations............................................................................................................................................................................ 872

Archi ve Backup.... ........ ......... ......... ......... ........ ......... ......... ......... ........ ......... ......... ......... ........ ......... ......... ......... ........ ......... ......... ......... .... 875

Restori ng wi th SAPDBA: Check (and Repair) Database ....................................................................................................................... 875

Requirements.................................................................................................................................................................................... 876

Reviewing General Rules for Database Recovery.............................................................................................................................. 876

Reviewing Backup Speed....................................................................................................................................................................... 877

Defining Backu p Frequency and Schedules .......................................................................................................................................... 877

Defini ng Oracle Redo Log Management and Arch ives ......................................................................................................................... 878

Defining Backup and Arch ive Storage Management ............................................................................................................................. 878

Verify ing Backup Strategy ...................................................................................................................................................................... 879

Choosing and Implementing a Backup Strategy ................................................................................................................................... 879

Backup and Archive Procedur es and Polices ......................................................................................................................................8710

Backup.............................................................................................................................................................................................8710System Environment.................................................................................................................................................................8710Policies.....................................................................................................................................................................................871Procedures...............................................................................................................................................................................8713Roles and Responsibilities........................................................................................................................................................8714

Recovery..........................................................................................................................................................................................8714System Environment.................................................................................................................................................................8714

Policies.....................................................................................................................................................................................8714Procedures...............................................................................................................................................................................8715Roles and Responsibilities........................................................................................................................................................8715

Introduction

Possibly the single most important aspect of the basis implementation is the establishment of an effectivebackup strategy. You must be able to restore the database in the event of any type of error.

The strategy you implement for backups should be manageable. For example, it should be clear tooperators what tapes should be mounted and when, so that mistakes are unlikely. The chosen backupstrategy should not have an adverse impact on daily business.

SAP provides two easy-to-use interfaces for performing a backup: SAPDBA on the operating system level,and CCMS-DBA on the R/3 level.

ORACLE also offers two types of backup: online and offline. Backups can be performed at any of thefollowing levels:

database - full backup, all data files are saved

tablespace - partial backup, data files of one or more tablespaces are saved

data file - one or more data files are saved

7/30/2019 087 Saez

2/16


Introduction

872 1996 SAP Technology, Inc.

Our recommendation:

Whenever downtime has to be minimized, we recommend that you use online backups (only offlinebackups cause system downtime).

Offline and Online Backups

Offline

During an offline backup, either the whole database or parts of it wont be available for use. Offlinebackups are usually done at the database level. Therefore BRBACKUP (the SAP backup utility) onlysupports offline backups at the database level. Once the database is closed, a full backup is donethat is,all data files, all online redo log files and at least one control file are backed up. Offline backups at thetablespace level are not advisable in an integrated environment like R/3, because the application modulesrequire access to data in several tablespaces. If one tablespace is not available, most application moduleswill not be able to continue.

The advantage of performing an offline backup is that the data can be restored and the database opened

without performing a recovery. The major disadvantage is that the database cannot be used while thebackup is running.

Online

An online backup is more appropriate for large databases. An online backup may be a full or a partialbackup. The backup includes all or some of the data files and a control file. The offline redo log filesgenerated while the backup was done need to be available as well in order to use the backup. Theadvantage is that the database is available for normal use while the backup is taken.

Two disadvantages of the online backup are:

1. Deterioration in performance:

The DBMS performance deteriorates because more redo log information is generated while the backup isrunning. For example, an online backup running alongside a background job with batch input causes therun time of the background job to increase considerably. Therefore, you should perform online backupsduring times of low system load.

2. Backed up data files without the redo log files are inconsistent:

If used for a recovery, the online backup must be supplemented with the redo log files archived duringthe backup. To ensure that the last online redo log file from the backup is safely archived, you shouldperform a redo log switch immediately after the backup. An online backup done with SAP's BRBACKUPtool does this automatically.

You can perform an online backup as follows: First, run BRBACKUP to save data files. Then run

BRARCHIVE immediately afterwards to save the archived redo log files belonging to the backup.

Recommendations

Determine whether offline or online backups or both will be used

Backup at the tablespace level

Increase frequency of backups

7/30/2019 087 Saez

3/16


Introduction


Increase backup frequency of heavily used tablespaces

Do backups in parallel

Adjust backup frequency by carrying out tests

Skip index tablespaces to reduce backup downtime

Back up to disk first Backups with mirrored disks can be made offline

Use hardware compression with the backup

Assess your tape devices

Verify that your backup tapes are readable

Determine whether offline or onli ne backups or both will be used

You should carefully consider whether you need to use offline or online backup. Use online backup ifdowntime cannot be tolerated or if your database is very large and would take too long to back up offline.

Backup at the tablespace levelIf you have decided that a complete backup takes too long, use backups at the tablespace level. Forexample, if the database is comprised of 20 tablespaces, back up 4 every nights Monday through Friday(which is equivalent to one full backup a week). Here, the worst case would be that a tablespace damagedon Sunday would have to be recovered from last Monday's backup.

Increase the frequency of backups

More frequent backups lead to a shorter recovery time and therefore shorter downtime. One compromisewould be to make less frequent full backups, (for example, one full backup on Sunday) and morefrequent partial backups (for example, backup one third of all tablespaces Monday, another third onTuesday, the last third on Wednesday, and start over for Thursday, Friday, Saturday). Here, the worst

case would be to have to use a backup which is 3 days old.

Increase backup frequency of heavily used tablespaces

It is wise to back up heavily used tablespaces more often (for example, by including them twice in abackup cycle). The reason behind this is that heavily used tablespaces put more of a load on disk drives,thus increasing the frequency with which they fail. The more often such tablespaces are backed up, themore likely a recent backup is available to be used in a recovery.

Do backups in parallel

Offline and online backups can be done in parallel to increase throughput. For example, if partial onlinebackups of tablespaces are done (see example above), you can also schedule the backups of several groupsof tablespaces to run in parallel, utilizing multiple devices. BRBACKUP supports parallel backups.

Adjust backup frequency by car rying out tests

There is no rule of thumb to determine the backup frequency. Suppose, for example, a test showed that toapply 3 redo log files to a restored full backup took 15 minutes (that is, 5 minutes recovery time perarchived redo log file) and assuming 20 redo log files are archived on average a day, then a recovery froma 3 day old full backup would take 3 * 20 * 5 minutes = 300 minutes (or five hours). If, as in this example, a

7/30/2019 087 Saez

4/16


Introduction


recovery time of five hours is too long, more frequent backups can be taken (or other techniques such asmirrored disks can be used).

Skip index tablespaces to reduce backup downtime

To improve backup performance, consider skipping index tablespaces completely from your backups. An

index tablespace contains only indices, which can always be rebuilt if required. If index tablespaces are notbacked up, the Reorganize tablespace and data files function of SAPDBA should be used to generate thescripts needed to create the tablespaces and indexes if they have to be rebuilt (this function can be stoppedafter the scripts have been generated, before the actual reorganization takes place). The scripts should berecreated every time that index structures or index tablespace structures have changed.

You should monitor to make sure that no tables are accidentally residing in an index tablespace. If a tableresides in an index tablespace it should be reported by SAPDBA during the creation of the reorganizationscripts. If a table has been 'misplaced', you should move it back to the appropriate data tablespace. Therecommendation to omit index tablespaces from backups is only valid if no tables reside in thesetablespaces.

Back up to disk firstIf sufficient disk space is available, consider backing up to disk first. A disk backup is usually faster than atape backup because disk devices are generally faster. You can then copy your backups from disk to tapewithout incurring downtime. If possible, retain the disk backup copy since a restore from disk is fasterthan from tape. Note that this assumes that the disks are not mirrored: with mirrored disks other optionsare available (see the next recommendation).

Backups with mir rored disks can be made offline

In the case of mirror disks, online backups are no different from backups of non-mirrored disks. If youwish to do offline backups in a mirrored disk environment, we recommend the following approach: First,shut down the database and split the disk mirror. Then restart the database on just one disk set. Finally,

mount the second disk set onto another system on which you will perform the offline backup.

If the database is backed up this way, it is not recommended to use BRBACKUP, because the BRBACKUPlog information will be incomplete on the original system.

After the backup is done, the two disk sets have to be re-synchronized. The downtime incurred with thismethod is the time taken to shut down the DBMS, split the mirror and then restart the DBMS.

It may take a substantial amount of time to re-synchronize the two disk sets, leading to severedegradation of performance.

This method has the disadvantage that the database is not mirrored during the backup. If it is considereda high priority to have disk mirroring all the time (for protection against disk failures), this technique can

be safely deployed if three-way mirroring is used.

Use hardware compression with backups

You should consider using hardware compression with backups. It cuts down backup time by as much as50%. If the backup must go to tape directly and be done online, consider using multiple tape drives forparallel backups to shorten backup time.

7/30/2019 087 Saez

5/16


Arc hive Back up


Assess your tape devi ces

It pays to think about what kind of tape devices you are using for backing up your database since this willdetermine the downtime in the case of offline backups. To give you some idea of this, the capacity of tapescurrently ranges from 2 to 30 GB and the speed of data transfer ranges from 1 to 10 GB per hour.

Verify that your backup tapes are readableYou should verify that your backups can indeed be successfully used for a restore. Use a separate systemfrom the live production system. To carry out a test, you may want to restore the data files of the systemtablespace, rollback segment tablespace, temporary tablespace and a tablespace of your choice, pluscontrol files, online redo log files and archived redo log files. Mount the database, take offline all data filesthat were not restored, recover the database and then open it. If successful, this is proof that the restoredfiles can be used.

Ar ch ive Backup

You should regularly (weekly, for example) perform a full backup of the off-line archived log files. These

files are crucial to the recoverability of the database should a database failure occur. Because these files areso important, SAP recommends that two copies of the archive logs be saved to tape. The archive utility(called BRARCHIVE) supports this process.

If you have configured your system according to the SAP recommendations, the ORACLE system willsave the online redo log files (where the changes made to the database are recorded) automatically (offlineredo log files are written). If you have not changed the standard profile init.ora, the offline redolog files are contained in the archive directory \saparch.

To perform a recovery of the database, the redo log entries must be available in their original,uninterrupted sequence. Therefore, it is essential that you protect the offline redo log files written by theORACLE system against loss. Moreover, a database shutdown may occur when no more space is available

for new offline redo log files in directory \saparch (archive stuck). For this reason,you should regularly archive the offline redo log files to a volume (tape). The SAP utility BRARCHIVE isprovided for this purpose.

When you select Backup archive logs, SAPDBA calls the SAP program BRARCHIVE. You can, of course,directly archive the offline redo log files by simply calling BRARCHIVE.

You can also use the Computing Center Management System of R/3 to plan an archive of the offline redolog files, start it, and then view its log. See the online help for the Computing Center Management System.

Restoring with SAPDBA: Check (and Repair) Database

The task of the SAPDBA recovery function is to remedy certain media and user errors. When such an

error occurs, it usually involves the loss of database files, which can contain many different types ofobjects: ORACLE Dictionary segments, temporary segments, rollback segments, or user segments (tablesand indices). SAPDBA supports restoring the database after the loss of the following files:

Data files of the SAP tablespaces (PSAPD/I)

Files of the system tablespace (SYSTEM)

Files of the rollback tablespace (PSAPROLL)

Files of the temporary tablespace (PSAPTEMP)

7/30/2019 087 Saez

6/16


Restoring with SAPDBA: Check (and Repair) Database


The menu item Check (and repair) database only enables recovery of the database up to the current time. Ifyou want to restore an older version of the database or perform a point in time recovery, please use theRestore/Recovery function.

Requirements

The SAPDBA recovery function works closely with the BRBACKUP and BRARCHIVE programs. In therestore phase, the copies of the database files and archive logs created by these programs are restored byBRRESTORE. The BRBACKUP and BRARCHIVE logs contain information on the directories or datamedia in which these files are stored. In addition, if you used a non-SAP backup utility (connection viaBRBACKUP/BRARCHIVE), SAPDBA is also provided with the backups required for a recovery.

The following requirements must be met to run an SAPDBA-assisted database recovery successfully aftermedia or user errors:

The complete, undamaged BRBACKUP and BRARCHIVE logs must be available for SAPDBA todetermine the location of the database files and archived redo log files. (Always make sure that asufficiently large number of logs are available, i.e., do not delete the logs too soon.)

Undamaged copies of the lost database files must be available.

Undamaged copies of all redo logs that were written between the point when the database copy usedfor the recovery was created and the point when the media error occurred must be available.

The control file and all copies of this file must be available in undamaged form. If this is not the case,you will have perform the actions necessary to bring about the required situation.

In each case at least one member of the online redo log groups must be available in undamaged form.In other case you have at first to perform the corresponding actions to rebuild the necessary redo logs.SAPDBA determines whether any copies of the online redo log files are missing or damaged. If so, youreceive a corresponding warning message, but can still execute the recovery. It is important to dealwith this at an appropriate time. Refer to the ORACLE documentation.

If these requirements are met, recovery can often be executed automatically using the SAPDBA recoveryfunction.

The recovery option should only be used by an experienced database administrator on his or her ownresponsibility. Make sure that only the database administrator is authorized to use the expert mode (seeSAPDBA: Expert mode). If in doubt, please contact an experienced coworkeror SAP directlyif yourdatabase requires recovery.

Reviewing General Rules for Database Recovery

Use the items in the following list as a rule of thumb for database recovery:

A detailed discussion of the subject of backup and recovery can be found in the ORACLE Backup &Recovery Handbook by Rama Velpuri, published by ORACLE Press.

As long as you have adhered to a proper data backup strategy, it should always be possible to restoreyour database to a complete and consistent status. Depending on the knowledge and experience ofyour administrator, you may need to call on external help.

The CHECK AND REPAIR scenario of the sapdba process supports the normal case for restoring thedatabase. You should note that R/3 operation is not possible while the database is being restored.

7/30/2019 087 Saez

7/16


Reviewing Backup Speed


Any recovery options that lie outside the scope of the CHECK AND REPAIR scenario should beattempted only after careful checking and preparation.

Reviewing Backup Speed

How long will a backup take (and what can I do to speed it up)? The following table of various tapedevices should give you a rough idea of backup rates for certain common devices.

Tape size Capacity Rate

DAT (DDS-2) 2 - 7 GB 1-2 GB/h

IBM 3490 2 GB 5-10 GB/h

DLT 10-15 GB 3-6 GB/h

IBM 3590 20-30 GB 5-10 GB/h

Note that due to various system limits (system bus, cpu, controllers), you cannot expect perfect scalabilityfrom these devices (that is, you cannot expect 10 DLT drives to backup 60GB/h). Certainly hardwarespeed is one area in which the customer should work with hardware vendors to obtain an optimalsolution.

Defining Backup Frequency and Schedules

How often should backups be performed? The ideal solution here is to perform a complete backup onevery day in which there is activity in the database. An SAP customer should only step back from thissolution if absolutely necessary (because the database is too large and the "backup window" too small, for

example).

The following list shows you the ideal strategy for backup activities:

1. Backup up your complete database every day on which you have online activity.

2. Make double copies of your redo logs.

3. Keep redo logs going back to your last complete backup (or oldest of your partial backups) availableon disk.

4. Use an expiration date of at least 28 days on all tapes (database backups and redo log archives).

5. Keep at least 5 backup generations (but more is better).

6. Store tapes at a secure off-site location.

All backup strategies are either implementations of the Ideal Strategy or variations of that strategy forcedby the given conditions at the customer site (VLDBs or very high availability demands, for example). Thequestions you must answer here are:

What (if any) periods in the week is the system fully available for administrative activities?

During which (if any) periods can the system, though online, handle the added load of backup beingperformed?

How long does it take to backup my entire database?

7/30/2019 087 Saez

8/16


Defining Oracle Redo Log Management and Archives


Do I have the media capacity for unattended backups?

How much redo log volume is expected between backups?

Do I have ample (at least double) disk capacity for handling this redo log volume in my archive directory?

Defining Oracle Redo Log Management and ArchivesWhen should redo log archives be performed? How can I guarantee that I will never lose a redo log? Howcan I prevent an archive stuck situation? How can I reduce recovery time?

Redo log management overshadows almost all other DBA activity: every day hundreds of megabytes ofredo log information gets written and must be saved. If redo logs are lost, there is danger of real loss ofdata in a restore situation. If they are not backed up and cleared from the archive directory, the archivedirectory can fill up completely and cause the entire database to freeze, resulting effectively in down timefor all users. On the other hand, by holding the redo logs going back to the last backup on disk, one canspeed up a recovery, since only damaged datafiles need then to be restored from the backup media.

The following is a simple and effective redo log archive strategy:

1. Provide generous disk capacity for your archive directory (at least double your expected redo logvolume between backups). Depending on the amount of activity on the customer system, this could beseveral gigabytes of space.

2. Provide capacity in your backup media for unattended archives of your redo log files. Ideally youshould be able to schedule a complete backup of your system followed by saving two copies of theredo log files.

3. Using brarchive options, you can set up a strategy which leaves one days worth of redo logs on diskafter they have been backed up. To help ensure that you will never lose redo logs, use the brarchiveoption which creates double copies of each log.

4. Using the alert monitors and training measures for MIS personnel you must guarantee that the archive

directory never fills up, whether due to unexpectedly high change volume in the database or errors inthe last archive run.

Note that there are other equally valid strategies available. You can start brarchive in continuous mode,for example: the program then runs and archives each offline redo log as soon as it has been written to thearchive directory.

You may also prefer to run your archives manually at regular times each day.

Defining Backup and Archive Storage Management

How long should the customer keep backups? How many generations should the customer keep? Howshould the tapes be labeled? Where should the tapes be kept?

1. Expiration dates and generations

We recommend an expire date of at least 28 days for both database backups and redo log archives. Wehave had customers ask us whether they really need to keep more than two generations of tapes. Weremind them of the issue, namely: what we are trying to avoid is a complete and irreversible loss of yourbusiness data. There is no SAP customer so small that their business data is less valuable than a monthsworth of DAT tapes.

7/30/2019 087 Saez

9/16


Verifying Backup Strategy


2. Volume labeling

A good strategy for volume labeling can provide you with increased security, especially if relativelyuntrained operators will be mounting tapes. With proper planning, for example, you can label your tapeswith the day of the month (C11B24A, C11B24B, and C11B24C, for example, for the C11 Backup on the24th of each month, volumes A, B and C ). Such a strategy helps guarantee, for example, that the

correct tapes are retrieved from off-site for the daily backup. (These considerations do not apply to usersof backup management software, such as ADSM, Omniback, Legato and others.)

3. Off-site storage

Plan offset storage for the case of fire or other major catastrophe in your computer room.

Veri fying Backup Strategy

How does the customer know that the backup tapes are OK? How can the customer be sure that they willbe able to recover their database?

Everyone who manages a database system must be aware of the possibility of absolute catastrophic data

loss. One SAP customer, for example, performed an operating system upgrade without re-testing theirbackup strategy. Several days later it became necessary to restore the backup, and the customerdiscovered that the tapes written since the operating system upgrade were unreadable. Only the fact thatthey still had generations from before the upgrade saved this customer from a true catastrophe;nonetheless, many days of business data were lost.

1. Test restore before productive start

An absolute minimum verification strategy is to perform a complete restore and recovery before yourproduction system goes live. Once your system has gone live, you should continue to verify your backupsregularly, at a minimum of, say three month periods and after every change to the backup infrastructure(new operating system, new database release, new hardware).

2. Backup verification after productive start

With version X.X of brbackup you can perform a verify your backup: brbackup restores the files from tapeand compares them to the productive versions. For an online backup only the size of the files can becompared; for an off-line backup the contents of the files are checked.

Choosing and Implementing a Backup Strategy

It is very important to set up a proper procedure to backup the valuable information of an R/3 System.These items should be defined before as early as possible to prevent any possible loss of data in the future.Followings is a list of Backup issues which should be resolved before going live:

Decide how often to perform complete database backups (preferably on every day in which there isactivity in the database)

Decide whether partial backups are necessary: if so, plan for their implementation

Decide when to perform redo log archives

Decide if you will make double copies of redo logs before deletion

Decide if you will hold redo logs on archive directory going back to latest complete backup

Provide ample disk space for the archive directory

7/30/2019 087 Saez

10/16


Backup and Archi ve Procedures and Polices


Decide on how to schedule redo log archives

Create a volume labeling scheme to ensure smooth operations

Decide on backup retention period (recommended at least 28 days)

Determine tape pool size

Initialize tapes Determine physical tape storage strategy (off-site)

Decide whether or not to use unattended operations

If unattended operations, in CCMS or elsewhere?

Document backup procedures in operations manual

Train operators in backup procedures

Implement a backup strategy

Perform a test restore and recovery

Backup and Archive Procedures and PolicesBackup policies and procedures should be defined as early as possible so that you will be prepared in theevent of data loss. The following is an example of backup and archive procedures and polices for a threesystem landscape (where DEV is a development system, QAS is a consolidation/quality assurancesystem, and PD1 and PD2 are production systems).

Backup

System Environment

Software Components

The following tools are used to perform the backup/restore tasks:

System Name Backup Software

DEV SAPDBA 3.0E

QAS SAPDBA 3.0E/HIBACK 3.02

PD1 SAPDBA 3.0E/HIBACK 3.02


Hardware Components

The hardware listed in the table below is used for backup and restore:

System Name Backup Hardware

DEV 1 x 4mm DAT 4/8GB DDS-2

QAS 1 x DLT 15/30 GB

PD1 1 x ADIC Autoloader (5 DLT parallel)

PD2 2 x DLT 15/30 GB

7/30/2019 087 Saez

11/16




Policies

Tape Retention Period

The tape retention period is chosen in such a way that even if one tape (backup/archive) is damaged orlost, the ability to recover the database is assured.

System

Name

Regular

Backup

Month End

Backup

Year End Backup Archives

DEV 15 days 15 days

QAS 30 days 30 days

PD1 30 days 36 months 5 years 30 days

PD2 30 days 36 months 5 years 30 days

Backup Frequency (DB + Archives)

Use a schedules similar to the ones below in order to ensure that you will be able to quickly and easily

restore the database.Database Schedule

System

Name

Mon Tue Wed Thu Fri Sat Sun

DEV Full

Online

Full/

Online

Full/

Online

QAS Full/

Online

Full/

Online

Full/

Online

PD1 Full/

Online

Full/

Online

Full/

Online

Full/

Online

Full/

Online

Full/

Offline

PD2 Full/Online Full/Online Full/Online Full/Online Full/Online Full/Offline

Archi ves

A backup of the archives (former online redo logs) is necessary to be able to perform either a recovery ofthe database from an online backup or to perform point-in-time recovery.

The CDS backup option of the BRARCHIVE program ensures that from each archive there will be storedtwo copies on two different tapes before the archive is automatically deleted.

System

Name

Mon Tue Wed Thu Fri Sat Sun

DEV CDS CDS CDS CDS CDSQAS CDS CDS CDS CDS CDS

PD1 CDS CDS CDS CDS CDS CDS

PD2 CDS CDS CDS CDS CDS CDS

S: Save SD: Save & Delete DS: Delete Saved CDS: Copy, Delete, Save

7/30/2019 087 Saez

12/16




Supplementary Backups

Supplementary backups are made at special dates (month end, year end) so that you can restore thedatabase to a previous state if needed.

System Name Month End Backup Year End Backup

DEV None NoneQAS None None

PD1 Full Offline with Verification Full Offline with Verification

PD2 Full Offline with Verification Full Offline with Verification

Storage Location

For safety reasons, the backup media must be stored in a safe place. The production system copies of thetapes should be stored in a remote (external) location.

System

Name

Data Safe Additional

Location

DEV Yes NoQAS Yes No

PD1 Yes Yes

PD2 Yes Yes

Tape Labeling

Choose self explanatory names to indicate the type and source of the backup. For further differentiation,use sequential numbers.

System

Name

Regular Backup Month End Backup Year End Backup Archives

DEV DEV_R_ DEV_A_QAS QAS_R_ QAS_A_

PD1 PD1_R_ PD1_M_ PD1_Y_ PD1_A_

PD2 PD2_R_ PD2_M_ PD2_Y_ PD2_A_

: Sequential Number

Verifying Backups

To guarantee the integrity of the backups, perform checks on the tapes according to the schedule below.

SystemName

Frequency of Backup Verification

DEV Every 2 weeks

QAS Every 2 weeks

PD1 Every 2 weeks

PD2 Every 2 weeks

7/30/2019 087 Saez

13/16




Checking Database integri ty

To avoid backing up a hidden, inconsistent database (e.g. bad blocks), the database must be checked atleast once within one retention period.

System

Name

Frequency of DB-checks

DEV Every 2 weeks

QAS Every 2 weeks

PD1 Every 4 weeks

PD2 Every 4 weeks

Procedures

Backup

The backup is performed unattended according to the backup frequency table. The schedulingfunctionality of the R/3 CCMS is used for scheduling the backup.

For systems running plain SAPDBA the required tapes can be listed with the VOLUMES Needed button onthe backup scheduling screen within the CCMS.

On systems running SAPDBA in combination with HIBACK, the HIBACK Volumemanager must be usedto list the required tapes.

Extra backups such as the monthly and yearly backup have to be performed offline and will be performedeither with SAPDBA interactive or prepared BRBACKUP script files with a special tape pool.

Archi vin g

Archiving (Backing up of Archives) is performed after successfully backing up the database according tothe archiving frequency table. Archiving is performed during normal operation of the system (no

performance impact).

With plain SAPDBA the needed volumes can be find using the query only option in the backup archivemenu of SAPDBA.

If HIBACK is installed, the HIBACK Volumemanager must be used for finding the correct tape.

For the extra backups there is no special archiving required, because these backups are performed offline,so the database is in a consistent state.

Verifying of Backups

Backups must be verified following the schedule. The verify and list tape contents option of SAPDBA willbe used to perform this task. In addition checks can be performed with mt and cpio on the operatingsystem level. On systems running with Hiback, Hiback is used to verify the tapes

Monitoring/Controlling

After the backup of the database and the archives is finished, all logs must be printed and placed in thefolder for each system.

7/30/2019 087 Saez

14/16




Database Check

An integrity check of the database must be performed within one retention period, in order to ensure thatthere are no corrupted blocks in the database. This is not recognized during backup. An export to the nulldevice (dummy export) is one way to perform this check running ORACLE analyze script another way tocheck the database.

Roles and Responsibil ities

Task Role

Backup Database Operator

Backup Archives Operator

Verifying Backups Operator/DBA

Monitoring/Controlling Operator/DBA

Database check DBA

Recovery

System Environment

Software Components

For a database recovery, use the same software tools that you used for the backup.

System Name Backup Software

DEV SAPDBA 3.0E

QAS SAPDBA 3.0E/HIBACK 3.02



Hardware Components

System Name Backup Hardware

DEV 1 x 4mm DAT 4/8GB DDS-2

QAS 1 x DLT 15/30 GB

PD1 1 x ADIC Autoloader (5 DLT parallel)

PD2 2 x DLT 15/30 GB

Policies

Testing Recovery

The restore procedure is one of the key issues of the R/3 system. Therefore, the procedures for recoveringa database must be maintained and tested regularly.

System

Name

Regularly Tests Supplemental Tests

DEV every 2 months when any of the involved components changes (e.g. SAPDBA)

QAS every 2 months when any of the involved components changes (e.g. SAPDBA)

7/30/2019 087 Saez

15/16




PD1 every 2 months when any of the involved components changes (e.g. SAPDBA)

PD2 every 2 months when any of the involved components changes (e.g. SAPDBA)

Procedures

Recovery procedures are based on SAPDBA or on SAPDBA plus Hiback. It is also absolutely advisable, to

be able to recover the database by hand, which means retrieving the backed up datafiles with native toolslike mt and cpio, if you are using a Backint compliant tool like Hiback with plain Hiback.

After retrieving the datafiles, the database must be recovered with database tools.

It is essential to be familiar with this procedure too.

Roles and Responsibil ities

Task Role

Developing Restore Procedures DBA

Testing Restore Procedures DBA

Training Operators DBA

Perform Restores Operator/DBA

For further detai ls refer to

R/3 System Administration Made Easy

Introducing R/3 System Architecture (Ch. 1)

R/3 Basis Knowledge Products

DBA Oracle CD: Reference Implementation Data Backup & Data Recovery

R/3 System Online Help

Database Administration Oracle

Basis Courses

Database Administration ORACLE (BC505)

7/30/2019 087 Saez

16/16

Documents

087 Saez