RMU BAckup fails due as the RBF file size almost 90% of the disk space.

[Navipa]

Hi all,
Charon VAX/OpenVMS v6.1, Rdb/VMS V4.1-0.

Seems the Rdb database we use has its db areas on many disks. The logical DataBS = DBAREA00:[PROD]CCS.RDB.

the below two lines backup scripts runs on daily for more than 5 years. We have two versions of MART.RBF file in the disk4, no other files on this disk4 One version will be deleted and one version will be kept along the new version taken daily. The DataBS logical refers to DBAREA00:[PROD]CCS.RDB
The MART.RBF file not used to restore so far, but luckily the application runs safe so far. Now the problem is the size of the MART file grows and backup command fails with insufficient disk space. The size of the disk4 is 80,00,000 and one of the MRT.RBF file size is 75,00,000. Because of this, now days the RMU backup fails everyday.

How this MART.RBF file become this much size, will there be any unwanted files in the database which I can delete as it is s 5 year old database without any maintenance work OR any other way such as start from scratch the full backup once a week and do the incremental backup for the rest of week's days, compress/zip?
Please give some idea how can I resolve this issue or make the database small, so that I can have successful backup to RESTORE at least in the future from now.

As this is Stromasys va runs on win2003, all these disk are files only. I have no idea how to increase size of disk4 or add the extra disk for this purpose. Can we add a extra disk to this emulated version of VAX/OpenVMS v6.0

Also I don't understand how the below RMU command backup all the DB_areas with just DataBS(CCS.RDB) specified in the RMU backup command?
==================================================
$ DELETE DISK4:[BACKUP]MART.RBF;*-1
$ RMU/BACKUP/ONLINE/LOG DataBS DISK4:[BACKUP]MART.RBF

%RMU-I-QUIETPT, waiting for database quiet point
%RMU-I-BCKTXT_01, Thread 1 uses devicesDISK4:
%RMU-I-BCKTXT_08, Thread 1 was assigned file DBAREA01:[PROD]UNIFORM_AREA_01.RDA;1
%RMU-I-BCKTXT_08, Thread 1 was assigned file DBAREA02:[PROD]UNIFORM_AREA_02.RDA;1
%RMU-I-BCKTXT_08, Thread 1 was assigned file DBAREA04:[PROD]UNIFORM_AREA_04.RDA;1
%RMU-I-BCKTXT_08, Thread 1 was assigned file DBAREA03:[PROD]UNIFORM_AREA_03.RDA;1
.....
.....
.....
%RMU-I-BCKTXT_00, Backed up root file DBAREA00:[PROD]CCS.RDB;1

%RMU-I-BCKTXT_02, Full backup of storage area DBAREA08:[PROD]DEFAULT_AREA.RDA;1
%RMU-I-BCKTXT_02, Full backup of storage area DBAREA01:[PROD]UNIFORM_AREA_01.RDA;1
%RMU-I-BCKTXT_02, Full backup of storage area DBAREA02:[PROD]UNIFORM_AREA_02.RDA;1
%RMU-I-BCKTXT_02, Full backup of storage area DBAREA03:[PROD]UNIFORM_AREA_03.RDA;1
%RMU-I-BCKTXT_02, Full backup of storage area DBAREA04:[PROD]UNIFORM_AREA_04.RDA;1
%RMU-I-BCKTXT_02, Full backup of storage area DBAREA05:[PROD]MIXED_AREA_01.RDA;1
%RMU-I-BCKTXT_02, Full backup of storage area DBAREA06:[PROD]MIXED_AREA_02.RDA;1
%RMU-I-BCKTXT_02, Full backup of storage area DBAREA07:[PROD]MIXED_AREA_03.RDA;1
%RMU-F-WRITEERR, error writing DISK4:[BACKUP]MART.RBF;
-RMS-F-FUL, device full (insufficient space for allocation)
%RMU-F-FATALERR, fatal error on BACKUP

Thanks
Navipa

[MarkOfAus]

As this is Stromasys va runs on win2003, all these disk are files only. I have no idea how to increase size of disk4 or add the extra disk for this purpose. Can we add a extra disk to this emulated version of VAX/OpenVMS v6.0

Perhaps you need to contact them?

