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.

I wonder if it's that the block size being used is much smaller? There's
some excellent documentation in the DB2 Information Center, but this doesn;t
seem to be configurable.

Also, it's writing out 15 x 2Gbyte files (sequentially) rather than one
large file: thought this would be different post-9.40. Anyone know why?

Thanks
Neil

Neil Truby wrote:

How many dbspaces?

What is your storage manager?

How does onbar -b -w run?

"TBP" <TheBigPotato (AT) NotHere (DOT) Co.Uk> wrote

What does it do? Gosh, I'm going to have to read TFM aren't I? ;-)


ISM


How does onbar -b -w run?

From the command line: onbar -b -w -L 0

BAR_MAX_BACKUP identifies how many backup threads Informix will use to
push pages/images to your storage manager. (ours, with netbackup as
storage manager is set to 12... this is related to your storage
manager).

Also, what is your BAR_RETRY set to?
Ours is set to 2, this means if for some reason the first attempt at the
backup of a dbspace fails, it will retry again. (or retry 2x, so maybe 3
attempts before it gives up on that dbspace).
Check your DB log. You may see that the large app dbspace is not
backing up on first attempt?

At first you listed you run onbar -b -L 0, that is different than onbar
-b -w -L 0.
A whole backup (the -w option) will run single threaded like ontape
(which is what you said you were benchmarking against, so maybe you do
want the -w option). Not using the "-w" option can give you much
better speed if your other supporting parameters are optimized.


================================================== ==========
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
================================================== ==========

sending to informix-list

-->Root, log log, phys log (3 x temp), one large application dbspace.

i would create more dbspaces... one big dbspace will not be done in
paralel.
if this is impossible stick with
onbar -b -w -L 0

it will do the critical first (maybe paralel ) and then the app dbspace

so you will not get paralelism out of it like this...

also look at the bar params in onconfig
maybe

BAR_NB_XPORT_COUNT 10
-------------------------------------^^^^ increase
dependant on how much mem you have say 100

on 2 k systems make sure that:
BAR_XFER_BUF_SIZE 31

also check ism for paralelism
check manual!!
eq
/nsr/res/nsr/res

-->> search for your dev
and look for targetsessions.
(not more then 4!! )

and ism_config -->> streams
not more then 4..

Superboer.

"Superboer" <superboer7 (AT) planet (DOT) nl> wrote


Thanks.

I take your point. But ontape doesn't do parallelism either and it's still
twice as fast! I'd like to know why ...

cheers

Neil

Hello Neil,

sorry do not know that suppose it less efficient compared to ontape
since it has to communicate with ism.

i assume all the logging etc is switched of?? eq BAR_DEBUG is 0

also try and play with BAR_NB_XPORT_COUNT

that's all; maybe top/sar/iostat can sched more light on this.
iostat should be able to tell you what the iosize is for what ism
is doing...

Superboer.


Neil Truby schreef:

"Sebastian, Norma J." <NormaJean.Sebastian (AT) tellabs (DOT) com> wrote

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.

"Neil Truby" <neil.truby (AT) ardenta (DOT) com> 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.

-----Original Message-----
From: owner-informix-list (AT) iiug (DOT) org [mailtowner-informix-list (AT) iiug (DOT) org]
On Behalf Of Neil Truby
Sent: 16 August 2005 10:40 PM
To: informix-list (AT) iiug (DOT) org
Subject: Re: ontape vs onbar

"Neil Truby" <neil.truby (AT) ardenta (DOT) com> wrote



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