Under certain circumstances, SAP backups using "dd" in BRBackup utility have shown better results when compared...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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:
Command used to copy database files and non-database files from disk to tape.
Suggested Value "dd"
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
Default value: "obs=16k" for NT
"obs=16k bs=16k" for UNIX
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:
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.
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.