Question
· Mar 21, 2022

Available space in a DB

When we run data purges in a namespace, the size and space of the DB does not change.  I assume like Oracle it leaves white space that is usable by cache, but is there a way to see how much of this space is available?  Today I increased the size of the disk available to the system as we were reaching critical low disk space,  however, with the purges, we should have several hundred GB of available space inside the database to use.  And is it safe to allow the system to run out of available disk space, as long as there is enough free space in the DB for writing data?

Product version: Caché 2014.1
$ZV: Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2014.1.3 (Build 775_0_16851U)
Discussion (6)2
Log in or sign up to continue

Aside from Robert's reply of viewing in the portal, there is also ^%FREECNT.

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GSA_manage#GSA_check_databases_freespace

In terms of the risks of letting the disk space fill up, that's hard to say. If everything happening is inside a database with free space, your disk wouldn't be filling up more. It's that other activity that may run into or cause a problem. I would say to consider compacting/truncating, though your $zv is really old so it may not be safe to do so.

Thank you both for the reply.  Robert's reply was perfect, I did not see that button!  I've taken this over from a guy that left,and it appears they have been managing this by purges as  the disk has been  sitting at 100% full for a long time.  So nightly they clear enough space in the DB namespace to allow for new incoming content.  It seems like it makes it difficult to  monitor  as standard snmp tools just see disk space and cannot monitor/alert for how much free space  is  in the DB.  I'm not sure what to do about that.

It's been a while since I looked at SNMP but I believe that you can monitor database free space by setting up the Caché SNMP agent (perhaps you already have some of this configured.)

At a higher level - I would consider how much database space you are using. Does the database actually fill up (or get close to filling) between each purge? if so, then you're not really so "safe" and may need more disk space. If the databases don't completely fill up and are only so large because of an unusual event in the past, then maybe you can free up some disk space by upgrading to a version where you can safely compact/truncate, and then you have meaningful alerting based on OS free space.

What do you expect your database growth to look like in the future? Maybe you're within the bounds now, but if your activity grows in the future or spikes abruptly due to an unexpected load, will that cause a problem?

Hope that helps.

upgrading to a version where you can safely compact/truncate

If you're not able to upgrade to a newer version, there's still the option of using the ^GBLOCKCOPY utility in the %SYS namespace. Unfortunately, you'll need downtime to use the utility but if you have databases with a high amount of free space, this will make a new copy of a database using the minimal amount of disk space. Then just replace the new database file with the old**, remount the database and Bob's your uncle!

Here's InterSystem's Documentation page for the utility:

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GSTU_remote_gblockcopy

Hope this helps!

** P.S. If you did want to save the old database, 7zip is quite good at compressing CACHE.DAT (and IRIS.DAT) database files. Be sure to use the LZMA2 compression method as it works well with multiple threads/cores, and I usually use a 'light' compression level - Fast or Fastest if in windows, -mx=3 if in Linux/Unix.