Backsups

[moiz7070]

Successful backups are the responsibility of every Basis and database administrator. Understanding the internal mechanisms of how backups are implemented in R/3 and Oracle will enable you to design, implement, and troubleshoot the most demanding database environments.
Volumes have been written on the subject of backup and archive, so I’ll refrain from writing yet another backup and archive configuration guide. Instead, this column will focus on behind-the-scenes backup and archive operations. I’ll look at the various backup tools provided by R/3 and the operating system, as well as backup and archive internals within R/3 and Oracle. My reference system is running R/3 release 4.0B on Digital Unix and Oracle 8.0.4. However, the following information should be valid for any operating system platform with the same configuration.
Backup Overview
Oracle organizes backups into two broad groups: logical and physical. Within each group the organization is broken down further into types. For example, logical backups have only one backup type: database exports; physical backups have two: hot and cold. The difference between the two groups is that physical backups store the actual data files associated with the database, while logical backups construct the actual commands (CREATE TABLE, INSERT, etc.) to rebuild the database on a target system. Daily maintenance of R/3 typically does not include logical backups. They are mainly used for migrating systems to a different platform.
R/3 Basis administrators and DBAs typically implement physical backups—of which hot backups are the most common type. This is because the system downtime that is required to complete a cold backup (especially of a large database) is generally unacceptable. I’ll steer clear of delving into the internals of logical backups and focus on physical backups with an emphasis on hot backups, since they are the most technically complex.
I’ll be working with an imaginary R/3 system called SND. In reality the system exists; however, I’ve modified the structure for the sake of simplicity when presenting the examples. I’ll walk through an actual backup and archive example and, along the way, examine the internal R/3 and Oracle mechanisms. This particular R/3 system contains five tablespaces: SYSTEM, PSAP40BD, PSAP40BI, PSAPTEMP, and PSAPROLL. All of the tablespaces consist of one data file with the exception of PSAP40BD and PSAP40BI. Both of these tablespaces contain two data files. The data files are laid out on the file system as follows:
/oracle/SND/sapdata1/system_1/system.data1 /oracle/SND/sapdata1/40bd_1/40bd.data1
/oracle/SND/sapdata1/40bd_2/40bd.data2
/oracle/SND/sapdata2/40bi_1/40bi.data1
/oracle/SND/sapdata2/40bi_2/40bi.data2
/oracle/SND/sapdata3/roll_1/roll.data1
/oracle/SND/sapdata3/temp_1/temp.data1
Before I get started, I would like to present a quick overview of the critical files needed in order to recover the system successfully.
The Critical Files
In order to capture a consistent physical backup of an online database, the following files must be saved:
The control file(s) — contains the database schema as well as information about the names, location, status, and state of all data and online redo logs in the database. The control file is checked when the database is started. If you lose the control file because of a disk crash, you can either rely on one of the backups kept on a different disk or, if all is lost, it can be recreated (consult the Oracle documentation for specifics).
The data files — the physical repository for the business data. As the database grows and more space is required, it is the responsibility of the R/3 administrator or DBA to allocate more. This can be accomplished by adding a data file to a tablespace, adding a new tablespace, or increasing the size of a data file. An interesting new feature found in Oracle 8 is its ability to autoextend the data files of a tablespace. To find out if the autoextend option is set for a particular data file, query the DBA_DATA_FILES view. Look at the value in the AUTOEXTENSIBLE column. You can enable or disable this feature for existing data files using the ALTER DATABASE command.
The archive redo logs — information describing a change to the database. The archive redo logs contain information necessary to roll the database forward. Information in the archive redo logs is organized into records called redo records, and redo records are broken down further into units called change vectors. A change vector is a structure that describes a change made to any single Oracle database block. Oracle blocks should not be confused with operating system blocks. Oracle blocks are usually a multiple of the operating system block size and can be configured via the initSND.ora parameter DB_BLOCK_SIZE.
The following files do not contain state information; however, they are just as critical and need to be backed up in order to recovery successfully. brbackup backs up these files by default.
initSND.ora – the database initialization parameter file. This file contains Oracle systems parameters that are used to customize the database.
initSND.sap – the SAP backup and recovery initialization parameter file. This file contains parameters that are used to customize the behavior of brbackup and brarchive. (It is also used by the brrestore facility.)
This list is by no means complete. For example, it doesn’t include Oracle binaries — the software installed by the server installation process. These files can be backed up using brbackup; however, they are usually backed up separately and are typically considered part of the operating system backups.
Profile Values
As mentioned earlier, the file initSND.sap is the configuration file used to customize the behavior of the SAP-delivered backup and recovery tools brbackup, brarchive, and brrestore. I’ve correctly configured the volume management portion of this file, and I have the tapes with the proper volume labels on hand. In addition, my tape address and size parameters have been configured to properly identify my tape drive. I’m using a standalone DLT 4000. The following list contains a few of the essential parameters and values contained in the initSND.sap profile:
backup_mode = all
backup_type = online
backup_dev_type = tape
compress = hardware
archive_function = save_delete
tape_copy_cmd = cpio
cpio_flags = -ovB
cpio_in_flags = -iuvB
Let’s look at each of these in turn.
The backup_mode parameter is used by brbackup and brrestore to determine the scope of the backup and recovery activity. It can have several values, which are documented in the R/3 online help CD. This CD comes standard with every R/3 distribution. The value all tells brbackup and brrestore to backup and restore all tablespaces in the database, respectively.
The backup_type parameter identifies the default type of database backup. It also has several well-documented options. The value online backs up the database while it is open and available to users. Also worth mentioning is the value offline_cons. This value backs up the database data files while the engine is online, and then backs up the offline redo logs generated during the backup to the same volume. This offline redo log backup runs independently of the archive log backups performed by brarchive and does not require an additional archive volume. This method provides a consistent backup of the database that can be recovered.
The backup_dev_type is set to the value tape because of my DLT drive. The compress parameter is set to hardware because I’ll be using the hardware compression of the tape drive. This means that I need to write to the Unix high-density tape device file. I’ve accomplished this by making sure the tape_address parameter is set to /dev/nrmt3h (high density with no rewind) and the tape_address_rew parameter is set to /dev/rmt3h (high density with rewind). The values for these two parameters will vary from system to system. Consult your Unix documentation about creating the appropriate special device for your particular drive.
The archive_function parameter defines how brarchive saves the offline redo logs. There are several strategies depending on the number of tape drives and the amount of disk space available. Refer to the R/3 online help CD for a complete list of options. The save_delete value archives the offline redo log files and then deletes them from the /oracle/SND/saparch directory. Even though I’m using save_delete in my example, I strongly recommend the use of copy_delete_save, which will create a second copy of the offline redo logs on a separate physical tape. This protects the archive redo logs from being lost in the event that one of the tapes is destroyed.
The tape_copy_cmd parameter is set to cpio. This parameter can have two values, cpio or dd. Both cpio and dd are used for copying data. The dd command is extremely flexible for performing data conversions on the fly and can often have performance advantages over cpio. Nonetheless, I’ll still use cpio. One major advantage of cpio is that it is a bit more intelligent than dd when reporting errors such as reaching the end of the tape. Regardless of this parameter value, raw devices are always copied with dd, and tape header and footer files are always written with cpio. For more information on cpio and dd, refer to the Unix man pages (man dd or man cpio).
cpio has three modes of operation: copy out (cpio –o), copy in (cpio –i), and directory copy (cpio –p). Copy out, copy in, and directory copy write data to and read data from an archive or write data to a specified directory. Options are passed to the cpio program using the cpio_flags, cpio_in_flags, and cpio_disk_flags parameters. cpio_flags is used to pass parameters to cpio for copy out mode. cpio_in_flags is used to pass parameters to cpio for copy in mode. cpio_disk_flags is used to pass parameters to cpio in copy directory mode. The following are default settings:
cpio_flags = -ovB
cpio_in_flags = -iuvB
cpio_disk_flags = -pdcu
-o, -i, and –p set the modes copy out, copy in, and copy directory, respectively. –v verbosely lists the files processed. –B performs block I/O and is only useful with the –o and –i modes. –d creates subdirectories as needed. –u copies unconditionally; without this option, a file from the archive with the same name as an existing file on the system is copied only if the archived file is newer. Finally, -c writes header information in ASCII form and is useful when creating or restoring archives to or from another system.
Performing the Backup
I’m finally ready to start the backup. It can either be scheduled through transaction DB13 (the database planning calendar) or started via the command line. I’ll start brbackup via the command line. Since the option values have been specified inside the parameter file initSND.sap, the command brbackup -c will start the backup correctly.
The –c option bypasses operator confirmation and continues without prompting for input. It is also worth mentioning that the –a option of brbackup will automatically call brarchive following the data file backup. Together the commands copy all of the data files, as well as offline redo logs, to the same tape. This procedure automates the backup to a greater degree and may offer a more efficient use of tape capacity.
If I use the Unix tail command to view the database alert and brbackup logs soon after I start the backup, I see the following:
Excerpt from /oracle/SND/saptrace/background/alert_SND.log
Sun Feb 7 23:11:47 1999
ALTER DATABASE BACKUP CONTROLFILE TO '/oracle/SND/sapbackup/cntrl.dbf'
Sun Feb 7 23:11:51 1999
Completed: ALTER DATABASE BACKUP CONTROLFILE TO ‘/oracle/SND/
Excerpt from /oracle/SND/sapbackup/bczhvugd.ant
BR051I BRBACKUP 4.0B
BR055I Start of database backup: bczhvugd.pnt 1999-02-07 23.19.19
BR319I Control file copied to /oracle/SND/sapbackup/cntrl.dbf
brbackup connects to the database and issues the ALTER DATABASE BACKUP CONTROLFILE command to copy the control file to the /oracle/SND/sapbackup directory. Shortly thereafter it checks the volume label on the tape. The output of the log looks as follows:
Excerpt from /oracle/SND/sapbackup/bczhvugd.ant
BR208I Volume with name SNDB06 required in device /dev/nrmt3h

