RE: Very slow onbar restore
Posted in 2004
Topics: Backup & Restore, Platform-Specific Issues, Versions, Editions & End-of-Life
Neil,
My suggestion is to always switch off KAIO on HP
at least during database restore. I saw very bad problems
with (ontape) restore in the past with KAIOON. Problems
were 100% reproducible and disappeared after we switched
to Informix AIO's.
The other idea is to try to make diagnostics of the
disk array write speed for some device, not yet restored by informix.
It might happen, that this is OS/hardware issue.
------------------------------------------
Alexey Sonkin
> -----Original Message-----
> From: Neil Truby [mailto:neil.truby@ardenta.com]
>
> IDS 7.31 on HP-UX 11.11
>
> The customer did a whole back-up onbar -b -w -L 0 on Saturday. Took about
> six hours. Netbackup 3.4.1 is used to backup to a tape device attached to
> another server on the network. Now they are doing a restore
> (onbar -r -p -w). Although it's running OK, it is so sllllooooowwwwww.
> For
> instance, if I zero out the stats, I see from onstat -D that the writes
> clock up at perhaps a few thousand a minute: about one-tenth of the rate I
> would expect.
>
> Using sar shows fast (sub 4ms) response times on the target disks.
> onstat -p also shows periods of inactivity, followed by a mass of writes,> followed by more inactivity. onstat -g ses shows the ontape thread
> constantly waiting on condition. there is nothing useful in the onbar,
> Informix or system syslogs. I've added another cpu vp (it's using kaio),
> to
> no avail.
>
> All the above points towards a systemic problem with the tape stacker.
> But
> it's not a network one: the only network card configured on the target
> server shows instant response times to a ping to the server to which the
> stacker is connected. The customer has previously tested restores on
> identical hardware/OS/Informix/ Netbackup and they have flown through at
> the
> expected rates.
>
> The customer has also executed a file system restore using the same
> stacker
> (not the samne device obviously) with the expected fast restore times.
> The
> customer also reckons that she started the restore yesterday and it went
> at
> normal speeds until it failed with a tape positioning error.
>
> Any ideas? Suggestions gratefully received.
>
> IBM support call 403279 refers.
>
> thanks
> Neil
sending to informix-list
"Alexey Sonkin" <alexeis@grandvirtual.com> wrote in message
news:c92q8v$iou$1@terabinaries.xmission.com...
>
> Neil,
>
> My suggestion is to always switch off KAIO on HP
> at least during database restore. I saw very bad problems
> with (ontape) restore in the past with KAIOON. Problems
> were 100% reproducible and disappeared after we switched
> to Informix AIO's.
Thanks. The customer is loathe to abandon the restore now, unfortunately,
so I can't try this straight away.
> The other idea is to try to make diagnostics of the
> disk array write speed for some device, not yet restored by informix.
> It might happen, that this is OS/hardware issue.
It might, but all our tests using sar, dd etc, and seeing that the ontape
thread is constantly waiting, suggest otherwise.
regards
Neil
Related threads
- IDS 10 table-level restore
- Informix Development Webinar December 11, 2007
- ontape -p/r with changed ROOTPATH
- Migrate from HP PA-RISC to HP ITANIUM by ontape