Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Free space within an Rdb file

2 views
Skip to first unread message

Patrick J. Feldner

unread,
Feb 8, 1990, 2:48:16 PM2/8/90
to
Dear Rdb Users:

I need a way to monitor the amount of free space left within
a Rdb partition and how, when, and by how much that file will
extend. I would also like to know about how much overhead one
can expect per relation. Ie. How much of the file is used for
overhead verses data?

Thanks in advance
-- Pat--
-=-=-=-=-=-=-=-=-=-=-= The Over Lord BUT the UNDER Paid =-=-=-=-=-=-=-=-=-=-=-
Patrick J. Feldner UUCP: fel...@iitmax.iit.edu
Senoir DEC Networks/Systems Analyst BITNET: SYSPAT@IITVAX
Chicago Title & Trust Ma Bell: (312) 630-3396

Albert Godfrind

unread,
Feb 9, 1990, 8:16:58 AM2/9/90
to

> I need a way to monitor the amount of free space left within
> a Rdb partition

Use the RMU/ANALYZE command; check the manual or the help for details on
available options.
A straight RMU/ANALYZE is a good starting point to get what you want.

> a Rdb partition and how, when, and by how much that file will
> extend.

Basically the file will extend by the factors you specified when you
defined the database (or will
use defaults). To view the current setting, just do an RMU/DUMP/HEADER.
Extension will happen
when no more space is available to store a new record.

> extend. I would also like to know about how much overhead one
> can expect per relation. Ie. How much of the file is used for
> overhead verses data ?

You need 16 bytes overhead for each record : 8 bytes are used by
pointers and control info,
another 7 bytes are added to the record itself; 1 or more bytes are
used to keep track of null
fields; there will be one byte for each group of 8 fields in the record.

On top of that, each data page has a fixed overhead of 42 bytes.

+-----------------------------------------------------------------------------+
| Albert Godfrind These are MY views, all MINE ! |
| Digital Equipment Corp. |
| European Technical Center INET: godf...@ricard.enet.dec.com |
| Valbonne, France UUCP: ...!decwrl!ricard.dec.com!godfrind |
+-----------------------------------------------------------------------------+

Marc Kenig

unread,
Feb 9, 1990, 7:09:20 PM2/9/90
to
In article <33...@iitmax.IIT.EDU> fel...@iitmax.iit.edu (Patrick J. Feldner) writes:
>Dear Rdb Users:
>
> I need a way to monitor the amount of free space left within
> a Rdb partition and how, when, and by how much that file will
> extend. I would also like to know about how much overhead one
> can expect per relation. Ie. How much of the file is used for
> overhead verses data?
>
1) You have to use RMU to find out anything you need to know about an
arbitrary Rdb database. Guide to Creating and Maintaining Databases, RTFM.
All the answers are given on an RMU/DUMP/LAREA and RMU/ANALYZE printout, if
you know what to look for, and more importantly, you know what the
questions are in the first place...

The LAREA number is the same a the RDB$RELATION_ID if you dump the
RDB$RELATIONS table.

2) It's not a simple answer anyway:

There's a 42 byte overhead per database page (default 2 blocks).
There's a SPAM page every so often (one per 1089 pages, default).
There's an Area Inventory page per SPAM page.
There's an ABM (Area Bitmap) page per realtion (area).

3) Things get more clouded by:

Compression of records
Uniform vs Mixed areas (Uniform areas can have up to 50% unused space)
Indexes, which are MOSTLY like data records/pages
Snapshot files, which are not exactly unlike data pages
After image journal files which are sort of like Snapshot files
Recovery files which are out there and taking up space, too

4) It's EXTREMELY important that you specify a correct page size and extent
when you create an area (they're not called partitions, BTW). It's also crucial
that you ALLOCATE enough space beforehand esp. if you are using HASH indexes, or
else your files will extend themselves to death and your buckets overfloweth.

Marc Kenig
VMS Engineering Manager
Informix Software, Inc.
....!pyramid!infmx!marc

0 new messages