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: >>>> IDS 10.0FC3 on Solaris 9 >>>> I'm doing some backups to disk. >>>> An ontape backup of the 30G database with a 768k TAPEBLK takes about >> 25 >>>> mins, but an onbar -b -L 0 takes over twice as long. >>> How many dbspaces? >>>Root, log log, phys log (3 x temp), one large application dbspace. >> > What is your storage manager? >>>ISM >>>How does onbar -b -w run? > > Yes, onbar -w is even worse - about 2 hours, against 25 minutes with > ontape. > Very strange. > > Anyway, I raised a call with Tech Support this morning (437443), so we'll > see what they make of it. 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.