Insufficient disk space error (9450)

[jeffcoop_69]

Hello all...
We are running progress v9 on a Compaq ML530, N.T. 4.0 and we received an error "Insufficent disk space during <system call>, fd <file descriptor>, len <bytes>, offset <bytes>, file <file-name>. (9450)". After this we got a "Wrong dbKey" error and then the database shutdown. We next performed diags on the server to see if we had a bad drive, etc... The disk drive has plenty of space (12gb) and nothing came back as bad from the server diags. We have the dB back up and running and everything looks good so far - I went through and checked the tables that were being processed at the time of the shutdown and everything looks OK - some transactions were backed out when we got the dB back up. I was wondering if anyone has any ideas of what could/would cause this or if anyone has seen this/has any thoughts? Thanks.

 

[Justin Hewitt]

Folks.

Have you scanned the database via the proutil DBRPR qualifier.

ie.
_proutil DBname -C truncate bi -G 0
_proutil DBName -C dbrpr

Options (V8) (V9 slightly different)
1
1
4
g
n
n
Q

Basically a block & record scan

Usually best to pipe these command in via a flat file & pipe out the output to another file.

eg.
_proutil DBName -C dbrpr <114gnnq.txt > Result.txt

Ok.
Are there any dbkey errors, block errors, skips etc...
If so you have database corruption..???

Can you verify the referencial integrity of the disk & controller.
IS AI active, is this disk OK.
Is BI on another disk, is this OK..??

More Information required. ???

 

[jeffcoop_69]

OK.
We've done a dbrpr to scan for bad records/blocks - no bad blocks were detected, no bad records, no skips or anything else that looks unsual with the output file.
Verify the referencial integrity of the disk & controller - I'll have to check with the network admin on this but I think that's part of the diags he ran.
AI is not active.
BI is on another disk and that disk appears to be OK - plenty of disk space, etc...


We converted the database to v9.1c from v8.3c back in mid May - did a dump and load at that time.

 

[Justin Hewitt]

Jeff.

I provide end level administration & troubleshooting to a network of 9000+ linked NT boxes all running an individual progress V8.3 database. I see all sorts of issues daily.
What I have realised regarding the progress database, is that, given a stable hardware environment the database is very stable. However faulty drive controllers, CPU's, memory dimms/simms, motherboards, hard drives, "can" all cause some form of database corruption. As you can imagine with 9000+ machines running 24-7-365, its a numbers game.

In your case, if the database scans clean, & chkdsk /f /r shows up no issues, then maybe you just had a hiccup. (lost your ptr to AI or BI)
"AIMAGE end" or "Truncate BI" usually take care of these.

We have had many "FUNNY" issues when memory was bad.
However, as the computer is a complex unit "unless" you have a total failure of a component , its often difficult to decide whether the disk corruption/database corruption was an issue of a bad drive, drive controller, cpu or bad memory.
(We have the luxury of just being able to replace the box on demand, Dump & load the database & keep going).

For the mean time In your case I would schedule another normal dumpload (if possible) & monitor the situation.
There may be a bad spot in the database that is not showing up on a scan. It is possible for DBRPR to show no errors, yet each time a certain table spot is read the broker drops or you start getting Drwtsn32.exe errors.
A normal dumpload will pick this up.
Sometimes when a index has gone bad, we see a read never come back. IDXBUILD or dumpload normally fix this.

Also
* Perform a regular chkdsk /F /R on the database drives &
* (If possible) I also use zipping as an indicator of health.
that is, I pkzip up the database & then pkzip -test it. if it scans OK I am confident of its integrity. (obviously size dependent)
(however, you should always do a scan dbrpr or pkzip -test several times. We have found that when memory is bad, you scan once & get maybe no errors , you scan the same file again & errors are suddenly reported) or the DBRPR on subsequent scans may show different results. I this case I often find there is no issue with the database once you refresh the hardware under it.

On re-occurrance I would probably look to cycle some fresh hardware into the box & again dumpload the database.
& of course keep a close eye on your backups, if you cannot bring down the primary database. It may be sufficient to restore a backup on a known good hardware setup & scan that database file.
We have also found that the progress database can sustain quite a lot of damage before it finally gives up.
Sometimes I scan a working database & find incredible amounts of block & record damage, yet miraculously the database was still up...
If you start seeing issues in scans of backups, either your backup method is faulty or your primary database is going bad...
Time to move ....

Regards

Justin.





:awink:

 

[rjilis]

hi ;
you have to verify if there is an extent that exceeded the size of 2G or onother file in relation with the database (bi,lic,...)