Informix Dynamic Server Archive/Restore

Hello All: We have a large scale Informix DB resident on an HP 9000, K460, with AutoRaid Disk Subsystem (218gb). And we are running IDS 7.30. Currently, we are using the Informix ontape archive/restore utility to archive the DB and to perform continuous logical logging. We use a single DLT to accomplish the archive. We have found this utility to be very slow when performing a level 0 archive. On average, the archive takes about 16 hours to complete with the IDS in quiescent mode. The DB consists of a combination of table and blob spaces on the Autoraid. The physical, logical, and rootdbs spaces are placed on other disk subsystems, separate and apart from the Autoraid. To improve archive performance, we have been testing the new onbar archive/restore utility using HP's Omniback for the storage manager. We found that we are able to perform onbar parallel backups (onbar -b -L 0) on the various storage spaces to improve performance, but the parallel backups can only be used to do "warm" restores. of the various db spaces. A whole onbar backup (onbar -b -w) includes "critical db spaces" and may be used to perform a "cold" restore. However, this type of backup cannot be run in parallel against the various db spaces. Rather, this restore is done serially with a single onbar thread. The question is: Is there a way to improve performance using the onbar whole backup (onbar -b -w), perhaps through the hardware configuration or through onconfig options?. Regards, Roy W. email: roy_whittington@intuit.com To archive the DB using this utility, it takes 16 hours.

Roy_Whittington@intuit.com wrote: > > Hello All: > > We have a large scale Informix DB resident on an HP 9000, K460, with > AutoRaid Disk Subsystem (218gb). And we are running IDS 7.30. > > Currently, we are using the Informix ontape archive/restore utility to > archive the DB and to perform continuous logical logging. We use a single > DLT to accomplish the archive. > > We have found this utility to be very slow when performing a level 0 > archive. On average, the archive takes about 16 hours to complete with the > IDS in quiescent mode. The DB consists of a combination of table and blob > spaces on the Autoraid. The physical, logical, and rootdbs spaces are > placed on other disk subsystems, separate and apart from the Autoraid. > > To improve archive performance, we have been testing the new onbar > archive/restore utility using HP's Omniback for the storage manager. We > found that we are able to perform onbar parallel backups (onbar -b -L 0) on > the various storage spaces to improve performance, but the parallel backups > can only be used to do "warm" restores. of the various db spaces. > > A whole onbar backup (onbar -b -w) includes "critical db spaces" and may be > used to perform a "cold" restore. However, this type of backup cannot be > run in parallel against the various db spaces. Rather, this restore is done > serially with a single onbar thread. > > The question is: Is there a way to improve performance using the onbar whole > backup (onbar -b -w), perhaps through the hardware configuration or through > onconfig options?. It depends on the storage manager you are using. If your storage manager supports spreading the archive over multiple devices you can reduce the archive time accordingly using the parallelization of the SM. Another option is to get a DLT7000 tape array. Arrays of up to five drives are available and these are treated as a single device to the OS and ontape/onbar but are n-times faster. Also most of these tape arrays can operate in RAID5 mode whereby parity is written to one of the physical drives so that a bad tape can be recovered or rebuilt. Art S. Kagel

Hi Roy, try to get the information by using the "dd" command. If "dd" can perform faster, than there is a way to speed up your backup. First question: How long does it take to read 1GB from your AutoRaid system. dd if=/dev/oneofyourchunks of=/dev/null bs=64k count=16384 ( ensure that your chunk is at least 1GB ) dd if=/dev/oneofyourchunks of=/dev/rmt/yourtapedevice bs=64k count=16384 Possibly something will change if you would use a larger blocksize ( bs=128k count=8192 ) ? Once you know how long it takes to backup 1GB manually by the dd command, you can calculate how long it will take to backup 218GB. Because you would like the "synchronous backup" you can think of a linear increase. Best regards, Stefan Weideneder Roy_Whittington@intuit.com wrote: > > Hello All: > > We have a large scale Informix DB resident on an HP 9000, K460, with > AutoRaid Disk Subsystem (218gb). And we are running IDS 7.30. > > Currently, we are using the Informix ontape archive/restore utility to > archive the DB and to perform continuous logical logging. We use a single > DLT to accomplish the archive. > > We have found this utility to be very slow when performing a level 0 > archive. On average, the archive takes about 16 hours to complete with the > IDS in quiescent mode. The DB consists of a combination of table and blob > spaces on the Autoraid. The physical, logical, and rootdbs spaces are > placed on other disk subsystems, separate and apart from the Autoraid. > > To improve archive performance, we have been testing the new onbar > archive/restore utility using HP's Omniback for the storage manager. We > found that we are able to perform onbar parallel backups (onbar -b -L 0) on > the various storage spaces to improve performance, but the parallel backups > can only be used to do "warm" restores. of the various db spaces. > > A whole onbar backup (onbar -b -w) includes "critical db spaces" and may be > used to perform a "cold" restore. However, this type of backup cannot be > run in parallel against the various db spaces. Rather, this restore is done > serially with a single onbar thread. > > The question is: Is there a way to improve performance using the onbar whole > backup (onbar -b -w), perhaps through the hardware configuration or through > onconfig options?. > > Regards, > > Roy W. > > email: roy_whittington@intuit.com > > To archive the DB using this utility, it takes 16 hours. -- Stefan Weideneder ---------------------------------------------------------------- ----------------------------------------------------------------

Roy_Whittington@intuit.com wrote in message <7cme7e$2bq$1@news.xmission.com>... > >Hello All: > >We have a large scale Informix DB resident on an HP 9000, K460, with >AutoRaid Disk Subsystem (218gb). And we are running IDS 7.30. > >Currently, we are using the Informix ontape archive/restore utility to >archive the DB and to perform continuous logical logging. We use a single >DLT to accomplish the archive. > >We have found this utility to be very slow when performing a level 0 >archive. On average, the archive takes about 16 hours to complete with the >IDS in quiescent mode. The DB consists of a combination of table and blob >spaces on the Autoraid. The physical, logical, and rootdbs spaces are >placed on other disk subsystems, separate and apart from the Autoraid. > >To improve archive performance, we have been testing the new onbar >archive/restore utility using HP's Omniback for the storage manager. We >found that we are able to perform onbar parallel backups (onbar -b -L 0) on >the various storage spaces to improve performance, but the parallel backups >can only be used to do "warm" restores. of the various db spaces. Really ? We have tested a full cold restore ( off-line, using onbar -r ) using exactly the same commands which worked successfully. > >A whole onbar backup (onbar -b -w) includes "critical db spaces" and may be >used to perform a "cold" restore. However, this type of backup cannot be >run in parallel against the various db spaces. Rather, this restore is done >serially with a single onbar thread. A word of warning - unless Informix have fixed a known bug with onbar and omniback (version 7.24.UC7 ), parallel onbar archiving can cause the engine to hang, with the "onstat -" message of CKPT BLOCKED: ARCHIVE > >The question is: Is there a way to improve performance using the onbar whole >backup (onbar -b -w), perhaps through the hardware configuration or through >onconfig options?. Not that I know of. Informix told us the work-around for the parallel bug was to perform the whole, serial arche using the same format, onbar -b -w Sean