As far as I know, unless there is some license limitation on the number of logical disks you can assign to your virtual box, then you should be able to create another disk with ample room and either encapsulate this new disk within your database or move it. Note, a backup (VMS) move will not suffice as the database has the locations set in it (if I recall, as it's been many years since I fumbled around with RDB).

Also I don't understand how the below RMU command backup all the DB_areas with just DataBS(CCS.RDB) specified in the RMU backup command?

RMU backs up the database, wherever it resides.

[abrsvc]

I don't know the details of your environment, but I believe that the SNP files are effecively saved as well.  Perhaps these snapshot files have grown rather large.  If so, try resetting the size of these files.  That may buy you enough time to investigate other options.

Dan

[Volker Halle]

Navipa,

creating a new .vdisk file for CHARON-VAX is very easy - assuming you have enough disk space on your physical disk. Use the CHARON MAKEDISK utility and create a new .vdisk file (=virtual disk) of the appropriate size. Then you need to add the 'new' disk into your CHARON configuration file and maybe update the config for the CHARON Windows service.

Volker.

[Brad McCusker]

Hi Navipa,

The RMU/BACKUP command understands the database structure and therefor it is able to backup all of the database storage areas while maintaining data consistency in the database.  That is the reason to use RMU/BACKUP instead of other backup tools.

Regarding making the database smaller, that will require intimate knowledge of the data in the database.  The obvious way to make the database smaller is to archive old data from the database with RMU/UNLOAD and then delete records.  You could look into dropping unused indexes and unused tables, but that all requires knowlwdge of the data and how it is used.

Regarding the disk size which is too small for your needs, it is not possible to make your emulated disk larger, however it is fairly straight forward to create a new, larger disk using the mkdisk utility and add it to your emulator.  You will need to plan for a shut down of the emulator to accomplish this.   I’d recommend creating a new .vdisk of at least 16,000,000 blocks (check the documentation for your specific emulator model and version for disk size limits), adding it to the CHARON configuration file and restarting CHARON (or recreating/restarting the service).  If your new disk is called DISK5, then change your backup commands to use DISK5 in place of DISK4.  DISK4 could then be used for other purposes.

If you need any help with this, our firm specializes in Rdb support and we are also a CHARON Value Added Reseller. 

Best Regards,

Brad McCusker

Software Concepts International

www.sciinc.com

[Navipa]

Thanks Dan, MarkOfAus, Brad McCusker, Volker.

Win2k3 hosts Charon VAX. I will ask lab (remote) engineer about the possiblity of creating new .vdisk and follow your suggestions. I don't know the lab engineer whether he was there during the Charon VAX migration and knows about creating new .vdisk.  OR does he has any Charon vax manual. 

I studied about another web post (forgot the website) from Volker and he mentioned about the need of special License to add a additional disk to Charon. Do we need any license or any specification for disk. Can we copy the contents of the new .vdisk to any media? Restore from .vdisk or media which will be easy?

What would be best RMU backup method (in my initial post, I have mentioned the exact RMU/backup command we used now) like full or/and incremental?

One more question, I see there is another backup prodcedure in the system which takes the backup of system on MUB0: that alo not being used. what is this device? is that tape device? or .vdisk/flat file? Can we use this device. I don't have access to the windows desktop (which hosts charon VAX) . 

$ SHOW DEV

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
QATST1$MUA0: Online 0
PROD01$MUB0: Online 0
 

 Thanks

Navipa

[Volker Halle · Accepted solution]

Navipa,

you do NOT need a special license to add another .vdisk to a CHARON-VAX.

To minimize the changes to your OpenVMS environment, you could create a new .vdisk and configure it into your CHARON-VAX. Then boot OpenVMS conversational (>>> B/1), change STARTUP_P1 to "MIN" and just do a BACKUP/IMAGE from the existing (old, small) disk to the newly created bigger disk. Then change STARTUP_P1 back to "", shutdown VMS and CHARON-VAX and use the newly created .vdisk instead of the previous smaller disk in your CHARON config file. This would allow you to get a bigger disk without ANY changes in your OpenVMS procedures !

MUB0: is most likely a virtual tape (.vtape file on your WIndows disk). You could use it for image-backups of your OpenVMS disks - much faster than a real tape.

Volker.