corruption - help fix?

[batavus]

I have a client with an old 7.2 database on an old sun box:

# uname -a
SunOS lvserv10 5.5.1 Generic_103640-24 sun4u sparc SUNW,Ultra-2


They have a bit of corruption:

13:30:58 Assert Failed: WARNING! pthdrpagetalloc:bad bfget
13:30:58 Who: Session(145, root@lvserv10, 3179, 203811420)
Thread(180, sqlexec, c23ea48, 1)
13:30:58 Results: Cannot use TBLSpace page for TBLSpace 2097153
13:30:58 Action: Run 'oncheck -pt 2097153'
13:30:58 See Also: /tmp/af.b48311
13:30:59 Process exited with return code 1: /bin/sh /bin/sh -c /usr/informix/log_full.sh 3 1 "Table failure: 'TBLSpace 2097153'." "pthdrpagetalloc:bad bfget" /tmp/



with the assert failing in /tmp as:

informix@lvserv10 (informix[pro]) 504> cat /tmp/af.b48311
TBLSpace header
0c603958: 0c57dee8 0a4bc860 00000000 00200001 .W...K.` ..... ..
0c603968: 00000000 00200004 00000000 00000000 ..... .. ........
0c603978: 00000005 00100002 00000208 00000000 ........ ........
0c603988: 00000000 00000000 00000000 00000000 ........ ........
0c603998: 00473d94 0047ea18 0a004800 00000000 .G=..G.. ..H.....
0c6039a8: 00000002 10000000 00473098 00000000 ........ .G0.....
0c6039b8: 00000000 00000000 00000000 00000000 ........ ........
0c6039c8 *
0c6039d8: 00000000 00000000 00473c00 0047c7b4 ........ .G<..G..
0c6039e8: 0047c8bc 0047c6e0 0044a610 00474060 .G...G.. .D...G@`
0c6039f8: 00473c00 0c2120f0 00000000 00000001 .G<..! . ........
0c603a08: 0c603da8 0c29a1f8 0047ea20 0000000c .`=..).. .G. ....
0c603a18: 0c603d60 00386f44 ffffffff 00000fff .`=`.8oD ........
0c603a28: 00000000 00000000 00000000 00000000 ........ ........
0c603a38 *
0c603a48: ef6ed5ac ef6ec5b8 0000000a 00000001 .n...n.. ........
0c603a58: 00000000 00000000 00000004 00000001 ........ ........
0c603a68: 00000000 00000000 ........
13:30:58
13:30:58 Assert Failed: WARNING! pthdrpagetalloc:bad bfget
13:30:58 Who: Session(145, root@lvserv10, 3179, 203811420)
Thread(180, sqlexec, c23ea48, 1)
13:30:58 Results: Cannot use TBLSpace page for TBLSpace 2097153
13:30:58 Action: Run 'oncheck -pt 2097153'
13:30:58 See Also: /tmp/af.b48311
13:30:58 Stack for thread: 180 sqlexec

base: 0x0c5f4018
len: 66048
pc: 0x00368728
tos: 0x0c602fb8

0x003680bc mt_affail (0xb48311, 0x47444c, 0xc23ea48, 0xc25ea5c, 0xc25ea5c, 0x47434c)
0x003682f4 mt_afwarn (0x47414c, 0x47434c, 0x47444c, 0xc23ea48, 0xc25ea5c, 0xc6031d8)
0x00269e9c rsam_afwarn (0x47414c, 0x47434c, 0x47444c, 0xc23ea48, 0xc25ea5c, 0xa1a522c)
0x001f6210 pthdrget (0x473e0c, 0x47ea0c, 0x47434c, 0x47444c, 0x429124, 0x0)
0x001f399c ptalloc (0x200040, 0x200040, 0x0, 0x200040, 0x1, 0xc57df44)
0x0022fb90 flalloc (0x10000, 0x0, 0x10010000, 0x6c00, 0x200040, 0xc4835e0)
0x001e7344 rspnopen (0x200040, 0x0, 0xc42eaf4, 0x4000, 0x0, 0x2)
0x002f3dec ispnopen (0x200040, 0x200040, 0x400, 0xc42eaf4, 0x0, 0xc57ec09)
0x003c167c fm_openfrag (0xc57dfd8, 0x200040, 0xc57ebb8, 0x0, 0xc42eaf4, 0x0)
0x003b8428 fmpnopen (0x200040, 0x400, 0xc42eaf4, 0x0, 0xc42eaf4, 0xc57e0d7)
0x00079df8 ddopen (0x0, 0xc290200, 0x2, 0xc57d830, 0xfffffff8, 0xc57e0d0)
0x000895fc dbopen (0xc57d848, 0x0, 0xa, 0x0, 0x0, 0xc57dc18)
0x0008933c find_db (0xc57d848, 0x895d0, 0x2, 0x0, 0x0, 0x0)
0x00089114 sqopendb (0xc57d848, 0xc57d92c, 0xc482118, 0x0, 0xffff9c36, 0x8)
0x00150d40 sqdbopen (0xc6040cc, 0x0, 0x0, 0xc42e058, 0x0, 0xc6040ad)
0x00150c38 sq_dbopen (0x0, 0x0, 0x0, 0xc6041b4, 0x47ea20, 0xc)
0x00161468 sqmain (0x47c69c, 0x473b54, 0x24, 0x47c400, 0xa, 0xef5f4118)
0x0034e574 startup (0x0, 0x2, 0xc29a234, 0xc3d6d80, 0x1, 0x0)
0x003455ec idle_processor (0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
0x00000000 ***unknown***


13:30:58
------------------ End of assertion failure 0 -----------------



No Informix support, no-one at the company knows anything about this box, let along the database. They say they do have a wall of tape backups from 5 years ago when it was still being backed up (data hasn't changed since then) - but if they used the only backup script I can find, they were doing a:

informix@lvserv10 (informix[pro]) 513> cat daily_backup
#!/bin/sh
# daily_backup
# This script is normally executed by root's cron entry.

OUTPUT_DEVICE=/dev/rmt/1
daynum=`date +%w`
case "$daynum"
in
6) DAY="Sat";;
0) DAY="Sun";;
1) DAY="Mon";;
2) DAY="Tue";;
3) DAY="Wed";;
4) DAY="Thu";;
5) DAY="Fri";;
esac

LASTLOGFILE="/var/adm/log/lastbackup"
LOGFILE=/var/adm/log/$DAY"backup.log"
ERRFILE=/var/adm/log/$DAY"backup.err"

(
echo "Backup started at `date`"
cd /
find . -depth -print|grep -v /proc | grep -v /dev | cpio -ocvB -O $OUTPUT_DEVICE
echo "Backup ended at `date`"
) > $LOGFILE

mv $LOGFILE $LASTLOGFILE


which doesn't include the raw devices...

Any assistance you can provide for resolving the issue, getting around the bad pages in the dbspace would be appreciated!

Thanks
Philip Greer

---
Batavus

 

[olded]

1) First, you're correct. The backup script you presented doesn't do a thing for backing up the database. I'd search for an archive-0 of the database.

2) Based on the log, the log_full.sh is called. Have you backup up your logical logs. If they fill up the engine will stop.

You can check your logical logs by performing an onstat -l
You should be able to identify if the logs are full.

Regards,


Ed

 

[batavus]

Logical logs are being backed up (hehe) to /dev/null (LTTAPEDEV=/dev/null).

So no issues there with the engine halting with a full log.


What do you mean 'archive-0' of the database?.....

---
Batavus