Table Size/records

Hi All,

I want to know the size and number of records of a table. We have below mentioned progress utility for the same but it is for all tables of the database not for one required table.

Code:
proutil db-name -C tabanalys

Above mentioned utility is so much time consuming as I want to know the size of a single table.

Please suggest.

Regards
 
Thanks for your reply Tamhas!

Can for each give me the size of the table in B, MB and GB. I think it won't.

Kindly suggest.

Regards
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
You can run an analysis report for a single storage area, which will be less time-consuming than scanning the whole DB:
proutil dbname -C tabanalys area areaname > dbname.tba

If you're running this against a production DB, use private read-only buffers:
proutil dbname -C tabanalys area areaname -Bp 10 > dbname.tba

If the table is small, then as tamhas said you can write some ABL code to iterate over the records and get counts and average record sizes, using the RECORD-LENGTH function. Note though that that would only give you the size of the record data on disk. It wouldn't include the size of record and table meta-data stored on disk. This approach would underestimate the size of the table on disk. And it wouldn't advise using it for a large table as it would be very slow.
 
One more question Rob,

What do mean by "it won't include the size of the record and table meta data stored on the disk".

Is meta data is some predefined data to user table or VST tables. Isn't the data inserted by user in user defined table?. Will proutil utility contain the size of the meta data.

Kindly suggest.

Regards
 

tamhas

ProgressTalk.com Sponsor
RECORD-LENGTH gives you the size of the *data* in the record. On disk there is additional space consumed by the DB housekeeping information.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Data is stored on disk in files, or extents. Extents are made up of units called blocks. Every block in the DB is the same size (the "DB block size"), but there are different types of blocks for different types of data. Table data goes in RM blocks; index data goes in IX blocks. There are about 20 different types of blocks in the OpenEdge DB, but by quantity most of them are RM and IX blocks.

Each block type has its own internal format. For example, an RM block (in a Type II storage area) is laid out something like this:
  • 64-byte block header (contains block address, block backup counter, block type, chain type, address of next block in chain, etc.)
  • 4-byte RM header (contains number of used and free directory entries and amount of free space)
  • row (or record) directory (contains a two-byte offset for each row stored in the block, pointing to the beginning of that row)
  • contiguous free space
  • record data
Each record consists of a 2-byte record length, some meta-data about the table and the record (about 14 bytes), and then the field data. The fields are stored in variable-length format so each field consists of a length sub-field (1 or 2 bytes) followed by the field value, a number of bytes specified in the length subfield. These field values are the data you see in your application or queries. Everything else is meta-data.

When you use the RECORD-LENGTH function in ABL, it calculates the size of the entire record, data and meta-data, except for the initial 2-byte record length sub-field. The calculation in dbanalys or tabanalys is similar, except it does include the 2-byte record length in its calculation, so it will be 2 bytes larger than the average you get if you calculate it programmatically. Neither of these calculations includes the record's 2-byte row directory entry. And as you see above, some of the data in a record block has nothing to do with any particular record. This is part of the reason why the total table size shown in dbanalys doesn't match the actual size of a table on disk. Another reason is that there are data structures in the database that describe and help it to manage a table (object blocks, cluster blocks, etc.) but they don't contain record data. These also contribute to the physical size of the table on disk but they are not visible to the ABL.
 
As per my understanding:-

Meta data is the data about data or the data which is maintained for other data.

For example:-

_lock, _file and _Fields are tables which are maintaining information about other tables so it is meta data. If this is the correct concept of meta data then this meta information is stored in other tables (VST) should not be part of the actual table size.

Kindly suggest.

Regards
 

joey.jeremiah

ProgressTalk Moderator
Staff member
you can use the slib/utils/fast-rec-cnt.p in the standard libraries project at the oehive.org

the utility uses proutil idxblockreport to calc the records. note that this is not an exact number but it's pretty close.

i timed it at roughly 1 second per 500,000,000 records.

<code>

define var i as int no-undo.

run slib/utils/fast-rec-cnt.p( "<physical dbname>", "table", output i).

message i.

</code>

hth
 
Top