RE: ontape vs onbar

-----Original Message----- From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org] On Behalf Of Neil Truby Sent: 16 August 2005 10:40 PM To: informix-list@iiug.org Subject: Re: ontape vs onbar "Neil Truby" <neil.truby@ardenta.com> wrote in message news:3m44k0F156p6lU1@individual.net... > "Sebastian, Norma J." <NormaJean.Sebastian@tellabs.com> wrote in message > news:1123819964.db90e50df91cec9c2fd9298509fcd802@teranews... >>> Neil Truby wrote: >Had the feedback through now. She says: > >"Onbar compared to ontape incurs a greater overhead and therefore it is >likely to be slower than ontape. However the purpose of Onbar is to provide >greater flexibility than ontape so this is the trade-off." >> > >Then lots of general common sense about parallel backups which >unfortunately >can't be applied in this case where there is a single application dbspace. > > >Well, I just supposed that a non-parallel onbar backup would deliver >equivalent performance to ontape, but it seems not to, and there doesn't >seem to be a workaround. The original question was based upon our >expectation that onbar in its non-parallel mode and ontape would deliver >broadly similar performance. I still don't feel I understand the answer to >why this is not so: my unqualified hunch is that the answer lies in the >fact >that with ontape I was able to configure a very high "tape" block size well >suited to a disk backup. There is probably a trade-off (overhead) if you go from ontape, to a very simple onbar config, not really using much of the multithreading capability, ALMOST like using PDQ running only one single thread (does this make sense ?) I think you will have to play with multithreading, so see where you get the optimum results, and this will include writing to multiple tapes / disks, to cancel out the overhead due to using onbar. sending to informix-list