BR280I Time stamp 1999-02-07 23.19.33
BR226I Rewinding tape volume in device /dev/rmt3h ...
BR351I Restoring /oracle/SND/sapbackup/.tape.hdr0
BR355I from /dev/nrmt3h ...

BR241I Checking label on volume in device /dev/nrmt3h
BR242I Scratch volume in device /dev/nrmt3h will be renamed to SNDB06

BR280I Time stamp 1999-02-07 23.19.43
BR226I Rewinding tape volume in device /dev/rmt3h ...

BR202I Saving /oracle/SND/sapbackup/.tape.hdr0
BR203I to /dev/nrmt3h ...

BR209I Volume in device /dev/nrmt3h has name SNDB06
brbackup uses cpio to read the volume label off the tape and save it to the /oracle/SND/sapbackup directory as .tape.hdr0. In this case the volume was labeled SCRATCH. This is a special volume label. If brbackup reads the volume label SCRATCH, it will correctly reinitialize the volume to the one it needs, as shown in the previous log entry. Once the volume label check succeeds, brbackup begins to save the Oracle and SAP initialization files to tape.
Excerpt from /oracle/SND/sapbackup/bczhvugd.ant
BR202I Saving init_ora
BR203I to /dev/nrmt3h ...

BR202I Saving /oracle/SND/dbs/initSND.sap
BR203I to /dev/nrmt3h ...

