How to use DBKEY in Rdb/VMS V4.1-0

[Navipa]

Hi all,

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

As few of our tables are growing regularly to large size, the disk space issue will come in the future also even after adding new vdisk of bigger size. I know few of our bigger tables are transactions tables only without any keys/date column and reference with other master or other transaction tables. It has nearly 10 years of millions of records.

As I guess ROWNUM and ROWID facility is not available, I like to select and delete atleast the records of 5 years old using DBKEY. I don't find much details about DBKEY; I just selected out records from one of our small table is like 

48:9194:1

48:9201:1
48:9207:1
48:9231:1
48:9267:1 

How can I know about this dbkey to find the respective records and its age?, just try to help me on this.

Thanks

Navipa

[Hoff]

What's your disk data growth rate?   If you don't know the answer to that, then you will want to find out — that'll tell you how soon it'll be before you really need to make changes, based on how long it'll take to get to a terabyte.  

Rather than spelunking in the database, it's usually easier to check the database file sizes once an hour or once a day, and to record that data over a week or a month, or whatever frequency is appropriate given your database activity.  Use this data to determine the trend.

Once you are approaching a terabyte for the aggregate data, you'll then want to relocate the component files across disks. IIRC, your database is already multi-part, so relocating those files ("back") to separate disks will gain you yet more time to migrate this database and applications elsewhere, or to upgrade to a more current configuration, or to work on other and higher-priority projects.

Why add disk?   Three to five terabytes of added storage is available for under US$200.  Even expensive vendor-specific disks aren't expensive.  This if the host system doesn't already have a couple of terabytes of free space, or more.  Adding disk and expanding partitions is much less disruptive than application changes, too.  "Throw hardware at the problem", in other words.

As for the answer to your DBKEY question, there's no such mapping — you're going to have to look at the structure of the database, and figure out what data is stale, what tables are growing, and by how much and how fast.  The DBKEY is "just" an index for the particular record, you're going to have to look elsewhere within the record or the associated data, in order to draw any conclusions.   (The Rdb documentation has related details.)

I'd check with your manager here, too.    If you want to spend time and effort beyond instantiating some disks to account for increasing storage requirements, then an upgrade to a more supportable configuration and more current software would be typical.   Spending some time in the Rdb documentation, as well.  But I'd guess that spending additional time on this configuration and with what clearly appears to be a non-critical server — beyond keeping it running — is probably something your manager might not view as beneficial.

FWIW, millions of records is something I'd expect to be able to handle even on an iPhone or iPad device, these days.  That's not really all that much data.