Tip

SAP Brbackup using DD option

Under certain circumstances, SAP backups using "dd" in BRBackup utility have shown better results when compared to SAP backups that uses "cpio" in terms of speed, hence reducing backup time.

Also, on Unix platforms like IBM-AIX, in our case, the SAP back ups using "cpio" command have been unsuccessful for file sizes greater than 2GB.

Though "dd" has been used mainly for backing up data lying on raw disks and "cpio" for directories back up, we've seen better results in journaled/formatted disks as well on NT and Unix flavours.

My personal experience on MS-Windows NT 4.0, Sun-Solaris 7.0 and IBM-AIX 4.3.3 servers has shown 45-50% improvement for SAP backups provided the corresponding parameters are also tuned accordingly.

----------------------------------------
It is HIGHLY RECOMMENDED:

1. First, test the recommendation in a development scenario in your set up before making the changes in the live server.

2. Maintain a backup copy of your Init<sid>.sap file before going ahead with any changes. This is helpful in case you want to compare or revert back to your original scenario.

3. Ensure you have the latest SAP BR* & SAPDBA kernels per your installation

4. Seek confirmation from SAP on incorporating the recommended changes in your set up
----------------------------------------

Parameters used to change SAP Brbackup for "DD" usage:

1. Tape_copy_cmd
Command used to copy database

    Requires Free Membership to View

files and non-database files from disk to tape.

Default: cpio
Suggested Value  "dd"

Caution:
The dd command generally reports an I/O error when it reaches the physical end of the tape. This message shouldn't be confused with the same message when it is output for hardware problems. Check whether the end of the tape was really reached, taking the tape capacity into consideration.

Suggested Value  "Reduce the value of parameter tape_size in this case to 10% smaller than identified value."

Note: Also, please note that the tape header files (i.e. tape file label, init_ora, init_sap) and tape end files (i.e. reorg_log, det_log, sum_log) are always written with "cpio" regardless of the type of backup option chosen.

2. DD_Flags & DD_In_Flags
Dd_flags
Default value: "obs=16k" for NT
"obs=16k bs=16k" for UNIX
Dd_in_flags
Default value: "ibs=16k" for NT
"ibs=16k bs=16k" for UNIX

If you set parameter tape_copy_cmd = dd, I recommend that you set parameters dd_flags and dd_in_flags as follows:
Unix systems
In case the tape is locally situated and backup_dev_type = tape
dd_flags = "obs=xk bs=xk"
dd_in_flags = "ibs=xk bs=xk"
In case the tape is remotely situated and backup_dev_type = pipe, then you should set the values as stated in copy_in_cmd & copy_out_cmd as stated in this document.
Windows NT
dd_flags = "bs=xk"
dd_in_flags = "bs=xk" (x >=16)
The dd options obs and ibs aren't supported on Windows NT.

In our scenario, we've gone ahead with x = 640 on AIX 4.3.3 64-bit server. I would suggest you try in sequence 16, 32, 64, 128, 256, 512, 640, 1024 and settle on the value after which gain in performance is minimal.

3. Copy_in Cmd & Copy_out_cmd
This parameter specification is useful only in combination with the parameter backup_dev_type=pipe & read_fifo_cmd/remote_host for reading from remote systems. Please note that Read_fifo_cmd is valid for version till 4.0x. The read_fifo_cmd had been replaced with command remote_host effected SAP Kernel version 4.6x

SAP recommends entering the command as
copy_in_cmd = "dd bs=5k if=$" ,
copy_out_cmd = "dd bs=5k of=$" ,
to enable volume reading with the dd command.
You can also use higher blocking to improve performance.

4. Cpio_flags & Cpio_in_flags

Cpio_flags Default value: -iuvB
Cpio_in_flags Default value: -iuvB

Please ensure you maintain the default value for this parameter when using "dd" Backups

Our Productive database is around 360 GB as of now. The currently used Tape Library (IBM - Magstar 3575 L-12) with two drives was able to take the BRBackup using "Cpio" of 128K block size in around 11 hours. The average write speed had been 16GB/hr per drive during this period.

Our first Test-change in the backup parameters using "dd" options of 64K block size for the same production database scenario resulted in back up happening in 7.25 hours. The straight gain in the backup window time had been around 34% with the average write speed of 23GB/hr per drive.

On further optimizing the block size to 256K, the backup time improved to 45% by finishing in just 7 hours.

We're still in a process of optimizing the parameter to its best possible value suitable in our landscape. So, please check if my experience makes your life much easier.


This was first published in September 2002

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.