Why is informix onbar backup so slow?

[Byron Myers]

When I run onbar with "-b" option, the backup completes in about 6 hours. When I run onbar with "-b -w" option, the backup completes in about 16 hours. What is going on?
N4000
HP-UX 11.0
Direct SCSI tape connect to STK 9490 drive
OmniBack V3.0 cell server on HP-UX 10.20 system
OmniBack V3.0 agents on client host (slow backups).
Informix Version: 7.31.UC7AX4
DB size: 137 GB
raw informix data disk: Symemtrix 3430

[harry d brown jr]

-w option to the command, which causes it to do a "whole system" backup, which backs up all storage spaces serially

http://www.oreilly.com/catalog/unixbr/chapter/ch14.html#51700

also:

http://www.geocities.com/Heartland/Acres/4927/backup.html

[Tommy Brown]

Byron, The "advantage" is, that the Whole backup is a better recovery mechanism and must be used if the rootdbs is damaged. As you have experienced, the disadvantage is the time it takes to back up. One option is to do a "weekly" whole backup and then make certain that you back up your logical logs routinely. This would provide a recoverable procedure with a lesser time impact. I am not an expert on this, but we use the Whole backup nightly (db size < 20GB).
Tommy

[Byron Myers]

Thanks for the responses. Here is more info. When I run the "onbar -b" the tape throughput is about 20 GB/hour, but with the "onbar -b -w" the throughput is about 9 GB/hour. Why is the throughput so much slower with the "-w" option.

[Alexander M. Ermes]

Hi there.
I am not really sure, but can it depend on the compression ? Backup going that slow i have only seen, when i switched on software compression on a drive with hardware compression ( sample DLT 7000 ).
Rgds
Alexander M. Ermes

[Tommy Brown]

I think, Byron, that the DLT is not in streaming mode. Since it is a single threaded serial backup the DLT is just not being fully utilized. It would be nice if it could be incorporated with a file-system backup that would allow the multi-thread to be utilized..
Tommy

[Zafar A. Mohammed]

Hi Myers,
Can you give the detail information of Storage Manager Parameters from onconfig. I too have the same problem like the whole system backup it took me 16-18 hours and now after tunning the parameters I got the same into less than 4 hours.
If you can provide the Informix configuration file then we can look and set some speed on onbar.
Thanks
Zafar

[Byron Myers]

Okay, here are the onbar parameters in the onconfig:
BAR_ACT_LOG /informix/PRD/etc/bar_act.log
BAR_BSALIB_PATH /opt/omni/lib/ob2informix.sl
BAR_MAX_BACKUP 0
BAR_NB_XPORT_COUNT 10
BAR_PROGRESS_REQ
BAR_RETRY 1
BAR_XFER_BUF_SIZE 31
RESTARTABLE_RESTORE 0
ISM_DATA_POOL ISMData
ISM_LOG_POOL ISMLogs

here are the "Tape Parameters" in onconfig
TAPDEV /dev/null
TAPEBLK 65536
TAPESIZE 7950000
LTAPEDEV /dev/null
LTAPEBLK 16384
LTAPESIZE 9300000

[Tim D Fulford]

Hi

I'm pritty sure onbar can allow multi threading (i.e backing up more than one thing at a time). However, the -w option, as mentioned before, causes it to backup the whole database/instance serially, i.e. a single thread. This would explain the difference in the time taken & throughput.

Also there was an "OLD PAGES" bug/feature in informix 7.3? which meant that when backing up large instances it would read the pages to be backed up find out they were old & write them back to the database (updating a time index). This certainly effected the speed of ontape & I assume onbar.

Tim

[Zafar A. Mohammed]

Hi Myer,
You have 2K page size. I hope there is some limitations with the XBSA transport buffers for only 64Kb. I don't remember correctly but check the manual for Onbar for 7.3.
Will you try to increase the BAR_MAX_BACKUP parameter and see the result.
If you have 2 Tapes then OmniBackII can be Parallely backed-up.
But try to increase the parameter and let us know. I think you don't have to shutdown the engine also.

Thanks
Zafar