Re: ontape vs onbar

Hi, if you want to get to the bottom of this I think it is time to analyse, where the bottleneck is. Ontape is rather simple, writing directly to a (usually local) tape. ON-Bar involves several components and you should look at each of these and the communication between them. You can start with the ON-Bar activity log file to check if there is a certain "phase" in the backup that takes longer than expected. You can also check/compare to the respective lines in IDS message log. You may also want to look into ISM log files, but you may find that messages there do not exactly (time-) match with messages from ON-Bar. If you find something suspicious, you may want to switch on some tracing (e.g. BAR_DEBUG value to 2, 3 or 4) to get more timing info. While this will slow down the operation as a whole, it should give more info as to where the time (in relative values) is spent ... This may by far not be the end of the line, but at least it should give you an idea where to start. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management owner-informix-list@iiug.org wrote on 16.08.2005 22:40:03: > "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. sending to informix-list

"Martin Fuerderer" <MARTINFU@de.ibm.com> wrote in message news:1124275387.367f6e33d3f4593be9c8290f7a8a7071@teranews... > > Hi, > > if you want to get to the bottom of this I think it is time to analyse, > where the bottleneck is. Ontape is rather simple, writing directly to > a (usually local) tape. > > ON-Bar involves several components and you should look at each > of these and the communication between them. You can start with > the ON-Bar activity log file to check if there is a certain "phase" in > the backup that takes longer than expected. You can also > check/compare to the respective lines in IDS message log. You > may also want to look into ISM log files, but you may find that > messages there do not exactly (time-) match with messages from > ON-Bar. It just starts off slowly, and consistently writes out slowly, compared on ontape. There's no particular phase in which it's slow, the throughput is just consistently a quarter the speed on ontape's. I should stress again here that both ontape and onbar are writing to *disk* in this comparison. If onbar is inherently slower, then it's slower. I'd just never noticed it as being so before and am very surprised. As I say. my hunch is still that it's all down to being able to configure TAPEBLK in ontape, but not onbar ...