The next step is to place the tablespace into backup mode and copy the data files to tape using cpio.
Excerpt from /oracle/SND/sapbackup/bczhvugd.ant
BR280I Time stamp 1999-02-07 23.19.59
BR315I Alter tablespace SYSTEM begin backup successful
BR202I Saving /oracle/SND/sapdata1/system_1/system.data1
BR203I to /dev/nrmt3h ...

#FILE..... /oracle/SND/sapdata1/system_1/system.data1
#SAVED.... system.data1 SNDB06/4

Excerpt from /oracle/SND/saptrace/background/alert_SND.log
Sun Feb 7 22:31:51 1999
ALTER TABLESPACE SYSTEM BEGIN BACKUP
Completed: ALTER TABLESPACE SYSTEM BEGIN BACKUP
Sun Feb 7 22:36:21 1999
ALTER TABLESPACE SYSTEM END BACKUP
Completed: ALTER TABLESPACE SYSTEM END BACKUP
brbackup places the appropriate tablespace into backup mode using the ALTER TABLESPACE <TABLESPACE_NAME> BEGIN BACKUP command. So how does Oracle allow users to continue using the database while a particular tablespace is being backed up?
The BEGIN BACKUP command flags all of the data files within the tablespace as hot-backup-in-progress. This command forces a checkpoint. Any dirty buffers related to the data files will immediately be flushed to disk. Next, a redo record is written to the online redo logs with the current System Change Number (SCN). The SCN is a unique value that describes a committed version of the database at a precise moment in time. Think of it as Oracle’s internal clock that ensures transaction consistency. This SCN is also recorded in the header of the data file. After the BEGIN BACKUP command, activities in the database do not advance the SCN value recorded in the data file header. The hot backup of the data file completes after the command ALTER TABLESPACE END BACKUP. This statement writes a redo record containing the SCN value from the BEGIN BACKUP command. This action ensures that, in the event of a recovery, the database needs to apply at least the redo records between the BEGIN BACKUP and END BACKUP commands. Doing so guarantees data file consistency. In addition, when the END BACKUP command is issued, the SCN value recorded in the data file header is advanced to the current database value.
The command ps aux | grep cpio shows how the data file is copied to disk when the tablespace is in hot backup mode. It appears as follows:
sh -c ( LANG=C cd /oracle/SND/sapdata4/ddicd_1 && echo ddicd.data1 | \
LANG=C cpio -ovB > /dev/nrmt3h ) 2>&1
As shown, if the cd to /oracle/SND/sapdata4/ddicd_1 is successful, then the ddicd.data1 data file is passed to cpio. Also, stderr is redirected to stdout, which in this case is /dev/nrmt3h. Setting LANG=C ensures the proper machine locale.
In addition to cpio, the brconnect utility runs for the duration of the backup. brconnect is a utility called by brbackup. Its purpose is to monitor the status of the database. In other words, if the backup type is specified to be online, brconnect ensures the database is open and available. If the backup type is specified to be offline, brconnect ensures the database is closed. If status conditions are not satisfied, brconnect will terminate brbackup and write errors to the backup log.
Finally, brbackup saves the control file from the BACKUP CONTROLFILE issued earlier and issues an ALTER SYSTEM SWITCH LOGFILE to write out the current redo log file and advance to the next one as follows:
Excerpt from /oracle/SND/sapbackup/bczhvugd.ant
BR202I Saving /oracle/SND/sapbackup/cntrl.dbf
BR203I to /dev/nrmt3h ...

