Initial phase of onbar backup painfully slow

IDS 9.30HC5, HP-UX11i We have this situation: starting an onbar -b -L 0 -w against an instance on our development box, about 230chunks, 30 dbspaces, 250Gb of data, mostly normal data type with some binary blobs. The initial phase - beween issuing the "onbar" command and the start of the backup of rootdbs - is taking upwards of 40 minutes or so. onstat -g sql of the informix session running the backup shows thefollowing for all that time (onstat -g ath doesn't show an "arcbackup" thread so I don't think it's ARC_VERY_OLD_PAGES): Informix Dynamic Server Version 9.30.HC5 -- On-Line -- Up 20 days 03:03:05 - - 372220 Kbytes Sess SQL Current Iso Lock SQL ISAM F.E. Id Stmt type Database Lvl Mode ERR ERR Vers 8147 SELECT sysmaster RR Wait 300 0 0 9.03 Current SQL statement : select count ( * ) from sysmaster : syschktab where dbsnum = ? and ( bitval ( flags , '0x20' ) != 0 or bitval ( flags , '0x80' ) != 0 or bitval ( flags , '0x1000' ) != 0 ) Last parsed SQL statement : select count ( * ) from sysmaster : syschktab where dbsnum = ? and ( bitval ( flags , '0x20' ) != 0 or bitval ( flags , '0x80' ) != 0 or bitval ( flags , '0x1000' ) != 0 ) This is a copy of a live instance, restored with onbar -r -w -p, and I've rebuilt the smi database. The development box is a 2-cpu machine but apart from that, it's configured more or less identically to the 4- cpu live box. Any clues?

On 24/01/2011 12:56, Malc wrote: > IDS 9.30HC5, HP-UX11i > We have this situation: > starting an onbar -b -L 0 -w against an instance on our development > box, about 230chunks, 30 dbspaces, 250Gb of data, mostly normal data > type with some binary blobs. > The initial phase - beween issuing the "onbar" command and the start > of the backup of rootdbs - is taking upwards of 40 minutes or so. > onstat -g sql of the informix session running the backup shows the> following for all that time (onstat -g ath doesn't show an "arcbackup" > thread so I don't think it's ARC_VERY_OLD_PAGES): > Informix Dynamic Server Version 9.30.HC5 -- On-Line -- Up 20 days > 03:03:05 - > - 372220 > Kbytes > > Sess SQL Current Iso Lock SQL ISAM > F.E. > Id Stmt type Database Lvl Mode ERR ERR > Vers > 8147 SELECT sysmaster RR Wait 300 0 0 > 9.03 > > Current SQL > statement : > select count ( * ) from sysmaster : syschktab where dbsnum = ? and > ( > bitval ( flags , '0x20' ) != 0 or bitval ( flags , '0x80' ) != 0 > or bitval > ( flags , '0x1000' ) != > 0 )> > Last parsed SQL > statement : > select count ( * ) from sysmaster : syschktab where dbsnum = ? and > ( > bitval ( flags , '0x20' ) != 0 or bitval ( flags , '0x80' ) != 0 > or bitval > ( flags , '0x1000' ) != 0 )> > > This is a copy of a live instance, restored with onbar -r -w -p, and > I've rebuilt the smi database. The development box is a 2-cpu machine > but apart from that, it's configured more or less identically to the 4- > cpu live box. > > Any clues? FIXED AND KNOWN DEFECTS IN IBM INFORMIX DYNAMIC SERVER 9.40 PRODUCT RELEASE DATE: 20 January 2003 II. CUSTOMER-REPORTED BUGS FIXED IN 9.40.UC1 ... bug_number 153836 description WHILE CREATING A DBSPACE LIST DURING AN ARCHIVE, ONBAR_D QUERIES SYSCHKTAB UNNECESSARILY, ONCE FOR EVERY DBSPACE, PROLONGING THIS SETUP PERIOD product_code ONUTILS component_code ONBAR ...

Jonny, thanks for that, nice to see it's a recognised bug. Weird thing is this doesn't happen on our live box - does anyone have any clue as to whether there's a workaround or fix to make a 9.30 engine do this properly? For reasons I've gone into exhaustively here before, TPTB here won't be upgrading anytime soon AFAICS... Oh and can anyone tell me where the bug description pages are these days on IBM, I've searched around and darned if I can find them?

Hello Malc, you could try "IBM IDS TechSupport" on http://www.informix-zone.com/ it gets a feed of the latest bugs found from ibm i guess. ( you have to scroll down to the bottom to get there...) it may not be what you require however at least it is something. Superboer. On 24 jan, 16:12, Malc <mal...@googlemail.com> wrote: > Jonny, thanks for that, nice to see it's a recognised bug. Weird thing > is this doesn't happen on our live box - does anyone have any clue as > to whether there's a workaround or fix to make a 9.30 engine do this > properly? > For reasons I've gone into exhaustively here before, TPTB here won't > be upgrading anytime soon AFAICS... > > Oh and can anyone tell me where the bug description pages are these > days on IBM, I've searched around and darned if I can find them?