Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

device full (insufficient space for allocation)”

 
SOLVED
Go to solution
Hoff
Honored Contributor

Re: device full (insufficient space for allocation)”

This may well be the wrong disk here; the disk being discussed might not be the disk tossing the error being reported.

Start looking at the process's local login disk, and at any other disks with Oracle Rdb files (database or journal or otherwise) as Rdb can toss up these errors.

In particular, the command here is using the Oracle RMU, and that can write to and allocate space on rather more than just the target disk device.

Which disks Oracle Rdb writes its data to depends on how the local site has configured Oracle Rdb; that varies widely.

One of the classic spots for these sorts of errors is the RDMS$RUJ directory, if the local site using a more distributed organization for Oracle Rdb. That directory can require quota and adequate storage and contiguous storage.

Better yet, look at the fragmentation and the percentage full on all of the local disks, and maintain sufficiently large freespace and sufficiently low fragmentation on each.

nb: This HP OpenVMS and Oracle Rdb configuration should undergo a review for the correctness of the archival processing and for general HP OpenVMS system and Oracle Rdb database operations.
Peter Zeiszler
Trusted Contributor

Re: device full (insufficient space for allocation)”

Sometimes when a disk errors on its allocation you can see it with "anal/disk diskname". We get that sometimes after a reboot where it thinks there is no space but its just erroring on its allocation. (usually if the system has open files when its rebooted)
Steve Reece_3
Trusted Contributor

Re: device full (insufficient space for allocation)”

It's worth remembering that although VMS doesn't implicitly put any limits on the files in a directory, there can be issues when directory files get large. I've seen systems where directories become corrupt when they grow large, meaning that the files within them are not accessible.

Steve
adarsh_4
Frequent Advisor

Re: device full (insufficient space for allocation)”

the error i get in the log file is shown below

%RMU-F-WRITEERR, error writing FSCBACK:[DB_BACKUP]ENGINEERING.RBF;
-RMS-F-FUL, device full (insufficient space for allocation)
%RMU-F-FATALERR, fatal error on BACKUP
%RMU-F-FTL_BCK, Fatal error for BACKUP operation at 18-NOV-2009 00:42:46.69

Hoff
Honored Contributor

Re: device full (insufficient space for allocation)”

The error indicates that copying too much data was attempted, or that the target disk is too fragmented for the RMU attempt; that the RBF file was too big, or the disk too fragmented, or other such.

oracle Rdb can also occasionally generate these errors when your login device (and usually the [RDMS$RUJ] directory and the database journal files that get written there) or when another device that is associated with the Rdb database is full or fragmented, as well.

Which usually means that some cleaning up of some or all of the contents of the disk(s) involved will be required; of freeing space on the disk. Or replacing the disk with a disk with more free space; with an empty disk or with a bigger disk. Or copying over less stuff to the disk.

Given we're looped back to what looks to be the original problem statement with no particular progress, please contact your support organization or preferred formal escalation channel for assistance here; to have a look at this case.
Highlighted
John McL
Trusted Contributor
Solution

Re: device full (insufficient space for allocation)”

"$ HELP/MESSAGE insufficient space for allocation" gives the response...
---------
Facility: RMS, OpenVMS Record Management Services

Explanation: A $CREATE, $EXTEND, or $PUT operation for a file failed because there is not enough space on the volume or there is
not enough contiguous space (in the case of a request for contiguous space).

User Action: Delete or purge as many files as possible to provide usable space on the volume, or request the system operator to do so. If the volume is private and files cannot be deleted, obtain a new volume.
------------

Do you have a lot of fragmentation on that disk? If so, then defrag it and try again.

P.S. I like the last sentence in that help message.
Jon Pinkley
Honored Contributor

Re: device full (insufficient space for allocation)”

adarsh,

Everything you have shown us is consistent with the FSCBACK: device running out of space.

What evidence do you have that it did not fill up, or there was insufficient space for the .RBF file to be extended?

The latest instance is when ENGINEERING.RBF was being written, although you told us before if was FINANCE.DBF that was being written. You provide us with nearly no information, yet you expect us to be able to tell you why you are getting the error.

How large do these RBF jounal files get?

The next time you run the backup, while it is running, start SDA (Analyze/system), set the process to the process running RMU (SDA> Set proc/id=<8 hex digit PID of process>, then show what channels are active for the process.

example: assume process id is 2BAD4DEC

$ set proc/priv=all
$ analyze/system
SDA> set process/index=2bad4dec ! this works
SDA> set output/noheader/noindex/single sys$login:chan.txt
SDA> sho proc/chan
SDA> exit
$ show device d/mounted

Then look at the chan.txt file and see what devices are being used.

Repeat show device d/mounted several times at 5 minute intervals.

If the RMU backup is being done by a batch job, you may want to submit another batch job that runs at the same time that monitors the disk space.

Even something as simple as:

$ ver='f$verify(1)'
$ set noon
$ set prefix "(!8%T) "
$ set output_rate=00:00:10
$_top:
$ show device d/mount
$ wait 00:01:00 ! wait a minute
$ goto _top

you can just toss a delete/entry=xxxx at the batch job when done.

At least you will then have a record with 1 minute granularity of the free blocks while your backup is running.

It's been over 15 years since I used RMU, so this may not be accurate. I don't think that RBF files have to be contiguous or are limited to a single file header. Also, unless the FSCBACK:[DB_BACKUP] has many more files than I would expect it to, I think it is unlikely that the FSCBACK:[000000]DB_BACKUP.DIR file can't be extended. So I think that Hein's guess is the most likely, i.e. the disk really is getting filled up.

Did you follow the advice about analyze disk/repair or set volume/rebuild=force? It is possible that the free space being reported is not correct, and an analyze/disk/repair will correct that.

Jon
it depends
adarsh_4
Frequent Advisor

Re: device full (insufficient space for allocation)”

thank you mr Pinky, i followed what u said and manage to fix the problem. thanks once again and thanks to all of you.

adarsh_4
Frequent Advisor

Re: device full (insufficient space for allocation)”

sorry its Mr Pinkley