#FILE..... /oracle/SND/sapbackup/cntrl.dbf
#SAVED.... cntrl.dbf SNDB06/5

BR340I Switching to next online redo log file for database instance SND...
BR321I Switch to next online redo log file for database instance SND successful.

Excerpt from /oracle/SND/saptrace/background/alert_SND.log
Sun Feb 7 22:36:31 1999
Thread 1 advanced to log sequence 1171
Current log# 13 seq# 1171 mem# 0: /oracle/SND/origlogA/log_g13m1.dbf
Current log# 13 seq# 1171 mem# 1: /oracle/SND/mirrlogA/log_g13m2.dbf
In addition to these files, other summary files are also written to tape. However, the major events have been covered.
Performing the Archive
brarchive can also be scheduled through transaction DB13 or started via the command line. Once again I’ll start it via the command line. The options have been specified inside the parameter file initSND.sap so brarchive -c will begin the archive correctly.
The tape volume is checked and, if the proper volume is in the drive, brarchive will begin writing the offline redo logs to tape and then delete them from the file system. Remember I configured this behavior by setting the parameter archive_function to save_delete in the initSND.sap profile.
Excerpt from /oracle/SND/saparch/aczfsceu.svd
BR202I Saving /oracle/SND/saparch/SNDarch1_962.dbf
BR203I to /dev/nrmt3h ...

#ARCHIVE.. /oracle/SND/saparch/SNDarch1_962.dbf
#SAVED.... SNDarch1_962.dbf SNDB03/39

BR015I Offline redo log file /oracle/SND/saparch/SNDarch1_962.dbf deleted.
A cpio command, similar to the one run by brbackup, will show up in the process list. Summary files are written to tape at the end of the brarchive procedure as well. This tape, combined with the tape generated from brbackup, constitutes a consistent physical snapshot of the database that can be recovered. Don’t forget that more recent versions of brbackup support the –a option. This will start brarchive immediately after the completion of brbackup and will append the archive logs to the current tape.

[rukku]

Good Article.It has good information.
Hi Moiz Ahmed how r u

[srikanth0250]

It is really awesome,
small query -
Does value of backup_dev_type same(tape) for windows OS or disk