![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
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? |
#3
| |||
| |||
|
#4
| |||
| |||
|
|
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? |
![]() |
| Thread Tools | |
| Display Modes | |
| |