Removing unwanted db stuff from RDA file to create free disk space (Insufficient disk space error)

[Navipa]

Hi all,
our environment; Charon-VAX 4000 model 108 and VMS v6.1, Rdb Version: Rdb/VMS V4.1-0.

One of our application fails with "insufficient Disk Space". I observed the disk has Rdb db areas which is running short of space. Our database has uniform_area_01 ..to 04, and mixed_area_01 to 03 which are spreaded on 4 disks. This particular disk5 has one UNIFORM_AREA_01.RDA which takes 78,00000 blocks out of the total disk5 space of 83,80080 blocks. Other 3 disks has more than 50% free space.

I will have to create free space on this disk5. I see from "sql> show table command" that any specific table uses this db area (UNIFORM_AREA_01.RDA). I don't know which DB part takes this much space on this DB area. I know this database ADB is being constantly used for more than 5 years without any database maintenance. I realize EXPORT and IMPORT wont' create much space.
I need your assistance to remove (sql> delete) something from this db area or truncate and create free space on this disk. If nothing

$ dir $DISK5:[DATABASE.PROD]
DEFAULT_AREA.SNP;1 4256
MIXED_AREA_01.RDA;1 79884
ADBPROD.RDB;1 63
UNIFORM_AREA_01.RDA;1 7761396
UNIFORM_AREA_04.SNP;1 94286

Total of 5 files, 7939885 blocks (total disk5 space = 8380080 blocks)
The disk free space says as 0%.

[Hoff]

Those are just some of the core component files of your database.  Nothing you really need, after all.   Of course if you should erroneously delete any of those files, your Rdb database will pretty quickly stop working, as the files you've just deleted comprise your Rdb database.

As you undoubtedly know from having reviewing the Rdb documentation, the .RDB file is your core database, the RDA files are most of your data, and the SNP files are so-called snapshot data that can be used to recover from various failures.

As for deleting stuff, ANALYZE /DISK /REPAIR $disk5: might free up some room, but otherwise you're going to have to look somewhere else on $disk5: for stuff you can delete or relocate.

Shut down OpenVMS, create a new partition within your emulator, and then boot a copy of your OpenVMS V6.1 installation CD or some other (and preferably newer) bootable OpenVMS partition, and use BACKUP to transfer your database data over into the new partition.   Then shut down, and configure the new partition as $disk5:, relocating the old partition to the side.  Basically, you're increasing the available size of the virtual disk; the size of what you are referring to as $disk5: here.  You could relocate some or all of these database constituent files to different disks (as was likely the case when this database was originally created), but given the ease of increasing the sizes of disk partitions and the likelihood that your host system has sufficient free storage space, that's not really worth the effort.

[Navipa]

Thanks Hoff,
Will Analyze/DISK/REPAIR free up enough space?.

My DB contains totally 4 Uniform_Areas and 3 Mixed _Areas, all Uniform and Mixed RDA files are spreaded into 4 disks. So can I  move the DISK5 content to the new vdisk using VMS BACKUP or RMD/BACKUP? OR take the entire DB backup, rename new vdisk as DISK5  and restore the entire DB ?

Thanks

Navipa.

[Volker Halle]

Navipa,

noone can tell or predict, whether **bleep**/DISK/REPAIR will free up ANY space on your DISK5 ! It would only be the case, if there are some files on that disk, which have not been completely deleted - this is pretty unlikely.

The easiest way to increase the disk space on DISK5 is:

- configure a new bigger disk on your emulator

- shutdown your database and close all files on DISK5. SHOW DEV/FILES DISK5 should only show INDEXFS.SYS.

- MOUNT/FOR the new disk

- BACKUP/IMAGE  DISK5:  new_disk

- watch out for NOBACKUP messages during the backup. If you see them, repeat the backup with /IGNORE=NOBACKUP

- change the MOUNT command to mount DISK5 in your startup procedure and mount your NEW DISK instead

- reboot your system and you should be done

Volker.

[Hoff · Accepted solution]

How much?  No idea.   The ANALYZE/DISK/REPAIR command will free up between somewhat less than the total current usage of the target disk, and zero blocks.  

Spreading an Rdb database around may or may not be necessary.   Such spreading was commonly implemented for performance reasons, and also sometimes because the disks were not sufficiently large.  Whether either or both are still factors here and applicable here is not known.

Given that most modern Windows and Linux systems have terabytes of storage available, creating a new and larger partition and repopulating it with data is often the most expedient approach, and your entire posting history here implies you want or need the most expedient solution.  It's also easier to explain.

Shuffling databases around is going to take more of an investment and — unless your existing partitions are already near or at a tebibyte (a base-2 "terabyte") in size, as that is the addressing limit on fossil OpenVMS versions — this is not usually worth the effort.  

I'm not referring to any sequences that require using RMU here, either.

Whether your existing Rdb database is being properly maintained and managed and backed up, and whether the database can be reorganized or restructured, is fodder for another discussion, and likely a rather longer discussion.   Among the larger issues here are the fossil software versions and what can be inferred as an interest in expedient answers to your OpenVMS-related problems, from which it can be inferred that there's no plan and little or no money to deal with any of this, beyond resolving outages.  Researching and collecting data and then reorganizing a database is more involved, and more effort.

In short — if I've inferred your working requirements correctly — patch it back together.   Create a larger volume and populate it with the current $disk5: contents and swap this new partition into your configuration, and move on.  Invest what time your management will allocate time and funding for, and where your management wants that invested.

[Navipa]

Hi Volker and Holf,

Thanks for your suggestions.

Finding old or unwanted records and reduce the size of the tables looks very difficult as the tables does not have any reference to other master tables, in fact I am unable to confirm which is master tables and transaction tables, the entire db lacks in referential integrity and the records are inconsist.

As per both of your great idea, I have moved the disk contents to the larger size disk, that resolved the disk space issue. but in the near future I must somehow find out the history of the records by discussing with various application users who keep on inserting and updating the tables. Thats why I ahve posted another question about DBKEY.  When I find a time, I have to find DBKEY's usuage and writing SQLMOD scripts to do sometype of Table's house keeping  work.

Thanks

Navipa